帖子: 547
注册时间: 2007-06-02 14:56
送出感谢: 0
接收感谢: 0



帖子 ofewiofewo » 2007-08-26 22:26 ... tro-p1.xml


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 fluency.

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 was fun.

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 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.

Getting involved

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 effort.

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 process endlessly.

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.

Starting afresh

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, right?

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.
上次由 ofewiofewo 在 2007-08-27 14:50,总共编辑 1 次。
帖子: 547
注册时间: 2007-06-02 14:56
送出感谢: 0
接收感谢: 0


帖子 ofewiofewo » 2007-08-26 22:32 ... tro-p2.xml


Making the distribution, Part 2

From Enoch to Gentoo, via minor setbacks and corporate run-ins

First steps to Enoch

In my previous article, 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).

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.

After getting my basic Enoch system up and running, I headed back to 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.

The first roadblock

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.

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.

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!).

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.

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.


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.

It's unfortunate that some distributions (ahem) aren't as good (RedHat) as others (Debian) about sharing their work with the community.

Compiler drama

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.

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.

Let the freakiness begin

I sent an e-mail to the marketing manager at Cygnus to let them know our intentions, expecting a "yeah, go for it, thanks for using our compiler" response. Instead the reply was that although we were (technically) allowed to use the Cygnus compiler, we were strongly urged not to use or include the compiler sources with Enoch. I responded by asking why they had released the source under the GPL, if that was the case. It's my guess that if they had a choice, they wouldn't have used the GPL, but because they derived their compiler from egcs (released under the GPL), they had no choice.

This is a good example of a situation where the GPL prevented a company from creating a proprietary product based on open sources. My educated guess is that Cygnus was afraid that if we used their compiler we would undermine their boxed product sales, which would be especially strange because none of their marketing materials (nor the InfoWorld review) mentioned the new compiler included with CodeFusion. CodeFusion was marketed solely as a "development IDE" product, not as a compiler.

In an attempt to put some of their paranoia to rest, I offered to endorse CodeFusion and place the endorsement on our Web site with a link to help spur CodeFusion sales. Personally I didn't think that a "turbo" Enoch would negatively affect their sales, since CodeFusion was marketed as an IDE. But I tried nevertheless to make them happy. The IDE component of CodeFusion was a commercial product, and we had no desire or intention (or right) to distribute it with Enoch.

I e-mailed my (generous?) offer to Cygnus and received another strange response. They wanted authority over all of our "marketing materials" (apparently, this also included the content of our Web site!) Another shocker. The Cygnus marketing team seemed to have no grasp of how the Linux community or the GPL worked, so I decided to cut off communication with Cygnus for the indefinite future. In the mean time, we created a private "turbo" and public "non-turbo" version of Enoch, leaving the final decision for later.

But after several months they integrated the CodeFusion x86 backend into gcc 2.95.2. Now everyone could benefit from the nice new backend, not just the people who knew about the "secret GPL compiler" included on the CodeFusion CD. But we decided to go ahead and use gcc rather than the CodeFusion compiler. In addition to being more stable, gcc 2.95.2 also allowed us avoid Cygnus, which by this time had been purchased by RedHat for a ridiculous sum of money. (Note: the new x86 backend in gcc 2.95.2 is what gave newer Linux distributions the significant speed boost that we all got to experience. It also gave FreeBSD 4.0 a nice speed boost over 3.3.6. Notice the difference?)

On the soapbox

Thanks to this and other experiences, I've learned a lot about for-profit open source companies. There's absolutely nothing bad about being a for-profit open source company. Nor is there anything morally wrong with producing proprietary closed-source software, if that's what you'd like to do. But it doesn't make any sense for open source companies to subvert or refuse to cooperate with the rest of the open source world, either by not supporting the GPL or by any other means. This is a practical point that clearly makes business sense.

Open source companies should realize that the free exchange of ideas and code is what they profit from. By opposing things like the standard GPL practices, they undermine the environment they rely upon to prosper and grow. If open source is the soil from which your business has sprouted, it makes sense to keep the soil healthy.

I understand that there's a temptation to keep at least some information secret for short-term financial gain. Advanced code or special techniques provide a coveted competitive advantage, which could potentially result in increased sales and profit. But if the goal is to be the sole provider of a product, the product should be commercial rather than open source. Open source does not allow for exclusive access to the inner workings of anything. That's what it means.

Back to Enoch

Now, I'll step down from my soapbox and continue my story.

As Enoch became more and more refined, we decided that a name change was in order, and "Gentoo Linux" was born. By this time we had released a couple of versions of Enoch (now Gentoo), and were racing to get to Gentoo Linux version 1.0. Around this time I also decided to upgrade my old Celeron 300 box (overclocked and rock-solid at 450Mhz) to a brand-new Abit BP6 (a dual Celeron board that had just hit the market). I sold my old box and put my dual Celeron 366 system together. After overclocking the processors to something on the order of 500Mhz, I was cruising. But I noticed that my new machine wasn't very stable.

Obviously my first reaction was to go back down to 2x366Mhz. But now I experienced an even stranger problem. As long as my machine kept the CPUs chugging away, the machine didn't lock up. But if I left the machine idle overnight, there was a good probability that the system would lock up completely. Yes, an idle bug -- argh! After some research, I found several other Linux users with the same problem on this particular motherboard. A chip on the BP6 (was it the PCI controller?) seemed to be flaky or out of spec, which caused Linux to lock up at idle.

I was more than a wee bit upset, and because I couldn't afford to order more PC parts, Gentoo development effectively halted. I became more and more pessimistic about Linux and decided to switch over to FreeBSD. Yes, FreeBSD. And that's where I'll end this installment -- see you in Part 3. :)
上次由 ofewiofewo 在 2007-08-27 14:51,总共编辑 1 次。
帖子: 547
注册时间: 2007-06-02 14:56
送出感谢: 0
接收感谢: 0


帖子 ofewiofewo » 2007-08-26 22:38 ... tro-p3.xml


Making the distribution, Part 3

The author strays from Linux and then returns

At the end of my previous article, 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.

FreeBSD impressions

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.

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.

FreeBSD pros

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.

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.

FreeBSD cons

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.

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.

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.

Back to Gentoo Linux development

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.

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.

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.

The new vision

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.

In the new version of Gentoo Linux, I made the decision to not use pgcc anymore, nor use very high optimizations to compile all binaries. Since stability was paramount, we would use reasonable ("-O2 -mpentium") optimizations but provide an easy way for users to customize these optimizations to their liking by using our autobuild system.

FreeBSD gave me a really good idea of how an autobuild system should function. I decided to add several FreeBSD features to make our autobuild system (now called Portage) a true next-generation ports system.

Portage is the heart of Gentoo Linux, and is more than a simple package management or maintenance system. Consisting of a set of build tools and build scripts, Portage allows you to rebuild the entire distribution from original sources. But more importantly to me, Portage gives the user full access to the intelligence of how Gentoo Linux was built. To us, this is very important because it means that we are documenting how to build a distribution while at the same time moving Gentoo Linux development forward. And, because Portage is easy to use and understand, we hope that it will open up Linux internals to even more people, so that others can begin to contribute to our sources and scripts.

Portage is our way of opening up Linux technology to others. By studying the autobuild scripts, you can see how all the various packages fit together into a unified whole. If necessary, you can grab our entire CVS tree and hack away at it, producing your own custom distribution or Linux-based technology. We believe that this is a good thing -- we want to give people the knowledge they need to take Linux into new realms.

Commercial concerns

Since its inception, there have been many people of various backgrounds involved with Gentoo Linux development. And I wasn't surprised to find that our developers had wildly different opinions of how we should approach the money-making end of Gentoo Linux. Basically, there were two groups of developers: one group was generally opposed to money-making pursuits, while the other group was excited about helping Gentoo Linux become a successful commercial product. This was an expected split; the first group saw commercial involvement as a corrupting influence, while the second saw no such negative associations.

In the Enoch days, I used to waver on this issue and didn't really know the right approach. I recognized the fact that distributions like Debian were truly committed to free distribution of their software. I liked that. Compared to other commercial distributions, they made things easy for the user by providing detailed instructions on their Web site. That was a good thing, and something I wanted to emulate.

At the same time, I really wanted Gentoo Linux to be commercially successful. I struggled to find a balance, but never really found one until recently.

What to do?

So, how are we planning to balance commercial and non-commercial interests? The key is to remember our foundation -- the foundation of Gentoo Linux is Open Source software. Thus, the foundation for all our endeavors must focus on Open Source. It's not good enough to just acknowledge Open Source software, or just to use it. We must also encourage its development and distribution, and never oppose this stance for commercial gain. More importantly, we must never structure our business model so that there's a temptation to restrict the free distribution of our sources. Our development team needs to be open and accessible to the public, and free distribution of Gentoo Linux must not only be allowed, but encouraged. We need to be Open Source advocates, not just in word, but in action also.

If a company wants to use Gentoo Linux for a commercial Linux-based technology, they can just grab the contents of our CVS tree and start using it, since all our work is distributed under the GPL. We don't want to limit the use of our work in any way, except to ensure that all derivative products comply with the GNU Public License.

We'd like as many people as possible to benefit from our work, but we'd also like to benefit as much as possible from your improvements to Gentoo Linux. If you're part of a company using Gentoo Linux as a base for your product, we hope that you'll send any freely-distributable improvements to us so that we can add them to our CVS tree. That way, everyone benefits. We can continue to maintain and improve your additions, and you in turn can benefit from these improvements. We want to foster collaboration between commercial and non-commercial entities. This way, both the sysadmin using Gentoo Linux at his ISP and the corporation building a commercial server product can benefit from each other's improvements and fixes to Gentoo Linux. It's time to promote the free exchange of code between everyone. Only Open Source makes it possible.

What does the future hold?

Right now, we're at the verge of releasing Gentoo Linux 1.0 (it may be available by the time you read this article on developerWorks.) But what does the future hold?

As we move towards 2.0, I hope to continue to improve Portage, the technology at the heart of Gentoo Linux. Any major improvement to Gentoo Linux generally starts with an improvement to Portage. I'd like to continue the process of converting the majority of the code from bash to python, which will allow us to add new features like object-oriented design to our autobuild system.

In addition to changes to Portage, I hope to continue to slowly and carefully grow our development team by finding skilled developers who share our same vision. As our development team grows, we will be able to vastly expand the number of autobuild scripts available for Gentoo Linux. But even more important than this, a slightly larger development team will give us the resources we need to continue to keep Gentoo Linux on the cutting edge of Linux technology. That's where the fun is :)

We also hope that commercial Linux technology companies will choose Gentoo Linux as a base for their products. We currently have one such relationship and we hope to have many more in the future. These kinds of collaborations promise to be lots of fun and to be a great benefit to all Gentoo Linux users.

In the end, our primary goal is to contribute something meaningful to the Linux community. Although there are many Linux distributions to choose from, we know that Gentoo Linux offers something that really isn't available anywhere else. We're excited about the future of Gentoo Linux development, and we hope you are too.


上次由 ofewiofewo 在 2007-08-27 14:53,总共编辑 1 次。
帖子: 335
注册时间: 2005-06-12 12:23
送出感谢: 0
接收感谢: 0


帖子 nifi » 2007-08-27 13:39

快乐工作 快乐学习
帖子: 2376
注册时间: 2006-09-21 14:28
送出感谢: 0
接收感谢: 0


帖子 flyinflash » 2007-08-27 15:02


帖子: 547
注册时间: 2007-06-02 14:56
送出感谢: 0
接收感谢: 0


帖子 ofewiofewo » 2007-08-27 15:09

帖子: 510
注册时间: 2005-09-01 20:48
送出感谢: 0
接收感谢: 0


帖子 paul » 2007-08-30 6:25

帖子: 510
注册时间: 2005-09-01 20:48
送出感谢: 0
接收感谢: 0


帖子 paul » 2007-08-30 6:47

帖子: 547
注册时间: 2007-06-02 14:56
送出感谢: 0
接收感谢: 0


帖子 ofewiofewo » 2007-08-30 8:27

帖子: 510
注册时间: 2005-09-01 20:48
送出感谢: 0
接收感谢: 0


帖子 paul » 2007-09-03 8:29

同意,我真没觉得G和U不是一家。Linuxer本一家,不是么?话说回来了,我还是很佩服Gentoor们的。我自己虽然选择了Linux,不过本质上懒人一个,不愿意花太多时间在操作系统本身上,要是资金不成问题的话,可能已经转投MacOs了,很多时候真的只是想有台电脑just works.
帖子: 1928
注册时间: 2005-10-04 10:59
来自: 上海
送出感谢: 0
接收感谢: 1 次


帖子 roylez » 2007-11-29 22:40


native speaker写的就是读起来舒服。
帖子: 1026
注册时间: 2007-04-28 21:38
送出感谢: 0
接收感谢: 0


帖子 aitilang » 2007-11-29 22:52

ofewiofewo 写了:其实G和U并不矛盾,论坛上不少精华贴和普及软件是资深gentoor的劳动成果。
thinkpad x61 2G DDR no cdrom
帖子: 990
注册时间: 2006-07-15 11:20
来自: 枫叶刀市
送出感谢: 2 次
接收感谢: 0


帖子 Nile » 2007-11-29 23:10

aitilang 写了:
ofewiofewo 写了:其实G和U并不矛盾,论坛上不少精华贴和普及软件是资深gentoor的劳动成果。

Thinkpad T400
帖子: 510
注册时间: 2005-09-01 20:48
送出感谢: 0
接收感谢: 0


帖子 paul » 2007-12-01 1:30

阴差阳错,装上了gentoo.本来打算装arch,结果老是莫名其妙的死机,然后就打算试试gentoo了。装上了一个礼拜,由于内存条不兼容的问题才貌似搞定,学了不少东西,目前为止很喜欢 :)

回到 “其它类Unix OS发行版”