swift 05/07/05 10:37:39
Added: www-redesign/htdocs/doc/en/articles index.xml
lpi-101-fundamentals-p1.xml
making-the-distro-p1.xml making-the-distro-p2.xml
making-the-distro-p3.xml
Log:
Wrong location
Revision Changes Path
1.1
gentoo-projects/www-redesign/htdocs/doc/en/articles/index.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/index.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/index.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: index.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!-- $Header:
/var/cvsroot/gentoo-projects/www-redesign/htdocs/doc/en/articles/index.xml,v
1.1 2005/07/05 10:37:39 swift Exp $ -->
<!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd">
<dynamic metadoc="/doc/en/metadoc.xml">
<title>Articles</title>
<intro>
<section>
<!--<title>Previously published articles</title>-->
<body>
<p>
A number of our developers have written articles for the Linux community. We
have republished them here for your convenience.
</p>
</body>
</section>
</intro>
<catid>articles</catid>
</dynamic>
1.1
gentoo-projects/www-redesign/htdocs/doc/en/articles/lpi-101-fundamentals-p1.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/lpi-101-fundamentals-p1.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/lpi-101-fundamentals-p1.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: lpi-101-fundamentals-p1.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo-projects/www-redesign/htdocs/doc/en/articles/lpi-101-fundamentals-p1.xml,v
1.1 2005/07/05 10:37:39 swift Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/lpi-101-fundamentals-p1.xml">
<title>LPI certification 101 (release 2) exam prep, Part 1</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<author title="Editor">
<mail link="[EMAIL PROTECTED]">M Curtis Napier</mail>
</author>
<abstract>
In this tutorial, we'll introduce you to bash (the standard Linux shell), show
you how to take full advantage of standard Linux commands like ls, cp, and mv,
explain inodes and hard and symbolic links, and much more. By the end of this
tutorial, you'll have a solid grounding in Linux fundamentals and will even be
ready to begin learning some basic Linux system administration tasks.
</abstract>
<!-- 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 -->
<version>1.1</version>
<date>2005-07-03</date>
<chapter>
<title>Before You Start</title>
<section>
<title>About this tutorial</title>
<body>
<note>
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.
</note>
<p>
Welcome to "Linux fundamentals," the first of four tutorials designed to prepare
you for the Linux Professional Institute's 101 exam. In this tutorial, we'll
introduce you to bash (the standard Linux shell), show you how to take full
advantage of standard Linux commands like ls, cp, and mv, explain inodes and
hard and symbolic links, and much more. By the end of this tutorial, you'll have
a solid grounding in Linux fundamentals and will even be ready to begin learning
some basic Linux system administration tasks. By the end of this series of
tutorials (eight in all), you'll have the knowledge you need to become a Linux
Systems Administrator and will be ready to attain an LPIC Level 1 certification
from the Linux Professional Institute if you so choose.
</p>
<p>
This particular tutorial (Part 1) is ideal for those who are new to Linux, or
those who want to review or improve their understanding of fundamental Linux
concepts like copying and moving files, creating symbolic and hard links, and
using Linux' standard text-processing commands along with pipelines and
redirection. Along the way, we'll share plenty of hints, tips, and tricks to
keep the tutorial meaty and practical, even for those with a good amount of
previous Linux experience. For beginners, much of this material will be new, but
more experienced Linux users may find this tutorial to be a great way of
rounding out their fundamental Linux skills.
</p>
<p>
For those who have taken the release 1 version of this tutorial for reasons
other than LPI exam preparation, you probably don't need to take this one.
However, if you do plan to take the exams, you should strongly consider reading
this revised tutorial.
</p>
</body>
</section>
<section>
<title>About the author</title>
<body>
<p>
Residing in Albuquerque, New Mexico, Daniel Robbins is the Chief Architect of
Gentoo Linux an advanced ports-based Linux meta distribution. He also writes
articles, tutorials, and tips for the IBM developerWorks Linux zone and Intel
Developer Services and has also served as a contributing author for several
books, including Samba Unleashed and SuSE Linux Unleashed. Daniel enjoys
spending time with his wife, Mary, and his daughter, Hadassah. You can contact
Daniel at [EMAIL PROTECTED]
</p>
</body>
</section>
</chapter>
<chapter>
<title>Introducing bash</title>
<section>
<title>The shell</title>
<body>
<p>
If you've used a Linux system, you know that when you log in, you are greeted by
a prompt that looks something like this:
</p>
<pre caption="The prompt">
$
</pre>
<p>
The particular prompt that you see may look quite different. It may contain your
systems host name, the name of the current working directory, or both. But
regardless of what your prompt looks like, there's one thing that's certain. The
program that printed that prompt is called a "shell," and it's
very likely that your particular shell is a program called <c>bash</c>.
</p>
</body>
</section>
<section>
<title>Are you running bash?</title>
<body>
<p>
You can check to see if you're running <c>bash</c> by typing:
</p>
<pre caption="The SHELL variable">
$ <i>echo $SHELL</i>
/bin/bash
</pre>
<p>
If the above line gave you an error or didn't respond similarly to our example,
then you may be running a shell other than bash. In that case, most of this
tutorial should still apply, but it would be advantageous for you to switch to
<c>bash</c> for the sake of preparing for the 101 exam. <!-- (The next tutorial
in this series, on basic administration, covers changing your shell using the
<c>chsh</c> command.) -->
</p>
</body>
</section>
<section>
<title>About bash</title>
<body>
<p>
Bash, an acronym for "Bourne-again shell," is the default shell on
most Linux systems. The shell's job is to obey your commands so that you can
interact with your Linux system. When you're finished entering commands, you may
instruct the shell to exit or logout, at which point you'll be returned to a
login prompt.
</p>
<p>
By the way, you can also log out by pressing control-D at the bash prompt.
</p>
</body>
</section>
<section>
<title>Using "cd"</title>
<body>
<p>
As you've probably found, staring at your bash prompt isn't the most exciting
thing in the world. So, let's start using bash to navigate around our file
system. At the prompt, type the following (without the <c>$</c>):
</p>
<pre caption="Changing directories">
$ <i>cd /</i>
</pre>
<p>
We've just told bash that you want to work in /, also known as the root
directory; all the directories on the system form a tree, and / is considered
the top of this tree, or the root. cd sets the directory where you are currently
working, also known as the "current working directory."
</p>
</body>
</section>
<section>
<title>Paths</title>
<body>
<p>
To see bash's current working directory, you can type:
</p>
<pre caption="Present Working Directory">
$ <i>pwd</i>
/
</pre>
<p>
1.1
gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p1.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p1.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p1.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: making-the-distro-p1.xml
===================================================================
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p1.xml,v
1.1 2005/07/05 10:37:39 swift Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/making-the-distro-p1.xml">
<title>Making the distribution, Part 1</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<author title="Editor">
<mail link="[EMAIL PROTECTED]">Shyam Mani</mail>
</author>
<abstract>
Each of us has a story to tell about our experiences with Linux. This is
Daniel Robbins' Linux story. In this first of three articles, he talks about
how he became a Stampede Linux developer, and why he eventually left Stampede
to start his own distribution called Enoch.
</abstract>
<!-- 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 -->
<version>1.0</version>
<date>2005-06-14</date>
<chapter>
<title>Birth of the Gentoo Linux distribution</title>
<section>
<title>Linux and me</title>
<body>
<note>
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.
</note>
<p>
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.
</p>
<p>
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
fluency.
</p>
</body>
</section>
<section>
<title>Linux is about potential</title>
<body>
<p>
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
was fun.
</p>
<p>
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.
</p>
</body>
</section>
<section>
<title>Linux is about people</title>
<body>
<p>
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.
</p>
<p>
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.
</p>
</body>
</section>
<section>
<title>Getting involved</title>
<body>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</body>
</section>
<section>
<title>People can get ugly</title>
<body>
<p>
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!
</p>
<p>
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
1.1
gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p2.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p2.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p2.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: making-the-distro-p2.xml
===================================================================
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p2.xml,v
1.1 2005/07/05 10:37:39 swift Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/making-the-distro-p2.xml">
<title>Making the distribution, Part 2</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<author title="Editor">
<mail link="[EMAIL PROTECTED]">Shyam Mani</mail>
</author>
<abstract>
In his previous article, Daniel Robbins told the story of how he became a
Stampede Linux developer and why he eventually left Stampede to start the Enoch
Linux distribution. In this go-round he lets you in on the strange events that
happened after the Enoch development team discovered a little-known, blazingly
fast compiler.
</abstract>
<!-- 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 -->
<version>1.0</version>
<date>2005-06-14</date>
<chapter>
<title>From Enoch to Gentoo, via minor setbacks and corporate run-ins</title>
<section>
<title>First steps to Enoch</title>
<body>
<note>
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.
</note>
<p>
In my <uri link="/doc/en/articles/making-the-distro-p1.xml">previous
article</uri>, I
gave you the low-down on my days with the Stampede development team and why I
left (to get away from lower-level politically-minded, project-controlling
"freaks"). Because of the interference from these meddlesome by-standers, I
figured it would be easier to put together my own Linux distribution than to
continue improving Stampede under such dirty conditions! Fortunately I took with
me a considerable amount of experience based on my (may I say substantial?) work
for Stampede, including maintaining several of their packages, designing the
initialization scripts, and leading the slpv6 (next-generation package
management project).
</p>
<p>
The distribution I began working on, code-named Enoch, was going to be blazingly
fast because it would completely automate the package creation and upgrading
process. I have to admit that this was in large part because I was a one-member
team and couldn't afford to spend my time on repetitive work that my development
box could be automated to do for me. And since I was designing a complete
distribution from scratch (rather than "spinning off" from someone like RedHat),
I had my work cut out for me and needed all the free time I could scrounge up.
</p>
<p>
After getting my basic Enoch system up and running, I headed back to
irc.openprojects.net and started my own channel called #enoch. From there I
gradually assembled a team of about ten developers. In those early days we all
hung out on IRC and worked on the distribution in our spare time. As we
communally and cooperatively hacked away at it, finding and fixing new bugs,
Enoch became more functional and professional every day.
</p>
</body>
</section>
<section>
<title>The first roadblock</title>
<body>
<p>
One inevitable day, Enoch hit its first roadblock. After adding Xfree86, glib,
and gtk+, I decided to get xmms (an X11/gtk+-based MP3/CD player app) working. I
figured it was time to celebrate with some music! But after installing xmms, I
tried to start it... and X locked up! At first I thought xmms locked up because
I used insane compiler optimizations ("-O6 -mpentiumpro", in case you were
wondering). My first thought, to compile xmms with standard optimizations,
didn't solve the problem. So I started looking elsewhere. After spending a full
week of development time trying to track down the problem, I got an e-mail from
an Enoch user, Omegadan, who was also experiencing xmms lockups.
</p>
<p>
We corresponded for a while, and after many hours of testing we determined that
the problem was a POSIX threads-related issue. For some reason, a
pthread_mutex_trylock() call did not return the way it should. As the creator of
a distribution, these were the types of bugs I really didn't want to encounter.
I counted on the developers to release perfect sources so I could focus on
enhancing the Linux experience rather than getting buggy sources to work. Of
course I soon learned that this was an unrealistic expectation, and that
problems like will always pop up from time to time.
</p>
<p>
As it turned out, the problem wasn't with xmms, gtk+, or glib. And it wasn't an
issue with Xfree86 3.3.5 not being thread-safe and locking up. Surprisingly, we
found the bug in the Linux POSIX threads implementation itself, part of the GNU
C library (glibc) version 2.1.2. I was shocked at the time to find that such a
critical part of Linux had such a major bug. (And we used a release version of
glibc in Enoch, not a prerelease or CVS version!).
</p>
<p>
So how did we track down the problem? Actually, we never were able to come up
with a bug fix, but at one point I stumbled across a couple of e-mails on the
glibc developer mailing list from another person who had the same problem. The
glibc developer who replied posted a patch that solved the thread problem for
us. But I was curious why RedHat 6 (which also used glibc 2.1.2) didn't suffer
from this problem since the patch was just posted and RedHat 6 had been
available for some time. To find out, I downloaded RedHat's glibc SRPM (source
RPM) and took a look at their patches.
</p>
<p>
RedHat had their own homegrown glibc patch that solved the
pthread_mutex_trylock() issue. Apparently they experienced the same problem and
created their own custom fix. Too bad they didn't send this patch "upstream" to
the glibc developers so it could be shared with the rest of the world. But who
knows, maybe RedHat sent the patch upstream and for some reason the glibc
developers didn't accept it. Or maybe the thread bug was triggered by a specific
combination of compiler and binutils versions, and RedHat never ran into it
(although they did have a thread patch in their SRPM). I suppose we'll never
know exactly what happened. But I did learn that RedHat SRPMs contain a lot of
private bug fixes and tweaks that never seem to make it upstream to the original
developers. I'm going to rant about this for a little while.
</p>
</body>
</section>
<section>
<title>Rant</title>
<body>
<p>
When you put together a Linux distribution it's really important that any bug
fixes you create are sent upstream to the original developers. As I see it, this
is one of the many ways that distribution creators contribute to Linux. We're
the guys who actually get all these different programs working as a unified
whole. We should send our fixes upstream as we unify so that other users and
distributions can benefit from our discoveries. If you decide to keep bug fixes
to yourself, you're not helping anyone; you're just ensuring that a lot of
people will waste time fixing the same problem over and over again. This kind of
policy goes against the whole open source ethic and stunts the growth of Linux
development. Maybe I should say that it "bugs" us all.
</p>
<p>
It's unfortunate that some distributions (ahem) aren't as good (RedHat) as
others (Debian) about sharing their work with the community.
</p>
</body>
</section>
<section>
<title>Compiler drama</title>
<body>
<p>
During the time we were trying to fix the glibc threads problem, I e-mailed
Ulrich Drepper (one of the guys at Cygnus who is heavily involved with glibc
development). I mentioned the POSIX thread problem we were having, and that
Enoch was using pgcc for optimum performance. And he responded with something
like this (I'm paraphrasing here): "Our own compiler included with the
CodeFusion product has an excellent x86 backend that produces executables far
faster than those generated with pgcc." Obviously, I was very interested in
testing out this mystery "turbo" compiler the Cygnus guys had created.
</p>
<p>
I thereupon requested a demo copy of Cygnus Codefusion 1.0 so that I could test
it out, and Omegadan and I were amazed to find that this compiler was everything
that Ulrich claimed and then some. The x86 backend increased the performance of
some of the CPU-intensive executables (like bzip2) by close to 90%! All
applications seemed to benefit from at least a 10% real-world performance
increase, and all we did was swap out compilers. Enoch even booted 30 - 40%
faster. The performance gains were far, far greater than what we gained by
switching from gcc to pgcc. Obviously, after experiencing it for ourselves, we
wanted to use this compiler for Enoch. Fortunately, the sources were included on
the CodeFusion CD and were released under the GPL, so we were fully permitted to
use this compiler... or so we thought.
</p>
</body>
</section>
<section>
<title>Let the freakiness begin</title>
<body>
1.1
gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p3.xml
file :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p3.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p3.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
Index: making-the-distro-p3.xml
===================================================================
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header:
/var/cvsroot/gentoo-projects/www-redesign/htdocs/doc/en/articles/making-the-distro-p3.xml,v
1.1 2005/07/05 10:37:39 swift Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/en/articles/making-the-distro-p3.xml">
<title>Making the distribution, Part 3</title>
<author title="Author">
<mail link="[EMAIL PROTECTED]">Daniel Robbins</mail>
</author>
<author title="Editor">
<mail link="[EMAIL PROTECTED]">Shyam Mani</mail>
</author>
<abstract>
This article concludes his story -- about how he ended up creating his own
distribution called Gentoo Linux. He wraps up the series by telling how he
left the Linux world to move to FreeBSD, and then came back to the Linux world,
restarting Gentoo Linux development with a fresh perspective. In addition to
comparing Linux and FreeBSD in a number of areas, he also describe current
Gentoo Linux development progress and share a future vision for the
distribution.
</abstract>
<!-- 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 -->
<version>1.0</version>
<date>2005-06-14</date>
<chapter>
<title>The author strays from Linux and then returns</title>
<section>
<body>
<p>
At the end of my <uri link ="/doc/en/articles/making-the-distro-p2.xml">previous
article</uri>, I described how Gentoo Linux development had effectively been
brought to a halt by a strange idle-lockup bug that I began experiencing as soon
as I upgraded to a new dual-Celeron motherboard (an Abit BP6). Because I was
unable to fix the problem, and at the time didn't have the funds to replace my
motherboard, I decided to halt Gentoo Linux development and switch over to
FreeBSD. I needed a working system, and since Linux was locking up all the time,
this would be an excellent time to get familiar with a BSD operating system. So
I installed FreeBSD, started learning, and didn't touch Linux at all for several
months.
</p>
</body>
</section>
<section>
<title>FreeBSD impressions</title>
<body>
<p>
All in all, I really liked FreeBSD. I felt that the operating system was well
put together and that nearly every part of the system had a consistently
high-level of refinement that's almost never found in the Linux world. I enjoyed
the fact that FreeBSD contained a full complement of man pages, unlike Linux
where many programs only have GNU info documentation, which I don't particularly
like using.
</p>
<p>
Most of all, I was impressed with FreeBSD's ports system, the technology used to
maintain and upgrade the system. Unlike the Linux approach, ports didn't use
binary packages but instead automatically compiled everything locally from their
original sources. Whether you were installing Samba or upgrading the core
system, everything was compiled right on your local machine. This approach
appealed to me and was very similar to the one I had been creating under Gentoo
Linux. In this and many other ways, FreeBSD's design agreed with my
sensibilities as a developer and a system administrator. For this reason,
FreeBSD provided a comfortable work environment for many months, and I'm glad I
took the time to get familiar with this excellent operating system.
</p>
</body>
</section>
<section>
<title>FreeBSD pros</title>
<body>
<p>
A lot of the differences between Linux and FreeBSD come from their different
development structures. Linux development is very decentralized, and we rely on
distributions to pull in and unite the various pieces of Linux scattered
throughout the Internet. Compare this to FreeBSD and the other BSDs (OpenBSD and
NetBSD), where there's a unified development team plugging away at a single,
unified set of sources. Well, at least each BSD has its own set of unified
sources. This can be a good thing, and results in FreeBSD not having a "patched
together" feel like many Linux distributions do.
</p>
<p>
Next, we can compare the technology under the hood. Many a FreeBSD fan will
assert that FreeBSD is better suited to being a server than Linux is. They'll
tell you that FreeBSD is better under high loads, and has a better TCP/IP stack.
If you're comparing Linux 2.2 or earlier with FreeBSD, I'd have to agree.
FreeBSD is a great server OS, that's for sure. But, that's just Linux 2.2 and
earlier. I happen to be a big fan of the 2.4 test kernels that I've been
running. They're really, really great and contain a nice TCP/IP stack and a
totally redesigned "netfilter" system that really rocks. In the end, I think
that Linux will be the one to set new performance standards and make free UNIX
servers even more competitive versus their commercial counterparts.
</p>
</body>
</section>
<section>
<title>FreeBSD cons</title>
<body>
<p>
As for the desktop, rather than the server world, there's really no comparison
-- Linux is where the action is. All the latest desktop developments appear on
Linux first, and Linux is ahead in its support of accelerated 3D graphics and
sound cards. With Linux 2.4 approaching, Linux will continue its dominance in
this area.
</p>
<p>
The one thing I don't like about FreeBSD is its use of the UFS filesystem. While
UFS is more reliable and rugged than ext2, it's also mind-numbingly slow. It's
possible to use a special UFS extension called soft updates, which is able to
speed up the filesystem by aggregating IO operations into bigger chunks. While
soft updates improves UFS tremendously, I can't say that UFS really outperforms
ext2 in any way. Of course, it's more reliable, so FreeBSD ends up beating Linux
in the filesystem war. Again, at least this is true when comparing older Linux
2.2 distributions to FreeBSD.
</p>
<p>
However, the tables turn when we start to compare modern Linux 2.2 and Linux 2.4
to FreeBSD. ReiserFS (a new journalling filesystem available for Linux) is just
amazing. Linux also has ext3, IBM's JFS, and XFS to look forward to, from which
we expect excellent performance and reliability as well. As of now, ReiserFS
gives Linux a major speed advantage over FreeBSD, and is one of the reasons I
believe that Linux 2.4 overturns many of the old arguments of FreeBSD's
superiority over Linux.
</p>
</body>
</section>
<section>
<title>Back to Gentoo Linux development</title>
<body>
<p>
After a few months, I decided to rejoin the Linux world and get Gentoo Linux
running on a new development box. At first, the decision to restart Gentoo Linux
development was more of a business decision -- I had invested a lot of my time
in becoming Linux-knowledgeable, and it would be a waste to throw all this
knowledge away by sticking with BSD. However, shortly after I began updating
Gentoo Linux, I found several new reasons why Linux was worth switching back to,
namely all the filesystem and kernel improvements mentioned above. FreeBSD was a
peaceful home, but a little too boring, too staid. Linux is where the action
was, where major progress was being made. There's no doubt that if you're
looking for excitement and innovation, Linux is the place to be.
</p>
<p>
To me, the Linux 2.2 era was a disappointing letdown from the 2.0 era, but the
2.4 era promised to be worth the wait. So, Gentoo Linux was reborn, and I was
excited.
</p>
<p>
There was another key to Gentoo Linux's rebirth -- Achim Gottinger, my
development team lead. I want to take some space to thank Achim for helping me
restart Gentoo Linux development. I started getting e-mails from Achim shortly
before my return to the Linux world. In almost every e-mail, he'd include some
new .ebuild (autobuild) scripts for Gentoo Linux, or some desperately needed
bugfixes. As I restarted Gentoo Linux development, Achim continued to contribute
his time and resources to help get the distribution back on its feet. Up until
recently, Achim and I have been the only two people working on Gentoo Linux, and
this has been by choice. Because we both have a similar vision for the
distribution, and because of Achim's skill, we were able to get a tremendous
amount of work done and I never really felt that adding a third developer would
significantly help our progress. Now, Achim serves as the Gentoo Linux
development lead, and continues to make major improvements to Gentoo Linux on an
almost daily basis. We've reached the point where we're ready for others to
start working on our CVS tree, and have begun to gradually and carefully expand
the Gentoo Linux development team.
</p>
</body>
</section>
<section>
<title>The new vision</title>
<body>
<p>
I don't feel that the time I spent in the BSD world was in any way wasted. In
fact, it gave me a tremendous opportunity to reflect on the happenings in the
entire Linux community and how Gentoo Linux could help to improve things.
</p>
--
[email protected] mailing list
