Carefully but Purposefully Oxidising Ubuntu

Concerns about Rust coreutils in Ubuntu’s model

• Several argue Rust-based coreutils fit better in rolling distros (Debian unstable, Gentoo, Alpine) than in Ubuntu LTS, given Rust’s rapid evolution and typical “use rustup” expectations.
• Worry that fundamental tools in an end‑user distro used by non-technical people shouldn’t be swapped without at least a full optional/beta cycle.
• Counterpoint: the article’s oxidizr tool already makes switching opt‑in and reversible, effectively enabling wide beta testing.

Rust toolchain stability, MSRV, and editions

• Skeptics cite Rust’s fast-moving ecosystem and fear breakage across Ubuntu releases, especially if upstream regularly bumps the Minimum Supported Rust Version.
• Others answer that Rust editions are designed for long-term compatibility; most changes are non-breaking, and edition-specific conditionals in the compiler are still few.
• One view: as long as each Ubuntu release picks a Rust toolchain that can build the chosen Rust coreutils, this is manageable.

Security and suitability of coreutils for “oxidation”

• Some question whether ls, chown, chgrp, etc. are significant security risks; they’re typically run by the current user on their own files, with limited attack surface.
• Others point out past CVEs and tricky inputs (weird filenames, terminal escapes, long names), but agree Rust doesn’t automatically fix POSIX design issues.
• A long tangent notes that many vulnerabilities are rooted in standards and shell semantics, not just memory safety.

Performance and rewrite motivations

• Multiple commenters say performance is rarely the primary Rust rewrite rationale; memory safety and tooling are more common.
• Examples like ripgrep show that new designs can be dramatically faster than old tools, but the speedups are attributed to algorithmic work, not Rust itself.
• Fil-C is suggested as an alternative path to safer C, with some discussion of its current overhead and when tools are actually compute-bound (e.g., sort on in‑RAM data).

Licensing, GNU/RMS, and copyleft

• Some explicitly welcome less GNU/RMS software; others defend the GNU/Free Software framing and criticize “open source” as business-friendly dilution.
• A detailed comment about uutils suggests a major motivation is providing a permissively licensed (MIT) drop-in replacement for GPL coreutils, with industry users caring about GPL compliance.
• Several see Ubuntu’s Rust move as part of a broader trend away from copyleft, potentially easing proprietary reuse.

Canonical’s track record and distro choices

• Historical experiments (dash as /bin/sh, Upstart, Mir, Unity, Snap, Bazaar) are cited as examples of Canonical’s “can’t leave things alone” behavior.
• Snaps and ads in logs/motd are strong negative signals for some; they’ve moved servers and desktops to Debian or Arch and express general distrust of Canonical’s motives.
• A minority defend parts of that history (e.g., Unity, Upstart) as technically good but politically outcompeted (systemd, GNOME).

Practical gaps: locales, architectures, integration

• uutils currently lacks full locale support; commenters doubt a mainstream distro can switch without that, and expect adding locales later will be non-trivial.
• Rust toolchains exist for most Ubuntu arches (x86_64, ARM, ppc64le, s390x), though edge-arch support still raises questions.
• Some criticize introducing oxidizr instead of reusing Debian’s alternatives system, which already integrates tightly with apt.
• One concern: if reverting is too easy, there may be less pressure to fix Rust tools; others think easy rollback is exactly what users need.

Strategic focus: what to “oxidize” first

• Several argue that heavily battle-tested C coreutils with few CVEs are low-priority for rewriting; newer, less-audited C/C++ code is a better target.
• There’s a reminder that Android’s experience suggests rewriting old, widely depended-on components carries large compatibility burdens, including reproducing non-critical quirks.