Gentoo版Linux操作系统的前世今生 （4）

新的开始

离开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的和我在这条路上将要面对的许多新的挑战。

Enoch踏出的第一步

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

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

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