Isn't it great when a thread devolves into a quarrel that goes on even after it's been marked as [SOLVED]?
To add further to the controversy (perhaps), I'd like to mention that the "bitness" of a CPU isn't actually related to the size of the memory bus. At all. For instance:
- 8-bit CPUs didn't have an 8-bit memory bus
- 16-bit CPUs didn't have a 16-bit memory bus
- Some 32-bit CPUs have a 32-bit memory bus, others don't
- Most 64-bit CPUs have a 64-bit memory bus, but that's mostly because it's convenient
A so-called 32-bit CPU has internal registers that are 32 bit wide. They can all easily manipulate numbers (data and addresses) in the range 0 to 2^32-1 (which is 4,294,967,295). An 8-bit CPU, however, dealt with numbers from 0 to 2^8-1 (which is 255).
That doesn't mean it's impossible to deal with numbers greater than 4,294,967,295 or 255 on these respective platforms. You just have to divide the larger numbers into smaller chunks, that's all (which makes that YouTube video about the importance of the number "255" in old video games look really silly). Also, some architectures allow(ed) registers to be combined, making is possible to manipulate much larger numbers directly.
Another thing it doesn't mean, is that a CPU would somehow be limited to access a memory space equal to the size of its registers. It certainly isn't. 8-bit CPUs typically had 16-bit memory buses for an address space of 64 kb. The 16-bit Intel 8086 CPU had a 20-bit memory bus (1 Mb), and the 80286 (still a 16-bit CPU) extended this to 24 (16 Mb).
The Intel 80386 was/is a 32-bit CPU which also has a 32-bit memory bus (4 Gb), but three generations later, Intel released the Pentium Pro, still a 32-bit CPU but with a 36-bit memory bus (64 Gb). The extra 4 bits were added using an ugly kludge called "Physical Address Extensions" (PAE), and while the OS can use this to extend its address space to a total of 64 Gb, a process running under said OS can still only access 4 Gb. Some of that is reserved for other purposes, typically leaving processes with a maximum of 3 Gb RAM each.
AMD created a set of 64 bit extensions (known as AMD64 or x86_64) to the Intel 80x86 architecture, and they were licensed back to Intel who decided to call them "EM64T" ("AMD who?" - every Intel executive ever). By way of cross-licensing they eventually also appeared in Intel-compatible VIA CPUs. I don't think you can buy an Intel-based system today that doesn't support "long mode" (64-bit mode). Such processors are also backwards compatible with the old 32-bit modes ("protected mode", "virtual 8086 mode" and "real mode"), meaning you can run operating systems designed for any mode you like.
So, should one choose a 32-bit or 64-bit Linux distribution? Well:
- If you want to run 64-bit applications, you need a 64-bit OS (the compatibility goes only one way)
- If you want a single process to be able to access more than 3 Gb memory, you need a 64-bit OS (se the bit about PAE above)
- If you want to run 32-bit applications, some 64-bit distributions may not work for you (at least not by default), as they may not come with the required 32-bit library files to support 32-bit applications
- And of course, if your system has more than ~60 Gb RAM, you can certainly forget about using a 32-bit OS
Basically, 64-bit is certainly the future for the 80x86 platform, but there's still a significant amount of 32-bit applications out there, some of which may never be recompiled for x86_64.
