[Linux] Gentoo的前世今生

原文链接：Making the Distribution
原作者： Daniel Robbins
译者：    Linky_fan

这篇文章的作者是Daniel Robbins，作为Gentoo公司的CEO和创始人，Robbins的经历充满争
议，这包括他见证了开源软件发展的历史，他也曾经供职于Microsoft，甚至由于对游戏的
挚爱而但当SONY的首席图形设计师。

此文的英文原文完成于2001年11月，文章详尽的叙述他在Gentoo的出世和成长历程中经历过
的种种磨难和变迁，字里行间带有对软件自由理念的热爱和狂热追求，绝对是一篇针对自由
软件开发者的传颂于世的精神宝典。

－－－－－－－－－－

Making the distribution, Part 1

我和Linux

现今对每一个linux爱好者来说，linux不再只是一个字面上的名称，她所呈现的一切对很多
开发人员来说已经超过了他们所接触过的任何东西， linux比它们更强大、更令人着迷和称
赞。当我在新墨西哥大学担任系统管理员时便与linux结下了不解之缘。那时因为我们的NT
服务器运行得非常棒，我的手头上也有了很多空余的时间可以加以利用，就这样第一个
linux操作系统被我安装到了一台Pentium 166的主机上，接下来的不断学习和深入理解的过
程使我对linux越来越着迷了......

一开始学习了linux下的很多细节的东西：网络访问、执行备份、搞定samba等等。接着我建
了一个qmail和apache的服务器并学习了 python编程和shell编程。我还搭建了一个小型局
域网接着把linux请回了家，在尝试过很多发行版后我最终选择了Stampede Linux这个版本
（注：该版本从2001起就没有再更新了）详细的消息可以看一下
http://distrowatch.com/table.php?distribution=stampede
你知道学习linux的过程是怎么样的吗？：第一、努力搞清楚linux基本的东西；第二、当你
已经有了相当好的掌握程度之后，学习定制你的linux，知识的累积会和你深入的程度成正
比。由于linux并没有隐藏任何东西，当linux对你来说变得越来越得心应手之后就可以开始
探究技术和那些实现这些技术的工具了。

Linux的潜能

Linux提供了很多以前我所没有见到过的东西，如果一定要我用一个词来形容这些不可思议
的话，我选择“潜能”这个单词：用来维护、改变、提高事物的能力，这种能力甚至能够冲
破一些固有规则的约束。 当我把kernel升级到一个更新的版本时，简简单单的就把我眼前
的这个linux的性能提升了很多，更为令人兴奋的是这种改变几乎每时每刻都在进行着。而
我也正是这种进步的一份子，伴随着linux的前进而不断进步着， 对我而言这种感觉真的很
棒。

如果你和我是同一类人，在你进入开源世界和linux世界之前大概看过位于Redmond和
Cupertino的那些大公司们准备的下一代操作系统，它们确实如你所愿般的完美，然而那些
东西却始终都只是一个虚幻的影子而已。然后就在我们慢慢等待的过程中linux来到了我们
面前。虽然等来的这个精灵并不如我们预料的那么完美，但是她却提供给了我们这些喜欢动
手hack的男孩和女孩一个亲手改变她的机会。就这样我们一边期待着一个更强大的操作系统，
一边津津有味的hack我们的linux。日子一天一天过去，直到某天我们才突然发现原来期待
着的那个强大的操作系统其实就在我们自己的手中，大家不约而同的笑了起来，也决定了继
续在linux这条路上走下去。

Linux的人文艺术

我学到的另一件事就是Linux对人们的影响，这个话题可能听上去还真有点新鲜，是吧？
Linux不仅仅只是一堆源代码的，它其实就是一个“社区”，从一开始的依赖这个社区解决
我们提出的问题到付出我们的时间和经验帮助他人，渐渐的我们也成为了这个社区的一部分。

IRC (Internet relay chat)既是一个交朋友的好地方也是一个很打发时间的场所。
irc.openprojects.net上的 #stampede频道已经成为了我在网络上正式的安乐窝^-^。那是
我解答自己疑问的地方，也是第一次回答朋友问题的地方。#stampede频道需要很多有安装
经验的用户去帮助那些新手解决他们刚刚开始安装后碰到的各种各样的问题。由于那些新手
在安装过程遇到的问题在irc中越来越普遍，原来很多有经验的Stampede Linux用户渐渐失
去了他们一开始的热情。但是我依然还是很兴奋，因为很多菜鸟的问题我都知道解决的办法，
要我忍着不回答那些问题我可做不到！当然我也并不是唯一的那个对解决新手问题乐此不彼
的人，同样的家伙也有不少。我也承认自己也有那么点私心，想从那些更有经验的家伙们
（不是指Stampede的开发人员）身上学到更多的东西。

如何起步

当有朋友问我如何才能加入一个开源项目时，我告诉他们的是首先是找一个能为他人做些什
么的地方，就算那里只是解答一些很基础的问题。一份诚挚的渴望帮助他人的愿望是通往
Linux社区的通行证，因为这份诚挚的愿望同样也扎根在每一个开源项目开发人员的心中
（不仅仅只是Linux项目），也应该扎根在那里。

沿着这条路走下去不可避免的你会遇到比你更有经验的同志，你将会从他们身上学到更多的
知识，就像以前新手从你身上学习时一样。另一方面，当你积累起更多的经验时在碰到某些
问题时你就会用一个新方法去解决它而不是用以前惯用的一套思路。你遇到的一些开发人员
有时会提出一些建议，有时又或者会需要一些帮助，他们更可能会邀请你加入他们的开发队
伍；如果你的助人为乐成为焦点时，他们可能会笑着从你身边经过；如果你帮助了很多很多
人之后，你在社区内肯定会备受瞩目。在Stampede和我身上这些故事都曾经发生过。

渐渐的我在Stampede的开发越来越深入，不久以后我就成为了一个正是的Stampede开发人员。
在受到了Stampede的领导者 Matt Wood的鼓励后，我开始对用于Stampede Linux软件包的原
有的.slp机制进行升级。当时，.slp软件包格式包含一个.tar.bz2的软件包和后面的一个包
含软件描述及软件包创作者等等在内的一个定长的页脚。这种实现的方式有两个主要问题：
页脚部分实际上包含的内容根本达不到定长所约定的字节数；该格式没有预留任何扩充余地
（也就是说如果未来没有办法加入一些可能需要的额外信息）。显然这些问题需要动一次大
手术了，活活。

和那些老资格的Stampede开发人员工作一段时间后，我拟了一个解决上面那些问题的草案。
过了一阵子我便开始用Python先编写了一些原始的实现方案，新的格式(代号slpv6）有些类
似与Amiga世界的IFF格式。下一代的.slp格式包含了了2 32（注1）个字段，字段种类为2
32种，每个字段最大数据段同样为2 32bytes。新的格式不仅具有良好的扩充性而且比纯文
本更加紧凑和简洁并易于解析。二进制代码和文本都能存储在这样的格式当中，该架构对其
本身在未来的进一步发展带来了无限的可能性。我的想法是把这个新版的动态header加入道
打包文件的结尾部分，从而这个新版本的.slp格式未来可以为 Stempede用户服务相当一段
时间并且同时又能和标准的UNIX档案文件保持不错的兼容性。

丑陋的一面

slpv6的开发进展很顺利，所有的资深开发者看到我取得的成果后都很高兴。不幸的是，两
名刚加入的Stampede开发者想要自己掌控slpv6项目。由于不欣赏我选择的开发方向，他们
花了很大劲诋毁和打击这个新的slpv6系统，虽然我也用了大量时间一边继续我的开发一边
加入讨论一边回应他们的攻击，但是这样做也没从根本上解决问题。最后一切都变的很明了，
他们只是很擅长辩论，并且显而易见的是除非走他们自己的路子，不然是不会罢休的。幸运
的是我的项目依然得到了资深开发人员的认可和支持。可是这些讨论渐渐地使我背上了一些
包袱，同时对Stampede的开发也产生了一些不好地影响。唉。。。。。。。

可惜我没办法使这些家伙消失，原来还可以在＃stampede频道里和那些高级的开发者互相交
谈，但是现在不得不退了出来。每次只要我一进入那个频道，他们就开始变得很不友好，总
是在破坏我想要进行得工作。这些家伙会使用各种各样的方法：比如一个开发者会议（其实
只是想当着其他资深开发者的面侮辱我）。他们还尝试用投票的方法控制Stempede，当然那
种投票只在他们可以得到更多支持的时候才会举行。但是自始至终我在这样的情况下都没有
放弃过我得 slpv6的开发工作。不用多说，资深开发者都喜欢我的开发项目也都支持我继续
做下去（没有他们的支持，我不可能克服那么多困难坚持下去）。 

对这些异类的了解

我习惯于把这两个家伙和这种类型的开发者称为“异类”。虽然我的开发工作因此变得很很
不愉快，但是我还是学会了怎么样去对付他们。就这点我乐于给各位提供一个对这些“异类”
的全方面的描绘：他们的品质、采用的方法以及当你作为一个项目领导者怎么样才能对抗这
些”异类“或是尽可能的用最小的代价去改变他们。

为了消除情绪上可能存在的危险，你需要具备一个先决条件：意志力。如果你不能用一种既
礼貌又态度坚决的方式回应你的对手，事情就会变得很糟糕。“异类”的目的就是尽可能多
的在你的项目中取得控制权，这么做会使他或她感觉更具有力量。首先，他们会对某个项目
或是项目的开发人员进行片面的指责和抱怨，同时他们也会阻止那些对这个项目富有建设性
的提议。当然这些家伙在他们获得项目管理人员位置之前也不会对这个项目伸出任何的援手。
目的就是使你确信只有依靠他们的那些“独道的、富有素养”的眼光才能最终解决问题，这
样你就不得不给他们足够的权限去实现这些。

如果指责和抱怨没起什么作用，这些“异类”就会要求举行一个开发者会议。这将会给他们
一个可以分裂你开发团队的机会。在觉得本方这方面已经得到了大多数人的支持后，他们就
会举行一次投票决定（当然他们知道赢的会是他们的情况下）。如果并没有赢得投票或是投
票被驳回，那么下周他们还是会提出举行一次会议以便再一次的分裂你的团队，然后再是那
种无休止的循环。

如果会议的方法行不通，“异类”们将会变成革新运动者。他们会用一种更民主（也就是更
容易操纵）的办法来取代先前压迫性的和非公平的决策方案。这些办法常常包括令人信服的
让你去为你的开发团队中的大部分人做任何事。异类比较偏爱这个办法，因为你没有办法弃
大多数投票表决的结果于不顾（活活活）。你许可这些事情发生的时候就已经把那把通往你
的”Lexus“的”钥匙“交到了他们的手里，这将使你失去能力。

”异类“们用的另一种方法是激怒你的主要开发人员并使他们离开，然后在你的开发团队混
乱的时候尝试重新组织该项目的管理团队。如果所有的努力都没有成功的话，他们会聚集尽
可能多的叛离者并把他们安插在你的项目中，痛啊！

对付这些异类

区分这些家伙还是相当容易的。他们不会写一行代码（也不愿意写），相反他们会花大量的
时间讨论那些更重要的问题（对了，就是那些管理方面的问题）。假设你是一个项目管理者，
对付他们非常容易。只需要告诉他们，在没有看到高质量的代码之前你是不会考虑他们所谓
的建议的。或者在他们提出”建设性“的批评之前强调对于某个项目有建设性得帮助也包括
服从项目的管理人员。如果他们开始编制优质的代码并且越来越有易于这个项目，那么就太
好了。如果没有，就告诫他们离开。在你忽略这帮家伙一段时间后，他们会选择离开或是一
边采取行动一边写一些代码，世界就这样清净了^_^。

不幸的是Stampede的那些资深开发人员对”异类“并没有采取更多的管理措施。换句话说，
他们许可了这两个家伙对我（和其他人）的无休止的纠缠。虽然这些资深开发者总是赞赏我
的项目，但是对那两个家伙他们却并没有做的更多。然后终于有一天我决定制作一个自己的
发行版，因为我觉得这样做比忍受那两个家伙更容易些。我退出了Stampede的开发团队并开
始制定自己发行版的一些计划和草案。

一段时间之内，我对自己因为两个低等级开发者而离开一个项目还是感到有些不可思议。其
实他们没有涉及到的实际情况却真正显示出这个项目存在很严重的管理方面的问题，如果高
等级的开发人员不能或者不愿意确认Stampede的开发成果是可喜的和有益的话，我想我不会
愿意继续留在那里。


新的开始

离开Stampede后我做的第一件事就是长长的舒了口气。喔……，整个世界都清净了。现在我
有了足够的时间来思考我自己的Linux发行版的轮廓和将给 Linux发行版的布局带来什么新
的贡献。对Stampede感兴趣的一件事是它所具有的原生的性能（这得感谢它使用的带有实验
性质的、并针对 Pentium处理器优化过的pgcc编译器），所以我决定首先我考虑的就是性能。
除了更少的CPU占用率以外，我还希望它更精简。很多发行版本（特别是那些流行的热缩塑
料封装的家伙）默认启动了太多的daemons以至于打开一个xterm（X环境下的终端）后系统
所剩余的可用RAM已经所剩无几了。我希望自己的发行版能更小也更强，为此我把目光放到
了最大限度的榨取让这个操作系统运行的硬件平台的性能上。为此我下决心进行一个整体测
试并处理掉所有细节中的性能方面的问题。

但是我真的很缺乏对应的资源，因为我是这个发行版的唯一的一个开发人员！我该怎样做才
能只靠自己就鼓捣出不逊色于Redhat或是Caldera这样的产品呢？解决办法是采用自动控制
技术。我必须写一些脚本以便所有的事情都可以自动搞定，这样我就可以事半功倍了。毕竟，
电脑们这些方面做得更好，对吧？

很快我发现光是写一些自动化的脚本还远远不够，需要设计的是一整套能从源代码产生一个
完整Linux系统的机制。我实验性的把它称做ebuild系统并且开始了工作。ebuild系统可以
自动的建立所有一个发行版所需要的二进制文件，包括从解压源代码并打好相应的patch再
到编译、封包的一系列过程的自动化解决方案。在一个基本、原始的ebuild可以工作后，我
开始为一个Linux发行版必要的一些关键组成部分（像是gcc、glibc、 binutils、
util-linux和friends）撰写ebuild脚本。通过重新撰写初始化脚本（基于以前我为
Stampede设计的初始化脚本）把原先的Stampede开发系统逐渐的演变成一个我自己的系统，
接着用来测试每一个我自己建立好的新的软件包。

几个月之后我有了一个完整的，自主的Linux版本。我给她起了个名字『Enoch』然后坐着满
足得笑了起来。但是什么改变了Enoch、Gentoo的发展又是怎么样的？续篇将会告诉大家
Enoch是怎么演变成Gentoo的和我在这条路上将要面对的许多新的挑战。

敬请期待^_^


Making the distribution, Part 2

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

Enoch踏出的第一步

我在先前的文章中告诉了大家那段和Stampede开发团队在一起的、曾经最兴旺的时光和最后
为什么离开的原因（就是想离那些有低级政治目的的、想控制项目的那帮家伙远点）。因为
这些爱管闲事的好事者的干涉，我才会觉得装配一个自己的Linux发行版比在那种恶劣条件
下改进Stampede要简单的多。幸运的是，我离开Stampede时是带着满满当当的经验离开的，
这些经验与在Stampede的工作（应该是实质性的吧？）是分不开的，维护一些软件包也好、
设计初始化脚本也好或是领导slpv6（下一代软件包管理系统）都使我相关方面的知识和经
验得到了极大的丰富。

Enoch是我开始工作的这个版本的一个代号，得益于为它开发的高智能的包管理和升级系统，
它将会是一个速度飞快的版本。我不得不承认这套智能化的系统在整个版本中占据了很大一
部分位置，因为对于我这个光杆司令来说在那种重复性的劳动中消耗时间是没法接受的，所
以才会要求开发中的系统必须自动为我完成那些琐事。另一方面完全由源代码来构建整个发
行版（比那些“spin off”的版本、例如RedHat要好）也需要把工作划分好并尽可能多的挤
出空闲时间来做这些工做。

使最基本的Enoch系统启动和运行之后，我回到了irc.openprojects.net并开设了自己的＃
enoch频道。在那里我逐渐聚集起了10 个开发人员组成的团队。在早期的那段时间里我们整
天都聚集在IRC里，用空下来的时间制作我们的发行版。在我们无私的付出和大家的齐心协
力的hack下，在不断的消除bug和新的bug的过程中，Enoch每天都在变化着，不管是专业化
的程度还是各方面的功能都变得越来越出色。

Enoch的第一块绊脚石

不可避免的一天，Enoch碰到了它的第一块绊脚石。在加入了Xfree86、glib、gtk＋之后，
我决定把xmms（一个基于X11/gtk＋的 MP3/CD播放软件）弄进我的发行版，因为也该到了用
音乐来调剂调剂的时候了！但是在安装好xmms之后启动它时......X死锁了！最初我觉得是
自己使用的编译器的优化参数造成的（"-O6 -mpentiumpro"，在你看来有点诧异吧？）。第
一个想到的解决办法就是用标准的编译器选项来编译，但是问题依然没有解决。然后只好到
处寻找解决方法，接下来整整几个星期的开发时间我都用来追踪这个错误。一天，我收到了
一个叫Omegardan的Enoch使用者的电子邮件，他也同样碰到了 xmms的这个死锁问题。

交流了一段时间然后历经了n个小时的检测后我们发现死锁的原因在于POSIX的线程描述符
（POSIX threads-related issue）。因为一些原因，pthread_mutex_trylock()函数没有返
回它应该返回的值。作为一个Linux版本的创始者，这种类型的 bug是我真的不愿意碰见的
家伙。我指望开发人员能能够释出完美的源代码以便我可以把精力放到提高Linux易用性上，
而不是把时间花在修复别人源代码的 bug上。当然很快我就发现这种希望仅仅只是一个美好
的想法罢了，相同的错误有时还是会出现。

在找到问题后，我们发现它不是xmms本身的问题，也不时gtk＋或glib的问题，也不是
Xfree86 3.3.5没有thread-safe和死锁的问题，而是令人惊异的存在于Linux 的POSIX的线
程执行本身，具体来说就是版本2.1.2的GNU C库（glibc）的部分代码中存在bug。我很震惊
的是在Linux如此核心的部分居然存在这样严重的bug（而且我们为Enoch使用的glibc的版本
是它的release版本，并不是什么prerelease版本或是CVS版本！）。

那么怎么样才能解决这个问题呢？我们不可能马上就能拿出一个修补方案，但是在浏览了一
堆glibc开发人员的邮件列表后，我偶然发现了还有一个人也碰到了相同的问题，然后在
glibc开发人员在回复他的邮件里我们找到了那个附带的补丁，它为我们解决了那个线程问
题。但我令我好奇的是为什么同样使用 glibc 2.1.2的RedHat 6没有受这个bug的影响（当
时RedHat 6的发布时间先于那个补丁的出现）。为了找到答案，我下载了RedHat里glibc的
SRPM包（source RPM）想看一下他们使用的补丁是怎么样的。

RedHat有他们自己的glibc补丁来解决pthread_mutex_trylock()函数的问题。显而易见的是
他们也碰到了同样的问题，然后自己进行了修补。但是由于RedHat没有把这个补丁回馈到
glibc的开发社区，其他人们就没有办法分享这个补丁。但是也可能是RedHat把这个修补方
案回馈到了glibc的开发社区，然儿glibc的开发人员并没有接受这个修补方案。或者这个
bug只会在特定版本的binutils和特定版本的编译器连用时才会触发，然而RedHat使用的
binutils和编译器的版本并不是这两个特定的版本（虽然RedHat还是给出了这个补丁）。我
猜测我们永远也不会知道究竟事情的真相是什么样的，但是我学会的一件事情是：RedHat的
SRPM包里有很多定制的补丁和增强代码，而这些代码和补丁看来从来没有回馈到原始的开发
人员那里。我将会为此来上一段激昂的演说。

激情的演说

当你将一大堆各种各样的源代码汇聚成一个Linux发行版时，把所有你做好的bug fix和补丁
反馈给原始的某个软件包的开发人员是一件相当重要的事情，就如我了解到的那样，这是发
行版的开发人员为Linux做贡献的很多途径中的一个。我们也恰好就是这样的一群人，为的
就是把很多不同的程序和软件集合在一起，让它们工作起来就像是一个整体。将来我们也会
把我们们对一些软件所做的修改和补丁反馈回原始软件的开发人员以便其他的用户和后来的
发行版能从中受益。如果你只是把补丁留在你自己那里，这样做不会对任何人有什么帮助，
很多人们将会为一些相同的问题浪费掉大量的时间。这种不顾别人的方式违背了整个开源世
界的精神和宗旨，同时对Linux的发展也只是有害无益。或许我应该说这样的做法对我们来
说就是一个大大的“BUG”。

不幸的是一些发行版（啊咳）（RedHat）并不如其他一些版本（Debian）那样对整个开源社
区分享他们的成果。

编译器的艺术

在我们尝试解决glibc 线程问题的时候，我给Ulrich Drepper发了封email（他是Cygnus的
一员并且在glibc的开发中举足轻重）。我在e-mail中提到了我们碰到的POSIX线程问题和我
们在Enoch中使用pgcc来获得优化的性能。在他的回信中他这样提到（我解释一下）：“我
们自己的包含在CodeFusion中的编译器制作的可执行代码比其他的一些编译器、比如pgcc编
译出来的代码执行速度更快速。”显然我对测试测试Cygnus那帮家伙开发的神秘的“turbo”
编译器非常有兴趣。

因此我申请拿到了一个Cygnus Codefusion 1.0的demo拷贝以便我可以对它的性能做一个测
试。Omegadan和我对测试的结果很吃惊，它同Ulrich提到的那样出色。x86的后端提高了 90
％的有关cpu-intersive的可执行文件的执行效率（比如bzip2）。几乎每一个程序都能从中
获得至少10％的真实世界的性能提升，而我们所作的仅仅是换了一个编译器。Enoch的速度
也因此获得了30％－40％的提升。同时性能也提高了不少，提升的幅度超过了我们以前把编
译器从gcc切换到pgcc时提高的幅度。显然，在对这个编译器的测试后，我们很希望把这个
编译器包含在Enoch中，有点幸运的是CodeFusion CD中的包含的源代码遵循的是GPL，这样
在Enoch中使用这个编译器已经可以算是已经得到了完全的认可了..........，至少我们是
这么想的。

异常事件的发生

为了能在Enoch中使用这个编译器，我给Cygnus的市场部主管发了一封电子邮件，但是期望
中的“哦，拿去用好了，感谢使用我们的编译器！”这样的回复并没有收到，取而代之的是
一句“虽然在技术上我们许可使用Cygnus的编译器，但是我们强烈建议不要在在Enoch中使
用该编译器或是包含它的源代码。接着在我的回复中我问了他们这样一个问题：“既然不愿
意让别人使用它的源代码，为什么还在以GPL的许可条例来发布它的源代码？”作为一个猜
测，我觉得他们事实上是不想以GPL的方式来发布他们的源代码的，但是由于这个编译器是
源自egcs（以GPL方式发布的），他们除了以GPL方式发布之外别无选择。

这是当某一个公司想使用开源的代码来生产私有产品这样的情况时，GPL如何阻止这样的事
情发生的一个很好的例子。我比较有根据的一个猜测是Cygnus担心我们使用这个编译器后将
会打击到他们整个产品框架的销售，更加奇怪的是不管是他们的行销方案还是InfoWorld的
预览中都没有提及包含在 CodeFusion中的那个新的编译器，因为CodeFusion销售的是一套
“development IDE”而不是一个编译器。

为了缓解一下他们那种偏执的态度，我提出了个建议，就是在我们的Enoch主页上放置上
CodeFusion的签注文件并加上一个链接来刺激 CodeFusion的销售。从我个人的观点来说，
我不认为一个“turbo”的Enoch会影响到CodeFusion（虽然它是一个IDE产品）的销售情况。
但是我还在想方设法的令到他们愉快，比如告诉他们这个IDE的组件是一个商业化的产品，
我们也并没希望或者有什么意图用Enoch来发行它。

我把这个（大方的）请求用电子邮件的方式发给了Cygnus，但是收到的确实另一个奇怪的回
复。他们想得到所有我们关于“市场元素”方面的具有权威的权利（显然，这也包括了我们
网站上的内容），真是太令人震惊了。Cyguns的营销团队似乎对Linux社区和GPL的运作一无
所知，事到如今我终于决定终止与Cygnus彼此间的联系，因为再这样下去事情会变得怎么样
谁都不知道。与此同时，我们为Enoch准备了两个版本，一个是内部的“turbo”版，一个是
公开的“non－turbo”版，其实就是把决定留在将来再去做。

但是几个月之后，他们就把CodeFusion x86的backend换成了gcc 2.95.2，现在不只是那些
知道包含在CodeFusion CD中的“隐秘的GPL编译器”的这群人可以获益，几乎每一个人都可
以从这个新的优秀的backend中获益了。然后我们还是决定继续前行，尽量使用 gcc来替代
CodeFusion的编译器。在gcc 2.95.2已经越来越成熟的情况下，我们已经可以放开Cygnus了
（同时，RedHat却为购买这个CodeFusion而花费了比较冤的一笔钱了。）（注：新的x86版
本gcc 2.95.2的backend为新的Linux发行版提供了一开始我们提到的很重要的速度提升，它
也为FreeBSD 4.0相对3.3.6版本速度上提升做出了很大的贡献。你注意到这两个提升的不同
点吗？）

肥皂盒

感谢这件事情和其他的一些经验，我从中对那些以开源为主要获利手段的企业有了很深的理
解。虽然对个人来说，乐于生产私有闭源软件这件事并没有任何错误的地方，但是一个开源
企业搅乱或是拒绝与其他的开源世界合作是没有任何意义的；同样，不支持GPL或是其他的
等等也没有什么意义。这是一个实践性质的并具有现实意义的观点。

思想和代码上自由的交换才是开源企业得以获利的根本，这点他们应该充分的认识到。反过
来，对立与GPL标准只会破坏这个他们依赖于发展与繁荣的环境。换句话说，开源的环境是
你事业的土壤，保护这片土壤的纯净还是很有意义的。

我也懂得在短时期内保留一些代码上秘密来获得财富的累积是一个颇具诱惑性的东西，先进
的代码和特别的技术提供给了人们一个在竞争中获得优势的绝好机会，由此可以获得增长的
销售业绩和利益。但是当你的目的是成为一个唯一的产品提供者，而这个产品商业的成分大
于开源的成分时，开源世界是不会许可这样排外性质地使用开源或是相关东西的，这就是开
源的意义。

回到Enoch

现在，我从自己的肥皂盒中出来并继续我的故事。

由于Enoch已经变得越来越出色，更名的计划也就这样列入了我们的议事日程当中，接着
“Gentoo Linux”诞生了。然后就是朝Gentoo Linux 的1.0版本努力前进中。大约也是这个
时候，我决定帮我那台Celeron 300M（超频到450M并且十分稳定）的老电脑升级一下，新平
台是一块崭新的Abit BP6主板（从市场上找到的双Celeron接口的）。在卖掉了老主板后我
把我两个Celeron 366的系统集中起来，然后把Celeron 366超到了500Mhz，然后开始工作了。
但是我注意到我的新机器不是非常稳定。

显然我第一个反应就是把频率改回没超之前的366Mhz，但是随之而来却遇到了一个更奇怪的
问题：不管CPU全速运转多少时间，系统都不会死锁；但是一旦空闲下来过一夜的话，系统
有很大的可能就会完全死锁掉。是的，这是一个idle bug－－－－噢！在作了一些调查之后，
我发现在这块主板上也有其他用户碰到了这个相同的问题。原因是BP6主板上的一个芯片
（可能是PCI控制器）与标准规格有点不同或是比较古怪，这个东西就是造成Linux在空闲时
候死锁的主要原因。

我渐渐的心烦意乱起来，因为我没法再去采购另外的PC部件了，Gentoo的开发也只好被迫终
止下来。我也开始对Linux越来越有些悲观的情绪了并决定转向FreeBSD。是的，的确是
FreeBSD！这部分就此为止了，我们Part3再见了：）


Making the distribution, Part 3

The author strays from Linux and then returns

在前一篇文章的结尾部分，我说到因为新升级的双Celeron主板（Abit BP6）存在一个古怪
的空闲时死锁的问题导致Gentoo开发停止。虽然解决问题的办法就是更换主板，但是我已经
没有重新更换主板的资金了，这件事也打击了我对Linux的信心并使我决定中断Gentoo的开
发并转向了FreeBSD。我需要的是一个可以正常运转的系统，而Linux在这个时候的表现并不
尽如人意（一天到晚的死锁），那个当口，我觉得是好好接触接触FreeBSD的时候了，便在
机器上安装了FreeBSD后开始了又一次的捣腾，在接下去的几个月中，我也几乎没有再碰过
Linux一个指头。

FreeBSD之印象

首先，我真的很喜欢FreeBSD。我感觉这个操作系统是一个组合的很完美的系统，它的几乎
每一个部分都同样精巧，而这种精巧的在Linux世界中几乎不存在。我的满意实质上是来源
于那些FreeBSD中非常充足的man page，这可不像Linux里那些只有GNU info文档的很多软件
那样让人根本没法用。

最最重要的是我对FreeBSD中维护与升级系统的ports系统印象非常深刻。与Linux维护与升
级的方法不同，ports使用的不是二进制的软件包而是直接去原始的软件站点下载所需要的
源代码并编译。不管你是安装Samba或是升级核心系统都是在你的机器上用源代码编译而成。
这样的实现方法和我在 Gentoo Linux中建立的那套机制有着异曲同工之处。从这点和其他
许多方面来说，FreeBSD的这种设计符合我作为一个开发人员和一个系统管理员所期望的那
种感觉。就这样，FreeBSD为我营造了整整几个月舒适的工作环境，同样我也很乐意于花些
时间在这个出色的操纵系统中探求与获取知识。

FreeBSD的优点

很多Linux和FreeBSD之间的不同点都是源自与它们本身开发架构的不同。Linux的开发架构
非常松散，我们只是依靠不同的发行版把分散在 Internet上呈离散状态的很多部分组合成
一个完整的Linux，而FreeBSD和其他BSD系统（OpenBSD和NetBSD）都有一个唯一的核心小组
来确保源代码的单一性和协调性，这样至少每一种BSD自身都拥有一套统一的源代码设置。
这是一件挺棒的事情，也是FreeBSD感觉上和 Linux那种“patch集合”有所不同的主要原因。

接下来，我们在纯技术方面再作个比较。很多FreeBSD的粉丝都声称FreeBSD比Linux更合适
用作服务器上跑的操作系统，他们会告许你在高负载情况下FreeBSD表现得更好，而且它的
TCP/IP栈相对出色一些（如果你用Linux 2.2或更早版本的内核和FreeBSD作比较，我同意这
个说法）。FreeBSD确实是一个很好的服务器操作系统，这点勿庸置疑，但是这只是
FreeBSD相对Linux 2.2或更早的内核版本时的情况。我作为一个新版本内核的粉丝，早就在
我的电脑上用上了2.4测试版的内核，它确是也很棒，从出色的TCP/IP栈到整个重新设计的
“netfilter”系统都是。我觉得在不久的将来，新的性能标准将会由Linux来定义，而
“free UNIX”将会在商业领域面对Linux强有力的挑战。

FreeBSD的不足

与服务器领域的应用不同，在桌面应用上，Linux占有绝对份额上的优势（仅相对BSD来说，
Linux不管是对Win还是对MAC都完全处于下风）。所有最新的桌面应用软件一定是先在Linux
上出现、在3D加速和声卡的支持方面，Linux也比BSD走在了前面。随着2.4版本内核的临近，
Linux 在这块地盘上还是会继续保持它的优势地位。

我对FreeBSD采用的UFS文件系统并不喜欢，虽然UFS相对Linux的ext2文件系统来说更健壮，
但是付出的代价是那个另人昏昏欲睡的龟速。现在也有一个UFS文件系统的扩展叫“soft
update”，它是把小块的IO操作聚合成大的文件块后再写入物理硬盘以提高文件系统的速度，
就算“soft update”这套机制大幅提高了UFS文件系统的性能，我也没法就说在所有方面的
比较中UFS都比ext2优秀。当然，UFS和“soft update”更加可靠，FreeBSD也可能会在文件
系统的战争中击败Linux，但是请不要忘记，输给FreeBSD的仅仅只是现在的2.2版本或者更
旧版本的Linux，这不代表将来也会。

现在，我们把话题转变一下，我们比较的双方是现今的Linux 2.2版本、2.4版本和FreeBSD。
Reiserfs（一个新的日志型文件系统）已经给我们带来了一阵惊喜，而Linux还有蓄势待发
的ext3、 IBM的JFS和XFS文件系统，这些文件系统都在提供高可靠性的同时提供了优秀的性
能。Reiserfs给了Linux在文件系统上超越FreeBSD 的一个契机，这也是我认为Linux 2.4版
本会上演大逆转的原因，FreeBSD的传统强项在未来2.4内核面前可能会荡然无存。

回到Gentoo的开发

几个月之后决定重新回到Linux世界的我在一台新的机器上又装了Gentoo。首先，回到
Gentoo的开发中来是一个计算后的决定－－我已经花费了很多时间使自己成为一个Linux的
万事通，而现在怀抱着BSD就等于是把以前学到的知识都浪费掉了，这样做我觉得不是很值
得。而且在更新Gentoo Linux后那么一段很短的时间内，我为“为什么再次回到Linux怀抱”
找到了几个新的理由，也就是前面提到过的kernel以及文件系统的改进等等。 FreeBSD是一
个宁静的家园，但是这样的宁静太安静了点，这样的宁静也包含着困惑。相反Linux世界充
满着活力，发展也是日新月异。如果你所寻找的是兴奋和创新的地方，那么毫无疑问Linux
就是你所向往的世外桃源。

Linux从2.0进步到2.2给我的感觉就是满失望的，但是2.4时代是绝对值得去守候着的，为此
Gentoo Linux重新回到了我们面前，那种兴奋的感觉也重新回到了我的心中。

Gentoo Linux重生的另一个关键因素是我们开发团队的领导者－－Achim Gottinger。我想
花一点篇幅对他所给予的帮助（使我我重新开始了Gentoo Linux的开发）致以诚挚的感谢。
我在回到Linux世界之前就开始与Achim Gottinger有了电子邮件上的往来，在几乎每一封他
的电子邮件中，我都可以看到一些新的.ebuild或者是些迫切需要修复的bug。在我回到
Linux世界并重新开始了Gentoo的开发之后，Achim继续贡献着他的时间和精力使这个发行版
步入正轨。直到最近，Achim和我都是 Gentoo Linux仅有的两个开发者，这也是出于选择的
结果。因为我们都使用几乎相同的发行版，也因为Achim的技术，我们可以轻松的完成非常
巨大的工作量以至于我觉得加入第三名开发者并不会对我们的进展有什么帮助。现在Achim
是Gentoo Linux开发组的负责人，几乎每天Gentoo的都会有基础部分中主要的提高。我们已
经走到了这里，也已经准备好了CVS树为后来者提供一个协同开发平台，小心翼翼的逐步扩
大Gentoo开发队伍的工作也开始付诸实施。

新的版本

我没有觉得花在BSD上的时间是在浪费。实际上，它给了我一个很好的机会来反省一下整个
Linux社区存在的问题和Gentoo Linux应该做点什么来改进这些短处。.

在新版本的Gentoo Linux中，我下决定不再使用pgcc或者什么非常优化的参数来编译所有的
软件包，因为稳定性还是要放在第一位的，我们默认将会使用合理的优化选项（" -O2
-mpentium"），但也同时向用户提供了可以简单自定义的优化选项来满足了一些同胞希望得
到最“bleed edge”的系统（通过我们的自动化系统完成）这么个愿望。

FreeBSD给了我一个关于“自动化定制系统如何工作？”这个问句一个很好的提示。我决定
在我们的自动化定制系统（现在叫做Portage）中加入一些FreeBSD的特性来制作一个新一代
的ports系统。

Portage 可以说是Gentoo Linux的心脏，它所具备的东西远远超过一个简单的包管理机制或
是一个系统管理机制。Portage通过它包含的对制作工具的设置和制作脚本可以使你从源代
码构建一个完整的发行版系统。但对我来说更重要的是，Portage给用户提供了一个可以完
全接触Gentoo Linux构建智慧的途径。对我们开发者来说，这意味着当Gentoo Linux不断发
展的同时我们也记录下了一个发行版制作的过程。Portage的易用性和可读性也为越来越多
的人提供了一个窥探Linux内部的窗口，它也为后来者贡献他们的代码和脚本打开了方便之
门。

Portage是我们为他人展示Linux技术和原理的一条途径，通货学习自动化制作脚本，你可以
看到大量各不相同的包是怎么互相适应并结合成一个整体的。如果你需要，你也可以从我们
的站点上攫取整个CVS树然后自己hack并制作个人的Linux发行版。我们坚信这是一件好事情
－－我们希望把知识交给渴望这些知识的人们以便他们可以把Linux带入一个新的领域。

商业上的关注

起初，有许多拥有不同背景的人们加入了Gentoo的开发中来。因为这个，我们的开发人员对
于如何最终在Gentoo上获得经济利益也有许多各不相同的打算，对此我并没有太多的诧异。
基本上有这么两种类型的开发人员：一类群体反对用Gentoo来追名逐利，另一类群体则对使
Gentoo Linux成为一个成功的商业产品非常感兴趣。这是一个预料中会存在分歧的地方，第
一类群体认为商业化的运作包含着腐化等不良的影响，而第二类群体则认为没有这么多的负
面因素。

在以前还是Enoch的那段时光中，我对商业成份究竟有利还是有弊这点也很难做个了断。我
验证过的是像Debian这样的Linux发行版真正忠于“自由”这样的事实，我喜欢这样。对比
其他商业化的发行版，他们给用户带来的易用性包括了在各自的网站上提供一份完整的安装
说明，这也是一个我想去借鉴的好东西。

同样，我也真心希望Gentoo Linux能够成为一个成功的商业版本，为了这个目的，我努力想
在商业和开源之间找到一个平衡点，可是直到最近我还是没有能够找到这么一个黄金分割点。

该做些什么

我们该怎么做才能在商业化和非商业化中取得平衡呢？关键的一点是一定不能忘记我们的基
楚和根本－－－Gentoo Linux 作为一个开源软件的根本和基础。所有我们作出的努力都必
须遵循这个基础，这不仅仅是肯定开源软件或只是使用开源软件，还是对开源软件和开源发
行版开发的鼓励和支持，也不会发对用这样的一个对待开源姿态来获取商业回报。更重要的
是，我们绝不会采用商业化的模型，因为这样做对于其他发行版使用我们的源代码有阻碍作
用。我们的开发团队对所有人来说都会是开放的和可接近的，而Gentoo Linux这个自由发行
版不仅仅可以被大家接受还会因为很多人的鼓励而继续走下去。我们必会成为开源运动的倡
导者，一个把这个理念贯彻到行动中而不是停留在文字层面上的倡导者。

如果某公司需要为一个商业化的基于Linux技术的需求使用Gentoo Linux，他们可以从我们
的CVS树中攫取这些代码并马上开始使用它们，因为所有我们的分散的工作都是基于GPL。我
们在确信所有基于Gentoo Linux的衍生产物都遵循GNU Public License的前提下是不会在任
何地方限制别人使用我们的代码的。

我们希望有尽可能多的人们从我们的工作中受益，但是我们也希望尽可能多的能从你对
Gentoo Linux的提高中获益。如果你公司的产品有很大一部份是基于Gentoo Linux的话，希
望你可以把所有可分类的修改和提高发送给我们以便加入到CVS树中使更多的人获益。继续
保管和改进你提交的修改后，你也能从我们所做的修改中受益。我们也鼓励商业实体和非商
业实体之间的合作，举个例子来说：不管是在他的ISP中使用Gentoo Linux的系统管理员还
是用Gentoo Linux构建商业服务器的公司都能从彼此对Gentoo Linux的改进中获益。是时候
来促进在人们之间的自由代码交换了，这也只有开源软件可以做到。

将来要走的路

现在离Gentoo Linux 1.0 的发布已经很近了（在你在developerWorks上读这篇文章的时候
它可能已经发布了，想想现在的2006.0是不是大家有种沧海桑田的感觉^-^??）。但是
Gentoo Linux将来的方向会是怎么样的呢？

当我们逐步迈向2.0版本时，我希望继续提升Portage作为Gentoo Linux核心的性能，因为任
何关于Gentoo Linux主要的进步都会从Portage的进步开始。主要代码从bash转换到python
的过程我也会继续下去，因为这么做会使我们加入新的设计（比如为我们的全自动构造系统
设计的面向对象的新东东）。

除了Portage的修改，我还希望小心谨慎的寻找技术出色并且和我们使用相同版本的开发者
加入我们的开发团队。在扩大了开发团队之后，我们可以为 Gentoo Linux的加入更多的自
动化定制脚本。比这更重要的是，适当扩大的开发团队可以使Gentoo Linux站在Linux技术
的尖锋之上，这才是乐趣所在嘛：）

我们也希望商业化的Linux技术公司可以把Gentoo Linux作为他们产品的基础。现在我们已
经有了这样一个关系，将来也会更多的，而这样的协作承诺充满着乐趣并对于Gentoo Linux
的用户非常有益。

最后我要说的是，我们主要的目标是为Linux社区提供有意义的贡献。虽然可选择的发行版
很多，但是Gentoo Linux还是拥有许多其他版本所没有的东西。我们对未来Gentoo Linux发
展充满着信心，我们希望你也有同样的感觉。

（完）