A look at Gentoo 2004.2

Gentoo 2004.2 was released last week. As a relative Gentoo newbie, this writer decided this would be as good a time as any to slap Gentoo onto his Toshiba laptop for further study.

Gentoo's installation process is, to put it mildly, different from most Linux distributions. Gentoo does not really offer an installer as such, but does have a process for installation that is well-documented.

At first glance, the quick install instructions for x86 machines gave the impression that it would be an extremely tedious process. In actuality, the install process for Gentoo was reasonably simple as long as the user is able to follow the directions and is willing to perform an install that requires more than point and click skills.

This writer wouldn't recommend installing Gentoo for anyone new (or newish) to Linux, but for Linux users with a decent amount of experience under their belt, installing Gentoo is no major feat. It's a bit time-consuming compared to other distributions, so be prepared to set aside a few hours to perform a Gentoo install from start to finish. Depending on the speed of your machine, and which stage you choose to begin from, the installation can easily consume a workday.

One of the things that was particularly nice about Gentoo's install was the ability to set up the SSH daemon after just a few steps, and log into the Gentoo system from my main desktop and finish the install from there -- allowing me to work on another project while doing the Gentoo install from an xterm, and to simply cut and paste most of the commands necessary to install Gentoo, rather than typing them.

One thing that did not endear me to Gentoo's installation process initially was the lack of a Vi-like editor by default. To install Gentoo, one needs to edit a few files in the process and the only available editor seems to be GNU nano. While having nano available is a good thing for users who aren't used to a Vi-like editor, most experienced Linux users expect a Vi-like editor to be present on almost any running Linux system.

For current Gentoo users, there's no need to go through the installation once again to reach 2004.2. Users who are on Gentoo 1.4, 2004.0 or 2004.1 can simply sync their Portage tree and run "emerge --update world."

The Portage system and Gentoo's management tools are what set Gentoo apart from other Linux distributions, and it takes a bit to get used to for those of us reared on package-based distributions like Slackware, Red Hat and Debian. (Ladislav Bodnar contributed a nice overview of Portage back in June.) Having only briefly toyed with Gentoo in the past, this writer spent quite a bit of time getting used to Portage. It is something of an acquired taste, but it works well and it's easy to see why so many Linux users are using Gentoo.

In fact, the Portage system actually came to the rescue about mid-way through the install. While editing the system's /etc/fstab, this writer became quite frustrated with trying to think in nano while editing the file. Instead of finishing the install with nano, a quick "emerge vim" made it possible to use Vim for the remainder of the install process.

Changes in the 2004.2 release are mostly incremental. One major change in this release is the inclusion of X.org-X11 as the default XServer for licensing reasons. This release also includes GNOME 2.6, KDE 3.2.2 and XFce 4.0.5. According to this week's Gentoo Linux Newsletter, GNOME 2.6.2, KDE 3.2.3 have been marked stable in the Portage tree, and XFce 4.0.6 will be there soon.

In all, Gentoo 2004.2 isn't a radical departure from previous versions of Gentoo. It's a good starting point for users who have been interested in using Gentoo, but haven't yet stepped up to the plate. For users who like to tweak things and get to know Linux in-depth, Gentoo is a user's paradise. For users who want something to work with minimal fuss, Gentoo is not the best way to go. That's not a criticism of the distribution, but a simple acknowledgment that Gentoo method is not a quick and easy way to install Linux.

The distribution is quite solid, and well-documented. In fact, Gentoo's documentation may be some of the best on the "market" -- it's easy to follow, and the Gentoo project has done a particularly good job at providing complete documentation for the installation and use of the system. While it is taking some time to get used to, this writer plans to continue using Gentoo on his laptop for some time to come.

Index entries for this article
GuestArticles	Brockmeier, Joe

---

to post comments

A look at Gentoo 2004.2

Posted Aug 5, 2004 10:03 UTC (Thu) by stevan (guest, #4342) [Link] (1 responses)

Good overview. The one thing missed, though, was that, for me, Gentoo
has somehow put the fun back into Linux.

S

A look at Gentoo 2004.2

Posted Aug 5, 2004 16:12 UTC (Thu) by jzb (editor, #7867) [Link]

Hmmm... guess I hadn't tried "emerge fun" just yet...

Scripting language dependency

Posted Aug 5, 2004 15:25 UTC (Thu) by heinlein (guest, #1029) [Link]

I've been running Gentoo on my SPARC mail server since last October. That little Sun Blade has run a number of operating systems -- Solaris 8, Solaris 9, OpenBSD, and Debian Linux -- but Gentoo is the only one of the bunch with which I've felt really comfortable.

So now I've got Debian, Fedora Core, and Gentoo on my systems at home. To me, one startling fact is that they're all fairly dependent on a scripting language other than the POSIX shell environment for package management and, to some extent, system administration. Gentoo and Fedora both rely heavily on Python, while Debian needs Perl.

I don't necessarily think that's a bad thing, but it's an interesting admission that systems management is increasingly too complex for POSIX toolsets.

A look at Gentoo 2004.2

Posted Aug 5, 2004 16:03 UTC (Thu) by alspnost (guest, #2763) [Link]

I wonder when we'll see a release that uses the 2.6 kernel headers and NPTL out of the box? Of course, you can make use of these now - by doing some extra work at install time - but they're obviously not regarded as stable enough yet for the core release images.

I'm hoping that 2004.3 will run these out of the box - and will perhaps even be based on a gcc-3.4 base!

But whatever, I've been running on Gentoo for 18 months now, and I've never regretted it for a moment. It's "fun" in a geeky way, very clever, and has a vibrant user community. I've never had any significant problems with my system either.

A look at Gentoo 2004.2

Posted Aug 5, 2004 19:09 UTC (Thu) by tomalok (guest, #7357) [Link]

vi (well, vim, actually) is available on the 2004.2 x86 minimal install cd, although once you chroot you can't reach it any longer.

the author mentions "emerge vim" as a solution, but for quicker gratification, before doing the chroot (and after untarring the stage archive)...

cp -a /usr/bin/vi* /mnt/gentoo/usr/bin
cp -a /usr/lib/libgpm* /mnt/gentoo/usr/lib

...then vi will be there for you after you chroot.

custom installers

Posted Aug 5, 2004 20:14 UTC (Thu) by edstoner (subscriber, #4496) [Link] (2 responses)

The gentoo install cd is just a gentoo system on a bootable iso. It is not that difficult to build your own (I've done it, emerge catalyst and go from there) to include whatever you want (vim, the 2.6 kernel, a known root password and the ssh server started on boot, etc.). This is a huge incentive for me to use gentoo at work, since I can totally tweak the install process so that all server's are actually setup correctly from the start. As far as I know, this is not really possible with other distributions.

custom installers

Posted Aug 6, 2004 11:39 UTC (Fri) by Duncan (guest, #6647) [Link] (1 responses)

It's /possible/ with other distributions. I know it was certainly
possible with Mandrake, and it should be possible for /some/ definition of
the term for any distribution with an open source installer, since one can
in theory simply modify the installer source as desired and
recompile/reconstruct the config from there.

On Mandrake, it was fairly easy to redefine which packages were available
on which CDs, and what each application group would install. Mandrake's
rather excellent urpmi dependency system (based on the perl URPM module
functionality) helped in this regard a great deal.

The catch, of course, is that at that, the simplest level, one is still
installing Mandrake generated packages with Mandrake generated dependency
decisions (parallel to Gentoo's USE flags, only at this point set up by
the distribution), limiting the flexibility to some extent.

Mandrake being an RPM/SRPM distribution, the next step beyond that would
be downloading the SRPMs and recompiling them into your own RPM packages.
The caveat here is that we are VERY quickly getting into poorly documented
territory. Altho the RPM commands for working with source themselves are
fairly standard, there's no parallel to the ease of finding USE flags on
Gentoo. Many of the possible configure options for rebuilding the srpms
with the various options and dependencies are ENTIRELY undocumented,
unless one wishes to go looking at the spec files and package config
scripts themselves, going deep into knowing and understanding the
component code, rather than just issuing a command and getting available
options along with their current status, as is the Gentoo way.

The ONE thing that continues to impress me about Gentoo, and it's already
been mentioned, is the sheer availability of the necessary information for
doing many of the out of the lowest common denominator tasks. That is,
there's very few distributions (if any) that even come CLOSE to Gentoo in
the documentation area. Not only is the above far easier to do without
"deep code diving" in Gentoo than elsewhere, as mentioned, but the info
about how to actually DO it is actually THERE! One doesn't have to "just
do it", and /hope/ they get it right, as I found so often the case on
Mandrake.

Duncan

"How do you want to waste the day?" -- yeah it's Gentoo!

Posted Aug 18, 2004 19:43 UTC (Wed) by gvy (guest, #11981) [Link]

> Mandrake's rather excellent urpmi dependency system

Oh no, not that again.

urpmi clearly sucks -- it will eagerly plug you packages with mutual Conflicts: tags :(

Conectiva's apt port is much closer to a workable solution. ALT Linux 3 is rumoured to be dropping Mdk's installer remnants altogether and moving to total apt'ification of the process, which is a Good Thing(TM) -- fixing the guts of pixel's chedeur (especially older versions) is what drove me mad, even not being really active on that.

---

On the topic of USE flags, modern package repos tend to have weighs of %def_with, %if_with and tags like that in specs so that you can rebuild a package in quite distracted manner as opposed to focused spec hacking. =)

---

I personally don't like Gentoo since it drives people being closely locked up in their localhosts, hardly being able to support larger numbers of systems which is essential to lowering the costs of running the systems. Yeah, there are many factors and tweaks but somehow a person able to do the trick with source-based distro is more productive at "real tasks" with a little help from package-based power tools, and person realizing the weaknesses of pre-packaging approach is able to get around them just as easily most of the time.

It's the same reason I don't like Slackware for -- you just can't offer jobs to people spoiled by that as "The Only Distro" as you can't rely on the resulting mess to be supportable.

Gentoo is much more organized, but the idea of having C compiler and kernel headers on *production* servers just doesn't help the fact you have to administer your own package repo otherwise (or have no advantage in face of packaged solutions).

But the docs are nice, that's true. Just as the buzz and Dan's PR is.

A look at Gentoo 2004.2

Posted Aug 10, 2004 20:52 UTC (Tue) by dododge (guest, #2870) [Link] (2 responses)

Here's my experience from trying Gentoo 2004.2 last weekend (installing
from the universal CD stage3):

- the mirrorselect + grep instructions in the Handbook produced a huge
sequence of null bytes that broke the make.conf file.

- "emerge nvidia-kernel" kept trying to install the old 4496 drivers for
some reason, which screwed things up. I'm pretty sure the 6111 ebuild
was in /usr/portage but for some reason emerge was ignoring it.

Admission: at this point I ran the Nvidia 6111 installer directly, because
it seemed to be the only way to get that version installed. Chaos ensued...

- "emerge tuxracer", or indeed trying to build anything that used
OpenGL, was a problem because somewhere along the way <GL/gl.h>
disappeared. For example at one point there were symlinks in
/usr/include/GL to non-existent files.

- "glxgears" was the only OpenGL application I could seem to get to
run. After managing to build tuxracer and neverball, they kept
insisting that OpenGL wasn't available despite glxinfo claiming
otherwise. winex-cvs wouldn't even build because of some missing
OpenGL definitions.

Various attempts to uninstall, emerge, and so on never got the machine
back into shape.

Now, this is my first time working with Gentoo, so I assume I'm missing
something obvious with regard to the 4496 vs. 6111 driver issue. I plan
to try again from scratch next weekend.

A look at Gentoo 2004.2

Posted Aug 12, 2004 19:54 UTC (Thu) by drathos (guest, #6454) [Link] (1 responses)

The newer nvidia drivers are "keyword masked". This is something akin to Debian's testing branch. The proper way of installing masked ebuilds is to create the file /etc/portage/package.keywords and add the proper package and keywords. For the nvidia drivers add:

media-video/nvidia-glx ~x86
media-video/nvidia-kernel ~x86

(This is assuming that you're running x86, not amd64 or something more exotic.)

A look at Gentoo 2004.2

Posted Aug 13, 2004 2:24 UTC (Fri) by dododge (guest, #2870) [Link]

Thanks for the tip. I brought up the driver issue on a LUG mailing list and some Gentoo-knowledgable folks there explained the keyword-based system in detail. Hopefully my next install attempt this weekend will go more smoothly.