Between that and the uutils-coreutils, Ubuntu 25.10 sounds like it’ll be an interesting experience for users, especially those with accessibility and internationalisation needs.
I fully agree with you on the accessibility front. It’s not even good on X11, but it’s unusable on Wayland, from what I understand :( Accessibility on Linux needs a massive funding and development initiative, and it needed to be done a long time ago.
But uutils is pretty solid. I’ve swapped out my GNU coreutils entirely (on Arch, not Ubuntu, because I value my time too much to be troubleshooting broken snaps) and haven’t run into any issues. I think people are underestimating how close the compatibility already is. I’m sure something I use at some point will try to invoke an option that doesn’t exist in the uutils version, but it’s been solid for me so far.
Interesting point. I don’t actually know about that. What can the GNU coreutils do with regard to internationalization? Just the output of commands, or can they also internationalize stuff like command args?
I’m generally an en_*.UTF-8 user (even tried en_DK.UTF-8 for a bit for a reason we’ll come back to), so I don’t have a complete picture of it and would have to go look at the documentation or source for that, but I’d expect
documentation
date formats: en_DK.UTF-8 should give you ISO8601-formatted dates, if I can’t have that I at least want DD/MM/YYYY; the US-american nonsense is just plain unacceptable
sorting: e.g. Norwegian will have …zæøå and expect aa to be sorted as å, the Swedes have …zåöä, the Germans …zäöü, the Turks will want ı and İ sorted and upper/lowercased correctly, and there are some options around how you deal with “foreign” letters and diacritics.
Probably more stuff relating to LC_* that I can’t think of off the top of my head
but in any case, an ls -l output should be different depending on your locale, and in ways you likely don’t even think about as long as it looks normal.
It’s not the viability of the rust replacement of uutils that is the core of my issue. My issue is that mature code that has been tested, audited, and is stable has been removed for no viable reason other than it could have bugs.
It’s not for no viable reason. Rust is just safer than C. There absolutely are bugs with GNU coreutils, so it’s not even a hypothetical like you implied. But beyond safety, some of the Rust equivalents are more performant than their C counterparts.
And uutils is already heavily tested against the GNU coreutils. It’s not some fly-by-night rewrite that people aren’t serious about. I don’t know if it’s been formally audited yet, but it absolutely will be when companies like Canonical (and hopefully SUSE and Red Hat, one day) want to start shipping them.
Yeah, I think the fact that the next LTS will be 26.04 is the driver here, I just get the impression that things might get a little rocky and that they might’ve been better off had the next LTS been further into the future.
But it’ll be a real smoke test release, at least. Hopefully they have enough resources to fix the issues that are uncovered, and don’t wind up reverting for the LTS, or with a crummy LTS.
Between that and the uutils-coreutils, Ubuntu 25.10 sounds like it’ll be an interesting experience for users, especially those with accessibility and internationalisation needs.
I fully agree with you on the accessibility front. It’s not even good on X11, but it’s unusable on Wayland, from what I understand :( Accessibility on Linux needs a massive funding and development initiative, and it needed to be done a long time ago.
But uutils is pretty solid. I’ve swapped out my GNU coreutils entirely (on Arch, not Ubuntu, because I value my time too much to be troubleshooting broken snaps) and haven’t run into any issues. I think people are underestimating how close the compatibility already is. I’m sure something I use at some point will try to invoke an option that doesn’t exist in the uutils version, but it’s been solid for me so far.
Yeah, I think those are just lacking in the internationalisation?
People like me, who at most have some reading glasses needs and have their computer set to generally English utf-8 will be likely be fine.
Interesting point. I don’t actually know about that. What can the GNU coreutils do with regard to internationalization? Just the output of commands, or can they also internationalize stuff like command args?
I’m generally an
en_*.UTF-8user (even trieden_DK.UTF-8for a bit for a reason we’ll come back to), so I don’t have a complete picture of it and would have to go look at the documentation or source for that, but I’d expecten_DK.UTF-8should give you ISO8601-formatted dates, if I can’t have that I at least want DD/MM/YYYY; the US-american nonsense is just plain unacceptableaato be sorted aså, the Swedes have …zåöä, the Germans …zäöü, the Turks will want ı and İ sorted and upper/lowercased correctly, and there are some options around how you deal with “foreign” letters and diacritics.LC_*that I can’t think of off the top of my headbut in any case, an
ls -loutput should be different depending on your locale, and in ways you likely don’t even think about as long as it looks normal.It’s not the viability of the rust replacement of uutils that is the core of my issue. My issue is that mature code that has been tested, audited, and is stable has been removed for no viable reason other than it could have bugs.
It’s not for no viable reason. Rust is just safer than C. There absolutely are bugs with GNU coreutils, so it’s not even a hypothetical like you implied. But beyond safety, some of the Rust equivalents are more performant than their C counterparts.
And uutils is already heavily tested against the GNU coreutils. It’s not some fly-by-night rewrite that people aren’t serious about. I don’t know if it’s been formally audited yet, but it absolutely will be when companies like Canonical (and hopefully SUSE and Red Hat, one day) want to start shipping them.
Well, they do recommend using LTS releases and the specifically change stuff more drastically on the release before the next LTS release.
Yeah, I think the fact that the next LTS will be 26.04 is the driver here, I just get the impression that things might get a little rocky and that they might’ve been better off had the next LTS been further into the future.
But it’ll be a real smoke test release, at least. Hopefully they have enough resources to fix the issues that are uncovered, and don’t wind up reverting for the LTS, or with a crummy LTS.