Gentoo的前世今生PART 1
Makingthe distribution, Part 1
Birth of the GentooLinux
我和Linux
現今對每一個linux愛好者來說，linux不再只是一個字面上的名稱，她所呈現的一切對很多開發人員來說已經超過了他們所接觸過的任何東西，linux比它們更強大、更令人着迷和稱讚。當我在新墨西哥大學擔任系統管理員時便與linux結下了不解之緣。那時因爲我們的NT服務器運行得非常棒，我的手頭上也有了很多空餘的時間可以加以利用，就這樣第一個linux操作系統被我安裝到了一臺Pentium166的主機上，接下來的不斷學習和深入理解的過程使我對linux越來越着迷了......
一開始學習了linux下的很多細節的東西：網絡訪問、執行備份、搞定samba等等。接着我建了一個qmail和apache的服務器並學習了python編程和shell編程。我還搭建了一個小型局域網接着把linux請回了家，在嘗試過很多發行版後我最終選擇了StampedeLinux這個版本（注：該版本從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中越來越普遍，原來很多有經驗的StampedeLinux用戶漸漸失去了他們一開始的熱情。但是我依然還是很興奮，因爲很多菜鳥的問題我都知道解決的辦法，要我忍着不回答那些問題我可做不到！當然我也並不是唯一的那個對解決新手問題樂此不彼的人，同樣的傢伙也有不少。我也承認自己也有那麼點私心，想從那些更有經驗的傢伙們（不是指Stampede的開發人員）身上學到更多的東西。
如何起步
當有朋友問我如何才能加入一個開源項目時，我告訴他們的是首先是找一個能爲他人做些什麼的地方，就算那裏只是解答一些很基礎的問題。一份誠摯的渴望幫助他人的願望是通往Linux社區的通行證，因爲這份誠摯的願望同樣也紮根在每一個開源項目開發人員的心中（不僅僅只是Linux項目），也應該紮根在那裏。
沿着這條路走下去不可避免的你會遇到比你更有經驗的同志，你將會從他們身上學到更多的知識，就像以前新手從你身上學習時一樣。另一方面，當你積累起更多的經驗時在碰到某些問題時你就會用一個新方法去解決它而不是用以前慣用的一套思路。你遇到的一些開發人員有時會提出一些建議，有時又或者會需要一些幫助，他們更可能會邀請你加入他們的開發隊伍；如果你的助人爲樂成爲焦點時，他們可能會笑着從你身邊經過；如果你幫助了很多很多人之後，你在社區內肯定會備受矚目。在Stampede和我身上這些故事都曾經發生過。
漸漸的我在Stampede的開發越來越深入，不久以後我就成爲了一個正是的Stampede開發人員。在受到了Stampede的領導者MattWood的鼓勵後，我開始對用於StampedeLinux軟件包的原有的.slp機制進行升級。當時，.slp軟件包格式包含一個.tar.bz2的軟件包和後面的一個包含軟件描述及軟件包創作者等等在內的一個定長的頁腳。這種實現的方式有兩個主要問題：頁腳部分實際上包含的內容根本達不到定長所約定的字節數；該格式沒有預留任何擴充餘地（也就是說如果未來沒有辦法加入一些可能需要的額外信息）。顯然這些問題需要動一次大手術了，活活。
和那些老資格的Stampede開發人員工作一段時間後，我擬了一個解決上面那些問題的草案。過了一陣子我便開始用Python先編寫了一些原始的實現方案，新的格式(代號slpv6）有些類似與Amiga世界的IFF格式。下一代的.slp格式包含了了232（注1）個字段，字段種類爲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的和我在這條路上將要面對的許多新的挑戰。
Gentoo的前世今生PART 2
Making thedistribution, Part 2
From Enoch to Gentoo, via minor setbacksand corporaterun-ins
Enoch踏出的第一步
我在先前的文章中告訴了大家那段和Stampede開發團隊在一起的、曾經最興旺的時光和最後爲什麼離開的原因（就是想離那些有低級政治目的的、想控制項目的那幫傢伙遠點）。因爲這些愛管閒事的好事者的干涉，我纔會覺得裝配一個自己的Linux發行版比在那種惡劣條件下改進Stampede要簡單的多。幸運的是，我離開Stampede時是帶着滿滿當當的經驗離開的，這些經驗與在Stampede的工作（應該是實質性的吧？）是分不開的，維護一些軟件包也好、設計初始化腳本也好或是領導slpv6（下一代軟件包管理系統）都使我相關方面的知識和經驗得到了極大的豐富。
Enoch是我開始工作的這個版本的一個代號，得益於爲它開發的高智能的包管理和升級系統，它將會是一個速度飛快的版本。我不得不承認這套智能化的系統在整個版本中佔據了很大一部分位置，因爲對於我這個光桿司令來說在那種重複性的勞動中消耗時間是沒法接受的，所以纔會要求開發中的系統必須自動爲我完成那些瑣事。另一方面完全由源代碼來構建整個發行版（比那些“spinoff”的版本、例如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的線程描述符（POSIXthreads-relatedissue）。因爲一些原因，pthread_mutex_trylock()函數沒有返回它應該返回的值。作爲一個Linux版本的創始者，這種類型的bug是我真的不願意碰見的傢伙。我指望開發人員能能夠釋出完美的源代碼以便我可以把精力放到提高Linux易用性上，而不是把時間花在修復別人源代碼的bug上。當然很快我就發現這種希望僅僅只是一個美好的想法罷了，相同的錯誤有時還是會出現。
在找到問題後，我們發現它不是xmms本身的問題，也不是gtk＋或glib的問題，也不是Xfree863.3.5沒有thread-safe和死鎖的問題，而是令人驚異的存在於Linux的POSIX的線程執行本身，具體來說就是版本2.1.2的GNUC庫（glibc）的部分代碼中存在bug。我很震驚的是在Linux如此核心的部分居然存在這樣嚴重的bug（而且我們爲Enoch使用的glibc的版本是它的release版本，並不是什麼prerelease版本或是CVS版本！）。
那麼怎麼樣才能解決這個問題呢？我們不可能馬上就能拿出一個修補方案，但是在瀏覽了一堆glibc開發人員的郵件列表後，我偶然發現了還有一個人也碰到了相同的問題，然後在glibc開發人員在回覆他的郵件裏我們找到了那個附帶的補丁，它爲我們解決了那個線程問題。但我令我好奇的是爲什麼同樣使用glibc2.1.2的RedHat6沒有受這個bug的影響（當時RedHat6的發佈時間先於那個補丁的出現）。爲了找到答案，我下載了RedHat裏glibc的SRPM包（sourceRPM）想看一下他們使用的補丁是怎麼樣的。
RedHat有他們自己的glibc補丁來解決pthread_mutex_trylock()函數的問題。顯而易見的是他們也碰到了同樣的問題，然後自己進行了修補。但是由於RedHat沒有把這個補丁回饋到glibc的開發社區，其他人們就沒有辦法分享這個補丁。但是也可能是RedHat把這個修補方案回饋到了glibc的開發社區，然而glibc的開發人員並沒有接受這個修補方案。或者這個bug只會在特定版本的binutils和特定版本的編譯器連用時纔會觸發，然而RedHat使用的binutils和編譯器的版本並不是這兩個特定的版本（雖然RedHat還是給出了這個補丁）。我猜測我們永遠也不會知道究竟事情的真相是什麼樣的，但是我學會的一件事情是：RedHat的SRPM包裏有很多定製的補丁和增強代碼，而這些代碼和補丁看來從來沒有回饋到原始的開發人員那裏。我將會爲此來上一段激昂的演說。
激情的演說
當你將一大堆各種各樣的源代碼匯聚成一個Linux發行版時，把所有你做好的bugfix和補丁反饋給原始的某個軟件包的開發人員是一件相當重要的事情，就如我瞭解到的那樣，這是發行版的開發人員爲Linux做貢獻的很多途徑中的一個。我們也恰好就是這樣的一羣人，爲的就是把很多不同的程序和軟件集合在一起，讓它們工作起來就像是一個整體。將來我們也會把我們們對一些軟件所做的修改和補丁反饋回原始軟件的開發人員以便其他的用戶和後來的發行版能從中受益。如果你只是把補丁留在你自己那裏，這樣做不會對任何人有什麼幫助，很多人們將會爲一些相同的問題浪費掉大量的時間。這種不顧別人的方式違背了整個開源世界的精神和宗旨，同時對Linux的發展也只是有害無益。或許我應該說這樣的做法對我們來說就是一個大大的“BUG”。
不幸的是一些發行版（啊咳）（RedHat）並不如其他一些版本（Debian）那樣對整個開源社區分享他們的成果。
編譯器的藝術
在我們嘗試解決glibc線程問題的時候，我給UlrichDrepper發了封email（他是Cygnus的一員並且在glibc的開發中舉足輕重）。我在e-mail中提到了我們碰到的POSIX線程問題和我們在Enoch中使用pgcc來獲得優化的性±能。在他的回信中他這樣提到（我解釋一下）：“我們自己的包含在CodeFusion中的編譯器製作的可執行代碼比其他的一些編譯器、比如pgcc編譯出來的代碼執行速度更快速。”顯然我對測試測試Cygnus那幫傢伙開發的神祕的“turbo”編譯器非常有興趣。
因此我申請拿到了一個CygnusCodefusion1.0的demo拷貝以便我可以對它的性能做一個測試。Omegadan和我對測試的結果很吃驚，它同Ulrich提到的那樣出色。x86的後端提高了90％的有關cpu-intersive的可執行文件的執行效率（比如bzip2）。幾乎每一個程序都能從中獲得至少10％的真實世界的性能提升，而我們所作的僅僅是換了一個編譯器。Enoch的速度也因此獲得了30％－40％的提升。同時性能也提高了不少，提升的幅度超過了我們以前把編譯器從gcc切換到pgcc時提高的幅度。顯然，在對這個編譯器的測試後，我們很希望把這個編譯器包含在Enoch中，有點幸運的是CodeFusionCD中的包含的源代碼遵循的是GPL，這樣在Enoch中使用這個編譯器已經可以算是已經得到了完全的認可了..........，至少我們是這麼想的。
異常事件的發生
爲了能在Enoch中使用這個編譯器，我給Cygnus的市場部主管發了一封電子郵件，但是期望中的“哦，拿去用好了，感謝使用我們的編譯器！”這樣的回覆並沒有收到，取而代之的是一句“雖然在技術上我們許可使用Cygnus的編譯器，但是我們強烈建議不要在在Enoch中使用該編譯器或是包含它的源代碼。接着在我的回覆中我問了他們這樣一個問題：“既然不願意讓別人使用它的源代碼，爲什麼還在以GPL的許可條例來發布它的源代碼？”作爲一個猜測，我覺得他們事實上是不想以GPL的方式來發布他們的源代碼的，但是由於這個編譯器是源自egcs（以GPL方式發佈的），他們除了以GPL方式發佈之外別無選擇。
這是當某一個公司想使用開源的代碼來生產私有產品這樣的情況時，GPL如何阻止這樣的事情發生的一個很好的例子。我比較有根據的一個猜測是Cygnus擔心我們使用這個編譯器後將會打擊到他們整個產品框架的銷售，更加奇怪的是不管是他們的行銷方案還是InfoWorld的預覽中都沒有提及包含在CodeFusion中的那個新的編譯器，因爲CodeFusion銷售的是一套“developmentIDE”而不是一個編譯器。
爲了緩解一下他們那種偏執的態度，我提出了個建議，就是在我們的Enoch主頁上放置上CodeFusion的簽註文件並加上一個鏈接來刺激CodeFusion的銷售。從我個人的觀點來說，我不認爲一個“turbo”的Enoch會影響到CodeFusion（雖然它是一個IDE產品）的銷售情況。但是我還在想方設法的令到他們愉快，比如告訴他們這個IDE的組件是一個商業化的產品，我們也並沒希望或者有什麼意圖用Enoch來發行它。
我把這個（大方的）請求用電子郵件的方式發給了Cygnus，但是收到的確實另一個奇怪的回覆。他們想得到所有我們關於“市場元素”方面的具有權威的權利（顯然，這也包括了我們網站上的內容），真是太令人震驚了。Cyguns的營銷團隊似乎對Linux社區和GPL的運作一無所知，事到如今我終於決定終止與Cygnus彼此間的聯繫，因爲再這樣下去事情會變得怎麼樣誰都不知道。與此同時，我們爲Enoch準備了兩個版本，一個是內部的“turbo”版，一個是公開的“non－turbo”版，其實就是把決定留在將來再去做。
但是幾個月之後，他們就把CodeFusionx86的backend換成了gcc2.95.2，現在不只是那些知道包含在CodeFusionCD中的“隱祕的GPL編譯器”的這羣人可以獲益，幾乎每一個人都可以從這個新的優秀的backend中獲益了。然後我們還是決定繼續前行，儘量使用gcc來替代CodeFusion的編譯器。在gcc2.95.2已經越來越成熟的情況下，我們已經可以放開Cygnus了（同時，RedHat卻爲購買這個CodeFusion而花費了比較冤的一筆錢了。）（注：新的x86版本gcc2.95.2的backend爲新的Linux發行版提供了一開始我們提到的很重要的速度提升，它也爲FreeBSD4.0相對3.3.6版本速度上提升做出了很大的貢獻。你注意到這兩個提升的不同點嗎？）
肥皂盒
感謝這件事情和其他的一些經驗，我從中對那些以開源爲主要獲利手段的企業有了很深的理解。雖然對個人來說，樂於生產私有閉源軟件這件事並沒有任何錯誤的地方，但是一個開源企業攪亂或是拒絕與其他的開源世界合作是沒有任何意義的；同樣，不支持GPL或是其他的等等也沒有什麼意義。這是一個實踐性質的並具有現實意義的觀點。
思想和代碼上自由的交換纔是開源企業得以獲利的根本，這點他們應該充分的認識到。反過來，對立與GPL標準只會破壞這個他們依賴於發展與繁榮的環境。換句話說，開源的環境是你事業的土壤，保護這片土壤的純淨還是很有意義的。
我也懂得在短時期內保留一些代碼上祕密來獲得財富的累積是一個頗具誘惑性的東西，先進的代碼和特別的技術提供給了人們一個在競爭中獲得優勢的絕好機會，由此可以獲得增長的銷售業績和利益。但是當你的目的是成爲一個唯一的產品提供者，而這個產品商業的成分大於開源的成分時，開源世界是不會許可這樣排外性質地使用開源或是相關東西的，這就是開源的意義。
回到Enoch
現在，我從自己的肥皂盒中出來並繼續我的故事。
由於Enoch已經變得越來越出色，更名的計劃也就這樣列入了我們的議事日程當中，接着“GentooLinux”誕生了。然後就是朝GentooLinux
的1.0版本努力前進中。大約也是這個時候，我決定幫我那臺Celeron300M（超頻到450M並且十分穩定）的老電腦升級一下，新平臺是一塊嶄新的AbitBP6主板（從市場上找到的雙Celeron接口的）。在賣掉了老主板後我把我兩個Celeron366的系統集中起來，然後把Celeron366超到了500Mhz，然後開始工作了。但是我注意到我的新機器不是非常穩定。
顯然我第一個反應就是把頻率改回沒超之前的366Mhz，但是隨之而來卻遇到了一個更奇怪的問題：不管CPU全速運轉多少時間，系統都不會死鎖；但是一旦空閒下來過一夜的話，系統有很大的可能就會完全死鎖掉。是的，這是一個idlebug－－－－噢！在作了一些調查之後，我發現在這塊主板上也有其他用戶碰到了這個相同的問題。原因是BP6主板上的一個芯片（可能是PCI控制器）與標準規格有點不同或是比較古怪，這個東西就是造成Linux在空閒時候死鎖的主要原因。
我漸漸的心煩意亂起來，因爲我沒法再去採購另外的PC部件了，Gentoo的開發也只好被迫終止下來。我也開始對Linux越來越有些悲觀的情緒了並決定轉向FreeBSD。是的，的確是FreeBSD！這部分就此爲止了，我們Part3再見了：）
Gentoo的前世今生part3
Making thedistribution, Part 3
The author strays from Linux and thenreturns
在前一篇文章的結尾部分，我說到因爲新升級的雙Celeron主板（AbitBP6）存在一個古怪的空閒時死鎖的問題導致Gentoo開發停止。雖然解決問題的辦法就是更換主板，但是我已經沒有重新更換主板的資金了，這件事也打擊了我對Linux的信心並使我決定中斷Gentoo的開發並轉向了FreeBSD。我需要的是一個可以正常運轉的系統，而Linux在這個時候的表現並不盡如人意（一天到晚的死鎖），那個當口，我覺得是好好接觸接觸FreeBSD的時候了，便在機器上安裝了FreeBSD後開始了又一次的搗騰，在接下去的幾個月中，我也幾乎沒有再碰過Linux一個指頭。
FreeBSD之印象
首先，我真的很喜歡FreeBSD。我感覺這個操作系統是一個組合的很完美的系統，它的幾乎每一個部分都同樣精巧，而這種精巧的在Linux世界中幾乎不存在。我的滿意實質上是來源於那些FreeBSD中非常充足的manpage，這可不像Linux裏那些只有GNUinfo文檔的很多軟件那樣讓人根本沒法用。
最最重要的是我對FreeBSD中維護與升級系統的ports系統印象非常深刻。與Linux維護與升級的方法不同，ports使用的不是二進制的軟件包而是直接去原始的軟件站點下載所需要的源代碼並編譯。不管你是安裝Samba或是升級核心系統都是在你的機器上用源代碼編譯而成。這樣的實現方法和我在GentooLinux中建立的那套機制有着異曲同工之處。從這點和其他許多方面來說，FreeBSD的這種設計符合我作爲一個開發人員和一個系統管理員所期望的那種感覺。就這樣，FreeBSD爲我營造了整整幾個月舒適的工作環境，同樣我也很樂意於花些時間在這個出色的操縱系統中探求與獲取知識。
FreeBSD的優點
很多Linux和FreeBSD之間的不同點都是源自與它們本身開發架構的不同。Linux的開發架構非常鬆散，我們只是依靠不同的發行版把分散在Internet上呈離散狀態的很多部分組合成一個完整的Linux，而FreeBSD和其他BSD系統（OpenBSD和NetBSD）都有一個唯一的核心小組來確保源代碼的單一性和協調性，這樣至少每一種BSD自身都擁有一套統一的源代碼設置。這是一件挺棒的事情，也是FreeBSD感覺上和Linux那種“patch集合”有所不同的主要原因。
接下來，我們在純技術方面再作個比較。很多FreeBSD的粉絲都聲稱FreeBSD比Linux更合適用作服務器上跑的操作系統，他們會告許你在高負載情況下FreeBSD表現得更好，而且它的TCP/IP棧相對出色一些（如果你用Linux2.2或更早版本的內核和FreeBSD作比較，我同意這個說法）。FreeBSD確實是一個很好的服務器操作系統，這點勿庸置疑，但是這只是FreeBSD相對Linux2.2或更早的內核版本時的情況。我作爲一個新版本內核的粉絲，早就在我的電腦上用上了2.4測試版的內核，它確是也很棒，從出色的TCP/IP棧到整個重新設計的“netfilter”系統都是。我覺得在不久的將來，新的性能標準將會由Linux來定義，而“freeUNIX”將會在商業領域面對Linux強有力的挑戰。
FreeBSD的不足
與服務器領域的應用不同，在桌面應用上，Linux佔有絕對份額上的優勢（僅相對BSD來說，Linux不管是對Win還是對MAC都完全處於下風）。所有最新的桌面應用軟件一定是先在Linux上出現、在3D加速和聲卡的支持方面，Linux也比BSD走在了前面。隨着2.4版本內核的臨近，Linux在這塊地盤上還是會繼續保持它的優勢地位。
我對FreeBSD採用的UFS文件系統並不喜歡，雖然UFS相對Linux的ext2文件系統來說更健壯，但是付出的代價是那個另人昏昏欲睡的龜速。現在也有一個UFS文件系統的擴展叫“softupdate”，它是把小塊的IO操作聚合成大的文件塊後再寫入物理硬盤以提高文件系統的速度，就算“softupdate”這套機制大幅提高了UFS文件系統的性能，我也沒法就說在所有方面的比較中UFS都比ext2優秀。當然，UFS和“softupdate”更加可靠，FreeBSD也可能會在文件系統的戰爭中擊敗Linux，但是請不要忘記，輸給FreeBSD的僅僅只是現在的2.2版本或者更舊版本的Linux，這不代表將來也會。
現在，我們把話題轉變一下，我們比較的雙方是現今的Linux2.2版本、2.4版本和FreeBSD。Reiserfs（一個新的日誌型文件系統）已經給我們帶來了一陣驚喜，而Linux還有蓄勢待發的ext3、IBM的JFS和XFS文件系統，這些文件系統都在提供高可靠性的同時提供了優秀的性能。Reiserfs給了Linux在文件系統上超越FreeBSD的一個契機，這也是我認爲Linux2.4版本會上演大逆轉的原因，FreeBSD的傳統強項在未來2.4內核面前可能會蕩然無存。
回到Gentoo的開發
幾個月之後決定重新回到Linux世界的我在一臺新的機器上又裝了Gentoo。首先，回到Gentoo的開發中來是一個計算後的決定－－我已經花費了很多時間使自己成爲一個Linux的萬事通，而現在懷抱着BSD就等於是把以前學到的知識都浪費掉了，這樣做我覺得不是很值得。而且在更新GentooLinux後那麼一段很短的時間內，我爲“爲什麼再次回到Linux懷抱”找到了幾個新的理由，也就是前面提到過的kernel以及文件系統的改進等等。FreeBSD是一個寧靜的家園，但是這樣的寧靜太安靜了點，這樣的寧靜也包含着困惑。相反Linux世界充滿着活力，發展也是日新月異。如果你所尋找的是興奮和創新的地方，那麼毫無疑問Linux就是你所向往的世外桃源。
Linux從2.0進步到2.2給我的感覺就是滿失望的，但是2.4時代是絕對值得去守候着的，爲此GentooLinux重新回到了我們面前，那種興奮的感覺也重新回到了我的心中。
GentooLinux重生的另一個關鍵因素是我們開發團隊的領導者－－AchimGottinger。我想花一點篇幅對他所給予的幫助（使我我重新開始了GentooLinux的開發）致以誠摯的感謝。我在回到Linux世界之前就開始與AchimGottinger有了電子郵件上的往來，在幾乎每一封他的電子郵件中，我都可以看到一些新的.ebuild或者是些迫切需要修復的bug。在我回到Linux世界並重新開始了Gentoo的開發之後，Achim繼續貢獻着他的時間和精力使這個發行版步入正軌。直到最近，Achim和我都是GentooLinux僅有的兩個開發者，這也是出於選擇的結果。因爲我們都使用幾乎相同的發行版，也因爲Achim的技術，我們可以輕鬆的完成非常巨大的工作量以至於我覺得加入第三名開發者並不會對我們的進展有什麼幫助。現在Achim是GentooLinux開發組的負責人，幾乎每天Gentoo的都會有基礎部分中主要的提高。我們已經走到了這裏，也已經準備好了CVS樹爲後來者提供一個協同開發平臺，小心翼翼的逐步擴大Gentoo開發隊伍的工作也開始付諸實施。
新的版本
我沒有覺得花在BSD上的時間是在浪費。實際上，它給了我一個很好的機會來反省一下整個Linux社區存在的問題和GentooLinux應該做點什麼來改進這些短處。.
在新版本的GentooLinux中，我下決定不再使用pgcc或者什麼非常優化的參數來編譯所有的軟件包，因爲穩定性還是要放在第一位的，我們默認將會使用合理的優化選項（"-O2-mpentium"），但也同時向用戶提供了可以簡單自定義的優化選項來滿足了一些同胞希望得到最“bleededge”的系統（通過我們的自動化系統完成）這麼個願望。
FreeBSD給了我一個關於“自動化定製系統如何工作？”這個問句一個很好的提示。我決定在我們的自動化定製系統（現在叫做Portage）中加入一些FreeBSD的特性來製作一個新一代的ports系統。
Portage 可以說是GentooLinux的心臟，它所具備的東西遠遠超過一個簡單的包管理機制或是一個系統管理機制。Portage通過它包含的對製作工具的設置和製作腳本可以使你從源代碼構建一個完整的發行版系統。但對我來說更重要的是，Portage給用戶提供了一個可以完全接觸GentooLinux構建智慧的途徑。對我們開發者來說，這意味着當GentooLinux不斷髮展的同時我們也記錄下了一個發行版製作的過程。Portage的易用性和可讀性也爲越來越多的人提供了一個窺探Linux內部的窗口，它也爲後來者貢獻他們的代碼和腳本打開了方便之門。
Portage是我們爲他人展示Linux技術和原理的一條途徑，通貨學習自動化製作腳本，你可以看到大量各不相同的包是怎麼互相適應並結合成一個整體的。如果你需要，你也可以從我們的站點上攫取整個CVS樹然後自己hack並製作個人的Linux發行版。我們堅信這是一件好事情－－我們希望把知識交給渴望這些知識的人們以便他們可以把Linux帶入一個新的領域。
商業上的關注
起初，有許多擁有不同背景的人們加入了Gentoo的開發中來。因爲這個，我們的開發人員對於如何最終在Gentoo上獲得經濟利益也有許多各不相同的打算，對此我並沒有太多的詫異。基本上有這麼兩種類型的開發人員：一類羣體反對用Gentoo來追名逐利，另一類羣體則對使GentooLinux成爲一個成功的商業產品非常感興趣。這是一個預料中會存在分歧的地方，第一類羣體認爲商業化的運作包含着腐化等不良的影響，而第二類羣體則認爲沒有這麼多的負面因素。
在以前還是Enoch的那段時光中，我對商業成份究竟有利還是有弊這點也很難做個了斷。我驗證過的是像Debian這樣的Linux發行版真正忠於“自由”這樣的事實，我喜歡這樣。對比其他商業化的發行版，他們給用戶帶來的易用性包括了在各自的網站上提供一份完整的安裝說明，這也是一個我想去借鑑的好東西。
同樣，我也真心希望GentooLinux能夠成爲一個成功的商業版本，爲了這個目的，我努力想在商業和開源之間找到一個平衡點，可是直到最近我還是沒有能夠找到這麼一個黃金分割點。
該做些什麼
我們該怎麼做才能在商業化和非商業化中取得平衡呢？關鍵的一點是一定不能忘記我們的基楚和根本－－－GentooLinux作爲一個開源軟件的根本和基礎。所有我們作出的努力都必須遵循這個基礎，這不僅僅是肯定開源軟件或只是使用開源軟件，還是對開源軟件和開源發行版開發的鼓勵和支持，也不會發對用這樣的一個對待開源姿態來獲取商業回報。更重要的是，我們絕不會採用商業化的模型，因爲這樣做對於其他發行版使用我們的源代碼有阻礙作用。我們的開發團隊對所有人來說都會是開放的和可接近的，而GentooLinux這個自由發行版不僅僅可以被大家接受還會因爲很多人的鼓勵而繼續走下去。我們必會成爲開源運動的倡導者，一個把這個理念貫徹到行動中而不是停留在文字層面上的倡導者。
如果某公司需要爲一個商業化的基於Linux技術的需求使用GentooLinux，他們可以從我們的CVS樹中攫取這些代碼並馬上開始使用它們，因爲所有我們的分散的工作都是基於GPL。我們在確信所有基於GentooLinux的衍生產物都遵循GNUPublicLicense的前提下是不會在任何地方限制別人使用我們的代碼的。
我們希望有儘可能多的人們從我們的工作中受益，但是我們也希望儘可能多的能從你對GentooLinux的提高中獲益。如果你公司的產品有很大一部份是基於GentooLinux的話，希望你可以把所有可分類的修改和提高發送給我們以便加入到CVS樹中使更多的人獲益。繼續保管和改進你提交的修改後，你也能從我們所做的修改中受益。我們也鼓勵商業實體和非商業實體之間的合作，舉個例子來說：不管是在他的ISP中使用GentooLinux的系統管理員還是用GentooLinux構建商業服務器的公司都能從彼此對GentooLinux的改進中獲益。是時候來促進在人們之間的自由代碼交換了，這也只有開源軟件可以做到。
將來要走的路
現在離GentooLinux 1.0的發佈已經很近了（在你在developerWorks上讀這篇文章的時候它可能已經發布了，想想現在的2006.0是不是大家有種滄海桑田的感覺^-^??）。但是GentooLinux將來的方向會是怎麼樣的呢？
當我們逐步邁向2.0版本時，我希望繼續提升Portage作爲GentooLinux核心的性能，因爲任何關於GentooLinux主要的進步都會從Portage的進步開始。主要代碼從bash轉換到python的過程我也會繼續下去，因爲這麼做會使我們加入新的設計（比如爲我們的全自動構造系統設計的面向對象的新東東）。
除了Portage的修改，我還希望小心謹慎的尋找技術出色並且和我們使用相同版本的開發者加入我們的開發團隊。在擴大了開發團隊之後，我們可以爲GentooLinux的加入更多的自動化定製腳本。比這更重要的是，適當擴大的開發團隊可以使GentooLinux站在Linux技術的尖鋒之上，這纔是樂趣所在嘛：）
我們也希望商業化的Linux技術公司可以把GentooLinux作爲他們產品的基礎。現在我們已經有了這樣一個關係，將來也會更多的，而這樣的協作承諾充滿着樂趣並對於GentooLinux的用戶非常有益。
最後我要說的是，我們主要的目標是爲Linux社區提供有意義的貢獻。雖然可選擇的發行版很多，但是GentooLinux還是擁有許多其他版本所沒有的東西。我們對未來GentooLinux發展充滿着信心，我們希望你也有同樣的感覺。
原文如下：
http://www.gentoo.org/doc/en/articles/making-the-distro-p3.xml