30 周年，Linux 成功的真正原因是什么？
微信搜索逆鋒起筆關注后回復編程pdf
領取編程大佬們所推薦的 23 種編程資料！
作者丨 Jeremy Andrews
譯者丨屠靈
策劃丨蔡芳芳
Linux 誕生于 1991 年，距今已經 30 年了。雖然它一開始只是 Linus 的一個個人項目，而非出于要開發一個新操作系統的偉大夢想，但如今的 Linux 早已無處不在。
30 年前，當 Linus Torvalds 第一次發布 Linux 內核時，他還是赫爾辛基大學的一名 21 歲的學生。他宣布說：“我正在開發一個（免費的）操作系統（這只是個愛好，不會做得很大，也不會很專業……）”。30 年后，500 強超級計算機和 70% 以上的智能手機都在運行 Linux。很顯然，Linux 不僅大，而且很專業。
30 年來，Linus Torvalds 一直在領導著 Linux 內核的開發，啟發了無數開發者和開源項目。2005 年，Linus 開發了 Git，用來管理內核開發過程。Git 現在已經成為最流行的版本控制系統，受到無數開源和私有項目的信任。
正值 Linux 誕生 30 周年之際，Linus Torvalds 通過電子郵件回復了 Tag 1 咨詢公司的創始合伙人 / 首席執行官 Jeremy Andrews 的訪談問題（《An Interview With Linus Torvalds: Linux and Git - Part 1》），回顧并總結了過去這些年他在領導大型開源項目過程中得到的真知灼見。本文著重介紹 Linux 內核開發和 Git。
1
Linux 內核開發
?Linux 發展的關鍵：“我不認識的人都在使用 Linux”
Jeremy Andrews：Linux 無處不在，它是整個開源世界的靈感源泉。當然，事情并不是從一開始就這樣的。1991 年，你在 comp.os.minix Usenet 新聞組中發布了一個 Linux 內核。十年后，你寫了一本書，叫作“Just for Fun: The Story of an Accidental Revolutionary”（中譯名：《只是為了好玩：Linux 之父林納斯自傳》），對那段歷史進行了深度回顧。今年 8 月，Linux 將迎來它的 30 周年紀念日！在這個過程中，你是在什么時候開始意識到 Linux 并不僅僅是一個“愛好”的？
Linus Torvalds：這聽起來可能有點荒謬，實際上我很早就開始意識到了。在 1991 年末（以及 1992 年初），Linux 已經比我預想的要大得多。
那時候可能只有幾百個用戶（確切地說不是“用戶”，因為人們還要不斷地對它進行修修補補），從沒想過 Linux 后來能夠發展壯大。在我看來，最大的轉折點是當我意識到其他人正在使用它，并對它感興趣，它開始有了自己的生命。人們開始發送補丁，這個系統能做的事情比我最初預想的要多得多。
1992 年 4 月的某個時候，X11 被移植到 Linux 上（其實我也記不太清具體時間了，畢竟那是很久以前的事了），這是一個重大進步，Linux 系統突然間有了 GUI 和一系列全新的功能。
我一開始并沒有什么大計劃。這只是一個個人項目，并不是出于要開發一個新操作系統的偉大夢想。我當時只是想了解我的新 PC 硬件的來龍去脈。
所以，在發布第一個版本時，實際上更多的是想“看看自己都做了些什么”。當然，我希望其他人會覺得它有趣，但它并不是一個真正可用的操作系統。它更多的是一種概念驗證，而且只是一個我在當時做了幾個月的個人項目。
從“個人項目”到其他人開始使用它、給我反饋（和 bug 報告）和發送補丁，對我來說是一個巨大的轉變。
舉個最基本的例子：最初的版權許可是“你可以以源代碼的形式發布它，但不能用它賺錢”。
對于當時的我來說，商業版 Unix 太貴了（作為窮學生，我已經為了買新 PC 花光了所有錢），所以我希望這個操作系統的源代碼是公開可用的（這樣人們就可以提供補丁），我希望將它開放給像我這樣負擔不起昂貴電腦和操作系統的人。
1991 年末（或是 1992 年初），我把許可改為 GPLv2，因為有人想把它以軟盤的形式分發給本地 Unix 用戶組，但又想收回軟盤的成本，并補償他們拷貝軟盤所花費的時間。我覺得這很合理，因為“免費”與否并不是最重要的，最重要的是要“公開源碼”。
最終的結果是：人們不僅在 Unix 用戶組中發布它，在幾個月之內還出現了 SLS 和 Slackware 的軟盤發行版。
與最初的那些根本性的變化相比，后來的一切都是“增量式”的。當然，有些增量式的變化也是大跨步（IBM 的加入、Oracle 數據庫的移植、Red Hat 的首次公開募股，Android 在手機上的應用，等等），但在我看來，它們仍然不如最初的“我不認識的人都在使用 Linux”那樣具有革命性。
?Linux 成功的重要原因：修改開源許可協議，采用 GPLv2
Jeremy Andrews：你是否曾經后悔修改了許可協議？或者說，其他人或公司用你開發的系統賺了很多錢，你因此感到后悔嗎？
Linus Torvalds：我從來沒有后悔過。
首先，我過得還不錯。我不是特別富有，但我是一個薪水很高的軟件工程師，可以按照自己的節奏做我喜歡做的事情。
關鍵是我百分之百認為這個許可是 Linux（以及 Git）取得成功的重要原因。我認為，當所有人都認為他們有平等的權利，沒有人在這方面有特權的時候，他們才會變得更快樂。
有很多項目采用了“雙重許可”，一方面，原作者保留了商業許可（“只要你支付了許可費用，就可以使用它”），另一方面，項目也可以在 GPL 許可下開源。
我認為要在這種情況下建立好的社區是非常困難的，因為開源那一方知道自己是“二等公民”。另外，為了讓享有特權的那一方一直享有特殊的權利，需要做很多許可文書工作，這給項目帶來了額外的阻力。
另一方面，我見過很多基于 BSD（或 MIT 等類似的許可）許可的開源項目，當它們變得足夠強大，大到具備商業價值時，它們就開始分裂，相關的公司不可避免地會將自己的那部分變成專有的。
我認為 GPLv2 能夠在“每個人都處于相同的規則之下”和“要求人們回饋社區”之間取得完美的平衡。每個人都知道，所有參與者都受到相同的規則的約束，所以這是非常公平的。
當然，你的投入總會得到回報。如果你只是想輕度參與項目，或者只是想作為一名用戶，那也是可以的。如果你真的只是這樣，就也無法控制這個項目。如果你真的只需要一個基本的操作系統，而 Linux 已經具備你想要的所有功能，那也完全沒有問題。但如果你有特殊的需求，想要為這個項目做一點事情，那么唯一的方法就是參與其中。
這讓每個人都秉持誠實的態度，包括我在內。任何人都可以 fork 這個項目，用他們自己的方式，然后說“再見了，Linus，我要維護自己的 Linux 版本”。我之所以“特別”，僅僅是因為人們相信我能把工作做好。
“任何人都可以維護自己的 Linux 版本”，這讓一些人對 GPLv2 產生了懷疑，但我認為這是一種優勢，而不是劣勢。我認為，這實際上是避免 Linux 出現分裂的原因：每個人都可以創建自己的項目分支。事實上，這也是“Git”的核心設計原則之一——代碼庫的每一個克隆都是一個分支，人們（和公司）再 fork 出自己的版本，完成開發工作。
所以，分支不是問題，只要你能把好的部分合并回來。這就是 GPLv2 發揮作用的地方。能夠拉取分支，并按照自己的方式修改代碼，擁有這些權利很重要，但另一方面也同樣重要——當一個分支被證明取得了成功，有權利把它合并回去。
另一個問題是，除了要有支持這種工作流的工具，也要有可以支持它的心態。合并分支的一大障礙不僅是許可問題，還有“嫌隙”問題。如果分支是源于對立，那么要合并兩個分支就非常困難——不是因為許可或技術方面的原因，而是因為分支之間太過對立。我認為 Linux 避免了這種情況的發生，主要是因為我們一直認為分支是一件很自然的事情。而且，當一些開發工作被證明取得了成功，嘗試將其合并回來也是很自然的。
雖然這個答案有點偏離正題，但我認為它很重要——我不后悔修改了許可，因為我真的認為 GPLv2 是 Linux 取得成功的一個重要原因。
金錢不是一種很好的激勵方式，它無法讓人們團結在一起。我認為，參與一個共同的項目，并感覺到自己可以成為這個項目的合作伙伴，這樣才能激勵人們。
Jeremy Andrews：現在，人們基于 GPLv2 發布源代碼通常是因為 Linux。你當時是怎么找到這個許可的？你在調研其他許可方面又投入了多少時間和精力呢？
Linus Torvalds：那個時候，有關 BSD 和 GPL 的爭論非常激烈。我在閱讀各種新聞組（比如 comp.arch、comp.os.minix 等）時看到了一些有關許可的討論。
其中兩個最主要的原因可能是 gcc 和 Lars Wirzenius。gcc 對 Linux 的發展起到了很大作用，因為我肯定需要一個 C 語言編譯器。Lars Wirzenius 是我在念大學時另一個說瑞典語（瑞典語在芬蘭是小語種）的計算機系學生。
Lasu 比我更喜歡討論與許可相關的事情。
在我看來，選擇 GPLv2 并不算是什么重大的政治問題，主要是因為我最初在選擇許可時太過倉促，后來需要做出修改。況且，我很感恩有 gcc，并且 GPLv2 更符合我對“你必須把源代碼合并回來”這種想法的期望。
因此，與其另起爐灶新建一個許可，不如選擇一個人們已經知道并且有一些律師參與其中的許可。
?Linux 之父的一天
Jeremy Andrews：通常情況下，你的一天是怎么過的？其中有多少時間花在寫代碼上，多少花在評審代碼上，多少花在電子郵件上？你如何平衡個人生活和 Linux 內核開發工作？
Linus Torvalds：我現在寫的代碼很少，而且已經很久沒寫了。再要寫代碼，通常是因為人們對某些特定的問題存在爭議。我修改代碼，并將其作為補丁發布出去，作為對解決方案的解釋說明。
換句話說，我寫的大部分代碼更多的是作為解決方案的示例，而補丁是一種非常具體的例子。人們很容易陷入理論討論的陷阱，而我發現描述解決方案最好的方式是寫代碼片段，不一定要完整的程序，只要讓解決方案具體化一些即可。
我的工作時間都花在電子郵件上了。主要是溝通，而不是寫代碼。事實上，我認為這種與記者和技術博主之間的交流就是我工作的一部分——它可能比技術討論優先級低一些，但我也花了相當多的時間在這類事情上。
當然，我也會花一些時間在代碼評審上。但老實說，當我收到一個 PR 時，有問題的代碼通常已經被其他人評審過了。所以，雖然我仍然會看一下補丁，但實際上會更多地去關注注解，以及補丁的演化過程。但對于那些與我共事很久的人，我不會這么做：他們是自己子系統的維護者，我不需要對他們的工作指手畫腳。
所以，很多時候，我的主要工作就是“待在那里”，執行管理和發布任務。換句話說，我的工作通常更多地是關于維護過程，而不是底層代碼。
?Linux 之父的工作環境
Jeremy Andrews：你的工作環境是怎樣的？比如，你是喜歡黑暗、不會受人打擾的房間，還是喜歡能看到風景的房間？你喜歡在安靜的環境下工作，還是喜歡一邊聽音樂一邊工作？你通常使用哪種硬件？你是在終端上使用 vi 來評審代碼，還是使用某種奇特的 IDE？你是否有偏愛的 Linux 發行版作為開發環境？
Linus Torvalds：我的房間并不“暗”，但我確實把桌子旁邊窗戶上的百葉窗關上了，因為我不想要強烈的陽光。所以，我的房間沒有什么風景視野，只有一張（凌亂的）桌子，配了兩個 4k 顯示器，桌子下面有一臺強勁的電腦主機。還有幾臺筆記本電腦供我測試和在路上用。
我喜歡安靜地工作。我很討厭機械硬盤的滴答聲，所以我把它們扔進了垃圾桶，現在只使用 SSD。這樣已經 10 多年了。嘈雜的 CPU 風扇聲也是不可接受的。
代碼評審都是在傳統的終端上完成的，不過我沒有使用 vi。我使用的是“micro-emacs”這個令人討厭的東西。它與 GNU emacs 完全沒有關系，只是有些鍵綁定與它相似。我在赫爾辛基大學時就習慣用它了，到現在還沒改掉這個習慣。幾年前，我給它增加了（非常有限的）utf-8 支持，但它確實很老舊了，所有的跡象都表明它是在 80 年代開發的，我使用的版本是一個自 90 年代中期以來就沒有更新過的分支。
赫爾辛基大學選擇了這個工具，因為它可以在 DOS、VAX/VMS 和 Unix 上運行，這也是為什么我也會用它。到現在，我的手指已經對它形成肌肉記憶了。我真的需要換個有人維護并支持 utf-8 的工具，只是我增強的那部分功能用起來還好，所以一直沒有強迫我的手指去接受新的工具。
我的工作桌面相當簡單：幾個文本終端，一個打開了電子郵箱的瀏覽器（還打開了其他幾個標簽，主要是新聞和科技網站）。我喜歡大的桌面空間，因為我習慣使用大終端窗口（100x40 是我的默認初始大小），并且并排打開好幾個。我使用了兩個 4k 顯示器。
我在所有的機器上都安裝了 Fedora 發行版，并不是因為我偏愛它，而是因為我習慣了。我并不太關心使用哪個發行版——對于我來說，選擇發行版只是在機器上安裝 Linux 和開發工具的一種方式。
?如何處理大量電子郵件？
Jeremy Andrews：Linux 內核郵件組（https://lore.kernel.org/lkml/） 是人們公開交流內核開發的地方，流量非常高。你是怎么處理這么多電子郵件的？你嘗試過郵件組之外的其他協作和溝通解決方案嗎？或者說，這種簡單的郵件組對你的工作來說足夠好嗎？
Linus Torvalds：我沒有直接閱讀內核郵件組里的郵件，而且好幾年都沒有。郵件太多了。
內核郵件組里的郵件會被抄送到所有的討論當中。當新人加入討論時，他們可以通過查看內核郵件組來了解相關的歷史和背景。
過去我會訂閱郵件組，讓所有沒有抄送給我的電子郵件自動歸檔，默認不看它們。當一些問題需要我介入時，我可以找到所有相關的討論，因為它們都在我的電子郵件里，只是在需要時才會出現在我的收件箱里。
現在，我使用的是 lore.kernel.org 提供的功能，因為它很好用，而且我們還基于它開發了一些工具。這樣就不需要讓郵件自動歸檔了，我們換了一種討論方式，但基本的工作流程是一樣的。
但很顯然，我仍然會收到很多郵件——但從很多方面來看，這些年來情況變得越來越好，而不是越來越糟。其中很大一部分原因是 Git 和內核發布流程的改進：我們過去在代碼流程和工具方面存在很多問題。在本世紀初是最為糟糕的，當時我們仍然在處理巨大的補丁炸彈，我們的開發流程存在嚴重的可伸縮性問題。
郵件組模式確實運作得很好，但并不是說人們就不使用除電子郵件之外的其他溝通方式了：有些人喜歡各種實時聊天工具（比如傳統的 IRC）。雖然我不是很喜歡這樣，但很顯然有些人喜歡用它們來進行頭腦風暴。但這種“郵件組存檔”模式運作得非常好，并且能夠無縫地與“開發者之間以郵件的形式發送補丁”和“以郵件的形式發送問題報告”相結合。
所以電子郵件仍然是主要的溝通渠道，并且因為郵件中可以包含補丁，我們可以更容易地討論技術問題。而且郵件可以跨越時區，當參與者分布在不同地區時，這一點非常重要。
?Linux 3.0 以來，內核開發的有趣事情
Jeremy Andrews：我密切關注內核開發大約有 10 年了，并在 KernelTrap 上寫與內核有關的博文，大概是在 3.0 內核發布時停止更新博客。3.0 內核的發布與 2.6.x 內核的發布相隔了 8 年。請總結一下自 3.0 版本以來內核開發中發生的一些有趣的事情。
Linus Torvalds：那是很久以前的事了，我不知道該從哪里開始總結。從 3.0 版本到現在已經 10 年了，在這 10 年中發生了很多技術上的變化。ARM 已經發展成熟，ARM64 已經成為我們的主要架構之一，并出現了大量新的驅動程序和核心功能。
如果說過去 10 年有什么有趣的事情，那一定是我們努力保持開發模式的穩定，以及那些沒有發生改變的東西。
在過去的幾十年里，我們經歷了多種不同的版本號方案和不同的開發模式，3.0 版本最終確定了后來一直使用的模式。它讓“基于時間發布，版本號只是數字，與特性無關”這一說法落地了。
在 2.6.x 版本中，我們就有了基于時間的發布模式，所以它并不是什么新東西，但 3.0 版本確實是讓這種模式板上釘釘的至關重要的一步。
我們以前使用隨機編號方案（主要是在 1.0 版本之前），然后用“奇數表示開發版內核，偶數表示穩定的生產就緒版內核”，然后在 2.6.x 版本中，我們開始進入基于時間的發布模式。但人們仍然對“什么時候需要增加主版本號”存在疑問。3.0 版本正式發布后，宣告了主版本號沒有任何意義，我們盡量簡化數字，不要讓它們變得太大。
因此，在過去的 10 年里，我們做了巨大的改變（有了 Git，就可以很容易地得到一些數字統計數據：超過 1.7 萬人提交了大約 75 萬次代碼），但開發模式仍然相當穩定。
但并非一直都是這樣的，內核開發的前 20 年經歷了相當痛苦的開發模式變更，只是在過去 10 年中，發布可預測性才得到大幅提升。
?Linux 發布流程
Jeremy Andrews：目前，最新的版本是 5.12-rc5。現在的發布流程標準是怎樣的？例如，-rc1 和 -rc2 有什么不同？你會在什么情況下決定正式發布其中一個給定的版本？如果在正式發布之后出現了大量的回歸會怎樣？這種情況發生的頻率是怎樣的？這些年來，這個過程是如何演變的？
Linus Torvalds：我之前提到過，這個過程本身是很標準的，并且在過去十年里一直如此。在此之前，它經歷了幾次演變，但實際上從 3.0 開始它就像時鐘一樣走得很穩定。
到現在為止，我們的發布節奏是這樣的：先是兩周的合并時間窗口，然后是大約 6 到 8 周的候選版本，然后是最終版本。這樣子差不多 15 年了。
規則一直都是一樣的，盡管它們并不總是被完全嚴格執行：合并時間窗口是針對那些被認為已經“經過測試和準備就緒”的新代碼，然后在接下來的大約兩個月里進行修復，以確保所有的問題都得到解決。有時候，那些所謂的“就緒”代碼會在發布之前會被禁用或完全推翻。
這個過程會重復，所以我們大約每 10 周發布一次。
達到可以發布的標準是我對候選版本有足夠的信心，而這是以各種問題報告為基礎的。如果某些方面在 rc 后期仍然會出問題，我就極力推翻這些內容，并建議將其放在后續的版本中。但總體而言，很少會出現這種情況。
這樣就完全沒有問題了嗎？不是的。一旦內核發布了，就會有新用戶，他們會發現一些在 rc 版本中沒有被發現的問題。這幾乎是不可避免的。這也是為什么我們需要“穩定內核”樹。在發布之后，我們可以繼續修復代碼。一些穩定內核比其他版本內核維護的時間更長，被稱為 LTS（“Long Term Support”）版本。
所有這些在過去十年里都沒有什么變化，盡管后來有了更多的自動化流程。一般來說，內核測試自動化是很困難的——因為很多內核是驅動程序，十分依賴硬件的可用性。不過，我們有幾個測試場同時進行引導和性能測試，以及各種隨機負載測試。這些在這幾年有了很大的改善。
?一直等待可用的 ARM 機器
Jeremy Andrews：去年 11 月，有人說你對蘋果公司在部分新款電腦中使用的 ARM64 芯片十分感興趣。Linux 會支持它們嗎？我看到一些代碼被合并到 for-next。即將到來的 5.13 內核有可能在蘋果 MacBook 上啟動嗎？你有可能是它的早期采用者嗎？ARM64 有什么重大的意義？
Linus Torvalds：我偶爾會跟進一下，但現在說這些還為時過早。正如你所說的，早期支持可能會被合并到 5.13 中，但這只是一個開始，并不能說明 Linux 和蘋果電腦將來會怎樣。
主要問題不是 arm64 架構，而是與之相關的所有硬件驅動程序（特別是 SSD 和 GPU）。到目前為止，一些底層的東西得到了支持，但除了可以啟用硬件之外，沒有任何有用的結果。要想達到可以被人們使用的程度，還需要一些時間。
不僅僅是蘋果的硬件得到了改進——arm64 架構總體上也已經成長了很多，內核在服務器領域也更具競爭力了。不久前，arm64 在服務器領域的競爭力還很弱，但亞馬遜的 Graviton2 和安培的 Altra 處理器——都是基于改進后的 ARM Neoverse IP——比幾年前的產品要好很多。
我已經等了十多年都沒能等到一個可用的 ARM 機器，可能還要繼續等下去，但情況明顯比以前好了一些。
事實上，我很早之前就想要一臺 ARM 機器。當我還是個少年，我真正想要的是一臺 Acorn Archimedes，但可用性和價格讓我最終選擇了 Sinclair QL（M68008 處理器），然后幾年后換成了 i386。
所以，這個想法已經醞釀了幾十年。但到現在它們還沒有被廣泛使用，而且對于我來說，它們在價格和性能方面都不具競爭力。希望在不久的將來，這個想法能夠變成現實。
?重寫內核會做出的改變
Jeremy Andrews：內核中有什么東西需要進行完全的重寫才能達到最優的嗎？或者說，內核已經有 30 年的歷史了，知識、編程語言和硬件在這 30 年里發生了很大的變化：如果現在讓你從頭開始重寫，你會做出哪些改變？
Linus Torvalds：如果有必要的話我們會這么做的。我們真的很擅長重寫，那些本來會造成災難的東西很久以前就被我們重寫了。
我們有很多“兼容”層，不過它們一般不會造成太大問題。如果從頭開始重寫，這些兼容層是否要去掉，我們還不清楚——它們存在的目的是為了與舊二進制文件向后兼容（通常是與舊架構向后兼容，例如在 x86-64 上運行 32 位的 x86 應用程序）。因為我認為向后兼容是非常重要的，所以即使重寫，我也希望保留這些兼容層。
所以很明顯，有很多東西并不是最優的，畢竟任何東西都有改進的空間。但就你提的這個問題，我不得不說，我不鄙視任何東西。有一些遺留驅動程序，可能沒有人關心，也沒有人去清理，會做一些丑陋的事情，但這主要是因為“沒有人關心”。這些在過去不是問題，而一旦成為問題，我們就會積極把這些沒人關心的東西移除掉。多年來，我們已經移除了很多驅動程序，當維護不再有任何意義時，我們會放棄整個架構支持。
“重寫”的主要原因是：整個架構不再有意義，但仍然存在一些應用場景。最有可能的情況是，一些小型嵌入式系統并不需要 Linux 提供的所有東西，它們的硬件很小，需要的是更簡單、更少的系統功能。
Linux 已經有了長足的發展。現在，即使是小硬件（比如手機等）也比當初開發 Linux 所使用的機器強大得多。
?不會用 Rust 取代 C 語言來開發內核
Jeremy Andrews：如果用 Rust 來重寫一部分系統會怎樣？在這方面還有改進的余地嗎？在內核開發方面，你覺得是否有可能用另一種語言（比如 Rust）來取代 C 語言？
Linus Torvalds：我不認為我們會用 Rust 取代 C 語言來開發內核，但可能會用來開發一些驅動程序，也許是整個驅動子系統，也許是文件系統。所以不是“取代 C 語言”，而是“在一些有意義的地方擴展我們的 C 代碼”。
當然，驅動程序幾乎占了內核的一半代碼，有非常大的重寫空間，但我不認為所有人都會很期待使用 Rust 全盤重寫現有的驅動程序。可能“有些人會用 Rust 開發新驅動程序，或者適當地重寫一部分舊驅動程序”。
現在更多的是“人們在嘗試和體驗”Rust，僅此而已。Rust 優勢的背后肯定存在復雜性，所以我會采取觀望的態度，看看這些優勢是否真的奏效。
?內核中最令 Linux 之父自豪的部分
Jeremy Andrews：內核中是否有你個人感到最自豪的部分？
Linus Torvalds：我最想說的是 VFS 層（虛擬文件系統，特別是路徑名查找）和 VM。前者是因為 Linux 在做一些基礎任務（在操作系統中查找文件名確實是一個核心的操作）時比其他系統都要好得多，后者主要是因為我們支持 20 多種架構，但仍然在使用一個基本統一的 VM 層，我認為這一點很了不起。
但與此同時，這很大程度上取決于“你最關注內核的哪一部分”。內核很大，不同的開發者（和不同的用戶）會關注不同的方面。有些人認為調度是內核中最令人感到興奮的部分，有些人則關注設備驅動程序的細節（我們有很多這樣的驅動程序）。我個人在 VM 和 VFS 這兩個方面參與得更多，所以自然會提到它們。
?Linux 在這個方面比其他操作系統做得更好
Jeremy Andrews：我看了這個關于路徑名查找的描述（https://www.kernel.org/doc/html/latest/filesystems/path-lookup.html） ，它比我預想的要復雜。是什么讓 Linux 在這方面比其他操作系統做得更好？你說的“更好”是什么意思？
Linus Torvalds：路徑名查找是一個非常常見和基礎的任務，以至于大多數非內核開發者不認為它會是一個問題：他們只知道打開文件，并認為這是理所當然的。
但要做好其實是相當復雜的。確切地說，因為幾乎所有地方都在用路徑名查找，所以對性能要求很高，而且大家都希望它在 SMP 環境中具有良好的伸縮性，而在鎖定方面又很復雜。你不想發生 IO，那么緩存就非常重要。路徑名查找是如此的重要，以至于你不能把它留給底層的文件系統，因為我們有 20 多種不同的文件系統，讓它們各自擁有自己的緩存和鎖定機制將是一場徹頭徹尾的災難。
所以，VFS 層的一個主要任務是處理所有路徑名組件的鎖定和緩存問題，以及所有的序列化和掛載點遍歷問題，這些都是通過無鎖算法（RCU）來完成的，但也會有一些非常智能的鎖（Linux 內核的“lockref”鎖是一種非常特殊的“帶有引用計數的自旋鎖”，表面上看是為 dcache 緩存而設計的，但本質上是一個專門的鎖感知引用計數，可以在某些常見情況下消除鎖）。
最終結果是：底層文件系統仍然需要對未緩存的內容進行查找，但它們不需要關心緩存和一致性規則以及與路徑名查找相關的原子性規則。VFS 會為它們處理好所有這些問題。
而且它的性能比任何其他操作系統都要好，基本上可以在擁有數千個 CPU 的機器上完美運行。
所以不僅僅是“更好”，而是“大寫”的更好。沒有什么能與之相提并論的了。Linux dcache 是獨一無二的。
?新冠疫情對內核開發的影響
Jeremy Andrews：過去的一年對全世界來說是艱難的一年。新冠疫情對內核開發進程帶來了哪些影響？
Linus Torvalds：實際上，得益于我們一直以來的工作方式，它的影響非常小。電子郵件真的是一個很好的工具，我們并不依賴面對面的會議。
是的，它確實影響了去年的年度內核峰會（今年的峰會仍懸而未決），大多數會議被取消或轉為線上進行。以前在辦公室工作的人大都開始在家里工作（但很多核心內核維護者在之前已經這么做了）。所以，周圍的很多東西都發生了改變，但內核開發還是像以前一樣。
很顯然，新冠疫情在其他方面影響了我們所有人的生活，但總的來說，作為幾乎完全通過電子郵件進行交流的內核開發人員，我們可能是受影響最小的。
2
版本控制系統 Git
?對 Git 項目領導權主動放手
Jeremy Andrews：Linux 只是你對開源做出的眾多貢獻中的一個。在 2005 年，你還創建了 Git，一個非常流行的分布式源代碼控制系統。你快速地將 Linux 內核源代碼樹從專有的 Bitkeeper 遷移到開源的 Git 系統中，并在同年將維護工作移交給了 Junio Hamano。這里有很多有趣的故事，是什么原因促使你這么快就將項目的領導權移交了出來，你是如何找到并選擇了 Junio 的？
Linus Torvalds：答案可以分為兩個部分。
首先，我并不想創建一個新的源代碼控制系統。開發 Linux 是因為硬件和軟件之間的底層接口很吸引我——基本上是出于個人的熱愛和興趣。相反，開發 Git 是因為確實有這個需要：不是因為我覺得源代碼控制很有趣，而是因為我十分鄙視市面上的大多數源代碼控制系統。而我覺得最合適的、在 Linux 開發當中很好用的 BitKeeper 已經無法維持下去了。
我開發 Linux 已經超過 30 年了（距離第一個版本的周年紀念還有幾個月，但在 30 年前我就開始研究 Linux 的“前身”了），并且一直在維護它。但 Git 呢？我從來沒有想過我真的想要長期維護它。我喜歡用它，而且在某種程度上，我認為它是最好的 SCM，但它并不是我的興趣所在。
所以我總是希望別人來為我維護 SCM——事實上，如果當初我不用自己開發這個 SCM，我會很開心。
以上就是故事的背景。
至于 Junio，他實際上是最早加入 Git 開發隊伍的人員之一。他在我將 Git 的第一個非常粗糙的版本公開后的幾天內提交了第一次變更代碼，所以 Junio 在 Git 一開始就參與其中了。
但我之所以把項目交給 Junio，并不是因為他是第一批參與項目的人。在維護了 Git 幾個月之后，讓我決定將項目交給 Junio 維護者的真正原因是“好品味”——一個很難描述的概念。我真的想不到還有什么更好的描述：編程主要是為了解決技術問題，但如何解決這些問題以及如何思考也很重要。隨著時間的推移，你開始意識到：有些人就有這種“好品味”，他總能選擇正確的解決方案。
我不想將編程說成是一門藝術，因為它實際上主要是關于“好的工程”。我很喜歡托馬斯·愛迪生的那句“天才是百分之一的靈感加上百分之九十九的汗水”：編程涉及的幾乎都是細枝末節的東西和日常繁重的工作。但是，那百分之一的“靈感”，也就是“好品味”，不僅要解決問題，而且要干凈、漂亮地解決。
Junio 就有那種“好品味”。
每次提到 Git，我都想試著講清楚：我在一開始提出了 Git 的核心思想，并經常因為這部分工作而獲得太多榮譽。Git 的這 15 年，我也只是在第一年真正參與了項目。Junio 是一個優秀的維護者，是他讓 Git 變成現在的樣子。
順便說一下，關于“好品味”，以及找到擁有好品味的人，并信任他們——不僅僅 Git 是這樣，Linux 也是這樣。與 Git 不一樣的是，Linux 這個項目我仍然在積極維護，但與 Git 一樣的是，Linux 也是一個有很多人共同參與的項目。我認為，Linux 的一大成功是它擁有數百名維護者，他們都具備了“好品味”，并維護著內核的不同部分。
?項目維護并非“非黑即白”
Jeremy Andrews：你有沒有過這樣的經歷：把控制權交給維護者，然后發現這是一個錯誤的決定？
Linus Torvalds：我們的維護體系從來就不是非黑即白的，所以不會出現這種情況。事實上，我們甚至沒有將維護權正式記錄下來：我們確實有一個 MAINTAINERS 文件，但那只是為了讓你在遇到問題時能夠找到對的人，并不是某種排他所有權的標志。
所以，“誰負責什么東西”更像是一種流動的指南，以及“這個人很活躍，工作做得很好”，而不是“我們把所有權給了那個人，然后他搞砸了”。
從某種意義上說，我們的維護體系也是流動的。假設你是某個子系統的維護者，如果你需要另一個子系統的東西，是可以跨界的。通常人們在這樣做之前都會進行廣泛的溝通，而且這種事情確實發生了。這并不是“你只能動這個文件”之類的硬性規定。
實際上，這與前面討論的有關許可的事情有些聯系。“Git”的另一個設計原則是“每個人都有自己的代碼樹，但沒有哪一個代碼樹是特殊的”。
因為很多其他項目都使用了工具——比如 CVS 或 SVN——這些工具會讓一些人變得“特殊”，賦予了他們某種“所有權”。在 BSD 世界里，他們稱之為“commit bit”：給一個維護者“commit bit”意味著他可以將代碼提交到中央代碼庫。
我一直很討厭這種模式，因為它會不可避免地導致政治“小團體”的出現。在這種模式下，總有一些人是特殊、隱性受信任的。問題的關鍵甚至不在于“隱性受信任”，而在于硬幣的另一面——其他人不被信任，他們被定義成局外人，必須受制于監護者。
同樣，在 Git 開發中也不存在這種情況。每個人都是平等的，任何人都可以克隆代碼，做自己的開發，做好了，就可以合并回來。
所以，沒有必要給人們特權，也不需要“commit bit”。這樣就可以避免出現政治“小團體”，也不需要“隱性信任”。如果他們做得不好——或者更常見的是，最終消失了，并轉向了另一個興趣——他們的代碼就不會被合并回來，也不會阻礙其他有新想法的人。
?對 Git 特性的看法
Jeremy Andrews：Git 有沒有哪些新特性讓你印象深刻，并成為你工作流的一部分？還有哪些特性是你想要增加的？
Linus Torvalds：我對 Git 的需求總是最早得到滿足的，所以，對于我來說，Git 沒有“新”特性。
這些年來，Git 確實有很大的改進，有一些在我的工作流中已經體現出來了。例如，Git 的速度一直都很快——畢竟這是我的設計目標之一——但它的大部分特性最初是圍繞 shell 腳本而構建的。多年來，大多數 shell 腳本都已經消失了，這意味著我可以比原來更快地應用 Andrew Morton 的補丁。這一點令人感到欣慰，因為這實際上是我早期用于性能測試的基準之一。
所以，Git 對我來說一直都很好，而且變得越來越好。
Git 最大的改進在于“普通用戶”的使用體驗變得更好了。一部分原因是人們在學習 Git 工作流的過程中逐漸習慣了它，但更多的是因為 Git 本身變得更易于使用。
6 個“嚇人”的 Linux 命令
10 本最佳 Linux、UNIX 編程書籍
Linux 新手入門的一些基本知識點整理
下載！《鳥哥 Linux 私房菜》PDF
Linux 開發過程那么麻煩，是否值得？
點個在看少個 bug ????
總結
以上是生活随笔為你收集整理的30 周年，Linux 成功的真正原因是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 被国人误传了数千年的七句话(转自天涯)
- 下一篇： Ubuntu（乌班图），初学Linux的