I really don't understand why Canonical rushes this. If 'rm' can't remove all possible directory entries, that is a big issue:
$ 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 directory
I tried switching a buildroot based CI server to the 26.04
One Makefile statement triggered a bug in rust ln:
In parallel build, we would get random failure:
Rewrote that Makefile to work-around it, and ended up with the same kind of bugs with parallel $(INSTALL) -D ...
Tried latest ubuntu 26.10 which supposedly fixes a lot of TOCTOU races in rust coreutils, but no better.
Gave up and switched back to original coreutils.
but it segfaulted in a memory safe way.
sarcasm detected here :D
I don't think this is a sarcasm, as a long standing Rust user myself, I don't think the community should preach out by "memory safety" -- rather the structural change in coding mindset and new ideas such as ADT and generic programming, while retaining mostly zero-cost like C++ without the bearing of C++ complexity (that includes a compiler that spits out 300 lines of compiler error just because I missed one <).
Memory safety is just what Rust inherited from C++ smart pointers with a stronger linear/affine type system twist, especially regarding move semantics, cloning and borrowing rules. What makes it powerful is the various language features it also incorporated from Cilk/C#/OCaml/Haskell.
Right now Rust and Zig is my two favourite middle ground. It is sad that Zig went completely sod-off-to-LLM mode but the most devastating aspect of Zig is that it is way too Linux focused. A lot of the code in Zig I cannot compile on Windows, plus the major changes to IO interface and the colorless function fiasco is really making me question the stability of Zig.
This recent event led me to displace Zig and replaced it with Nim, which emits C code instead and having a really powerful algebraic language system, while getting some benefits of Rust such as scoped smart pointer (I think they call it ORC), or using simple mark and sweep arena collector or even full-blown Boehm GC.
Right now I'm trying to create a distribution of Nim in a single binary (with musl and mingw packed together) and using tcc as the backend, all in a single binary with Rust and an internal project to convert wasm 3.0 and wasi proposal 1 modules into Rust code, which the Nim compiler and TCC are both compiled to WASIp1 first, then term-rewritten/transpiled to Rust (think w2c2 or wasm2c, but targets Rust, I found some nice structuralism of Rust and wasm lately)
What new ideas? Standard ML features from 1983?!
Rush? This is an interim release (95% or so only tracks LTS's) that is not even out yet... Go file a bug reports if you have some time.
I have. It has been an open bug upstream for years as well.
ok, that's concerning, if you post it here I'll vote for it (after confirming).
The Launchpad bug is https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu... .
The apparently related bug in the origin project is https://github.com/uutils/coreutils/issues/2949, filed back in 2022 and which sat unmoved for several years until, probably not coincidentally, almost the same time yesterday that this appeared on Hacker News.
Reporting bugs before Ubuntu releases has never worked for me. They always land a bunch of major changes after the supposed "freeze" then they ignore all feedback because of the freeze. It's infuriating.
Glad to hear that I am not alone. I feel like launchpad is totally ignored most of the time.
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...
I've been a Ubuntu user for about 20 years, and I file bugs every now and then on launchpad. I don't recall any of them ever being fixed.
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.
Upstream for much is Debian, but of course Ubuntu forks from testing, and then modifies...
But if you can identify it as a bug in a version in Debian, that's a good place to file, as Ubuntu will get the fix eventually.
Reporting bugs _at all_ in Ubuntu has never worked for me.
I did, and the original dev of the component fixed it within a few days. It was straightforward, a backwards reading of a spec, reordered.
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.
Fork Ubuntu and threaten their business model, that’ll get their attention.
Only half joking.
Ubuntu is the fork; just use Debian.
There are plenty of Ubuntu forks?
There's very little incentive to switch. When people release for Linux they almost always first/only test it works on Ubuntu - hence it's going to be the least buggy. (ex: GOG only seemingly tested games on Ubuntu)
So the switching cost is buggy software. You'd need something radically different that brings enough new features to the table to make it worth it the switch and dealing with bad/non-existant support.
I think something like Nix/Guix but with stable library versions that matches Ubuntu/Debian LTS ones 1-to-1 could get traction
Then you would have to embrace their bad decisions, such as this one, and if you do, what’s the point?
Everything just needs to run from a container with their expected runtime environment.
[flagged]
If you still have toes, take some morphine and reload.
My solution was to stop using Ubuntu and move to Debian.
And in that debian install rust unix coreutils as default
My experience is that filing bug reports to ubuntu is a complete waste of time. Not sure if it's different for paying users.
The bug report I filed several months ago hasn't been looked at. Many of these utilities were released and made the default for Ubuntu 26.04 LTS!
There's a whole load of basic bugs reported and ignored:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils
They eventually fixed the one where it didn't sort properly, but it tooks months: https://github.com/uutils/coreutils/issues/12253 https://github.com/uutils/coreutils/issues/12912
This is certainly not just affecting interim releases. Ubuntu 26.04.1 has been released but is currently held back from do-release-upgrade for the LTS channel (which IIRC is unusual for a LTS's .1 release) due to rust-coreutils issue:
> Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils.
https://discourse.ubuntu.com/t/ubuntu-26-04-1-lts-released/8...
This is what made me move away from Ubuntu. Use LTS and encounter issues with outdated packages? "Well duh, you're supposed to upgrade to interim releases if you need remotely up to date software". Use interim releases and encounter bugs? "Well duh, it's an interim release. Of course it's a buggy mess, nobody uses those"
Every Fedora release is intended to be solid and they come out twice a year.
I moved to Fedora from Ubuntu about a year ago for my laptop. My main motivation was not be defaulted to snap packages. I have had a great experience i.e it gets out of the way and it doesn't fall apart when I update stuff. I was worried about SELinux but find Fedoras defaults just fine and intuitive.
Keep using it, there's tons of bugs for you to find in Fedora.
My favorite was a system-upgrade that installed broken video drivers, as recently as late 30x releases.
The 26.04.01 upgrade LTS is delayed from it too, not just interim releases.
https://lists.ubuntu.com/archives/ubuntu-announce/2026-Augus...
> Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils.
It's entirely aisine and makes me avoid Ubuntu every time it is possible. And it is repeated offence, Ubuntu always tried to push the envelope in worst place and way possible
Let them first fix Snap.
They need to kill snap ...
Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.
I'll avoid it at this point anyway. The Rust coreutils is another reason for that. Snap, monetizing updates, telemetry, enough is enough.
Yup. After almost 20 years, I have had enough of their crap. All of my new machines are getting Debian. Can’t wait until I am free of Ubuntu.
Appimages are bloated and unreliable. You can't guarantee that your app will run on any machine because it might depend on different system libraries.
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.
> Snap is the same thing but worse
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
My problem with flatpak is that the underlying runtime has a limited lifespan. I used the Sublime Text 3 flatpak for many years, and it was deprecated a few months ago because the runtime it was using was no longer supported. This caused people to update the flatpak to Sublime 4, which is good, but I only have a license for 3. In the end I just downloaded the binary for 3 from their website, and it still just worked. Flatpak still doesn't save you from bitrot.
There's a project called "anylinux appimages" that aims to make the most compatible appimages. They also use DwarFS for faster opening and smaller file sizes.
See: https://pkgforge-dev.github.io/Anylinux-AppImages/
> Flatpak uses shared stable runtimes that are the same everywhere and don't take up space more than once.
https://pkgforge-dev.github.io/Anylinux-AppImages/disk-usage...
Also flatpak runtimes are NOT stable, they do nonsense like this: https://www.reddit.com/r/linuxquestions/comments/1pwgdwb/gpu...
AppImages do not work anywhere close to how macOSs .apps do, and even if they did the approach isn't correct for how things work on Linux.
I think ubuntu wants to kill desktop linux. No other explaination of why they push firefox inside snap, which then proceeds to constantly crash, when firefox used normally works completely fine.
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.
Firefox installed as a snap feels sluggish to me. When I install a Ubuntu system, the first thing I do is to uninstall any snap and install the apt versions of things, possibly adding official PPAs or using Guix to install software.
why bother with ubuntu at all ? If you want ubuntu but without snap out of the box, Zorin is 1 option. Or if you also hate gnome, linux mint.
Indeed. Thought not in all cases I can decide what OS to use. An employer might prescribe which one to use. And any distro will be better than being forced to use Windows.
sandboxing a browser makes total sense. my firefox and chromium running as snaps never crashed a single time for as long as I can remember, and I use both every day, at the same time.
Both have performance issues when installed as snaps across my 24.04 and 26.04 machines.
I sandbox with firejail. There is no reason to use snaps. Also in firejail I never experienced a crash.
> never crashed a single time
I'm very happy for you. How does that help the people who do encounter issues?
Browsers literally sandbox their own tabs.
And the entire Linux user space is already sandboxed by design. This is why you type sudo.
If os and software developers actually designed with the Linux filesystem in mind, there would be no need for Flatpaks and Snaps and AppImages.
There's a whole directory for user applications and their libraries.
/usr
> I haven't tried chromium but I presume it's the same issue
No issues with snap Chromium.
Thanks to snap I've learned of Librewolf. Couldn't install non snap Firefox, so just got ff fork instead.
Also, after a system update all PPAs (including Librewolf) got turned off, so I went like a year without updating the browser. Fun stuff.
Also, snap is now partially fixed. It used to take all your drive space with old versions of snaps. You needed a special script to remove them automatically.
Now there's no more than 2(?) old versions of snaps anytime. Progress!
But not to complain too much, Ubuntu still kind of works. I moved my laptop to Fedora, and almost did it with the desktop, but learned of Librewolf. Should probably remove the fedora root and home at some point. Don't remember any issues that were not caused by me (other than snaps). Compared to Windows with it's auto updates when you need PC for sth critical, ads everywhere and this annoying way of installing software not from terminal and having to update it manually separate from system updates. Ubuntu did a lot for Linux, maybe more it's community than canonical, but it will always have a place in my heart.
It is a good idea, unfortunately poorly executed.
There is no reason for anyone on any distro to use snap.
It will die so just leave it alone.
It can fail blazingly fast!
Am I the only one cynical enough to feel physical pain when I see “blazing fast” in a README? It’s like a dog whistle for “hey everybody, I’m kinda annoying!”
Not pain but annoying fly.
But this is totally not a memory ownership bug! It's some other kind of bug!
It is Year of the Linux Desktop, not Year of the Linux Cli.
to enable GPL free embedded Ubuntu, field tested on all platforms (because it happens to be the default).
yeah, this is a bug. And yes, it should be fixed. But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?
That way of thinking just means it'll never be fixed
Nah, people should (and do) fix small issues as well as big issues. Lying about the scale of issues and calling them "big" when they aren't just leads to no ability to prioritize or evaluate.
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)
Because Collin reported it in Ubuntu too :)
"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds
The problem there is that this is exactly the class of bug that does not exist in GNU coreutils because of philosophy of that project. Non-existence of such bugs proves that the impementation is not copied from AT&T code.
It's complicated to do it yourself when upstream won't accept your code.
What approach would you suggest for priorisation of tickets?
Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.
This isn't a port - it's a re-implementation without any use of the original source.
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.
I have had to tell them repeatedly to stop copying tests verbatim, including the original comments from GNU coreutils. So I doubt this is true, which is frustrating.
What's wrong with them using the coreutils tests?
If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.
> and you can't include GPL code in a MIT licensed project without making it GPL.
Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.
But you should be able to use a GPL test suite on an MIT-licensed program (or even a proprietary one, without the program needing to be under the GPL.
Ehh... Technically yes but when you don't own the copyright on the tests you need to be very careful against creating derivative works, and you need to preserve both licenses in the distributed source.
Capitalism.
What programmer or programming language can't iterate a loop more than 32000 times?!
It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that far away:
https://lwn.net/Articles/1035727/
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]).
[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.
Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? 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.
But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
> implicitly creating new stacks
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.
I see it, certain algorithms need guaranteed tail-call elimination, otherwise they are too inefficient and must be manually unrolled or rewritten to avoid blowing the stack. So a compiler optimization that is "nice to have" is not good enough.
No algorithm requires tail-call elimination in a general-purpose language with imperative mutability. It's just another way to express iteration.
Sure, but mutual recursion might require `goto` for example. Or an explicit state machine.
I can see how it might require an explicit state machine (keep a mutable state number and switch over the inlined bodies of what could be functions), but I'm not seeing how it could require `goto`.
Are there more-complex relationships that might require it?
I meant it more in the sense that “you need one or the other” rather than “some cases require one and some other cases require the other”.
> because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it.
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.
Uh, yes, if you guarantee the semantics only when the code explicitly opts in and not by default then semantics will not subtly change, that is the point of my comment
It's not a change in semantics of compiled code. It is only a change of whether or not the code will compile.
Guaranteeing an optimization that otherwise only might run is a change in semantics. The attribute doesn't allow (in any sensible language) the code to simply not compile because the optimizer doesn't feel like it today (or you compiled with -O0), it forces the compiler to not allocate a stack frame wherever the code fits the structure that makes that definitely possible and fails to compile wherever it doesn't (even if after other optimization passes it happens to fit a structure that makes it possible).
Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi....
That's not implementing tail calls breaks things, that's bad design of implementing tail calls breaking things.
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.
Do any widely used languages guarantee tail call optimization? It's a pretty niche feature.
Scala, ocaml, racket, clojure, zig.
For recursion only kotlin.
(For most of these only with syntax specifying it)
How interesting. I'd seen LISP(y) implementations like Scheme guarantee tail-call since recursion is a very common technique in that language family. But I didn't know Zig supported it.
https://ziglang.org/documentation/master/#call
They have an @call built-in that guarantees: always/never tail, as well as always/never inline. That's neat, I can see how that would be useful in various situations.
JavaScript too, but only implemented in JavaScriptCore, so basically just Safari and Bun.
Depends on how widely we consider Scheme and Raket adoption in CS curriculum.
I don't think that's related? The bug alluded to looks something like
and no amount of tail call optimization will save you here, because this isn't tail recursion. Of course you could rewrite it using an explicit stack + tail recursion, but then you might as well be using a while loop.
So it's enumerating all the subdirectories first and unlinks the tree afterwards?
I get that this isn't transactional and inherently prone to race conditions, but if this is indeed the problem, it's rediculous. A single while loop could do the job correctly and use less RAM. It'd probably also be faster. But that wouldn't be a rusty thing to do?
I look at code from the heirloom project and, despite its warts, I think we've lost something in the past 45 years or so.
> A single while loop could do the job correctly and use less RAM. It'd probably also be faster. But that wouldn't be a rusty thing to do?
No, the "single while loop" is just harder to implement than a naive recursion, because recursion is a natural way to implement tree traversal. With a while loop, you need an explicit stack, which is more complex.
(A stackless traversal seems unrealistic here, as getting the succeeding node would be too expensive. Not that I've tried...)
> I look at code from the heirloom project and, despite its warts, I think we've lost something in the past 45 years or so.
I've just tried and heirloom rm segfaults on the same test too. Which is no wonder, seeing how that code also recurses.
(It's mentioned somewhere else in the thread, but this is exactly the reason why GNU had to specify "no hard limits" as a policy. Unix used to be full of such bugs.)
Thank you for clearing that up. Good points!
8MB is the default per-thread stack size from glibc, also seems to be the default "ulimit" from pam or the kernel, I'm not sure. So for the main/default thread (or if not using threads) the process can use setrlimit() and for threads it can use pthread_attr_setstacksize() to get bigger stacks if it knows it may need them.
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!
8MB is huge compared to the stacks we used to have when address spaces were 32-bit, but it's tiny compared to how much memory we can actually make use of now. The only real argument I can think of for having such a small stack is that large stack usage is often indicative of an infinite recursion bug and it catches them earlier.
But I don't really buy that for the same reason most programming languages don't limit loops to 8 million iterations (or whatever) by default - it would make catching infinite loop bugs easier!
I say most, because I know of at least one language that did do that - QuakeC! It made lots of sense in that context though.
When triaging an issue you have to prioritise. Do you fix a problem that affects 2-3 people or one that may affect thousands?
The point is that such bugs shouldn't exist in the first place.
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?".
> The point is that such bugs shouldn't exist in the first place.
That's true of every bug, but you don't have infinite time or manpower, so how do you prioritise?
By that logic, why even spend effort migrating from a known-working implementation to one which is known to have outstanding bugs that there isn't enough bandwidth to fix?
Fashion.
Hard to say, but there are legitimate reasons. One of which being they think Rust is growing while C is a shrinking language. Other could be safety (yes, yes the audit did surface bugs). Or even that having a single lib work seamlessly on Windows/Linux/MacOS/Redux/Web.
Rust ? Because of ... memory safety. /s
It's less about the specific issue and more indicative of bad/insufficient test coverage
> But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?
When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?
AI agent needs , rust memory safety , wasm , parralel task
from a ground-up rewrite, in a memory safe language i expect at the very least
- A meaningful error
- not a segfault
And that’s why i keep ubuntu far from my computers…
I mean, that should work... but you can see why that would be considered low priority right?
Their strategy is basically adopt now, hey now we’re forced to fix it! And it’s disgusting. Frankly, I don’t know how any enterprise users on Ubuntu will be able to forgive this. Well, many businesses are on RHEL and not Ubuntu anyways…
Wow! Memory safety and such... Reminds me when a friend of mine wrote in IRC long time ago: "Hmm, tail just segfaulted." When I asked "Are you on Hurd?" he just replied "Yes."
Hi, this is not a one bug.when the change app flags not working or not happening. I was measured with bsd and busybox.
Ubuntu is free. But Canonical is for profit. In these cases "if you are not paying for the product, you are the product" applies.
Ubuntu users will test this. Once the problems are ironed out, other distros will follow.
While I supported that idea of Rust coreutils, this your experiment showed me how bad it is. My results are totally different, but not what I expected (edited out long strings of "a/a/a" for brevity). I wouldn't call it stable...
And then they plan to move to a new Rust-based NTP. No comment...
I wouldn’t judge the ntpd-rs move from this. Have been running it for 9 months or so with a nts pool in ntp server mode on my pi5. Been rock solid.