$ podman run --rm -it ubuntu:26.10
$ apt update -y; apt upgrade -y
$ rm --version
rm (uutils coreutils) 0.10.0
$ gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
$ rm -rf a
Segmentation fault (core dumped) rm -rf a
$ ls a
a
$ gnurm -rf a
$ ls a
ls: cannot access 'a': No such file or directoryUbuntu 26.10 completes transition to Rust-based coreutils (omgubuntu.co.uk)
collinfunk 18 hours ago
teekert 18 hours ago
collinfunk 17 hours ago
teekert 17 hours ago
jeffbee 17 hours ago
collinfunk 17 hours ago
To get a response on a buggy GNU coreutils patch of theirs [1], I had to mention it in a rust-coreutils bug months later...
[1] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/215...
jabl 2 hours ago
Maybe the bugs get traction if you have a service contract?
Best to file bugs directly to upstream, but that of course means you should try it on the latest upstream version and not whatever version ubuntu ships, so it's more friction.
mixmastamyk 17 hours ago
The fix is still sitting unmerged many months later.
This surprised me since I thought the project was in heavy bugfix/compat mode. I won’t touch it until I see some velocity on open bugs.
baq 2 hours ago
Only half joking.
yjftsjthsd-h an hour ago
tjoff an hour ago
LtWorf 2 hours ago
Symbiote 2 hours ago
There's a whole load of basic bugs reported and ignored:
rwmj 29 minutes ago
amelius 17 hours ago
0x696C6961 8 hours ago
cute_boi 4 hours ago
petre 3 hours ago
voakbasda 3 hours ago
tancop 2 hours ago
Flatpak uses shared stable runtimes that are the same everywhere and don't take up space more than once. It also comes with a native update system and sandboxing. Snap is the same thing but worse.
ChocolateGod an hour ago
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
suby an hour ago
ChocolateGod an hour ago
LtWorf 2 hours ago
I haven't tried chromium but I presume it's the same issue.
At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox.
At least in the past few months the dbus crashes (been using systemd on debian for several years just fine, this never happened) that render the system unusable and un-rebootable have stopped… I guess when my company will decide to upgrade to 26.04 there will be more instability and problems.
zelphirkalt 40 minutes ago
tjoff 3 hours ago
It will die so just leave it alone.
dark-star 17 hours ago
secondcoming 17 hours ago
gpm 17 hours ago
Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
abirch 17 hours ago
dfox 17 hours ago
LtWorf an hour ago
7bit 17 hours ago
secondcoming 17 hours ago
gpm 17 hours ago
That's also not all that's happening. It's also making improvements like better internalization support, better error messages, and a small handful of other extensions.
collinfunk 17 hours ago
mrkdkirlwkfkf 4 hours ago
tosti 15 hours ago
IshKebab 15 hours ago
tosti 15 hours ago
gpm 14 hours ago
[1] https://github.com/rust-lang/rust/issues/112788
[2] https://github.com/rust-lang/rust/issues/153827
By-default guaranteed tail calls really isn't rust's style, because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. If you want to guarantee that a call can't allocate a new stack frame you should have to say it.
lioeters 14 hours ago
But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
gpm 14 hours ago
I'd argue that it's explicit - that's what a function call does and you don't have implicit function calls in rust.
> Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same.
What you're asking for here already exists. Tail calls might be optimized into not allocating extra stack frames, the rust compiler just doesn't guarantee that it will perform that optimization (and almost certainly won't when code is compiled without optimizations... for instance).
What people want is the semantic guarantee that the stack frame won't be allocated. Not just a compiler that often performs the optimization. Otherwise you can't be sure that your code will keep working with new compiler flags/versions/architectures/... You could say "whenever the code is the right shape we'll guarantee the optimization" (C++ famously did this for things like copy elision)... but now the shape of code comes with non-obvious semantic guarantees and that's not rust's style. Hence the proposal for a keyword instead.
lioeters 14 hours ago
clhodapp 4 hours ago
jmalicki 5 hours ago
No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
gpm 5 hours ago
jmalicki 4 hours ago
afdbcreid 4 hours ago
jmalicki 3 hours ago
The whole idea of "let's change semantics to make it easier" is dumb.
If you want guaranteed tail calls, change your code until it works.
IshKebab 11 hours ago
gpm 11 hours ago
For recursion only kotlin.
(For most of these only with syntax specifying it)
ploxiln 4 hours ago
8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB!
Ygg2 15 hours ago
nh2 2 hours ago
Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety.
Every time you call something recursively you should be thinking "how deep is this?".
BHSPitMonkey an hour ago
hulitu 3 hours ago
geokon an hour ago
IshKebab 15 hours ago
lynx97 3 hours ago
froh an hour ago
barbarkaragul 35 minutes ago
znpy 4 minutes ago
erminpour 2 hours ago
Will this really make coreutils more secure? I doubt it, if anything there will be a river of new bugs.
So, again, why are they pushing Rust so much? Having Microsoft make Rust a 'Tier-1' language also doesn't bode well.
pjmlp 39 minutes ago
Microsoft making Rust tier 1 is great, it means probably one day we get a VS proper support instead of VSCode only.
If you head off to Microsoft official blogs, you will find out that Microsoft already has tier 1 support for Java (ironically), Python and Go, besides the usual .NET languages and C++.
Malakun 17 hours ago
https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...
collinfunk 16 hours ago
It is frustrating that Canonical has no interest in fixing it, though. It makes it hard to take their claims seriously that you can still use GNU coreutils if you want.
dwattttt an hour ago
Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.
egorfine 16 hours ago
But it's clear that Ubuntu will remove coreutils, genuine sudo and other tools from the future versions. It's the direction, it's ideological and thus nor merit nor our feedback will change anything here.
lioeters 14 hours ago
That made me curious, it sounds related to this:
Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords - 5 months ago (413 comments)
egorfine 13 hours ago
i was referring to their counterfeit sudo emulator written in rust. It's called "sudo-rs" afair.
lioeters 13 hours ago
Security issues discovered in sudo-rs - https://lists.debian.org/debian-security-announce/2025/msg00...
Sudo-Rs Affected by Multiple Security Vulnerabilities - https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10
Sudo-rs enables password feedback by default - https://www.phoronix.com/news/sudo-rs-password-feedback
Arcuru 16 hours ago
egorfine 16 hours ago
stouset 15 hours ago
There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs.
By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.
egorfine 15 hours ago
noosphr an hour ago
LtWorf an hour ago
pjmlp 29 minutes ago
I would appreciate Go much more otherwise.
pjmlp 31 minutes ago
Also for Rust based rewrites, they could start by bootstraping Rust compiler itself, dependent on C++ to start it.
They don't do it, because even though LLVM and GCC are written in C++, a pure Rust compiler would not scale to the same level of contributions, and existing capabilities.
tcfhgj 8 hours ago
estebank 16 hours ago
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
Surac an hour ago
suby 32 minutes ago
sehw an hour ago
LtWorf an hour ago
Ubuntu does offer some certifications but only for paying customers, so everyone else should really steer clear.
pjmlp 37 minutes ago
SubiculumCode 3 hours ago
uecker an hour ago
bayindirh an hour ago
One systemd patch at a time.
hexfish 25 minutes ago
t0duf0du 2 hours ago
werdl 39 minutes ago
Alien1Being 20 minutes ago
atoav 15 minutes ago
Just because it is Rust, it is not safe!
It worked before, don't replace it!
etc.
Not that these are not valid points of criticism, but in my opinion if we have two core utils we can (and should) pick the better one after careful continous evaluation. And if the old one is the better one on the day of the release, so be it. Having two competing solutions can have benefits for everybody looking for the best core utils they can get in the long run.I had to reimplement and reverse engineer old tech myself as part of my dayjob and had those engineers seen my results it probably would have improved their work as well, since I usually found oddities that they probably did not intend to be that way. This means my work on their work could be seen as another pair of eyeballs, bullet-proofing their original work, instead of seeing me as a threat. That additional pair of eyeballs is crucial to open source software.
This is why it is sad that too much about this whole discussion feels like yet another culture war, heated on the stove of social media figures looking to convert heat into ad revenue.
Which is why I would love to have more concrete points of technical criticism of specific bits maybe even to specific lines in the code or specific reproducable behavior.
If we go the culture-war route nobody wins, if we discuss both solutions on their merits, we all can win.
arjie 3 hours ago
hk1337 17 hours ago
01HNNWZ0MV43FF 5 hours ago
We might see a fracture open slowly. For me, even AGPL is not enough
zahlman 4 hours ago
pjmlp 2 hours ago
There is a reason all FOSS OS alternatives for embedded systems like Zephyr, NuttX, FreeRTOS, IDF, Arduino,... are not GPL based, while Google has purged Android and ChromeOS from it, with the Linux kernel being the only GPL piece left.
Flimm 3 hours ago
My source is this interview with the VP of Engineering at Canonical on this topic: https://corrode.dev/podcast/s05e05-canonical/
uecker an hour ago
pjmlp 27 minutes ago
dsign 4 hours ago
someothherguyy 4 hours ago
nairboon 3 hours ago
overfeed 15 minutes ago
nalekberov an hour ago
They worked pretty fine for decades, now, who needs these rewrites? Not saying it's useless, but in practice, what benefits did this bring?
froh 43 minutes ago
justincormack 29 minutes ago
rwmj 25 minutes ago
grougnax 2 hours ago
asrk-qlwu 18 hours ago
WatchDog an hour ago
[0]: https://fil-c.org/.
[1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-per...
* Guaranteed to crash rather than potentially grant arbitrary code execution.
quotemstr 28 minutes ago
logicchains 19 minutes ago