Oxidizing Ubuntu: adopting Rust utilities by default

Original Article ↗ Hacker News Discussion ↗

uutils Rust coreutils and compatibility

  • Commenters note uutils’ explicit goal: 1:1 behavior with GNU coreutils, treating any divergence as a bug.
  • Only the “production ready” subset (actual GNU coreutils, not util‑linux tools like more) is being adopted, which some argue many people are missing.
  • Others emphasize that despite the stated goal, the implementation is still incomplete and buggy; GitHub issues show many behavioral discrepancies and missing options, so it is not yet a true drop‑in.

Security, TOCTOU, and correctness

  • A TOCTOU check in uutils’ more is dissected: one side claims it’s a benign extra stat() for nicer error messages; another demonstrates a symlink race that exposes /etc/passwd.
  • This leads to the conclusion that the original more is “vulnerable” in similar ways, so the extra check mainly affects error reporting, not core safety.
  • More broadly, some argue memory safety is not crucial for short‑lived, non‑networked CLI tools; others respond that utilities can end up in networked contexts or complex pipelines, so safer implementations still matter.

Licensing, copyleft vs permissive, and “attack on freedoms”

  • A large subthread debates whether moving from GPL coreutils to MIT Rust equivalents undermines user freedoms.
  • One side sees permissive licensing as a “corporate workaround” to avoid GPL reciprocity, warning about loss of strong copyleft at the base of systems and citing concerns about vendors like Red Hat or Oracle.
  • The opposing view: coreutils are a commodity; BSD‑style userlands (e.g., macOS) show permissive licenses don’t doom ecosystems; GPL’s “viral” nature can also discourage adoption and contributions.
  • Several participants stress that companies sometimes build proprietary alternatives rather than accept GPL, while others counter that even partial or probabilistic contributions under permissive licenses are better than “100% of nothing.”

Canonical/Ubuntu trust and history

  • Many commenters distrust Canonical’s motives, given past decisions (Snap by default, search/terminal ads, ZFS licensing stance). Some see this move as “ulterior motive” licensing games, not neutral modernization.
  • Others argue Canonical likely has solid legal advice (e.g., on ZFS) and that courts care about actual harm, not abstract license purity.

Rust as a technical choice (safety, leaks, and tooling)

  • Rust’s memory safety is praised, but a long side discussion notes that Rust can still leak memory (e.g., via ownership patterns, Rc/Arc cycles, arena‑style Vec patterns), and that the borrow checker doesn’t magically prevent space leaks.
  • Some argue leaks are at least no worse than in GC’d languages, and Rust’s strictness plus a strong compiler makes large refactors and even LLM‑assisted coding safer to review.
  • Others report current LLM‑generated Rust tends to be verbose, misuse clone/collect, and mishandle Result, requiring experienced Rust developers to clean up.

Value of rewrites vs stability

  • One camp calls this “the worst kind of busy‑work”: rewriting mature, battle‑tested tools without adding features, thereby injecting new bugs.
  • Another emphasizes maintainability and future evolution: Rust is more pleasant and safer for new contributors than aging C, and uutils is already adding small UX features (e.g., progress bars).
  • There’s disagreement over whether performance or resilience will measurably improve over highly optimized GNU C code.

Labor and economic interpretations

  • A provocative comment claims Rust rewrites are a deliberate corporate tactic to devalue C/C++ expertise and replace seniors with cheaper juniors.
  • Replies largely reject this as conspiratorial: full rewrites are expensive and risky; skill obsolescence and language churn have always been part of software; if juniors can match seniors in C++ using safer Rust, that’s an argument against C++, not for gatekeeping.

Sandboxing, Wayland, and “security theater”

  • Separate from coreutils, some tie this change into a broader frustration with recent Linux desktop “security” trends (Wayland, Flatpak/Snap): broken drag‑and‑drop, flaky clipboard, macro restrictions, blocked AppImages.
  • Others defend application sandboxing as analogous to iOS/Android permissions: conceptually sound, though current UX and ecosystem smoothness are poor.