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. =^)
I use a few packages from http://www.getdeb.net/ and have several 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.
IIRC 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.
You 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.
The downside is that pointer sizes in 64bit software are double, and this does sometimes have issues with the processors cache. Personally I haven't seen much difference in practice either way (except in cases where you have more RAM ... MySql on 10 GB totally rocks :)).
I was asking because I choose to install the 32bit version ... 64 bit packages are more unstable being less popular.
Absolutely 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.
Several 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.
To 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.
I 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. ;^)
Java 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.