from Hacker News

Carefully but Purposefully Oxidising Ubuntu

by wicket on 3/13/25, 1:39 PM with 107 comments

  • by burntsushi on 3/13/25, 3:09 PM

    I mentioned this on reddit, but AFAIK, the uutils project doesn't yet support locales: https://github.com/uutils/coreutils/issues/3997

    I'm not any more a fan of POSIX locales than the next person[1], but AIUI, that seems a likely requirement for uutils to be used in a distro like Ubuntu.

    I'd be curious how they plan to address this. At least from my perspective, unless uutils has already been designed to account for locales from the start (I don't know if it has), it seems likely that a significant investment of time will be required to add support for it.

    [1]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

  • by larsnystrom on 3/13/25, 1:57 PM

    > Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change.

    Is performance a frequent rationale for rewriting C applications in Rust?

  • by glitchc on 3/13/25, 1:55 PM

    Are there any security vulnerabilities in ls, chgrp, chown etc. that requires this change? Or this just more Rust evangelism?

  • by Spivak on 3/13/25, 3:54 PM

    Why oxidizer over the existing Debian alternatives system? It's designed for this exact use case and already works with many existing packages. The author's response in the comments was a basically a non-answer which doesn't exactly inspire confidence.

    > Long-term, my concern would be that this may somewhat muddy the picture for which packages need substantive fixes. If it is extremely easy to just revert, what is the benefit to switching?

    ??? Is this not the ideal situation? It provides low friction both for moving to the new cool thing and moving back to the existing tools when you have software that hard depends on GNU coreutils. You want the changeover to be high risk because it's hard to undo? I guess that's one way to force yourself to commit but the real users on the ground won't be happy when going to the LTS is substantially more work.

    This would be 3 different symlink managers in Ubuntu all used for different sets of software. The alternatives system at least has the benefit of integrating tightly with apt.

  • by vimarsh6739 on 3/13/25, 6:19 PM

    To me, this feels less about Rust and more about moving away from copyleft.

  • by lproven on 3/13/25, 2:29 PM

    I am curious -- I asked on Discourse as well...

    How this will work on CPU architectures other than x86 and Arm? Ubuntu also supports ppc64le and IBM s390. Is LLVM usefully able to built binaries from Rust code for those architectures now?

  • by pizlonator on 3/13/25, 2:14 PM

    I think that all of those tools can be recompiled with Fil-C today and you get memory safety while retaining the original functionality.

  • by xiphias2 on 3/13/25, 3:17 PM

    While changing the core packages as a rewrite looks easy (,,just reimplement ls''), compatibility/stability may mean reproducing all the tiny but not safety critical bugs as well.

    There's enough data from the Android ecosystem that it's much better to focus oxidisation on new software instead of old.

  • by _ink_ on 3/13/25, 2:12 PM

    Please fix fractional scaling first. The performance is still bad.

  • by amiga386 on 3/13/25, 1:57 PM

    Snaps were the first shot across the bow. This is another. Switch to Debian before this happens.

  • by superkuh on 3/13/25, 1:48 PM

    Porting of stable tools to an unstable (rapidly changing) language which can only successfully compile projects if the distro toolchain is rolling (or constantly updated outside of repos every few months, ala curl|sh, rustup, etc). Ubuntu is not a rolling distro. This is a bad match.

  • by Y_Y on 3/13/25, 1:51 PM

    How about Ubuntu just sticks to their area of competency repainting Debian.

    Remember when the switched they shell to dash? Not to mention, Upstart, Mir, Unity, Snap.

  • by blankx32 on 3/13/25, 2:31 PM

    We can’t leave things alone

  • by Kwpolska on 3/13/25, 2:12 PM

    On the one hand, having less RMS and GNU software in the world is better.

    On the other hand, I'd prefer for basic system tools to be provided by an established and well-funded project, and not just switch to something written in Rust because Rust is the hype these days.