On Thursday, March 10, 2011 09:29:01 dsimcha wrote: > == Quote from Jonathan M Davis ([email protected])'s article > > > Linux distros _definitely_ prefer to have native binaries, and those that > > try and be 64-bit pure _can't_ use 32-bit binaries unless those binaries > > are completely statically linked - though multilib is still the most > > common scenario for 64-bit versions of most Linux distros. > > Out of curiosity, what's the advantage of this purity, other than a fairly > inconsequential amount of disk space and bandwidth savings? 32-bit can > even be _more_ efficient for certain things because pointers are only 4 > bytes instead of 8.
Probably the biggest advantage of purity is that it simplifies the system and makes life easier on package management and whatnot. For multilib, you have to have duplicate lib directories (lib and lib32, or lib and lib64, or possibly even lib, lib32, _and_ lib64). You have to make sure that everything is set up correctly so that the 32-bit stuff is where the 32-bit stuff goes and the 64-bit stuff is where the 64-bit stuff goes. You have to make sure that stuff doesn't clash. Some stuff doesn't deal very well with having mutliple architectures on the same box. You have to have more versions of all of the packages that get duplicated. You have to maintain 32-bit versions of packages targetted for 64- bit systems in addition to the normal 32-bit versions and the 64-bit versions of packages. Etc. Etc. It's not always trivial to mix 32-bit and 64-bit on the same machine, and it does create a fair bit of work for those managing the distros. On some level, it's the same as supporting a whole other achitecture. From the perspective of the user, while they may not have to worry about sorting out all of the lib directories and making sure that packages mix correctly, they _do_ have to worry about getting whatever 32-bit packages they need for something to work. As long as all you're using is distro-released packages, that isn't too bad, but using a 32-bit binary on a 64-bit box when you're not installing it with the package manager can be a pain, because you have to figure out exactly which packages you need for that particular binary to work. There have been plenty of problems with people trying to get dmd working on their 64- bit machines. It doesn't just work out of the box. Now, assuming that all of that is taken care, if you're using a 32-bit binary on a 64-bit system, you're still going to be restricted on how much that program can use. It doesn't use the native word size of the machine to do what it does, and in many cases, running a 32-bit program on a 64-bit machine is slower than running a 64-bit version of that program on that machine (though that's going to vary from program to program, since there are obviously quite a few factors which affect efficiency). And then of course, there are the people who want the purity of 64-bit for the sake of purity. They don't want to be running 32-bit programs in a 64-bit environment any more than they'd want to be running 16-bit programs in a 32-bit environment. They want a 64-bit machine to be running 64-bit code. And I'm sure that there are other reasons/advantages/disadvantages, but I believe that the average user who is aware of the issue wants to be running 64- bit programs on 64-bit machines, not 32-bit programs. And there _are_ a number of problems and disadvantages in mixing architectures and running 32-bit programs on 64-bit machines. It's worse for the folks maintaining a distro than the user of a distro, but it can be a definite issue having to deal with 32-bit stuff on a 64-bit box. - Jonathan M Davis
