[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發

展充滿着信心，我們希望你也有同樣的感覺。

（完）