Linus Torvalds 答疑

Linus Torvalds 答疑

星期一，您有机会向 Linus Torvalds 提出任何您想问的问题。我们向他发送了十几个评分最高的问题，以下是他关于计算机、编程、书籍和版权的回答。他还谈到了如果重新来过，他会对 Linux 做出哪些不同的选择。提示：答案和“无”押韵。

软件版权的彻底终结？

作者：eldavojohn

最近您公开反对软件专利和专利流程。但我对您提到版权问题的“棘手”程度更感兴趣。您以 SCO 为典型噩梦案例，但如果是针对开源许可证（如 GPLv3 的违规行为）呢？如果有人分叉 Linux 内核，对其进行重大修改并开始销售而不向客户发布代码，您会在意吗？对于开源和商业闭源，您理想的状况是什么？您是否会简单复制芬兰的模式，而不担心美国专家和美国陪审团一样愚蠢吗？

Linus: 我喜欢版权，即使是对于专利，我也不完全认为“专利完全是邪恶的”。当我抱怨专利或版权时，我针对的是*过度行为*和糟糕的政策，而不是反对它们的存在。

专利问题，Slashdot 上的人可能都很熟悉：系统几乎是为滥用而设计的，毫无意义的专利都能被批准，这阻碍了发明而不是促进它。失败之处很多，我不知道如何修复，但显然需要更严格的专利限制。

人们似乎对我说版权也有问题感到惊讶。我不明白为什么他们如此惊讶，更不明白为什么有人会认为“版权有问题”就意味着“应该废除版权保护”。这完全不符合逻辑。

坦率地说，互联网上有很多**蠢蛋**。

无论如何，版权问题来自荒谬的保护期过长，以及一些过于疯狂的执法行为。别误会，我并不认为这些问题在软件行业中表现得特别明显。SCO 的案例，我认为，并不是版权法本身的失败：当然，这很烦人，但实际上这是一个失败的企业试图利用系统的例子。他们尝试了，但失败了。是的，这个闹剧持续时间太长，花费太多，而且应该立即结束，但“在美国使用法律进行骚扰”是与版权问题无关的独立问题。

不，当我说版权保护过于强大时，我指的是类似“作者寿命+70年”和企业的 95 年版本。这*太荒谬了*。再加上判断合理使用的困难，这实际上阻碍了材料的存档、纪录片的制作等等。

所以我个人认为，知识产权保护本身并不是邪恶的——但当它被推得太远时就会变得邪恶。专利保护和版权保护都被推得太远了。

将保护期限缩短到大约 15 年左右，版权就会好得多。

当我为 Linux 设计处理器时。

作者：Art Popp (29075)

我花了一些时间用 Verilog 设计东西，并尝试阅读 opencores.org 上其他人的源码，我记得您曾在 Transmeta 工作过。一段时间以来，我一直有一个可以添加到处理器中的指令列表，这些指令将极大地加速常见功能。SSE 4.2 包括了一些我喜欢的功能，比如双字串比较指令。那么，您有没有一些您认为应该由处理器处理但从未实现的指令的想法？

Linus: 我实际上不是那些闪亮新功能的超级粉丝。在处理器设计中——就像许多技术领域一样——更重要的是互操作性和兼容性。我知道这会让人失望，因为人们总是追逐那些酷炫的新功能，但嘿，最终，技术是关于做有用的事情。99% 的改进是通过在现有知识和基础设施之上构建和扩展实现的。

偶尔的大变革和全新的事物可能会吸引所有注意力，但它们很少真正重要。我喜欢引用托马斯·爱迪生的一句话：“天才是1%的灵感，99%的汗水。” 这句话同样适用于CPU架构：灵感并没有执行得好来得重要。当然，你需要一些灵感，但其实不需要太多灵感。

因此，在CPU设计中，真正应该关注的是CPU在执行我们预期任务时表现如何。指令集是重要的——但它的主要意义在于“我可以运行上一代CPU支持的相同指令，因此我可以运行你所有的程序，而无需额外的工作”，而不是“你希望在指令集中增加什么新酷功能”。

对CPU架构师而言，我会建议他们尽全力优化内存子系统。例如，不论指令集如何，你都需要一个端到端出色的内存子系统。我不仅是指优秀的缓存，而是优秀的**所有部分**。这是一大堆细节（汗水），而且我敢保证，要做到非常出色需要一大批人努力好几代才能实现。没有一种简单的灵丹妙药或酷炫的新指令能为你解决这个问题。

不过不要误解我——CPU设计不仅仅是关于内存子系统，它也涉及其他所有细节。

现在说到实际的指令，我确实认为世界已经偏离了RISC。我非常相信能很好地运行现有的二进制文件，跨越多种不同的微架构——整个“兼容性”问题。因此，我认为依赖静态指令调度或顺序执行的脆弱架构简直就是疯了。如果你的CPU需要针对特定指令延迟或解码器限制进行指令调度，那么你的CPU就是失败的。我非常厌恶Itanium，因为它将微架构暴露在指令集中，这实在是疯狂。

不，我想要乱序执行和实际能在相同ISA（指令集架构）及不同硬件类别（例如，从低功耗嵌入式到高端服务器CPU范围）中工作的“高级”指令。例如，我认为“memcpy”或“memset”这样的指令是一个好主意，因为它允许你根据不同的内存子系统和微架构优化运行。

一个**不应该做的例子**是暴露直接缓存行访问，比如某种愚蠢的“DCBZ”指令用于清除它们——因为这样软件就必须关心缓存行的大小，等等。对于绕过L1缓存的“非时序访问”之类的事情也是如此——在不同CPU拥有不同缓存子系统的情况下，软件如何知道何时使用这些？软件根本不应该关心这些。软件只需要清除内存，而不是对齐的缓存行；软件也**不应该**担心如何在某个特定的新机器上最有效地完成这项任务。

你会做得不一样吗？
作者：Rob Kaper

自Linux诞生以来已经过去了20多年。如果你在早期就拥有今天的知识和经验，你会有什么不同的做法？

Linus: 我经常被问到这个问题，但我真的不知道自己是否可能做得更好。我并不是在宣扬某种深远的先见之明——只是回过头看，我确实做出了正确的重大选择。我仍然热爱GPLv2，并且绝对认为让Linux开源是最伟大的决定。

我犯过错误吗？当然有。但总的来说，我认为Linux表现得非常出色，而我也围绕它做出了正确的决策（重大问题有时是技术性的，但更多时候是非技术性的，比如“不要为一家商业Linux公司工作，即使这看起来是自然而然的事情——继续在中立的地方工作，以便人们可以继续和我合作”）。

单体内核与微内核架构
作者：NoNeeeed

在Linux内核的发展过程中，你是否曾经希望走类似Tannenbaum倡导的Hurd风格微内核路线，还是你觉得从架构的角度来看，Linux因采用单体设计而受益？

Linux比Hurd成功得多，但我想知道这有多少是由于其方法的内在技术优势，以及有多少是由于社区的支持及中心驱动力的缺乏？Hurd的模式似乎应该能让更多人参与，但这种情况从未发生过。

Linus: 我认为微内核是愚蠢的。它们将问题域推向了**通信**，而通信实际上是一个比它们试图解决的小问题更大且更根本的问题。这也导致了可怕的额外复杂性，因为你必须与微内核模型抗争，并发明新的方法来避免额外的通信延迟等。Hurd是这类糟糕案例的典型代表，人们发明了全新的内存映射模型，仅仅因为微内核模型破坏了正常的“在同一上下文中快速系统调用”的模型。

顺便说一句，这不仅仅是微内核。每当你有“一种压倒一切的想法”，并将你的想法推崇为一种优越的意识形态时，你就会出错。微内核有这样的意识形态，其他人也有过类似的意识形态。这些都是胡扯。事实上，现实是复杂的，不适合那种“一个大思想”模式来解决问题。现实生活中问题的唯一解决方式是通过努力将细节做对，而不是通过某种包罗万象的意识形态魔术般地让事情运转。


避免Unix战争
作者：dkleinsc

为什么你认为Linux能够（大部分）避免上世纪80年代困扰竞争性Unix的碎片化问题？你会说是什么因素帮助Linux保持为一个统一的项目，而不是像BSD那样更多地分叉呢？

Linus： 我非常相信GPLv2，我真的认为许可证是重要的。对我来说，开源许可证的重要之处不在于是否可以分叉（BSD允许分叉），而在于许可证是否鼓励将改进合并回主线。

顺便说一下，在有人想要和我进行“许可证争论”之前，我想特别强调“对我来说”这一点。许可证是一种个人选择，并不存在“错误”的选择。对于我关心的、由我启动并能为其做出许可决定的项目，我认为GPLv2是正确的选择，原因有很多。但这并不意味着，如果别人为他或她的代码做了另一种选择，那就不是该人为其代码做出的正确选择。

例如，对于那些我不太关心、只是想“放出去以便别人可能使用”的代码，我会选择类似BSD的许可证。我也不认为专有许可证是邪恶的。这一切都取决于原作者决定将项目引向什么方向。

回到问题上来——我确实认为，鼓励合并是我选择许可证时最重要的一部分。拥有像GPLv2这样的许可证，基本上要求每个人都有权将有用的代码合并回主线，这是一件很棒的事情，也避免了对分叉的担忧。

我想说，分叉本身并不糟糕。分叉是绝对必要的，因为开发的进行依赖于容易的分叉。事实上，git的一个设计原则就是使分叉变得简单，没有任何技术障碍（例如“更中心化的代码库”）阻碍分叉的发生。分叉很重要，任何时候有开发者认为自己在某些方面可以做得更好，就需要进行分叉。去尝试吧，分叉项目并证明你的观点，向大家展示你的改进。

但如果没有好的方法将改进合并回来，分叉就会成为问题。而在Linux中，这不仅仅与许可证有关。当然，许可证意味着法律上我们始终可以将分叉合并回主线，只要这些分叉被证明是有价值的。但我们还有一种鼓励分叉并使其不带有敌意的文化。基本上，*所有*的Linux发行版都有自己的内核“分叉”，但这并不被认为是坏事，反而被认为是自然且*好的*事情。这意味着这些分叉通常是友好的，并且不仅没有法律上的问题可以将其合并回主线，通常也没有大的个性冲突或不满情绪。

因此，问题并不是Linux不分叉，而是我们努力使分叉变得小而无痛，并尝试很好地将改进合并回来。当然，会有分歧，但它们会被解决。比如看看Android的工作：是的，这并不总是快乐的，也不是没有问题的，但最终大部分内容都被合并回来了，而且我认为并没有过多的负面情绪。


GIT
作者：vlm

如果让你重新设计GIT，有什么地方会改进吗？另一个非常相关的问题是，你喜欢git-flow项目吗？会考虑将其集成到主线中吗？

Linus： 关于这个问题，我认为我们可能可以在一些小细节上做得更好，但总体上我对git感到*非常*满意。我认为核心设计非常稳固，几乎没有冗余信息，并且核心模型确实围绕一些非常合理的概念建立。Git非常像Unix，它有一些基本的设计理念（“一切都是对象”，以及git数据库中不同对象之间的基本关系），然后围绕这个核心设计构建了很多实用工具。

所以我对git非常自豪。我认为我设计得很好，然后其他人（尤其是Junio Hamano）基于这个优秀的设计进行了很棒的扩展。当然，早期对于外部用户来说使用起来可能不太友好，如果你来自某些传统的源代码管理系统，它现在可能仍然有些奇怪，但它确实让我的生活变得*更加*美好，而且我真的认为它在一些根本性问题上比之前的源代码管理系统做得更好。

至于git-flow，我想再次强调Junio Hamano作为git维护者是多么出色。在过去五年左右的时间里，我完全不需要担心git的开发问题。Junio一直是一位模范维护者，展现出了极好的品味。由于我不需要参与，我甚至没有关注过围绕git的一些项目，比如git-flow。这不是我需要的git工作流工具，但如果它能帮助人们用git维护一个好的主题分支模型，那就更好。至于它是否应该进入git主线，我甚至不会评论，因为我完全相信Junio会做出正确的决定。


内核中的存储进步？
作者：ScuttleMonkey

现在Ceph在被合并到主线内核后正在获得动力，你认为接下来会有哪些存储（或低级别）方面的进步？（完整声明：我目前在Inktank工作，这家公司聘用了大部分核心Ceph工程师）

Linus: 实际上，我并不算是一个存储专家，虽然我是顶级内核维护者，但这个问题可能更适合问其他一些人。

关于存储，我想重申一点（个人看法），那就是旋转存储正逐渐像渡渡鸟（或磁带）一样走向灭绝。用一句话表达我的态度就是：“我有多讨厌你，让我来数数理由”。旋转存储的延迟非常糟糕，我个人拒绝使用那些装有旋转铁锈盘（硬盘）的计算机。

当然，也许那些旋转盘在一些 NAS 设备中还可以用来存储大容量媒体文件（或者在你使用的云存储集群中，由于网络延迟的存在，磁盘延迟变得次要），但在一台真正的计算机中呢？呃。“离我远点，撒旦”。

这并没有回答你真正问的问题，不过我确实对存储并没有太多兴趣。



favorite hack
by vlm

我问了很多关于硬件架构的问题，现在来个轻松点的吧。您最喜欢的与内核内部或内核编程相关的 hack 是什么？无论是驱动、内部结构，还是其他任何方面都可以。那种让您看到代码后会感叹“哇，这真是太酷了”的情况。请您自行定义“最喜欢的”、“hack”和“内核”。只是想放松一下，听听关于酷代码的故事。

Linus: 嗯，你知道的，我现在已经不太直接接触代码了。我花时间不是在写代码，而是在读邮件和合并别人写的东西。而当我真的接触代码时，往往是因为它坏了，这时你会发现我在咒骂写这段代码的人，并质疑他们的家世甚至宠物的来历。

所以，恐怕我现在很少参与到那些真正酷的代码中了。我更多参与的是那些“天哪，我们当初怎么会合并这种垃圾”的代码。也许还没有 Greg 遇到的那么多（他得处理 staging 树），不过 Greg 是个“特别”的人。

话虽如此，内核中确实有很多非常酷的代码。我特别为我们的文件名查找缓存感到自豪，但嘿，我可能有些偏心。那段代码并不适合心脏脆弱的人，因为整个无锁查找（以及回退到更传统的加锁代码）非常复杂和微妙，普通人最好不要看它。由于任何文件名查找都会涉及到它，它被优化到了一种非常极端的程度。我还记得去年合并新的无锁 RCU 文件名查找代码时，我是多么高兴。

在另一端，我其实希望更多人能理解真正核心的底层编码。这并不是像无锁文件名查找那样的大型复杂代码，而是简单的指针到指针的良好使用。例如，我见过太多的人在删除单链表的一个节点时，会跟踪“prev”节点，然后用类似这样的代码删除节点：

  if (prev)

    prev->next = entry->next;

  else

    list_head = entry->next;

每当我看到这样的代码，我就会想“这个人不懂指针”。遗憾的是，这种情况相当普遍。

真正理解指针的人只会使用“指向节点指针的指针”，并用它来初始化链表头的地址。然后在遍历链表时，他们可以在不使用任何条件判断的情况下删除节点，只需执行

*pp = entry->next

。

所以在细节上做得完美让我感到很自豪。也许它并不是很大、很重要的代码，但我喜欢看到那些真正关注细节的代码，同时也考虑到了编译器生成高效代码的可能性（而不是指望编译器足够智能，以至于能从原始代码的状态中生成高效代码）。



Books, Books, Books
by eldavojohn

作为一名软件开发者，我收藏了一些值得珍藏的书籍。这些书籍中有些（包括小说和非小说）从根本上改变了我的人生轨迹。假设您的书架上不只是手册页和 .txt 文件，那么它们都有哪些呢？

Linus: 我读了不少书，但不得不承认，对我来说，读书更多是一种逃避现实的方式，而书籍对我来说大多是可忘却的。我想不出有哪本书像某些人那样能彻底改变我的人生观。

不过，我可以提几本我非常喜欢的书。在非小说类中，理查德·道金斯的《自私的基因》是一本我认为非常有影响力的书。小说方面，作为一名青少年，我非常喜欢海因莱因的《异乡异客》，不得不提到《指环王》对我来说也很重要——不过不是因为我是托尔金的超级粉丝。对我来说，这是我第一次真正用英文阅读的书，我从一开始旁边放着一本字典，到最后可以不需要字典直接阅读。

现在，我依然看一些平庸的书。我喜欢用 Kindle，常常读一些售价 99 美分的自出版书籍。虽然其中确实有一些糟糕的作品，但也有不少“这本书确实值这 99 美分”的作品。另外，我也喜欢重读一些我成长过程中读过的经典书籍——比如最近我刚重读了《基督山伯爵》和《三个火枪手》。

如何应对倦怠？
by kallisti5

你在 Linux 内核开发过程中一定经历过多次倦怠... 你是如何应对的？

Linus: 哦，我真的很享受我所做的事情。我实际上也很喜欢争论，虽然我可能会经常爆粗口，看起来像个脾气暴躁的老头，但我也很擅长放下事情。所以，我对某些事情可能非常热衷，但同时我并不会长时间执着于某个具体问题，我认为这有助于避免倦怠。

对某些事情保持专注是很重要的，这些事情确实很重要，但如果你无法放下它们，你最终会崩溃。

所以对我来说，那些偶尔的激烈争论实际上让我感到很有活力。而且技术和使用场景的变化足以让事情从不感到无聊，因此我实际上很少接近倦怠的边缘。

唯一一次真的痛苦的经历是在 2.4.x 系列的中期（大约十年前），在我把维护工作移交给稳定维护之前，当时确实存在很多问题。你可以通过搜索“Linus doesn't scale”（Linus 无法扩展）找到当时的一些讨论和其他问题。那确实是一段痛苦的时期。内核正在快速增长，而我无法跟上。BitKeeper 和一些相当痛苦的流程变更确实帮了大忙。



描述你的电脑
by twistedcubic

你能详细描述一下你的家用和工作电脑，包括处理器、主板和显卡吗？并谈谈它们与 Linux 的兼容性？

Linus: 我的家用电脑其实并没有那么有趣：我现在对 CPU 性能的需求已经没那么高了。这些年来，我的主要需求（因为 CPU 已经足够快）是电脑要非常非常安静，并且有一个好的 SSD。如果我们的猫有幸跳到我的腿上时，房间里最响的声音应该是猫的呼噜声，而不是电脑的噪音。

因此，我的主要台式机实际上是一台四核 Westmere 机器，并不算特别出色。机器最特别的部分可能是它有一个好机箱（我现在忘了具体的型号），可以避免震动等问题。而且配备了一个大容量的 Intel SSD。我想今年秋天我会升级这台机器，但这台机器我已经用了大概两年了。

我现在正在用笔记本写这些内容，因为我目前正在日本和韩国旅行。这是一台 11 英寸的 Apple Macbook Air（去年款，但当然运行的是 Linux，没有任何 OS X 的痕迹），因为我真的讨厌大笔记本。我无法理解那些带着 15 英寸（甚至 17 英寸）“怪物”四处走的人。对我来说，笔记本电脑的理想重量是 1 公斤，不多不少。



Re: 最后的问题
by Narnie

说到结束，有一天你会把职责传递下去。你如何想象内核和 Linux 生态系统在你卸任之后的发展？

Linus: 哦，内核确实有一个非常坚实的开发社区，我对此并不担心。我们有几个“顶级助手”可以接手，我更担心其他许多没有同样庞大开发社区的开源项目。

话虽如此，我已经做这件事超过二十年了，我并不觉得自己会停下来。我仍然喜欢我正在做的事情。如果没有内核可以研究，我可能会无聊到发疯。