OpenBSD 開發者拒絕 uutils coreutils 提案 （★ 30 分）
OpenBSD 的第三方軟體套件樹收到 uutils coreutils 提案。uutils 是以 Rust 程式語言重新實作 GNU Core Utilities（GNU 常用命令列工具組）的計畫；提案預計以 gcat、gls、gcp、gdate 等 g 字首名稱提供工具，這些名稱會連至 libexec/uutils 內同一個多功能執行檔，並與既有的 GNU coreutils 套件互斥。提案者希望讓需要 GNU 相容工具的其他套件不必修改原始碼，便能改用 uutils。
OpenBSD 創辦人 Theo de Raadt 與資深開發者認為，這項提案沒有足夠理由納入。OpenBSD 基礎系統本已提供採 BSD 授權、行為彼此協調的工具；再放入另一套採 MIT 授權（寬鬆型開源授權）、卻在細節上略有差異的替代品，可能破壞指令稿與管線流程。舉例來說，ls 的輸出若被 sed、cut 等工具以非標準但長期可用的方式解析，替換其中一項工具後，輸出格式、結束狀態或邊緣行為的差異都可能造成難以追查的問題。批評者也指出，uutils 的單一多功能執行檔架構不符合 OpenBSD 傾向個別工具各自封裝的慣例，任何一項工具異動都可能得重建與散布整組套件。
報導將爭議延伸至 Rust 與授權取向：uutils 已通過大部分 GNU coreutils 測試，且 Ubuntu 26.10 預定採用它，顯示其成熟度逐漸提高；不過 OpenBSD 對基礎系統新增 Rust 工具鏈仍持保留態度，考量包括龐大的相依範圍、多種硬體架構的自我建置需求，以及長期維護成本。文章推論，OpenBSD 使用者短期內仍會以既有的 GNU coreutils 套件取得 GNU 相容命令，而非採用 uutils。
Hacker News 討論者普遍認為，這篇報導過度聚焦 Theo de Raadt 的尖銳措辭與「Rust 議程」，卻弱化了實際的套件維護理由。有人指出原始郵件串的核心是：OpenBSD 已經得保留 GNU Core Utilities，才能建置許多其他第三方套件，因此再維護一套替代品的效益有限；Rust 其實已在 OpenBSD 的第三方套件中有一定存在感，反對的並非一概排斥 Rust，而是它不適合目前的基礎系統條件。討論者也批評報導疑似誤讀電子郵件引述關係，並在 2026 年的討論脈絡中使用了 2024、2025 年的 OpenBSD 版本時程，使其可信度受質疑。
討論中另有兩項重要爭點。一方認為 Rust 的記憶體安全特性可作為 C 與 C++ 的較安全選擇；另一方則指出，語言本身無法排除所有設計與邏輯缺陷，uutils 的相容性、維護負擔與漏洞風險仍須以實際成果檢驗。有人還提到 uutils 曾在發行說明中承認部分貢獻含有 GNU GPL（GNU 通用公眾授權條款）程式碼或註解，後來已重寫處理。至於 Theo de Raadt 的作風，意見同樣分歧：有人把強硬拒絕視為保護技術決策的必要手段，也有人認為不必以敵意溝通，否則會損害開發圈的參與意願。
👥 31 則討論、評論 💬
https://news.ycombinator.com/item?id=49951648