The Answer Gang 
By Jim Dennis, Jason Creighton, Chris G, Karl-Heinz, and... (meet the Gang) ... the Editors of Linux Gazette... and You!
x86_64 distributions
From Rick Moen
Answered By: (folks on the ILUG mailing list) Kevin Lyda, Rick Moen, Braun Brelin, David Golden
[Mailing list participant Braun Brelin inadvertently triggered a noisy 100-post distribution-advocacy flamewar by asking what's the "best 64-bit Linux distro". These meta-comments followed:] -- Heather
[Kevin]
So, after that long thread, I'm wondering what Braun thinks of his
choice.
No, no, not the distro choice; his choice of ILUG as a place to email a question about Linux distros...
[Rick] Are you suggesting that there's at least one on-line Linux forum on the globe where soliciting "Suggestions for best 64-bit [sic] Linux distro" would not constitute the hapless posting of flamebait?
Someone with a bit more common sense might have posted "Here's the Linux distros I'm aware of, so far, with active x86_64 ports: Ubuntu, Kubuntu, Gentoo, Debian, Fedora, Mandriva, SuSE, RHEL, CentOS, Tao Linux, Scientific Linux, CRUX, Lineox, cAos-2, RockLinux, Knoppix64, Slamd64 (Slackware), StartCom, SourceMage, Rocks, rpath Linux, Kanotix, White Box. Any others worth mentioning?"
Someone might even have chased down a long batch of URLs for publication. -- Heather
[Kevin]
What can I say, I'm a Pisces; I dream a lot. Dreaming or not, I do
think a nearly 100-message thread on it borders on farce.
Any others worth mentioning?"
It would be nice to get some ideas of what people are using. If you
want to use a distro that will have local support, I think the question
has some merit.
Just as a reminder, though, the question posed was "What's the best...?"
You're a Taurus? I've always wondered, how do you acquire flatware?
Just as a reminder, though: The question posed was "What's the
best...?"
Yes, OK, that wasn't the wisest choice of words. But still, no matter
how distro questions are asked, these threads always seem to careen out
of control.
Okay, in most respects they do, but one thing really annoys me about both KDE and GNOME is the way they still don't handle applications running from different machines and home directories properly at all. They make the assumption, time and again, that all the apps on the screen are running on the one display with prefs in the one home directory. If I wanted that, I could get a fucking Macincrap.
Older X applications used the xrdb, so that UI configuration was a property of the display. All your resource db-supporting apps could look just how you wanted them, no matter which host they were running from.
Then 10000 Windows-developer-weenies apparently jumped ship to Linux, bringing an incoherent mess of files stuck in the home directory and slagged off xrdb while completely missing the point of it, so we have things like the unadulterated horror of GConf. A few did eventually grasp what xrdb brought, and I acknowledge that xrdb would need heavy tweaking bordering on rearchitecting for "modern" preference datatypes, but they really threw the baby out with the bathwater by forsaking its core ideal of dynamic, server-brokered preferences.
P.S. See "man Xaw" for an interesting hack: you can now specify the vector-drawing commands used to draw a widget in the "displayList" xrdb resource of an Athena widget...
[Braun Brelin]
The reason I asked the question was not because I wanted to know the
best "distro", I wanted to know what was the best "64-bit" distro.
Given that 64-bit chips are still fairly new to the average user, I
wasn't sure how well the 64-bit distros stacked up.
Part of the problem is that AMD64/EM64T (collectively: x86_64[1]) are sufficiently new that they're relatively new to many long-time Linux people, too. Some will have had recent experience with one x86_64 flavor; few will be in a position to compare and contrast them very well.
Another part of the problem is that there are some subtle migration (32/64) problems, which, speaking for myself, aren't easy to master, let alone know where all the ported distros stand on them. (Some are a problem for all of the distros roughly equally, e.g., the lack of a native OO.o, Macromedia Flash interpreter, WINE, Win32 codecs, etc.) Basically, after booting an x86_64 Linux distribution, running apps provided only in binary IA32 form requires a IA32 environment, which can be either a chroot (in what is otherwise dubbed a "pure64" OS build, with the disadvantage of chewing up disk space with all the duplicated libs, applications, and utilities) or a set of separate 32-bit libs known to the dynamic linker and in a parallel directory structure (reserving "lib" for IA32, using "lib64" for x86_64), a category of solution termed a "multiarch" OS build -- which has the disadvantage (if I understand correctly) that compiling and installing new 32-bit apps and libs is difficult.
A good survey of x86_64 distributions would start with classifying each as to whether it uses the pure64 or multiarch approach. And not even Distrowatch seems to have attempted that, so far.
Of course, you can also ignore the CPU instruction set extensions and run a regular old IA32 ("x86") distro[2] -- bringing with it the relatively smaller memory map, but simplifying software support -- but what fun would that be? ;->
[1] The nomenclature is hopelessly confused: AMD say that "x86_64" (their original term for the extended architecture) is now deprecated and that everyone should say "AMD64", but that of course would make an awkward way to encompass Intel's compatible EM64T implementation that competes with AMD's. A minority in the Linux community, such as the Debian Project, call the architecture "amd64"; I follow the most-common usage and say "x86_64", since the term is vendor-neutral.
[2] This level of backwards compatibility is the architecture's salient advantage over Intel's still-exotic and incompatible IA64 Itanium/Itanium2 (dubbed "Itanic" by TheReg) architecture -- whose existence hints at one of the problems with "lib64" directories: the namespace collision with Itanium.
Imagine my surprise when, upon trying to run it, the shell script complains that the architecture is incompatible with the drivers....
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/
