记者：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有何重大意义？
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语言吗？
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是因为我对发现硬件和软件之间的低等级接口很感兴趣——这基本上是出于热爱和个人兴趣的推动。相比之下，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本身变得更加方便使用了。
本文经原作者授权，由CSDN翻译，转载请注明来源，原文链接：
https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git
-END-
关注视频号，参与留言送书活动
↓↓↓↓
