Linux之父表示不會用Rust取代C語言開發(fā)內(nèi)核

“Linux 誕生于 1991 年，距今已經(jīng) 30 年了。雖然它一開始只是 Linus 的一個個人項目，而非出于要開發(fā)一個新操作系統(tǒng)的偉大夢想，但如今的 Linux 早已無處不在。

30 年前，當 Linus Torvalds 第一次發(fā)布 Linux 內(nèi)核時，他還是赫爾辛基大學的一名 21 歲的學生。他宣布說：“我正在開發(fā)一個（免費的）操作系統(tǒng)（這只是個愛好，不會做得很大，也不會很專業(yè)……）”。30 年后，500 強超級計算機和 70% 以上的智能手機都在運行 Linux。很顯然，Linux 不僅大，而且很專業(yè)。

30 年來，Linus Torvalds 一直在領(lǐng)導著 Linux 內(nèi)核的開發(fā)，啟發(fā)了無數(shù)開發(fā)者和開源項目。2005 年，Linus 開發(fā)了 Git，用來管理內(nèi)核開發(fā)過程。Git 現(xiàn)在已經(jīng)成為最流行的版本控制系統(tǒng)，受到無數(shù)開源和私有項目的信任。

正值 Linux 誕生 30 周年之際，Linus Torvalds 通過電子郵件回復了 Tag 1 咨詢公司的創(chuàng)始合伙人/首席執(zhí)行官 Jeremy Andrews 的訪談問題（《An Interview With Linus Torvalds： Linux and Git - Part 1》），回顧并總結(jié)了過去這些年他在領(lǐng)導大型開源項目過程中得到的真知灼見。本文著重介紹 Linux 內(nèi)核開發(fā)和 Git。InfoQ 對訪談內(nèi)容進行了翻譯，以饗讀者。

Linux 內(nèi)核開發(fā)

Jeremy Andrews：Linux 無處不在，它是整個開源世界的靈感源泉。當然，事情并不是從一開始就這樣的。1991 年，你在 comp.os.minix Usenet 新聞組中發(fā)布了一個 Linux 內(nèi)核。十年后，你寫了一本書，叫作“Just for Fun： The Story of an Accidental Revolutionary”（中譯名：《只是為了好玩：Linux 之父林納斯自傳》），對那段歷史進行了深度回顧。今年 8 月，Linux 將迎來它的 30 周年紀念日！在這個過程中，你是在什么時候開始意識到 Linux 并不僅僅是一個“愛好”的？

Linus Torvalds： 這聽起來可能有點荒謬，實際上我很早就開始意識到了。在 1991 年末（以及 1992 年初），Linux 已經(jīng)比我預(yù)想的要大得多。

那時候可能只有幾百個用戶（確切地說不是“用戶”，因為人們還要不斷地對它進行修修補補），從沒想過 Linux 后來能夠發(fā)展壯大。在我看來，最大的轉(zhuǎn)折點是當我意識到其他人正在使用它，并對它感興趣，它開始有了自己的生命。人們開始發(fā)送補丁，這個系統(tǒng)能做的事情比我最初預(yù)想的要多得多。

1992 年 4 月的某個時候，X11 被移植到 Linux 上（其實我也記不太清具體時間了，畢竟那是很久以前的事了），這是一個重大進步，Linux 系統(tǒng)突然間有了 GUI 和一系列全新的功能。

我一開始并沒有什么大計劃。這只是一個個人項目，并不是出于要開發(fā)一個新操作系統(tǒng)的偉大夢想。我當時只是想了解我的新 PC 硬件的來龍去脈。

所以，在發(fā)布第一個版本時，實際上更多的是想“看看自己都做了些什么”。當然，我希望其他人會覺得它有趣，但它并不是一個真正可用的操作系統(tǒng)。它更多的是一種概念驗證，而且只是一個我在當時做了幾個月的個人項目。

從“個人項目”到其他人開始使用它、給我反饋（和 bug 報告）和發(fā)送補丁，對我來說是一個巨大的轉(zhuǎn)變。

舉個最基本的例子：最初的版權(quán)許可是“你可以以源代碼的形式發(fā)布它，但不能用它賺錢”。

對于當時的我來說，商業(yè)版 Unix 太貴了（作為窮學生，我已經(jīng)為了買新 PC 花光了所有錢），所以我希望這個操作系統(tǒng)的源代碼是公開可用的（這樣人們就可以提供補丁），我希望將它開放給像我這樣負擔不起昂貴電腦和操作系統(tǒng)的人。

1991 年末（或是 1992 年初），我把許可改為 GPLv2，因為有人想把它以軟盤的形式分發(fā)給本地 Unix 用戶組，但又想收回軟盤的成本，并補償他們拷貝軟盤所花費的時間。我覺得這很合理，因為“免費”與否并不是最重要的，最重要的是要“公開源碼”。最終的結(jié)果是：人們不僅在 Unix 用戶組中發(fā)布它，在幾個月之內(nèi)還出現(xiàn)了 SLS 和 Slackware 的軟盤發(fā)行版。

與最初的那些根本性的變化相比，后來的一切都是“增量式”的。當然，有些增量式的變化也是大跨步（IBM 的加入、Oracle 數(shù)據(jù)庫的移植、Red Hat 的首次公開募股，Android 在手機上的應(yīng)用，等等），但在我看來，它們?nèi)匀徊蝗缱畛醯摹拔也徽J識的人都在使用 Linux”那樣具有革命性。

Jeremy Andrews：你是否曾經(jīng)后悔修改了許可協(xié)議？或者說，其他人或公司用你開發(fā)的系統(tǒng)賺了很多錢，你因此感到后悔嗎？

Linus Torvalds： 我從來沒有后悔過。

首先，我過得還不錯。我不是特別富有，但我是一個薪水很高的軟件工程師，可以按照自己的節(jié)奏做我喜歡做的事情。關(guān)鍵是我百分之百認為這個許可是 Linux（以及 Git）取得成功的重要原因。我認為，當所有人都認為他們有平等的權(quán)利，沒有人在這方面有特權(quán)的時候，他們才會變得更快樂。有很多項目采用了“雙重許可”，一方面，原作者保留了商業(yè)許可（“只要你支付了許可費用，就可以使用它”），另一方面，項目也可以在 GPL 許可下開源。

我認為要在這種情況下建立好的社區(qū)是非常困難的，因為開源那一方知道自己是“二等公民”。另外，為了讓享有特權(quán)的那一方一直享有特殊的權(quán)利，需要做很多許可文書工作，這給項目帶來了額外的阻力。

另一方面，我見過很多基于 BSD（或 MIT 等類似的許可）許可的開源項目，當它們變得足夠強大，大到具備商業(yè)價值時，它們就開始分裂，相關(guān)的公司不可避免地會將自己的那部分變成專有的。

我認為 GPLv2 能夠在“每個人都處于相同的規(guī)則之下”和“要求人們回饋社區(qū)”之間取得完美的平衡。每個人都知道，所有參與者都受到相同的規(guī)則的約束，所以這是非常公平的。

當然，你的投入總會得到回報。如果你只是想輕度參與項目，或者只是想作為一名用戶，那也是可以的。如果你真的只是這樣，就也無法控制這個項目。如果你真的只需要一個基本的操作系統(tǒng)，而 Linux 已經(jīng)具備你想要的所有功能，那也完全沒有問題。但如果你有特殊的需求，想要為這個項目做一點事情，那么唯一的方法就是參與其中。

這讓每個人都秉持誠實的態(tài)度，包括我在內(nèi)。任何人都可以 fork 這個項目，用他們自己的方式，然后說“再見了，Linus，我要維護自己的 Linux 版本”。我之所以“特別”，僅僅是因為人們相信我能把工作做好。

“任何人都可以維護自己的 Linux 版本”，這讓一些人對 GPLv2 產(chǎn)生了懷疑，但我認為這是一種優(yōu)勢，而不是劣勢。我認為，這實際上是避免 Linux 出現(xiàn)分裂的原因：每個人都可以創(chuàng)建自己的項目分支。事實上，這也是“Git”的核心設(shè)計原則之一——代碼庫的每一個克隆都是一個分支，人們（和公司）再 fork 出自己的版本，完成開發(fā)工作。

所以，分支不是問題，只要你能把好的部分合并回來。這就是 GPLv2 發(fā)揮作用的地方。能夠拉取分支，并按照自己的方式修改代碼，擁有這些權(quán)利很重要，但另一方面也同樣重要——當一個分支被證明取得了成功，有權(quán)利把它合并回去。

另一個問題是，除了要有支持這種工作流的工具，也要有可以支持它的心態(tài)。合并分支的一大障礙不僅是許可問題，還有“嫌隙”問題。如果分支是源于對立，那么要合并兩個分支就非常困難——不是因為許可或技術(shù)方面的原因，而是因為分支之間太過對立。我認為 Linux 避免了這種情況的發(fā)生，主要是因為我們一直認為分支是一件很自然的事情。而且，當一些開發(fā)工作被證明取得了成功，嘗試將其合并回來也是很自然的。

雖然這個答案有點偏離正題，但我認為它很重要——我不后悔修改了許可，因為我真的認為 GPLv2 是 Linux 取得成功的一個重要原因。

金錢不是一種很好的激勵方式，它無法讓人們團結(jié)在一起。我認為，參與一個共同的項目，并感覺到自己可以成為這個項目的合作伙伴，這樣才能激勵人們。

Jeremy Andrews：現(xiàn)在，人們基于 GPLv2 發(fā)布源代碼通常是因為 Linux。你當時是怎么找到這個許可的？你在調(diào)研其他許可方面又投入了多少時間和精力呢？

Linus Torvalds： 那個時候，有關(guān) BSD 和 GPL 的爭論非常激烈。我在閱讀各種新聞組（比如 comp.arch、comp.os.minix 等）時看到了一些有關(guān)許可的討論。

其中兩個最主要的原因可能是 gcc 和 Lars Wirzenius。gcc 對 Linux 的發(fā)展起到了很大作用，因為我肯定需要一個 C 語言編譯器。Lars Wirzenius 是我在念大學時另一個說瑞典語（瑞典語在芬蘭是小語種）的計算機系學生。

Lasu 比我更喜歡討論與許可相關(guān)的事情。

在我看來，選擇 GPLv2 并不算是什么重大的政治問題，主要是因為我最初在選擇許可時太過倉促，后來需要做出修改。況且，我很感恩有 gcc，并且 GPLv2 更符合我對“你必須把源代碼合并回來”這種想法的期望。

因此，與其另起爐灶新建一個許可，不如選擇一個人們已經(jīng)知道并且有一些律師參與其中的許可。

Jeremy Andrews：通常情況下，你的一天是怎么過的？其中有多少時間花在寫代碼上，多少花在評審代碼上，多少花在電子郵件上？你如何平衡個人生活和 Linux 內(nèi)核開發(fā)工作？

Linus Torvalds： 我現(xiàn)在寫的代碼很少，而且已經(jīng)很久沒寫了。再要寫代碼，通常是因為人們對某些特定的問題存在爭議。我修改代碼，并將其作為補丁發(fā)布出去，作為對解決方案的解釋說明。

換句話說，我寫的大部分代碼更多的是作為解決方案的示例，而補丁是一種非常具體的例子。人們很容易陷入理論討論的陷阱，而我發(fā)現(xiàn)描述解決方案最好的方式是寫代碼片段，不一定要完整的程序，只要讓解決方案具體化一些即可。

我的工作時間都花在電子郵件上了。主要是溝通，而不是寫代碼。事實上，我認為這種與記者和技術(shù)博主之間的交流就是我工作的一部分——它可能比技術(shù)討論優(yōu)先級低一些，但我也花了相當多的時間在這類事情上。

當然，我也會花一些時間在代碼評審上。但老實說，當我收到一個 PR 時，有問題的代碼通常已經(jīng)被其他人評審過了。所以，雖然我仍然會看一下補丁，但實際上會更多地去關(guān)注注解，以及補丁的演化過程。但對于那些與我共事很久的人，我不會這么做：他們是自己子系統(tǒng)的維護者，我不需要對他們的工作指手畫腳。

所以，很多時候，我的主要工作就是“待在那里”，執(zhí)行管理和發(fā)布任務(wù)。換句話說，我的工作通常更多地是關(guān)于維護過程，而不是底層代碼。

Jeremy Andrews：你的工作環(huán)境是怎樣的？比如，你是喜歡黑暗、不會受人打擾的房間，還是喜歡能看到風景的房間？你喜歡在安靜的環(huán)境下工作，還是喜歡一邊聽音樂一邊工作？你通常使用哪種硬件？你是在終端上使用 vi 來評審代碼，還是使用某種奇特的 IDE？你是否有偏愛的 Linux 發(fā)行版作為開發(fā)環(huán)境？

Linus Torvalds： 我的房間并不“暗”，但我確實把桌子旁邊窗戶上的百葉窗關(guān)上了，因為我不想要強烈的陽光。所以，我的房間沒有什么風景視野，只有一張（凌亂的）桌子，配了兩個 4k 顯示器，桌子下面有一臺強勁的電腦主機。還有幾臺筆記本電腦供我測試和在路上用。

我喜歡安靜地工作。我很討厭機械硬盤的滴答聲，所以我把它們?nèi)舆M了垃圾桶，現(xiàn)在只使用 SSD。這樣已經(jīng) 10 多年了。嘈雜的 CPU 風扇聲也是不可接受的。

代碼評審都是在傳統(tǒng)的終端上完成的，不過我沒有使用 vi。我使用的是“micro-emacs”這個令人討厭的東西。它與 GNU emacs 完全沒有關(guān)系，只是有些鍵綁定與它相似。我在赫爾辛基大學時就習慣用它了，到現(xiàn)在還沒改掉這個習慣。幾年前，我給它增加了（非常有限的）utf-8 支持，但它確實很老舊了，所有的跡象都表明它是在 80 年代開發(fā)的，我使用的版本是一個自 90 年代中期以來就沒有更新過的分支。

赫爾辛基大學選擇了這個工具，因為它可以在 DOS、VAX/VMS 和 Unix 上運行，這也是為什么我也會用它。到現(xiàn)在，我的手指已經(jīng)對它形成肌肉記憶了。我真的需要換個有人維護并支持 utf-8 的工具，只是我增強的那部分功能用起來還好，所以一直沒有強迫我的手指去接受新的工具。

我的工作桌面相當簡單：幾個文本終端，一個打開了電子郵箱的瀏覽器（還打開了其他幾個標簽，主要是新聞和科技網(wǎng)站）。我喜歡大的桌面空間，因為我習慣使用大終端窗口（100x40 是我的默認初始大?。?，并且并排打開好幾個。我使用了兩個 4k 顯示器。我在所有的機器上都安裝了 Fedora 發(fā)行版，并不是因為我偏愛它，而是因為我習慣了。我并不太關(guān)心使用哪個發(fā)行版——對于我來說，選擇發(fā)行版只是在機器上安裝 Linux 和開發(fā)工具的一種方式。

Jeremy Andrews：Linux 內(nèi)核郵件組（https://lore.kernel.org/lkml/）是人們公開交流內(nèi)核開發(fā)的地方，流量非常高。你是怎么處理這么多電子郵件的？你嘗試過郵件組之外的其他協(xié)作和溝通解決方案嗎？或者說，這種簡單的郵件組對你的工作來說足夠好嗎？

Linus Torvalds： 我沒有直接閱讀內(nèi)核郵件組里的郵件，而且好幾年都沒有。郵件太多了。

內(nèi)核郵件組里的郵件會被抄送到所有的討論當中。當新人加入討論時，他們可以通過查看內(nèi)核郵件組來了解相關(guān)的歷史和背景。

過去我會訂閱郵件組，讓所有沒有抄送給我的電子郵件自動歸檔，默認不看它們。當一些問題需要我介入時，我可以找到所有相關(guān)的討論，因為它們都在我的電子郵件里，只是在需要時才會出現(xiàn)在我的收件箱里。

現(xiàn)在，我使用的是 lore.kernel.org 提供的功能，因為它很好用，而且我們還基于它開發(fā)了一些工具。這樣就不需要讓郵件自動歸檔了，我們換了一種討論方式，但基本的工作流程是一樣的。

但很顯然，我仍然會收到很多郵件——但從很多方面來看，這些年來情況變得越來越好，而不是越來越糟。其中很大一部分原因是 Git 和內(nèi)核發(fā)布流程的改進：我們過去在代碼流程和工具方面存在很多問題。在本世紀初是最為糟糕的，當時我們?nèi)匀辉谔幚砭薮蟮难a丁炸彈，我們的開發(fā)流程存在嚴重的可伸縮性問題。

郵件組模式確實運作得很好，但并不是說人們就不使用除電子郵件之外的其他溝通方式了：有些人喜歡各種實時聊天工具（比如傳統(tǒng)的 IRC）。雖然我不是很喜歡這樣，但很顯然有些人喜歡用它們來進行頭腦風暴。但這種“郵件組存檔”模式運作得非常好，并且能夠無縫地與“開發(fā)者之間以郵件的形式發(fā)送補丁”和“以郵件的形式發(fā)送問題報告”相結(jié)合。

所以電子郵件仍然是主要的溝通渠道，并且因為郵件中可以包含補丁，我們可以更容易地討論技術(shù)問題。而且郵件可以跨越時區(qū)，當參與者分布在不同地區(qū)時，這一點非常重要。

Jeremy Andrews：我密切關(guān)注內(nèi)核開發(fā)大約有 10 年了，并在 KernelTrap 上寫與內(nèi)核有關(guān)的博文，大概是在 3.0 內(nèi)核發(fā)布時停止更新博客。3.0 內(nèi)核的發(fā)布與 2.6.x 內(nèi)核的發(fā)布相隔了 8 年。請總結(jié)一下自 3.0 版本以來內(nèi)核開發(fā)中發(fā)生的一些有趣的事情。

Linus Torvalds： 那是很久以前的事了，我不知道該從哪里開始總結(jié)。從 3.0 版本到現(xiàn)在已經(jīng) 10 年了，在這 10 年中發(fā)生了很多技術(shù)上的變化。ARM 已經(jīng)發(fā)展成熟，ARM64 已經(jīng)成為我們的主要架構(gòu)之一，并出現(xiàn)了大量新的驅(qū)動程序和核心功能。

如果說過去 10 年有什么有趣的事情，那一定是我們努力保持開發(fā)模式的穩(wěn)定，以及那些沒有發(fā)生改變的東西。

在過去的幾十年里，我們經(jīng)歷了多種不同的版本號方案和不同的開發(fā)模式，3.0 版本最終確定了后來一直使用的模式。它讓“基于時間發(fā)布，版本號只是數(shù)字，與特性無關(guān)”這一說法落地了。

在 2.6.x 版本中，我們就有了基于時間的發(fā)布模式，所以它并不是什么新東西，但 3.0 版本確實是讓這種模式板上釘釘?shù)闹陵P(guān)重要的一步。

我們以前使用隨機編號方案（主要是在 1.0 版本之前），然后用“奇數(shù)表示開發(fā)版內(nèi)核，偶數(shù)表示穩(wěn)定的生產(chǎn)就緒版內(nèi)核”，然后在 2.6.x 版本中，我們開始進入基于時間的發(fā)布模式。但人們?nèi)匀粚Α笆裁磿r候需要增加主版本號”存在疑問。3.0 版本正式發(fā)布后，宣告了主版本號沒有任何意義，我們盡量簡化數(shù)字，不要讓它們變得太大。

因此，在過去的 10 年里，我們做了巨大的改變（有了 Git，就可以很容易地得到一些數(shù)字統(tǒng)計數(shù)據(jù)：超過 1.7 萬人提交了大約 75 萬次代碼），但開發(fā)模式仍然相當穩(wěn)定。

但并非一直都是這樣的，內(nèi)核開發(fā)的前 20 年經(jīng)歷了相當痛苦的開發(fā)模式變更，只是在過去 10 年中，發(fā)布可預(yù)測性才得到大幅提升。

Jeremy Andrews：目前，最新的版本是 5.12-rc5?，F(xiàn)在的發(fā)布流程標準是怎樣的？例如，-rc1 和 -rc2 有什么不同？你會在什么情況下決定正式發(fā)布其中一個給定的版本？如果在正式發(fā)布之后出現(xiàn)了大量的回歸會怎樣？這種情況發(fā)生的頻率是怎樣的？這些年來，這個過程是如何演變的？

Linus Torvalds： 我之前提到過，這個過程本身是很標準的，并且在過去十年里一直如此。在此之前，它經(jīng)歷了幾次演變，但實際上從 3.0 開始它就像時鐘一樣走得很穩(wěn)定。

到現(xiàn)在為止，我們的發(fā)布節(jié)奏是這樣的：先是兩周的合并時間窗口，然后是大約 6 到 8 周的候選版本，然后是最終版本。這樣子差不多 15 年了。

規(guī)則一直都是一樣的，盡管它們并不總是被完全嚴格執(zhí)行：合并時間窗口是針對那些被認為已經(jīng)“經(jīng)過測試和準備就緒”的新代碼，然后在接下來的大約兩個月里進行修復，以確保所有的問題都得到解決。有時候，那些所謂的“就緒”代碼會在發(fā)布之前會被禁用或完全推翻。

這個過程會重復，所以我們大約每 10 周發(fā)布一次。

達到可以發(fā)布的標準是我對候選版本有足夠的信心，而這是以各種問題報告為基礎(chǔ)的。如果某些方面在 rc 后期仍然會出問題，我就極力推翻這些內(nèi)容，并建議將其放在后續(xù)的版本中。但總體而言，很少會出現(xiàn)這種情況。

這樣就完全沒有問題了嗎？不是的。一旦內(nèi)核發(fā)布了，就會有新用戶，他們會發(fā)現(xiàn)一些在 rc 版本中沒有被發(fā)現(xiàn)的問題。這幾乎是不可避免的。這也是為什么我們需要“穩(wěn)定內(nèi)核”樹。在發(fā)布之后，我們可以繼續(xù)修復代碼。一些穩(wěn)定內(nèi)核比其他版本內(nèi)核維護的時間更長，被稱為 LTS（“Long Term Support”）版本。

所有這些在過去十年里都沒有什么變化，盡管后來有了更多的自動化流程。一般來說，內(nèi)核測試自動化是很困難的——因為很多內(nèi)核是驅(qū)動程序，十分依賴硬件的可用性。不過，我們有幾個測試場同時進行引導和性能測試，以及各種隨機負載測試。這些在這幾年有了很大的改善。

Jeremy Andrews：去年 11 月，有人說你對蘋果公司在部分新款電腦中使用的 ARM64 芯片十分感興趣。Linux 會支持它們嗎？我看到一些代碼被合并到 for-next。即將到來的 5.13 內(nèi)核有可能在蘋果 MacBook 上啟動嗎？你有可能是它的早期采用者嗎？ARM64 有什么重大的意義？

Linus Torvalds： 我偶爾會跟進一下，但現(xiàn)在說這些還為時過早。正如你所說的，早期支持可能會被合并到 5.13 中，但這只是一個開始，并不能說明 Linux 和蘋果電腦將來會怎樣。

主要問題不是 arm64 架構(gòu)，而是與之相關(guān)的所有硬件驅(qū)動程序（特別是 SSD 和 GPU）。到目前為止，一些底層的東西得到了支持，但除了可以啟用硬件之外，沒有任何有用的結(jié)果。要想達到可以被人們使用的程度，還需要一些時間。

不僅僅是蘋果的硬件得到了改進——arm64 架構(gòu)總體上也已經(jīng)成長了很多，內(nèi)核在服務(wù)器領(lǐng)域也更具競爭力了。不久前，arm64 在服務(wù)器領(lǐng)域的競爭力還很弱，但亞馬遜的 Graviton2 和安培的 Altra 處理器——都是基于改進后的 ARM Neoverse IP——比幾年前的產(chǎn)品要好很多。

我已經(jīng)等了十多年都沒能等到一個可用的 ARM 機器，可能還要繼續(xù)等下去，但情況明顯比以前好了一些。

事實上，我很早之前就想要一臺 ARM 機器。當我還是個少年，我真正想要的是一臺 Acorn Archimedes，但可用性和價格讓我最終選擇了 Sinclair QL（M68008 處理器），然后幾年后換成了 i386。

所以，這個想法已經(jīng)醞釀了幾十年。但到現(xiàn)在它們還沒有被廣泛使用，而且對于我來說，它們在價格和性能方面都不具競爭力。希望在不久的將來，這個想法能夠變成現(xiàn)實。

Jeremy Andrews：內(nèi)核中有什么東西需要進行完全的重寫才能達到最優(yōu)的嗎？或者說，內(nèi)核已經(jīng)有 30 年的歷史了，知識、編程語言和硬件在這 30 年里發(fā)生了很大的變化：如果現(xiàn)在讓你從頭開始重寫，你會做出哪些改變？

Linus Torvalds： 如果有必要的話我們會這么做的。我們真的很擅長重寫，那些本來會造成災(zāi)難的東西很久以前就被我們重寫了。

我們有很多“兼容”層，不過它們一般不會造成太大問題。如果從頭開始重寫，這些兼容層是否要去掉，我們還不清楚——它們存在的目的是為了與舊二進制文件向后兼容（通常是與舊架構(gòu)向后兼容，例如在 x86-64 上運行 32 位的 x86 應(yīng)用程序）。因為我認為向后兼容是非常重要的，所以即使重寫，我也希望保留這些兼容層。

所以很明顯，有很多東西并不是最優(yōu)的，畢竟任何東西都有改進的空間。但就你提的這個問題，我不得不說，我不鄙視任何東西。有一些遺留驅(qū)動程序，可能沒有人關(guān)心，也沒有人去清理，會做一些丑陋的事情，但這主要是因為“沒有人關(guān)心”。這些在過去不是問題，而一旦成為問題，我們就會積極把這些沒人關(guān)心的東西移除掉。多年來，我們已經(jīng)移除了很多驅(qū)動程序，當維護不再有任何意義時，我們會放棄整個架構(gòu)支持。

“重寫”的主要原因是：整個架構(gòu)不再有意義，但仍然存在一些應(yīng)用場景。最有可能的情況是，一些小型嵌入式系統(tǒng)并不需要 Linux 提供的所有東西，它們的硬件很小，需要的是更簡單、更少的系統(tǒng)功能。

Linux 已經(jīng)有了長足的發(fā)展?，F(xiàn)在，即使是小硬件（比如手機等）也比當初開發(fā) Linux 所使用的機器強大得多。

Jeremy Andrews：如果用 Rust 來重寫一部分系統(tǒng)會怎樣？在這方面還有改進的余地嗎？在內(nèi)核開發(fā)方面，你覺得是否有可能用另一種語言（比如 Rust）來取代 C 語言？

Linus Torvalds： 我不認為我們會用 Rust 取代 C 語言來開發(fā)內(nèi)核，但可能會用來開發(fā)一些驅(qū)動程序，也許是整個驅(qū)動子系統(tǒng)，也許是文件系統(tǒng)。所以不是“取代 C 語言”，而是“在一些有意義的地方擴展我們的 C 代碼”。

當然，驅(qū)動程序幾乎占了內(nèi)核的一半代碼，有非常大的重寫空間，但我不認為所有人都會很期待使用 Rust 全盤重寫現(xiàn)有的驅(qū)動程序。可能“有些人會用 Rust 開發(fā)新驅(qū)動程序，或者適當?shù)刂貙懸徊糠峙f驅(qū)動程序”。

現(xiàn)在更多的是“人們在嘗試和體驗”Rust，僅此而已。Rust 優(yōu)勢的背后肯定存在復雜性，所以我會采取觀望的態(tài)度，看看這些優(yōu)勢是否真的奏效。

Jeremy Andrews：內(nèi)核中是否有你個人感到最自豪的部分？

Linus Torvalds： 我最想說的是 VFS 層（虛擬文件系統(tǒng)，特別是路徑名查找）和 VM。前者是因為 Linux 在做一些基礎(chǔ)任務(wù)（在操作系統(tǒng)中查找文件名確實是一個核心的操作）時比其他系統(tǒng)都要好得多，后者主要是因為我們支持 20 多種架構(gòu)，但仍然在使用一個基本統(tǒng)一的 VM 層，我認為這一點很了不起。

但與此同時，這很大程度上取決于“你最關(guān)注內(nèi)核的哪一部分”。內(nèi)核很大，不同的開發(fā)者（和不同的用戶）會關(guān)注不同的方面。有些人認為調(diào)度是內(nèi)核中最令人感到興奮的部分，有些人則關(guān)注設(shè)備驅(qū)動程序的細節(jié)（我們有很多這樣的驅(qū)動程序）。我個人在 VM 和 VFS 這兩個方面參與得更多，所以自然會提到它們。

Jeremy Andrews：我看了這個關(guān)于路徑名查找的描述（https://www.kernel.org/doc/html/latest/filesystems/path-lookup.html），它比我預(yù)想的要復雜。是什么讓 Linux 在這方面比其他操作系統(tǒng)做得更好？你說的“更好”是什么意思？

Linus Torvalds： 路徑名查找是一個非常常見和基礎(chǔ)的任務(wù)，以至于大多數(shù)非內(nèi)核開發(fā)者不認為它會是一個問題：他們只知道打開文件，并認為這是理所當然的。

但要做好其實是相當復雜的。確切地說，因為幾乎所有地方都在用路徑名查找，所以對性能要求很高，而且大家都希望它在 SMP 環(huán)境中具有良好的伸縮性，而在鎖定方面又很復雜。你不想發(fā)生 IO，那么緩存就非常重要。路徑名查找是如此的重要，以至于你不能把它留給底層的文件系統(tǒng)，因為我們有 20 多種不同的文件系統(tǒng)，讓它們各自擁有自己的緩存和鎖定機制將是一場徹頭徹尾的災(zāi)難。

所以，VFS 層的一個主要任務(wù)是處理所有路徑名組件的鎖定和緩存問題，以及所有的序列化和掛載點遍歷問題，這些都是通過無鎖算法（RCU）來完成的，但也會有一些非常智能的鎖（Linux 內(nèi)核的“l(fā)ockref”鎖是一種非常特殊的“帶有引用計數(shù)的自旋鎖”，表面上看是為 dcache 緩存而設(shè)計的，但本質(zhì)上是一個專門的鎖感知引用計數(shù)，可以在某些常見情況下消除鎖）。

最終結(jié)果是：底層文件系統(tǒng)仍然需要對未緩存的內(nèi)容進行查找，但它們不需要關(guān)心緩存和一致性規(guī)則以及與路徑名查找相關(guān)的原子性規(guī)則。VFS 會為它們處理好所有這些問題。而且它的性能比任何其他操作系統(tǒng)都要好，基本上可以在擁有數(shù)千個 CPU 的機器上完美運行。

所以不僅僅是“更好”，而是“大寫”的更好。沒有什么能與之相提并論的了。Linux dcache 是獨一無二的。

Jeremy Andrews：過去的一年對全世界來說是艱難的一年。新冠疫情對內(nèi)核開發(fā)進程帶來了哪些影響？

Linus Torvalds： 實際上，得益于我們一直以來的工作方式，它的影響非常小。電子郵件真的是一個很好的工具，我們并不依賴面對面的會議。

是的，它確實影響了去年的年度內(nèi)核峰會（今年的峰會仍懸而未決），大多數(shù)會議被取消或轉(zhuǎn)為線上進行。以前在辦公室工作的人大都開始在家里工作（但很多核心內(nèi)核維護者在之前已經(jīng)這么做了）。所以，周圍的很多東西都發(fā)生了改變，但內(nèi)核開發(fā)還是像以前一樣。

很顯然，新冠疫情在其他方面影響了我們所有人的生活，但總的來說，作為幾乎完全通過電子郵件進行交流的內(nèi)核開發(fā)人員，我們可能是受影響最小的。

版本控制系統(tǒng) Git

Jeremy Andrews：Linux 只是你對開源做出的眾多貢獻中的一個。在 2005 年，你還創(chuàng)建了 Git，一個非常流行的分布式源代碼控制系統(tǒng)。你快速地將 Linux 內(nèi)核源代碼樹從專有的 Bitkeeper 遷移到開源的 Git 系統(tǒng)中，并在同年將維護工作移交給了 Junio Hamano。這里有很多有趣的故事，是什么原因促使你這么快就將項目的領(lǐng)導權(quán)移交了出來，你是如何找到并選擇了 Junio 的？

Linus Torvalds： 答案可以分為兩個部分。

首先，我并不想創(chuàng)建一個新的源代碼控制系統(tǒng)。開發(fā) Linux 是因為硬件和軟件之間的底層接口很吸引我——基本上是出于個人的熱愛和興趣。相反，開發(fā) Git 是因為確實有這個需要：不是因為我覺得源代碼控制很有趣，而是因為我十分鄙視市面上的大多數(shù)源代碼控制系統(tǒng)。而我覺得最合適的、在 Linux 開發(fā)當中很好用的 BitKeeper 已經(jīng)無法維持下去了。

我開發(fā) Linux 已經(jīng)超過 30 年了（距離第一個版本的周年紀念還有幾個月，但在 30 年前我就開始研究 Linux 的“前身”了），并且一直在維護它。但 Git 呢？我從來沒有想過我真的想要長期維護它。我喜歡用它，而且在某種程度上，我認為它是最好的 SCM，但它并不是我的興趣所在。

所以我總是希望別人來為我維護 SCM——事實上，如果當初我不用自己開發(fā)這個 SCM，我會很開心。

以上就是故事的背景。

至于 Junio，他實際上是最早加入 Git 開發(fā)隊伍的人員之一。他在我將 Git 的第一個非常粗糙的版本公開后的幾天內(nèi)提交了第一次變更代碼，所以 Junio 在 Git 一開始就參與其中了。

但我之所以把項目交給 Junio，并不是因為他是第一批參與項目的人。在維護了 Git 幾個月之后，讓我決定將項目交給 Junio 維護者的真正原因是“好品味”——一個很難描述的概念。我真的想不到還有什么更好的描述：編程主要是為了解決技術(shù)問題，但如何解決這些問題以及如何思考也很重要。隨著時間的推移，你開始意識到：有些人就有這種“好品味”，他總能選擇正確的解決方案。

我不想將編程說成是一門藝術(shù)，因為它實際上主要是關(guān)于“好的工程”。我很喜歡托馬斯·愛迪生的那句“天才是百分之一的靈感加上百分之九十九的汗水”：編程涉及的幾乎都是細枝末節(jié)的東西和日常繁重的工作。但是，那百分之一的“靈感”，也就是“好品味”，不僅要解決問題，而且要干凈、漂亮地解決。

Junio 就有那種“好品味”。

每次提到 Git，我都想試著講清楚：我在一開始提出了 Git 的核心思想，并經(jīng)常因為這部分工作而獲得太多榮譽。Git 的這 15 年，我也只是在第一年真正參與了項目。Junio 是一個優(yōu)秀的維護者，是他讓 Git 變成現(xiàn)在的樣子。

順便說一下，關(guān)于“好品味”，以及找到擁有好品味的人，并信任他們——不僅僅 Git 是這樣，Linux 也是這樣。與 Git 不一樣的是，Linux 這個項目我仍然在積極維護，但與 Git 一樣的是，Linux 也是一個有很多人共同參與的項目。我認為，Linux 的一大成功是它擁有數(shù)百名維護者，他們都具備了“好品味”，并維護著內(nèi)核的不同部分。

Jeremy Andrews：你有沒有過這樣的經(jīng)歷：把控制權(quán)交給維護者，然后發(fā)現(xiàn)這是一個錯誤的決定？

Linus Torvalds： 我們的維護體系從來就不是非黑即白的，所以不會出現(xiàn)這種情況。事實上，我們甚至沒有將維護權(quán)正式記錄下來：我們確實有一個 MAINTAINERS 文件，但那只是為了讓你在遇到問題時能夠找到對的人，并不是某種排他所有權(quán)的標志。所以，“誰負責什么東西”更像是一種流動的指南，以及“這個人很活躍，工作做得很好”，而不是“我們把所有權(quán)給了那個人，然后他搞砸了”。

從某種意義上說，我們的維護體系也是流動的。假設(shè)你是某個子系統(tǒng)的維護者，如果你需要另一個子系統(tǒng)的東西，是可以跨界的。通常人們在這樣做之前都會進行廣泛的溝通，而且這種事情確實發(fā)生了。這并不是“你只能動這個文件”之類的硬性規(guī)定。

實際上，這與前面討論的有關(guān)許可的事情有些聯(lián)系。“Git”的另一個設(shè)計原則是“每個人都有自己的代碼樹，但沒有哪一個代碼樹是特殊的”。

因為很多其他項目都使用了工具——比如 CVS 或 SVN——這些工具會讓一些人變得“特殊”，賦予了他們某種“所有權(quán)”。在 BSD 世界里，他們稱之為“commit bit”：給一個維護者“commit bit”意味著他可以將代碼提交到中央代碼庫。

我一直很討厭這種模式，因為它會不可避免地導致政治“小團體”的出現(xiàn)。在這種模式下，總有一些人是特殊、隱性受信任的。問題的關(guān)鍵甚至不在于“隱性受信任”，而在于硬幣的另一面——其他人不被信任，他們被定義成局外人，必須受制于監(jiān)護者。

同樣，在 Git 開發(fā)中也不存在這種情況。每個人都是平等的，任何人都可以克隆代碼，做自己的開發(fā)，做好了，就可以合并回來。

所以，沒有必要給人們特權(quán)，也不需要“commit bit”。這樣就可以避免出現(xiàn)政治“小團體”，也不需要“隱性信任”。如果他們做得不好——或者更常見的是，最終消失了，并轉(zhuǎn)向了另一個興趣——他們的代碼就不會被合并回來，也不會阻礙其他有新想法的人。

Jeremy Andrews：Git 有沒有哪些新特性讓你印象深刻，并成為你工作流的一部分？還有哪些特性是你想要增加的？

Linus Torvalds： 我對 Git 的需求總是最早得到滿足的，所以，對于我來說，Git 沒有“新”特性。

這些年來，Git 確實有很大的改進，有一些在我的工作流中已經(jīng)體現(xiàn)出來了。例如，Git 的速度一直都很快——畢竟這是我的設(shè)計目標之一——但它的大部分特性最初是圍繞 shell 腳本而構(gòu)建的。多年來，大多數(shù) shell 腳本都已經(jīng)消失了，這意味著我可以比原來更快地應(yīng)用 Andrew Morton 的補丁。這一點令人感到欣慰，因為這實際上是我早期用于性能測試的基準之一。

所以，Git 對我來說一直都很好，而且變得越來越好。

Git 最大的改進在于“普通用戶”的使用體驗變得更好了。一部分原因是人們在學習 Git 工作流的過程中逐漸習慣了它，但更多的是因為 Git 本身變得更易于使用。

編輯：jq