That only works when you are in the < 4Gb of RAM range of memory. I have machines with 8Gb and 16Gb of memory, so running 32bits is pointless.
Wrong. Running a 32 bit OS may be pointless with that much memory, but running a 32 bit app isn't. As long as an app doesn't need that much memory (like aMule), it's pointless running it at 64 bit. It only uses more memory that way, and therefore it also runs slower.
This is a hot debated topic, given that in AMD64 your application has a lot of extra registers to use. long int math is cheaper as well. I'd say the consensus is that the performance is even and sometimes better in 64bit. Regarding aMule it seems to use about 10% more virtual memory for me, almost the same RSS.
Anyways, this is not a 32 vs 64 bits bug, but a threading one.
Just take a look at the crash reports here, and count how many are about 64 bit versions. There's something seriously wrong with the 64 bit builds, causing strange pointer corruptions.
I saw that bugs and I couldn't reproduce them. Right now aMule is working fantastically for me in my 64bit setup (I've to wait for request number 2^32 to really assure that, right now it's going by 1931804051) Keep in mind that if the xcb patch solves this issue a lot of crashes seen here are thankfully solved.
[Let me digress here a bit, the fact that aMule is doing such a number of request is highly suspicious, for instance XDefineCursor is being called 10 times a second from toolbar code. WTF wx!. I'll have a look at some profiling information, but I cannot promise anything]
I'm sorry I was mistaken at first with this one. Mismatch of request number in async X connection should logically be caused by a threading bug (the application starting a request before the previous one ended)
The probability of the bug being in such a vital library was IMHO really small, given the time such a library has been in production. In this case the bug was in libxcb, I didn't expect that, and fortunately it's fixed in new versions.
I'd start suggesting to users with these strange crashes to start using 32 bit builds, as long as we're unable to fix the problems with the 64 bit version.
Of course a 64bits environment is a less mature one than a 64bits one (and 64bit users should be aware of the problems they will have). But what you suggest is a bad idea for two reasons:
- Debian based distributions have bad support for multi-arch. Anyways, you end having a lot of duplicated libraries. As wuischke said, there's no reason to duplicate libraries that are open source, if they are well written they should run in 32, 64 and 128 bits. Just think of all the 32bits libraries needed to run aMule.
- Bugs happening in 64 bits are bugs nevertheless. I don't know why are you unable to fix the problems. Maybe they are not bitting you in 32bits now. The fact you ignore it, the bug won't go away. Maybe in two years time when 16Gb setups are common 32bits will be the less supported arch.
I'd say quite the oppossite, users who are bothered by 64bits should use a 32bits distribution, not run 32bits binaries in a native 64 bits enviroments. If they have >4Gb of RAM they may use a 64bits kernel. That was my previous setup, but then I ran into the case some of my applications wanted to profit from 16Gb of RAM, so the upgrade was neeeded.
Other option is just use a chroot.
Of course, if your distribution has multi-arch setup you have none of these problems.
