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

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).

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.

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.

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

Embrace the lock-in.

My solution was to stop using Ubuntu and move to Debian.

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

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.

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.

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.

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.

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.

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

"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds

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?

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.

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

Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi....

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)

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!

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?".

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?

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?

but it segfaulted in a memory safe way.

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...

  root@71a8c5a6c5e3:/# mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
  mkdir: File name too long
  root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
  gnumkdir: cannot create directory 'a/a/a/.../a/a': File name too long
  root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((3 * 1024)) | tr -d '\n')
  root@71a8c5a6c5e3:/# rm -rf a
  rm: cannot remove 'a/a/a/.../a/a/a': Directory not empty
  root@71a8c5a6c5e3:/# gnurm -rf a
  root@71a8c5a6c5e3:/# rm -rf a
  root@71a8c5a6c5e3:/#

And then they plan to move to a new Rust-based NTP. No comment...

You can use coreutils-from-gnu instead uutils. However since 26.04 build-essential depends on coreutils-from-uutils, it cannot be upgraded while coreutils-from-gnu is installed.

https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...

You can use equivs to create a dummy coreutils-from-uutils package, as mentioned in the responses to that report.

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.

You're specifically frustrated about unbounded stack recursion exhausting the stack, triggered by multiple thousands of directories? It doesn't sound like this is about multi-thousand-deep directory structures, it sounds like it's about something else.

Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.

This isn't the first issue with uutils.

Canonical is just rushing the switch because they want to get rid of software with GPLv3 license, not because there is any technical merit for doing so.

If they want the default to be non-GPLv3 Rust-based that's fine, but some of us don't care (and want the same behaviour everywhere, like on RH-based systems we may also have) and they should leave the GNU as an option. Potentially both could be installed at the same time (it's what update-alternatives is for after all).

For now you can list dependent packages manually in apt-get install: https://packages.ubuntu.com/resolute/build-essential

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.

genuine sudo

That made me curious, it sounds related to this:

Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords - 5 months ago (413 comments)

https://news.ycombinator.com/item?id=47464134

nah

i was referring to their counterfeit sudo emulator written in rust. It's called "sudo-rs" afair.

Was there something wrong with how they are currently written or do they just want the badge that says they converted to Rust?

License. GNU is copyleft and the new thing is permissive.

We might see a fracture open slowly. For me, even AGPL is not enough

Once they have a more permissive license, cui bono?

Businesses.

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.

Arduino,... are not GPL based

Arduino is "just" repacked gcc in a nutshell, so it is GPL-based.

You need more than a compiler, so it is complicated, and not pure GPL,

https://support.arduino.cc/hc/en-us/articles/4415094490770-L...

Neither. They basically see Rust as the future. They want to be able to attract young contributors and to hire young employees who are excited about Rust and who want the safety features. Bear in mind, the average age of the Linux developer is increasing. They also see technical benefits in Rust. And they are increasing test coverage of both the Rust tools and the tools written in C, IIRC.

My source is this interview with the VP of Engineering at Canonical on this topic: https://corrode.dev/podcast/s05e05-canonical/

Interestingly enough, young developers have no issues writing C or C++ when it comes to game development, Pebble, Arduino or ESP-32 coding.

Those are more expensive!

Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I looked at in detail had pretty bad performance or correctness issues.

[1] https://jackson.dev/post/rust-coreutils-dd/

The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.

I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources.

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.

Same here. Love Rust. Hate rust rewrites.

The worst thing about rust are the people using it.

My impression is that go developers moved to rust.

The reason for existence of uutils is ideological, not technical.

which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.

Rewrite it in anything that isn't GPL.

Are people saying that there's an ideology of pushing rust for things without concern for quality?

Yes, there is. There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe.

The original authors of uutils do not particularly care about licensing, and the Rust ecosystem defaults to MIT/Apache2. So they chose that.

Many people have decided that this decision supposedly specifically about licensing ideology.

You can make up your mind about which of the two you believe.

See also, for Ubuntu's take on this: https://news.ycombinator.com/item?id=49707948

Hmm, this doesn’t make sense. You simply don’t replace utilities with many decades of maturity and that “just work” with something that is not as mature. It will open all users of the distro to all sorts of subtle and not so subtle bugs. I for one don’t want to find myself staring at a mysterious segfault when I want to build the latest version of nodejs or flash a microcontroller. It’s such a pity; I have used Ubuntu for close to 23 years.

then install the other tool. no one is holding a gun to your head. it isn't windows.

on the other hand, Rust is memory safe!

So what is the way forward for Linux to have sandboxi g as strong as Android? Appimage everything? I know it's possible now hacking together things, but I mean by default and integrated.

Amutable. Building an immutable and image based system which even the installer can't modify, a-la macOS.

One systemd patch at a time.

I was bummed when I came across this: https://github.com/trifectatechfoundation/sudo-rs/issues/129...

I don't understand - I thought sudo-rs was supposed to be a drop-in replacement? If it implements a subset of features how can this be the case?

I don't think sudo-rs ever advertised itself as a drop in replacement. They seem pretty upfront that it isn't their goal. See this list:

https://github.com/trifectatechfoundation/sudo-rs#difference...

Whether you like Rust or not, it's questionable as to why Canonical would push this so much and do it in such a cavalier way.

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.

Canonical has been pushing its own agenda for ages, how many examples do you need?

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++.

It removes a GPLv3 dependency that might stop some companies from adopting Ubuntu Core.

> Will this really make coreutils more secure?

In the long run yes. Sure, many logic bugs happen in Rust programs as well, but memory safety bugs are another level of hell. At least many classes of exploits will mostly be impossible. Also, Rust program failures tend to be more predictable. For example, in C/C++, if you do out of bound writes in an array or writes in a freed memory block, the behavior is undefined. The program might crash, the memory might be silently corrupted, or nothing might happen at all. In a normal (non unsafe) Rust code these kinds of issues are either prevented by static checks or become explicit runtime panics.

While the migration could be done more gradually, 26.10 is not an LTS release and is not considered stabe enough. The next LTS is 28.04, so I hope there is 1.5+ years for things to stabilize.

new C++ STL standard makes it no more undefined.

Can you point to any outstanding, unfixable, memory safety bugs in the coreutils that justify such a rewrite? This is a cynical license issue, not a safety issue. I think there are much more severe security risks which come from behavior divergence of replacement tooling than memory safety bugs from 40 year old widely used/tested software.

Other distros are based of ununtu. Will the all ship with crippled coreutils from now on?

People still use ubuntu when Debian and Mint exist?

Yes, proprietary hardware support out of the box, and pre-installed option by the few OEMs that sell GNU/Linux computers.

My nvidia GPU worked just fine. Debian has non-free repo you know...

Nowadays the non-free-firmware repo is active by default, so the normal official debian image actually works.

It used to be the case that the normal download from the homepage was often useless because it didn't support most networking hardware, but this is no longer the case now.

How long ago was that? I tried Debian about 15-20 years ago and I don’t recall encountering that issue.

(The issue I do remember encountering was random kernel panics that I didn’t have with Ubuntu on the same machine.)

Debian packages are ancient, unless you use "testing", which will be broken. That being said, Ubuntu is horrible too. The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu.

If you ask their motivation? "We want to make them safer"

They worked pretty fine for decades, now, who needs these rewrites? Not saying it's useless, but in practice, what benefits did this bring?

it's GPL free. which is good for embedded, the business side of it. like cars.

The kernel is still GPL

but GPLv2

Good for car manufacturers, not necessarily for cars or their owners. As a car owner I quite like manufacturers to be forced to produce source code.

Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code..

[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.

"Stronger" is absolute bullshit. No data race prevention. No intra-object protection. Mandatory GC, and 5x the compute cost. Nothing like a statically safe language.

It's coreutils, there shouldn't be any threads to be data racing.

Haven't threads been one of the reason some core util got faster?

Only GNU sort uses threads. There is still some room for improvement there, if anyone wants to take a shot at it. :)

I would be very curious about a bit more concrete and substential criticism what is bad (or good) about how the both versions, that goes beyond general arguments like:

  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.

if the argument is "but bugs!" then that's a nothing burger. Your old code is more battle-tested, but that doesn't inherently make it better. I wish more companies thought like this.

ProTip: You can switch back to Gnu coreutils on 26.04 with:

apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential

And pin it so an upgrade doesn't flip it back with:

printf 'Package: coreutils-from-uutils\nPin: release a=*\nPin-Priority: -10\n' \ | sudo tee /etc/apt/preferences.d/uutils > /dev/null

Just curious, why the 'sudo tee {file} > /dev/null'?

Beware that rust coreutils on 26.04 currently has really bad performance with larger block sizes. Ganeti uses "dd bs=1M" as part of a disc image transfer pipeline, and with 26.04 performance dropped from ~350MB/sec to 30MB/sec, with the dd command CPU-bounded.

The issue seems to be that it is operating on partial buffers and then having to copy remainder of that 1M buffer around as part is consumed. Coreutils 0.11 solves that but 26.04 is at v0.8.

I've always used "bs=32k" because decades ago I did some testing and found that seemed to be large enough that it reduced the overhead while not being so large that it caused other problems, one of the most noticeable being scheduler issues where performance went into the toilet, especially on SD or USB thumb drives. Using this also seems to work better with rust coreutils dd.

Why are we still using dd?

Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.

I don’t know of a better tool that operates on raw blocks, maybe there is one.

`dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.

    cp file.iso /dev/sda

this works great but in my experience sometimes you should add

  && sync

not sure why it's necessary only sometimes!

This isn't portable though, it's a GNU-specific "smart" things. Elsewhere, this overwrites the target device file.