（译文）Gentoo的前世今生 PART 1（完成版）
Making the distribution, Part 1
Birth of the Gentoo Linux
我和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的和我在这条路上将要面对的许多新的挑战。
敬请期待^_^
翻译：linky_fan @ www.linuxfans.org
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发展充满着信心，我们希望你也有同样的感觉。
Making the distribution, Part 1
Birth of the Gentoo Linux
我和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的和我在这条路上将要面对的许多新的挑战。
敬请期待^_^
翻译：linky_fan @ www.linuxfans.org
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发展充满着信心，我们希望你也有同样的感觉。
152
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
