[ILUG] braun's choice?

[Braun Brelin]

This is definitely the truth.  For example, I'm using a GeForce 5500 video
card.  Suse Linux doesn't ship with the 3d drivers, so I downloaded (or so
I thought) the appropriate driver from the nVidia home page.  It was the
one for x86_64.

Imagine my surprise when, upon trying to run it, the shell script
complains that the architecture is incompatible with the drivers....

Braun


> 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
> --
> Irish Linux Users' Group
> http://www.linux.ie/mailman/listinfo/ilug/
>