Distributions

Gentoo Linux on AMD64

After having installed (been sufficiently impressed by) the AMD64 ports of both Debian Sid and Fedora Core 3 (see Debian on AMD64 and Fedora Core 3 on AMD64), we expected the same from our third victim - Gentoo Linux. Not only is Gentoo a distribution designed to be compiled locally and optimized for the system it is being installed on, Gentoo's AMD64 port has had plenty of time to mature - version 2004.3 was, in fact, the distribution's third stable release for this architecture. And although the road to a complete AMD64 Gentoo system had a lot more potholes than its Debian or Fedora counterparts, further intercepted by frequent side trips to the Gentoo forums and mailing lists, the end result was equally good - a powerful and incredibly fast high-end workstation.

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.

Comments (3 posted)

NetBSD 2.0 released

NetBSD 2.0 is out. The list of improvements in this release is quite large; see the announcement for the details.

Comments (21 posted)

Debian

The Debian Release-critical Bugreport for December 10 and the December 10 Work-needing packages report are available.

Comments (none posted)

Fedora Core 3 for PowerPC platforms

A version of Fedora Core 3 for the PowerPC platform has been released for testing. Click below for details, open issues with this release, and mailing list information.

Full Story (comments: none)

Fedora Core

Fedora Core 3 updates: libpng10 (latest version), libpng (latest version), glib2 (bug fixes), gtk2 (bug fixes), postgresql-odbc (64 bit fixes), shadow-utils (bug fixes), MyODBC (locale setting bug fix), grep (UTF-8 performance improvement), gstreamer (multilib support), mikmod (packaging change)

Fedora Core 2 updates: libpng (bug fixes), libpng10 (latest version), glib2 (bug fixes), gtk2 (bug fixes), postgresql-odbc (64 bit fixes), postgresql (synchronize with FC3), shadow-utils (bug fixes), MyODBC (locale setting bug fix)

Comments (none posted)

Unofficial Fedora FAQ Updated

An update of the Unofficial Fedora FAQ dated December 13, 2004 is available. Changes include several new translations, and various topic improvements.

Full Story (comments: none)

Mandrakelinux

Mandrakelinux updates: evolution (bug fixes), mdkonline (bug fixes and windowless capability), libpng (invalid zlib header problem).

Comments (none posted)

Trustix Secure Linux

Trustix Secure Linux updates: multiple packages.

Comments (none posted)

The Ubuntu 4.10 starter guide

Chua Wen Kiat has put together an unofficial starter guide for the Ubuntu "warty" release. It is a wide-ranging document in the FAQ style which may become a required bookmark for anybody working with the Ubuntu distribution.

Comments (none posted)

What's the Ubuntu community up to?

The Ubuntu distribution has announced a new community work page. "Please update this page with projects/initiatives that you have/are undertaking, so everyone can read what's happening all over the world in sharing Ubuntu."

Full Story (comments: none)

Gentoo Weekly Newsletter

The December 13 issue of the Gentoo Weekly Newsletter is out; this week's issue looks at the new Chinese forum, virtualization techniques, and more.

Full Story (comments: none)

Product Reviews: BeatrIX GNU/Linux (LinuxTimes)

LinuxTimes.Net reviews BeatrIX GNU/Linux, an Ubuntu/Knoppix-based live CD distribution. "BeatrIX is a functional, easy to use and easy to set up desktop system for the average user. Power users will find the lack of utilities in the default install annoying, but it may be worth the trade for a more custom environment and a smaller download."

Comments (1 posted)

My workstation OS: Slackware (NewsForge)

Michael Stibane reviews Slackware 10 in a NewsForge article. "Working as a freelance Linux trainer and writer for a few German Linux magazines, I have to test a lot of software. If it's bleeding edge and packaged as RPM or DEB it usually causes major problems when I install the software on Debian or RPM-based distros. It's a pain to bring Debian package management back to a normal state once it's out of sync after a dpkg -i --force-things command. By contrast, there is nothing like Slackware's tgz packaging without dependency checks (except compiling from source). Install the package, run it from a terminal, and see which libraries are not found. Install those too and usually everything is fine. Slackware also takes RPM packages without questions if you supply the --nodeps switch."

Comments (2 posted)