作者 | Jeremy Andrews
译者 | 火火酱，责编 | Carol
出品 | CSDN（ID：CSDNnews）
Linux内核开发
记者：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：这要等等再看。我不认为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已经站不住脚了。
但之所以把项目交给朱尼尔，并不是因为他是第一个出现的人。在维护了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
60+专家，13个技术领域，CSDN 《IT 人才成长路线图》重磅来袭！
直接扫码或微信搜索「CSDN」公众号，后台回复关键词「路线图」，即可获取完整路线图！
☞“时隔 10 年，重新开始写代码的我要崩溃了！”
☞Google 宣布 Kotlin-first 已四年，为什么 Java 开发者仍不买账？
☞“32 位应用已死！”
文章评论