Linux内核开发流程与管理 - 公司每9周发布一个新版本，其中包含一个为期两周的合并窗口期，在此期间需要处理大约12,000次提交，合并后的提交量在11,000到13,000次之间 [1][13][15] - 在合并窗口期后的7周内，工作重点转向查找并修复bug，并发布每周的候选版本，直至最终版本发布 [1][16] - 公司对长期支持版本有明确规划，通常每年指定一个版本作为LTS，旨在为各类企业提供一个可长期依赖的标准版本 [9][10] - 公司通过灵活的合并窗口机制减轻开发压力，代码在准备好时被合并，而非设定绝对截止日期，若错过一个版本，9周后即可进入下一个周期 [13] - 项目掌舵者目前的核心职责是保持对整体项目的高层次理解，合并不同团队的代码，并处理代码冲突，而非亲自编写代码 [15][17][18] 代码质量与维护原则 - 公司坚持一条核心铁律：不允许出现功能倒退、回退性问题或破坏向后兼容性的回归 [2][22] - 维护过程中最不能接受的行为是开发者不愿意承认自己引入了bug，正确的态度应是承认错误并修复 [3][21] - 为确保质量，掌舵者会在自己的所有机器上运行每一个即将发布的内核版本，并经常能发现本应在测试阶段被捕获的bug [20][21] - 坚持“不允许回归”原则在技术上极具挑战，因为某些行为改变可能在数年后才被发现，此时修复可能影响已适应新行为的程序，因此公司有时会采取让内核对不同程序表现出不同行为的极端方案 [30][31][32] - 公司在引入新功能时，会创建新的接口，同时确保旧接口保持可工作状态，以维护向后兼容性 [33] 对人工智能技术的看法与应用 - 公司掌舵者直言讨厌“AI”一词，主要因其被过度炒作，而非讨厌技术本身 [3][24] - 认为AI与几十年前编译器的出现本质相同，都是重要的工具革新，不应期待AI会突然彻底改变编程 [3][27] - 更看好AI在代码审查和维护方面的应用价值，而非仅仅用于生成代码，已有多个相关项目在推进，并希望明年能将其深度集成到工作流程中 [24][25][26] - 认可AI工具在审查代码时能发现连专家都未注意到的问题，这证明了其实际价值 [26] - 指出AI的优势在于提供了更高的抽象层，允许用更高级的语言表达意图，从而提升效率，这与需要明确底层细节的编译器工作方式不同 [29]

Linux内核开发流程与版本发布 - 项目采用固定的9周发布周期，每周期包含一个合并窗口期和后续的bug修复阶段 [14] - 在合并窗口期的两周内，项目掌舵者需要处理大约12,000次代码提交，范围在11,000至13,000次之间 [16] - 合并窗口期结束后，有7周时间专门用于查找并修复bug，以提升内核稳定性 [17] - 项目每年会指定一个版本作为长期支持版本，为各类公司提供可长期依赖的标准版本 [10] - 项目有意识地避免在LTS版本中引入巨大、颠覆性的变动，以保持稳定 [10] 项目维护者的角色与工作方式 - 项目掌舵者自称已不再编程，核心工作是合并由子维护者提交的代码，并保持对项目的宏观理解 [16][18] - 其工作重点是处理代码合并冲突，确保不同团队提交的代码能正确整合，并维护项目流程 [18][20] - 作为维护者，其会在自己的所有机器上运行最新的内核版本，以此作为发现bug的一种方式 [21] - 项目掌舵者认为，在代码审查和冲突处理方面，其经验比绝大多数子维护者更丰富 [18] 项目开发文化与原则 - 项目拥有一条核心铁律：不允许出现功能倒退或破坏向后兼容性的回归问题 [3][23] - 项目掌舵者最不能接受的行为是开发者不愿意承认自己引入了bug [4][22] - 坚持“无回归”原则在技术上非常困难，有时需要为不同的程序保留不同的行为以维持兼容性 [31][33] - 项目在引入新功能时，会创建新的接口，同时保持旧接口可工作，极少有项目能做到这一点 [34] 对人工智能技术的看法与应用 - 项目掌舵者直言讨厌“AI”一词，认为其被过度炒作，但非常相信AI作为工具的价值 [4][25] - 将AI的出现类比为几十年前编译器的出现，认为其是工具的又一次进化，而非彻底改变编程的革命 [4][28] - 认为AI在帮助审查代码、解释问题方面比用于编写代码更有价值，并希望其能成为工作流程的重要组成部分 [25][26] - 指出AI的优势在于提供了额外的抽象层，允许用更高层次的语言表达意图，而不必解释所有底层细节 [30] - 已有公司内部项目使用AI进行代码审查，并能发现专家未注意到的问题，展现了其价值 [26][27] 项目规模与社区管理 - Linux内核的代码行数已突破4000万行，拥有几百名维护者和数千名开发者 [19] - 项目通过固定的发布周期和灵活的合并窗口，减轻了开发者必须赶在某个绝对截止日期前完成代码的压力 [14] - 项目掌舵者会因开发者在合并窗口结束前一刻提交代码或未充分测试就提交导致其发现bug而感到恼火 [21] - 项目掌舵者承认自己也会有压力，并努力在社区互动中保持克制和礼貌 [23]

Rust在Linux内核中的发展历程与现状 - 围绕是否将Rust引入Linux内核的争论持续数年，被视为对内核安全的潜在突破或对现有工程秩序的挑战[1] - 2025年Linux内核维护者峰会达成共识，Rust在Linux内核中的“实验阶段”正式结束，被明确认可为Linux主线内核的长期组成部分[2] - Rust for Linux项目始于2020年，初期定位克制，旨在评估Rust是否值得内核为其付出额外的复杂度成本，而非取代C或大规模重写内核[4] Rust在内核中取得认可的关键事实 - 自2022年以来，已有超过2万行Rust代码被合入Linux上游内核，表明其已成为持续演进的真实工程代码[5] - Rust编写的内核驱动已在真实设备中运行，例如Google Pixel系列手机的部分底层驱动，证明了其在生产环境中的可行性与安全性[5] - 围绕内核开发的Rust生态正在成熟，包括基础库、抽象层和工具链逐步完善，使得用Rust写内核代码具备可扩展性[5] 实验结束后的官方定调与未来工作 - 项目负责人Miguel Ojeda宣布，Rust支持在Linux v6.1版本合入主线，初衷是评估其是否适合内核开发，而2025年的峰会正式宣布实验结束[6] - 实验结束不代表完美，Rust在内核中的适配仍有大量工作要做，包括不同架构、内核配置以及GCC与LLVM混合构建的适配[6] - 一些组合方案，如GCC + LLVM混合构建以及即将到来的GCC原生Rust支持，目前仍具有一定实验性[6] - 方向已明确，Rust将长期留在Linux内核中[7] Rust驱动加速落地与行业影响 - 一批由Rust参与编写的重量级项目正在或即将进入Linux主线，包括面向Apple Silicon的Asahi GPU驱动、作为Nouveau继任者的Nova驱动（面向NVIDIA基于GSP的GPU）以及针对ARM Mali GPU的Tyr驱动[8] - 具体时间线：Asahi项目将在Linux 6.17中加入Devicetree schema支持，Nova驱动计划在Linux 6.19中完成初始启用，Tyr驱动已经能在Linux 6.18上启动GNOME桌面并运行基础游戏[8] - Linux内核对Rust“实验结束”的表态是一个明确信号，向公司、芯片厂商和开发者社区表明Rust是值得长期投入的方向，可能促使更多企业提供Rust培训，更多硬件厂商考虑用Rust编写新一代驱动[8] Rust与C语言的共存关系 - Rust在Linux内核中的地位转变，从“是否该引入”变成了“如何更好共存”的问题[9] - C语言在Linux内核中的核心地位不会被动摇，Linux内核仍将长期是一个以C为核心的工程[9]