整理 | 屠敏
出品 | CSDN（ID：CSDNnews）

“我绝不反对 Rust，大局但我必须降低大家的没人码预期：不要指望 Rust 能像魔法一样修复所有 Bug。”

近日，彻内核Linux 与 Git 之父 Linus Torvalds 现身印度孟买，底搞懂L的万代该与 Verizon 开源项目办公室负责人 Dirk Hohndel 展开了一场深度“围炉”对话。行代修复此次交流恰逢 Linux 7.1 版本发布，演进Linus 摒弃了传统的掌控正式演讲，以自由问答的所有形式，拆解了开源内核数十年的结束运转逻辑与未来演进方向。

面对 3500 万行庞大代码库的大局维护压力，Linus 坦言自己早已脱离一线核心编码，没人码转而专注于把控“大局”与整体架构。彻内核他深入探讨了淘汰 486 处理器、底搞懂L的万代该NTFS 子系统双版本并行竞争、行代修复Rust 语言的演进定位边界，并直面 AI 给内核社区带来的双面冲击——LLM 虽能挖掘隐蔽 Bug，却因缺乏全局工程思维，往往只能产出“创可贴式补丁”。

此外，Linus 还收紧了内核合并窗口规则，强调避免在截止期前扎堆提交修复；并直言，维护大型开源项目最大的挑战并非代码冲突，而是复杂的人际沟通。

视频地址：https://www.youtube.com/watch?v=YKkEe-PxW10

Linux 7.1 发布：稳定迭代优于华丽新功能

Dirk Hohndel：很高兴回到孟买，这里令人兴奋。我大概 21 年没来了，天气宜人，美食也很棒。我是 Dirk Hohndel，从事开源开发的时间可能比在座大多数人都长。这位是……

Linus Torvalds：我是 Linus。请别鼓掌，我极其讨厌公开演讲。采用“围炉谈话”形式，是因为我不需提前准备，由他人提问，这让我感到更自然，也减少了对公开场合的厌恶。

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

Linus Torvalds：说实话，我们很久没有传统意义上的“亮点”了。真正的亮点在于 Linux 始终在稳定向前发展。自 2005 年转向 Git 开发模式及新发布周期以来，流程一直可靠。我甚至刻意避免发布拥有“重大、华丽新功能”的版本，转而追求持续的增量改进和稳步推进。

近期因 AI 发现了一些有趣 Bug，给社区带来了一定压力，但总体而言，我们仍保持每 9 到 10 周发布一个新版本的节奏，确保系统稳定演进，而非带来意外的“惊喜”。

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

Linus Torvalds：NTFS 在 Linux 中有一段奇特历史。作为众多文件系统之一，它曾是“问题儿童”，长期缺乏维护者。如今，两个不同团队维护着两个不同版本的 NTFS，且均能正常工作。我的态度是：让他们竞争，看谁胜出，或者两者长期共存。

37 年后，Linux 正式告别 Intel 486 处理器

Dirk Hohndel：另一件热议之事带点伤感：对 486 的支持消失了。

Linus Torvalds：是时候放手了。在技术上我不感性。虽然只要还有用户就应支持硬件，但维护旧硬件的成本终将成为沉重负担。这不仅涉及 Bug 修复，更在于为新功能提供兼容支持。

我们将移除浮点模拟代码。这并非针对 486，而是针对更早一代无硬件浮点运算单元（FPU）的 x86 机器。从即将发布的 7.2 版本开始，我们将不再支持此类硬件。最后一款此类硬件大概是 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 发布节奏快（约 9 周一版），将非紧急修复推迟几周并无大碍。此前几个版本规模过大，我正努力调整节奏。

Dirk Hohndel：经过两天 PR 合并，有何印象深刻之事？

Linus Torvalds：没有。我尽量避免在旅行期间开启合并窗口，因为那是我最忙碌的时候。

两周合并期内，我需完成约 200 次合并。我不希望“盲目合并”。尽管我信任合作数十年的核心开发者，但我职责不仅是合并代码，更需从宏观角度理解过程。

这并非特别有压力。我们有有序的发布流程，技术问题均可解决。真正让我感到压力的，往往是“人际关系”问题。代码易修复，但人的性格和相处问题难解决。合并窗口期间，真正的困难往往在于处理人际问题，而非技术细节。

“3500 万行代码，无人能真正理解全部”

Dirk Hohndel：你希望更多了解进入内核的代码。处理约 200 个 PR 时，你有多少时间阅读代码、理解意图？

Linus Torvalds：说实话，我现在几乎不再阅读代码了。我不是传统程序员，而是开发主导者。我知道如何编程，但 Linux 内核之外，我只写一些业余小玩意。

我更多依赖“信任”。开源项目建立在信任之上——我们彼此了解，共事多年甚至数十年。我合并的 200 个 PR 来自我长期信任的人。

我不需要完全理解每一行代码。面对 3500 万行代码的项目，无人能真正理解全部。

处理 PR 时，我关注“大局”。我要求提交者提供详细说明，我会仔细阅读，了解背景与动机。这样即使未来出问题，我也能回忆背景，知道从何排查。

事实上，几十年来我已不再编写所谓的“核心代码”。

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

Linus Torvalds：是的，我会发补丁或建议修复方案，但明确说明这是未经完整测试的建议。我期望负责该部分的维护者基于此完善并提交最终修复。我现在亲自提交代码的情况极少。

Dirk Hohndel：你说自己不看代码，这很有趣。对维护者而言，提交导致构建失败的 PR 是获得你注意力的有效方法。

Linus Torvalds：我正在改进这一点。

我并非完全不看代码。例如，遇到代码冲突时，我会查看相关代码。这很常见，我闭着眼也能解决。但冲突往往暴露两个团队目标不一致的问题，此时我会仔细审视双方改动。

若 PR 说明不清，我也会看代码以理解意图。若看完仍觉得改动不合理，我会拒绝。

虽然我不是传统程序员，但我拥有深厚技术背景，能在需要时做出判断。

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

Dirk Hohndel：Git 仍是你的主要工具吗？是否有希望拥有的新工具？

Linus Torvalds：对我而言，Git 和电子邮件是全部工具。我会用 Google 查询资料，因为我不擅长记忆行业缩写。人们提交说明中常使用我不熟悉的术语，这时我会搜索。所以 Google 也是我的工具。

绝大多数时候，我阅读邮件并使用 Git 合并代码。

但我是特例。其他维护者工具更多，许多人使用 AI 辅助补丁检查。但我工作在更高层级，核心对象是“人”而非工具。我信任开发者本人及其长期展现的判断力，无论他们效力于哪家公司。

Dirk Hohndel：Git 本月引入 Rust，未来将成为必需项。你认为这种趋势会蔓延吗？Linux 内核也已支持 Rust。

Linus Torvalds：我不确定 Rust 是否会接管世界。Rust 很有趣，但基于我的经历，C 语言仍是更简单、直接的工具。

我更关注帮助验证 C 代码的工具。静态分析已有多年，但我更喜欢近年出现的自动化补丁验证工具。它们虽无 Rust 的安全保障，但能让更多“眼睛”检查代码，发现 C 语言常见错误。

我对 Sashiko 等自动化测试工具及补丁邮件检查流程感到兴奋。

Dirk Hohndel：C 像电锯，Rust 像 CNC 数控机床。有人习惯用电锯……

Linus Torvalds：我属于“简单粗暴”派。我喜欢 C 语言原始直接的力量，这点不会改变。

Git 的目标并非 C 语言本身，C 只是实现选择。Git 早期就有 Java 版本，服务器环境中 Java 版 Git 很方便。Git 支持 Rust 并非巨大变化，因为它本就支持多语言实现。

Dirk Hohndel：Rust 正被推广至更多领域，如 Ubuntu 23.10 自动更新故障。

Linus Torvalds：公平地说，Rust 能避免 C 语言中的低级错误，但不能解决逻辑错误。它不替你思考。

若代码逻辑有误，无论何种语言，结果皆错。我完全不反对 Rust，但希望降低预期：不要认为 Rust 能像魔法一样修复所有 Bug。它仅解决特定类型问题，你仍可能犯大量逻辑错误。

事实上，Linux 内核近期一些重大 Bug 恰恰是逻辑错误，而非内存安全问题或复杂语言特性导致。即使在理论上安全的内核核心部分，也可能发生。

不要期待某种编程语言能自动解决所有 Bug。

Dirk Hohndel：Rust 与 C 交互时，安全保证会消失。

Linus Torvalds：客观而言，大多数 Rust 与 C 的交互涉及内核核心 C 代码。核心代码质量通常高于外围代码，因其经历极其充分的测试，涉及内存管理、调度器等，在所有平台上接受检验。

相比之下，硬件驱动程序仅在对应硬件存在时才得到充分测试。因此，内核代码质量存在差异。Rust 目前主要交互的，往往是最稳定、开发最完善的核心部分。

Dirk Hohndel：内核本身也存在差异，核心代码经过最多测试，最值得信赖。

Linus Torvalds：是的。核心代码获最多关注。即使驱动开发者也需理解核心接口；但核心 VFS 层维护者无需查看具体驱动实现。

因此，我建议新开发者从驱动程序入手，那里有大量学习机会。但需提醒，Linux 内核庞大，入门不易，我们对新开发者有严格规范。

AI 仍缺少“工程品位”

Dirk Hohndel：对话已 26 分钟，终于聊到 AI 和 LLM。你曾提 LLM 带来约 10 倍效率提升。

Linus Torvalds：需澄清，“10 倍”非科学计算，只是随口举例。

Dirk Hohndel：LLM 目前为内核社区带来多少真正价值？

Linus Torvalds：我希望其创造的生产力超过消耗的精力。

年初前，LLM 多生成垃圾代码。即便现在，仍消耗大量资源。例如，开发者可能收到看似合理的 Bug 报告，实则是 AI“幻觉”，需花费大量时间验证，造成资源浪费。

但近几个月情况改善，我们收到高质量 Bug 报告。但这通常需“中间人”——人类开发者参与。

我们强调：若用 LLM 发现 Bug，仅生成报告并直接提交是不够的。我们希望看到建议性补丁，且希望 LLM 使用者参与后续沟通，协助判断。因为修复可能需重新组织代码，而非简单一行修改。

Dirk Hohndel：这揭示了区别：LLM 在发现 Bug 方面强大，但在编写符合内核标准的高质量代码方面，更擅长“从零到 Demo”，而非从 Demo 到生产代码。

Linus Torvalds：没错。我在“玩具项目”中使用 LLM，视其为原型开发工具。若尝试实现新功能，亲自写不确定可行代码成本太高，LLM 可助初步实现。这些代码虽不能直接用于生产，但适合探索新想法。

我也同意，AI 生成的 Bug 报告有时附带补丁。简单情况下可能有效，但很多时候，它们更像“盲目的创可贴”。它们解决眼前问题，却未修复底层逻辑错误，Bug 仅换形式存在，未来可能在别处暴露。

这类问题，仍需长期维护代码、理解系统整体结构的开发者解决。据我经验，LLM 尚未达到此水平。

未来或许改变。也许有一天，通过提示词让模型“从整体角度理解”、“彻底修复”、“展现工程品位”。但至少现在，AI 仍缺少这种“品位”。

Dirk Hohndel：反复调整提示词能提升质量，但目前它们无法取代经验丰富的架构师所具备的系统级理解能力。

Linus Torvalds：是的，你仍需理解整体架构的人。我好奇在座约一半是软件工程师，每天使用 LLM 的有多少人？（观众举手）哇，很多。

Dirk Hohndel：AI 有很多好场景。我们谈了 Bug 报告质量变化及帮助发现长期存在的问题。

Linus Torvalds：有些发现令人震惊——痛苦的震惊。处理 Bug 从不愉快，尤其涉及安全并登上头条时。

但我绝不“迁怒于发现问题的人”。相反，我认为 LLM 帮助发现 Bug 是好事。即使 Bug 让我们尴尬，即使存在几十年，找到并修复它们仍是好事，我们会因此更强。

过去几个月艰难，因 LLM 发现一系列相关问题。这并不奇怪：一人通过 AI 找到 Bug，另一人可能问 AI：“类似位置是否也有问题？”于是，几周内可能有多个相关 Bug 成为焦点。

Dirk Hohndel：以沉重话题结束似乎不妥，聊聊 AI 的轻松用途。听说你旅行时用 AI 把“哥斯拉”加入发给家人的照片？

Linus Torvalds：没错。每次去新地方——这次是印度——我都会给孩子发当地照片。出于奇怪原因，哥斯拉似乎总跟着我，出现在照片里。

AI 既有很多严肃用途，也有纯粹娱乐玩法。

Dirk Hohndel：“哥斯拉”是完美收尾。感谢聆听，感谢大家到来。

2026 奇点智能产品大会全日程正式发布!

7月17-18日，北京金隅喜来登大酒店

40+位来自字节、百度、阿里、腾讯、宇树、360、京东、蚂蚁、科大讯飞等一线产品技术领袖，围绕 Agent 智能体、企业级 AI、AI Coding、具身智能、AI 原生组织等 12 大专题，全链路拆解 AI 原生落地闭环。