Linux 7.1 新版发布：没有“惊喜”，就是最大亮点

“我并非 Rust 的反对者，但我也希望大家不要对它抱有过高期待——别指望 Rust 能像魔法一样瞬间修复所有漏洞。”

近日，Linux 与 Git 创始人 Linus Torvalds 现身印度孟买，与 Verizon 开源项目办公室负责人 Dirk Hohndel 进行了一场围炉式深度对话。伴随 Linux 7.1 新版本的正式亮相，他依然放弃了传统演讲，采用自由问答形式，深入剖析了开源内核长达数十年的运作机制。

在 3500 万行庞大内核代码的维护压力之下，Linus 再次强调自己早已不是直接编写核心代码的一线程序员，日常工作核心是掌控“大局”，聚焦于 Linux 整体架构的演进。同时，他就最新版本中的热门议题——淘汰 486SX 处理器、内核中两套 NTFS 实现的并行竞争、Rust 语言的定位边界等，给出了直截了当的解答。他还正面回应了 AI 给内核社区带来的双重影响：LLM 能够挖掘出隐藏多年的底层 Bug，但也会产出缺乏全局考量的“创可贴式补丁”，至今仍欠缺成熟的工程思维。

此外，他明确收紧了内核合并窗口规则，要求维护者不要在截止日期前集中提交修复补丁，并坦言维护大型开源项目最大的压力从来不是代码冲突，而是复杂的人际沟通。整场对话跳出了纯技术层面，从三十余年的开源实战视角，系统阐述了稳定迭代、语言取舍、工具边界与社区治理等底层问题，真实还原了 Linux 内核当前的开发状态。

Dirk Hohndel：很高兴能来到这里。重返孟买令我感到非常兴奋，上次来大概是 21 年前了。这里的天气很宜人，之前有人提醒我会是 120 华氏度且暴雨倾盆，看来并非如此。我们也品尝了当地美食，非常棒。我是 Dirk Hohndel，从事开源开发的时间可能比在座大多数人的年龄都要长。而这位是……

Linus Torvalds：我是 Linus。请先不要鼓掌，因为我非常讨厌公开演讲。之所以采用这种“围炉谈话”的形式，是因为我无需提前准备和思考该说什么，由别人准备好问题来问我，我甚至不知道问题是什么。希望这能让对话更自然流畅，也让我没那么反感这种公开场合。

Dirk Hohndel：这是一个非常有说服力的开场白。你在伦敦希思罗机场时发布了 Linux 7.1，这一版有哪些亮点？

Linus Torvalds：其实我常说，我们已经很久没有传统意义上的“亮点”了。对我来说，真正的亮点在于，Linux 始终在稳定地向前演进。过去 20 多年里，我们一直坚持同样的方法。自 2005 年起，我们转向了基于 Git 的新开发模式并采用新的发布周期，整个开发流程运行得相当可靠。这也意味着，我们不再发布那种拥有“重大、华丽新功能”的版本，事实上，我甚至刻意避免这种模式。我们追求的是持续的增量改进以及稳步推进的发展节奏。

最近，这件事变得稍微困难了一些，因为 AI 发现了一些有趣的 Bug，给社区成员带来了不小的压力。但总体而言，我们依然保持着每 9 到 10 周发布一个新版本的节奏，确保系统始终稳定演进，而不是时不时给社区带来意外的“惊喜”。

Dirk Hohndel：但我们还是看到了一些有趣的新东西，比如更新后的 NTFS 子系统。

Linus Torvalds：我们在 NTFS 上有一段很奇特的历史。Linux 有几十种不同的文件系统，多到数不清。多年来，NTFS 一直是个“问题儿童”，有时候很难找到维护人员。现在突然出现了两个不同的团队在维护两个不同版本的 NTFS，而且它们都能正常工作。我目前的态度就是让他们竞争，看看哪一个能胜出，或者可能两个都会长期存在。

37 年后 Linux 停止支持 Intel 486 处理器

Dirk Hohndel：这确实算是比较令人兴奋的事情之一。另一件被广泛讨论的事则带点伤感：对 486 架构的支持消失了。

Linus Torvalds：我想说，是时候放手了。在技术问题上，我并不是一个感性的人。我始终认为，只要还有用户，就应该继续维持对硬件的支持；但与此同时，到了某个阶段，维护旧硬件的成本终究会变成一种沉重的负担。这不仅体现在修复 Bug 上，更多体现在为新功能提供兼容支持上。

我们终于要移除浮点模拟代码了。不过，这不是针对 486，而是针对更早一代的硬件。从即将发布的 7.2 版本开始，我们将不再支持那些在 x86 架构上没有硬件浮点运算单元（FPU）的机器。我想，最后一款这样的硬件大概是 30 年前发布的 486SX。

Dirk Hohndel：486SX，没错。那是 1993 年左右的事情了。

Linus Torvalds：是的，距今已有 30 多年。我们以前一直支持那个硬件基础。虽然它不需要太多维护工作，但在你每次进行更改时，它依然是需要额外关注的对象。因此，我们现在正更积极地尝试放弃对那些除了在博物馆外、实际上已经没人在用的硬件支持。

Dirk Hohndel：没错，最近好像还处理了业余无线电数据包层、ISDN、ATM 等老旧且无人维护的代码。

Linus Torvalds：是的，我们正在尝试清理源代码库。这属于持续改进的一部分，目的是确保代码是可维护的。Linux 的代码库非常庞大，维护起来绝非易事，但至少我们不应该让它变得比必要的更难。

Linus：不要总是赶在合并窗口前再提交修复

Dirk Hohndel：在飞往孟买的飞机上时，合并窗口开启了，你坐在飞机座位上就开始处理合并请求了。最近几个内核版本中，我们看到后期 RC（发布候选版）的数量明显增加。那么，这种趋势在合并窗口阶段是否也存在？比如，规模更大的合并请求是否会更早地集中涌入？

Linus Torvalds：合并窗口的代码量确实略有增加，但没那么多。我认为，现在出现这种情况，除了 AI 帮助发现了更多问题这一显而易见的原因之外，还有一点是：这些问题一旦被发现，我们有时会选择非常激进地立即修复，而不是把修复留到下一版本继续开发。

不过，这其中也有一部分原因在于我自己。过去，我可能太愿意接受那些并非绝对必要的修复补丁了。所以上一个版本中，我告诉大家：“冷静一点。如果不是特别重要的修复，就把它排到下一版本，不要总是在最后一刻给我发修复补丁。”希望在座的软件开发者都能理解这一点：修复补丁当然是为了解决问题，但它本身也可能带来新的问题。因此，每到发布窗口后期，我们都要权衡一个问题：这个修复虽然能解决现有问题，但它是否值得冒着引入新 Bug 的风险，在这个阶段合入？

因此，我现在开始收紧这方面的做法，因为有些人已经习惯在发布窗口临近结束时才提交修复。对于 Linux 内核来说，这其实没有太大必要。我们的发布节奏本来就很快，一个版本周期大约只有九周，因此把修复推迟到下一版本，通常并不是一件大事。如果一个修复并不是为了解决特别严重的问题，而且我们对它仍有一些顾虑，那么即使它确实是一个修复，也完全可以推迟几周，在下一版本中再合入。之前连续几个版本规模都太大了，我担心我们正在朝着错误的方向发展，所以现在正努力把节奏重新调整回来。

Dirk Hohndel：经过两天的 PR 合并，有什么让你印象深刻的事情吗？

Linus Torvalds：没有。我会尽量避免在旅行期间开启合并窗口，因为那通常是我最忙碌的时候。在两周的合并窗口期内，我大概需要完成 200 次合并，这是一个比较粗略的数字。这意味着，我不希望自己只是进行“盲目合并”。虽然我非常信任那些长期与我合作的核心开发者，其中一些人甚至已经和我共事了三十年，但我仍然认为，我的职责不仅仅是把代码合并进来，还需要从更宏观的角度理解整个过程中发生了什么。同时，这并不是一个特别有压力的时期。我们有一套非常有序的发布流程，新代码虽然会带来技术问题，但这些问题本身并不会让我感到困扰，因为它们都是可以解决的。真正让我感到压力的，往往是偶尔出现的“人际关系”问题。要知道，代码很容易修复，但人的性格和相处问题并不总是那么容易解决。这也是为什么在合并窗口期间，真正困难的地方往往并不只是处理技术细节，而是需要同时面对各种人与人之间的问题。

“Linux 内核有 3500 万行代码，没有人能够真正理解全部代码”

Dirk Hohndel：你刚才提到，你希望更多了解进入内核的代码。考虑到你需要在两周内处理大约 200 个 PR，你实际上还有多少时间去阅读代码、理解代码背后的意图，或者了解它涉及的具体领域？

Linus Torvalds：说实话，我现在几乎不再阅读代码了。我不是传统意义上的程序员，而是一名开发主导者。当然，我知道如何编程，也依然会为了兴趣写代码，但那些业余项目并不是 Linux 内核，而只是一些我享受其中过程的小玩意。我更多依赖的是“信任”。我认为，开源项目本质上都建立在信任之上——我们彼此了解，已经共同工作了很多年，甚至几十年。我合并的那 200 个拉取请求，来自于那些我长期合作并且信任的人。我并不认为自己需要完全理解每一行代码。毕竟，面对一个拥有 3500 万行代码的项目，没有任何人能够真正理解全部代码。在处理一个拉取请求时，我真正想了解的是“大局”。这也是为什么我要求提交者必须提供非常详细的说明。我会认真阅读这些说明，了解发生了什么，以及为什么要做这些改变。这样做的意义在于，未来如果出现问题，我能够回忆起当时的背景。即使我从未亲自查看过那部分代码，遇到问题时也能马上想到：“我知道这件事是怎么回事，也知道应该从哪里开始排查。”这就是我现在工作的层面。事实上，到目前为止，我已经几十年没有真正编写所谓的“核心代码”了。

Dirk Hohndel：但你还是会写一些小东西……

Linus Torvalds：我当然还会写代码。比如，我可能会给别人发送补丁，或者提出一个可能的修复方案：“嘿，也许可以这样处理。”但我会明确说明，这只是一个建议，没有经过完整测试。它可能只是我刚刚编译过，甚至偶尔运行过的东西。我希望真正负责这一部分代码的维护者，能够基于这个思路进一步完善，并提交最终的修复方案。所以现在，我亲自提交代码的情况已经非常少了。偶尔会发生，但确实非常罕见。

Dirk Hohndel：你说自己不再看代码，这一点很有意思。因为对于维护者来说，想获得你全部注意力，一个有效的方法就是提交一个会导致构建失败的拉取请求。那时候，你一定会认真检查代码，而且还会“非常仁慈、非常体谅”地对待他们。

Linus Torvalds：我正在努力改进这一点。其实，我并不是完全不看代码。比如，在合并过程中遇到代码冲突时，我就会查看相关代码。这种情况很常见，也没有什么问题。有些人觉得解决冲突很困难，但多年来我处理过太多冲突了，甚至闭着眼睛都能完成这类工作。我并不担心这一点。不过，冲突往往意味着两个不同团队同时修改了同一部分代码。这时候，我会仔细看看双方到底做了什么，而很多问题恰恰会在这个阶段暴露出来。有时，问题的根源在于两个团队实际上有着不同的目标。另外，如果一个拉取请求的说明写得不够清楚，我也会去查看代码。有时候，看完代码后，我会明白：“哦，原来他们想做的是这个。”但也有一些情况，即使看完代码，我仍然觉得这个改动不合理，那么我就会拒绝它。所以，虽然我已经不是传统意义上的程序员，但我仍然拥有足够深厚的技术背景，能够在需要查看代码时做出判断。

“不要认为 Rust 能够像魔法一样修复所有 Bug”

Dirk Hohndel：我们刚才提到，这种开发模式的转变发生在 20 年前，其中一个重要原因就是 Git 的诞生。如今，Git 仍然是你处理所有工作的主要工具吗？你还会使用其他工具吗？或者有没有什么工具是你希望拥有的？

Linus Torvalds：对我个人来说，Git 和电子邮件基本就是我使用的全部工具。我会用 Google 查询资料。我相信在座的一些人可能天生就能记住整个行业里的各种三字母缩写，但我做不到。人们经常会在提交说明中提到一些我并不熟悉的领域，使用各种缩写和专业术语，让我完全摸不着头脑。这时候，我就会去 Google 搜索。所以，从这个意义上来说，Google 也是我的工具。但绝大多数时候，我做的事情就是阅读邮件，以及使用 Git 进行代码合并。这就是我工作的核心工具。不过，我想强调一点：我是一个特殊案例。大多数其他维护者使用的工具要丰富得多，很多人现在也开始使用 AI 工具来辅助补丁检查。但既然我说自己的工作是在更高层级上进行，那么我面对的核心对象其实是“人”，而不是工具。这也是为什么我一直强调“信任”。我信任的是开发者本人，以及他们做出的判断。这种信任往往已经建立了几十年。开发者可能会从一家企业跳槽到另一家企业，但我并不关心他们使用什么邮箱，也不关心他们现在效力于哪家公司。我信任的是这个人本身，以及他长期以来展现出的判断能力。我认为，很多开源项目都是以这种方式运转的。而且在开源社区中，这一点比公司内部更加明显——在公司里，你可能因为某个人是同事而信任他；但在开源社区，你信任一个人，是因为你们已经长期合作，并且共同经历了很多事情。

Dirk Hohndel：Git 当然也是你发起的另一个重要项目。这个月，Git 决定引入 Rust。虽然目前 Rust 仍然是可选项，但默认配置已经开启，而在未来的 Git 3 中，Rust 将成为必需项。你认为这种趋势会在更多领域出现吗？比如 Linux 内核目前也已经正式将 Rust 作为支持的编程语言之一。

Linus Torvalds：我不确定 Rust 是否会接管整个世界。我认为 Rust 确实很有趣，但也许因为我的个人经历，我仍然觉得 C 语言是一种更简单、更直接的工具。其实，我个人更感兴趣的是那些帮助验证 C 代码的工具。我们已经拥有多年的静态分析工具，但我更喜欢近年来出现的自动化补丁验证工具。这些工具正在真正创造价值。它们并不能提供 Rust 那样的安全保障，但它们能够让更多“眼睛”去检查代码，帮助发现开发者在传统 C 语言开发中经常犯的错误。所以，我对正在出现的这一类工具非常兴奋。现在我们已经有了像 Sashiko 这样的自动化测试工具，以及针对补丁的自动化邮件检查流程。

Dirk Hohndel：我总觉得，C 语言就像一把“电锯”，而 Rust 更像是一台带有精密控制系统的 CNC 数控机床。有些人更习惯使用电锯……

Linus Torvalds：我更像是那种“简单粗暴”的人。我依然喜欢 C 语言那种原始而直接的力量，我不认为这一点会改变。

回到 Git 的话题，Git 的目标之一从来不是 C 语言本身。C 只是一个实现选择，因为它是我一直使用的语言。我希望 Git 拥有几个非常高层的概念，能够解释整个架构。你可以从 Git 的早期历史中看到这一点，我们不仅有 C 语言版本，还有实际上在很多公司后台运行的 Java 版本。在服务器环境中，拥有 Java 版本的 Git 通常非常方便。Git 现在开始支持 Rust 也不像 Rust 进入内核那样是一个巨大的变化，因为 Git 本来就已经支持多种不同的语言实现了。

Dirk Hohndel：这很有意思，因为 Rust 正在被推广到越来越多的领域。我们已经看到了一些早期案例：开发者使用 LLM 将现有工具重写并迁移到 Rust。但与此同时，也出现了一些相当严重的问题，比如 Ubuntu 23.10 的自动更新故障。

Linus Torvalds：公平地说，Rust 确实能够避免一些在 C 语言中很容易犯的低级错误，但它并不能解决逻辑错误。它不会替你思考。如果你的代码逻辑本身有问题，那么无论使用什么编程语言，最终结果都会是错误的。我完全不反对 Rust，但我也希望降低大家对它的期待，不要认为 Rust 能够像魔法一样修复所有 Bug。它只能解决某些特定类型的问题，让一些错误更难发生，但你依然可能犯大量逻辑错误。事实上，最近 Linux 内核中一些影响较大的 Bug，恰恰都是逻辑错误，而不是内存安全问题，也不是由于某些复杂的语言特性导致的，而是单纯的编程逻辑出了问题。遗憾的是，即使是在维护良好的子系统中，甚至是在那些理论上应该非常安全的内核核心部分，也依然可能发生这种情况。所以，不要期待某种编程语言能够自动帮你解决所有 Bug。

Dirk Hohndel：在向 Rust 过渡的过程中，像 Linux 内核或者 Git 这样的项目，都需要面对 C 代码和 Rust 代码之间的交互问题。Rust 提供的安全保证只存在于纯 Rust 代码中，一旦涉及 C 代码调用，这些保证就会消失。

Linus Torvalds：客观地说，大多数 Rust 与 C 代码的交互，实际上都是在和内核核心部分的 C 代码打交道。而内核核心代码的质量，通常要高于外围代码。这并不是因为编写核心代码的人更聪明，或者能力一定更强，而是因为核心代码会在各种环境中经历极其充分的测试。毕竟，它是内核的基础部分，无论运行什么场景，都会涉及内存管理、核心调度器等组件，因此这些代码会在 Linux 支持的几乎所有平台上不断接受实际运行检验。相比之下，具体的硬件驱动程序则不同。一个驱动只有在对应硬件存在并被使用时，才有机会得到充分测试。所以，Linux 内核中的代码质量实际上存在差异，有些部分非常成熟稳定，有些部分则没有经过同等程度的验证。我认为，Rust 目前主要交互的，往往正是那些最稳定、开发最完善的部分。

Dirk Hohndel：显然，内核本身其实也存在这样的差异：有些代码经过了大量测试，而一些实验性代码可能并没有得到同等程度的验证。此外，还有一些历史更久的代码，由于对应的硬件已经不再常见，甚至已经不存在，因此也很少有人继续使用和测试。比如，我不知道现在还有多少人在自己的 S390 机器上运行 Linux，但我不认为 Linux 是大型机领域的主流操作系统。所以，我认为，经过最多测试、最多审查，也最值得信任的代码，往往是所有人都会依赖的核心代码。

Linus Torvalds：是的。核心代码通常也会获得最多关注。即使你是一名驱动开发者，通常也需要理解核心代码以及相关接口的工作方式；但反过来，维护核心 VFS（虚拟文件系统）层的人，可能永远都不需要查看某个具体硬件驱动的实现。这也是为什么，我通常建议希望参与内核开发的新开发者可以从驱动程序入手，因为那里有大量学习和实践的机会。不过，同时也要提醒大家，Linux 内核是一个极其庞大的项目，并不是一个容易上手的领域。我们对新开发者以及整个开发流程都有非常严格的规范和要求。

AI 仍然缺少一些“工程品位”

Dirk Hohndel：我们要记录一下，我们的对话已经进行了 26 分钟，竟然还没有聊到 AI 和 LLM。我想，这可能是本次大会中少有的、直到这么久之后才提及 AI 的讨论。不过，我们确实应该谈谈这个话题。你之前在明尼阿波利斯也提到过，大语言模型本质上只是一个工具，它可能带来大约 10 倍的效率提升。这个说法被很多人反复引用。

Linus Torvalds：我需要先澄清一下，“10 倍”并不是经过科学计算得出的结果。那只是我当时随口举的一个数字。

Dirk Hohndel：那么，你认为大语言模型目前能够为 Linux 内核社区带来多少真正的价值？

Linus Torvalds：目前来看，我希望它创造的生产力能够超过它消耗的精力。在今年年初之前，我们看到的更多是大语言模型生成的垃圾代码，而不是有实际价值的代码。即使到了现在，它仍然会消耗开发者大量资源。比如，你可能会收到一些看起来非常合理的 Bug 报告，但最终发现它们只是 AI 产生的“幻觉”。开发者需要花费大量时间去验证这些报告，最后却发现它们并不真实。这实际上造成了巨大的资源浪费。不过，过去几个月里情况确实有所改善，我们开始收到一些质量非常高的 Bug 报告。但这些高质量报告通常并不是单靠 LLM 产生的，而是需要一个“中间人”——也就是人类开发者参与其中。我们也一直在强调这一点：如果你使用 LLM 发现了一个 Bug，仅仅让模型生成一份报告，然后直接提交给我们是不够的。我们希望看到建议性的补丁，也希望看到运行 LLM 的那个人参与后续沟通，帮助我们讨论和判断这个问题。因为有些情况下，修复可能只是简单的一行代码修改；但更多时候，情况会变成：“我们之前没有考虑到这个问题，需要重新组织部分代码，才能真正解决它。”这时候，就需要最初提交报告的人继续参与。当开发者提出：“这是我们的修复方案，你的 LLM 对此有什么看法？”时，需要有人在中间帮助沟通。

Dirk Hohndel：你刚才提到的，其实揭示了一个很多人容易混淆的区别。LLM 在发现 Bug 方面已经变得非常强大。作为一种“攻击工具”或者“找问题工具”，它们的能力提升非常明显，尤其是在过去半年里。但另一方面，在编写符合 Linux 内核标准的高质量、稳定代码方面，我仍然认为 LLM 更擅长的是“从零到 Demo”。它可以非常快速地帮助你做出一个演示版本，但从 Demo 到真正可投入生产的代码，我并不认为 LLM 一定能够带来同样程度的效率提升。这也是我之前提到生产力提升时想强调的区别。

Linus Torvalds：没错。我自己会在一些“玩具项目”中使用 LLM，而且我非常享受这个过程。我把它看作一种原型开发工具。比如，我可能会想：“我想尝试实现某个功能，但如果让我亲自为这个小项目从头写一堆不确定是否可行的代码，成本太高了。”这时候，我会让 LLM 帮我完成初步实现。当然，这些代码通常不能直接用于生产环境，但它非常适合探索新的想法。我希望这也是目前大多数人使用 LLM 的方式。我也同意，AI 生成的 Bug 报告有时确实会附带补丁。在简单情况下，这些补丁可能完全有效。但很多时候，它们更像是一种“盲目的创可贴”。它们可能解决了眼前的问题，却没有修复底层逻辑错误。结果只是让 Bug 换了一种形式存在，未来可能在另一个地方再次暴露。这类问题，仍然需要那些长期维护代码、真正理解系统整体结构的开发者来解决。根据我的经验，目前 LLM 还没有达到这个水平。未来也许会改变。也许有一天，你可以通过提示词告诉模型：“请从整体角度理解这个问题，请尝试彻底修复它，请展现出一些工程品位。”但至少现在，AI 仍然缺少这种“品位”。

Dirk Hohndel：我认为，反复调整提示词确实能够提升结果质量。但至少目前，它们仍然无法取代经验丰富的架构师所具备的系统级理解能力。

Linus Torvalds：是的，你依然需要一个能够理解整体架构的人。我出于好奇想问一下，在座各位看起来大约有一半是软件工程师，你们当中每天使用 LLM 的有多少人？（现场观众举手）哇，人数非常多。这完全不令人意外，我只是想确认一下。

Dirk Hohndel：显然，AI 已经有很多非常好的应用场景。我们刚才谈到了 Bug 报告质量的变化，以及它们如何帮助内核发现一些长期存在的问题。

Linus Torvalds：有些发现甚至让人感到震惊——当然，是一种有些痛苦的震惊。不要误解，处理 Bug 从来都不是一件令人开心的事情。尤其当 Bug 涉及安全问题，并且几天后登上科技媒体头条时，那种感觉非常糟糕。但我绝不会因此“迁怒于发现问题的人”。恰恰相反，我认为 LLM 帮助我们发现 Bug 是一件非常好的事情。即使这些 Bug 让我们感到尴尬，即使它们可能已经存在了几十年，最终能够找到并修复它们，仍然是一件好事。我们会因此变得更强大。过去几个月确实有些艰难，因为 LLM 发现了一系列相关问题。但这其实并不奇怪：一个人通过 AI 找到了一个 Bug，另一个人可能会继续问 AI：“类似的位置是不是也存在问题？”于是，我们可能会在几周内看到三四个高度相关的 Bug 接连成为新闻焦点。

Dirk Hohndel：以这个话题结束似乎有点沉重，那我们换一个轻松的话题，聊聊 AI 的另一个有趣用途。听说你会在旅行时使用 AI，把“哥斯拉”加入发给家人的照片里？

Linus Torvalds：没错，我自己也会在一些小项目中使用 AI。每次去新的地方旅行——这次是我第一次来到印度——我都会给孩子们发送当地的照片。出于某种奇怪的原因，哥斯拉似乎总是会跟着我，并出现在这些照片里。所以，AI 既有很多严肃的用途，也有很多纯粹为了娱乐的玩法。

Dirk Hohndel：我想“哥斯拉”是一个非常完美的收尾话题。非常感谢各位的聆听，感谢大家到来。