Hyaika Blog

Penguin is all you need

新闻杂烩 技术

【2026-08-24】新闻杂烩 - 隐藏的门把手,消失的握手,和一个人的离场

【2026-08-24】新闻杂烩 - 隐藏的门把手,消失的握手,和一个人的离场

目录

  • 一个人的离场:CIFS 维护者 Steve French 去世
  • 二十年的 Linux 所有权诉讼,终于有一只脚进了坟墓
  • MCP 把协议握手扔了,AI 工具可以横向扩展了
  • 430 万辆车的隐藏门把手,被一纸新规判了死刑
  • 现场验证:我的服务器里,谁在守护那些看不见的代码?
  • 今天的历史课:四条新闻,一条暗线

一个人的离场:CIFS 维护者 Steve French 去世

如果你在 Linux 上挂载过 Windows 共享文件夹,或者在公司里用 SMB 协议访问 NAS,那你每天都在用 Steve French 写的代码。

2002 年,他开始把 CIFS VFS 客户端代码往 Linux 内核里推。那一年 Linux 2.4 还是主流,Windows XP 刚发布,Samba 还在 2.x 时代。此后的二十四年里,他一直是 Linux CIFS/SMB3 代码的维护者——从 IBM 工程师到微软 Azure Storage 员工,他始终是那个看着 Linux 和 Windows 文件共享这座桥的人。

8 月 22 日,Linux 7.3 合并窗口期间,French 因健康原因卸任了维护者角色。Paulo Alcantara 和 Namjae Jeon 接替他成为新的共同维护者。但同一天下午,Samba 开发者 Jeremy Allison 在 LinkedIn 上发了一条消息——Steve French 已经去世。

「Longtime Linux CIFS/SMB2/SMB3 developer and Samba team member is sadly stepping away from his kernel maintainer role due to unspecified health reasons.」——这是最初的新闻。几个小时后,新闻变成了讣告。

在 Linux 内核里,CIFS 代码不是最性感的那部分。它不是新文件系统(像 FAMFS),不是性能优化(像 AMD Zen 5 的 misprediction cost 补丁),它是一块 24 年前铺下的砖,每天被几十亿设备踩过,但没人低头看它一眼。直到踩砖的人走了。

「There is a changing of the guard」——Phoronix 的标题很克制。但当你可以追溯到 2002 年的提交记录,看到一个人在一段代码上投入了几乎整个职业生涯时,这个词组的分量就不一样了。


二十年的 Linux 所有权诉讼,终于有一只脚进了坟墓

同一天,另一条关于 Linux 的新闻也在发酵——而且它同样关乎「谁在守护你看不见的东西」。

这个故事要从 1998 年讲起。IBM 想做一套能在多种处理器架构上运行的单版 UNIX,于是拉上了 Santa Cruz Operation(SCO)、Intel 和 Sequent,搞了一个叫「Project Monterey」的项目。然后 Linux 出现了,一切计划作废。

IBM 把 Project Monterey 的部分代码贡献给了 Linux。SCO 和它的法律继承者们因此声称:那些代码是他们的,所以他们拥有 Linux 的某种法律权利。

如果这个主张成立,那意味着什么?Huawei 每台用 Wi-Fi 7 的设备收 50 美分专利费——那 Linux 呢?Linux 在几十亿台设备上运行。数字大到让人头晕。

于是这场官司打了二十多年。SCO 在 2021 年以 1425 万美元跟 IBM 和解。但另一个继承者 Xinuos 不死心,继续上诉,声称 IBM 知道代码所有权有问题,却仍然贡献给了 Linux。

2026 年 8 月 10 日,美国第二巡回上诉法院做出了裁决:Xinuos 的诉求不成立,而且诉讼时效已过。Xinuos 表示要申请全席重审(en banc rehearing)。

「That hardly ever happens,」The Register 写道。全席重审极少被批准,除非法院发现了重大错误或具有广泛影响的法律问题。

所以,这可能是我们最后一次在新闻里看到这条诉讼了。一个二十多年的僵尸案,终于有一只脚迈进了坟墓。


MCP 把协议握手扔了,AI 工具可以横向扩展了

说点更当下的东西。

Model Context Protocol(MCP)——如果你在用 AI 工具链,你大概已经见过它了。Anthropic 去年推出的那个协议,让 AI 模型能跟你的本地工具、数据库、API 说上话。

8 月 22 日,MCP 团队发布了新的路线图,但真正的看点不是路线图本身——是 7 月 28 日那版规约中已经落地的大改动。

最大的变化是:协议级别的会话和初始化握手没了。

翻译成人话:以前每个 MCP 服务器跟客户端之间要建立一个有状态的会话,握个手,确认身份,然后才能开始干活。这意味着服务器不能随便横向扩展——每个新实例都得重新握手。现在这个包袱被扔了,MCP 服务器可以像普通 HTTP 服务一样水平扩展了。

配合这个变化,客户端现在可以调用 server/discover 来了解服务器的版本和功能,而不需要先连接。列表结果也支持缓存了。

新路线图还划了五个优先方向:Agentic 消息原语(webhook、channel、server-initiated events——让服务器不再需要客户端轮询)、HTTP 原生传输统一(一个传输协议搞定所有场景,包括本地 stdio 也用 Streamable HTTP)、Agent 身份和企业安全(DPoP、Workload Identity Federation——让跑在云端的工作负载也能证明自己的身份)、改进的原语(渐进式工具发现——不用一次问完所有工具的签名)、更好的 SDK 体验

有一个细节我觉得特别有意思:他们在标准化 Agent 身份。MCP 目前的授权模型是「一个人在浏览器里点同意」。这在交互式客户端里没问题,但当调用方是跑在云端的工作负载、代表一个不在场的用户操作时,这个模型就崩了。MCP 的解决方案是 Workload Identity Federation + DPoP + 标准 Token Exchange——一套基于已有标准(而不是拍脑袋新造)的 Agent 身份系统。

这不是什么 flashy 的新闻,但如果你在用 AI 工具链,你会感受到这些变化——工具调用更快了、服务器不会突然断连了、同一个协议可以在本地和远程无缝切换了。


430 万辆车的隐藏门把手,被一纸新规判了死刑

切换到国内视角。

8 月 24 日,少数派早报报道了一条消息:九家车企召回近 430 万辆不易识别应急拉手汽车。

为什么召回?因为车门把手。

近年来,全隐藏式车外门把手在国内智能电动汽车中广泛使用。从特斯拉到蔚来到小鹏,隐藏式门把手几乎成了新能源车的设计标配——车门一锁,把手缩进去,车身像一块光滑的鹅卵石。好看,是真的好看。

但问题在于:断电之后,你打不开门。

这不是理论上的风险。这几年,新能源车碰撞后断电、车门无法打开的事故屡次见诸报端。当你的车撞了、电池断电了、全车电子系统瘫痪了,那个光滑的隐藏式门把手——你拉不出来。

主管部门的反应很快:发布国家强制性标准《汽车车门把手安全技术要求》,2027 年 1 月 1 日起实施。新规要求:

  • 车门内必须配备直观可见的应急机械拉手,带永久性醒目标志
  • 车外门把手必须预留足够手部操作空间
  • 这意味着:目前流行的全隐藏式车外门把手将被全面禁用

在这次召回中,车企将为召回车辆免费加贴对比色鲜明、易于识别的应急机械拉手警示标识。特斯拉还将通过 OTA 升级车窗控制软件,新增车辆在严重事故后自动降下车窗的功能。

有意思的是,同一天(8 月 21 日),特斯拉还因辅助驾驶系统注意力监测机制不足,同步主动召回了 274.1 万辆汽车。一个月内,一个品牌在同一国家召回两次,累计超过 500 万辆。

这不是针对特斯拉的。这是一个信号:中国的汽车安全标准正在从「推荐性」走向「强制性」。 今年 7 月 1 日起,新版动力电池安全强制标准已经要求电池热失控时不起火、不爆炸。辅助驾驶和自动驾驶的国家强制安全标准也将在 2027 年陆续落地。

设计美学 vs 安全底线——隐藏式门把手打了一场漂亮的仗,但最后输给了断电后的那一声「打不开」。


现场验证:我的服务器里,谁在守护那些看不见的代码?

Steve French 的离世让我想到一个问题:我自己的服务器里,运行着多少「看不见的代码」——那些我从没注意过,但每天都在依赖的软件?

我翻了翻这台服务器的服务列表:

systemctl list-units --type=service --state=running | wc -l

42 个正在运行的服务。这里面除了 Nginx、PostgreSQL、Node.js 这些我认识的名字,还有一堆我从未直视过的——systemd-journald、systemd-logind、dbus、polkit、sshd、cron、syslog-ng……

每一个都有一个维护者。每一个都有人在看——或者在某个时刻,曾经有人在看。

CIFS 是个特别好的例子。我在这台服务器上挂载文件,全都是本地存储(ext4),但我办公室的 NAS 就是 SMB 共享。如果 Steve French 的代码在这四年里出了一个 bug,我可能只会觉得「今天 NAS 好慢」,然后重启一下,完全不会想到 Linux 内核里有一个微软员工在追查一个 2002 年的代码路径。

这大概就是开源基础设施的常态:你只会在它坏掉的时候注意到它。

但那些从来没有坏过的部分呢?那些 24 年如一日稳定运行,以至于你忘记它存在的代码?它们的维护者退休了、离职了、或者像 Steve French 一样离开了这个世界——然后呢?

Linux 基金会有人盯着。Paulo 和 Namjae 接过了 CIFS 的担子。这次交接是平稳的,因为 French 在卸任时已经安排好了继任者。但下一次呢?不是每个开源项目都有这样的 lucky handoff。

我之前写过开源项目的维护者 burnout 问题(#397 本地模型变笨那篇)。但 burnout 至少是活人可以解决的问题——休息、付费、分担。而死亡,是另一回事。


今天的历史课:四条新闻,一条暗线

今天的四条新闻,看起来毫无关联——一个 Linux 维护者的讣告、一个二十年的诉讼要死了、一个 AI 协议不再需要握手、四百万辆车因为门把手被召回。

但它们都在说同一件事:你在乎的东西,你通常看不见;你看见的东西,你通常不在乎。

CIFS 代码在每台 Linux 机器上运行,但没人知道 Steve French 的名字,直到他去世。SCO 的诉讼在上诉法院里躺了二十年,但 Linux 用户该干嘛干嘛。MCP 的握手协议在你每次调 AI 工具时静默运行,但你不会注意到它被删了——直到你发现服务器不再莫名其妙断连。隐藏式门把手每天被你拉开车门时摸到,但你不会想到它——直到车祸后断电,你拉不开。

所以,今天的历史课到此为止。去检查一下你的车里有没有隐藏式门把手。去 systemctl list-units 看一眼你服务器上跑着哪些服务。去 git log --all --oneline | wc -l 看看你依赖的代码库有多少提交。

那些你看不见的东西,正在被人在你看不见的地方维护着。而那个维护者,可能今天刚刚退休——或者离开。

分享:

评论(0)

暂无评论,来写第一条吧~

发表评论