The original version of this article was first published on IBM
developerWorks, and is property of Westtech Information Services. This
document is an updated version of the original article, and contains
various improvements made by the Gentoo Linux Documentation team.
This document is not actively maintained.
Making the distribution, Part 1
Birth of the Gentoo Linux distribution
Linux and me
For every Linux geek there's a time when Linux becomes more than just a name
and reveals itself as something more wonderful, powerful, and intriguing than
anything a developer has ever encountered. My revelation came while I was
working at the University of New Mexico as a sysadmin. Our NT server was
running pretty well and I had some extra time on my hands. So I got Debian set
up on a Pentium 166 server box and started learning ... and learning and
learning and learning. And then I was hooked.
First I learned the basic ins and outs of Linux: how to get around, perform
backups, get Samba running, etc. Then I set up qmail and Apache and learned
python and shell programming. I built a departmental Intranet. I got Linux
installed at home and began trying different distributions. Finally I settled
with Stampede Linux. You know how the progression goes: first you struggle
with grasping Linux basics; then, when you have a decent grip, you customize
your Linux, learning as you go. Because Linux has nothing to hide, you can
explore the technology and tools that make it tick while you grow in Linux
Linux is about potential
Linux offered something I had never seen before. If I had to put that magical
something into words, I'd call it potential: the potential to change, to
improve, to fix things, and yes, even to break things. As I upgraded to new
kernel versions I saw Linux improve before my eyes and transform itself almost
daily. And I was along for the ride! I was a part of the transformation. It
If you're anything like me, before you were exposed to Linux and open source
you looked to those big companies in Redmond and Cupertino to provide a
next-generation operating system that finally worked exactly the way you
wanted it to. But alas, that dream never became reality. And while we were
waiting, Linux came along. And although it had a lot of rough edges, it
provided something for us hacker guys and gals that we could improve upon
while we waited for the next big thing. Then one day we awoke to find that
Linux had become the next big thing. And smiling all the while, we continued
to hack away.
Linux is about people
The next thing I learned was that Linux is about people. Isn't that refreshing?
Linux isn't just a bunch of source code. It's a community. We rely on this
community to get our questions answered, and we become part of the community
when we start helping others by contributing our time and expertise.
IRC (Internet relay chat) is a great place to meet people and waste a
tremendous amount of time. The #stampede channel on irc.openprojects.net
became my official hangout. That's where I'd ask my Linux questions. It's also
where I first began to help other people out. #stampede desperately needed
experienced Linux users to help out newbies who had just gotten the
distribution installed. As is common on IRC, many of the experienced Stampede
people had lost their zeal for answering (yet another) newbie question. But I
was so excited that I actually knew the answer to newbies' questions, that I
couldn't resist helping out! And that's how my involvement with Stampede began.
I was just another guy who liked to answer questions. Of course, it wasn't
entirely altruistic, because I also helped myself to expert Linux knowledge
that the more experienced people on the channel (not to mention the Stampede
developers themselves!) had to offer.
When people ask me how to get involved in an open source project, I tell them
to find a place where they can be helpful, even if it's just by helping with
basic Linux questions. A sincere desire to help others is a great ticket into
the Linux community because this sentiment is at the heart of all open source
development (including Linux). At least, it should be.
Along the way you'll inevitably run into people who know more than you. And
you'll learn from them just as newbies continue to learn from you. It's also
likely that as you gain more experience you'll come across opportunities to help
in new ways. Maybe some of the project developers you come across will suggest
something, or they'll ask for help themselves. They may even invite you to
become part of the development team. If you're focused on helping others, they'd
be foolish to pass you by. If you're helping a lot of people out, you will
definitely be noticed in the community. That's sort of how it happened with
Stampede and me.
Gradually I became more and more involved in Stampede development. Before long,
I was an official Stampede developer. With the blessing of skibum (Matt Wood,
Stampede's head honcho), I began working on a new version of Stampede's
primitive .slp packaging format. At the time the .slp package format consisted
of a .tar.bz2 archive with a fixed-length footer stuck on the end that contained
information about the package author, a description of the contents, the package
creator, etc. This approach had two major problems: the fields were a fixed
length and the footer really wasn't that big, and there was no extensibility
built into the format (there was no way to add any additional fields to the .slp
format in the future). Obviously this thing needed a major overhaul.
Working with the senior Stampede developers, I wrote up a proposal of how to
deal with the problem. Then I started coding the prototype tools in Python. The
new format (codenamed slpv6) was somewhat similar to the IFF file format from
the Amiga world. This next-generation .slp format allowed for 2 32 fields, 2 32
categories of fields, and a maximum field data length of 2 32 bytes. Not only
was the format very extensible, it was also more compact than plain-text and
easy to parse. Both text and binary data could be stored in the format, which
allowed for a lot of possibilities for the future. The idea was to stick this
next-generation dynamic header on the end of the archive file, thereby producing
a next-generation .slp format that would serve Stampede users for years to come
and at the same time maintain compatibility with standard UNIX archive formats.
People can get ugly
slpv6 development was going well and all the senior developers were happy with
my progress. But unfortunately, two lower-level Stampede developers wanted to
control the slpv6 project. They didn't like the direction I was taking, and they
spent most of their time insulting the new slpv6 system. Though I spent hours in
heated development discussions defending the proposal against their attacks, we
weren't able to resolve anything. Eventually it became clear that they were just
naturally argumentative and wouldn't be happy until they had their way.
Fortunately for me, my project had the approval of the senior Stampede
developers. But these discussions began to wear on me and made Stampede
development very unpleasant. Ugh!
I couldn't avoid these guys since I had to hang out on #stampede to chat with
higher-level developers. And every time I was on the channel they became
combative, trying to undermine my work. They'd use devious techniques like
calling for development meetings (really just an opportunity to insult my work
in front of the senior developers). They'd also try to call for votes,
attempting to seize control of Stampede. Of course they'd only call for a vote
when they thought they had convinced enough people to agree with them.
Throughout all of this I continued my slpv6 development. Needless to say, the
senior development loved my work and wanted me to continue (without their
support I wouldn't have been able to stick it out).
Understanding the freak
These two guys belong to a category of developer I like to call "the freak". But
although they made my development work very unpleasant, I also learned a lot
from having to deal with them. At this point I'd like to offer you an expos?f
the freak developers, a sort of comprehensive overview: the qualities that make
a freak, the freak's modus operandi, and how you, the development project
leader, can confront and possibly reform the freak without exerting a lot of
In order to avoid emotional damage, you'll need one prerequisite: a backbone. If
you're unable to confront the freak in a respectful but firm manner, there's no
hope. The freak's goal is to control as much of your project as possible so that
he or she will feel powerful. The freak will use several techniques to make this
happen. First they'll start unfairly criticizing or bitterly complaining about a
project and/or the developers working on a project. Then they will refrain from
offering any constructive solutions. They will also not be willing to help with
the project in any other way unless they are promoted to the role of project
manager. Their goal is to convince you to give them as much authority as
possible so that they can solve problems that only they, with their finely
trained freak eyes, can see.
If the criticism and complaining aren't effective, they'll request a developer
meeting. This will be their opportunity to try and divide your development team
into two factions. When they think that they've gotten enough people on their
side, they'll request a vote (knowing they will win). If they don't win the vote
or they are overruled, they'll push for another developer meeting next week in
which they'll again try to divide your development team. They'll repeat this
If the developer meeting approach doesn't work, freaks will become reformers. By
adopting this role they will try to streamline (read: undermine) the oppressive
and unfair executive decision-making process by attempting to replace it with
something more democratic (read: easily manipulated.) This will often involve
convincing you that you should do whatever the majority of your developers want.
Freaks love this because then you can't override those developer meeting votes
anymore (muhahaha!). If you allow this to happen, you've basically given the
freak the keys to your Lexus. You're powerless.
In another approach, freaks will irritate and drive away your productive
developers. Then they'll work your entire team into a frenzy as they forcefully
try to reform the project's power structure. If their efforts are finally
defeated, they'll try to rally as many defectors together as possible and fork
from your project. Ouch!
Managing the freak
You can identify these guys pretty easily. They're the ones who aren't writing
any code (nor do they have any intention to). Instead they spend their time
talking about more important things. You know, those managerial issues. If
you're a project leader, it's pretty easy to deal with them. Just tell them that
you won't consider any proposal unless they produce working code. Or insist that
they constructively help the current project, which includes obeying the current
project manager, before giving them the opportunity to offer any (constructive)
criticism. If they write some nice code or start being more helpful, great. If
not, tell them to go away. They'll either leave the project (if you ignore them
long enough), or they'll get their act together and start writing some code and
generally become more pleasant.
Unfortunately the senior Stampede developers didn't take on freak management. In
other words, they allowed these two guys to pester me (and others) to no end.
While the senior developers were always in favor of my development work, they
didn't do much to get these guys under control. So one day I decided that it
would be easier to create my own distribution rather than have to put up with
the two freaks. I resigned from Stampede development and started making plans to
produce my own distro.
While I felt a bit weird about leaving a project because of two lower-level
developers, the fact that they weren't dealt with really indicated that the
project had severe managerial problems. If the higher-level developers weren't
able or willing to make sure the Stampede development effort was pleasant and
rewarding, then I didn't want to be there.
Once I left I breathed a big sigh of relief. Wow! Finally, things were calm and
quiet. Now it was time to define what my distribution would be about and what it
would contribute to the Linux distribution scene. One of the things that
attracted me to Stampede was its raw performance (thanks to its use of the
experimental Pentium-optimized pgcc compiler). So I decided to focus first on
performance. In addition to minimizing CPU utilization, I also wanted to
minimize bloat. Too many distributions (especially those popular shrink-wrapped
ones) enable so many daemons by default that you barely have any RAM left after
opening an xterm. I wanted my distribution to be lean and mean, and focused on
maximizing the performance of the hardware that it ran on. I decided to take a
holistic approach and tackle the performance problem from all angles.
But I had a serious lack of resources, since I was the only developer for my
distribution! How could I possibly create something that was comparable to
Caldera or RedHat off the ground on my own? The answer was automation. I had to
write scripts to automate everything, so that I would have a minimal amount of
time-consuming, repetitive labor. After all, that's what computers do best,
I quickly saw that writing simple scripts for the kind of automation I needed
wasn't going to be enough. I needed to design a complete system for generating a
Linux distribution from scratch. I tentatively called it the ebuild system and
got to work. The ebuild system would be able to automatically create all the
distribution binaries, automating everything from unpacking and patching the
sources to compilation, installation and packaging. After getting a basic ebuild
prototype working, I started creating ebuild scripts for the key components of a
Linux distribution (like gcc, glibc, binutils, util-linux, and friends). My
Stampede development box was gradually turning into my own system, as I
redesigned the initialization scripts (basing them on the Stampede
initialization scripts that I had previously designed) and testing and
installing every new package that I created.
A few months later I had a complete, self-hosted Linux distribution. I named it
Enoch and sat back and smiled contentedly. But what became of Enoch, and how did
Gentoo Linux evolve? Join me in my next article as I tell the story of how Enoch
became Gentoo Linux, and the many new challenges I faced along the way.
About the author
Daniel Robbins lives in Albuquerque, New Mexico. He was the President/CEO of
Gentoo Technologies Inc., the Chief Architect of the Gentoo Project and is a
contributing author of several books published by MacMillan: Caldera OpenLinux
Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel has been involved
with computers in some fashion since the second grade when he was first exposed
to the Logo programming language and a potentially lethal dose of Pac Man. This
probably explains why he has since served as a Lead Graphic Artist at SONY
Electronic Publishing/Psygnosis. Daniel enjoys spending time with his wife Mary
and his new baby daughter, Hadassah. You can contact Daniel at