Gentoo的前世今生(转)
filed in Linux/c/c++ on Dec.21, 2008
原文链接: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 [...]