Linus Torvalds谈开源技术：Linux、Git、Rust与AI，开源世界如何应对新技术浪潮？

Linus Torvalds谈开源技术：Linux、Git、Rust与AI，开源世界如何应对新技术浪潮？

如果只看技术履历，Linus Torvalds是Linux和Git的创造者，是过去三十多年开源世界绕不开的人物。但在这场对谈里，更值得看的并不只是他如何评价Linux 7.1、Rust、C语言或AI，而是一个长期站在复杂系统中心的人，如何理解软件、社区、工具和人。

这场对话发生在一场开源技术会议上，由DH Consulting创始人、资深开源开发者Dirk Hohndel提问，Linus Torvalds回答。两人的关系并不陌生，Dirk熟悉开源社区的脉络，也知道该如何把Linus从“技术细节”引向更大的工程问题。

于是，这场对话从Linux 7.1发布聊起，一路谈到内核开发节奏、486等老旧硬件支持的退出、Git与邮件驱动的协作方式、C与Rust的语言取舍，以及LLM正在给Linux内核社区带来的真实变化。

这场对话最有意思的地方在于，Linus并没有把技术趋势包装成宏大的叙事，而是始终从工程实践出发。他谈到，Linux内核已经不追求“惊艳发布”，而是依靠20多年来稳定运行的开发节奏持续演进；486、ISDN、ATM等旧硬件和旧代码的逐步退出，也不是怀旧与否的问题，而是维护成本与代码可维护性的现实取舍。

在语言之争上，Linus依然保持了典型的工程师式直白。他承认Rust能减少一部分类C语言中常见的错误，但也提醒外界不要神化Rust：语言无法替人思考，更无法自动修复逻辑错误。相比“Rust会不会接管世界”，他更关注C代码验证工具、自动化补丁检查和代码审查体系的进步。

在谈到AI和大语言模型时，Linus的态度同样克制。他把LLM视为工具，而不是魔法。它们已经在发现bug、生成原型、辅助验证方面展现出价值，尤其能把更多“眼睛”投向过去很少被充分审查的代码角落。但与此同时，AI生成的错误报告、幻觉内容和“创可贴式补丁”也在消耗维护者资源。对Linux内核这样的复杂工程而言，LLM目前还无法替代长期维护者的架构判断、工程经验和代码品味。

从某种意义上说，这场对话不只是Linus对Linux、Git、Rust和AI的一次集中回应，也呈现了开源世界面对新技术浪潮时最朴素的一面：工具可以变化，语言可以变化，AI也可以加入流程，但真正支撑大型工程长期运转的，仍然是信任、经验、审查机制和对复杂系统的敬畏。

以下为完整对话内容，经InfoQ编译：

“我对技术不是特别怀旧”

Dirk Hohndel：很高兴来到这里，也很高兴再次回到孟买。我已经大概21年没来过这里了。我叫Dirk Hohndel，是一名开源开发者，从事开源的时间可能比在座很多人的年龄都长。你来介绍下你自己吧，Linus。

Linus Torvalds：我是Linus。之所以采用这种有点奇怪的炉边对谈形式，是因为我非常讨厌公开演讲。所以解决办法就是，不让我自己准备演讲内容，而是由别人来准备问题，然后问我一些我事先不知道的问题。这样对话会更自然一点，也让我没有那么讨厌这种公开场合。

Dirk Hohndel：这是一个很有说服力的开场。你最近其实是在伦敦希思罗机场发布了Linux 7.1。这个版本有哪些亮点？

Linus Torvalds：我通常会说，从传统意义上讲，Linux版本发布并没有太多所谓“亮点”。对我来说，真正的重点一直是持续、稳定的改进。我们已经用同样的方式做了20多年。2005年，我们切换到了基于Git的新开发模式，也采用了新的发布节奏。一开始大家需要适应，但后来这个模式运行得非常可靠。

这也意味着，我们不会做那种带有巨大、炫目新特性的版本发布。我其实会主动避免那种模式。我们想要的是持续的、增量式的改进，让项目一直稳定向前。

最近这件事变得稍微困难了一些，因为AI找到了一些有意思的bug，这也让社区里一些人感到压力。但总体而言，Linux仍然保持着稳定的发布节奏：大约每9到10周发布一个新版本，并尽量确保它稳定，不让社区感到意外。

当然，这个版本也有一些有趣的新东西。比如更新后的NTFS子系统，这应该是大家期待已久的，尤其是来自微软的演讲嘉宾可能会很关心。Linux和NTFS的历史一直有点奇怪。多年来，NTFS一直像个“问题孩子”，维护者也不总是好找。现在突然出现了两个不同的团队，分别维护两个不同版本的NTFS，而且它们都能工作。所以我就让他们先竞争，看最后哪个版本胜出，也有可能两个版本都会长期存在。这确实算是比较有意思的变化之一。

另一个很多人提到、也有点让人伤感的变化是：486支持被移除了。

Dirk Hohndel：是的，很多人都在讨论486被移除这件事。能跟我们展开讲讲吗？

Linus Torvalds：现场有多少人是在486发布时已经出生的？这件事该发生了。可以这么说，我对技术并不是特别怀旧。我当然支持，只要还有用户，我们就应该尽量维护硬件支持。但到某个阶段，继续维护非常老旧硬件的成本会变成负担。

这里的问题甚至不只是bug，而是特性支持。我们终于要移除浮点仿真代码了。严格来说，这甚至不是这次7.1，而是下一个7.2版本里的事情。我们将不再支持那些在x86上没有硬件浮点单元的机器。

我印象中，最后一批这样的硬件大概是30年前发布的，也就是486SX，大概是1993年左右。所以这真的是30多年前的硬件。过去我们仍然支持这类硬件平台。它本身也许不需要很多工作，但每次你做变更时，仍然要额外考虑它。

因此，现在我们会稍微更主动地移除那些实际上已经没有人使用、只存在于博物馆环境里的硬件支持。最近类似的例子还有业余无线电packet layer，以及一些无人维护的旧代码，比如ISDN、ATM等也在逐步移除。

这也是持续改进的一部分。我们需要清理代码库，确保它仍然可维护。Linux是一个非常庞大的代码库，它永远不会变得“容易维护”，但至少我们不应该让它比必要程度更难维护。

“我几乎不写、也不读内核代码了”

Dirk Hohndel：说到维护的难度，合并窗口开启时，你其实正在飞往孟买的飞机上。也就是说，你坐在飞机座位上就开始合并代码了。

过去几个内核版本里，我们看到后期RC阶段的补丁量明显增加。那么在这次合并窗口中，是否也出现了更大规模的merge request更早涌入的情况？

Linus Torvalds：合并窗口确实稍微变大了一些，但没有后期RC增长得那么明显。

这里面有一个显而易见的原因：现在有很多AI工具在发现问题，而这些问题随后会被修复。有些修复不只是下一个版本的常规开发内容，而是我们有时觉得必须比较积极地修掉的问题。

但另一方面，我觉得这也有我的责任。我可能有点过于愿意接受那些并非绝对必要的修复了。上一个版本里，我基本上已经告诉大家：冷静一点。如果不是非常重要的修复，请把它排到下一个版本，不要在最后时刻发给我。

在座很多人应该都是软件开发者，大家应该都知道：修复确实是在修问题，但偶尔一个修复也会引入新的问题。所以这里有一个平衡。你需要判断：是的，这是一个修复；但如果已经到了发布窗口很晚的阶段，这个修复是否值得承担它可能带来新问题的风险？

所以我接下来会更明确地往回推一些。因为我觉得有些人已经太习惯在发布窗口很晚的时候提交修复了。尤其是内核社区的发布节奏本来就比较快，我们大约每9周就发布一次，所以说“我们等一下，把这个修复放到下个版本”并不是很大的问题。

如果一个修复并不是特别严重，而我们又对它有一点担心，那完全可以先等几周。我觉得过去几个版本有点太大了，这让我担心方向不太对。所以现在我想把这个趋势纠正回来。

Dirk Hohndel：那在合并PR的前两天里，有什么特别突出的东西吗？

Linus Torvalds：没有。我一般会尽量避免在旅行期间遇上合并窗口，因为合并窗口是我最忙的时候。两周时间里，我大概要做200次合并，这是一个非常粗略的数字。

这也意味着，我不想只是盲目合并。虽然我信任那些长期合作的主要开发者，有些人我甚至已经合作了30年，但我仍然觉得，我的工作不只是合并代码，还要从高层次理解正在发生什么。

所以合并窗口是一个非常忙的阶段，在飞机上用笔记本做这件事当然谈不上有趣。但同时，它也不是一个特别让我紧张的阶段。我们的发布流程非常有组织，新代码是一个技术问题，而技术问题不会让我太焦虑，因为它们可以被修复。

我会经历这两周非常忙的时间，当然最好不要是在飞机上。但真正让我紧张的不是代码，而是偶尔出现的人际问题。相信我，代码很容易修，人格问题、人际问题就不总是那么容易修了。这些事情往往更有压力。虽然大多数时候，希望它们在外界看来是不可见的，因为我们并不想把这些事情变成媒体喜欢的冲突戏码。

Dirk Hohndel：你刚刚说到，你希望对进入内核的内容有一个更高层次的理解。但两周内有大约200个merge request，你实际上有多少时间去读代码？你怎么理解这些代码触及了哪些领域？

Linus Torvalds：老实说，我现在几乎不读代码了。我已经不是一个程序员了，我更像是一个开发负责人。我知道怎么写程序，也仍然会为了兴趣写代码。但我出于兴趣写的那些项目并不是内核，而是一些我私下玩的玩具项目。

在Linux内核上，我依赖的是信任。我认为开源本身也依赖信任。我们彼此认识，一起工作了很多年，有时甚至是几十年。我合并的这大约200个pull request，都是来自我长期合作、并且信任的人。

当你面对3500万行代码时，没有人能真正理解全部代码。所以对我来说，处理pull request时，我想理解的是大图景。这也是为什么我要求pull request必须有非常好的解释说明，因为我会认真读这些说明。

我想知道发生了什么。这样，当之后出现问题时，即便我当时没有读过具体代码，我也能想起来：好，我大概知道这是什么方向的问题，也知道应该去看哪部分代码。

这就是我现在工作的层级。我已经很多年没有真正写“真实代码”了。

Dirk Hohndel：但你还是写一些小东西吧？

Linus Torvalds：我仍然会写代码，意思是我会给别人发patch。有时我会发一个很小的建议性修复，然后说：也许可以这样做。

但我会非常明确地说明：这只是一个建议，没有经过测试。也许我编译过它，有时甚至可能运行过它，但我期待真正维护那部分代码的人来判断，并最终把修复发回来。

所以我现在很少直接提交自己的代码。当然，这种情况也会发生，但已经相当少了。

Dirk Hohndel：你说你不怎么看代码，这一点很有意思。因为维护者想要获得你“全神贯注关注”的方式之一，就是提交一个会破坏构建的pull request。那时你就会去看代码，而且你一向以非常“友好和理解”的方式指出问题。

Linus Torvalds：我正在努力变得更好。但确实，我会看代码。比如在合并过程中出现冲突时，我会看代码。这种情况一直都会发生，也不是问题。有些人认为冲突很难，但这么多年下来，我已经处理过太多冲突，可能睡着了都能解决。我不担心这个部分。

不过，当我看到冲突时，它通常意味着两个不同小组在同一块代码区域同时工作。这时我确实想看一看他们分别在做什么。很多时候，我看代码时会发现一些问题，而这些问题正是因为两个团队同时修改同一部分代码、但目标不同所造成的。

另外，当某个pull request的解释不够充分时，我也会去看代码。有人给我发pull request，但说明不清楚，我经常会直接看代码。然后有时我会觉得：哦，原来如此，这说得通。有时则完全说不通，那我就会反对。

所以，是的，我也许已经不再是严格意义上的程序员，但我仍然有足够强的技术背景。看到代码时，我仍然能够做判断。

不要以为Rust能修掉所有bug

Dirk Hohndel：我们刚才谈到，Linux在20年前切换到了现在这套开发模式，其中一个重要原因就是Git的出现。Git现在仍然是你处理所有事情的主要工具吗？你还会使用其他工具吗？有没有你希望拥有但现在没有的工具？

Linus Torvalds：对我个人来说，Git和邮件基本上就是我真正使用的两个工具。

当然，我也会用Google来查东西。也许你们中有人是超人，可以记住行业里所有三字母缩写，但我不是。有人给我发解释，他们可能工作在某个我不熟悉的角落，然后使用那个领域里的各种缩写和简写。我会想：这到底是什么？这时候我就会用Google。

所以从这个意义上说，Google也是我使用的工具。但大部分时间，我就是读邮件，然后用Git做合并。这是我的主要工具。

不过我也要指出，我是一个比较特殊的例子。大多数其他维护者会使用更多工具。我认为很多人已经开始使用AI工具做patch检查。但因为我声称自己是在更高的层次上工作，我面对的是人，而不是工具。

这也是为什么我一直强调，最重要的是信任，是信任那个人。我信任的是具体的人。几十年来都是这样。开发者会从一家公司跳到另一家公司，我并不关心他们用什么邮箱，也不关心他们在哪家公司工作，因为我信任的是这个人，相信他能做出判断。

我认为很多项目都是这样运作的，但在开源里尤其如此。在公司内部，你可能因为某个人和你在同一家公司，所以信任他；但在开源里，你信任一个人，是因为你和这个人一起工作了很长时间。

Dirk Hohndel：Git当然也是你启动的另一个重要项目。这个月，Git决定让Rust成为默认开启的选项，虽然它目前仍然是可选的；而在下一个版本Git 3中，Rust将成为要求。你认为这种情况会出现在更多领域吗？内核现在也已经把Rust作为官方允许和支持的编程语言之一。

Linus Torvalds：我不确定Rust会接管整个世界。我仍然认为Rust非常有意思。但与此同时，我仍然觉得C是一个简单得多的工具。所以我个人其实更兴奋的是，现在我们有了很多用于验证C代码的工具。

很多静态分析工具已经存在很多年了，但我很喜欢的是，现在我们开始有一些自动化补丁验证工具，它们确实带来了实际价值。它们不一定能带来Rust那种意义上的安全性，但它们相当于给传统C代码里人们常犯的错误多加了一双眼睛。所以，对正在出现的这类工具，我其实非常兴奋。

Dirk Hohndel：我们现在也有一些针对补丁的自动邮件检查工具，比如Sashiko。

Linus Torvalds：对。我一直觉得，C就像一把链锯，而Rust更像是一台带有严格控制的CNC机床。不同的人适合不同的工具。有些人就是更适合链锯，而我更像是喜欢直接上手、一路砍过去的那种人。我仍然喜欢C那种原始、简单但强大的力量，而且我不认为这一点会改变。

不过回到Git。对我来说，Git的目标之一从来不是C本身。C不是问题，C只是一个实现选择，因为那是我一直使用的语言。

我真正希望Git拥有的是少数几个非常高层次的概念，这些概念可以解释整个架构。你其实可以从很早期的Git历史里看到这一点。我们不只有C版本，也有Java版本。很多公司后台其实都在运行Java版本，因为在服务器环境里，一个Java版本的Git通常非常方便。

所以，Git现在支持Rust，我认为这并不像Rust进入内核那样是一个巨大的变化。因为Git早就已经有多种不同语言并存的情况。

Dirk Hohndel：你这么说很有意思。Rust现在已经被推向很多领域。我们已经看到一些人用LLM把现有工具重写成Rust，也已经看到一些相当糟糕的bug，比如Ubuntu 25.10的自动更新问题。这件事你怎么看？

Linus Torvalds：公平地说，Rust的确可以避免一些你在C里面容易犯的简单错误，但它不会修复逻辑错误，对吧？它不会替你思考。

如果你写的是错误代码，那么语言本身并不重要，最后结果仍然会是错的。所以我完全不反对Rust，但我也想降低大家的预期：不要以为Rust能修掉所有bug。

Rust确实能修掉几类bug，让这些bug更难出现。但你仍然可以犯很多逻辑错误。事实上，最近内核里一些比较大、比较受关注的bug，就是逻辑错误。它们不是内存安全问题，也不是某种微妙的语言问题，就是糟糕的编程。而遗憾的是，即使在维护非常谨慎的子系统里，这种事情也会发生。即使是那些很重要、理论上应该非常安全的内核代码里，也会发生。

所以，不要期待一门语言能神奇地替你修掉所有bug。

Dirk Hohndel：这里还有一个问题。在内核、Git这类工具的过渡阶段，C代码和Rust代码会互相交互。Rust给你的那些保证，只适用于代码库里纯Rust的部分。一旦你和C代码交互，这些保证就不再完全成立了。

Linus Torvalds：公平地说，大多数和C代码交互的Rust代码，交互的是内核里的核心C代码。而这些核心代码的质量通常比外围的一些C代码要高得多。

我这么说不是因为写这些代码的人更聪明，或者是更好的程序员，而是因为这些代码已经在各种环境下被测试过。它们太核心了。无论你做什么，都会和内存管理、核心内核代码之类的东西打交道。所以这些代码已经在Linux支持的每一个平台上被测试过。

但另一方面，很多单独的驱动程序，只有当你拥有特定硬件时才会被测试。所以在内核里，代码的可靠程度确实是不一样的。我认为，Rust侧现在接触到的很多C代码，恰恰是更稳定、更成熟的核心代码。

Dirk Hohndel：内核本身也有这样的结构：有些代码经过了大量测试，有些实验性代码可能没有测试得那么充分。还有我们前面提到的，一些更老的代码因为硬件已经不常见，甚至已经不存在了，所以也不太常被使用。

比如有多少人在自己的S390上跑Linux，我不知道。但我不认为那是大型机上运行的主要操作系统。所以我觉得，测试最多、审查最多、最值得信任的代码，往往是所有人都依赖的核心代码。是这样吗？

Linus Torvalds：是的。而且这类代码通常也是被最多人看到的代码。即使你是一个驱动开发者，通常也需要了解一点核心代码。你需要知道内核里的内存分配是怎么工作的，所以你至少会看过那些接口。

但反过来就不一定成立。如果你维护的是核心VFS层之类的东西，你可能永远不会去看某一个具体的驱动。

所以我确实会鼓励那些想进入内核开发的人从驱动开始。因为那里有很多……我不想说“问题”，但那里确实有很多边缘情况。

Dirk Hohndel：我们可以称之为学习机会。

AI可以带来10倍提效？

Linus Torvalds：对，学习机会。但与此同时，我也想提醒大家，内核真的很大。它不是最容易上手的项目。所以我也想稍微降低大家的预期。我们对新开发者有相当严格的规则，也有固定的做事方式。

Dirk Hohndel：我想先郑重指出一下：我们已经聊了很多内容了，但居然还没有谈到AI和LLM。不过我觉得，这可能是本次会议里唯一一场能坚持这么久才谈AI的对话。当然，我们还是应该谈谈这个话题。一个月前，我们在明尼阿波利斯也做过一场类似形式的对谈。那次有很多人注意到，你在台上说，你认为LLM只是一个工具。这个观点我完全同意。

你当时还说了一句很有意思的话：你说它可能带来10倍的增量效率。然后很多人就说，“哦，Linus认为LLM能让一切都变好10倍。” 所以我很好奇，你当时说的那个10倍，到底是什么意思？

Linus Torvalds：那不是科学数字，显然，那就是我随口拍出来的数。

Dirk Hohndel：本来这是后面两个问题之后才要问的。所以换句话说，那是你凭直觉给出的一个数字。那么LLM到底提供了多少真实的增量价值？

我们刚才说，核心代码会得到更多人的关注。但LLM可以把同样的审查力度、同样的算法、同样的逻辑测试能力应用到所有代码上。你觉得LLM现在能在多大程度上为Linux内核社区带来生产力提升？我说的不是对你个人，而是对整个内核社区。

Linus Torvalds：现在我们大概处在这样一个阶段：希望它创造的生产力已经超过它消耗掉的生产力。

直到今年年初左右，我们看到的LLM生成内容里，垃圾内容肯定比有用代码多。即使到现在，它仍然会占用开发者很多资源。

因为你会收到一些bug报告。我不知道在座有多少人在自己的工作中见过这种模式。我敢打赌，或者说我知道这种情况不只发生在内核里：你会收到一个看起来完全合理的bug报告，但你可能要花相当多精力，最后才发现它其实只是幻觉。

当人类需要花很多时间去判断一个机器生成的报告是不是真的时，这会非常消耗资源。

但与此同时，过去几个月里确实发生了一个变化：我们开始收到很多非常好的bug报告。不过，大多数好的报告并不只是LLM自己生成的。它们需要一个人去检查AI生成的报告，确认它是有效的，并且在修复问题的开发者之间扮演中间人的角色。

我们也不得不反复提醒一些人：如果你用LLM找到了一个bug，并不意味着你只要让LLM写一份bug报告，然后把它扔给我们就够了。

我们希望看到一个建议性的补丁。我们也希望运行LLM的那个人能够参与往返沟通。我们需要有人可以讨论问题。

有些时候，补丁只是一个非常简单、显而易见的一行修改。但很多时候，问题会变成：我们过去没有考虑到这个问题，要真正修好它，需要重新组织一些代码，需要投入一些精力。

这时候，你就非常希望最初提交报告的那个人能参与进来。开发者可能会回来问：“这是我们建议的修复方案，你的LLM怎么看？”

对复杂系统要有敬畏之心

Dirk Hohndel：你刚才描述的其实指出了一个很多人容易忽略的区别。LLM现在非常擅长找bug。作为一种攻击工具，或者说作为一种发现问题的工具，它们已经强了很多。尤其是过去六个月，我们确实看到了一些明显进步。

但另一方面，如果是让它们生成Linux内核这个级别所要求的可靠代码，我仍然没有完全被说服。我一直觉得，LLM很擅长“从零到demo”。你可以很快做出一个演示。但“从零到生产级代码”，我不确定它一定会做得更快。

Linus Torvalds：是的。我个人会在自己的玩具项目里使用LLM，而且我确实很喜欢这一点。我把它们当作原型工具。

比如我会说：我想试试这个东西，但这只是我的玩具项目，如果完全自己写，成本太高，而且我还不确定它能不能行。于是我就让LLM帮我做。很多时候，生成出来的代码并不能直接使用，但它是一种很好的试验方式。我希望大多数人今天也是这样使用LLM的。

我同意，当我们看到AI生成的bug报告时，有时也会收到AI生成的补丁。在简单情况下，这些补丁完全没问题。

但很多时候，它们更像是没有思考的“创可贴式”补丁。它们没有修复底层问题。它们可能修掉了眼前的问题，但同类bug还在那里，只是在走廊里等着从另一个地方跳出来打你。

这类修复往往需要那些长期维护代码、真正理解代码的维护者和开发者来处理。以我的经验，LLM还没有达到这个层次。

当然，这未来可能会改变。也许有一天你可以告诉它：“请看大局，请真正把这个问题修好，请表现出一点好的工程品味。”但至少现在，大多数时候还缺少这种品味。

我认为，对LLM进行反复提示，确实常常能帮助它生成更好的质量。但至少在今天，它们还不能替代那种来自经验的架构级知识。

Dirk Hohndel：是的，你确实需要一个理解大局的架构师。出于个人好奇，在座大概有一半人看起来像软件工程师。你们当中有多少人每天都在使用LLM？

Linus Torvalds：显然，AI有很多很好的用例。我们刚刚谈到了它在bug方面带来的变化。有些被发现的问题不只是在当前代码里，有些甚至可以说非常惊人。当然，是以一种痛苦的方式惊人。

别误会，bug从来都不好玩。如果是安全相关的bug，而且两天后就出现在科技媒体上，那就更不好玩了。

但与此同时，我绝不是那种“射杀信使”的人。我认为，LLM能找到bug，对我们来说整体上是一件好事。即使这些bug让人尴尬，即使它们是我们可能20年前就应该发现的长期存在的严重bug，最终它们被发现仍然是好事。

当下可能会有点痛苦，但最终我们会因此变得更强。只是过去几个月确实有点痛苦，因为LLM指出了几个相关的bug。这并不奇怪：一个人发现一个bug后，另一个人就会去问LLM：“那这个相似区域呢？”

所以我们才会在几周内看到三四个关系非常紧密的bug变成大新闻。