Gentoo Linux on AMD64
But let's start from the beginning. We installed the latest version of Gentoo on a system with the following specifications: AMD64 3500+ processor (2.2GHz), K8N Neo2 (Socket939) mainboard from Micro-Star International, 2 GB of DDR SDRAM, 2 x 120 GB Maxtor hard disks, Plextor PX-712A DVD/CD Rewritable Drive, and NVIDIA GeForce4 Ti 4600 graphics card. Those who are following the series might have noticed that the we have doubled the amount of RAM since the last time - that's because we noticed that even with 1 GB of RAM, the system was still making use of the swap partition, especially when compiling Gentoo packages in the background, while running a KDE desktop, several KDE and GNOME applications, and a web server.
We launched the Gentoo installation program from a 52.3 MB minimal live CD (version 2004.3-r1) and followed the instructions in the Gentoo Handbook. If you haven't installed any recent Gentoo release, you should know that, despite some talk about automating parts of the Gentoo installer, the installation is still as manual (read "tedious") as ever. This is of course due to Gentoo's policy of making sure that users installing the distribution learn the basics of a Linux-based operating system early, rather than flood the mailing lists and forums with elementary questions later. While this attitude is understandable, even commendable, those of us who frequently install various distributions for testing purposes or for large-scale deployment would certainly welcome a more automated installation procedure.
We decided to perform a full installation from "stage1". This would seem like a waste of time and effort on a AMD64 system - on traditional x86 architectures we could further optimize the build process to target our chip, whether that be a Pentium 4, an Athlon XP, or even a 486, but what do we optimize for on an AMD64 system? The Gentoo installation handbook doesn't deal with this issue either, but based on the information found in the GCC manual we decided to set CHOST to "x86_64-pc-linux-gnu" and CFLAGS to "-march=k8 -O2". We also defined some USE variables to indicate what type of system we are building before configuring the kernel and starting the long compilation process.
Unfortunately, things didn't go all that well. While the base system compiled and installed without a hitch, we ran into problems when trying to compile ttmkfdir (a utility to create a fonts.scale file from a set of TrueType fonts) xterm and ncurses. These were relatively easy to solve compared to a later problem with ScrollKeeper - for some reason all ScrollKeeper executable files had been pre-fixed with a name of the architecture, so other applications trying to execute "scrollkeeper" were unable to find it. A trip to Gentoo forums revealed that several other users had suffered from the same issue, until a helpful soul came along and offered a workable solution: unmask and upgrade gcc-config, then remove the CTARGET line from /etc/env.d/05gcc (despite a stern warning not to touch the file!).
The above is just an example of some of the potential setbacks facing users who attempt to compile hundreds of packages on Gentoo Linux. Since the version of Gentoo we attempted to install was a stable release (as opposed to a beta or development release), we expected things to go smoothly, but it wasn't the case. One of the solutions that we learned early to solve a compilation problem was to "unmask" a package (by placing its name in the /etc/portage/package.keywords file) and attempt to run emerge again. This often worked - for example, we weren't able to compile the "stable" mozilla-1.7.3 ebuild, but once we unmasked it, the emerge command went on to fetch and compile successfully a "testing" mozilla-1.7.3-r3 ebuild. On a positive note, we had no problems emerging KDE, and once we solved the Scrollkeeper and Mozilla issues, the remainder of the GNOME packages also compiled fine.
For those who are wondering about the speed of compiling applications on this AMD64 system, here is an indication of the processor's power: emerging the xorg-x11 package (in its default configuration) took about 25 minutes. In contrast, emerging the same package on a 1.4 GHz Pentium 4 system took about 40 minutes.
Mixing 32-bit and 64-bit applications on a Gentoo installation is achieved in a similar fashion as on Debian. The relevant libraries are stored in separate directories - /lib64 is a symbolic link to /lib and /lib32 is a symbolic link to /emul/linux/x86/lib. OpenOffice.org is only available in a 32-bit binary format and so are Opera, Flash Player, Acrobat Reader, and other binary-only applications. One nice thing about Gentoo (compared to Fedora Core) is that most of these applications are available from within the portage infrastructure (e.g. a simple "emerge corefonts" downloads and installs Microsoft TrueType fonts, "emerge nvidia-kernel" downloads and installs the NVIDIA binary driver), so there is no need to configure a third-party repository to be able to take advantage of some of the popular, but non-free software.
Despite some bugs in the installation setup and the necessity to peruse
Gentoo's community resources to solve several problems, the overall
experience of installing and using Gentoo Linux on the AMD64 system wasn't
overly negative. Sure, we cursed profusely every time the compile process
came to a sudden halt with a loud error message, but luckily, none of the
problems were showstoppers. Thanks to them, we had the opportunity to
appreciate the quality of Gentoo's documentation and the helpfulness of
users on the distribution's forums. When all was said and done, we ended up
with a a complete, fast and powerful graphical workstation, just as we did
with Debian or Fedora. And while the effort required to achieve that goal
was far greater than with the other two distributions, there is little
doubt that Gentoo Linux is an elegant operating system with powerful
package management and truly superb documentation.
| Index entries for this article | |
|---|---|
| GuestArticles | Bodnar, Ladislav |