↖  Linux操作系统30周年专访创始人Linus Torvalds-2..

（接续）

Jeremy：去年（2020年）11月，有人说你对苹果公司在其新电脑中的ARM64芯片印象深刻。Linux是否仍在支持他们的开发工作？Linux即将到来的5.13内核是否会在苹果的MacBook上启动？ARM64有何重大意义？

注：在2021年5月，Linux内核5.13-RC1版已实现对苹果M1的初步支持。当前仅支持启动，GPU的使用还未跟上，但也突破了最大的挑战，奠定了坚实的基础。

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

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

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

我等了十多年都没有等到一台可用的ARM机器，可能还要继续等下去，但显然，我们已经取得很大进展了。事实上，我想要ARM机器的时间远比想象中要久，当我还只有十几岁时，最想要的机器其实是Acorn Archimedes，但最终可用性和价格促使我选择了Sinclair QL（M68008处理器），几年后换成了i386 PC。

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

Jeremy：在内核中是否有什么不尽如人意的地方，需要彻底重写才能完全解决？内核已经有三十年了，技术、语言和硬件都发生了很大变化，如果现在从头开始重写，你会做哪些改变？

Linus：我们真的非常擅长完全重写，所以如果有不尽如人意的地方也早就被重写了。我们也有很多“兼容”层，但一般无伤大雅。而且尚不清楚如果重写的话，那些兼容层是否会真的消失——它们是对旧二进制文件的向后兼容（通常是对旧体系结构的向后兼容性，例如在x86-64上运行32位x86应用程序）。我认为向后兼容是非常重要的，所以希望即使在重写时也要保持这种兼容性。

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

不过，重写的唯一主要原因是——整个架构已经没意义了，但却还有一些用例。最有可能的情况是，一些小型嵌入式系统并不需要Linux提供的东西，而且其硬件空间很小，它需要的是比Linux更小、更简单的东西。因为Linux已经成长了很多。现在，即使是小硬件（比如手机等）也比当初开发Linux时使用的机器功能强大得多。

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

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

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

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

Jeremy：内核有哪个部分是你个人最引以为豪的吗？

Linus：个人认为是VFS（虚拟文件系统）层，尤其是路径名查找和我们的VM代码。前者是因为Linux在做基础任务时表现确实非常优秀（在操作系统中查找文件名就是操作系统中的基础核心操作）。后者主要是因为我们支持20多种架构，但仍使用基本统一的VM层，我认为这一点非常了不起。但与此同时，这很大程度上取决于“更注重内核的哪一部分”。我个人在VM和VFS领域的参与更多，因此自然也会选择这两方面的内容。

Jeremy：我发现关于路径名查找的描述比我想象得要复杂。是什么让Linux比其他操作系统“更好”的呢？你提到的“更好”可以怎么理解？

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

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

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

最终：底层文件系统仍然需要对未缓存的内容进行实际查找，但它们不需要担心缓存、一致性规则、以及与路径名查找相关的原子性规则。这些都由VFS来处理。而且它的性能比任何其他操作系统都要好，基本可以完美扩展到拥有数千个CPU的机器上，即使这些机器最终都会接触相同的目录。所以Linux dcache是独一无二、无可匹敌的。

2.Git的维护之路

Jeremy：除了Linux，你还创建了Git并移交了这个项目的领导权至Junio Hamano（滨野纯，以下简称Junio），是什么让你这么快做出决定？以及是如何找到并选择他的？

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

首先，我并不想创建新的源码控制系统，Git的诞生完全是出于需要。并不是我觉得源代码控制很有意思，而是因为我完全看不上当时市面上大多数源代码控制系统，包括在Linux开发模型中运行得很好的BitKeeper也无法满足我的需求了。

相比之下，我做Linux已经有三十多年（加上研究的时间)，并且一直在对其进行维护，但我从未想过要长期维护Git。我喜欢使用Git，而且我认为它是目前市面上最好的SCM，但这不是我的热情和兴趣所在，因此，我一直希望由别人来替我维护SCM。

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

但之所以把项目交给Junio，并不只是因为他“来得早”。在维护了Git几个月后，真正让我决定邀请Junio担任维护者的因素，是一个比较抽象的概念——“好品味”。编程依赖的也是各种细枝末节和每日的繁重工作，偶尔也会需要所谓的“灵感”，即“好品味”，它能干净、漂亮，甚至是完美地解决问题。

编程是为了解决技术问题，但如何解决这些问题，以及如何思考也是非常重要的。随着时间的推移，你会清楚地认识到：有些人就是有那种“好品味”，能够做出“正确的”选择。

而Junio就具备这种“好品味”。

每次提到Git，我都会尽量讲得非常清楚，虽然确实是我提出并设计了Git的核心思想，但Git这十五年来，我只有在第一年亲自参与了项目工作，Junio一直都是一名优秀的维护者，是他让Git有了今天的成就。

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

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

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

因此，“谁拥有什么权利”更像是一个流动性指导，以及“这个人很活跃，而且做得很好”。整个结构体系都是流动的，可能你是一个子系统的维护者，但如果你需要另一个子系统的东西，是可以跨越边界的。一般这种情况大家都需要提前进行沟通，但重点是它确实可以实现，这绝对不等同于“你只能动这一个文件”之类的硬性规定。

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

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

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

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

开源之力

1.开源项目的管理

Jeremy：作为开源项目的维护者，你学到了哪些重要的经验教训，可以帮助其他人更成功地管理他们的项目？

Linus：这是一个很难回答的问题，因为我真的不知道成功的关键是什么。虽然Linux非常成功，Git也站稳了脚跟，但我很难说二者成功的深层次原因究竟是什么。天时、地利、人和都非常重要。对于Linux和Git来说，最重要的是这两个项目恰好满足了很多人的需求，或者是因为很多人都有这样的需求，但我是唯一一个站出来创建了这样的项目，并取得了成功的人？我个人更倾向于后者，选择很重要，运气也很重要。

另一方面，我觉得对于开源维护者而言，确实需要一些务实的精神和思想，这很重要。

首先，你必须时刻关注其他开发人员。当你遇到技术难题时，可以与他们交流，可能会有不同的想法。

难的部分在于，你可能需要和自己不太喜欢/不太喜欢你的人交流，最终可能会导致双方都很不爽，但必须克服这些困难完成工作。我想说的是，维护一个大项目需要付出大量努力，而且你需要付出长期的努力，这不是儿戏。

其次，你必须保持开放的心态。我们很喜欢建立一个内部的小圈子，私下讨论问题，只公开最终的结果。但是“开放”也代表要勇于接受别人的解决方案，遇到问题时不要轻易地下结论，思想一定要灵活。Linux成功的原因之一就在于，我并没有制定宏伟的计划，甚至对项目的发展都没有很高的期望，因此当人们向我发送补丁程序或功能请求时，我欣然接受了，因为我对Linux应有的模样没有先入为主的执念。最终结果是，所有希望参与Linux内核开发的个人（以及后来的大公司）都拥有自由发挥的空间，因为我对Linux持开放态度。

最后，诚实也很重要。你应该坦诚地告诉人们你的动机、项目的初衷以及项目的内容。你不必喜欢每一个共事的伙伴，他们也不必喜欢你，但是如果每个人都坦诚地说出自己的目标和工作内容，那么即便你们不是最好的朋友，至少你们可以互相信任，因为信任非常重要。

在维护开源项目的过程中，压力肯定是有的。有时我也会感到厌烦。自己要学会调节，我会适当放松或安排休假，只要把工作安排好即可。

Jeremy：除了上述你提到的有关减少编写的代码量，增加沟通和领导之外，你还需要掌握哪些特定的技能？你又是如何学习这些技能的呢？

Linus：所有的经历对我来说都是一个循序渐进的过程，三十年是一个漫长的过程，今日的一切都不是一蹴而就的，而大多时候我们的做事方式都是“顺其自然”。

换句话说，这一切都不是我们的计划，也不是从课本上学习来的结果。Linux项目本身是自然发展而来的，如今我们拥有的任何结构都不是来自某种理论的组织结构图，而是人们自发地找到了“自己的位置”。

很多人都会觉得“放权”很难。其实早年间有人给我发送补丁，但我并没有直接使用，我会阅读他们的代码，搞清楚他们想要什么，然后自己重新写代码。然而事实证明，我这样做并没有什么用，因为我很懒，所以决定在阅读并理解补丁后直接使用。因此，我眷恋权力的日子很快就过去了。信任他们，不要对他们进行过多的微管理。

因此，将项目委托给别人也不是一个大问题（当然我知道有些项目情况大不同），归根结底，部分原因是我们的维护模型不需要某种绝对的信任，因此情况就简单了许多。

另外，沟通技巧非常重要。我出生于一个新闻记者家庭，读书和写作是每个人都喜欢的事情。

虽然英语是我的第三语言，但是当我建立Linux项目的时候，已经可以熟练地使用英语交流了。总的来说，大部分时间里，我都是在一边工作一边学习。再说一次，Linux的成功不是一蹴而就。我们经过了三十年的努力，这个项目才有了如今大不同的局面。

Jeremy：尽管开源取得了巨大的成功，但现状却是有些开发人员每周的收入甚至连买一杯咖啡都不够。你认为这个问题可以得到解决吗？开源模型是否可持续？

Linus：说实话，我没有答案，出于某种原因，Linux内核始终没有遇到这个问题。有些公司是纯粹的Linux“用户”，但他们仍然需要支持，因此最终他们还是会依赖承包商或Linux发行版，而这些公司最终也成为了内核开发人员的主要收入来源之一。

Linux内核开发社区在商业利益方面也取得了一定的成功。Linux一直向商业用户开放，而且我有意避免了“反对企业”的心态。我认为GPLv2是一个非常出色的许可，但与此同时，我一直反对某些极端的“自由软件”形式。

坦白来说，我一直很谨慎地保持中立，不希望Linux被商业利益左右。例如，我有意避免为某家Linux公司工作。我希望人们看到我是中立的，不希望别人把我当成一个竞争对手。

但是我认为，有些项目可能太过于排斥商业化而陷入了困境，即便有公司希望介入，也很难有机会。虽然和其他公司展开合作并非易事。我们有几个内核维护者一直在非常积极地教各个公司如何使用开源，这也是Linux基金会的一项重任。

我个人百分百相信开源代码不仅可以持续下去，而且在一些复杂的技术问题上，你必然会用到开源代码，因为这些问题太过于复杂，仅靠某个公司内部无法解决，即便是科技巨头也会力不从心。

但这确实需要双方都保持一定开放性，毕竟并非所有公司都能成为优秀的合作伙伴，而且某些开发人员也不一定要与大公司合作。

2.Linux基金会

Jeremy：Linux基金会是怎样创建的？你的角色是什么？这个基金会除了让你不必为商业Linux公司工作就可以获得报酬之外，对Linux内核还有什么其他的影响？

Linux基金会Logo

Linus：我并没有参与OSDL（开源开发实验室，后来的Linux基金会）。实际上我只是一名员工。

最初OSDL是一个非营利行业联盟，尤其是企业级的协作。最初他们提出为开发人员提供计算机实验室，这一切都是我与他们展开合作之前。

后来OSDL与另一个非营利性行业联盟自由标准组织合并，并成立了Linux基金会。于是，“行业合作”成为了主导力量。而我只是他们的员工，我一直专注于技术内核的开发。

Linux基金会除了支持我们这些核心开发者以外，还构建了各种各样的基础架构，比如一些技术性的架构（kernel.org等），他们还做了很多支持工作，比如组织会议、为行业合作伙伴设立工作组等等。而我只是一名员工，只不过我们之间的协议有点不寻常，因为我所做的一切都必须是开源的，而Linux基金会也不能干涉Linux的开发，这无论是对于我还是其他参与开发的公司都是双赢的状况，因为我不受任何公司政策限制。

本文已获作者翻译授权，原文：

[1] 30 Years Of Linux, An Interview With Linus Torvalds: Linux and Git - Part 1, https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git

[2] An Interview With Linus Torvalds: Open Source And Beyond - Part 2, https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2

本页Url