Linus Torvalds & Dirk Hohndel：Linux、Rust 与维护者
本页标题、字幕、摘要和阅读笔记为已保存的 AI 译文，可能有误。时间戳与来源一致，可展开查看原始字幕，并对照原视频核对。
Linus Torvalds 与 Dirk Hohndel 谈 Linux 6.7 版本发布、内核中的 Rust、老龄化的维护者以及新维护者从何而来，还有编程中的 LLM。
转录来源：Vidleaf 上的自动语音识别（可能包含错误）。AI 标点由 Vidleaf 添加；阅读文本已应用经审核的姓名更正；时间戳锚点保留。原始转录可在下方查看。
AI生成的摘要
Linus Torvalds 与 Dirk Hohndel 讨论 Linux 内核以及维护它的人们。对话从 Linux 6.7 版本发布和 Rust 的逐步引入开始，随后谈及维护者疲劳、继任问题以及硬件厂商与社区之间不断变化的关系。Torvalds 权衡了语言模型在代码审查中的可能用途与人们发现错误的需要。后面的讨论将开放协作与中立组织归属的价值联系起来。这些是在录制活动中表达的观点，包括 Torvalds 偏好渐进式工程而非宏大的长期预测。
要点
- [5:41] Rust 的引入被作为内核开发中的一个渐进过程来讨论。
- [15:21] 维护者继任和欢迎新贡献者仍然是该项目面临的人性挑战。
- [20:50] Torvalds 考虑在编程和审查中引入 AI 辅助，同时保留人类判断的必要性。
根据转录稿生成。请对照原始视频核对所链接的段落。由 Vidleaf 于 2026-10-20 审阅。摘要和要点由 Vidleaf 于 2026-10-21 审阅。
完整概述
本次讨论形式的会议由 Linus Torvalds 与 Verizon 的 Dirk Hohndel 对话，涵盖 Linux 6.7 版本发布以及更广泛的内核社区话题。Linux 6.7 RC4 已在几天前发布，计划推出一个圣诞/新年前夜内核，而 6.8 的合并窗口可能会推迟一两周；6.7 被描述为一个无聊的版本，这是好事，并且按提交数量计算可能是史上最大的版本，部分原因是有一个开发了大约十年的新文件系统。Torvalds 表示 Rust 的引入一直平稳而安静，目前还没有任何内核部分依赖它，不过一些甚至主要的子系统明年将开始积极使用它，而 Rust 成为内核重要组成部分还需要数年时间；他称自己是一位管理代码而非人员的技术负责人。商业环境和硬件支持在 20 年间有了极大改善，公司现在为自己的硬件编写驱动程序，尽管文档仍然很难找到。维护者疲劳仍然是一个未解决的反复出现的话题，维护者需要良好的品味和持续的可供性，而维护者树的顶层正在显著老龄化，许多维护者将在五年内接近 60 岁。关于 AI，Torvalds 预计 LLM 编写的代码将作为拉取请求提交，希望 LLM 能帮助审查代码并发现明显的愚蠢错误，并担心幻觉和没有人类发现问题时的自动化，同时并不认为 AI 像每日新闻所暗示的那样具有革命性。他也拒绝参与开放数据讨论，宁愿放下不属于他这一边的领域。演讲者被描述为一位高调的 Linux 基金会员工，将自己局限于内核，他反思了开放如何被广泛接受：曾经关于你为什么以及如何赚钱的问题不再出现，开放数据被讨论而没有人问为什么，开放在一定程度上已成为行业标准。他指出，人们理所当然地认为，公司之间共享大型编程或数据项目的最简单方式是将其开放，并采用允许广泛共享的许可证。他说 Linux 基金会做开放数据很棒，但这不是他做的事，并且一个人们可以聚集在一起的中立场所很重要；他在 Linux 基金会工作是因为他拒绝在 Linux 公司工作，也不想让某个商业实体成为那个特殊的地方。关于方向，他说开放已从开放代码转向开放数据，问题是下一步走向哪里，他称自己是一个缓慢前行的工程师，看着眼前的下一步，而不是做出宏大的 10 年宣言。他不认为长期规划在技术中很有效，尽管你需要对想去哪里有个想法，而且仍然是一次一步。主持人随后询问明年开源峰会回到日本时应该在哪里举办，建议冲绳；嘉宾说他喜欢东京，一直和妻子四处走走逛逛商场，冲绳对他来说听起来也不错，随后主持人感谢大家并结束。
带时间戳的章节摘要
Linus Torvalds 谈 Linux 6.7 版本发布时间
- [0:05] Dirk Hohndel 是 Verizon 开源项目办公室的负责人。
- [0:13] Linus Torvalds 被介绍为 Linux 和 Git 的创造者。
- [1:00] 这显然是他们第 23 次采用这种形式。
- [1:07] Linus 不喜欢公开演讲，所以他们采用讨论形式，问题是他事先不知道的。
- [2:04] Linux 6.7 RC4 已在几天前发布，并且将有一个圣诞/新年前夜内核。
- [2:31] Linus 的目标是大约每 10 周发布一次。
- [2:54] 今年圣诞节恰逢发布的平静期，这对 Linus 来说很合适。
- [3:19] 为 6.8 做准备的维护者会有些恐慌，因为合并窗口在圣诞节后开启。
- [3:39] 合并窗口可能会推迟一两周。
Linux 6.7 版本发布讨论
内核中的 Rust 与维护者角色
- [5:41] Rust 被引入内核，过程相对平稳和安静。
- [5:55] 最初的 Rust 基础设施去年被合并，并且正在增长，但内核还没有任何部分真正依赖 Rust。
- [6:09] Rust 在技术上说得通，但对他更重要的是，作为内核和开发者，不能停滞不前。
- [6:25] 他从事内核工作已有 32 年，它一直保持有趣，因为它不是单一不变的东西。
- [7:08] Rust 尚未真正展现出作为下一个伟大事物的样子，但明年一些甚至主要的子系统将开始积极使用它。
- [7:24] Rust 成为内核重要组成部分还需要数年时间。
- [7:34] 他一直在读一些 Rust 代码，以便判断哪些太糟糕而不能包含，但他自己不写 Rust 代码。
- [7:56] 内核依赖成千上万的人；每个版本中约有一半的人只发送一个补丁，其中很多人再也不会出现。
- [8:46] 他不会成为管理 Rust 代码的人，因为那不是他的专长。
- [8:57] 他称自己为技术负责人而非管理者：他管理代码，而不是人，他的日常工作不是编程。
商业环境和硬件支持得到改善
维护者疲劳与开源的人性面
- [11:08] 维护者疲劳以及这个角色多么令人疲惫，多年来一直是内核峰会的反复主题。
- [11:38] 很难找到维护者，找到开发者要容易得多，而且每个版本都会被提及。
- [11:55] 维护者不需要是能包办一切的超級开发者；那实际上不是真的。
- [12:01] 维护者需要良好的品味来判断他人的代码，其中一些可能是天生的，但很多需要多年练习。
- [12:39] 维护者必须一直在线，或者找其他维护者在假期周围安排。
- [13:23] 目前还没有解决方案；维护者团体形成了不同的解决方案，一个问题是人很难，代码很容易。
- [13:49] 与目标不同、将各自领域推向不同方向的维护者合作可能会非常有压力。
- [14:15] 开源并不全是编程；很多是关于沟通的，而且不需要是同一个人。
- [14:38] 维护者可能需要将开发者的输出翻译到项目中，意思是上下文和代码的原因，不一定是语言。
内核维护者老龄化与继任
软件开发中的人工智能与大型语言模型
Linus 谈人工智能在编码和代码审查中的应用
- [19:42] 人工智能可能已经在较小规模上作为编写代码的辅助使用。
- [19:59] 自动化一直帮助人们编写代码，所以这不是什么新鲜事。
- [20:12] 他不认为人工智能像每日新闻所说的那样具有革命性。
- [20:50] 他希望 LLM 能帮助审查代码和维护子系统，特别是发现明显的愚蠢错误。
- [21:33] 编译器已经警告真正明显的错误，但 LLM 可以通过标记看起来不规则的模式来警告稍微更微妙的情况。
- [22:01] 他认为 LLM 远不止是“打了鸡血的自动更正”，可以帮助我们更好地完成工作。
- [23:13] 他担心大语言模型会产生幻觉、编造内容，而且当它们在没有人类在场捕捉错误的情况下自动执行更多操作时，情况会变得可怕。
- [23:37] 令人担忧的不是科幻式的世界统治，而是那些会影响我们生活或代码的众多缺陷。
- [23:49] 他没那么担心，因为即使没有大语言模型，缺陷也每天都在发生，而我们自己处理得挺好。
Linux 基金会中的开放与开放数据
- [24:16] 30 年前，开源给人的感觉是代码掌控着未来，价值数十亿美元的代码是决定性因素。
- [24:38] 如今，似乎远不止代码，而是数据在掌控我们的世界，指的是谷歌、亚马逊和苹果对我们的了解。
- [24:57] 他不参与开放数据的讨论，更愿意放下不属于自己这边的事情，就像他在内核中所做的那样。
- [25:37] 他是 Linux 基金会中较为高调的员工之一，但只专注于内核。
- [26:02] 他很高兴开放已被更广泛地接受，回忆起 30 年前人们会问为什么以及如何赚钱，这些问题如今再也不会出现。
- [26:29] 开放数据正在被讨论而没有人问为什么，这才是关键，开放在一定程度上已成为行业标准。
- [26:43] 人们理所当然地认为，当编程或数据领域的大型项目需要在公司之间共享时，最简单的方法就是将其开放，并采用允许广泛共享的许可证。
- [27:16] Linux 基金会做开放数据很棒，但这并不意味着那是他做的事情。
- [27:37] 一个人们可以聚集在一起的中立场所很重要，他在 Linux 基金会工作是因为他拒绝在 Linux 公司工作，也不想让某个商业实体成为那个特殊的地方。
渐进式步骤胜过长期计划
- [28:23] 开放的方向已经从开放代码转向开放数据，问题是下一步会走向哪里。
- [28:38] 演讲者称自己是一个踏实的工程师，着眼于眼前的步骤，而不是做出宏大的 10 年宣言。
- [28:46] 他引用了一封电子邮件，其中某人将一个有趣的小项目描述为只是一个小爱好，他说这证明了他多么不擅长预测。
- [29:15] 他认为制定长期计划行不通，并指出五年规划在政治中效果并不太好。
- [29:25] 他说长期规划在技术领域其实不太行得通，尽管你需要对想去的地方有个想法。
- [29:35] 如果你不看清眼前，你就会四处摸索，永远无法到达山顶。
- [29:45] 你可能心中有一趟宏大的旅程，但仍然要一步一步来，尤其是在技术领域，你无法通过一次大跃进改变世界。
开源峰会日本 2025 场地建议
姓名更正由Vidleaf审核
已审核2026-10-20。原始字幕仍可在下方查看。
[0:00] 现在我很高兴介绍我们下一位对话演讲者。请欢迎——请欢迎上台，Dirk Hohndel，Verizon 开源项目办公室负责人，以及 Linux 和 Git 的创造者 Linus Torvalds。请欢迎。再见。
[0:31] 谢谢。早上好。看到所有这些手机指向我们真是太有趣了。我想拿出我的手机给你们所有人拍张照，但我把手机落在那边了。我是 Dirk Hohndel，我在 Verizon 负责开源，引用 Jim Zemlin 的话，这就是那个“另一个人”。是的。是的，我就是另一个人，我以前做过这个，我们做过这个。Dirk 说这显然是我们第 23 次做了。
[1:04] 我们这样做的原因是我并不喜欢公开演讲。我相信很多人理解这不是世界上最有意思的事情，所以我们想出了这种形式，Dirk 准备了我事先不知道的问题，我们更多是在你们面前进行讨论，这让我舒服多了，希望对你们也有效。是的，通常效果不错。偶尔他会抛出让我措手不及的曲线球，让我想，我现在该怎么办？所以看看这次是哪个。我很高兴回到日本。已经几年了。
[1:43] 遗憾的是。昨晚我们做了传统的寿司 OD，总是很高兴来到这里。非常感谢你们邀请我们。时间变了。过去日本的会议像是在六月。所以在这里过圣诞节前其实挺有趣的。所以我——相当开心。——而且我们天气也很幸运。——是的，天气一直很好。所以 Linus，你几天前发布了 Linux 6.7 RC4。
[2:16] 其中有趣的事情之一是我们将有一个圣诞新年内核。做得好。时机正好。嗯，我的意思是，我们每……两个半月发布一次，我想 10 周基本上是我努力的目标。所以每次圣诞节来临都会这样，而合并窗口，也就是我忙碌的时间，正好在圣诞节前后，这真的毁了我的圣诞节。或者我们有安静期。
[2:54] 当我们只是在努力寻找并修复最后几个缺陷时。而今年，令我高兴的是，对我来说，圣诞节就是发布前最后几周进行时的安静时期，我们只是在等待，确保没有什么大的、会导致停摆的问题发生。这对我来说非常有效，但这意味着所有……一些现在正在为下一个版本做准备的维护者和开发者，6.8，他们会——他们会有点恐慌，因为他们知道圣诞节后我的合并窗口就会打开，而那时他们应该已经为下一个版本准备好所有东西了。
[3:39] 所以我们可能会把那个推迟一两周，因为我们每年都这样做，以便让时间安排更合适，因为没有人想在圣诞节期间工作。是的，但是那么随着6.7，有什么令人兴奋的？有什么特别引起你注意的吗。嗯……实际上，在过去几乎20——不，不是20年，而是15年多的时间里，我们一直有一个非常规律的发布计划。我很高兴地说，6.7 结果是那些无聊的版本之一。无聊是好事。- 无聊是好事。- 你不想要太多刺激，因为刺激通常意味着大缺陷。
[4:23] 6.7 是—— - 带G的缺陷，不是带CK的。- 是的。是的。谢谢。太可怕了。但6.7实际上有点不寻常。我认为，如果只计算提交数量，这可能是我们有过的最大的版本。而且，呃，原因实际上是我们有一个新的文件系统，它已经酝酿了大约十年。
[4:56] 有很多新的提交涌入。但看到我们不仅保持稳定，而且实际上还在提高开发速度，仍然很有趣。内核大小往往在增长，这是一个好迹象，但显然也意味着有更多工作在进行，维护者有更多工作要处理。是的，除了Linus不喜欢我的笑话之外，我想向同声传译员道歉，因为我完全不知道你们会如何把这个翻译成日语。
[5:36] 所以在过去几个内核版本中，我们谈论很多的事情之一就是将Rust引入内核。我认为它一直——相对稳定和安静。你的看法是什么？- 嗯，其余部分仍然处于我们还没有……初始基础设施去年被合并了。它一直在增长，但我们还没有任何真正依赖Rust的内核部分。对我来说，Rust是那种，第一，在技术上说得通，但对我个人来说更重要的是，我们作为内核和开发者不能停滞不前。
[6:22] 所以我总是——对尝试新事物、不过于安逸地做同样的事情感到兴奋。我的意思是，我现在已经在内核上工作了32年。是的，32年。在一件事情上工作这么长时间是很长的，但它仍然有趣，因为它不是同一件事情。我的意思是，32年前的Linux显然与今天的Linux非常不同。我实际上——经常寻找我们可以做新事情、可以以不同方式做事的地方，因为很容易陷入窠臼并说：“这运行得很好，”对吧？
[7:06] 而Rust。还没有真正展现出自己是下一个伟大的大事物，但我认为在明年，我们实际上会开始整合，甚至一些主要子系统也开始积极使用它。所以它是那种事情之一。它要成为内核的一大部分还需要数年时间，它确实正在发展成那种东西。- 那么你自己在写Rust代码吗？你在审查Rust代码吗？- 哦不。我一直在稍微阅读Rust代码，只是为了能对某些东西是否太可怕而不应被包含进内核做出某种判断。但我必须承认，没有。
[7:54] 我的意思是，内核我们依赖成千上万的人。我们每一个版本都有上千人参与，而且他们不是同一千人。相当常见的是，事实上，在最长的时间里，我们的统计数据大致是每个版本……大约一半参与的人只发送一个补丁。而且很多人再也没有出现。他们可能有一些他们关心的小东西想修复，他们并不是真正的内核人。他们因为其他原因发现了它。
[8:29] 然后他们把小小的补丁发给了内核。他们从未有兴趣做更多事情。但然后——另一半。不断回来。而说到Rust，我不会是管理Rust覆盖的人，因为那不是我的专长，正如内核的许多其他部分一样。老实说，我现在与其说是程序员，不如说我称自己为技术负责人，因为我不是管理者。
[9:03] 我不管理人，我管理代码。所以我称自己为技术负责人。我不是，我的日常工作不是编程，而是合并别人的代码，Rust将是那些状态之一。是的，所以Jim在他的主题演讲中指出，开源开发者有时会有主见。有时他们会表达自己的意见。- 抱歉？- 你过去有以表达丰富而闻名的名声，当然最近不是，但我一直在想的一件事是，那么目前谁在你的淘气名单上？哪些公司可能……哦，我不会去那里。
[9:46] 我去过那里……我们能举个手示意一下吗？他应该去那里吗？不，不，不。这就是那种你……多年前对某家公司竖中指的事情之一20。而那张照片每天都不断冒出来。所以我吸取了教训。我觉得当你搜索自己的图片时，它仍然是排名第一的搜索结果。我觉得那仍然是第一个孩子，是的。但我的意思是，说实话，我是在开玩笑，但与此同时，整个商业环境在过去20年里已经好多了。我们曾经处于那种情况，很难找到硬件的文档。
[10:27] 而且有些公司会主动抱有敌意。而现在这已经不再是事实了。我的意思是，现在我们有公司为自己的硬件编写驱动程序，而有时候很难找到文档，因为编写文档本身就很困难。很多公司不一定愿意记录他们硬件中的一些怪癖或缺陷，但就硬件支持而言，我们现在的处境非常好。
[10:57] 与我们过去相比。所以你谈到了不断变化的环境。内核峰会就在几周前刚刚举行。而多年来内核峰会上一直非常常见的话题之一，就是这个关于维护者疲劳以及这个角色有多么消耗人、多么有压力的整体问题。我们正在做些什么来改善这种情况，这不仅是为了个体维护者，也是为了Linux生态系统和更大的开源生态系统，我想。
[11:35] 所以我的意思是，我似乎——我是说，这一直是一个由来已久的问题。事实证明，找到维护者很难。找到开发者要容易得多。我们有很多开发者。每个版本都会被提及。但要成为一名维护者，嗯，有些人认为你必须是一个能包揽一切的超级开发者，但实际上并非如此。但要成为一名维护者，你必须具备一定程度的良好品味——你能够评判别人的代码。
[12:08] 而其中一些——也许是天生的，但很多只是需要练习。去看别人的代码，并能轻易判断出，这是一个好方法还是坏方法？这通常只是做了很多年的事情。所以，要成为一名维护者并胜任你的工作，你必须做很长时间。我们确实有很多很棒的维护者，但另一部分是，你必须一直都在。
[12:42] 呃，或者你必须找到其他可以合作的维护者，这样你就能围绕你的假期之类的事情来安排。对我来说，一直都在并不是问题，因为我热爱我所做的事情。我几个月前去度假了，我随身带着笔记本电脑。如果我没有……随身带着笔记本电脑，我会无聊死的。因为这就是我做的事，也是我长期以来一直在做的事。
[13:17] 但我意识到那不是每个人都适合的生活，尤其是当你必须为此投入多年的生命时。所以我们没有解决这个问题的办法。我们一直在讨论不同的解决方案，我们的许多维护者团队已经形成了不同的解决方案，而事实证明，问题之一在于：人很难。代码很容易。写代码，你有正确答案和错误答案。人际关系很难，能够与其他开发者合作、与其他维护者合作，并且工作，尤其是当你的维护者从事不同的事情、有不同的目标，他们想把自己的领域推向一个方向，而另一个领域的维护者进来想把它拉向另一个方向时。
[14:09] 这可能会非常有压力，而且这是那种……很多人似乎认为开源全都是关于编程的？但是……其中很多也是关于沟通的。而且不需要是同一个人。很多时候，有你的程序员，他没有太多社交技能，这样挺好。这确实会发生，对吧？然后你可能需要有一位维护者来充当翻译，我说翻译并不是指……我的意思是，在日本，我们在许多开源项目中也有语言问题。
[14:50] 项目，但当我说翻译时，我不一定是指语言。我是指上下文。代码的原因。嗯，这又是维护者的工作之一，就是把开发者的产出拿来，翻译到项目中，这又使得……这是一项艰难的工作，需要特定类型的人。我们很幸运……能有这么多维护者。如果你想成为一名维护者，相信我，高层是有空间的。但这实际上是我接下来想谈的。因为如果你看看高层，如果你看看副维护者级别的人。
[15:37] 如今他们中的大多数人要么像Greg一样没有头发。要么他们就是，这很残酷。要么他们像我们俩一样，他们的头发还没有完全变灰。有些人自欺欺人地认为头发还没有完全变灰。另一些人已经接受了这一点。但玩笑归玩笑，领导层，也就是所谓的维护者树顶端，我们确实看到那里明显的老龄化。显然随着时间推移，这必然会发生。
[16:14] 如果我展望五年后，很多人将开始步入60多岁，而第一批人将接近70多岁。你认为这会走向何方？在某种程度上，这是一个好问题。我的意思是，内核峰会是什么时候——一个月前，差不多吧？——三周。——三周前。而实际上那是第一年我个人意识到这一点：是的，我们很多人都开始变灰了。
[16:44] 谢谢。但与此同时，部分原因确实是维护者峰会我们试图将其限制在30人左右。在这30人中，至少有三人已经存在了超过30年。所以他们从Linux存在的第一年就在了，而他们仍然在、仍然活跃、仍然来参加维护者峰会，这意味着是的，他们更老更灰了，但也意味着我们确实有一个人们会留下来的社区。
[17:20] 但这是一把双刃剑。绝对是的。而且……例如，我喜欢内核中Rust方面的一件事是，有一位维护者明显比大多数维护者年轻得多，那就是Rust维护者。而且，呃，我们可以清楚地看到内核中的某些领域带来了更多年轻人。我们在维护者峰会上有一个——在维护者峰会上，我们有一个明显的分界，文件系统的人非常谨慎、非常稳重，他们深切关心自己的代码是100%正确的，因为如果文件系统有bug，你磁盘上的数据可能会丢失。
[18:13] 所以这些人非常认真地对待自己和他们的代码。然后你有驱动的人，他们稍微更，好吧。尤其是GPU的人似乎像是，什么都行。而且你确实注意到——在驱动方面，更容易找到年轻人，传统上这就是我们培养了很多维护者的方式，包括我的意思是，没头发的Greg。
[18:46] 我道歉，Greg。你可以稍后揍我。我的意思是，我的额头每年都在变大，所以我能说什么呢？离我也不远了。让我们完全换个话题，谈谈别的。正如Jim向我们证明的，你今天不可能不做关于人工智能和大语言模型的演讲。嗯，我通常说人工智能是打了兴奋剂的自动更正。因为大语言模型所做的就是预测你接下来最可能使用的词，然后从那里推断。所以，并不是真的很智能。
[19:26] 显然它对我们的生活和我们所处的现实的影响是显著的。你认为我们会看到LLM编写的代码作为拉取请求提交给你吗？我确信这会发生，是的。我的意思是，它可能已经在发生了，也许规模较小，人们更多地把它作为编写代码的辅助工具，但……很明显，自动化一直帮助人们编写代码。我的意思是，这不是什么新鲜事。对吧。
[20:07] 机器码了。我们甚至不写汇编器。现在我们正从C转向Rust。所以我不认为这像新闻每天谈论AI那样具有革命性。这显然不是我工作的领域。我仍然非常底层。我进入内核是因为我喜欢底层硬件细节，这就是为什么我还在那里。但你说你期望这能帮助人们编写代码，这能帮助人们入门。
[20:42] 但然后如果我们看看之前的对话以及代码审查和维护方面的挑战，那么你认为大语言模型会达到可以帮助我们审查代码、帮助维护子系统的程度吗？我希望，我希望，因为这肯定是其中一个我看到它们真正能够大放异彩的领域，找到明显的愚蠢bug。因为，我的意思是，这个房间里有多少人实际上是程序员？——很多。——相当多。很多bug我写，很多bug我看到别人写？它们不是那种微妙的bug。很多只是你没想到的愚蠢bug，你不需要那种更高的智能来找到它们。
[21:33] 但拥有警告的工具——我的意思是，我们有编译器警告明显的、非常明显的那些，但拥有LLM警告稍微更微妙的——情况，它可能只是说，这个模式看起来不像常规模式。你确定这是你的意思吗？而答案可能是，不，那完全不是我的意思。你发现了一个明显的bug。非常感谢。所以我确实认为LLM将成为一个大——你贬义地称呼它们——等等。
[22:10] 打了兴奋剂的自动更正，我实际上认为它们远不止于此，而且大多数人的工作方式是我们都是。在某种程度上是打了兴奋剂的自动更正。我看到这是一个可以帮助我们更好地做我们所做的事情的工具。但我一直很乐观。整个——充满希望。充满希望是你用的词。是的，是的。有帮助、充满希望和谦逊。充满希望和谦逊，这是我的中间名。
[22:41] 但——另一方面，我的意思是，我一直如此乐观，以至于32年前，我愚蠢到认为你可以写出比任何人都好的内核。所以你必须有点——有时过于乐观才能有所作为。我对你的镜头的态度真的必须是这样，嘿，这太棒了。这将……我喜欢看到乐观。我不一定分享它。现在很多人不同意我的观点。
[23:13] 但在这一切中我担心的一件事是我们看到幻觉。我们看到……这是LLM的技术术语。它们确实会产生幻觉，确实会编造东西。所以它们越是被置于没有实际人类在那里捕捉它们的情况下自动做事情的位置。这变得越可怕。不是科幻意义上的它们将统治世界那种可怕，而是将会发生如此多的bug，这将影响我们的生活或我们的代码。
[23:49] 嗯，我每天都能看到没有他们时出现的那些 bug。所以这可能就是我不那么担心的原因。我觉得我们自己把这些事情做得挺好的。而且我觉得我没办法用更好的亮点来结束 AI 这个话题了。让我们从那里转到我想谈的下一个话题，也就是数据。当然，这实际上和 AI 密切相关。30 年前我们刚开始做开源的时候，感觉代码才是掌控未来的东西，而协作的能力、拥有这个——正如 Jim 所描述的——我们创造的价值数十亿美元的代码，才是决定未来的因素。在 1990 年代，这当然是事实。
[24:38] 如果我看看我们今天的生活，似乎控制我们世界的是数据，而不是别的。Google、Amazon、Apple 这些公司对我们的了解。那么，你会参与关于开放数据的讨论吗？也就是说——在另一个领域重演那场革命？- 不，不，所以我一直最喜欢开源的一点就是，我可以放手，不去管那些不属于我这边的事情。
[25:11] 我是说，那是……在 kernel 内部也一直非常如此，那里有一些领域是我集中投入个人精力远多于其他人的。而我会让维护那一边的其他人去操心，比如网络、驱动之类的东西。所有 LF 项目也完全是这样。呃……我可能是 Linux Foundation 里比较高调的员工之一。
[25:43] 但我把自己留在 kernel 里。- 它的名字就叫 Linux Foundation。- 是的，这是个好名字。但我很享受这样一个事实：开源，甚至不只是开源，这种开放的理念已经被如此广泛地接受了。我尤其享受这一点，因为我记得它当初是什么样子。30 年前我刚启动这个项目的时候，人们会问我，为什么？对吧？人们会说，但你怎么赚钱？
[26:20] 对。这曾经是个问题，现在却再也没人提了。所以，我们居然在谈论开放数据，而且甚至没人问“你为什么要那么做？”，我觉得这才是真正的关键所在。我认为开放在某种程度上已经成为行业内的标准。人们有点理所当然地认为，当你必须做大项目时，无论是编程还是数据，最终项目会大到需要在公司之间共享。
[27:02] 最简单的共享方式就是直接把它开放，并使用允许完全广泛共享的许可证，我是说，这就是 LF 做的事情之一。所以 LF 做开放数据这件事很棒，但这并不意味着那是我做的事。不过我认为，如果你回想 Jim 的主题演讲，Linux Foundation 关注的很多重点就是超越个人、超越公司的协作，作为社会去协作和做事。
[27:37] 这里不想说得太夸张。拥有一个中立的地方，让人们可以聚在一起做事，这有着非常巨大的作用—— - 嗯，我是说，这，这 literally 就是我在 Linux Foundation 工作的原因。因为我拒绝在 Linux 公司工作。因为我不想处于那种由一家公司或一个商业实体成为特殊场所的境地。所以我同意 100%。你需要有一个中立的地方。而且——这就是为什么我把我的名字给了下面的链接。
[28:15] 那么开放数据。你认为在那之后——这种开放会走向什么方向？我们从开放代码走到了开放数据。我们要往哪里去？哪里是——？这是五年、10 年的事情。而我总是，我的答案总是一样的。我是个踏实的工程师。我看着眼前这一步。我不会发表宏大的宣言，说这就是 10 年后的世界。- 我记得有个人发过这样一封邮件。他说：“嘿，我启动了这个有趣的小项目。
[28:54] “这只是个小爱好。”- 嗯，我是说，这多少证明了我有多不擅长预测——是的，这就是为什么这个房间里有上千人，因为你太不擅长规划了，我猜。是的，现在我真的认为，很多人有时觉得有长期计划很棒。而我不认为这行得通，它在政治上行不通。整个五年规划那套在那个领域效果不太好，我也不认为它在技术领域真的有多大用处。你多少得对你想去的地方有个想法。
[29:33] 但如果你不看……眼前，你就只会……瞎摸索，永远到不了那座山顶，对吧？你可能心里有一趟宏大的旅程，但仍然要一步一步来。在技术领域尤其如此，你没法一步就改变世界。你必须走完所有小步去改进。你是技术型的。幻灯片直到你到达—— 嗯，既然你喜欢思考相对近期的未来，那我想在今天我们对话结束时给你一个挑战。那么明年 Open Source Summit 回到日本时，它应该在哪里举办？我提议冲绳。你呢？嗯，那会……我是说，我其实挺喜欢东京的。我妻子和我一起来的，所以我们一直……
[30:33] 四处走走，逛些奇怪的商场，在这里玩得很开心。不过冲绳对我来说听起来也不错。说到这里，谢谢大家。很高兴见到你们。
查看英文原始字幕
[0:00] Now I'm pleased to introduce our next speaker for conversation. Please welcome--please welcome to the stage, Dirk Horndell, the head of the Open Source Program Office at Verizon and the creator of Linux and Git, Linus Tobos. Please welcome. Bye.
[0:31] Thank you. Good morning. It's so funny to see all these cell phones pointed at us. I want to take out my cell phone and take a picture of all of you, but I left my phone over there. I'm Dirk Hoendel, I run open source at Verizon, and to quote Jim Zemlin, this is that other guy. Yes. Yeah, I'm the other guy, and I've done this before, and we've done this. Dirk said this is apparently the 23rd time we've done it.
[1:04] And the reason we do it this way is I do not enjoy giving public talks. I'm sure a lot of you understand that it's not the most fun thing in the world, so we've come up with this format where Dirk prepares. questions that I don't know beforehand, and we have more of a discussion in front of you, and that makes me much comfortable and hopefully it works for you people too. Yeah, and usually it works well. And occasionally he throws me curveballs that make me go, what do I do now? So let's see which one this one is. So I'm thrilled to be back in Japan. It's been a few years.
[1:43] sadly. We did our traditional sushi OD last night and it's It's always good to be here. Thank you so much for for having us. The timing changed. It used to be that the Japan conferences were like in June. And so being here pre-Christmases are actually kind of fun. So I'm-- quite happy. - And we've been lucky with the weather too. - Yes, it's been gorgeous. So Linus, you released Linux 6.7 RC4 a couple of days ago.
[2:16] And one of the fun things that came out in this is that we are going to have a Christmas New Year's Eve kernel. Well done. Good timing. Well, I mean, we have releases every... two and a half months, I think 10 weeks is basically what I try to aim for. So this happens every time that Christmas comes around, and we have The merge window, which is my busy time, is right around Christmas, which really destroys Christmas for me. Or we have the quiet period.
[2:54] when we're just trying to find and fix the last few bugs. And this year, happily, Christmas for me is the quiet period when the last few weeks of the release are going on and we're just waiting to make sure that we have nothing big going on that is a show stopper. And that works really well for me, but it means that All the... some maintainers and developers who are now preparing for the next version, 6.8, They will -- they will be in a slight panic just because they know that after Christmas my merge window opens, and that's when they are supposed to have all their stuff ready for the next version.
[3:39] So we'll probably delay that by a week or two just because We do that every year to make the timing work out better because nobody wants to work over Christmas. Yeah, but so with 6.7, what's exciting? Anything that sticks out to you. Um... We've actually had for the last, almost 20--no, not 20 years but 15 plus years, we've had a very regular release schedule. I'm happy to say that 6.7 is-- turning out to be one of the boring releases. Boring is good. - Boring is good. - You don't want to have too much excitement, because excitement usually means big bugs.
[4:23] 6.7 is-- - Bugs with a G, not with a CK. - Yes. Yeah. Thank you. Horrible. But 6.7 is actually slightly unusual. I think it may be the biggest release we've ever had when you just count number of commits. And, uh, The reason for that is actually we have a new file system that has been in the works for like a decade.
[4:56] There's a lot of new commits coming in for that. But it's still interesting to see that Not only are we keeping steady, we are still actually increasing the development speed. and the Kernel sizes tend to be going up, which Which is a good sign, but it obviously also means that there's a lot more work going on and a lot more work for maintainers to deal with. Yeah, besides Linus not liking my joke, I want to apologize to the simultaneous translators, because I have no idea how you would translate this into Japanese.
[5:36] So one of the things we've talked a lot about over the last few kernel releases is the introduction of Rust into the kernel And I think it has been-- relatively steady and quiet. What's your perception? - Well, the rest still is at the point where we don't, we have, The initial infrastructure got merged last year. It's been growing, but we don't have any part of the kernel that really depends on Rust yet. To me, Rust was One of those things that A, made technical sense, but to me personally even more important was that We need to not stagnate as as a kernel and as developers.
[6:22] And so I am always-- excited by trying something new and not getting too comfortable doing the same thing. I mean, I've been working on the kernel now for 32 years. Yeah, 32 years. And that's a long time to work on one single thing, but it's still interesting because it's not the same single thing. I mean, Linux 32 years ago was very different from what Linux is today, obviously. I actually-- often look for things where where we can do new things and we can do things differently, because it's so easy to get stuck in a rut and say, "This is working just fine," right?
[7:06] and rust. has not really shown itself as the next great big thing, but I think during next year, we'll actually be starting to integrate and some even major subsystems that are starting to actively use it. So it's one of those things. It's going to take years before it's a big part of the kernel, It's certainly shaping up to be one of those. - So you're writing Rust code yourself? You're reviewing Rust code? - Oh no. I have been reading Rust code a bit just so that I can make some kind of judgment calls on when something is too horrendous to be included in the kernel. But I have to admit, no.
[7:54] I mean, the colonel We rely on literally thousands of people. Every single release we have, a thousand people involved, and they're not the same thousand people. Quite often we have people, in fact, for the longest time, we've had the statistics be roughly that every release... about half the people involved Send just one patch. And a lot of them never show up again. They may have something small they wanted to fix that they cared about, and they were not really colonel people. They found it for some other reason.
[8:29] and they sent their small, patch to the colonel. And they were never interested in doing anything more. But then-- The other half. keeps coming back. And when it comes to rust, I'm not going to be the one who manages the rust cover because that's not my expertise, as is true of so many other parts of the kernel. I'm honestly I'm less of a programmer these days than I am, I call myself a technical lead because I'm not a manager.
[9:03] I don't manage people, I manage code. So I call myself a technical lead. I'm not, my day-to-day work is not programming, it is merging other people's codes and Rust will be one of those states. Yeah, so Jim in his keynote pointed out that open source developers sometimes are opinionated. sometimes they express their opinions. - I'm sorry? - You have had in the past a reputation for being expressive and not lately of course, but one of the things that I've been wondering about, so Who is currently on your naughty list? Who are the companies that might... Oh, I'm not going there.
[9:46] I went there... Can we get a sign of hands? Should he go there? No, no, no. It's one of those things you... give some company the finger 20 years ago. And that picture keeps coming up every day. So I learned my lesson. I think it's still the number one search result when you look for images of you. I think that's still The first kid, yes. But I mean, to be honest, I mean, I joke, but at the same time, the whole commercial environment has gone so much better over the last 20 years. We used to be in the situation that it was, hard finding documentation for hardware.
[10:27] And some companies would be actively hostile. And that's just not true anymore. I mean, now We have companies that write drivers for their own hardware, and sometimes it's so hard to find documentation because writing documentation is hard. And a lot of companies don't necessarily want to document some of the quirks or bugs in their hardware, but we're in such a good position when it comes to hardware support.
[10:57] compared to where we used to be. So you talked about the changing environment. The Kernel Summit was just a few weeks ago. And one of the topics that has been very common at the Kernel Summit for many years is this overall question of maintainer fatigue and how draining and stressful this role is. what are we doing to improve the situation, which is not just for the individual maintainers but for the Linux ecosystem and for the larger open source ecosystem, I guess.
[11:35] So I mean, I seem-- say, I mean this has been an thing that has been coming up for the longest time. It turns out it's hard to find maintainers. It's much easier to find developers. We have a lot of developers. Every release is mentioned. But to be a maintainer, Um, Some people think that you have to be this kind of super developer that can do it all, but that's not actually true. But to be a maintainer, you have to have a certain amount of good taste to--you can judge other people's code.
[12:08] and Some of that-- maybe innate, but a lot of it is just it takes practice. to look at other people's code and easily be able to tell, is this a good approach or a bad approach? it's usually just a matter of having done it for many years. So to be a maintainer and be good at your job, you have to do it for a long time. And we do have a lot of great maintainers, but the other part of it is You have to be there all the time.
[12:42] uh or you have to find other maintainers that you can work with so that you schedule around your vacations and things like that. For me, being there all the time is not a problem because I love doing what I'm doing. I was on vacation. a couple of months ago and I had my laptop with me And if I didn't have... my laptop with me, I would have been so bored. Because it is what I do, and it is what I've been doing for a long time.
[13:17] But I realize that's not the life for everybody, especially when you have to put in years of your life into this. So we don't have a solution to this. we've been talking about different solutions and many of our maintainer groups have formed different solutions, and it turns out one of the issues is People are hard. Code is easy. To write code you have a right answer and you have a wrong answer. People relationships are hard and being able to work with other developers, work with other maintainers, and work, especially when you have maintainers that work on different things and they have different goals, and they want to push their area in one direction and another maintainer comes in from another area and wants to pull it in another direction.
[14:09] It can be very stressful and It's one of those things where A lot of people seem to think that open source is all about Programming? But... A lot of it is about communication too. And it doesn't need to be the same person. Quite often it's good to have, you have your programmer that does not have a lot of social skills. It happens, right? and then you may need to have a maintainer who's the one who translates, and I say translates not, I mean in Japan, We have the language issue too in many open source programs.
[14:50] project, but when I say translates, I don't necessarily mean language. I mean the context. the reason for the code. Um, And that's again one of those jobs of a maintainer to kind of take take the developer output and translate it into the project and again makes Makes four. a tough job and a certain kind of person. And we're lucky to... to have as many main tears as we do, If you want to be a maintainer, Trust me, there's room at the top. But this is actually where I wanted to go next. Because if you look at the top, if you look at the people at the sub-maintainer level.
[15:37] Most of them these days are either like Greg and have no hair. or they are, that's rough. Or they are like the two of us and they have It's not completely gray yet. Some people kid themselves that the hair isn't completely gray yet. Others have accepted that. But Kidding aside, the the leadership, what you call at the top of the maintainer tree, we are certainly seeing a significant aging there. Obviously as time goes by that has to happen.
[16:14] If I look five years into the future, and a lot of people will start hitting the 60s, and the first ones will approach the 70s. Where do you see this going? It's a--to some degree, it's a good problem to have. I mean, so the Kernel Summit was what-- a month ago, something like that? - Three weeks. - Three weeks ago. And it was actually the first year when I personally reacted to the fact that yes, a lot of us are going gray.
[16:44] Thank you. But at the same time, part of the reason really is The maintainer summit is we try to limit it to about 30 people or so. Of those 30 people, at least three of them had been around for more than 30 years. So they had been around since like, the first year of Linux existing, and the fact that they are still around and still active, and still end up coming to maintainer summits means that yes, they are older and grayer, but it also means that we actually have a community where people do stick around.
[17:20] But that's a double-edged sword. Absolutely. And it's... For example, one of the things I liked about the rust side of the kernel was that there was one maintainer who was clearly much younger than most of the maintainers, and that was the rust maintainer. And, and, uh, we can clearly see that certain areas in the kernel bring in more young people. We had a--in the maintainer--at the maintainer summit, we had this clear division between the file system people who were very careful and very staid and they cared deeply about their code being 100% correct because if you have a bug in a file system, the data on your disk may be gone.
[18:13] So these people take themselves very seriously and their code very seriously. And then you have the driver people who are A bit more, OK. Especially the GPU people seem to be like, anything goes. And you did notice that the-- On the driver's side, have a much easier time finding young people and that is traditionally how we've grown a lot of maintainers including I mean, Greg with no hair.
[18:46] I apologize, Greg. You can beat me up later. I mean, my forehead is getting larger every year, so what can I say? It's not far away from me. Let's switch gears completely and talk about something else. You cannot possibly give a presentation today as Jim proved to us. without talking about artificial intelligence and large language models. Um, I typically say artificial intelligence is autocorrect on steroids. because all a large language model does is it predicts what's the most likely next word that you're going to use and then it extrapolates from there. So, not really very intelligent.
[19:26] Obviously the impact that it has on our lives and on the reality we live in is significant. Do you think we will see LLM written code that is submitted to you as a pull request? I'm convinced it's going to happen, yes. I mean, and it may well be happening already, maybe on a smaller scale where people really use it more as a, as a help in writing code, but It's... it's clearly is something where Automation has always helped people write code. I mean, this is not anything new at Right.
[20:07] machine code anymore. We don't even write assembler. And now we're moving on from C to Rust. So I don't see this as something as revolutionary as all the news talk is every day about AI. It's not an area I obviously-- work with. I'm still very low level. I got into kernels because I love the low level hardware details and that's why I'm still there. But so you say you expect this can help people write code, this can help people get started.
[20:42] But then if we look at the previous conversation and the challenges around code reviews and maintaining, so do you think that large language models will get to the point that they can help us review code, that they can help maintain subsystems? I hope, I hope, because that's certainly one of the areas where which I see them really being able to shine, to find the obvious stupid bugs. Because, I mean, how many people here are actually programmers in this room? - A lot. - A fair number. A lot of the bugs Ivory right a lot of the bugs I see other people right? They're not like I subtle bugs. A lot of them are just the stupid bugs that you did not think about and you don't need to and his kind of higher intelligence to find them.
[21:33] But having tools that warn-- I mean, we have compilers that warn about the obvious, really obvious ones, but having LLMs that warn about slightly more subtle-- cases where where it may just say, This pattern does not look like the regular pattern. Are you sure this is what you mean? I and The answer may be, no, that was not at all what I meant. You found an obvious bug. Thank you very much. So I do think that LLMs are going to be a big -- you call them disparagingly -- Wait.
[22:10] autocorrects on steroids and I actually think that They're way more than that and how most people work is we all are. autocorrects on steroids to some degree. And I see that as a tool that can help us be better at what we do. But I've always been optimistic. The whole -- Hopeful. Hopeful was the word you had. Yes, yes. Helpful, hopeful and humble. Hopeful and humble, that's my middle name.
[22:41] But -- On the other hand, I mean, I have been so optimistic that 32 years ago, I was stupid enough to think that you can write a better kernel than anybody else. So you have to kind of be a bit-- bit too optimistic at times to make a difference. My approach to your lens really has to be in that, hey, This is wonderful. This is going to... I love seeing the optimism. I don't necessarily share it. Now a lot of people disagree with me.
[23:13] But one of the things that I worry about in all this is we see the hallucinations. We see... And that's a technical term for LLMs. They do hallucinate and they do make up stuff. And so the more they are being put into the position where they will automatically do things without an actual human being there to catch them. the more this becomes scary. not scary as in they will rule the world and not in the sci-fi sense, but in the so many bugs that will happen and that will affect our lives or our code.
[23:49] Well, I see the bugs that happen without them every day. So that may be why I'm not so worried. I think we're doing those just fine on our own. And I don't think I can end the AI topic on a better highlight. Let's go from there to my next. topic I wanted to talk about, which is data. Which is, of course, very related to AI, actually. 30 years ago when we started on open source, it felt like code was the thing that controlled the future and the ability to collaborate, to have this, as Jim described it, billions of dollars worth of code that we have created is the determining factor of the future. That was certainly true in the 1990s.
[24:38] If I look at our lives today, it seems it's far more data than controls our world. What the Googles and Amazons and Apples of the world know about us. So, do you get engaged in the discussions about open data? So-- repeating that revolution just in a different realm? - No, no, so one of the things I enjoy most about open source has always been that I can let go and not care about the things that are not my side.
[25:11] I mean, that's... That's been true very much inside the kernel too where there are AREAS. where I concentrate. my personal effort much more than others. And I let other people who maintain that side worry about. like networking, things like drivers. And the same is very much true of All the LF projects. Uh... I may be one of the more high profile employees of the Linux Foundation.
[25:43] But I keep myself into the kernel. - Which is named the Linux Foundation. - Yes, it's a great name. but I I enjoy the fact that open source and not even open source, the notion of openness has gotten so much more widely accepted. And I enjoy it particularly because I remember what he was. 30 years ago when I had started this project and people would ask me, Why? Right? And people would say, But how do you make money?
[26:20] Right. And this used to be a question and it never comes up anymore. So the fact that we are even talking about open data And nobody even asks, "Why would you do that?" I think that's the real, deal here. Openness has, I think, to some degree become the standard within the industry. And people kind of take for granted that when you have to have big projects, whether they are programming or data, and you end up having them so big that you need to share between companies.
[27:02] The easiest way to share is to just make it open and use a license that allows for completely wide sharing and I mean this is what one of the things LF does. So the fact that LF does open data is great, but that does not mean that it's a thing I do. But I think that if you reflect on Jim's keynote, A lot of what the Linux Foundation is focused on is that collaboration beyond the individual, beyond the company, to collaborate and do things as a society.
[27:37] trying to be too hyperbolic here. There is a very huge role in having that neutral place that people can come together and do things that-- - Well, I mean, this, that is literally why I'm working at Linux Foundation. because I refuse to ever work at a Linux company. because I did not want to be in the situation where one company or one commercial entity would be the special place. So I agree 100%. You need to have a neutral place. And-- That's why I gave my name to the links below.
[28:15] So open data. What do you think Beyond that will be-- the the direction this openness is taking. We went from open code to open data. Where are we going with this? Where is the--? This is the five year, 10 year thing. And I always, my answer is always the same thing. I'm a plodding engineer. I look at the step in front of me. I don't make grandiose announcements of, this is what the world will be 10 years from now. - I remember there's this email of this guy. He says, "Hey, I started this fun little project.
[28:54] "It's just a little hobby." - Well, I mean, that kind of proves how bad I am at predicting the-- Yes, this is why there are a thousand people in this room, because you're so bad at planning, I guess. Yes, now I actually think A lot of people sometimes think that having of long-term plan is great. And I don't think it works, it doesn't work in politics. The whole five-year planning thing did not work so well in that area and I don't think it really works in technology very much. You have to have kind of an idea of where you'd like to go.
[29:33] But if you don't look... Right in front of you, you will just... fumble around and you'll never actually get to that top of the mountain, right? You may have a great big journey in mind, but it's still one step at a time. And that is particularly true in technology where you can't just change the world in one big leap. You have to take all the small steps to to improve. You are technical. slide until you get-- Well, and since you like to think in relative near-term future, So I figure I'll give you a challenge for for the end of our conversation today. So when the Open Source Summit comes back to Japan next year, Where should it be? I'm suggesting Okinawa. How about you? Well, that would... I mean, I actually enjoy Tokyo. I'm here with my wife, so we've been...
[30:33] walking around and doing odd shopping malls, and have been having a good time here. But Okinawa sounds good to me too. And on that note, thank you, everyone. Good to see you.
在Vidleaf工作台中打开
搜索转录文本，选择行，复制带时间戳的引文，翻译。
署名
“主题演讲：Linus Torvalds，Linux & Git 的创造者，与 Dirk Hohndel 对话”，由 The Linux Foundation 制作（https://www.youtube.com/@linuxfoundationorg），依据 CC BY 3.0 许可（https://creativecommons.org/licenses/by/3.0/）。源视频：https://www.youtube.com/watch?v=OvuEYtkOH88。本页是该视频的文本转录，添加了段落分隔和时间戳；创作者与 Vidleaf 无关联，也不为其背书。Vidleaf 添加了 AI 标点和 AI 生成的摘要；原始措辞仍可在本页查看。阅读文本还包含 Vidleaf 经来源核实的姓名更正。
您是创作者或权利持有人吗？请求更正或移除：copyright@vidleaf.app（参见关于这些页面）。
最后更新于