祝 Linux 30 岁生日快乐：Linus 21 岁首次发布 Linux 内核

30年前，Linus Torvalds首次发布Linux内核时还是赫尔辛基大学的一名21岁学生。他当时说：“我在开发一款（免费的）操作系统，纯属业余爱好，它不会是庞大且专业的操作系统。”谁料到30年后，全球500强超级计算机都在运行Linux，70%以上的智能手机运行Linux。Linux显然庞大且专业。

30年来，Linus Torvalds领导Linux内核开发工作，启发了另外的无数开发人员和开源项目。2005年，Linus还开发了Git以帮助管理内核开发过程，此后Git就成为了最受欢迎的版本控制系统，备受无数开源项目和专有项目的信赖。

Linus Torvalds通过电子邮件回复了Tag 1咨询公司的创始合伙人/首席执行官Jeremy Andrews的问题，体现了多年来他领导一个大型开源项目所得到的真知灼见。本文着重介绍Linux内核开发和Git。

Linus解释道：“「Linux」是一个个人项目，不是源于为了实现开发一款新操作系统的宏伟梦想，而是纯粹出于我起初只想了解我那台新PC的硬件底层。”

至于开发Git、后来交给Junio Hamano来改进和维护，Linus特别指出：“我不想声称编程是门艺术，因为编程实际上就是‘良好的工程”（good engineering）’。我深信托马斯·爱迪生的这句名言‘百分之一的灵感加上百分之九十九的汗水’：关键几乎在于小小的细节和日常的枯燥乏味工作。但偶尔会有‘灵光乍现’，会有“高品味”，即不仅仅解决某个问题，而是干净、漂亮甚至优雅地解决问题。Junio就有那种‘高品味’。”

Linux内核开发

Jeremy Andrews：Linux无处不在，向来是整个开源界的灵感来源。当然，过去并非总是如此。早在1991年您发布了著名的Linux内核，在comp.os.minix上发表了一则不起眼的Usenet帖子。10年后您出了一本引人入胜的个人著作，题为《只是为了好玩：一个意外的革命者的故事》，讲述了那段历史。今年8月，Linux将迎来30周年！这很了不起，恭喜您！您在什么时候意识到自己做了什么，意识到Linux不仅仅是“纯属业余爱好”？

Linus Torvalds：

这听起来有点荒谬，但实际上早早就发生了。到1991年末1992年初，Linux已经变得比我预期的庞大得多。

是的，考虑到那时可能只有几百个用户（甚至谈不上“用户”，人们只是在捣鼓Linux），鉴于后来Linux最终变得极其庞大，这听起来匪夷所思。但是就我个人而言，一大拐点出现在我意识到其他人实际上在使用它、对它有兴趣，它开始自成一体。人们开始发送补丁，系统实际上开始处理比我最初设想的多得多的任务。

我记得X11是在1992年4月移植到Linux的（我可能记岔了，年代太久远了），这是另一大步，因为突然有了GUI和一系列全新的功能。

综上所述，我确实一开始并未寄予厚望。这是一个个人项目，不是源于为了实现开发一款新操作系统的宏伟梦想，而是纯粹出于我起初只想了解那台新PC的硬件底层。

因此，我发布第一个版本时，实际上更多的是“看看我所做的事情”；当然，我希望别人会觉得它有意思，但这不是一款专业级、易用的操作系统。它更像是概念证明，只是我捣鼓了几个月的个人项目而已。

从那个“个人项目”到别人使用它、发送反馈（和错误报告）以及偶尔发送补丁的项目，这对我来说是天大的变化。

仅举一个很基本的例子：原始的版权许可证类似“您可以将其以源代码的形式分发，但不能为了牟利。”

那是由于对我而言，问题之一实际上是商用Unix太贵了（至少对于把所有钱花在新PC的穷学生来说太贵了），所以在我看来，重要的是源代码可供使用（以便人们可以捣鼓），我希望它对像我这样无力选择替代方案的人来说是开放的。

1991年末1992年初我将许可证改为GPLv2，因为有人希望通过软盘将其分发给本地Unix用户组，但希望起码收回这些软盘及复制时间的成本。我意识到这显然完全合情合理，重要的不是“不涉及钱”，而是“源代码需要公开可用”这部分。

最终结果：不仅人们在Unix用户组会议上分发它，早期的软盘发行版（比如SLS和Slackware）在几个月内就问世了。

与那些最初真正根本性的变化相比，其他一切变化都是“渐进的”。当然，其中一些渐进式变化很大（IBM加入阵营，Oracle DB被移植，Red Hat上市，Android在手机上大行其道等），但是它们本身具有的变革性仍不如“我甚至不认识的人也在使用Linux”这个早期的变化。

JA：您有没有为您选择的许可证感到后悔，或者为其他人和公司从您创造的发明中赚了多少钱感到后悔？

年轻时的 Linus Torvalds（右）

LT：

绝对没有后悔。

首先，我过得很好。我不是超级富有，却是薪水丰厚的软件工程师，可以按自己的时间表做自己想做的事情。

但同样重要的是，我百分之百确信许可证是Linux（以及Git）成功的一大因素。我认为，当每个参与人员知道大家都有平等的权利，许可方面无人享受特权时，他们最终会快乐得多。

有为数不少的“双重许可证”项目，原始所有者拥有商业许可证（“如果您向我们支付许可费，可以在您的专有产品中使用它”），另一方面，这种项目也采用GPL之类的许可证，供开源场合使用。

我认为围绕这种情况建立社区确实很难，因为开源方面总是知道它是“二等公民”。另外，这导致了许多许可文书工作，为了特殊方始终保留其特殊权利。因此，这给项目大大增加了不和谐的声音。

另一方面，我看到许多采用BSD（或MIT或类似许可证）的开源项目，当它们变得庞大得足以在商业上很重要时，就会碎片化或支离破碎，相关公司不可避免地决定将自己的组件专有化。

因此，我认为GPLv2几乎很好地兼顾了“每个人都遵循相同规则”这个宗旨，仍要求大家回馈社区。每个人都知道，所有其他相关方都受到相同规则的约束，因此做到公平公正。

当然，另一方面是您还可以取出您添加的东西。当然，您可以搭顺风车，“蹭”项目，就是一个用户而已，这没问题。但是如果这么做，您对项目毫无控制权。如果您其实只需要一款基本的操作系统，这完全没问题，因为Linux已经满足您的所有需求。但是如果您有特殊要求，想真正影响项目的唯一方法就是参与。

这确保大家都诚实，包括我。任何人都可以分叉（fork）项目，按自己的方式行事，然后说：“再见Linus，我要接手维护我的Linux版本的工作了。”我之所以“特别”，完全是由于大家相信我做得很好。本来就应该是这样子。

“谁都可以维护自己的版本”，这让一些人对GPLv2有所担忧，但我确实认为这是优点，而不是弱点。有点不合常理，但我认为这实际上促使Linux避免了碎片化：每个人都可以开发项目的分叉版，这没问题。实际上，这正是“Git”的核心设计原则之一——代码库的每个克隆版都是其自己的小分叉，而个人（和公司）分叉各自的版本其实是进行所有开发的做法。

因此分叉不是问题，只要您随后可以重新合并好的部分。而这时候GPLv2就有了用武之地。有权利分叉和做自己的开发很重要，但另一方面同样重要：当分叉被证明很成功时，有权利随后始终重新合并分支。

另一个问题是，您确实想拥有支持该工作流程的工具，但您也得有支持工作流程的理念。重新合并分叉的一大障碍不仅在于许可，还在于“恶感”。如果出于很敌对的原因开始分叉，合并两个分叉可能很难——并非由于许可或技术原因，而是由于分叉对抗很激烈。我认为Linux避免了这种情况，这主要是由于我们一直认为分叉是很自然的事情，因此某个分叉证明很成功后，试图重新合并也是很自然的事情。

因此，这个回答有点离题了，但我认为这很重要——我不后悔所选择的许可证，因为我确实认为GPLv2是Linux成功的一大因素。

钱的激励效果其实并不好，无法将大家团结在一起。我认为，有一个共同的项目，真心觉得您可以成为该项目的合作伙伴，这才会激发积极性。

JA：如今人们发布采用GPLv2的源代码时，通常是由于Linux才这么做。您是如何发现该许可证的？您又花了多少时间和精力来比较其他的现有许可证？

LT：

早在那时，BSD与GPL之争仍很激烈（我认为Richard Matthew Stallman确实有法子惹人恼火、引发争论），于是我通过订阅的各种Usenet新闻组（比如comp.arch和comp.os.minix等），看到了一些许可证方面的讨论。

但是两个主要原因可能就在于gcc（这款编译器对于Linux的运行至关重要，因为我绝对需要C编译器）以及Lars Wirzenius（“Lasu”），他是我读大学时的同窗好友。

Lasu在许可证讨论方面的研究比我深入得多。

在我看来，选择GPLv2不是多大的政治问题，主要是由于我的原始许可证是临时性的，需要更新，我对gcc心怀感激，而GPLv2符合我的“您得回馈源代码”这一期望。

因此，我不是创建另一种许可证（或者仅仅编辑原始许可证——仅仅删除“没有金钱易手”条款可能是一种选择），我想挑选大家已经了解的一个人，并请来了一些律师。

JA：您平日是怎样子的？多少时间花在了编写代码、审查代码以及收阅和撰写邮件上？您又如何兼顾个人生活和Linux内核方面的开发工作？

LT：

现在我编写的代码很少，很长时间没写代码了。我写代码时，最常见的情形是，对某个特定问题进行一番讨论，然后我做出更改，以补丁的形式发布，主要是对建议的解决方案加以解释。

换句话说，我编写的代码大多数主要是“瞧，我们这么做怎样”，而补丁是非常具体的例子。至于如何解决问题，很容易陷入一番理论上的总体讨论；我发现，描述解决方案的最佳方法常常是直接编写代码片段（也许不是全部代码），使解决方案非常具体化。

由于我的实际工作花在了收阅和撰写邮件上，主要侧重交流，而不是编程。实际上，我认为与新闻记者和技术博客作者的这种交流实际上是日常工作的一部分——它可能不如实际的技术讨论来得要紧，但我确实在这方面也花了大量时间。

没错，我也花一些时间来审查代码，但是坦率地讲，等我收到合并请求时，相应的代码通常之前已经被多人审查过了。因此虽然我仍查看补丁，但实际上往往主要查看解释以及补丁是如何出现在我眼前的。如果对方与我共事多年，我甚至都不查看：他们是子系统的维护者，我并不过分干涉他们的工作，放手他们去处理。

因此，很多时候我的主要工作是“就在那里”收集信息，负责管理和执行发布。换句话说，我的工作通常主要针对维护过程，而不是底层代码。

JA：您的工作环境是什么样的？比如说，您偏爱没有干扰的黑暗房间，还是有摆设的房间？您倾向于安静地工作还是边听音乐边工作？您通常使用哪种硬件？您在终端中使用vi还是使用高级的IDE来审查代码？还是，您是否有青睐的Linux发行版做这方面工作？

Threadripper

LT：

我的房间并非一片“黑暗”，但办公桌旁窗户的百叶窗确实关上，因为我不喜欢明晃晃的阳光照进来。因此没有其他摆设，只有一张（凌乱的）办公桌、两台4k显示器和办公桌下方一台功能强大的台式机。还摆着用于测试和外出时使用的几台笔记本电脑。

我喜欢安静地工作。我过去讨厌机械硬盘发出的声响，早就扔掉了这些硬盘，现在完全使用SSD已有十多年，嘈杂的CPU风扇声也让人受不了。

一切都在传统的终端中完成，但我不使用“vi”。我使用令人厌恶的micro-emacs，它与GNU emacs绝对毫无关系，只是一些按键绑定很相似。我在赫尔辛基大学时就习惯使用micro-emacs了，我还是离不开它，不过我觉得必须尽早摆脱它。几年前，我添加了utf-8支持它的功能（非常有限），但它确实显露老态，显示出了上世纪80年代编写的种种迹象，我使用的版本是自90年代中期以来就未得到维护的分叉版。

赫尔辛基大学之所以使用它，是由于它可以在DOS、VAX/VMS和Unix上运行，这就是我接触它的原因。我其实需要改用实际上得到维护，又适当支持utf-8的替代者，可能是“nano”。

因此，我的桌面环境很简单：打开的几个文本终端，以及带有电子邮件的Web浏览器（以及另外几个标签，主要是新闻和技术网站）。我希望有相当大的桌面空间，因为我习惯于有相当大的终端窗口（100x40是默认起始大小），我有多个终端并排打开。因此使用两台4k显示器。

我在所有系统上都使用Fedora，倒不是由于它一定是“首选”的，而是由于我习惯使用它。我对发行版不是太在乎——对我而言，发行版主要是在系统上安装Linux，设置好所有工具的一种方法，以便我随后可以替换内核、进行这方面的工作。

JA：Linux内核邮件列表是内核开发公开进行的地方，访问量极大。您如何跟进这么多的电子邮件？您是否考虑过除邮件列表之外的其他方法用于协作和交流，还是说有简单的邮件列表很适合您的工作？

LT：

哦，我并不直接阅读内核邮件列表，好多年不这么做了。上面的邮件太多了。

不，内核邮件列表的要点是，它基本上获得有关所有讨论的抄送。这样一来，新人加入讨论时，他可以通过查看内核邮件列表来了解来龙去脉和背景。

因此，我过去做的是订阅列表，但是将没有抄送我本人的所有lkml电子邮件自动归档，因此默认情况下我不会看它。但是当某个问题单逐级上报到我地方时，所有讨论都会显示，因为它就在我的电子邮件中，仅在需要时才出现在我的收件箱中。

如今，我实际上改而使用lore.kernel.org功能，因为效果很好，我们围绕它构建了另外一些工具。因此，不是自动归档在我自己的邮件归档中，讨论内容最终而是以这种方式呈现出来。但是基本工作流程在概念上一样。

很显然，我确实仍收到大量邮件，但从许多方面来看，情况一直在改善而不是恶化。这主要归功于Git以及内核发布流程有多顺畅：我们过去在代码流和工具方面遇到的问题多得多。早些年，我的电子邮件情况极其糟糕，那时我们仍处理巨大的补丁炸弹，并在开发流程方面遇到严重的可扩展性问题。

邮件列表（带有工具）模式确实效果不赖。这倒不是说大家除了电子邮件（个人邮件和邮件列表）外不使用其他交流方式：有人喜欢各种实时聊天方式（IRC是传统的聊天方式），一些人喜欢用它进行头脑风暴。但是“邮件列表作为归档”模式屡试不爽，与“以邮件的方式在开发人员之间发送补丁”和“以邮件的方式发送问题报告”理念无缝吻合。

因此，电子邮件仍然是主要的交流渠道，易于讨论技术问题，补丁嵌入在同一个渠道中。邮件对不同时区的人都适用，大家在地域上很分散时这非常重要。

JA：我密切关注内核开发差不多有10年，在KernelTrap上发表相关的博文，并撰文介绍不断改进的新功能。我在3.0内核发布时不再关注。是否可以总结一下自3.0版本以来内核方面发生的一些比较有意思的事情？

LT：

那是很久以前的事了，我甚至无法开始总结。自3.0以来已有10年，我们在那10年间进行了多次技术更改。ARM已发展壮大，ARM64已成为我们的主要架构之一，有了很多新的驱动程序和新的核心功能。

过去10年有意思的地方在于，我们实际上使实际的开发模式保持很顺畅以及有些方面并没有变化。

几十年来，我们经历了许多不同的版本编号方案，我们有不同的开发模式，但3.0版本实际上最终敲定了我们使用的模式。整个“基于时间发布，版本号只是数字，没有任何功能依赖性”观念多少成了官方立场。

我们在2.6.x时期通过合并窗口开始了基于时间的发布，因此这方面并无新意。但是3.0却标志着抛弃了“数字有意义”的残留痕迹。

我们使用了随机编号方案（主要在1.0之前），拥有完整的“奇数次版本号意味着开发内核，偶数次版本号意味着稳定的生产级内核”模式，然后在2.6.x中我们开始采用基于时间的发布模式。但是人们仍存在“提高主版本号需要具备什么条件”这个问题。3.0正式宣布连主版本号都毫无意义，我们将尽力使版本号易于处理，不让版本号变得太大。

因此在过去10年，我们进行了绝对重大的更改（Git使得一些统计数据很容易显示：100万次提交中约四分之三是17000多人完成的）。但是开发模式本身实际上相当顺畅和稳定。

其实并非总是如此。内核开发的前20年充斥着相当痛苦的开发模式更改。而过去这10年发布方面稳定多了。

JA：到目前为止，最新版本是5.12-rc5。发布流程有多标准化？比如说，哪些种类的变更进入到-rc1而不是-rc2？您在什么时候确定某个版本准备好正式发布？如果您有误，在最终版本发布后发现一个大的回归，会发生什么？出现这种情况的频次有多高？这些年来，这个流程出现了怎样的变化？

LT：

所以我前面提到过这一点：流程本身确实相当标准，过去10年一贯如此。在此之前经历过几次变动，但实际上自3.0以来，几乎稳定不变。

我认为，我们有了这样的节奏：“两周合并窗口”，随后是大约6-8周的发布候选，最后是最终版本发布，这已持续了近15年。

而规则始终一样，不过它们并未一直完全得到严格执行：合并窗口用于本应“测试并准备就绪”的新代码，然后大约两个月用于修正版，并实际确保所有问题都已解决。这种情况并非总是会发生，有时本该“准备就绪”的代码在发布之前被禁用或完全复原。

然后重复一遍，因此我们大概每10周发布一次。

我对发布标准很有信心，这显然基于仍在报告哪些类型的问题。如果某方面在发布候选的后期仍出现问题，我会非常主动地复原代码，说“一旦我们完全搞清楚这个问题，会在以后的版本中处理它”，但总的来说需要这么做的情况很少见。

总是奏效吗？并非如此。一旦内核发布（尤其是一旦发行版采用了内核），您就迎来新用户，他们在开发过程中并未测试内核，发现了我们在发布候选期间并没有发现的问题。这几乎是不可避免的。这就是为什么我们拥有整个“稳定内核”树，稳定内核树在发布后继续添加修正版。一些稳定内核的维护时间长于其他的稳定内核，它们被称为LTS（“长期支持”）内核。

这一切在过去10年基本上保持不变，不过我们最终落实了更多的自动化机制。内核测试自动化通常很难，一方面是由于内核的大部分是驱动程序，这些驱动程序显然依赖硬件的可用性，但是有几个farm同时进行启动测试和性能测试，并进行各种随机负载测试。多年来，这已经有了很大的改善。

JA：去年11月，媒体报道称苹果的一些新计算机中的新ARM64芯片给您留下了深刻的印象。您是否在密切关注Linux支持这些新芯片方面的开发工作？我看到编程工作被合并到for-next。Linux是否可能最早在即将发布的5.13内核上就能在苹果的MacBook硬件上启动？您可能会成为早期采用者吗？ARM64的重要性在于什么？

苹果M1 ARM64芯片

LT：

我偶尔在关注这方面，但为时尚早。如您所述，早期支持功能可能会合并到5.13中，但是您要意识到这实际上只是个开始，还没有通过Linux发挥苹果硬件的用途。

最终的问题不在arm64部分，而在于其周围硬件（尤其是SSD和GPU）的所有驱动程序。到目前为止，早期工作可以使一些真正底层的系统正常运行，但是除了早期的硬件支持外不会带来任何实用的效果。要使它成为人们尝试的真正选择还需要一段时间。

但是有所改善的不仅仅是苹果硬件，arm64的基础架构总体上已大有发展，核心已经从“平淡无奇”变成在服务器领域极具竞争力。不久前，arm64服务器领域还相当糟糕，但是亚马逊的Graviton2和Ampere的Altra处理器（两者都基于大幅改进的ARM Neoverse IP）比几年前的产品要出色得多。

10多年来我一直在等待有一台易用的ARM系统，现在还没有到来，但是显然比以前更接近了。

实际上，我很早以前就一直想要一台ARM机器；十几岁时，我真正想要的机器是Acorn Archimedes，但是可用性和价格让我选择了Sinclair QL（M68008处理器），几年后改而选择了i386 PC。

因此可以说这个梦想酝酿了数十年，但是ARM机器在市面上仍不广泛，性价比方面对我来说不具有竞争力。但愿不久的将来会梦想成真。

JA：内核中有没有并非最优，需要完全重写才能适当解决的部分？换句话说，内核已有30年的历史，知识、语言和硬件在这30年发生了很大的变化：如果您现在从头开始重写内核，会作何改变？

LT：

我们实际上在如有必要，完全重要这方面做得很到位，因此早已重写了任何会是彻头彻尾的灾难的代码。

当然，我们有很多“兼容”层，但它们通常并不可怕。尚不清楚如果从头开始重写，连那些兼容层是否真的会消失——它们旨在与较旧的二进制代码实现向后兼容（而且常常与较旧的架构向后兼容，比如在x86-64上运行32位x86应用程序）。由于我认为向后兼容非常重要，我希望即使在重写时也要保留向后兼容。

因此，从可以改进这方面而言，显然有很多部分“并非最优”，但就您提出的问题而言，我要说没有，没有我所鄙视的东西。有些遗留驱动程序是没人足够关心因而去清理的，因此它们可能表现欠佳，但是关键在于“没人足够关心”。这不是问题；如果真成为问题，我们就往往很积极地删除我们找不到任何人关心的遗留支持功能。因此，这些年来我们摈弃了很多驱动程序，当维护变得再也毫无意义时，我们摈弃了整个架构支持。

不，“重写”的唯一主要原因是如果您最终遇到整个结构不再有意义的几种使用场景。最可能出现的情况是一些小型嵌入式系统，它们根本不需要Linux提供的所有功能，硬件占用空间如此之小，以至于只需要比Linux更小巧更简单的系统。

由于Linux有了长足的发展，如今连小型硬件（比如手机等）的功能也比Linux开发所依赖的原始机器强大得多。

JA：用Rust这一种专门为性能和安全性设计的语言重写至少部分代码怎么样？这方面是否有改进的空间？您是否觉得像Rust这样的另一种语言有可能在内核中替换C？

Rust的非官方吉祥物Ferris

LT：

我们将拭目以待。我不认为Rust会接管核心内核，但是用它编写单个驱动程序（也许是整个驱动程序子系统）听起来并非完全不可能。也许还可以用Rust编写文件系统。因此，Rust不是“替换C”，更多的是在“必要的情况下补充我们的C代码”。

当然，特别是驱动程序占了实际内核代码的一半，因此这方面大有空间，但是我认为没有人真的期望完全用Rust重写现有驱动程序，更多的是“一些人会用Rust编写新驱动程序，在必要的情况下重写几个驱动程序”。

但是现在更多的是“有人在尝试和捣鼓Rust”，而不是有更大的动作。很容易看到其优势，但当然也有其复杂性，所以我持观望的态度，看看承诺的优势是否切实见效。

JA：内核的哪些特定部分是您个人最引以为豪的？

LT：

我往往会指出的突出部分是VFS（“虚拟文件系统”）层（尤其是路径名查找）和VM代码。前者是由于Linux在做一些基本的事情（查找文件名在操作系统中其实就是这样一种核心操作）方面比其他任何系统要好得多。而后者主要是由于我们支持20多种架构，我们仍使用基本上统一的VM层来实现，我认为这很了不起。

但是与此同时，这很大程度上与“您关注内核的哪个部分”有关。内核足够大，以至于不同的开发人员（和不同的用户）对最重要的部分会有不同的看法。有人认为调度是内核中最令人兴奋的部分，而有人注重设备驱动程序的细节（我们有很多驱动程序）。我个人往往更多地参与VM和VFS方面，因此自然提到这两方面。

JA：我找到了路径名查找的这番描述（https://www.kernel.org/doc/html/latest/filesystems/path-lookup.html），比我预期的要复杂。什么使Linux实现比其他操作系统中要好得多？您说的“更好”是什么意思？

LT：

路径名查找实际上是一种很常见很基本的操作，内核开发人员之外的大多数人甚至都不认为这是一个问题：他们只是打开文件，一切都视为理所当然。

但要真正做好实际上相当复杂。正因为绝对所有系统始终都在执行路径名查找操作，因此这非常注重性能，这也是您还希望在SMP环境中具有良好扩展性的那些方面之一，它在锁定方面很复杂。您也不想执行任何IO，因此缓存非常重要。实际上，路径名查找太重要了，您不能将其交给低级文件系统，因为我们有20多个不同的文件系统，让每个文件系统执行各自的缓存和各自的锁定将完全是一场灾难。

因此，VFS层所做的主要任务之一是实际处理路径名组件的所有锁定和缓存，并处理所有的序列化和挂载点遍历，使用基本上无锁的算法（RCU）来完成这一切，但是又使用一些非常巧妙的类似锁的东西（Linux内核的“locker”锁是非常特殊的“带有引用计数的自旋锁”，它实际上是为dcache缓存设计的，它基本上是一个专门的锁感知引用计数，可以为某些常见情况执行锁省略）。

最终结果：低级文件系统仍需要为未缓存的内容执行实际的查找，但是它们不必担心缓存以及伴随路径名查找而来的所有一致性规则和原子性规则。VFS可以为它们处理这一切。

Linux在这方面的表现胜过其他任何操作系统所做的机制，同时基本上可以完美地扩展，以支持拥有数千个CPU的计算机。即使那些机器最终都访问相同的目录，也可以执行这种操作。

因此，它不仅仅是“更好”，而是“好得多”。没有什么能与之匹敌。Linux dcache完全别树一帜。

JA：去年全球各地都很艰难。新冠疫情对内核开发流程有怎样的影响？

LT：

由于我们一贯以来的工作方式，新冠疫情的影响微乎其微。电子邮件确实最终是很棒的工具，我们也不依赖面对面的会议。

是的，新冠疫情确实影响了去年的年度内核峰会（今年峰会仍未定下来），大多数会议被取消或改为线上进行。以前在办公室工作的人大多开始在家工作（但是许多核心内核维护者早就在家工作了）。因此，许多非核心开发发生了变化，但核心开发本身与以前一样。

新冠疫情很显然从其他方面影响了我们所有人的生活，总体上只是社会层面的影响。但总的来说，作为几乎已经通过电子邮件与他人进行交互的内核开发人员，我们可能是受影响最小的一群人。

Git分布式版本控制系统

JA：Linux只是您对开源界的众多贡献之一。2005年，您还开发了非常流行的分布式源代码控制系统Git。您迅速将Linux内核源代码树从专有的Bitkeeper迁移到了新开发的开源Git，并在同年将维护权移交给了Junio Hamano。这背后有精彩的故事，是什么促使您如此迅速地移交了该项目的领导权？您是如何找到并选择Junio的？

Git徽标

LT：

这个分两部分来回答。

第一部分是，我其实不想开发一种新的源代码管理系统。创建Linux是由于我发现硬软件之间的低级接口引人入胜——这基本上出于热爱和个人兴趣的工作。相比之下，开发Git是出于需要：不是由于我觉得源代码控制很有意思，而是由于我绝对鄙视市面上的大多数源代码控制系统，我发现当初颇受欢迎、在Linux开发模式中确实运行良好的源代码控制系统（BitKeeper）已变得无以为继。

最终结果：我开发Linux已有30多年的时间（第一个发行版再过几个月就迎来周年纪念，但我在30年前就已开始开发后来成为Linux的内核），我一直在专职维护Linux。但是Git呢？我从来没有想过想要长期维护它。我喜欢使用Git，很显然我认为它是市面上最好的源代码控制管理系统，但它不是内心的热情和兴趣所在，您明白我说的话。

因此，我一直希望别人为我维护Git，实际上要是当初我没必要编写这样一个系统，会很高兴。

这就是那番背景。

至于Junio，他实际上是最早成为Git开发人员的人之一。在我公布Git的第一个很粗糙的版本后几天内，他开发的首个更改就出现了。因此，从Git诞生之初开始，Junio实际上就颇有知名度了。

但我不是将项目随便交给最先出现的人。我确实维护了几个月的Git，让我问起Junio是否想要成为维护者的是那个很难描述的“高品味”概念。我确实没办法更准确地描述：编程旨在解决技术问题，但是您如何解决技术问题、以及如何思考它们也很重要，您逐渐开始认识到：某些人有这种“高品味”，能选择“正确”的解决方案。

我不想说编程是门艺术，因为编程实际上就是“良好的工程”。我深信爱迪生的这句名言“百分之一的灵感加上百分之九十九的汗水”：关键几乎在于小小的细节和日常的枯燥乏味工作。但偶尔会有‘灵光乍现’，会有“高品味”，即不仅仅解决某个问题，而是干净、漂亮甚至优雅地解决问题。

而Junio就有那种‘高品味’。

每次提到Git，我都尽量非常明确地阐述它：我可能开创并设计了Git的核心理念，但是我常因这个系统而备受赞赏。Git已有15年的历史，我实际上只在头一年参与了Git。Junio一直是杰出的维护者，是他使Git成为今天的样子。

顺便说一下，这整个“高品味”概念，找到拥有高口品味的人，并信任他们，这不仅仅贯穿Git，还贯穿Linux的整个历史。与Git不同，Linux显然是我仍在积极维护的项目，但与Git一样，Linux也是另外许多其他人参与的项目，我认为Linux的一大成功就是拥有数百名维护者（无不拥有这种难以定义的“高品味”），以及维护内核各部分的所有人。

JA：您是否曾经将控制权交给某个维护者，后来却认定是错误的决定？

LT：

我们的维护体系从来没有如此的绝对和僵硬、以至于出现问题。我们确实有一个MAINTAINERS（维护者）文件，但这是为了可以找到合适的人选，它其实并不是表明某种专属所有权。

因此，“谁拥有什么”更像是一条灵活的指导方针，表明“这个人很活跃，工作做得很好”，而不是“哎呀，现在我们将所有权赋予那个人，然后他搞砸了。”

从某种意义上说，也许您是一个子系统的维护者，但如果您需要另一个子系统的某个组件，您常常可以跨越国界。当然，通常人们在行事之前进行广泛讨论。

由于其他许多项目使用CVS或SVN之类的工具，因而根本上确实使一些人很特殊，并且从根本上讲确实拥有“所有权”。在BSD界，他们称之为“提交比特”（commit bit）：为维护者授予“提交比特”意味着，他现在被允许将代码提交到中央代码库（或至少中央代码库的一部分）。

我始终讨厌这种模式，因为它不可避免地导致冲突纷争和“陈旧”的开发模式：某些人很特殊，被隐式信任。而问题甚至不在于“隐式信任”，而是另一方面在于，其他人不被信任，天生被视作外人，不得不通过一位监护人才能获得信任。

同样，在Git中不存在这种情况。人人平等。任何人都可以克隆，进行自己的开发，如果做得好，他们可以被重新合并（如果工作干得出色，他们可成为维护者，最终可以将代码合并到树中）。

因此，不需要赋予人们特殊的特权——不需要这种“提交比特”。这还意味着您可以避免这方面的冲突纷争，您不需要隐式信任他人。如果他们最终做得不好（或更常见的情况是，最终逐渐淡出，找到另一个感兴趣的项目），他们的代码不会被重新合并，也不会妨碍有新想法的其他人。

JA：Git的新功能有没有打动您，并成为您工作流程的一部分？有没有您仍然希望看到添加上去的功能？

LT：

我的使用场景显然是最先满足要求的，因此对我而言重点很少是新功能。

多年来，Git确实有了改进，它的一些功能在我的工作流程中也很显眼。比如说，Git一直非常快——毕竟这是我的设计目标之一，但它的许多功能最初是作为一些核心帮助程序方面的外壳脚本来完成的。多年来，大多数外壳脚本不复存在，这意味着我可以比原先更快地打上来自Andrew Morton的补丁炸弹。这让人非常高兴，因为这实际上是我用于性能测试的早期基准测试之一。

所以Git对我来说一直很好，而且在变得更好。

重大改进在于对于“常规用户”而言它日趋完善。主要在于人们学习Git工作流程，并开始适应它（Git与人们已习惯使用的CVS和及其他系统大不相同），但是关键在于Git本身变得用起来更称心如意。