5 ms·
Looking forward to upgrading from 9.04 to 9.10 ...in 3 to 6 months when all the bugs are shaken out and everything is compatible with the new version. =^)
by trevorbramble 17y ago
Looking forward to upgrading from 9.04 to 9.10 ...in 3 to 6 months when all the bugs are shaken out and everything is compatible with the new version. =^)
- ramidarigaz 17y agoWhat do you use that isn't compatible?
- trevorbramble 17y agoI use a few packages from http://www.getdeb.net/ http://www.getdeb.net/ and have several PPAs https://launchpad.net/ubuntu/+ppas https://launchpad.net/ubuntu/+ppas installed as well so there's some secondary lag there as those developers release new packages for 9.10. Which shouldn't be too long, really. My main concern with this release is the ongoing, phantom ext4 (and sometimes 3?) corruption problem. Depending on which reports you read, it affects 64-bit installations specifically, which is what I use. As much as the software, I want to ensure that there's plenty of community documentation and collective experience compiled before I switch. My System76 laptop here is my bread and butter; I don't want to find myself pathfinding on a new problem when I need to get things done, I want someone to have already charted a solution.
- bad_user 17y agoOut of curiosity ... why do you use the 64bit version? Do you have more than 4GB of ram?
- Randai 17y agoYou probably already know this, but mostly all modern CPU's (within the last 5+ years, I could be wrong on some accounts) are actually 64 bit, so I believe and I might be wrong, you are losing some optimizations. Also its your RAM + Videocard Memory that is your memory, so while you might have say 4 gig, and it would seem to show up on your computer, its including your video card memory.
- doki_pen 17y agoAbsolutely wrong. I wish ppl would stop spreading this nonsense. 64 bit is actually slower in practice, since addresses double in size. It also causes nearly double the memory consumption, since all libraries become twice as big, so when you upgrade to 64 bit, you should actually double the memory you wanted on 32 bit. There are only 2 reasons why you need 64 bit: * You need to compute extremely large numbers. You'll get big performance boosts here. * You need more then ~3.5 G ram. In which case you actually have to buy AT LEAST 8G to see a positive impact. Even this is not a hard requirement, as there are work arounds in 32-bit. But 64-bit is an absolute must if an individual process needs that much ram. note: I see I'm voted down, and maybe I'm a little harsh in my comment, but can anyone add any other reasons to go to 64 bit? I've read a ton over the years and those are the only two I could find. Maybe I should add "because 64 is bigger then 32 and I can tell ppl my OS is 64 bit" edit: Double is a great exaggeration, but not as much as the replies indicated. I moved from a 64-bit slicehost with 512M to a 32-bit linode with 320M and have LESS memory woes. The libraries really are almost twice as big. I speak from experience and not from theory.
- liuliu 17y agoSeveral reasons for me because that my desktop computer are mainly used to run several scientific computing tasks. 1. It can provide performance boost if you take advantage of that 64-bit calculation (two 32-bit calculations) is done in one clock-cycle, you can actually achieve 100% speed up. 2. Use more than 4G memory is not a big deal in scientific computing, and let's face it, more memory is better than read from disk. 3. The argument about the double memory consumption is plain wrong. All program still use int as the main type, which only 32-bit long. Only pointers takes 64-bit long, but you don't save much pointers in your memory (what's the point of keep 4G pointers in memory anyway?). Thus, the memory consumption is little larger, but definitely manageable. 4. (This point may be wrong, please correct me) double precision is common for calculation, and it takes exact 64-bit long, which makes it more suitable for 64-bit CPU.
- wmf 17y agoTo explain why you're being downvoted into oblivion: ints remain the same size, but longs and pointers are double the size. 64-bit libraries may be bigger, but there's no reason they would double in size. In general, a 64-bit system uses more RAM, but not double.
- trevorbramble 17y agoI have 4GB system and 512GB video memory installed. However, I only upgraded from 2GB after installation because the already-heavy Java apps I use (Eclipse, SQL developer) now required twice the memory. As the other commenter mentioned, there are the CPU optimizations to consider, but what decided my final transition (I've tried it out a few times over the past few years) was when System76 moved to shipping their systems with the 64-bit distro installed. I want to maximize their ability to support me, so when I did a fresh install on a new drive I opted for 64-bit as well. Most of the problems of compatibility with 32-bit binaries have been trivialized or are routed around easily enough these days. Though 64-bit Linux was never as much hassle as x64 Windows. ;^)
- gchpaco 17y agoJava is not a good benchmark. Sun's JVM won't even pack memory (if you have a class with 64 "boolean" variables, it takes header + 64*4 bytes, not header + 64/8 bytes, for some reason that is utterly unclear) unless you use arrays of primitives, and my experiments indicate that it just shifts to packing on a 32 byte boundary to packing on a 64 byte boundary on a 64-bit VM. That is to say the Sun JVM does implement the naive "everything is twice as big" translation even though it needn't. Of course the 32-bit JVM also has a 2.5 gig or so address space limit that makes no goddamn sense whatsoever, so if you want to process more than 2 gigs of data for any reason you have to either do it offline or you have to buy twice as much memory and do it on a 64 bit VM.
- pyre 17y agoIIRC 64-bit isn't just about memory size. x86_64 is a chance to use things like SSE for floating point rather than x87. The older floating point units are still on the processors, but in a depreciated fashion (Windows/Linux ABI don't use them). You can use SSE for floating point on a 32-bit system if you compile all of your apps yourself (ala Gentoo), but then the resulting binaries are not 'x86-compatible' because every x86 processor is not guaranteed to have SSE support. As you can see, x86-64 isn't just about memory size.
- swolchok 17y agoYou also get a ton more registers, 64-bit registers, and other nice processor features.
- rbanffy 17y agoA ton as in "8", right? It's not a ton by any measure...
- ZeroGravitas 17y agoThis seemed a bit harsh, but (after consulting Wikipedia) I'm guessing you're trying to say that even after doubling to 16, it still sucks compared with "common RISC processors (which typically have 32–64 registers) or VLIW-like machines such as the IA-64 (which has 128 registers)."
- rbanffy 17y agoSorry. I didn't want to sound harsh. The x86 ISA has a register starvation problem. I am sure the phone I am writing this on has a far more elegant and modern processor than the PC I'll return to after I finish lunch. The sooner we can ditch x86 (and that includes amd64), the better.
- pyre 17y agoThe problem with IA64 being that Intel designed/patented it so that they could bring in royalties if/when everyone went to 64-bit and used their architecture. I'm thanking amd64 for saving us from creating a new generation of processors where everyone was paying an Intel tax. It may have a superior design, but I don't want every processor in a desktop/laptop out there to be a revenue generation machine for a single company, even when the processor's manufacturer is different.