Linux学习总结（68）——Linux 30年专访：Linus Torvalds谈Linux内核开发与Git

川长思鸟来 2023-01-18 12:25 156阅读 0赞

三十年前，当Linus Torvalds（林纳斯·托瓦兹，下文统称Linus）首次发布Linux内核时，他还是赫尔辛基大学（University of Helsinki）的一名21岁的学生，他宣布说：“我正在做一个（免费的）操作系统（只是个爱好，规模不大，也不怎么专业……）”。三十年后，前500强超级计算机、以及超过70%的智能手机全部都在运行Linux。显然，Linux的规模庞大，且十分专业。三十年来，Linus一直领导着Linux内核的开发，并为无数开发人员和开源项目提供了灵感和启发。在2005年，Linus还创建了Git来辅助管理内核开发过程，此后，它便成为了最受欢迎的版本控制系统，受到了无数开源和专利项目的信任。Linus通过电子邮件接受了记者的采访，反思了他这些年从领导大型开源项目中学到的东西。**在本文的访谈内容中，重点讨论了Linux内核开发和Git。**“\[Linux\]最初只是一个个人项目，并不是出于什么创造新的操作系统的伟大梦想，”Linus表示，“它只是由我对新PC硬件的深入学习而逐渐发展演变形成的。”关于创建Git并将其交给朱尼尔·哈马诺（Junio Hamano）来改进和维护这件事，Linus表示：“我并不将编程称为一门艺术，因为它实际上更偏向于‘好的工程’。我非常认同托马斯·爱迪生（Thomas Edison）所说的‘天才是百分之一的灵感和百分之九十九的汗水’：编程依赖的也是各种细枝末节的细节和每日的繁重工作。偶尔也会需要所谓的‘灵感’，即‘好品味’，它能干净、漂亮、甚至是完美地解决问题。而朱尼尔就具备这种‘好品味’。”

# Linux内核开发 #

**记者**：**Linux无处不在，它是整个开源世界的灵感源泉。当然，它也不是从一开始便能获得如此成就的。早在1991年，您便在comp.os.minix上一个不起眼的Usenet帖子中发布了著名的Linux内核。十年后，您写了一本书——《只是为了好玩：偶然发明趣事》（Just for Fun: The Story of an Accidental Revolutionary）。今年8月，Linux将迎来它的30周年纪念日。在这段旅程中，您是在什么时候意识到自己所做的Linux并不仅仅“只是一个爱好”的？**

**Linus：**听起来可能有点荒谬，但其实我很早就意识到这一点了。在1991年末（以及1992年初），Linux就已经比我预想的要大得多了。

那个时候，可能只有几百个用户（甚至都不能算是“用户”，人们只是在不断地对其进行修补），要说我在当时就开始考虑Linux后来将如何发展壮大的话，听起来可能会有点可笑。但就我个人而言，最大的转折点是当我意识到真的有人正在使用它，并对它感兴趣时，它开始有了自己的生命。人们开始发送补丁，而且我渐渐发现这个系统能够完成的事情远比我预想的要多得多。

我记得X11好像是在1992年4月的某个时间被移植到Linux上的（具体日期记不清了，毕竟那已经是很久之前的事情了)，这可以算是又一里程碑式的大动作，GUI以及一套全新的功能横空问世。

从这个角度来看，我最初并没有什么高期望的大计划。它只是一个个人项目，也并不是出于什么创造新的操作系统的伟大梦想，它只是由我对新PC硬件的深入学习而逐渐发展演变形成的。

**因此，我发布的第一个版本实际上更像是“快来看！我做了一个新东西”。我当然希望大家会觉得它很有趣，但它并不是一个真正严谨且可用的操作系统。**它的存在更像是为了证明概念的可行性，只是我花了几个月时间就完成的一个个人项目而已。

从“个人项目”到“有其他人使用、发送反馈（和bug报告）、以及偶尔的补丁”，这对我来说是一个巨大的转变。

**举一个最基本的例子：在原始版本中，你可以以源代码的形式发布，但不能盈利。**

那是因为对当时的我来说，商业unix太贵了（至少对于一个把所有钱都花在新PC上的穷学生党来说非常贵）。所以对我而言，源代码可用是非常重要的，只有这样人们才能对其进行修补，而且我希望它能对像我这样负担不起其他选择的人开放。

我在1991年底（或者1992年初）把许可证改成了GPLv2，因为有人想把它以软盘的形式分发给本地Unix用户组，但又希望至少能收回软盘的成本以及其复制时间。我才意识到这个要求完全合理的，重要的不是“免费”，而是“源代码需要公开”。

**最终的结果是：人们不仅在Unix用户组会议上进行了发行，而且在短短的几个月内便出现了SLS和Slackware等早期软盘发行版。**

除了那些最初的根本性变化，其他一切都是“渐进式”的。当然，有些渐进变化是相当大的（IBM的加入、Oracle DB移植、Red Hat的首次公开募股、Android在手机上的应用发展等等），但对我而言，这些变化都不如最初“我甚至不知道这些人都在使用Linux”那样具有革命性。

**记者：您是否曾为自己的许可证选择后悔过？或者曾为其他人或公司从你创造的系统上赚了多少钱而后悔？**

**Linus**：从未后悔过。

首先，我过得还不错。虽然并不算特别富有，但作为一名高薪的软件工程师，我可以按照自己的节奏做我喜欢做的事，保持一个相对舒适的状态。

与此同时，我100%地相信许可证是Linux（以及Git）成功的重要组成部分。我始终坚信要让大家都知道自己具有平等的权利且没有人在许可方面享有特权，这对所有人来说都是一件好事。

现在，有非常多的“双许可证”项目：原始所有者保留了商业许可证（“如果你向我们支付许可证费用，你便可以在自己的专利产品中使用它”），但另一方面，该项目也可以在GPL等情况下开源代码。

**我认为要想在这种情况下建立社区是非常困难的，因为开源的一方总是知道自己的“二等公民”身份。另外，要想让享有特权的一方始终保持其特殊权利，就必然需要大量的许可文书工作，而这给项目增加了很多额外阻力。**

另一方面，我见过许多BSD（或MIT等等）许可的开源项目，当其规模逐渐扩大到具有商业重要性时，就会走向四分五裂的局面，相关公司必然会决定将自己的部分变成专有部分。

我认为GPLv2能够实现“所有人都在相同规则下工作”与“要求人们回馈社区”的完美平衡。大家都知道所有参与其中的人都受同样的规则约束，所以这是非常公平公正的。

**同样，你的投入也会得到相应的回报。**当然，如果你想只做一名用户，在项目方面保持“旁观者”姿态的话也是可以的，只是这样你便失去了对该项目的控制权。如果你只是需要一个基本的操作系统，而Linux已经可以实现你想要的所有功能的话，那么也完全没问题。但如果你有特殊要求，那么能对项目产生真正影响的唯一方法就是参与进来。

在这种情况下，所有人（包括我在内）都要保持诚实。任何人都可以对项目进行分叉，走自己的路，然后告别：“再见了，Linus，我要接管我的Linux版本的维护。”我之所以特别，仅仅是因为人们相信我能把工作做好。而这本来就是理所当然的事情。

“任何人都可以维护自己的版本”这一点让一些人对GPLv2产生了怀疑，但我其实认为这并不是劣势，而是一种优势。我认为，正是这一点保护Linux逃过了分裂的结局：每个人都可以完成自己的项目分支。事实上，这也是“Git”的核心设计原则之一——存储库的每个克隆都是自己的小分支，而人们（和公司）要想真正完成项目开发的话，则需要从中分叉出去。

**所以分叉本身不是问题，只要你能把好的部分合并回来即可。这就是GPLv2的意义所在。**要保障大家具备进行分叉并实现个人项目的权利，但与此同时，也要保证当分叉成功时，大家也有权利能再次将其融合回来。

**另一个问题是，大家都想拥有能够支持项目生产的工具，但同时，也要具备相应强大的心态**。将分叉融合回来的障碍并不仅仅是许可证的问题，还有“bad blood”的问题。如果两个分叉从根本上就非常对立的话，那么要想将它们进行融合是非常困难的——**并不是因为许可证或技术原因，而是因为分叉过于尖锐对立。**同样，我认为Linux很好地避免了这一点，主要是因为我们一直认为分叉是一件非常正常且自然的事情；当其证明了自身的成功后，要合并回来同样也是非常正常且自然的。

虽然这个答案或许有点跑题了，但我认为这一点非常重要——**我从未后悔过自己的许可证选择，因为我真心认为GPLv2是Linux能够取得成功的重要原因。**

金钱其实并不是一个很好的激励方式，因为它并不能将人们团结在一起。我认为，真正能够起到激励作用的是：人们参与到一个共同的项目中来，并且真正感觉到自己可以成为这个项目的全面合作伙伴。

**记者**：**现在，人们在GPLv2下发布源代码，通常都是因为Linux。您是如何寻找许可证的呢？您在审查现有许可证上投入了多少时间和精力呢？**

![Linux 30年专访：Linus Torvalds谈Linux内核开发与Git][Linux 30_Linus Torvalds_Linux_Git]

**Linus**：当时，人们仍对BSD和GPL有相当大的争论（我想很大一部分原因是RMS真的很擅长激怒别人），所以我只能在浏览各usenet新闻组（如comp.arch, comp.co.minix等）时看到一些有关许可证的讨论。

**但最主要途径的有两个**：gcc——它对Linux的发展起了很大作用，因为我肯定会需要C语言编译器——和拉尔斯·维兹尼乌斯（Lars Wirzenius，“Lasu”），他是当年我大学里另一个说瑞典语的CS学生（瑞典语在芬兰是一个非常小众的语种）。

Lasu比我更喜欢讨论许可证之类的事情。

对我来说，选择GPLv2并不是什么重大原则性决定，主要是因为我原来的临时许可证亟待更新，我很感激gcc，但GPLv2更符合我“你需要把源代码还回来”的期望。

因此，与其设立新的许可证（或者只是对旧的许可证进行修改），我更希望能挑选一个已经为人所熟知，且有律师参与的许可证。

**记者**：**您每天会花多长时间写代码？审查代码？收发邮件？您是如何平衡个人生活和Linux内核工作的呢？**

**Linus**：我现在很少会写代码了，已经很久没写了。当人们在特定问题上存在争议时，我才会写代码进行修改并将其作为补丁发出去，对提出的解决方案做出解释说明。

换句话说，我写的代码更像是“看，我们这样做行么？”，补丁就是一个非常具体的例子。我们常常会陷入如何解决某个问题的高级别理性讨论中，然后我发现描述解决方案的最佳方式其实是直接把代码片段写出来，虽然片段并不完整，但这却会让问题变得非常具体。

其实我的工作时间全都花在了阅读和回复电子邮件上了。主要负责沟通，而不是编码。这种与记者和科技博主间的沟通交流本就是我工作的一部分——或许它不如实际的技术讨论重要，但我确实在上面花费了相当多的时间。

同时，我也会花时间进行代码审查，但说实话，当我收到拉取请求时，有问题的代码应该已经被多个人审查过了。因此，虽然我仍然会看一下补丁，但实际上我会更关注解释、以及补丁的形成过程。对于那些与我共事很久的人，我甚至都不会看：**他们才是自己子系统的维护者，我不需要事无巨细地去监管他们的工作。**

所以很多时候，我的主要工作就是以揽收点的身份“待在那里”，并且承担管理和发布的任务。**换句话说，我的工作通常更侧重于维护过程，而不是处理低级别代码。**

**记者****：****您的工作环境是怎样的？比如，您是喜欢黑暗且没有干扰的房间，还是明亮且风景优美的房间？是倾向于安静地工作，还是喜欢边听音乐边工作？您习惯使用什么样的硬件？是喜欢用终端的vi审查代码，还是用IDE？还有，您个人在工作中是否有偏爱的Linux发行版本？**

![Linux 30年专访：Linus Torvalds谈Linux内核开发与Git][Linux 30_Linus Torvalds_Linux_Git 1]

**Linus**：我的房间并不是很暗，但我确实会把办公桌旁边窗户的百叶窗关上，因为我不喜欢过于强烈的阳光（这是俄勒冈州此时最常见的天气）。因此，我的办公室中没有风景，只有一张（凌乱的）桌子，桌子下有双4K显示器、一台功能强大的台式电脑，还有几台用于测试的笔记本电脑。

我喜欢在安静的环境下工作。我之前非常讨厌机械磁盘驱动器的滴答声——而我也已经使用固态硬盘超过十年了，当时舍弃机械磁盘真是个明智之选，而且我也忍受不了嘈杂的CPU风扇。

一切都在传统终端中完成，但我没有用“vi”，而是用了一种名为“micro-emacs”的东西，它与GNU emacs毫无关系，只是其中一些键的绑定方式是相似的。我还年轻，在赫尔辛基大学上学时用它用习惯了，因此就算我心里清楚自己需要尽快将其戒掉，但还是没能成功。**几年前，我为它设计了（非常有限的）utf-8支持，各种迹象都表明其写于80年代，而我使用的版本还是自90年代中期以来就没有进行过任何维护的分叉。**

赫尔辛基大学之所以使用它是因为它可以在DOS、VAXVMS和Unix上工作，而我也是因此才知道了它，导致现在我的手指都已经对其形成肌肉记忆了。我必须要将其换成一个能够实际维护并执行utf-8的东西，可能会是“nano”。我只是还没有强迫手指去改掉之前的记忆，所以现在用起nano来还是磕磕绊绊的。

**因此，我的桌面环境相当简单：几个文本终端、一个浏览电子邮件的浏览器**

（还有其他几个新闻和科技相关的标签页）。我需要很大的桌面空间，因为我的终端窗口非常大（默认初始大小是100x40），并且我会并排打开多个终端。因此，需要双4k显示器。

我所有机器上使用的都是Fedora，倒不是因为它多么好用，只是因为用习惯了而已。我也不太关心是否是发行版本——对我而言，它的作用就是在机器上安装Linux并设置所需工具，让我能更换内核在其上工作即可。

**记者**：**人们通过Linux内核邮件列表进行公开的内核开发，而且其流量非常大。您是如何兼顾这么多邮件的呢？有没有探索过邮件列表之外的其他合作沟通解决方案？还是说简洁的邮件列表对您的工作而言就是完美的？**

**Linus**：我已经很多年没有直接阅读过内核邮件列表了，实在是太多了。

内核邮件列表的意义在于可以将内容抄送给所有人。这样一来，当有新人加入讨论时，可以通过查看内核邮件列表来了解历史沟通记录。

我之前订阅了列表，设置将所有没私人抄送的lkml邮件都自动归档，默认不显示。当有问题需要处理时，我也能找到所有的相关讨论。所有内容都储存在电子邮件中，但只有在需要时才会出现在收件箱。

最近，我一直都在用lore.kernel.org的功能，它非常好用，而且我们还有一些围绕其构建的工具。因此，邮件讨论内容就不必自动归档在邮箱里了，可以以另一种方式呈现，但其基本的工作流程是相同的。

当然，我仍会收到非常多的电子邮件——但从很多方面看来，这些年来情况已经在逐步转好了。其中很大一部分原因是Git及内核发布流的完美运作：以前，我们在代码流和工具方面存在很多问题。在本世纪初，我的邮件状况非常差，当时我们还在处理庞大的补丁问题，在世纪之交时更糟糕，当时我们仍在处理巨大的补丁炸弹，开发流还存在严重的可扩展性问题。

（附带工具的）邮件列表确实非常好用。并不是说所有人都只用电子邮件或者线下见面沟通，也有人喜欢各种实时聊天设置（当时还有IRC）。虽然这不是我的风格，但确实有些人喜欢用它来进行头脑风暴。但“邮件列表存档”模式非常好用，并且能够无缝衔接“开发者之间以邮件方式发送补丁”和“以邮件方式发送问题报告”。

因此，电子邮件仍是主要的沟通渠道，补丁可以被嵌入同一媒介，简化了技术讨论流程。而且它能实现跨时区工作，当大家在异地工作时，这一点就显得尤为重要了。

![Linux 30年专访：Linus Torvalds谈Linux内核开发与Git][Linux 30_Linus Torvalds_Linux_Git 2]

**记者**：**3.0内核与之前的2.6.x版发布之间隔了整整八年。自3.0版本发布以来，内核有没有发生什么更有趣的事情呢？**

**Linus**：哈哈，那是很久以前的事了，久到我都不知该从何说起了。3.0距今也有十年了，在这十年中我们的技术发生了很大变化。ARM发展成熟了，而ARM64也已经了成为主要架构之一。有了很多新的驱动程序和核心功能。

如果有的话，过去十年的有趣之处在于“**我们是如何保持实际开发模型平稳”的，以及“什么东西没有变”。**

几十年来，我们推出过许多不同的版本方案以及多个开发模式，但3.0版本最终确定了我们一直以来使用的模式。它真正实现了“基于时间，版本号只是数字，不依附于任何功能”的说法。

**在2.6版本中，我们就已经有了具备合并窗口的“基于时间”的概念，因此这并不稀奇，但3.0是那“最后一片拼图”。**

我们有随机编号方案(主要是在1.0之前)，其规则是：小数点后奇数表示开发内核，偶数表示稳定的生产内核。然后在2.6中，我们开始做基于时间的发布模式。但是仍然存在“何时增加主版本号”的问题。而3.0的正式出现表示，主版本号并没有什么特殊意义，只是为了尽量简化数字，不要让它太长太繁琐。

**因此，在过去的十年里，我们做了非常大的改变。但开发模式本身其实一直都相当平稳和稳定。**

但实际上，内核开发的前二十年中，开发模式一路走来经历了很多坎坷，只是在过去的十年中，发布的可预测性才大大提高了。

**记者****：****截至目前，最新版本是5.12-rc5。发布过程的标准化程度如何？例如，什么样的变化会进入rc1、rc2等等？您是在什么时候才会决定特定版本是否可以正式发布的？如果有错误，在版本发布后宣布撤回的话会发生什么？这种情况的发生频率高吗？这一过程多年来的是如何演变的？**

**Linus**：我之前提到过：这个过程本身是有一定标准的，并且在过去的十年里一直如此。此前，它曾经历过几次剧变，但实际上从3.0开始其运转就如时钟般稳定了（甚至还会更早一些，因为人们要适应Git还需要花费一定的时间）。

因此，我们形成了相对固定的节奏：在最终版本发布之前，有约两周的合并窗口时间，然后每周约6-8个候选版本，到现在已经有将近15年了。

规则一直都是一样的，但并不会总是完全严格按其执行：合并窗口是为假定“已经过测试和准备好”的新代码准备的，然后在接下来的约两个月里进行修改，确保所有问题都能得到妥善解决。但是，有时在发布之前，那些“已经准备好”的代码也会被禁用或彻底推翻。

**然后从头再来——-所以我们大约每10周左右就有一次发布。**

**发布标准是我自身要对该版本有足够的信心，而这种信心是要建立在递交上来的问题报告的基础之上的。**如果某方面在rc后期仍出问题的话，我们会积极修改，并牢记“在解决这个问题之后，也要在随后的版本中注意不要再发生同样的情况”但总体而言，这种情况是相当罕见的。

发布了就一定会取得成功么？当然不是。内核一经发布，就会产生新的用户，其中不乏没有参与开发测试的人，而他们常常会发现一些我们在rc中没有发现的问题，这种情况无法避免。这也是我们需要“稳定内核”树的原因之一，它能够在发布后继续添加修复。一些稳定内核的维护时间比其他内核更长，因此也被称为LTS（“Long Term Support”）内核。

所有这些在过去的十年里都没有什么变化，只是有了更加完善的自动化流程。一般来说，内核测试的自动化是很困难的——部分原因是很多内核都是驱动程序，这依赖于硬件的可用性——但有几个场同时进行启动和性能测试，并进行各种随机负载测试。因此近年来情况已经有了很大改善。

**记者**：**去年11月，有人说您对苹果公司在其新电脑中的ARM64芯片印象深刻。Linux是否仍在支持他们的开发工作？我看其被并入了for-next。Linux即将到来的5.13内核会否在苹果的MacBook上启动？ARM64有何重大意义？**

![Linux 30年专访：Linus Torvalds谈Linux内核开发与Git][Linux 30_Linus Torvalds_Linux_Git 3]

**Linus**：我偶尔会跟进一下，但现在谈论这些还为时过早。你也发现了，早期支持可能会被合并到5.13中，但要知道，这只是一个开始，并不能预测苹果和Linux 之间的未来。

最重要的问题并不是Arm64，而是它周围的所有硬件驱动程序（特别是SSD和GPU）。到目前为止，启动的工作都相对比较简单，除了早期的硬件启用之外，并没有产生任何有用的成果。它还需要一段时间才有资格被大众选择。

但不仅仅是苹果的硬件得到了改进——Arm64的基础设施总体上也成长了很多，内核在服务器领域也更有竞争力了。不久前，Arm64的服务器还是一团糟，但亚马逊的Graviton2和Ampere的Altra处理器——都是基于改进后的ARM Neoverse IP——比几年前的产品要好得多。

我等了十多年都没有等到一台可用的ARM机器，而且可能还要继续等下去，但显然，我们已经取得很大进展了。

事实上，我想要ARM机器的时间远比想象中要久——当我还只有十几岁时，最想要的机器其实是Acorn Archimedes，但最终可用性和价格促使我选择了Sinclair QL（M68008处理器），几年后换成了i386 PC。

所以，这个想法已经酝酿了几十年了，但对我来说，与电脑相比，它们在价格和性能上仍不具备竞争力。希望在不久的将来，这一愿望终能实现。

**记者**：**在内核中是否有什么不尽如人意的地方,需要彻底重写才能完全解决？内核已经有三十年的历史了，在这三十年里，知识、语言和硬件都发生了很大变化：如果让您现在从头开始重写，您会做出哪些改变呢？**

**Linus**：如果有必要的话。我们真的非常擅长完全重写东西，所以即使有任何本会导致无妄之灾的东西，也早就已经被重写了。

我们也有很多“兼容”层，但一般并无大碍。而且尚不清楚如果从头开始重写的话，那些兼容层是否会真的消失——它们是对旧二进制文件的向后兼容（通常是对旧体系结构的向后兼容性，例如在x86-64上运行32位x86应用程序）。我认为向后兼容是非常重要的，所以我希望即使在重写时也要保持这种兼容性。

显然，很多东西都不是“最优选”，任何东西都有改进的空间，但就这个问题而言，我想说，我不鄙视任何东西。确实有一些遗留驱动没人关心，也没人清理，所以可能会被利用做一些坏事，但最重要的是“没人关心”。当问题出现时，我们想要去积极主动解决根源问题——“没人关系”。因此多年来，当架构维护不再具有意义时，我们就会直接放弃整个架构支持。

**不，重写的唯一主要原因是——整个架构已经没意义了，但却还有一些用例。**最有可能的情况是，一些小型嵌入式系统并不需要Linux提供的东西，而且其硬件空间很小，它需要的是比Linux更小、更简单的东西。

因为Linux已经成长了很多。现在，即使是小硬件（比如手机等）也比当初开发Linux时使用的机器功能强大得多。

**记者**：**如果用Rust这种专门为性能和安全而设计的语言来进行部分重写可以吗？在这种情况下还有改进的空间吗？您觉得其他像Rust这样的语言有可能在内核中取代C语言吗？**

![Linux 30年专访：Linus Torvalds谈Linux内核开发与Git][Linux 30_Linus Torvalds_Linux_Git 4]

**Linus**：这要等等再看。我不认为Rust会接管核心内核，但是做单独的驱动程序（或整个驱动子系统）也不是完全不可能，或许还能做文件系统。所以它不是要“取代C语言”，而是“在适当的地方增强C语言”。

特别是驱动程序约占实际内核代码的一半，所以空间非常大，但我不认为有人真的会用Rust全盘重现有的驱动程序。绝大多数人都会“用Rust做新的驱动程序，在适当的地方重写几个驱动程序”。

但现在更多的人仍处于“试着玩玩”的阶段。要指出优点很容易，但其背后存在着复杂性，所以我更愿意持观望态度，看看其承诺的优点是否真的能实现。

**记者****：内核有哪个部分是您个人最引以为豪的吗？**

**Linus**：个人认为是VFS（“虚拟文件系统”）层（尤其是路径名查找）和我们的VM代码。前者是因为Linux在做基础任务时的表现确实非常优秀（在操作系统中查找文件名就是操作系统中的基础核心操作）。后者主要是因为我们支持20多种架构，但仍使用基本统一的VM层，我认为这一点非常了不起。

但与此同时，这很大程度上取决于“你更注重内核的哪一部分”。内核很大，不同的开发人员（以及不同的用户）对于“最重要的事”有不同的看法。有些人认为调度是内核中最棒的部分，而其他人则更喜欢设备驱动程序的各种细节。我个人在VM和VFS领域的参与更多，因此自然也会选择这两方面的内容。

**记者**：**我发现这个关于路径名查找的描述比我想象得要复杂。是什么让Linux比其他操作系统“更好”的呢？您提到的“更好”又是什么意思呢？**

**Linus**：路径名查找是非常常见和基础的请求，因此大多数外行人甚至都不把它看作是一个问题：他们只会理所当然地打开文件。

但要想把这件事做好其实是相当复杂的。确切地说，因为几乎所有的任务都是在不断进行路径名查找动作，所以它对性能高低起着至关重要的作用，而且大家都希望它能在SMP环境中实现良好扩展，而锁定又非常复杂。由于不想做IO，所以缓存非常重要。因此，路径名查找的重要性不言而喻，我们不能把它留给低级别文件系统，因为我们有20多个不同的文件系统，如果让它们各自执行自己的缓存和锁定的话，后果将不堪设想。

所以VFS层的重要认为之一就是处理所有路径名组件的锁定和缓存，处理所有的序列化和挂载点遍历，这些都要通过无锁算法（lock-free algorithms，RCU）来完成，但也有一些非常好用的类琐工具（Linux内核lockref锁就是一种专为dcache 缓存设计的特殊“带参考计数的自旋锁”，它有专门的锁感知参考计数，可以在某些常见情况下进行锁消除)。

**最终：底层文件系统仍然需要对未缓存的内容进行实际查找，但它们不需要担心缓存、一致性规则、以及与路径名查找相关的原子性规则。这些都由VFS来处理。**

而且它的性能比任何其他操作系统都要好，基本上可以完美扩展到拥有数千个CPU的机器上，即使这些机器最终都会接触相同的目录。

所以不仅是“更好”，还是“更更好”，没有什么能与之相提并论。Linux dcache是独一无二、无可匹敌的。

**记者**：**过去的一年对全世界来说都是艰难的一年。疫情对内核开发进程有什么影响？**

**Linus**：实际上，得益于我们一直以来的工作方式，它的影响并不大。有邮件这个好帮手，我们并不过分依赖于会议。

但它确实影响了去年的年度内核峰会（今年峰会仍悬而未决），大多数会议都被取消或转为线上进行。以前在办公室工作的人也开始在家工作（其实许多核心内核维护者们之前就是这样）。所以，周围很多事情都发生了改变，但核心开发本身还是和以前一样运作。

显然，它在其他方面影响着我们所有人的生活——仅限于一般的社会影响。但总的来说，作为一个几乎完全通过电子邮件与人交流的内核开发人员，我们可能是受影响最小的一群人了。

**Git分布式版本控制系统**

**记者**：**Linux只是您对开放源码做出的众多贡献之一。在2005年，您还创建了Git这个广受好评的分布式源代码控制系统。您很快便将Linux内核源代码树从专有的Bitkeeper迁移到了新创建的开源Git中，并在同年将维护权移交给了朱尼尔·哈马诺（Junio Hamano）。这其中一定有很多趣事，是什么让您这么快就移交了出这个项目的领导权，以及您是如何找到并选择朱尼尔的？**

**Linus**：这个问题的答案分为两个部分。

![Linux 30年专访：Linus Torvalds谈Linux内核开发与Git][Linux 30_Linus Torvalds_Linux_Git 5]

首先，我当时并不想创建新的源代码控制系统。创建Linux是因为我对发现硬件和软件之间的低等级接口很感兴趣——这基本上是出于热爱和个人兴趣的推动。相比之下，Git的诞生则是出于需要：并不是因为我觉得源代码控制很有意思，而是因为我完全看不上当时市面上大多数源代码控制系统，而我觉得最合适、且在Linux开发模型中确实运行得很好的BitKeeper已经站不住脚了。

**最终：我做Linux已经有30多年了（距离第一个版本的周年纪念还有几个月，但是我在30多年前就已经开始研究类似Linux 前身的东西了)，并且一直在对其进行维护。但是我从来没有想过要长期维护Git。**我喜欢使用它，而且我认为它是目前市面上最好的SCM，但这不是我最基本的热情和兴趣所在。

因此，我一直希望由别人来替我维护SCM——其实，如果当初有现成的SCM可以用的话，我会更高兴的。

以上便是背景故事。

**至于朱尼尔——他其实是最早加入Git开发者队伍的人之一。他在我公开了第一版Git（非常粗糙的一版）后的几天内便完成了首次改动。所以朱尼尔实际上从Git诞生之初就已经是我们中的一员了。**

但之所以把项目交给朱尼尔，并不是因为他是第一个出现的人。在维护了Git几个月后，真正让我让做出“邀请朱尼尔担任维护者”决定的是一个比较抽象的概念——“好品味”。我不知道该如何确切描述这种感觉，编程是为了解决技术问题，但如何解决这些问题，以及如何思考也是非常重要的。随着时间的推移，你会清楚地认识到：某些人就是有那种“好品味”，能够做出“正确的”选择。

我并不想将编程称为一门艺术，因为它实际上更偏向于“好的工程”。我非常认同托马斯·爱迪生（Thomas Edison）所说的“天才是百分之一的灵感和百分之九十九的汗水”：编程依赖的也是各种细枝末节的细节和每日的繁重工作。偶尔也会需要所谓的“灵感”，即“好品味”——它能干净、漂亮，甚至是完美地解决问题。

而朱尼尔就具备这种“好品味”。

**每次提到Git，我都会尽量讲得非常非常清楚：确实是我提出并设计了Git的核心思想，但我也常常会因此而备受过誉**。Git这十五年来，我只有在第一年亲自参与了项目工作，朱尼尔一直都是一名优秀的维护者，是他让Git有了今天的成就。

找到并信任具备“好品味”的人——这不仅仅是Git的故事，也是Linux的历史。与Git不同的是, Linux是一个我仍积极亲自参与维护的项目；但与Git相同的是，它也是一个有很多人参与的项目。我认为Linux的一大成功之处就在于有数百名的维护者，他们都具备难以言表的“好品味”，他们齐心协力共同维护内核。

**记者：您有没有过把控制权交给维护者后却发现这是一个错误决定的经历？**

**Linus：**我们的维护体系并不是如此非黑即白且僵化的，所以从来没有出现过此类问题。而且我甚至没有将维护控制权严谨记录归档：我们有一个MAINTAINERS文件，但那只是为了方便让大家为任务找到合适的人选，并不是某种排他性所有权的标志。

**因此，****“谁拥有什么权利”更像是一个流动性指导，以及“这个人很活跃，而且做得很好”，而不是“我们把所有权交给了某某，然后他现在搞砸了”**。

整个结构体系都是流动的，也就是说，可能你是一个子系统的维护者，但如果你需要另一个子系统的东西，是可以跨越边界的。一般这种情况大家都需要提前进行沟通，但重点是它确实可以实现，这绝对不等同于“你只能动这一个文件”之类的硬性规定。

其实这与之前提到的许可证有点联系，另一个能够说明Git设计原则的例子是“每个人都有他们自己的树，在技术上大家处于同一起点”。

因为其他很多项目都使用了工具——比如CVS或SVN——从根本上说，这些工具会让一部分人享有特权，并且赋予其工具附带的“所有权”。在BSD世界中，他们称之为“commit bit”：给维护者“commit bit”就意味着他现在可以向中央仓库（或至少部分中央仓库）进行提交。

我一直都不喜欢这种模式，因为它一定会导致政治“小团体”的发展，在这种模式下，总有一些人是特殊的、隐性受信任的。而最重要的甚至都不是“隐性信任”的问题，而是“其他人不被信任”的问题，他们会被定义成局外人。

同样，在Git中，这种情况并不存在。每个人都是平等的。所有人都可以克隆，进行自己的开发，如果做得好的话，还可以被合并回来（如果他们做得好，就会成为维护者，最终成为在自己的树上完成合并的那个人）。

所以其实没有必要给人们特权——也不需要“commit bit”。这样我们就可以避开政治小团体，也不需要“隐性信任”。如果他们最终做得不好——或者找到了其他兴趣，直接人间蒸发——他们就不会合并回来，也不会妨碍其他有新想法的人。

**记者：Git的新功能是否给您留下了深刻印象？有什么能用到您的工作中的么？或者有什么新功能是您希望在将来看到的么？**

**Linus**：作为创始人，我自己的用例当然是Git出现后完成的第一个用例，所以对我来说，很少会关注新的功能。

这些年来，Git确实取得了很大进展，而且在我的工作中也体现出来了。例如，Git的速度一直都非常快——毕竟这本就是我的设计目标之一——但很多功能最初都是围绕核心辅助程序的shell脚本完成的。多年来，大多数shell脚本都已经消失了，这意味着我可以比原来更快地应用Andrew Morton的补丁。这点让人非常欣慰，因为这其实是我性能测试的早期基准之一。

因此，对我而言，Git一直都很好用，只是它现在变得更好了。

最大的改进在于，普通用户的使用体验变得更好了。一部分原因是有些人在学习Git的过程中逐渐习惯其使用方法（毕竟它与CVS等使用习惯不同）；但更多的是由于Git本身变得更加方便使用了。

[Linux 30_Linus Torvalds_Linux_Git]: /images/20221021/9d072fb544774ae38eb3819d975e37b3.png
[Linux 30_Linus Torvalds_Linux_Git 1]: /images/20221021/3709c3b215c34e07a89dba1db03757ca.png
[Linux 30_Linus Torvalds_Linux_Git 2]: /images/20221021/010dc2cb2ea4460f8a152c2299beddfb.png
[Linux 30_Linus Torvalds_Linux_Git 3]: /images/20221021/948b29296c1d4a579c9fa8912dff4579.png
[Linux 30_Linus Torvalds_Linux_Git 4]: /images/20221021/d93dc7d71d9c4bff9dff88608e13cae6.png
[Linux 30_Linus Torvalds_Linux_Git 5]: /images/20221021/efd59c26bed0405489dbb83174b10fff.png