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

如果你和我是同一类人，在你进入开源世界和 Linux 世界之前大概看过位于 Redmond 和 Cupertino 的那些大公司们准备的下一代操作系统，它们确实如你所愿般的完美，然而那些东西却始终都只是一个虚幻的影子而已。然后就在我们慢慢等待的过程中 Linux 来到了我们面前。虽然等来的这个精灵并不如我们预料的那么完美，但是她却提供给了我们这些喜欢动手 hack 的男孩和女孩一个亲手改变她的机会。就这样我们一边期待着一个更强大的操作系统，一边津津有味的 hack 我们的 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 格式包含了了 232 个字段，字段种类为 232 种，每个字段最大数据段同样为 232bytes。新的格式不仅具有良好的扩充性而且比纯文本更加紧凑和简洁并易于解析。二进制代码和文本都能存储在这样的格式当中，该架构对其本身在未来的进一步发展带来了无限的可能性。我的想法是把这个新版的动态 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 的和我在这条路上将要面对的许多新的挑战。

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

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

使最基本的 Enoch 系统启动和运行之后，我回到了 irc.openprojects.net 并开设了自己的 ＃enoch 频道。在那里我逐渐聚集起了 10 个开发人员组成的团队。在早期的那段时间里我们整天都聚集在 IRC 里，用空下来的时间制作我们的发行版。在我们无私的付出和大家的齐心协力的 hack 下，在不断的消除 bug 和新的 bug 的过程中，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”。

不幸的是一些发行版并不如其他一些版本（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 已经变得越来越出色，更名的计划也就这样列入了我们的议事日程当中，接着“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！

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

最重要的是我对 FreeBSD 中维护与升级系统的 ports 系统印象非常深刻。与 Linux 维护与升级的方法不同，ports 使用的不是二进制的软件包而是直接去原始的软件站点下载所需要的源代码并编译。不管你是安装 Samba 或是升级核心系统都是在你的机器上用源代码编译而成。这样的实现方法和我在 Gentoo Linux 中建立的那套机制有着异曲同工之处。从这点和其他许多方面来说，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 强有力的挑战。

与服务器领域的应用不同，在桌面应用上，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 内核面前可能会荡然无存。

几个月之后决定重新回到 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 发展充满着信心，我们希望你也有同样的感觉。