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。InfoQ 對訪談内容進行了翻譯，以飨讀者。
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”那樣具有革命性。
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 更符合我對“你必須把源代碼合并回來”這種想法的期望。
是以，與其另起爐竈建立一個許可，不如選擇一個人們已經知道并且有一些律師參與其中的許可。
Jeremy Andrews：通常情況下，你的一天是怎麼過的？其中有多少時間花在寫代碼上，多少花在評審代碼上，多少花在電子郵件上？你如何平衡個人生活和 Linux 核心開發工作？
Linus Torvalds： 我現在寫的代碼很少，而且已經很久沒寫了。再要寫代碼，通常是因為人們對某些特定的問題存在争議。我修改代碼，并将其作為更新檔釋出出去，作為對解決方案的解釋說明。
換句話說，我寫的大部分代碼更多的是作為解決方案的示例，而更新檔是一種非常具體的例子。人們很容易陷入理論讨論的陷阱，而我發現描述解決方案最好的方式是寫代碼片段，不一定要完整的程式，隻要讓解決方案具體化一些即可。
我的工作時間都花在電子郵件上了。主要是溝通，而不是寫代碼。事實上，我認為這種與記者和技術部落客之間的交流就是我工作的一部分——它可能比技術讨論優先級低一些，但我也花了相當多的時間在這類事情上。
當然，我也會花一些時間在代碼評審上。但老實說，當我收到一個 PR 時，有問題的代碼通常已經被其他人評審過了。是以，雖然我仍然會看一下更新檔，但實際上會更多地去關注注解，以及更新檔的演化過程。但對于那些與我共事很久的人，我不會這麼做：他們是自己子系統的維護者，我不需要對他們的工作指手畫腳。
是以，很多時候，我的主要工作就是“待在那裡”，執行管理和釋出任務。換句話說，我的工作通常更多地是關于維護過程，而不是底層代碼。
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）。雖然我不是很喜歡這樣，但很顯然有些人喜歡用它們來進行頭腦風暴。但這種“郵件組存檔”模式運作得非常好，并且能夠無縫地與“開發者之間以郵件的形式發送更新檔”和“以郵件的形式發送問題報告”相結合。
是以電子郵件仍然是主要的溝通管道，并且因為郵件中可以包含更新檔，我們可以更容易地讨論技術問題。而且郵件可以跨越時區，當參與者分布在不同地區時，這一點非常重要。
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 年中，釋出可預測性才得到大幅提升。
Jeremy Andrews：目前，最新的版本是 5.12-rc5。現在的釋出流程标準是怎樣的？例如，-rc1 和 -rc2 有什麼不同？你會在什麼情況下決定正式釋出其中一個給定的版本？如果在正式釋出之後出現了大量的回歸會怎樣？這種情況發生的頻率是怎樣的？這些年來，這個過程是如何演變的？
Linus Torvalds： 我之前提到過，這個過程本身是很标準的，并且在過去十年裡一直如此。在此之前，它經曆了幾次演變，但實際上從 3.0 開始它就像時鐘一樣走得很穩定。
到現在為止，我們的釋出節奏是這樣的：先是兩周的合并時間視窗，然後是大約 6 到 8 周的候選版本，然後是最終版本。這樣子差不多 15 年了。
規則一直都是一樣的，盡管它們并不總是被完全嚴格執行：合并時間視窗是針對那些被認為已經“經過測試和準備就緒”的新代碼，然後在接下來的大約兩個月裡進行修複，以確定所有的問題都得到解決。有時候，那些所謂的“就緒”代碼會在釋出之前會被禁用或完全推翻。
這個過程會重複，是以我們大約每 10 周釋出一次。
達到可以釋出的标準是我對候選版本有足夠的信心，而這是以各種問題報告為基礎的。如果某些方面在 rc 後期仍然會出問題，我就極力推翻這些内容，并建議将其放在後續的版本中。但總體而言，很少會出現這種情況。
這樣就完全沒有問題了嗎？不是的。一旦核心釋出了，就會有新使用者，他們會發現一些在 rc 版本中沒有被發現的問題。這幾乎是不可避免的。這也是為什麼我們需要“穩定核心”樹。在釋出之後，我們可以繼續修複代碼。一些穩定核心比其他版本核心維護的時間更長，被稱為 LTS（“Long Term Support”）版本。
所有這些在過去十年裡都沒有什麼變化，盡管後來有了更多的自動化流程。一般來說，核心測試自動化是很困難的——因為很多核心是驅動程式，十分依賴硬體的可用性。不過，我們有幾個測試場同時進行引導和性能測試，以及各種随機負載測試。這些在這幾年有了很大的改善。
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 所使用的機器強大得多。
Jeremy Andrews：如果用 Rust 來重寫一部分系統會怎樣？在這方面還有改進的餘地嗎？在核心開發方面，你覺得是否有可能用另一種語言（比如 Rust）來取代 C 語言？
Linus Torvalds： 我不認為我們會用 Rust 取代 C 語言來開發核心，但可能會用來開發一些驅動程式，也許是整個驅動子系統，也許是檔案系統。是以不是“取代 C 語言”，而是“在一些有意義的地方擴充我們的 C 代碼”。
當然，驅動程式幾乎占了核心的一半代碼，有非常大的重寫空間，但我不認為所有人都會很期待使用 Rust 全盤重寫現有的驅動程式。可能“有些人會用 Rust 開發新驅動程式，或者适當地重寫一部分舊驅動程式”。
現在更多的是“人們在嘗試和體驗”Rust，僅此而已。Rust 優勢的背後肯定存在複雜性，是以我會采取觀望的态度，看看這些優勢是否真的奏效。
Jeremy Andrews：核心中是否有你個人感到最自豪的部分？
Linus Torvalds： 我最想說的是 VFS 層（虛拟檔案系統，特别是路徑名查找）和 VM。前者是因為 Linux 在做一些基礎任務（在作業系統中查找檔案名确實是一個核心的操作）時比其他系統都要好得多，後者主要是因為我們支援 20 多種架構，但仍然在使用一個基本統一的 VM 層，我認為這一點很了不起。
但與此同時，這很大程度上取決于“你最關注核心的哪一部分”。核心很大，不同的開發者（和不同的使用者）會關注不同的方面。有些人認為排程是核心中最令人感到興奮的部分，有些人則關注裝置驅動程式的細節（我們有很多這樣的驅動程式）。我個人在 VM 和 VFS 這兩個方面參與得更多，是以自然會提到它們。
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： 實際上，得益于我們一直以來的工作方式，它的影響非常小。電子郵件真的是一個很好的工具，我們并不依賴面對面的會議。
是的，它确實影響了去年的年度核心峰會（今年的峰會仍懸而未決），大多數會議被取消或轉為線上進行。以前在辦公室工作的人大都開始在家裡工作（但很多核心核心維護者在之前已經這麼做了）。是以，周圍的很多東西都發生了改變，但核心開發還是像以前一樣。
很顯然，新冠疫情在其他方面影響了我們所有人的生活，但總的來說，作為幾乎完全通過電子郵件進行交流的核心開發人員，我們可能是受影響最小的。
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”。這樣就可以避免出現政治“小團體”，也不需要“隐性信任”。如果他們做得不好——或者更常見的是，最終消失了，并轉向了另一個興趣——他們的代碼就不會被合并回來，也不會阻礙其他有新想法的人。
Jeremy Andrews：Git 有沒有哪些新特性讓你印象深刻，并成為你工作流的一部分？還有哪些特性是你想要增加的？
Linus Torvalds： 我對 Git 的需求總是最早得到滿足的，是以，對于我來說，Git 沒有“新”特性。
這些年來，Git 确實有很大的改進，有一些在我的工作流中已經展現出來了。例如，Git 的速度一直都很快——畢竟這是我的設計目标之一——但它的大部分特性最初是圍繞 shell 腳本而建構的。多年來，大多數 shell 腳本都已經消失了，這意味着我可以比原來更快地應用 Andrew Morton 的更新檔。這一點令人感到欣慰，因為這實際上是我早期用于性能測試的基準之一。
是以，Git 對我來說一直都很好，而且變得越來越好。
Git 最大的改進在于“普通使用者”的使用體驗變得更好了。一部分原因是人們在學習 Git 工作流的過程中逐漸習慣了它，但更多的是因為 Git 本身變得更易于使用。