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能修掉所有bugDirk Hohndel我们刚才谈到Linux在20年前切换到了现在这套开发模式其中一个重要原因就是Git的出现。Git现在仍然是你处理所有事情的主要工具吗你还会使用其他工具吗有没有你希望拥有但现在没有的工具Linus Torvalds对我个人来说Git和邮件基本上就是我真正使用的两个工具。当然我也会用Google来查东西。也许你们中有人是超人可以记住行业里所有三字母缩写但我不是。有人给我发解释他们可能工作在某个我不熟悉的角落然后使用那个领域里的各种缩写和简写。我会想这到底是什么这时候我就会用Google。所以从这个意义上说Google也是我使用的工具。但大部分时间我就是读邮件然后用Git做合并。这是我的主要工具。不过我也要指出我是一个比较特殊的例子。大多数其他维护者会使用更多工具。我认为很多人已经开始使用AI工具做patch检查。但因为我声称自己是在更高的层次上工作我面对的是人而不是工具。这也是为什么我一直强调最重要的是信任是信任那个人。我信任的是具体的人。几十年来都是这样。开发者会从一家公司跳到另一家公司我并不关心他们用什么邮箱也不关心他们在哪家公司工作因为我信任的是这个人相信他能做出判断。我认为很多项目都是这样运作的但在开源里尤其如此。在公司内部你可能因为某个人和你在同一家公司所以信任他但在开源里你信任一个人是因为你和这个人一起工作了很长时间。Dirk HohndelGit当然也是你启动的另一个重要项目。这个月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是的你确实需要一个理解大局的架构师。出于个人好奇在座大概有一半人看起来像软件工程师。你们当中有多少人每天都在使用LLMLinus Torvalds显然AI有很多很好的用例。我们刚刚谈到了它在bug方面带来的变化。有些被发现的问题不只是在当前代码里有些甚至可以说非常惊人。当然是以一种痛苦的方式惊人。别误会bug从来都不好玩。如果是安全相关的bug而且两天后就出现在科技媒体上那就更不好玩了。但与此同时我绝不是那种“射杀信使”的人。我认为LLM能找到bug对我们来说整体上是一件好事。即使这些bug让人尴尬即使它们是我们可能20年前就应该发现的长期存在的严重bug最终它们被发现仍然是好事。当下可能会有点痛苦但最终我们会因此变得更强。只是过去几个月确实有点痛苦因为LLM指出了几个相关的bug。这并不奇怪一个人发现一个bug后另一个人就会去问LLM“那这个相似区域呢”所以我们才会在几周内看到三四个关系非常紧密的bug变成大新闻。
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能修掉所有bugDirk Hohndel我们刚才谈到Linux在20年前切换到了现在这套开发模式其中一个重要原因就是Git的出现。Git现在仍然是你处理所有事情的主要工具吗你还会使用其他工具吗有没有你希望拥有但现在没有的工具Linus Torvalds对我个人来说Git和邮件基本上就是我真正使用的两个工具。当然我也会用Google来查东西。也许你们中有人是超人可以记住行业里所有三字母缩写但我不是。有人给我发解释他们可能工作在某个我不熟悉的角落然后使用那个领域里的各种缩写和简写。我会想这到底是什么这时候我就会用Google。所以从这个意义上说Google也是我使用的工具。但大部分时间我就是读邮件然后用Git做合并。这是我的主要工具。不过我也要指出我是一个比较特殊的例子。大多数其他维护者会使用更多工具。我认为很多人已经开始使用AI工具做patch检查。但因为我声称自己是在更高的层次上工作我面对的是人而不是工具。这也是为什么我一直强调最重要的是信任是信任那个人。我信任的是具体的人。几十年来都是这样。开发者会从一家公司跳到另一家公司我并不关心他们用什么邮箱也不关心他们在哪家公司工作因为我信任的是这个人相信他能做出判断。我认为很多项目都是这样运作的但在开源里尤其如此。在公司内部你可能因为某个人和你在同一家公司所以信任他但在开源里你信任一个人是因为你和这个人一起工作了很长时间。Dirk HohndelGit当然也是你启动的另一个重要项目。这个月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是的你确实需要一个理解大局的架构师。出于个人好奇在座大概有一半人看起来像软件工程师。你们当中有多少人每天都在使用LLMLinus Torvalds显然AI有很多很好的用例。我们刚刚谈到了它在bug方面带来的变化。有些被发现的问题不只是在当前代码里有些甚至可以说非常惊人。当然是以一种痛苦的方式惊人。别误会bug从来都不好玩。如果是安全相关的bug而且两天后就出现在科技媒体上那就更不好玩了。但与此同时我绝不是那种“射杀信使”的人。我认为LLM能找到bug对我们来说整体上是一件好事。即使这些bug让人尴尬即使它们是我们可能20年前就应该发现的长期存在的严重bug最终它们被发现仍然是好事。当下可能会有点痛苦但最终我们会因此变得更强。只是过去几个月确实有点痛苦因为LLM指出了几个相关的bug。这并不奇怪一个人发现一个bug后另一个人就会去问LLM“那这个相似区域呢”所以我们才会在几周内看到三四个关系非常紧密的bug变成大新闻。
)
