[ILUG] braun's choice?
Rick Moen
rick at linuxmafia.com
Thu Jun 30 00:47:34 IST 2005
Quoting Braun Brelin (bbrelin at openapp.biz):
> 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.
It's a reasonable concern.
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
a namespace collision with Itanium.
--
Cheers, "Cthulhu loves me, this I know; because the High Priests tell me so!
Rick Moen He won't eat me, no, not yet. He's my Elder God, dank and wet!"
rick at linuxmafia.com
More information about the ILUG
mailing list