Hans Peter Anvin was talking about the overhead, whose amount was concluded from the Ubuntu benchmark test with the very title of the thread he was replying to.

What's more, Hans Peter Anvin's assertion of "the number of non-embedded machines that should run 32-bit kernels today is functionally the null set" basically means that he thinks that because Intel, his employer, don't ship more IA32 desktop CPUs, all IA32 desktop CPUs must have disappeared immediately, within one nanosecond.

Don't you think he is brain dead to this extent?

64-bit memory addressing is going to give more overhead than 32-bit addressing, but realistically, having the ability to use more memory addressing space which 64-bit allows past the 4 GB limit of 32-bit operating systems without specialized features such as PAE (Physical Address Extension) which was used in Windows Server 2003 Enterprise and Datacenter Editions.

Linux, *BSD, OSX, and other UNIX variants and like systems all have support for PAE, but the CPU utilized in the machine must also support PAE as well, and other stipulations must be met with also.

I think that as a kernel developers he is more knowledgeable about these topics than most other people, regardless for which company he works. Also, how Ubuntu performs in benchmarks is irrelevant to the technical merits of the Linux kernel, the mechanisms are the same on Red Hat or Slackware, and irrelevant for his comment, since these mechanisms were already known before.

Regarding his comment that there is no good reason to use 32 bit OSes anymore, I assume that he means modern machines. AMD delivers 64 bit x86 CPUs since 2003, Intel since 2004. Anything that old is in the world of IT ancient.

Make 892 MB of those 4GB and you are correct. Read the link I gave before for explanation.

Yeah, and with most systems coming with configurations of 8, 16, 32, and even 64 GB of RAM, having a 32-bit operating system is more or less self-defeating. Even PAE has it's limitations as accessing more than 4GB of RAM on a 32-bit system is considered risky due to the instabilities of the system to support the extended address ranges.

You'd kind of be nuts to even offer a system anymore with less than 4GB and a 32-bit operating system. I've even seen NetBooks starting to go 64-bit.

As originally stated, the ONLY 32-bit systems I've seen sold are ARM based 32-bit computers like Tablets and PDAs.

The only market 32-bit has left is legacy system support, and that market is shrinking every day, and for one company, specifically Intel, they're crapping bricks over this because they own x86_32, while AMD owns x86_64 technology. Right now they're in a mutual collaboration to where if one dies the other dies too, but if 32-bit dies, Intel is going to be hurting, because all AMD has to do is cease the need for x86_32 support in their CPUs and strictly move into AMD64/EM64T and they'll have Intel by the balls.

I just fell out of my chair, I thought the same thing the first time I ran in to WOW64. LOLROTF

Go in to a store, most of the motherboards are 64-bit.

I haven't seen a 32-bit motherboard in more than 5 years.

AMD64/EM64T is not possible without IA32, there are merely extensions of the architecture, not new architectures. Intel and AMD has granted each other patent licenses to use the stuff from on another, so I don't see problems if one of them would die. Which I don't expect either, with Intel as the major player in desktop and server CPUs and AMD as the major player for game console CPUs.

Me neither, because they are always hidden in the chassis.

He may know, but he can lie.
This is why he lies.
Can you point me out where Red Hat or Slackware users said Apache is 16 times faster in 64-bit than in 32-bit on the same hardware? Obviously I did not question the mechanism. I am pretty clear I only said the benchmark was fake. Drawing conclusion from obviously fake data is not good conduct.

Yes, 64-bit can be faster. But you should prove it in some way such as a t-test, etc. but not just say "Ah! Some Ubuntu guys say 64-bit is 16 times faster so no machine should run 32-bit nowadays".

That AMD and Intel deliver x86_64 CPUs since 2003/04 doesn't mean they don't deliver IA32 CPUs since then. I just checked ark.intel.com and saw the CPU for my home server, a U2500, is still active. I find no x86_64 alternative with the same or lower TDP and higher performance. I don't want to trigger a fire alarm with a hot 64-bit CPU running 24*365.

Please provide evidences for your claims that Hans Peter Anvin lies in his post. I would suspect that lying on the LKML is pretty soon be debunked by other developers.
I have never claimed they said that, I pointed out the the mechanisms are the same on any Linux OS, so that they apply to any Linux OS. Don't put words in my mouth!
If a Core 2 Duo SU9300 with 10W TDP (instead of the 9W of your CPU) will trigger your fire alarm then you should recalibrate it. Get serious.

Why something as complicated at LXC? Why not just ye olde chroot? I understand there'd be no isolation, but as you're granting lots of access anyway I think chroot would be simpler. You can set up schroot to automatically bind things and copy files. I have even set up an Ubuntu environment to run 32-bit software that was only supported under Ubuntu (though that WAS a mess).

Not many good reasons really. Mostly so I had the option of running the full stack hald, consolekit, notifyd, etc in case something expected to see the usual environment but for the most part chrooting into a 32bit tree would work fine.

You'd actually be surprised at how many motherboards I often run into with my line of work anymore. I run into very few newer systems with 32-bit only technology inside of it.

In fact little people know this but 64-bit technology has been around for a good number of years especially in memory modules and peripheral add-on cards. Most motherboards have been 64-bit capable for years now even before 64-bit processors were out, but it wasn't until a CPU was created to run AMD64/EM64T and actually installed in those systems that true 64-bit computing actually came to light.

I think this thread is wondering off the rails. 32-bit only hardware is going to be around and useful for a long long time yet. Both in the x86 and in the broader world of all platforms. I was more interested in the software side of things (which should be more flexible and faster moving); and further interested in the narrow space of x86 vs AMD64/EM64T.

I feel for the most user space code that can only compile/run on x86 at this stage in the game is a case that should largely be considered broken or obsolete; responding to the original post about suggest multilib be made an OOB option for Slackware.