核心内容摘要
Java后端写了10年，我才真正理解这8个设计原则
整理 | 屠敏出品 | CSDNIDCSDNnews今年年初Linux 内核的代码行数突破了 4000 万行。
而作为这个庞大项目的掌舵者Linus Torvalds 对外宣称自己“已经不再是程序员”、“不再编程”了那么他在整个项目中到底负责什么又是如何把控、维护这个项目的他会用 AI 来做内核工作吗近日Linus Torvalds 出席了 Linux 基金会在日本举办的开源峰会与 Verizon 开源项目办公室负责人 Dirk Hohndel 展开了第 29 次对谈https://www.youtube.com/watch?vyEzdHYjY_RU。
其二人聊到了 Linux 内核维护的高密度节奏、合并窗口期的挑战以及 AI 在代码中可能扮演的角色。
Linus 表示在 Linux 内核的世界里没有捷径可走他们每 9 周发布一个版本一个合并窗口期里自己通常要处理大约 12,000 次提交算上合并后的提交大约在 11,000 到 13,000 次之间。
其中他会花两周时间用来合并代码接下来的七周则用于查找并修复 bug。
值得关注的是Linux 内核维护中有条铁律no regressions——不允许功能倒退、不允许引入回退性问题也不能破坏向后兼容性。
Linus 称真正让自己完全不能接受的行为是是有人不愿意承认是自己引入了 bug。
至于 AILinus 也直言自己的态度“我其实很讨厌‘AI’这个词不是因为讨厌技术本身而是因为它被炒得太厉害好像现在所有事情都非 AI 不可。
”他指出「AI 和当年编译器的出现本质上是一样的。
别觉得 AI 会突然彻底改变编程这件事我们早就经历过了——几十年前写编译器的那些人已经完成过一次革命。
」以下是这场对话的完整内容最新的 Linux 版本还是一如既往的“枯燥”Dirk Hohndel早上好我是 Dirk Hohndel在 Verizon 负责开源业务Verizon 是美国最大的移动运营商。
Linus Torvalds我是 Linus Torvalds。
我们已经这样对谈过很多次了。
我不喜欢做演讲也不做 Keynote。
对我来说更愿意和 Dirk 进行这种对我来说“毫无准备”的问答环节而且我们已经这样聊了很多年了。
Dirk Hohndel没错这是我们的第 29 次对谈。
那Linus你的职业版图是不是又扩展了听说你现在成了 YouTube 明星了Linus Torvalds不不不。
我确实在几周前录了一个 YouTube 视频大概是上周发布的。
但说实话这也确实是我在 Linux 事业中乐在其中的一点——我可以去做一些平时通常不会做的奇怪事情。
我拍了这个 YouTube 视频我觉得对我来说这已经足够了。
Dirk Hohndel总之看到你在一种完全不同的对话场景中出现真的很有趣。
但现在我们还是回到我们更常规的交流方式上。
Linux Kernel
18 上周发布了你能给我们介绍一些亮点吗有什么值得关注的内容Linus Torvalds对我来说亮点就是它“一如既往还是老样子”。
我喜欢“枯燥”、平淡无奇。
当你开发的内核被所有人依赖时——无论是手机还是超级计算机——你真的不希望有太多的意外和刺激。
我已经做了 35 年了我觉得核心词应该是“稳步推进”。
我们最近做了相当多的清理工作。
当然其中很大一部分依然是对新硬件的支持这是不断更迭的部分。
内核的工作大约有一半实际上就是硬件驱动程序。
Dirk Hohndel我觉得关于
18 很重要的一点是它是下一个 LTS长期支持版本。
它做了大量的清理、许多细小的改进而不是巨大的、颠覆性的生态系统变动这也是项目目标的一部分。
这是设计的有意为之还是仅仅是巧合Linus Torvalds这是设计使然虽然这种“设计”也是多年来逐渐演变而成的。
我相信 GregGreg Kroah-Hartman现在就在观众席的某个地方他负责维护长期支持版本并接手特定版本进行多年的维护这样无论是大公司、小公司还是个人都能有一个可以长期依赖的标准版本。
Dirk HohndelLinux 过去通常不会预先宣布哪个版本将是下一个 LTS 版本但这在几年前改变了现在一般是每年的最后一个版本。
Linus Torvalds我不认为这是官方提前公布的事情但大家大概能猜到会发生什么。
我们有计划但它也是灵活的。
Dirk Hohndel过去我们不预先宣布的原因是为了避免那种“为了赶上版本而匆忙合入代码”的情况吗Linus Torvalds我们曾经遇到过这样的问题当人们知道某个版本将成为下一个 LTS 时就会拼命想把功能塞进去。
这会导致问题因为原本应该是最稳定的内核有时反而因为人们急于合入新代码而变得不稳定。
但我觉得大家现在已经非常习惯我们的工作方式了。
即便你知道预期是什么那种“冲刺感”也没那么强了因为大家已经见证这种机制运行了这么久。
他们知道如果错过了一个 LTS 版本下一个总会到来。
而且大多数依赖 LTS 的公司也知道一年的时间其实很短。
9 周一个发布周期大约会收到 12,000 次提交Dirk Hohndel就像你说的这个流程已经持续了很久大约 20 年了。
现在你正处于下一个内核的合并窗口期大约完成了三分之二。
我今天真的很想聊聊这个请带我们了解一下这个过程对你来说“合并窗口期”意味着什么Linus Torvalds合并窗口期间是我非常忙碌的一段时期。
我会接收维护者们认为已经为下一个内核准备就绪的所有新代码并没有一个硬性的“功能规则”来规定下一个内核必须包含什么。
它本质上是关于“这些代码现在准备好了”所以当合并窗口开启时我们就可以进行整合。
事实证明这对我这个维护者以及开发者来说压力都小得多。
因为没有一个绝对的截止日期说“你的代码必须在某月某日准备好”。
它更像是“代码什么时候准备好了它就会被合并”。
既然我们大约每两个月确切地说是 9 周发布一个版本如果有人错过了一个版本他也知道再过 9 周下一个发布周期就会开始。
这真的减轻了开发过程中的很多压力。
不过对我个人而言那两周确实很忙。
我需要合并所有新代码。
如果其中一周正好赶上出差而且明天还要参加内核维护者峰会这意味着上周我在赶飞机前尝试完成所有工作压力确实比平时大一点。
Dirk Hohndel但你刚才略过了我真正想了解的部分。
那你具体是做什么的Linus Torvalds我现在已经不写代码了如果你是想问这个的话。
实际上我做的事情是把别人开发的、由别人维护的代码整理起来然后当这些子维护者觉得某个代码模块准备好了就会发给我一个 pull request。
我来合并它。
一个合并窗口我通常会收到大约 12,000 次提交。
如果算上合并后的提交大约在 11,000 到 13,000 次之间。
它们是通过几百个 pull request 发给我的。
所以在第一个星期我几乎一直在合并代码这不只是朝九晚五是从早到晚整整一周都在做。
第二周我会放慢节奏处理一些滞后的提交有些是因为我需要仔细检查有些只是提交晚了。
总之两周时间处理所有新功能然后我就停止接收新功能。
在之后的 7 周时间里我们会尝试找出所有的 Bug尝试修复所有的 Bug并让内核处于尽可能好的状态。
我们做这个流程已经很久了也越来越熟练。
在那个阶段我会发布每周的候选版本Release Candidates直到发布最终版本。
对于 LTS 版本和所有版本之后都会有一段时间的稳定维护期。
“在合并窗口的前一天收到 PR会惹毛我却也总有人想试试”Dirk Hohndel我觉得很有意思的是要让你真正讲你在做的有趣的事情可不容易。
因为凡是合并过不同 pull request 的人都知道这从来不是“点一下就好了”。
你要在两周内合并 12,000 个提交、几百个 pull request不可避免会遇到冲突和各种挑战。
Linus Torvalds我合并这么多次了现在几乎可以闭着眼睛合并了。
很多人应该也都了解当两个人修改了同一片代码区域出现冲突时会发生什么。
我几乎每天都在处理这种情况对这种合并已经很熟练了以至于我让子维护者不要帮我提前合并。
即便他们比我更了解自己的模块我合并的经验也比绝大多数人都丰富所以我更喜欢自己来合并。
原因有两点一是我能清楚知道哪些地方发生过冲突这对我很重要我想知道不同团队在同一区域的交互情况二是如果冲突比较复杂我有时会让子维护者先在测试目录里做预合并然后我再比对我的结果。
这样我有时候会发现自己合并的问题但更常见的是发现他们的预合并有问题。
所以这就是我做的事情。
我很久没真正写代码了我会给别人发代码片段说“嘿可以这样改”。
但我真正做的是保持对整个项目的高层次理解合并不同团队的代码知道大局发生了什么也能判断什么时候两组代码冲突。
你想想Linux 内核里面有 4000 万行代码和文档、几百个维护者、每次发布都有几千个开发者参与每九周一次这就足够我跟进了。
我不会纠结小细节那交给我信任的开发者和子维护者去做。
我关注的是维护、流程确保发布计划合理、内核运作正常。
这就是我的工作。
Dirk Hohndel这很有趣因为我接下来的问题正是你多久会看一次这些代码即进行代码审查多久会遇到合并冲突然后说“嗯这里不对”Linus Torvalds当冲突发生时我不仅想知道冲突本身还要理解代码这样我才能确保冲突修复是正确的。
现在我看得最多的就是冲突代码。
有时候我看完代码就会说“哦这里写错了。
”这种情况几乎每个合并窗口都会发生。
就几天前我合并一个提交时出现冲突我看了冲突的代码发现问题出在有人提交的代码上有明显错误然后我就从 tree 上撤回那段代码并要求发送代码的人给出解释。
所以这就是我现在仍然涉及的编程部分——我会看代码、会修改代码但我是以维护者的身份而不是开发者身份去做。
Dirk Hohndel我想在场有不少人都做过 Git 合并。
哪怕只是偶尔做一次但想到要在两周内处理几百个 merge都会觉得压力很大。
那在你做了这么多年、流程也这么成熟、大家也都很有经验的情况下有没有什么“雷点”哪些事情最容易把你惹毛Linus Torvalds有那么几个。
一个是时间点。
我偶尔会收到别人在星期六发来的拉取请求也就是我正准备结束合并窗口的前一天。
我心里就会想“不是说好代码应该在合并窗口前就准备好的吗现在我正准备收尾、让节奏慢下来、准备第一个 RC你却在这时候发过来。
”有时候我会直接说“不行等下一个版本吧再等九周。
因为你太晚了你本该更清楚。
”其实大家都知道这个道理但有时候还是会有人这样试一试。
我觉得大概就是这么回事。
另外一件让我比较恼火的事是——我不只是合并代码我每天都会运行自己的内核。
我不会每合并一次就重启但我会在自己所有机器上用最新的内核。
也就是说每一个版本我都会自己用一遍而几乎每次发布我都会发现 bug。
这本不该发生。
我做的事情并不奇怪我的机器也很普通。
如果我都能遇到 bug那说明有人在提交前根本没有好好测试。
如果问题严重到我是第一个发现的人我确实会有点不爽有时也会给维护者发邮件直接说“你这次没把工作做好。
”Dirk Hohndel语气会很客气吗Linus Torvalds不一定。
我通常还是尽量保持礼貌的但有些人我已经合作了几十年当我觉得他们明明应该更清楚的时候语气确实会变得有点冲。
真正让我完全不能接受的是有人不愿意承认自己引入了 bug。
出 bug 本身没问题这是不可避免的。
我们并不完美再小心也会犯错这很正常我不会为这个生气。
但当别人指出 bug 时你应该站出来说“抱歉那是我的错我会修复它。
”可有时候我收到的回应是“我修了另一个 bug。
”这就不行了。
这不是“前进一步、后退两步”的问题。
你不能拿“我修了一个 bug但又引入了另一个”当借口。
这只会让系统变得不可信。
说实话我宁愿有一个大家都知道、可以绕开的老 bug也不愿意 bug 到处跑、让人完全没法应对。
所以内核里一直有一个非常严格的原则不允许产生回归no regressions。
这并不意味着回归不会发生而是说一旦发生我们就要认真对待而不是说一句“是回归不过……”就算了。
所以确实有几件事特别容易触发我的情绪。
我也一直在努力让自己更克制一点让自己变得有礼貌。
如果我曾经伤到过在座某些人的感情我在这里道歉。
我也会有压力大家都会有。
归根结底我们都是人犯错是难免的而我们建立这些流程就是为了尽量把错误的影响降到最低。
“我很讨厌‘AI’一词但我非常相信 AI 作为工具的价值”Dirk Hohndel你刚才也提到你做这件事做了这么久已经非常熟练了。
但我在想有没有什么工具能让这件事更轻松毕竟现在是 AI 的时代大家都在谈 AI……Linus Torvalds好一个转折笑。
Dirk Hohndel我觉得这并不突兀。
其实正好呼应了你刚才讲的那些内容代码合并、冲突处理、bug 处理。
有没有可能用一些工具甚至是 LLM 这样的现代 AI 系统来减轻你的工作负担Linus Torvalds当然可以。
我们本来就是一个高度依赖工具的开发环境用来检查代码的工具非常多。
明天我们要参加年度维护者峰会其中一个重要话题就是在使用 AI 工具这件事上我们该如何扩展现有工具链和相关规则。
我其实很讨厌“AI”这个词不是因为我讨厌 AI 技术本身而是因为它被炒得太厉害了好像现在所有事情都非 AI 不可。
但话说回来我非常相信 AI 作为工具的价值。
我们已经有一些项目在用 AI 做代码审查。
就我个人来说因为我是维护者代码审查对我非常重要所以我对“用 AI 写代码”反而没那么感兴趣。
很多人一谈编程就想到用 AI 写代码但在我看来这远没有“用 AI 来帮助维护代码”有意思。
这是完全不同的方向而且我们已经有好几个相关项目在推进了。
我不确定哪些已经公开讨论过其中不少是在公司内部把 AI 作为现有工具链之上的一层用来检查补丁、避免发布有问题的代码。
理想情况下它们甚至能在代码到我这里之前就把问题拦下来那我的工作流也会轻松很多。
这件事其实已经讨论了很久现在我也开始看到一些 AI 代码审查的实际案例其中有些非常有前景。
所以我对这件事很有信心希望明年它能成为我们工作流程中一个相当重要的组成部分。
Dirk Hohndel出于保密原因我就不点名了不过现在确实有一个工具正在开发中。
你最近刚好用分析了一个有 Bug 的改动。
那个 AI 工具在识别和解释问题方面表现得非常出色。
Linus Torvalds对那次其实不是我亲自用的而是在某家公司内部完成的我只是看到了最终结果。
当时我就想“对这个工具我想要。
”那确实是个很好的例子而且事情就发生在这一次合并窗口里——我对那个改动本身就有意见而那个 AI 工具不仅找出了我提出的那些问题还额外发现了一些。
这一直是个非常好的信号当一个工具连专家没注意到的东西都能发现那就说明它真的有价值。
所以这一点毫无疑问——炒作确实很多甚至有点过头但技术本身也确实很有意思。
当然现在所有 AI 公司基本都在用 LinuxLinux 也是大多数 AI 工作负载的基础。
但反过来用 AI 来帮助 Linux 内核开发这件事我们其实还做得不多不过这一点肯定会到来。
AI 如同当年的编译器别觉得 AI 会突然彻底改变编程Dirk Hohndel我很喜欢你刚才说的一个观点真正的突破点在“审查”和“解释”上。
不过我注意到每次合并窗口回顾时贡献者数量和新贡献者数量都非常高。
我在想LLM 这种 AI 工具能在多大程度上帮助新人入门毕竟内核有 4000 万行代码流程复杂、工具繁多想真正开始参与内核开发之前要学的东西实在太多了。
那在流程的另一端、也就是最开始的阶段你觉得这些工具能不能降低门槛让更多人更容易参与进来Linus Torvalds:我觉得是可以的。
不过先说一句内核里已经有很多开发者了而且说实话内核并不一定是你入门编程的最佳起点。
内核是个很特殊的领域。
当然我也认为内核是编程世界里最有意思的地方之一所以我很推荐大家去了解、去尝试。
但如果你刚开始学编程也许可以先从规模更小、复杂度没那么高的项目入手。
总体来说我把 AI 看作是任何人都可以使用的工具。
它确实新鲜、也很有吸引力但同时它又并不陌生。
它和当年编译器的出现本质上是一样的。
你得意识到我刚入行的时候编译器其实很糟糕而今天编译器能做的事情简直像魔法。
现在的编译器让程序员不用了解那么多底层细节就能完成工作这本身就是一次巨大的飞跃。
有人总爱说 AI 能带来“10 倍效率提升”但编译器带来的是上千倍的提升。
所以 AI 并没有那么“特别”。
别觉得 AI 会突然彻底改变编程这件事我们早就经历过了——几十年前写编译器的那些人已经完成过一次革命。
如果 AI 在此基础上再带来 10 倍、甚至 100 倍的提升那当然很好它会让我们能做出更多、更好、更有意思的项目。
但归根结底它依然只是个工具。
这就是我的看法。
当然如果 10 年后机器人统治世界、把我们都干掉了那我就承认我说错了。
Dirk HohndelAI 工具和编译器之间的区别是AI 工具在犯错时要有礼貌得多。
当它弄错时例如 Claude 会说“哦是的你说的对我弄错了很抱歉”。
从来没有编译器对我这么说过。
Linus Torvalds我听说有人专门用内核相关的数据训练了一个 AI不只是代码还包括内核邮件列表的内容。
结果他们后来发现得教这个 AI 少说脏话因为它学到的表达方式并不总是那么有礼貌。
这听起来也许只是个玩笑。
但我真正喜欢 AI 的地方在于你不需要向它解释所有底层细节。
相比之下当你试图向编译器说明你的意图时往往必须在非常底层的层面把事情说清楚这个过程既繁琐又费力。
AI 的优势在于它提供了一个额外的抽象层。
你可以用更高层次的语言去表达你的想法而不只是告诉系统每一步该怎么做。
这一点让人类完成事情变得更容易也更高效。
所以我对 AI 抱有很大的期待。
Linux 铁律拒绝出现回归Dirk Hohndel我这里还有 12 个关于 AI 方面的问题但为了能“活着”离开这间屋子我还是换个话题吧。
你刚才提到了我们有这样一条规则在内核中不允许回归no regressions也不能破坏向后兼容性。
有意思的是真正能长期坚持这项原则的项目并不多。
在来这里的路上我们还聊到Python
14 的一次更新导致你正在使用的一个业余项目工具失效了。
那么为什么做到“不破坏现有功能”这么难Linus Torvalds从技术角度看这件事确实很难。
并不是所有的内核开发者都喜欢我这条“不许产生回归”的规则要长期坚持这一规则确实很辛苦。
问题在于所谓的“回归”往往不是马上就能发现的。
比如某个行为在两年前改变了但当时大家都在运行旧的 LTS 内核并没有察觉异常。
等到两年后他们升级到新内核才发现某个细节和以前不一样了而这个差异恰好破坏了他们的特定应用。
更麻烦的是两年的时间已经过去其他应用程序可能已经开始依赖这种“新的行为”。
这时我们就会陷入一个非常棘手的局面如果去修复当初的回归就会影响那些已经适配了新行为的程序等于制造新的回归。
所以这件事远没有听起来那么简单。
嘴上说一句「不许产生回归」很容易真正坚持下去却极其困难。
为了守住这个原则我们不得不做出一些非常极端的选择。
比如在内核中对不同的程序表现出不同的行为——因为我们很清楚某些程序期待的是旧的行为而另一些程序已经建立在新的行为之上。
站在软件工程师的角度你其实并不想这样做这种方案本身是“丑陋”的。
还有一个现实问题是很多人尤其是在开源社区里之所以投入时间做这些事情本身就是因为热爱编程。
而对开发者来说“有趣”的事情往往是做一些和过去不一样的、带有创新性的改动你引入了新的行为从旧的模型中学到了很多也可能觉得旧的设计本身就是错的于是想把它修掉。
这种冲动完全可以理解。
但如果你开发的是一个被他人依赖的库或者是一个被库依赖、进而被无数人依赖的内核你就不只是在修复你自己的 Bug你是在破坏所有依赖你项目的程序。
开发者或许会很容易说一句“我已经把问题修好了你去重新编译你的应用吧。
”但现实是很多应用依赖的可能是一个 30 年前写成、如今早已无人维护的库。
当底层基础设施悄然改变了行为修复这类问题往往几乎不可能。
这就是为什么内核一直坚持这个原则我们不做那种“改进”。
如果我们要做新东西我们会使用新的接口而让旧接口保持在可工作的状态。
极少有其他开源项目或闭源项目有这种做法。
我希望更多项目能这样做但我还不是“世界之王”所以我管不了别人我只能给内核定规矩。
来源https://www.youtube.com/watch?vyEzdHYjY_RU