Next.js Hacker News
Ubuntu 25.10 Replaces GNU Coreutils with Rust Uutils
28 points by donnachangstein 5 hours ago | 19 comments
  • JonathonW
    This reads like AI spew, and it's also not news (the post announcing this initiative [1] is from March).

    [1] https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...

  • lionkor
    That's the worst idea I've seen in a while. People rely on the behaviors of the GNU coreutils, this is going to break a lot of stuff. The uutils are not there yet at all.
    • whatagreatboy
      I think this is a good experiment. 25.10 is not an LTS, people who want stability are using LTS anyway.
      • TickleSteve
        Correct me if I'm wrong but the next LTS will be 26.04 which would give them 6 months to get maturity and stability... For such an important set of utilities, that seems unlikely.
    • turtleyacht
      If this rewrite is indicative of other rewrites, we'll see a license change from GPL [1] to MIT.

      "Differences with GNU are treated as bugs." - https://github.com/uutils/coreutils#goals

      That's promising. Wouldn't it be annoying though, to have to keep things bug-for-bug compatible on a green-field project? That priority may be the first compromise, and divergence is inevitable.

      (If few report edge cases and there's no fuzzing.)

      [1] https://github.com/coreutils/coreutils?tab=GPL-3.0-1-ov-file

    • matheusmoreira
      And one day people will rely on the behaviors of other things. There's no reason those things can't be these Rust utilities, they just need feature parity. Hopefully they will surpass their GNU equivalents. They'll probably be easier to contribute to as well.
  • polycaster
    > The replacement will affect more than a hundred utilities that are part of Coreutils

    …

    > Last week, the issue of the package uutils coreutils 0.0.30 successfully passed 507 tests (in the last issue of 506, in a year old – 476) from the standard GNU Coreutils test set.

    If I’m reading this right then there are on average only one to five tests per utility (like cat, dd, …) which is a shockingly low number. Particularly when you consider how many options a single command alone might accept. And of course, this alone would not even remotely cover a critical part of all the circumstances that might vary.

    • miohtama
      Many of those were written in 80s, testing was not a thing.
      • polycaster
        Yes, I remember. It still shows me how I overestimated the maintenance work distributors do / can do. My unreflected expectation was that in the past 40 years test were developed to secure the very foundation we keep on building on since then.
  • tuananh
    Does GNU coreutils have that many CVE?
    • carlmr
      I wouldn't say many, but not none: https://app.opencve.io/cve/?vendor=gnu&product=coreutils

      The question is rather how many are logic bugs and how many are memory safety bugs, Rust excludes the latter quite well, which according to the MS and Google Studies makes up about 70% of programming mistakes in their C++ codebases. However rewriting carries the risk of introducing new logic bugs. So There's a tradeoff here.

      I am a big believer in Rust, I basically only use rg instead of grep and fd instead of find and never looked back, but they are slightly different in behavior, so not a drop-in replacement. I'm not sure if porting coreutils will be so useful in the end, since if you do all the workarounds for the rust version to behave like the C version, maybe you won't have the performance benefits or the clean codebase that you set out for in the end. I like the rg and fd approach much better. It's an almost drop-in with huge performance benefits.

      But let's see if they succeed.

  • temp0826
    Does this fix something specific with coreutils (is there no way to upstream patches?)? Or is it that rust is supposed to save us from some class of unknowns (related to memory safety?)?
    • diegocg
      The world is slowly but steadily going to replace non memory safe code by memory safe code (no matter how people feel about it). This is just part of that.
      • flumpcakes
        It seems like replacing code that has been written and used extensively for decades with a complete rewrite without a real need is more of a risk to me. Perhaps the uutils are 'simple' enough not to be an issue though.
        • diegocg
          Replacing non memory safe code is good. Rewrites are unstable at first, then time passes and bugs are fixed and is no longer that
        • carlmr
          I think the simplicity is maybe why this is a good first experient. I think we can learn from it, more than it being useful on its own.

          A lot of code will need to be replaced by memory safe code in the future, but a lot of code is not so easy to replace as something like this.

  • black_13
    [dead]