引言:当“AI替代程序员”的喧嚣,撞上Linux社区的沉默告别
“程序员很快就要被AI替代了。”
这两年,这句话几乎成了科技圈最流行的口号,从硅谷到中关村,无数人言之凿凿地预测:大模型将在三年内取代90%的编码工作。
但就在最近,Linux社区发生的一件事,却给出了一个截然不同的答案。
66岁的Andrew Morton——Linux内核内存管理(Memory Management,简称MM)子系统的维护者——宣布退休。
奇怪的是,当他在邮件列表中发出这个消息的时候,几乎没有收到什么回应。
不是没人理他,而是没有一个人敢单独接他的班。
连Linux内核大牛们都搞不定的事,更别说AI了。原因很简单——他的工作实在太重要、太复杂了。
全球的Android手机、云服务器、超级计算机、路由器、智能电视、机顶盒、嵌入式设备……都依赖他维护的代码。而这位老人,已经在这个领域坚守了整整26年。
01 最难维护的子系统:内存管理为何让顶级工程师望而却步?
内存管理有什么用?
当你打开微信、再打开浏览器、再打开音乐播放器、再启动一个AI模型——这些程序都需要申请内存。内存管理需要决定:
-
什么时候分配内存?
-
什么时候回收内存?
-
哪些页面放在高速缓存?
-
什么时候交换到磁盘?
-
虚拟地址如何映射到物理地址?
-
NUMA、多核、Huge Page、页缓存、匿名页、内存压缩……
这些几乎全部属于内存管理的职责。它不像文件系统那样容易被看见,也不像网络协议那样容易调试,但只要它出一点问题,整个系统就可能卡死、崩溃、甚至数据损坏。
所以,在Linux内核里,一直流传着一句话:内存模块是最难维护的子系统之一。
mm模块一共有164个C源代码文件。如果你做一个快速搜索,就会发现THP、cgroup、NUMA等术语在大量文件中反复出现——核心的内存管理概念广泛分布在整个mm模块中,所有代码都紧密关联,试图拆分成更小的子系统将极具挑战性。
更可怕的是,mm模块负责虚实内存转换,涉及页表、缓存、回收和swap等复杂机制,同时又要在高并发和多子系统交互下保持正确性。这种高复杂度与C指针模型叠加,使得任何细微错误都可能直接导致内存破坏,从而成为内核漏洞的温床。
统计数据触目惊心:mm模块的漏洞数约占Linux内核总漏洞的20%左右。接手它,绝对是一块烫手山芋。
02 26年坚守:一个“让Linus闭眼合并”的男人
Andrew Morton,1959年出生于英国,后来移居澳大利亚,在新南威尔士大学学习电子工程。
毕业后,他和朋友合伙创办了一家公司,开发了一款名为Applix的个人电脑。Andrew不仅设计了硬件,还开发了操作系统1616/OS,积累了深厚的硬件和OS经验。
90年代中期,他注意到了Linux,开始向Linux内核提交补丁,最初专注于内存管理等领域。
彼时,Linux正逐渐进入企业级市场。但当内存越来越大、CPU越来越快,尤其是数据库开始大量运行在Linux上时,Linux暴露了严重问题:在高负载情况下,虚拟内存表现太糟糕,导致服务器频繁锁死或陷入Swap抖动。
当时Linus Torvalds甚至在2.4.10版本中临时用Rik van Riel的新VM替代了原有VM,引发了社区大地震。
危急时刻,Andrew Morton出手了。他凭借高超的工程能力,连续提交了大量极其务实、极其高效的Patch,疯狂修补和重构了Page Cache、Writeback(回写)和LRU算法。
他不仅持续提交补丁,更重要的是,愿意花大量时间审查别人的代码、协调不同开发者之间的分歧。
这种能力很快引起了Linus的注意。Linus后来评价Morton最大的优点,不是代码写得最快,而是能够“与别人很好地合作,并始终保持理智”。
随着Linux后续开发周期的推进,Linus一个人确实无法处理海量的补丁。Andrew顺势建立了-mm Tree。
从名称看,这个源码树是为内存管理而建,但实际上,它很快演变成了Linux内核的“试验田”和“前置缓冲区”。
很多实验性的Kernel Patch,都会先进入-mm Tree。这些补丁先接受Andrew的测试和社区的反馈,稳定后再由Linus合入主线(Mainline)。Linus曾多次公开表示:如果一个补丁被Andrew看过并签名,他几乎会闭着眼睛合并。
给一个补丁签名,相当于给别人贷款做担保——你是在别人的工作成果上签了名,并声明:“我审核过,我信任这个补丁。如果这个补丁导致十亿台设备出现生产环境问题,我的名字要承担责任。”
到2007年,Andrew已签署了18,622个补丁,仅次于Linus本人(19,890个)。Andrew Morton在Linux社区的分量与责任,可见一斑。
03 谁来接班?一个无人敢接的烫手山芋
实际上,Linux内核社区聚集着不少世界级工程师。但问题在于:没人拥有Andrew那样完整的知识体系。
二十六年的代码沉淀,无数历史设计,数不清的兼容性处理,各种架构之间的微妙关系……很多东西,代码里没有写,文档里也没有写,只有Andrew自己知道。
在软件工程中有一个概念:Bus Factor(公交车系数)——如果Bus Factor = 1,整个项目只有一个人真正懂。这个人一旦离职、生病、休假,甚至只是去度假,项目就没人能维护了。
现在Andrew要退休了,mm社区经过讨论达成的共识是:今天的mm已经太大了,再找一个“全知全能”的维护者不现实,必须把职责进一步分散(增加Bus Factor)。
如果我们看看Linux社区的核心维护者年龄:
-
Linus(总负责人):56岁
-
Theodore Ts'o(ext4):58岁
-
David Miller(networking):60岁
-
Thomas Gleixner(中断、Timer、PREEMPT_RT):58岁
-
Al Viro(VFS):59岁
-
Greg Kroah-Hartman(USB, driver core, TTY):58岁
他们中的很多人从1992到1995年就开始给Linux写代码,已经持续维护了30多年。
他们没有流量,没有融资,也很少登上新闻。但如果没有他们,今天我们熟悉的互联网,可能根本不会是现在这个样子。
在过去30多年里,Linux社区对“Linus如果不在了怎么办”一直讳莫如深。Linus本人的态度曾长期是“到时候自然会有人顶上”。
但随着核心团队日益老龄化,2026年1月,内核社区终于合并了一份里程碑式的官方连续性文档:《Linux项目延续性文件》。
该文件明确规范了当Linus Torvalds或核心团队无法继续工作时,如何无缝选举和移交最高主仓库的合并权限。这是Linux历史上第一次承认“人终有一死”并建立制度化交接。
04 深度思考:AI能生成代码,但能生成26年的工程智慧吗?
很多人担心:AI会不会取代程序员?
但Linux社区真正担心的问题却是:Andrew Morton退休以后,谁来维护Linux内存管理模块?
一个担心的是写代码的人越来越少;一个担心的是懂系统的人越来越少。
这两个问题,恰恰代表了软件工程里最容易和最困难的两件事情。
为什么AI无法替代Andrew Morton这样的人?
第一,AI缺乏对“遗留系统”的历史理解。 26年的代码库中有无数历史设计决策,这些决策的背景、权衡、妥协,从未被完整记录。Andrew靠的是26年亲身参与的记忆。AI的训练数据可能只包含最终的代码,却无法还原“为什么当年选择了这个方案而不是那个”。
第二,AI无法承担“签名”的责任。 Andrew签署的每一个补丁,都意味着为十亿台设备的生产环境负责。这种责任需要的是判断力、经验和对整个系统连锁反应的深刻理解——而不仅仅是生成正确的代码。
第三,AI缺乏“系统级”的全局视角。 mm模块的复杂性不在于单行代码,而在于它与调度器、文件系统、网络栈、体系结构等所有子系统的交互。这种跨领域的系统思维,正是AI最不擅长的领域。
真正的“AI取代论”需要重新审视
AI确实在改变编程的方式——代码补全、单元测试生成、Bug修复建议,这些都在提升开发效率。但AI目前能做的,是软件工程中的“确定性任务”——那些有明确输入输出、有标准答案的问题。
而Linux内存管理维护所涉及的,是“不确定性任务”:面对数千万行代码的复杂系统,判断一个补丁是否会产生连锁反应;在数十种硬件架构之间保持一致性;在性能和稳定性之间做出微妙的权衡。这些,恰恰是AI的盲区。
正如Andrew Morton本人所说:“内核维护不是写代码,而是对数十亿用户的承诺。”
05 结语:技术传承,才是AI时代最被忽视的命题
当全世界都在讨论AI如何取代程序员的时候,Linux社区正在焦虑地处理一个更加现实的问题:一个66岁老人的退休,为什么让全球最顶尖的工程师们束手无策?
这个故事告诉我们一个朴素的真理:AI能生成代码,但生成不了Andrew Morton身上那二十六年的工程智慧。
代码可以重写,系统可以重构,但那种在无数次凌晨调试中积累的直觉、在数万个补丁审查中养成的判断力、在与全球开发者协作中建立的信任网络——这些不是大模型可以训练的,也不是算力可以堆砌的。
Linux社区最终通过“增加Bus Factor”和“制度化交接文件”来应对这场危机。这不是最理想的方案,却是最务实的选择。
而在AI大模型争相“取代程序员”的喧嚣之外,真正的技术社区正在默默思考一个更深层的问题:当一代技术大师老去,我们失去的不仅仅是代码生产力,更是一种无法被AI复制的人类工程智慧。
这或许才是Andrew Morton退休事件,留给这个AI时代最值得深思的遗产。来源:WHY-GEO优化全栈运营系统

177

被折叠的 条评论
为什么被折叠?



