【编者按】1991年8月25日，21岁的Linus Torvalds（以下简称Linus）做了一个免费的操作系统“Linux”，并在这一天向外界公布这个由“业余爱好”主导的个人项目；现在，环球超级计算机500强和超过70%的智能手机都在运行Linux，因此，8月25日也被很多Linux的爱好者视为Linux真正的诞生日期。
30年来，Linus一直领导着Linux内核开发，并在2005年创建Git。在Linux 30周年之际，Linus接受了Tag Consulting创始人&首席执行官采访Jeremy Andrews（以下简称Jeremy）的采访，深入谈起30年来管理如此大型开源项目的履历与思考。
[size=1.176em]— 01 —
[size=1.176em]Linux与Git
[size=0.882em]Linux内核之旅
Jeremy：今天，Linux将迎来它的30周年事念日。在这段旅程中，你是在什么时候意识到自己所做的Linux并不仅仅“只是一个爱好”的？
Linus：我很早就意识到这一点。在1991年末（以及1992年初），Linux已经比我预想的要大很多。当时可能只有几百个用户（甚至都不能算是“用户”，人们只是在不断地对其进行修补），虽然其时还不至于考虑将Linux发扬光大，但就个人而言，最大的迁移变化点是当我意识到真有人在利用它，并对它感兴趣时，它开始有了自己的生命。人们开始发送补丁，而且我徐徐发现这个系统能够完成的事情远比预想的要多。
[size=0.706em]Linux 30周年官方海报
在我的影象中，X11大概是在1992年4月被移植到Linux上的，这可以算是又一里程碑式的大动作：GUI以及一套全新的功能横空问世。从这个角度来看，我最初并没有什么高期望的大筹划。它只是个人项目，也并非出于什么创造新的操作系统的伟大空想，只是由我对新PC硬件的深入学习而逐渐发展演变形成的。
因此，第一版现实上更像在说“快来看！我做了一个新东西”。我当然渴望各人会以为它很有趣，但当时它并不是一个真正严谨且可用的OS。它的存在更像是为了证明概念的可行性，是仅用几个月完成的个人项目罢了。
从个人项目到有人利用、发送反馈及偶尔的补丁，这对我来说是一个巨大的变化。
举一个最基本的例子：在原始版本中，可以用源代码的情势发布，但不能盈利。由于对其时还是学生的我来说，贸易UNIX太贵了。对我而言，源代码可用好坏常紧张的，只有这样人们才气对其进行修补，而且我渴望它能对像我这样负担不起其他选择的人开放。
我在1991年底（或1992年初）把允许证改成了GPLv2，由于有人想把它以软盘的情势分发给本地UNIX用户组，同时渴望能至少收回软盘成本和时间成本，而这个诉求其实是完全合理的。“免费”不是最紧张的，“源代码公开”才是。
最终的结果是：人们不仅在UNIX用户组会议上进行了发行，而且在短短的几个月内便出现了SLS（Softlanding Linux System）和Slackware等早期软盘发行版。
除了那些最初的根本性变化，其他统统都是“渐进式”的。当然，有些渐进变化是相当大的（IBM的加入、Oracle DB移植、Red Hat的首次公开募股、Android在手机上的应用发展等等），但对我而言，这些变化都不如最初发现有很多人都在利用Linux那么具有革命性。
Jeremy：你是否曾为自己的允许证选择后悔过？大概曾为其他人/公司从你创造的系统上赚了多少钱而后悔？
Linus：从未后悔过。首先，我过得还不错。虽然并不算特别富有，但作为一名高薪的软件工程师，我可以按照自己的节奏做喜好做的事，保持一个相对舒适的状态。
与此同时，我100%地相信允许证是Linux（以及Git）成功的紧张组成部分。我始终坚信要让各人都知道自己具有平等的权利且没有人在允许方面享有特权，这对全部人来说都是一件好事。
现在，有非常多的“双允许证”项目：原始全部者保存了贸易允许证（支付允许证费用便可在自己的专利产物中利用它），但另一方面，该项目也可以在GPL（通用公共允许证）等情况下开源。
我认为要想在这种情况下建立社区好坏常困难的，由于开源的一方总是知道自己的“二等公民”身份。另外，要想让享有特权的一方始终保持其特殊权利，必然需要大量的允许文件，这给项目增长了很多额外的阻力。
另一方面，我见过很多BSD（或MIT等）允许的开源项目，当其规模逐渐扩大到具有贸易紧张性时，就会走向四分五裂的局面，相关公司必然会把属于自己的部分变成专有的部分。
我认为GPLv2能够实现“全部人都在相同规则下工作”与“要求人们回馈社区”的完美均衡，各人都受同样的规则束缚，非常公平公正。
同样，你的投入也会得到相应的回报。你可以当项目的“旁观者”，但也就失去了项目的控制权；也可以只把Linux当做一个基本的操作系统；但假如你有特殊要求，那么能对项目产生真正影响的唯一方法就是到场进来。
在这种情况下，包括我在内的全部人都要保持老实。任何人都可以对项目进行分叉，走自己的路，然后接受自己的Linux版本维护。我的特别仅仅在于人们相信我能把工作做好，而这本就是天经地义的事情。
“任何人都可以维护自己的版本”这一点让一些人对GPLv2产生了怀疑，但我认为这是一种上风。正是这一点保护Linux逃过了分裂的结局：每个人都可以完成自己的项目分支。事实上，这也是“Git”的核心设计原则之一——存储库的每个克隆都是自己的小分支，开发者（或公司）要想真正完成项目开发的话，则需要从中分叉出去。
以是分叉自己不是问题，只要你能把好的部分合并回来即可，这就是GPLv2的意义所在。要保障各人具备进行分叉并实现个人项目的权利，但与此同时，也要保证当分叉成功时，各人也有权利能再次将其融合回来。
另一个问题是，各人都想拥有能够支持项目生产的工具，与此同时，心态也一定要强大。将分叉融合回来的停滞，不仅是允许证，另有“Bad Blood”的问题。假如两个分叉从根本上就非常对立的话，那么要想将它们融合好坏常困难的——并不是由于允许证或技能原因，而是由于分叉过于尖锐对立。同样，我认为Linux很好地避免了这一点，主要是由于我们一直认为分叉是一件非常正常且天然的事情；当其证明白自身的成功后，天然也要合并回来。
虽然这个答案大概有些跑题，但我认为这一点非常紧张——我从未后悔过自己的允许证选择，由于我真心认为GPLv2是Linux能够取得成功的紧张原因。
金钱其实并不是一个很好的鼓励方式，由于它并不能将人们团结在一起。我认为，真正能够起到鼓励作用的是：人们到场到一个共同的项目中来，并真正感觉到自己可以成为这个项目的全面互助伙伴。
Jeremy：现在人们在GPLv2下发布源代码，通常都是由于Linux。你是如何寻找允许证的？在检察现有允许证上投入了多少时间和精力？
Linus：其时，人们仍对BSD和GPL有较大争论，我会在欣赏各Usenet新闻组时看到一些有关允许证的讨论。
但最主要途径的有两个：一是GCC。它对Linux的发展起了很大作用；二是Lars Wirzenius（昵称Lasu），他是当年我大学里另一个说瑞典语的CS同学。Lasu比我更喜好讨论允许证之类的事情。
对我来说，选择GPLv2并不是什么庞大原则性决定，主要是由于我原来的临时允许证亟待更新，我很感激GCC，但GPLv2更符合我“你需要把源代码还回来”的期望。因此，与其设立新的允许证（大概只对旧的允许证进行修改），我更渴望能挑选一个已经为人所熟知，且有律师到场的允许证。
Jeremy：人们通过Linux内核邮件列表进行公开的内核开发，而且流量非常大。你如何兼顾这么多邮件？有没有探索过邮件列表之外的其他互助沟通解决方案？还是说简便的邮件列表对你的工作而言就是完美的？
Linus：我已经很多年没有直接阅读过内核邮件列表了，实在是太多了。内核邮件列表的意义在于可以将内容抄送给全部人。当有新人加入讨论时，可以通过查看内核邮件列表来了解历史沟通记载。
我之前订阅了列表，设置将全部没私人抄送的LKML邮件都自动归档，默认不显示。当有问题需要处理时，我也能找到全部的相关讨论。全部内容都储存在电子邮件中，但只有在需要时才会出现在收件箱。
最近，我一直都在用lore.kernel.org的功能，它非常好用，而且我们另有一些围绕其构建的工具。因此，邮件讨论内容就不必自动归档在邮箱里，可以用另一种方式呈现，但其基本的工作流程是相同的。
当然，我仍会收到非常多的Email，但这些年来情况已经在徐徐转好。此中很大一部分原因是Git及内核发布流的完美运作，不会再碰到像本世纪初当时一样的各种代码流和工具方面的问题。
附带工具的邮件列表确实非常好用。并不是说全部人都只用电子邮件大概线下见面沟通，也有人喜好各种实时聊天设置（其时另有IRC）。但“邮件列表存档”模式非常好用，并且能无缝衔接“开发者之间以邮件方式发送补丁”和“以邮件方式发送问题报告”。
因此，电子邮件仍是主要的沟通渠道，补丁可以被嵌入同一媒介，简化了技能讨论流程。而且它能实现跨时区工作，当各人在异地工作时，这一点就显得尤为紧张了。
Jeremy：3.0内核与之前的2.6.x版发布之间隔了整整八年。自3.0版本发布以来，内核有没有发生什么更有趣的事情呢？
Linus：3.0距今也有十年了，在这十年中我们的技能发生了很大变化。ARM发展成熟了，ARM64也已成为主要架构之一，拥有很多新的驱动程序和核心功能。已往十年的有趣之处在于“我们是如何保持现实开发模型安稳”的，以及“什么东西没有变”。
几十年来，我们推出过很多不同的版本方案以及多个开发模式，但3.0版本最终确定了我们一直以来利用的模式。它真正实现了“基于时间，版本号只是数字，不依附于任何功能”的说法。在2.6版本中，就具备合并窗口的“基于时间”的概念，因此这并不特别，但3.0是“最后一片拼图”。
我们有随机编号方案（主要是在1.0之前），其规则是：小数点后奇数表现开发内核，偶数表现稳固的生产内核。在2.6中，我们开始做基于时间的发布模式。但仍然存在“何时增长主版本号”的问题。而3.0的正式出现表现，主版本号并没有什么特殊意义，只是为了只管简化数字，不要让它太长太繁琐。
因此，在已往的十年里，我们做了非常大的改变。但开发模式自己其实一直都相当安稳。
事实上，内核开发的前二十年中，开发模式一路走来经历了很多坎坷，只是在已往十年里，发布的可预测性才大大进步了。
Jeremy：最新版本Linux 5.14即将来临。发布过程的标准化程度如何？例如，什么样的变化会进入RC1、RC2等等？你是在什么时候才会决定特定版本是否可以正式发布？假如版本有错误，在版本发布后宣布撤回的话会发生什么？这种情况的发生频率高吗？这一过程多年来是如何演变的？
Linus：这个过程自己是有一定标准的，并且在已往十年一直如此。它曾经历过几次剧变，但现实上从3.0开始其运转就如时钟般稳固了（甚至还会更早一些，由于人们要顺应Git还要一定的时间）。
因此，我们形成了相对固定的节奏：在最终版本发布之前，有约两周的合并窗口时间，然后每周约6-8个候选版本，到现在已经有近15年了。
规则没有变过，但不一定完全严格执行：合并窗口是为假定“已经过测试和准备好”的新代码准备的，然后在接下来的约两个月里进行修改，确保全部问题都能得到妥善解决。但有时在发布之前，那些“已经准备好”的代码也会被禁用或彻底推翻，然后重新再来，以是我们大约每10周左右就有一次发布。
发布标准是我自身要对该版本有足够的信心，而这种信心要建立在递交上来的问题报告的底子上。假如某部分在RC后期仍出问题的话，我们会积极修改，并牢记不再犯，但总体而言，这种情况是相当罕见的。
发布了就一定会取得成功么？当然不是。内核一经发布，就会产生新的用户，此中不乏没有到场开发测试的人，而他们常常会发现一些我们在RC中没有发现的问题，这种情况无法避免。这也是我们需要“稳固内核树”的原因之一，它能够在发布后继续添加修复。一些稳固内核的维护时间比其他内核更长，因此也被称为LTS（Long-term support）内核。
全部这些在已往的十年里都没有什么变化，只是有了更完善的自动化流程。一般来说，内核测试的自动化是很困难的，部分原因是：很多内核都是驱动程序，这依赖于硬件的可用性。但有几个测试场同时进行启动和性能测试，并进行各种随机负载测试，以是近年来情况已经有了很大改善。
Jeremy：客岁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是独一无二、无可匹敌的。
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”。这样我们就可以避开政治小团体，也不需要“隐性信任”。假如他们最终做得不好、大概找到了其他兴趣，他们就不会合并回来，也不会妨碍其他有新想法的人。
— 02 —
开源之力
[size=0.882em]开源项目的管理
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基金会的一项重任。
我个人百分百相信开源代码不仅可以持续下去，而且在一些复杂的技能问题上，你必然会用到开源代码，由于这些问题太过于复杂，仅靠某个公司内部无法解决，即便是科技巨头也会力有未逮。但这确实需要双方都保持一定开放性，毕竟并非全部公司都能成为优秀的互助伙伴，而且某些开发职员也不一定要与大公司互助。
[size=0.882em]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
操作系统主题书单
NO.1
鸟哥的Linux私房菜 底子学习篇 第四版
内容简介：
本书是最具知名度的Linux入门书《鸟哥的Linux私房菜 底子学习篇》的最新版，以CentOS 7.x为蓝本，全面而详细地介绍了Linux操作系统。本书内容丰富全面，基本概念的讲解非常细致，深入浅出。各种功能和下令的介绍，都配以大量的实例操作和细致的解析。本书是初学者学习Linux不可多得的一本入门好书。
NO.2
Linux就该这么学
内容简介：
本书旨在打造最简单易学且最具实用性的Linux入门教程，其内容涵盖了最底子的Linux系统安装到各种高级服务的摆设（如iptables和firewalld、SSH、Apache、vsftpd、Samba、BIND、DHCP、Postfix、Dovecot、Squid等）。本书还覆盖了红帽RHCSA+RHCE认证的考试内容。通过本书，读者可以迅速入门Linux，为Linux的进阶打好坚固的底子。
NO.3
UNIX/Linux 系统管理技能手册（第5版）
内容简介：
本书延续了《UNIX系统管理技能手册》前几版的讲解风格，以当前主流的Linux发行版本为例，把Linux系统管理技能分为4个部分分别进行介绍。第一部分（底子管理）对UNIX和Linux系统进行了简介，涵盖了运行单机系统所需的大部分知识和技能。第二部分（连网）讲解了UNIX系统上利用的协议和服务器的相关技能。第三部分（存储）讲解了如何解决数据存储和管理的问题。第四部分（运维）介绍了系统管理员在工作中经常碰到的问题。本书适用范围广泛，无论是Linux的初学者还是具有丰富履历的Linux专业技能职员都能从本书中获益。
NO.4
奔跑吧Linux内核（第2版）卷1：底子架构
内容简介：
本书基于Linux 5.0内核的源代码讲述Linux内核中核心模块的实现。本书共9章，主要内容包括处理器架构、ARM64在Linux内核中的实现、内存管理之预备知识、物理内存与虚拟内存、内存管理之高级主题、内存管理之实战案例、历程管理之基本概念、历程管理之调度和负载均衡、历程管理之调试与案例分析。本书适合Linux系统开发职员、嵌入式系统开发职员及Android开发职员阅读，也可供计算机相关专业的师生阅读。
NO.5
奔跑吧Linux内核（第2版）卷2：调试与案例分析
内容简介：
本书基于Linux 5.0内核的源代码讲述Linux内核的调试技巧和案例。本书共6章。主要内容包括并发与同步，中断管理，内核调试和性能优化，基于x86_64的宕机困难解决方案，基于ARM64的宕机题解决方案，安全漏洞的产生原理与修复方案等。本书适合从事Linux系统开发职员、嵌入式系统开发职员及Android开发职员阅读，也可供计算机相关专业的师生阅读。 | 
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
