The Gentoo Linux distribution is one of a small-but-increasing number of Linux distributions designed to allow the user to easily compile the entire operating system, without manually downloading, configuring, and installing each package. It is essentially a compromise between the Linux from Scratch approach, and the more conventional Linux-based package approach adopted by most well-known Linux distributions such as Red Hat or Debian, and more closely parallels the approach taken by the BSD's.

My attention was drawn to Gentoo via this link on Slashdot pointing to a review of Sorcerer GNU Linux, which had this reply, which refered to Gentoo as "by far stablest and easiest to install of [the three source-based distros (s)he mentions".

Gentoo is currently (Jan 2002) for people with previous Linux experience, and patience inversely proportional to the speed of your machine. If you have little or no Linux experience, or have a slow machine and little patience, then neither this distibution nor this review is for you.

. . . and by extension, the other source based distributions.

Gentoo works by bootstrapping from a small initial install into a full-blown Linux installation, much as Debian does. Instead of downloading pre-compiled binaries, though, Gentoo downloads source code to your machine and compiles it on the spot. There are two basic reasons to do this:

1. Optimize the code to your machine: Every processor model since the Pentium One has had a relatively sophisticated architecture inside. Each chip architecture gives these chips different performance characteristics. Sometimes, the best arrangement of instructions for one processer is the worst arrangement of instructions for another, and as the processors advance, the differences are magnifying. Thus, a program optimized for a Pentium II may or may not perform well on a Pentium IV, whereas the same program optimized for the Pentium IV it is running on may perform very well.
   
   Most, if not all, binary distributions of Linux work by compiling binaries for some least-common-denominator, either i386 (most common), or the i586 (a.k.a. "Pentium" One). Both of these architectures are ancient by modern standards, and while code compiled for them is quite likely to work on a wide variety of processors, it may be relatively inefficient on any particular model.
   
   The claim with source-based distributions is that by compiling everything on your machine, you can optimize it for your exact environment and personal needs. While the processor you're running on is by far the most importent factor in the optimization, one can also choose certain space-versus-time tradeoffs and more aggressive optimizations. A binary distribution must stick to the lowers common denominator, so it works on every system. Overly aggressive optimizations may break someone's system, and programs optimized to use Pentium IV instructions will not work at all on a 486, so a binary-based distribution cannot do these things. By compiling all code on your machine, the source-based distributions put the control over this process in the hands of the user.
    
2. Optimize each program to your Linux installation: Many modern Linux programs have multiple compilation options, which you cannot see reflected in your standard binary distribution. For instance, programming languages like Perl or Python might come with the option to interface to databases or certain system libraries, or a word processing program may have the option to interface to the GNOME system if you have it. When a binary distribution wish to make such a program available, they must make one of three choices:
    
1. Include the kitchen sink: Because they don't know whether this binary will be used on a system with KDE, GNOME, MySQL, SSL, any, all, or none of those, the binary designers must include all of the options. This bloats the final size of the executable with functionality that almost certainly will not always be used. (This can also cause wierd dependencies to emerge in the package database. For instance, you may find yourself installing an entire TeTeX distribution, just because an editor you are choosing to install has TeTeX support if and only if TeTeX is installed. I've never seen anything quite this drastic, but I have seen this type of thing, even in Debian. Red Hat was even worse in my experience.)
    
2. Pick and choose: The binary distributor will pick and choose what they will support. That means that even if the program includes support for Your Favorite Database, if the binary distributor chose not to include that option, you are out of luck.
    
3. Chunk the functionality into seperate packages: This is the approach taken by many distributions for programming language libraries. Want Perl? Install Perl. Want the Perl interface to MySQL? That's a seperate package. This works, but is inconvenient, complicates the dependency tree, and perhaps worst of all, is much more difficult for the package maintainer to maintain.
    

In theory, a custom binary is superior to all of those options.

One last advantage, which I haven't seen listed anywhere explicitly but is also interesting, is that it is significantly easier to create and maintain a package in the source-only system, since the maintainer need not track options, dependencies for those options, bug reports for those options, ad nauseum, but can instead just verify that the source works and move on with life. If a released set of source code fails to compile on someone's system, it's generally the program author's 'fault'. If a binary package malfunctions, it's the package maintainer's fault by default.

My review of Gentoo Linux comes from the following rather sub-spec machine:

• Pentium I w/MMX 133MHz
   
• 40 MB ram
   
• 2.1 GB hard drive
   
• No CD-ROM. Couldn't boot from it if it had one.
   
• Previous installation of Debian.
   

Due to the speed of the machine, I will refrain from reporting how long things took to compile, as it could potentially give you the wrong idea. (Think many, many hours though.)

Because I cannot boot from a CD-ROM, I followed the instructions on the download/install page for a non-ISO build. I later had to figure out how to move the newly-compiled distribution onto my hard drive, which I report on later.

I write this before Gentoo is finished installing, so my experiences are not yet "tainted" by hands-on experience with the system. We can see how my knowlege holds up to experience. :-)

It is certainly possible to increase performance significantly with proper optimizations. Starting with the Pentium I, modern Intel-style chips have had multiple pipelines, which essentially means they can do more then one thing at a time. If you have two otherwise equivalent Pentium-based machines, one running a program that keeps both of its pipelines completely full, and the other running a program which only utilizes one, in theory the former will have twice the performance of the latter. Combine that with the fact that some optimizations speed up the program in other non-processor-dependent ways, and you'll see that a multiplicitive speed increase is certainly possible.

Within my own experience on this machine, I used the stock Debian install of Enlightenment, a windows manager for XFree86 that is quite heavy on the graphics. After I re-compiled Enlightenment specifically for a Pentium architecture, Enlightenment ran roughly two times faster. In other words, if we call the original performance P133-class performance, Enlightenment was now running with P266-class performance... and that's the difference between usable, if not speedy, and painfully slow.

However, one program's performance does not necessarily relate to how the entire system will perform. Indeed, since enlightenment spends a lot of time moving graphics around and doing other, easily-optimized tasks, it is possibly a best-case for optimization improvement.

Another problem is that it takes the compiler authors time to come up with good optimizations for a given architecture; I've heard that as a rule of thumb, it can take five years to really optimize code correctly. Since I am reviewing on a Pentium I, the compiler optimizations for this platform are well understood and worked out. If you are on an Athlon or a Pentium IV, you may not experience the same benefits... though it can't hurt to stop running i386 binaries!

With regard to the other claim, it is nice to be able to ensure the binary contains no more and no less then what you can use, but with modern hard drives, this is only an issue for systems like mine.

Ironically, this is the class of machine for which optimized binaries make a significant difference, and binary size differences quickly become importent, yet compiling on such a machine is a very, very slow operation. Since this is an auxilary machine, thought, I can afford to wait. Time not spent sitting at the computer waiting really doesn't count for much in my book. For me, that eliminates many people's prime objection to this sort of system. Again, let me reiterate, if you are not the patient sort this process is not for you!

With only a few setting changes as described in the install docs, Gentoo was off and running, compiling the compiler and everything else it needed to function. An absolutely amazing amount of work was done by the computer with just a bit of editing and a few brief commands by me. In a way, it's a very empowering feeling.

The only problem I had was with a program called LyX, my favorite text processor. Compiling that with optimizations ran my system out of memory. LyX is programmed in C++, uses templating and other memory-intensive C++ features extensively, and it was just too much. Compiling without optimizations worked fine. Fortunately, LyX is already a surprisingly svelte program, despite its complicated compilation process, so it doesn't really need optimization.

One of the advantages of reviewing Gentoo on this particular Pentium 133MHz is that I am intimately familiar with the performance characteristics of the machine under a standard Debian install. If anything is faster by more then 10%, I tend to notice immediately. So with that said, the real test of the optimization stuff for my purposes will boil down to, "Does the system feel significantly more responsive?" If so, then I will be happy, otherwise, I will consider this install a failure.

Unfortunately, direct comparisions proved difficult, because Gentoo is significantly more up-to-date then my previous system. For instance, I was still using XFree86 3.3.x, whereas Gentoo runs on 4.2. 4.2 takes longer to start up, but doesn't seem any slower. But Gentoo's compile of Enlightenment did match the speed of my previous install of Enlightenment. This is interesting because I had already optimized Enlightenment on my previous system (as a bottleneck), but that required significantly more effort to do with Debian: request the source, unpack the source, configure (being careful to hit the right directories) and override the optimization settings, compile, and install. On Gentoo, it was just as simple as grabbing anything else.

The system does feel snappier, but I guess you could say I'm still burning it in.

Browsing around in the Gentoo software database, I find a surprisingly complete array of software, even stuff that is very new. One of my current areas of interest is Python, so I can read that list over and say with confidence that that is a very complete set of packages to choose from. For instance, anygui is a fairly new project right now, and there it is.

The selection of games was a bit paltry, though. ;-)

WARNING: The following details my experiences and techniques to get this system going, but this is not guarenteed to work for you, or to be complete. Do not ask me for any more support then what you see below. This is to give you an idea only. I expect that if you're trying this, you know what you're doing anyhow. I take no responsibility for damage to your system resulting from referencing the following experiences. They're not even 'directions', they're just 'experiences' and 'advice'.

For others who may wish to install Gentoo on such a constrained system and would be interested in my experiences, here's what I did in order to move Gentoo from its little staging area to the main part of my hard drive, displacing Debian in the process:

1. First, I downloaded the tar.gz file with the base Gentoo distribution in it from the somewhat-hidden download and installation page. (For some reason, this differs from the standard download/install instructions page. I found this "somewhat hidden" page in the FAQ question  
2. After finishing the install, inside of the Gentoo chroot'ed environment, I re-mounted my partitions as necessary. I only have one partition, so I re-mounted my /dev/hda3 as /mnt/hdd in the chroot'ed environment. (I took a moment to revel in the recursion.)
    
3. For safety reasons, I shut down as many of the daemon processes as I could from the original Linux install.
    
4. I blew away the old Linux, as carefully as possible. Watch out for /dev (if devfs) and /proc, and any other odd mounts you may have.
    
5. This is where it gets really interesting, and really hairy. I opened four shells, two in the chroot and two out of it. (I think you only need one of each.) I wish I could claim I did this on purpose, because it ended up saving my installation. Here's the problem with the transferal process: You need to use programs like "mv" and "ls" to do the transferring, which live in /usr/bin or /bin. These programs dynamically link to libraries in /lib, and will NOT work if those libraries are missing! Thus, if at any point the /lib directory has moved, and the /bin directory has not, you're potentially screwed.
   
   I ended up doing the following: In the chroot'ed shell, moving bin over into the re-mount of my hard drive, using [hard-drive-mount]/bin/mv to move /lib into place, panicking when everything stopped working. Switched to a non-chrooted shell, and completed moving the directories into place.
   
   I'd recommend that you carefully use the mv command to move bin, lib, and usr into their new position all at once and switching into the non-chroot'ed shell, but that's not the way I did it so I can't confirm that works.
    
6. Ran grub and installed, rebooted, and had me a Gentoo Linux system.