To be 64bits or not to be 64bits, that's the question...
 

So, I've been playing around with Kubuntu in two separated machines. One is running Kubuntu x86_64 and the other x86. Needless to say, the 64 bits version is a big headache. It took me far longer than necessary to get things working, findind scripts to install flash, getting a beta version of opera, codecs to work properly, etc, etc, etc. Some emulators won't run at all either, such as epsxe.

I wonder why it is taking sooooo long time to change from 32bits to 64 bits. I mean, back in the days, when Windows 95 came out, it was no problem switching to 32 bits.

The interesting thing is that Windows XP 64 had pretty much the same (actually far worse) problems than we are having today.

Personally, I am still trying to find a reason to stick with 64 bits Linux. Even the binaries are a bit bigger than 32 bits (as it is expected). Not that it is a big problem with HD's today, but it is still a negative thing overall.

All that benchmarks out there show is how slightly faster it is to compress/uncompress files and rip dvd's in a 64 bits environment. I'd give up all that if all the applications I need to run worked with a 64 bits OS (since I can't notice any difference in performance anyway).

So the question is, in your personal opinion, why is the lack of 64 bits software so big today? Why is it taking so long time to switch once and for all to a 64 bits system today? And are you using a 64 bits OS or are you waiting for better support for it as well?

That is not correct - Windows just hid the 16 bit stuff from the user.

The earliest 32-bit personal machine I know of was the Sinclair QL 1984. But had been used in unix for a while.

64, by comparison, was barely out of experimental when it got to us - great for rendering and similar hi-res number-crunching, but otherwise , you won't notice the difference.

Run 64bit OS for servers and high end applications and if you like experimenting.
Use 32bit for personal computing.

Note: this is changing quite fast.

Unless you're doing something computationally intensive, our feeble human minds won't notice the performance improvement of 64 over 32-bits. I simulate complex repairable systems and switching from 32-bit to 64-bit cut the time to run one simulation from about 40 hours to about 28 hours. Even my feeble mind recognized that!!! You'll find other, similar, reports where a 15-minute task now takes 8-minutes.

Other than adding 32-bits, the x86_64 architecture added additional registers, more instructions, relative address RIP, etc. It'll take time for developers to take full advantage of all the new features. Obviously existing code can't either, but most packages will compile perfectly fine as 64-bit apps with no or very few tweaks. Some can be a bear, but they are generally the ones that don't use autotools or are really old.

The x86_64 architecture was designed by the AMD engineers to be backwards compatible with 32-bit and 16-bit code. Hence, it is a multilib architecture and a technically proper OS provides multilib support. A lot of Linux distros try to go "pure 64-bit" and that can be a real headache because that's not standards compliant and not how the x86_64 architecture wants to run. On a multilib OS, you can run 64-bit and 32-bit applications side by side, no wrappers, no chroot, nothing fancy,

I've been using a multilib x86_64 system for almost two years and have had no problems. It is rock stable except when I do something stupid. Most of the applications I build as 64-bit apps. Six are 32-bit apps; Firefox (using it right now), mplayer, Wine, Acrobat Reader, Nero, and Lacie's lightscribe. Granted, in order to build a 32-bit Firefox, the dependencies have to be 32-bit, but you don't need two of everything. I don't use wrappers or chroots to use any of these applications, I just click the icon. However, I understand that most people don't want to use Cross Linux from Scratch and build everything themselves.

Other than CLFS, Gentoo provides good multilib support (I use Gentoo as well). Slamd64-12.0 claims to be a standards compliant multilib OS but I haven't tried it yet. Both of my kids run Ubuntu on x86_64 platforms and it provides 32-bit support, but they put files in non-standard locations. That can cause it to be a real pain in the a$$ to get a 32-bit app installed and working.

Anyway, that's my experience with 64-bit. I would recommend a multilib, standards-compliant distro to anyone using x86_64.

I'm running a pure 64-bit Arch Linux, got no problems so far. :)

Debian has taken the "Pure 64" route rather than multilib. The only exception I'm aware of is that they include the nsplugin (whose exact name I forget) with the Macromedia Flash plugin. I have been running that system for well over a year without that plugin, dual booting a 32 bit system for the rare occasions I really need Flash. The Gnash application works well on YouTube videos, but can't handle some of the newer Flash applets. Konqueror, which does not need a Mozilla type plugin, handles all Java applets fine.

As far as I know, those are the only two areas where 64-bit support is lagging. I recommend 64-bit as the primary installation unless internet apps are extremely critical, and you do not have the option of running a 32-bit OS as a backup. 64-bit OSes are the future of personal computing, and you lose very little by moving there now.

I am using lfs for AMD64(--disable-multilib, i.e. "pure-64"), it was built on fedora 7(64) and it much faster than fedora 7.

I am using AMD 64 and intel 64 about 7 months, i haven't tried lfs for intel 64.

intel 64 seems slightly better performance than AMD 64.
But I don't care.

because,
intel 64 = [______________A_area_____________________][B_area]
AMD 64 = [______A_area_____][_________B_area____________]

Where A area is traditional hardware area, all old software has been optimized for long time under name of "x86" platform(8~32bit) and some kind of cache portion? and (45nm?)
Otherwise, B area is new relatively, for example, HyperTransport, cpu+gpu(amd spider platform), multicore etc.

intel chose stability, and AMD chose "change", i go for AMD 64, blackfin, ibm new technology(optronics), tilera, etc, etc.
* http://blackfin.uclinux.org/gf/
* http://www.tilera.com/
* http://www.macnn.com/articles/07/12/....breakthrough/
* http://en.wikipedia.org/wiki/MMIX

Thanks all for the replies. I think that for now, I will stick with Simon's above suggestion. I'm very happy with my 64bits system at the moment, but there is still a few things getting hard to work with. I don't really want to have a mixed environment at the moment either.

Because of that, I feel like I will need to go back to a 32bits OS. Which makes me actually feel kinda bad. I mean... if we all are scared to switch to a 64 bits, we are also, indirectly, telling the third party developers such as Adobe and Skype, that we don't need a 64 bits port. At least it feels that way for me.

Well, let's see. I will keep x64 a few more days and try to make everything I need to work with, well, work :D

Cheers everyone!

http://gmplib.org/32vs64.html

At least, for using gmp(Computer algebra system like maxima etc etc), better off to use pure 64.

That link would indicate that GMP 64-bit binaries outperform GMP 32-bit binaries not that pure 64 outperforms multilib. Additionally, those results are for UltraSPARC processors, not x86_64 processors. The last comment regarding Athlon processors is discussing the theoretically maximum improvement, not actual test results.

do you know what does "multilib" mean here?