uutils/coreutils 很容易被看成一个简单的“用 Rust 重写”故事。仓库介绍的是 GNU coreutils 的跨平台重新实现，项目文档也把 uutils 放在 Linux、Windows、macOS 和其他平台通用命令行工具的框架里。[3][4] 这个描述准确，但观看 FOSDEM 2026 演讲《Rust Coreutils in Ubuntu: One Troll, One Argument, One Answer》时，它仍然算不上最有解释力的入口。更值得采用的读法是，uutils/coreutils 是一场公开的 Unix 命令行为审计，Rust 是实现语言，兼容性才是真正交付的东西。[1][2][3]
Coreutils 算不上耀眼的基础设施。它们是 cat、cp、date、ls、mv、rm、sort、stat、tail，以及几十个被脚本当作背景物理规律使用的命令。GNU 手册记录了 GNU core utilities 9.11 版本，也展示了这个表面有多宽：文件输出、目录列举、基础文件操作、权限、时间戳、进程控制、数值操作，以及更多内容。[5] 当 Ubuntu 尝试替换这一整片表面时，真正有风险的问题不在于 Rust 能否编译出快速的二进制文件，而在于 shell 脚本、软件包构建、维护任务和人的操作记忆，是否依赖了一些从来没有被明确命名的行为。[2][5][6]
先看第一步：意识形态之前的兼容性
观看时第一条有用的笔记，是这场演讲并没有真正把论点放在旧 C 代码有问题、新 Rust 代码天然更好上。FOSDEM 页面把这场分享放在 Ubuntu 试图把 Rust Coreutils 带进发行版时发生的事情之中：隐蔽行为、Essential 软件包风险、基准测试声明，以及让维护者在 GNU 与 Rust 实现之间切换的工具。[2] 这个框架很重要，因为 coreutils 替换不能靠偏好来推动。它必须经得起软件归档库、用户脚本，以及那些在任何人打开调试器之前就已经运行起来的沉闷命令的接触。
uutils README 也用项目语言把同一层约束写得很明白。它的目标包括匹配 GNU 输出和退出码、把差异视为 bug、改进错误消息、支持 UTF-8、提升性能，并在多种平台上运行。[3] 对观看者来说，核心短语是“把差异视为 bug”。这会把项目从一片空地上的克隆，变成一本行为账本。每个缺失的 flag、古怪的诊断信息、意外的时间戳格式、locale 边缘情形或文件系统竞态，都成为兼容性发现，而不再是理念分歧。[3][5]
这也解释了它为什么适合放进 OSS 的 Annotated Viewing。演讲位于上游雄心和下游问责的交汇处。作为开源项目，uutils 可以快速推进；而 Ubuntu 要问的是，这份输出是否已经足够安全，可以承担默认操作系统角色。[2][6] 把这段视频当作发行版工程案例来观看，它的价值最高；把它当作编程语言争论来观看，反而会错过主要内容。
中段谈的是那些没人签过字的契约
观看进入中段时，可以留意 FOSDEM 摘要中暗示的实践例子：依赖奇怪 flag 的脚本、预设了某种命令行为的软件包，以及只有在正确性足够接近之后才真正有意义的基准测试。[2] 这些都不属于库意义上的 API 契约。没有一个整洁的语义化版本接口，专门说明“每个构建脚本到底期待 date 做什么”。然而契约确实存在，因为生态系统一直在运行它。
GNU 手册说明了这件事为何困难。它不只是 POSIX 基础项的短清单。它记录了通用选项、命令特定行为、标准符合性，甚至还记录了 coreutils 多调用形式，同时提醒可移植脚本默认不要依赖这一形式。[5] 标准行为、GNU 扩展、历史习惯和可移植性警告混在一起，正是 uutils 必须穿过的地带。一个替代品可以拥有更好的内存安全性，却仍会因为漏掉某个软件包维护者、CI 任务或安装器安静依赖的细小行为而在运行层面出错。[3][5][6]
Ubuntu 在 2026 年 4 月的更新让这一点变得具体。它描述了安全审查流程、外部审计、上游协作，以及 Ubuntu 26.04 中的部分默认启用；其中 cp、mv 和 rm 仍保留 GNU coreutils，因为截至 2026 年 4 月 22 日，关于检查时刻到使用时刻的剩余风险仍未关闭。[6] 这里的教训很清醒：现代化是一串经过审查的替换，远远超过一次性换旗；安全敏感和文件系统敏感程度最高的工具会得到特别严格的检查。[6]
审计改变了“完成”的含义
对一个较小的命令行工具来说，“完成”可以意味着已经实现、写好文档、发布并打包。放在 uutils/coreutils 上，“完成”必须带有更严厉的含义。命令要在 stdout、stderr、退出状态、选项解析、错误措辞、locale 行为、文件系统语义和构建系统预期上足够匹配，让用户感知到破坏缺席本身。[3][5] 这个指标并不光鲜，却是这里真正起作用的指标。
项目文档给出了这个雄心的简洁版本：用 Rust 编写的通用命令行工具，覆盖主要平台，并生成用户文档和开发者文档。[4] GitHub README 又补上了直接替换的目标，并说明所有程序都已经实现，同时部分选项或行为仍有差异。[3] 把这些说法同 Ubuntu 更新一起读，这个项目就不像一次已经完成的重写，更像一场已经进入真实部署的大型兼容性行动。[3][4][6]
也在这里，演讲标题变得有用起来。《One Troll, One Argument, One Answer》指向了围绕 Rust 迁移的噪声，但严肃的答案是流程。兼容性焦虑要靠测试、审计、真实软件包构建、issue 跟踪、上游修复和回退路径来回应。性能焦虑要在正确性可以衡量之后回应。安全声明则要把语言层面的内存安全，同具体命令里的竞态条件、权限行为和文件系统边缘情形分开处理。[2][6]
最后一段应该带走什么
看到最后，观看者对 uutils 是否以一句口号“赢过” GNU coreutils 的兴趣应当下降。更有用的问题，是这次替换尝试揭示了既有系统的什么。它揭示出日常命令就是基础设施 API。它揭示出发行版默认用户层不只是一个软件包选择，也是它同每个脚本和软件包之间的契约，因为那些脚本和软件包都预设这些命令会以特定方式行动。它还揭示出，开源现代化的成功来自上游和下游把含混的信任转化为具体测试、审计和发布门槛。[2][3][5][6]
uutils/coreutils 的重要性在于，它把那份看不见的契约变得可见。这个项目用 Rust 编写，但它的主要工程产物不只是 Rust 代码。它也是一张不断扩展的地图，标出兼容性实际要求什么。由此，FOSDEM 这场演讲即使对没有强烈 Rust 立场的人也值得观看。它是一则关于替换基础软件的案例研究，提醒人们“同一个命令名”与“同一套系统行为”之间还有很长的验证距离。[1][2][3][6]
来源
- FOSDEM，《Rust Coreutils in Ubuntu: One Troll, One Argument, One Answer》，YouTube 视频。
- FOSDEM 2026，《Rust Coreutils in Ubuntu: Yes, we rewrote /bin/true in Rust - Here's what really happened》，活动页面与录像链接。
- uutils/coreutils，GitHub 仓库 README。
- uutils Coreutils Documentation，“Introduction”。
- GNU Project，“GNU Coreutils 9.11” 手册。
- Ubuntu Community Hub，“An update on rust-coreutils”，2026 年 4 月 22 日。
- Benjamin Bellamy，“Fosdem 2026 - 15.jpg”，Wikimedia Commons 照片。