“我并非排斥 Rust，但我希望大家降低对其的预期，不要以为 Rust 能像魔法一样解决所有缺陷。”

近日，Linux 与 Git 创始人 Linus Torvalds 亲临印度孟买，在与 Verizon 开源项目办公室负责人 Dirk Hohndel 的围炉深度访谈中，亮出了这一核心观点。此次对话正值 Linux 7.1 版本发布，延续了非正式演讲的风格，以开放式问答形式，剖析了开源内核数十年的运行机制。

面对 3500 万行庞大内核代码的维护压力，Linus 坦言自己早已不再是一线核心代码编写者，日常工作重心是把握“大局”，关注 Linux 的整体架构。此外，他深入解答了新版本中的若干热点：淘汰 486SX 处理器、内核中两套 NTFS 实现的并存竞争、Rust 语言的边界定位，并直面 AI 对内核社区带来的双重影响。

他还进一步收紧了内核合并窗口的规范，要求维护者避免在截止日前集中提交修复补丁。整场对话超越技术表面，从三十余年开源实践的视角，深入探讨了稳定迭代、语言选择、工具边界、社区治理等根本性问题，如实呈现了 Linux 内核当前的开发实况。

Linux 7.1 新版本发布，稳定迭代持续演进

Dirk Hohndel 的开场轻松随意，但 Linus 的回答直率而坦承：“我非常讨厌公开演讲，选择这种‘围炉对话’的方式，是因为我不需要提前准备，由别人提问，我甚至不知道问题会是什么。” 这或许正是这场对话如此自然流畅的原因。

当被问及新版本有何亮点时，Linus 的回答出人意料的冷静。他表示，Linux 已经很久没有传统意义上的“亮点”了。真正的亮点在于它一直在稳定前行。自 2005 年转向 Git 及新开发模式后，整个流程运行得十分可靠。他们有意避免发布带有“重大、华丽新功能”的版本，而是追求持续的增量改进与稳步推进的节奏。近期，AI 发现了一些有趣的 Bug，给社区带来了一定压力，但总体而言，他们仍保持每 9 到 10 周发布一个新版本的节奏，确保系统稳定演进，而不是时不时给社区带来意外的“惊喜”。

Dirk 提起了更新后的 NTFS 子系统，Linus 兴致勃勃地分享了一段趣闻。Linux 拥有数十种不同的文件系统，而 NTFS 多年来一直是“麻烦制造者”，很难找到维护者。如今，突然出现了两个不同的团队分别维护两个版本的 NTFS，而且两者都能正常工作。Linus 目前的态度是让它们自由竞争，看谁能胜出，或者两者可能会长期共存。

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

另一件备受关注的事，是对 486 架构支持的终止。Dirk 感到些许伤感，但 Linus 斩钉截铁地表示：“是时候放手了。” 在技术问题上，他不是一个感性的人。只要还有用户，就应当继续支持；但到了某个阶段，维护旧硬件的成本会变成沉重负担，不仅体现在修复 Bug 上，更体现在为新功能提供兼容支持上。

从即将发布的 7.2 版本开始，他们将不再支持那些在 x86 架构上缺乏硬件浮点运算单元的机器。最后一款此类硬件大约是 30 多年前发布的 486SX。虽然维护工作量不大，但每次进行更改时，它依然是需要额外关注的部分。如今，他们正更积极地尝试放弃那些除了博物馆外实际已无人使用的硬件支持。近期，他们还清理了业余无线电数据包层、ISDN、ATM 等老旧且无人维护的代码。

“避免在合并窗口截止前扎堆提交修复补丁”

谈到合并窗口，Dirk 注意到一个现象：最近几个内核版本中，后期 RC（发布候选版）的数量明显增加，规模更大的合并请求似乎也更早地集中涌来。Linus 承认，这背后除了 AI 帮助发现了更多问题，还有一个原因在于他自己。过去，他可能过于愿意接受那些并非绝对必要的修复补丁。因此，在上一个版本中，他明确告知社区：“冷静一下。如果不是特别重要的修复，就安排到下一版本，不要总是在最后一刻给我发送修复补丁。”

他希望软件开发人员都能理解：修复补丁本身也可能引入新问题。每到发布窗口后期，都需要权衡：这个修复虽然能解决现有问题，但值不值得冒着引入新 Bug 的风险在这个阶段合入？对于 Linux 内核而言，发布节奏本就很快，一个版本周期大约只有九周，因此将修复推迟到下一版本通常并非大事。他正在努力重新调整节奏，避免连续几个版本规模过大，防止朝错误的方向发展。

当被问及在旅行期间处理 PR 的体验时，Linus 表示，他会尽量避免在旅行期间开启合并窗口。在两周的合并窗口期内，他大约需要完成 200 次合并。他不想只是进行“盲目合并”，虽然非常信任那些长期合作的核心开发者，但职责不仅仅是合并代码，还需要从更宏观的角度理解整个过程。不过，这并不算什么特别有压力的时期。真正让人感到压力的，往往是偶尔出现的“人际关系”问题。代码很容易修复，但人的性格和相处问题并不总是那么容易解决。

“没有人能完全理解 3500 万行代码”

Dirk 好奇，既然要在两周内处理大约 200 个 PR，Linus 还有多少时间去阅读代码、理解背后的意图？Linus 的回答非常实在：“说实话，我现在几乎不再阅读代码了。我不是传统意义上的程序员，而是一名开发主导者。” 他依赖的是“信任”——开源项目本质上都建立在信任之上。他合并的那 200 个拉取请求，来自那些长期合作并值得信赖的人。面对 3500 万行代码的项目，没有人能真正理解全部代码。

在处理拉取请求时，他真正想把握的是“大局”。他要求提交者必须提供详细说明，他会认真阅读这些说明，了解发生了什么以及为何做出这些改动。这样做的意义在于，未来如果出现问题，他能回忆起当时的背景。即使从未亲自查看过那部分代码，遇到问题时也能迅速知道从何入手排查。他已经几十年没有真正编写过所谓的“核心代码”了。

他当然还会写代码，比如给别人发送补丁或提出一个可能的修复方案，但会明确说明这只是一个建议，并未经过完整测试。他希望真正负责这部分代码的维护者能够基于这个思路进一步完善。如今，他亲自提交代码的情况已经非常罕见了。

当然，他也不是完全不看代码。在合并过程中遇到代码冲突时，他就会查看相关代码。冲突往往意味着两个不同团队同时修改了同一部分代码，这时他会仔细看看双方到底做了什么。有时，问题根源在于两个团队实际上有不同的目标。此外，如果一个拉取请求的说明写得不够清楚，他也会去查看代码。即使看完代码，如果他仍然觉得改动不合理，就会拒绝它。

“不要指望 Rust 像魔法一样修复所有 Bug”

当话题转向工具时，Linus 坦言，对他个人而言，Git 和电子邮件就是全部工具。他会使用 Google 查询资料。人们经常在提交说明中提到一些他不熟悉的领域和各种缩写，让他摸不着头脑，这时他就会去 Google 搜索。他特别强调，自己是一个特例。大多数其他维护者使用的工具要丰富得多，很多人现在也开始使用 AI 工具来辅助补丁检查。

既然他的工作是在更高层级上进行，那么他面对的核心对象其实是“人”，而不是工具。他信任的是开发者本人以及他们做出的判断。这种信任往往已经建立了几十年。开发者可能会换公司，但他不关心他们使用什么邮箱或效力于哪家公司。他信任的是这个人本身以及长期展现出的判断能力。很多开源项目都以这种方式运转，这一点在公司内部可能更明显。

Dirk 提到 Git 决定引入 Rust，并询问这种趋势是否会扩展到更多领域。Linus 明确表态：他不确定 Rust 是否会统治整个世界。他个人仍认为 C 语言是一种更简单、更直接的工具。他更关注那些帮助验证 C 代码的工具，比如近年出现的自动化补丁验证工具。这些工具正在创造真正的价值，虽然无法提供 Rust 那样的安全保障，但能让更多“眼睛”检查代码，帮助发现开发者在传统 C 语言开发中常犯的错误。

Dirk 将 C 语言比作“电锯”，Rust 比作“CNC 数控机床”，而 Linus 则笑称自己更像是那种“简单粗暴”的人，依然钟情于 C 语言那种原始而直接的力量。他认为，Rust 确实能避免一些在 C 语言中很容易犯的低级错误，但它并不能解决逻辑错误。它不会替你思考。如果你的代码逻辑本身有问题，那么无论用什么语言，结果都是错的。

“我并非反对 Rust，但我希望大家降低预期，不要认为 Rust 能像魔法一样修复所有 Bug。它只能解决某些特定类型的问题，让一些错误更难发生，但你依然可能犯大量逻辑错误。” 最近 Linux 内核中一些影响较大的 Bug，恰恰都是逻辑错误，而不是内存安全问题，也不是由于某些复杂的语言特性所致，而是单纯的编程逻辑出了偏差。即使是在维护良好的子系统中，甚至是在理论上应该非常安全的内核核心部分，也依然可能发生这种情况。

关于 Rust 与 C 代码的交互，Linus 指出，大多数 Rust 与 C 代码的交互，实际上都是与内核核心部分的 C 代码打交道。而内核核心代码的质量通常高于外围代码。这并不是因为编写核心代码的人更聪明，而是因为核心代码会在各种环境中经历极其充分的测试。它是内核的基础部分，无论运行什么场景，都会涉及内存管理、核心调度器等组件，因此这些代码会在 Linux 支持的所有平台上不断接受实际运行检验。相比之下，具体硬件驱动只有在对应硬件存在并被使用时才有机会得到充分测试。Rust 目前主要交互的，往往正是那些最稳定、开发最完善的部分。

对于新开发者，Linus 建议可以从驱动程序入手，因为那里提供了大量学习和实践的机会。但同时也要提醒，Linux 内核是一个极其庞大的项目，并非一个容易上手的领域，对新开发者和整个开发流程都有非常严格的规范和要求。

AI 仍然缺乏“工程品位”

对话不可避免地转向了 AI 和 LLM。Linus 之前曾提到大语言模型可能带来大约 10 倍的效率提升，但这次他澄清，那只是随口举的一个数字，并不是科学计算的结果。他认为，目前来看，LLM 创造的生产力能否超过它消耗的精力还有待观察。

在今年年初之前，他们看到更多的是 LLM 生成的垃圾代码，而不是有实际价值的代码。即使到现在，它仍然会消耗开发者大量资源。例如，你可能会收到一些看似合理的 Bug 报告，但最终发现只是 AI 产生的“幻觉”，开发者需要花费大量时间去验证，最后却发现并不真实，这造成了巨大的资源浪费。

不过，过去几个月情况有所改善，他们开始收到一些质量非常高的 Bug 报告。但这些高质量报告通常并非单靠 LLM 产生，而是需要一个“中间人”——也就是人类开发者参与其中。他强调，如果使用 LLM 发现了一个 Bug，仅仅让模型生成一份报告然后直接提交是不够的。他们希望看到建议性的补丁，也希望看到运行 LLM 的那个人参与后续沟通，帮助讨论和判断问题。

Dirk 补充道，LLM 在发现 Bug 方面确实已经非常强大，但在编写符合 Linux 内核标准的高质量、稳定代码方面，它更擅长的是“从零到 Demo”，可以快速做出演示版本，但从 Demo 到真正可投入生产的代码，并不一定能带来同样程度的效率提升。

Linus 对此表示赞同。他会在一些“玩具项目”中使用 LLM，而且非常享受这个过程，将其视为一种原型开发工具。例如，想尝试实现某个功能，但若要亲自从头写一堆不确定是否可行的代码，成本太高，这时他会让 LLM 帮忙完成初步实现。这些代码通常不能直接用于生产环境，但非常适合探索新想法。他也希望这是目前大多数人使用 LLM 的方式。

他承认，AI 生成的 Bug 报告有时确实会附带补丁。在简单情况下，这些补丁可能完全有效。但很多时候，它们更像是一种“盲目的创可贴”，可能解决了眼前的问题，却没有修复底层逻辑错误，结果只是让 Bug 换了一种形式存在，未来可能在另一个地方再次暴露。这类问题，仍然需要那些长期维护代码、真正理解系统整体结构的开发者来解决。目前来看，LLM 还没有达到这个水平。未来也许会改变，也许有一天可以通过提示词告诉模型：“请从整体角度理解这个问题，请尝试彻底修复它，请展现出一些工程品位。”但至少现在，AI 仍然缺少这种“品位”。

Dirk 对此深表认同：反复调整提示词确实能改善结果质量，但至少目前它们仍然无法取代经验丰富的架构师所具备的系统级理解能力。Linus 甚至现场询问了在座的软件工程师，多少人每天使用 LLM，结果举手的人数之多并不令人意外。

尽管 LLM 帮助发现了一些让人“有些痛苦地震惊”的 Bug，尤其是那些涉及安全且登上科技媒体头条的 Bug，但 Linus 明确表示，他绝不会因此“迁怒于发现问题的人”。恰恰相反，他认为 LLM 帮助发现 Bug 是一件非常好的事。即使这些 Bug 让人尴尬，即使它们可能已经存在了几十年，最终能够找到并修复它们，仍然是一件好事。他们会因此变得更加强大。

最后，Dirk 以 AI 的另一个有趣用途——Linus 会在旅行时使用 AI，把“哥斯拉”加入到发给家人的照片中——作为轻松收尾。Linus 坦然承认，他每次去新的地方旅行都会给孩子们发送照片，出于某种奇怪的原因，哥斯拉似乎总是会跟着他并出现在这些照片里。AI 既有很多严肃的用途，也有很多纯粹为了娱乐的玩法。这场关于技术、代码与人性的对话，在“哥斯拉”这个幽默的注脚中落下了帷幕。