Rewriting essential Linux packages in Rust

Original Article ↗ Hacker News Discussion ↗

Rusty replacements for classic tools (ripgrep, fd, etc.)

  • Multiple comments praise modern Rust CLI tools (ripgrep, fd, eza, bat, erdtree) and use them as drop-in replacements in shells.
  • Debate centers on whether ripgrep should be installed by default:
    • Pro: better day-to-day UX, can coexist with grep.
    • Con: it is not POSIX grep; base systems should ship the standard, boring, scripting-compatible tools.
  • Some argue POSIX compliance is overrated; others say compatibility with existing scripts, docs, and user knowledge is crucial for base utilities.

Platform support and portability

  • Rust (via LLVM) does not support all obscure architectures Linux supports, though many such platforms are barely tested for coreutils either.
  • Discussion distinguishes “it compiles” from real support (tests passing, tools actually working).
  • Rust4Linux is separate from GCC Rust frontends (gccrs), though they communicate.

Complexity and ergonomics of core utilities

  • Reimplementing coreutils in Rust is described as complex even with high-level stdlib support.
  • Some want more “human-friendly” filesystem tools (e.g., human-utils, richer new/mov commands) instead of just bug-for-bug clones.
  • Example of mdadm being rewritten in Rust to avoid root-only limitations when inspecting RAID metadata.

Dependencies and supply-chain risk

  • Concern over uutils having 200–300 Rust dependencies; “left-pad” is used as shorthand for supply-chain fragility.
  • Others note crates.io prevents exact left-pad-style unpublishing, but acknowledge malicious-code risk is real.
  • Tools like cargo vet and cargo audit are mentioned, yet skeptics say tooling cannot detect intentional backdoors.
  • Debate over whether many small crates improve quality via reuse/review or bloat the attack surface and pull in unused, risky code (xz + systemd example).

Rust, security claims, and adoption

  • Presenter’s quotes about Rust being “obviously” good for security/parallelism and “almost certain” portability are met with skepticism; overconfidence is seen as a security risk.
  • Some C/C++ developers describe Rust as overhyped, hard to integrate into existing workflows, and slow to adopt due to team inexperience and cargo/build issues.
  • Others see Rust projects as additive, not a replacement for the current C ecosystem, at least for now.

Licensing: GPL vs MIT for core utilities

  • Strong thread arguing that rewriting GPL coreutils as MIT (e.g., uutils) undermines copyleft protections that keep core infrastructure user-controlled and resistant to proprietary lock-in and TiVoization.
  • Critics worry corporations can adopt permissively licensed replacements, add DRM or “secret sauce,” and never contribute back, using them specifically to avoid GPL obligations (e.g., car vendors).
  • Counter-arguments:
    • MIT/BSD are “more free” for both individuals and companies; developers often prefer them and dislike GPL’s obligations and legal complexity.
    • Long-lived projects gain protection from many copyright holders, not just copyleft; permissive projects like OpenBSD are cited as examples of stability.
    • For userland tools, some see GPL as less critical than for kernels; maximizing portability (Linux, BSD, proprietary UNIX, Windows) is cited as a reason to choose MIT.
  • AGPL and GPLv3 are discussed at length (TiVoization, SaaS, “freedom 0”), with disagreement over whether AGPL remains “free software” and how effective any copyleft is in modern SaaS/device contexts.

Motivations and politics around uutils

  • One long comment reviews an interview where the maintainer says the project is not primarily about security and claims not to care much about licensing beyond “OSI-compliant.”
  • However, they reportedly avoid reading GNU source to stay clear of GPL contamination and explicitly support users who want non-GPL coreutils (with car manufacturers given as an example).
  • Critics interpret this as an intentional strategy to displace GPL foundations with permissive clones under a security/modernization narrative.

Other concerns

  • Some worry that Rust’s toolchain size and heavy dependency graphs are a poor fit for minimal or embedded systems that currently use busybox/toybox.
  • A few point to historical rewrites (e.g., Perl Power Tools) as precedents, and express interest in collecting Rust idioms/reusable patterns for porting classic Unix tools.