本文共 8053 字，大约阅读时间需要 26 分钟。

Linus Torvalds谈Linux内核开发与Git

在本文的访谈中，重点讨论了Linux内核开发和Git的创建与发展。

Linux内核开发

记者：Linux无处不在，它是整个开源世界的灵感源泉。当然，它也不是从一开始便能获得如此成就的。早在1991年，您便在comp.os.minix上一个不起眼的Usenet帖子中发布了著名的Linux内核。十年后，您写了一本书——《只是为了好玩：偶然发明趣事》（Just for Fun: The Story of an Accidental Revolutionary）。今年8月，Linux将迎来它的30周年纪念日。在这段旅程中，您是在什么时候意识到自己所做的Linux并不仅仅“只是一个爱好”的？

Linus：听起来可能有点荒谬，但其实我很早就意识到这一点了。在1991年末（以及1992年初），Linux就已经比我预想的要大得多。

那个时候，可能只有几百个用户（甚至都不能算是“用户”，人们只是在不断地对其进行修补），要说我在当时就开始考虑Linux后来将如何发展壮大的话，听起来可能会有点可笑。但就我个人而言，最大的转折点是当我意识到真的有人正在使用它，并对它感兴趣时，它开始有了自己的生命。人们开始发送补丁，而且我渐渐发现这个系统能够完成的事情远比我预想的要多得多。

我记得X11好像是在1992年4月的某个时间被移植到Linux上的（具体日期记不清了，毕竟那已经是很久之前的事情了），这可以算是又一里程碑式的大动作，GUI以及一套全新的功能横空问世。

从这个角度来看，我最初并没有什么高期望的大计划。它只是一个个人项目，也并不是出于什么创造新的操作系统的伟大梦想，它只是由我对新PC硬件的深入学习而逐渐发展演变形成的。

**因此，我发布的第一个版本实际上更像是“快来看！我做了一个新东西”。我当然希望大家会觉得它很有趣，但它并不是一个真正严谨且可用的操作系统。**它的存在更像是为了证明概念的可行性，只是我花了几个月时间就完成的一个个人项目而已。

从“个人项目”到“有其他人使用、发送反馈（和bug报告）、以及偶尔的补丁”，这对我来说是一个巨大的转变。

举一个最基本的例子：在原始版本中，你可以以源代码的形式发布，但不能盈利。 那是因为对当时的我来说，商业unix太贵了（至少对于一个把所有钱都花在新PC上的穷学生党来说非常贵）。所以对我而言，源代码可用是非常重要的，只有这样人们才能对其进行修补，而且我希望它能对像我这样负担不起其他选择的人开放。

我在1991年底（或者1992年初）把许可证改成了GPLv2，因为有人想把它以软盘的形式分发给本地Unix用户组，但又希望至少能收回软盘的成本以及其复制时间。我才意识到这个要求完全合理的，重要的不是“免费”，而是“源代码需要公开”。

最终的结果是：人们不仅在Unix用户组会议上进行了发行，而且在短短的几个月内便出现了SLS和Slackware等早期软盘发行版。

除了那些最初的根本性变化，其他一切都是“渐进式”的。当然，有些渐进变化是相当大的（IBM的加入、Oracle DB移植、Red Hat的首次公开募股、Android在手机上的应用发展等等），但对我而言，这些变化都不如最初“我甚至不知道这些人都在使用Linux”那样具有革命性。

记者：您是否曾为自己的许可证选择后悔过？或者曾为其他人或公司从你创造的系统上赚了多少钱而后悔？

Linus：从未后悔过。

首先，我过得还不错。虽然并不算特别富有，但作为一名高薪的软件工程师，我可以按照自己的节奏做我喜欢做的事，保持一个相对舒适的状态。

与此同时，我100%地相信许可证是Linux（以及Git）成功的重要组成部分。我始终坚信要让大家都知道自己具有平等的权利且没有人在许可方面享有特权，这对所有人来说都是一件好事。

现在，有非常多的“双许可证”项目：原始所有者保留了商业许可证（“如果你向我们支付许可证费用，你便可以在自己的专利产品中使用它”），但另一方面，该项目也可以在GPL等情况下开源代码。

我认为要想在这种情况下建立社区是非常困难的，因为开源的一方总是知道自己的“二等公民”身份。另外，要想让享有特权的一方始终保持其特殊权利，就必然需要大量的许可文书工作，而这给项目增加了很多额外阻力。

另一方面，我见过许多BSD（或MIT等等）许可的开源项目，当其规模逐渐扩大到具有商业重要性时，就会走向四分五裂的局面，相关公司必然会决定将自己的部分变成专有部分。

我认为GPLv2能够实现“所有人都在相同规则下工作”与“要求人们回馈社区”的完美平衡。大家都知道所有参与其中的人都受同样的规则约束，所以这是非常公平公正的。

**同样，你的投入也会得到相应的回报。**当然，如果你想只做一名用户，在项目方面保持“旁观者”姿态的话也是可以的，只是这样你便失去了对该项目的控制权。如果你只是需要一个基本的操作系统，而Linux已经可以实现你想要的所有功能的话，那么也完全没问题。但如果你有特殊要求，那么能对项目产生真正影响的唯一方法就是参与进来。

在这种情况下，所有人（包括我在内）都要保持诚实。任何人都可以对项目进行分叉，走自己的路，然后告别：“再见了，Linus，我要接管我的Linux版本的维护。”我之所以特别，仅仅是因为人们相信我能把工作做好。而这本来就是理所当然的事情。

“任何人都可以维护自己的版本”这一点让一些人对GPLv2产生了怀疑，但我其实认为这并不是劣势，而是一种优势。我认为，正是这一点保护Linux逃过了分裂的结局：每个人都可以完成自己的项目分支。事实上，这也是“Git”的核心设计原则之一——存储库的每个克隆都是自己的小分支，而人们（和公司）要想真正完成项目开发的话，则需要从中分叉出去。

**所以分叉本身不是问题，只要你能把好的部分合并回来即可。这就是GPLv2的意义所在。**要保障大家具备进行分叉并实现个人项目的权利，但与此同时，也要保证当分叉成功时，大家也有权利能再次将其融合回来。

另一个问题是，大家都想拥有能够支持项目生产的工具，但同时，也要具备相应强大的心态。将分叉融合回来的障碍并不仅仅是许可证或技术原因，而是因为分叉过于尖锐对立。

同样，我认为Linux很好地避免了这一点，主要是因为我们一直认为分叉是一件非常正常且自然的事情；当其证明了自身的成功后，要合并回来同样也是非常正常且自然的。

尽管这个答案或许有点跑题了，但我认为这一点非常重要——我从未后悔过自己的许可证选择，因为我真心认为GPLv2是Linux能够取得成功的重要原因。

金钱其实并不是一个很好的激励方式，因为它并不能将人们团结在一起。我认为，真正能够起到激励作用的是：人们参与到一个共同的项目中来，并且真正感觉到自己可以成为这个项目的全面合作伙伴。

记者：现在，人们在GPLv2下发布源代码，通常都是因为Linux。您是如何寻找许可证的呢？您在审查现有许可证上投入了多少时间和精力呢？

Linus：当时，人们仍对BSD和GPL有相当大的争论（我想很大一部分原因是RMS真的很擅长激怒别人），所以我只能在浏览各usenet新闻组（如comp.arch, comp.co.minix等）时看到一些有关许可证的讨论。

但最主要途径的有两个：gcc——它对Linux的发展起了很大作用，因为我肯定会需要C语言编译器——和拉尔斯·维兹尼乌斯（Lars Wirzenius，“Lasu”），他是当年我大学里另一个说瑞典语的CS学生（瑞典语在芬兰是一个非常小众的语种）。

Lasu比我更喜欢讨论许可证之类的事情。

对我来说，选择GPLv2并不是什么重大原则性决定，主要是因为我原来的临时许可证亟待更新，我很感激gcc，但GPLv2更符合我“你需要把源代码还回来”的期望。

因此，与其设立新的许可证（或者只是对旧的许可证进行修改），我更希望能挑选一个已经为人所熟知，且有律师参与的许可证。

记者：您每天会花多长时间写代码？审查代码？收发邮件？您是如何平衡个人生活和Linux内核工作的呢？

Linus：我现在很少会写代码了，已经很久没写了。当人们在特定问题上存在争议时，我才会写代码进行修改并将其作为补丁发出去，对提出的解决方案做出解释说明。

换句话说，我写的代码更像是“看，我们这样做行么？”，补丁就是一个非常具体的例子。我们常常会陷入如何解决某个问题的高级别理性讨论中，然后我发现描述解决方案的最佳方式其实是直接把代码片段写出来，虽然片段并不完整，但这却会让问题变得非常具体。

其实我的工作时间全都花在了阅读和回复电子邮件上了。主要负责沟通，而不是编码。这种与记者和科技博主间的沟通交流本就是我工作的一部分——或许它不如实际的技术讨论重要，但我确实在上面花费了相当多的时间。

**同时，我也会花时间进行代码审查，但说实话，当我收到拉取请求时，有问题的代码应该已经被多个人审查过了。因此，虽然我仍然会看一下补丁，但实际上我会更关注解释、以及补丁的形成过程。对于那些与我共事很久的人，我甚至都不会看：他们才是自己子系统的维护者，我不需要事无巨细地去监管他们的工作。

**所以很多时候，我的主要工作就是以揽收点的身份“待在那里”，并且承担管理和发布的任务。**换句话说，我的工作通常更侧重于维护过程，而不是处理低级别代码。

记者：您的工作环境是怎样的？比如，您是喜欢黑暗且没有干扰的房间，还是明亮且风景优美的房间？是倾向于安静地工作，还是喜欢边听音乐边工作？您习惯使用什么样的硬件？是喜欢用终端的vi审查代码，还是用IDE？还有，您个人在工作中是否有偏爱的Linux发行版本？

Linus：我的房间并不是很暗，但我确实会把办公桌旁边窗户的百叶窗关上，因为我不喜欢过于强烈的阳光（这是俄勒冈州此时最常见的天气）。因此，我的办公室中没有风景，只有一张（凌乱的）桌子，桌子下有双4K显示器、一台功能强大的台式电脑，还有几台用于测试的笔记本电脑。

我喜欢在安静的环境下工作。我之前非常讨厌机械磁盘驱动器的滴答声——而我也已经使用固态硬盘超过十年了，当时舍弃机械磁盘真是个明智之选，而且我也忍受不了嘈杂的CPU风扇。

**一切都在传统终端中完成，但我没有用“vi”，而是用了一种名为“micro-emacs”的东西，它与GNU emacs毫无关系，只是其中一些键的绑定方式是相似的。我还年轻，在赫尔辛基大学上学时用它用习惯了，因此就算我心里清楚自己需要尽快将其戒掉，但还是没能成功。**几年前，我为它设计了（非常有限的）utf-8支持，各种迹象都表明其写于80年代，而我使用的版本还是自90年代中期以来就没有进行过任何维护的分叉。

**赫尔辛基大学之所以使用它是因为它可以在DOS、VAXVMS和Unix上工作，而我也是因此才知道了它，导致现在我的手指都已经对其形成肌肉记忆了。我必须要将其换成一个能够实际维护并执行utf-8的东西，可能会是“nano”。我只是还没有强迫手指去改掉之前的记忆，所以现在用起nano来还是磕磕绊绊的。

因此，我的桌面环境相当简单：几个文本终端、一个浏览电子邮件的浏览器（还有其他几个新闻和科技相关的标签页）。我需要很大的桌面空间，因为我的终端窗口非常大（默认初始大小是100x40），并且我会并排打开多个终端。因此，需要双4k显示器。

我所有机器上使用的都是Fedora，倒不是因为它多么好用，只是因为用习惯了而已。我也不太关心是否是发行版本——对我而言，它的作用就是在机器上安装Linux并设置所需工具，让我能更换内核在其上工作即可。

记者：人们通过Linux内核邮件列表进行公开的内核开发，而且其流量非常大。您是如何兼顾这么多邮件的呢？有没有探索过邮件列表之外的其他合作沟通解决方案？还是说简洁的邮件列表对您的工作而言就是完美的？

Linus：我已经很多年没有直接阅读过内核邮件列表了，实在是太多了。

内核邮件列表的意义在于可以将内容抄送给所有人。这样一来，当有新人加入讨论时，可以通过查看内核邮件列表来了解历史沟通记录。

我之前订阅了列表，设置将所有没私人抄送的lkml邮件都自动归档，默认不显示。当有问题需要处理时，我也能找到所有的相关讨论。所有内容都储存在电子邮件中，但只有在需要时才会出现在收件箱。

最近，我一直都在用lore.kernel.org的功能，它非常好用，而且我们还有一些围绕其构建的工具。因此，邮件讨论内容就不必自动归档在邮箱里了，可以以另一种方式呈现，但其基本的工作流程是相同的。

当然，我仍会收到非常多的电子邮件——但从很多方面看来，这些年来情况已经有了很大改善。其中很大一部分原因是Git及内核发布流的完美运作：以前，我们在代码流和工具方面存在很多问题。在本世纪初，我的邮件状况非常差，当时我们还在处理庞大的补丁问题，在世纪之交时更糟糕，当时我们仍在处理巨大的补丁炸弹，开发流还存在严重的可扩展性问题。

（附带工具的）邮件列表确实非常好用。并不是说所有人都只用电子邮件或者线下见面沟通，也有人喜欢各种实时聊天设置（当时还有IRC）。虽然这不是我的风格，但确实有些人喜欢用它来进行头脑风暴。但“邮件列表存档”模式非常好用，并且能够无缝衔接“开发者之间以邮件方式发送补丁”和“以邮件方式发送问题报告”。

因此，电子邮件仍是主要的沟通渠道，补丁可以被嵌入同一媒介，简化了技术讨论流程。而且它能实现跨时区工作，当大家在异地工作时，这一点就显得尤为重要了。

Git创建与发展

记者：Linux只是您对开放源码做出的众多贡献之一。在2005年，您还创建了Git这个广受好评的分布式源代码控制系统。您很快便将Linux内核源代码树从专有的Bitkeeper迁移到了新创建的开源Git中，并在同年将维护权移交给了朱尼尔·哈马诺（Junio Hamano）。这其中一定有很多趣事，是什么让您这么快就移交了出这个项目的领导权，以及您是如何找到并选择朱尼尔的？

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

首先，我当时并不想创建新的源代码控制系统。创建Linux是因为我对发现硬件和软件之间的低等级接口很感兴趣——这基本上是出于热爱和个人兴趣的推动。相比之下，Git的诞生则是出于需要：并不是因为我觉得源代码控制很有意思，而是因为我完全看不上当时市面上大多数源代码控制系统，而我觉得最合适、且在Linux开发模型中确实运行得很好的BitKeeper已经站不住脚了。

**最终：我做Linux已经有30多年了（距离第一个版本的周年纪念还有几个月），并且一直在对其进行维护。但是我从来没有想过要长期维护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本身变得更加方便使用了。