GNU coreutils 的跨平台 Rust 重写

原文 ↗ Hacker News 讨论 ↗

一个长期存在的、用 Rust 重新实现 GNU coreutils 的项目，随着其兼容性测试套件如今已通过大多数 GNU 测试，重新引发了关注。评论者权衡了潜在收益——内存安全、更清晰的现代代码、更容易的交叉编译，以及避免 GPL 义务的宽松 MIT 许可证——与对项目寿命、细微不兼容性，以及非 GPL 重写是否削弱 copyleft 目标的担忧。该项目被认为尤其适合 Windows、macOS 和嵌入式环境，但许多人怀疑它短期内会在主流 Unix 系统上取代 GNU coreutils。

项目目标与状态

  • uutils 是一个已有十年历史的 Rust 项目，目标是成为 GNU coreutils 的跨平台、可直接替换的替代品。
  • 与 GNU 行为的差异被明确视为 bug；共享测试套件显示，如今通过的测试数量已显著多于失败的测试。
  • 几位评论者提到“最后 10% 会花掉 50% 的时间”，并预计人们会等到几乎完全一致后才会把它作为系统默认工具。

采用情况与使用场景

  • 许多人怀疑传统 Unix/Linux 发行版短期内会切换，原因是 GNU coreutils 有 30 多年的记录并且无处不在。
  • 也有人看到明确的利基场景：macOS（避免使用非常老旧的 BSD 工具）、Windows（WSL/虚拟机/ Cygwin 要么别扭、要么慢、要么被禁止）、嵌入式系统，以及像 NixOS 这类让替换 coreutils 变得容易的环境。
  • 在某些环境下，Rust 的交叉编译被认为比 C 更简单。

Rust vs C：安全性、可维护性、性能

  • 支持 Rust 的论点包括：内存安全、更好的整数/UTF-8 处理、更强的工具链，以及比“古老、简短、聪明”的 GNU C 源码更现代、更容易接近。有人表示，将嵌入式/机器人代码迁移到 Rust 后，现实中的 bug 大幅减少。
  • 怀疑者指出，coreutils 的严重 CVE 很少，而且多半不是内存问题；在这里，他们认为逻辑/语义 bug 比内存问题更重要。
  • 也有人担心与 BusyBox/Toybox 和纯 C 相比，二进制体积和可移植性。

许可：MIT vs GPL

  • MIT 许可证是一个主要争议点。
  • 批评者认为这是试图摆脱 GPL 的“病毒性”，使公司能够集成并扩展核心工具而无需共享修改，同时也是更广泛、令人担忧的远离 copyleft 的趋势的一部分。
  • 支持者则认为，宽松许可证更利于采用，反映了既有实践（许多关键组件本身就已经是 BSD/MIT/Apache），而且 GPL 义务（尤其是 v3/AGPL）对公司来说确实是负担。
  • 关于 copyleft 是否真的能为用户和小公司带来更好的结果，以及企业为何不愿在 GPL 下贡献，线程中存在来回争论。

合法性与清洁室顾虑

  • 一些人质疑，一个与 GPL 授权的 coreutils 一比一对应的 MIT 重写，是否真的独立，提到了此前发现的复制标识符名称，以及很难保证“没有人看过”的问题。
  • 另一些人强调，独立重实现是合法的；清洁室是抗辩理由，而非要求，并指责这种怀疑是在散布 FUD。
  • 总体法律状态在讨论中存在争议，但尚无定论。

更广泛的思考

  • 讨论还涉及项目寿命（Lindy 效应论点与对这种推理的批评）、历史上以体积优化为主的 C 与现代可读性之间的权衡，以及将此类项目作为对 Rust 是否适合作为系统工具“新 C”的压力测试。