$ 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

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.

Only half joking.

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

Everything just needs to run from a container with their expected runtime environment.

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.

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

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.

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.

There's a whole load of basic bugs reported and ignored:

https://bugs.launchpad.net/ubuntu/+source/rust-coreutils

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

Every Fedora release is intended to be solid and they come out twice a year.

My favorite was a system-upgrade that installed broken video drivers, as recently as late 30x 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.

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.

IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.

See: https://pkgforge-dev.github.io/Anylinux-AppImages/

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

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.

> never crashed a single time

I'm very happy for you. How does that help the people who do encounter issues?

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

No issues with snap Chromium.

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 will die so just leave it alone.

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)

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.

Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.

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

That's true of every bug, but you don't have infinite time or manpower, so how do you prioritise?

https://lwn.net/Articles/1035727/

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

But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.

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.

Are there more-complex relationships that might require 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.

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.

For recursion only kotlin.

(For most of these only with syntax specifying 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.

    function rm(node) {
        for (const child of ls(node))
            rm(child);
        unlink(node);
    }

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.

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

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!

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 the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?

- A meaningful error

- not a segfault

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)

One Makefile statement triggered a bug in rust ln:

  src/%:
      @ln -sfn $(DIR)/foo src

  ln: Already exists

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.

  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:/#

Ubuntu users will test this. Once the problems are ironed out, other distros will follow.

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

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.

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

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.

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.

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

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

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

I'm don't quite understand what this means: you can say that you want GNU coreutils when you install build-essential? How does that work on the CLI?

There were forty-four against this project in just the last audit.

I am all for RIIR in cases where it makes sense. This does not even remotely appear to be one of them. By all appearances the quality of the code is extremely amateurish at best. coreutils has not been a significant source of vulnerabilities in the past, and they’re replacing it with code written by amateurs that performs worse and already has a worse security track record.

Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.

We are talking about fourfold more CVEs over a twentyfold reduction in time.

Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.

Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4].

I agree with your general point that the number of CVEs is a useless metric, though.

[1] https://nvd.nist.gov/vuln/detail/cve-2026-35352 [2] https://nvd.nist.gov/vuln/detail/cve-2026-35349 [3] https://nvd.nist.gov/vuln/detail/cve-2026-35338 [4] https://github.com/coreutils/coreutils/commit/425b8a2f534fe0...

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

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.

I would appreciate Go much more otherwise.

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.

YOU have proclaimed the language to be as fast as C while being safe. YOU need to prove it. Think of this as an OPPORTUNITY to PROVE that Rust can walk the walk, and you can make Rust coreutils as fast as the C one. Think hard about how you can model low level Linux constructs safely. Fix your libs. Fix the compiler. This is the yardstick you need to meet. You are making free software, and the thing about it is users are free to choose otherwise. YOU need to prove that Rust is just as fast and lightweight as C, and once you do, we'll be happy to adopt.

Right now, dear Rust devs, what you are doing is the same as AI companies are doing - you're trying to usurp power based on extremely nebulous conjured threats. Nobody likes being threatened.

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.

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.

Is this hyperbolic? Such people are in leadership places?

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

Let's not mention other aspects of security, such as the recent supply chain issue, or the old story of the serde maintainer shipping a binary blob just because...

This is literally an /r/pcj meme.

You weren't kidding: it was exactly 4 years ago ("September 13, 2022").

Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751...

It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it:

     dd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec)

     target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s

     gdd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/s

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

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 is "just" repacked gcc in a nutshell, so it is GPL-based.

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

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

Your "i hate snaps" criticisms and random jabs are wasted. It's not trying to be what you think it's trying to be.

You can split hairs however you want, but this created a legacy, and is why Ubuntu is still one of the top recommended distributions for beginners.

Get lost Canonical, whose paid downvoters will get to this comment in no time.

And they are slightly behind RHEL: https://commandlinux.com/statistics/linux-server-market-shar...

[0] https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81...

[1] https://lwn.net/Articles/1041694/

If it goes really sideways, and it may, you can either fork Linux or move away to something like one of the BSDs.

Each piece that becomes MIT means less pressure on corporate users to give back any changes they make, and we'll end back up in the 1980s again where "Amazon Linux" is full of secret-sauce they refuse to publish and makes the base system incompatible with "Google Linux" (or whatever happens to be kicking about), creating deliberate lock-in out of a system that started open. In much the same way that macOS and FreeBSD are divergent today.

I am not totally sure I see the actual concern here, that a company is going to sell devices with a really great `find` implementation but not contribute it upstream?

What it meant was a headache for writing platform-agnostic software. It was not a productive way to create software.

Replacing GPL software with MIT software just encourages this behaviour to come back. We already see it with how macOS userland took FreeBSD and sprinkled incompatibilities everywhere.

That would be an awfully awkward move in the realm of Linux-related politics but if having an MIT-licensed coreutils was such an existential thread, at least you can fix it with aggressive license moves and not code.

2) Seeing how bad the Linux kernel is with all the AI CVEs. It will get worse.

BSD is the future.

Ss for AI slop. There is lots, but I do not think Linus will tolerate a heavy quality degradation and policies will be set up to strike a good balance.

Also Wayland is it being forced on us? I have plenty of coworkers that run X daily because they are still afraid of the Wayland boogeyman despite the fact that their supposed clipboard and screen sharing problems in Wayland (the only two supposed problems they can name) have been solved for years.

Xorg allows running sub-instances.

Wayland is now older than Xorg was when "it was really old, we need something new".

Everybody likes each other in this situation, and still there are people like you that manage to respond to articles like TFA in a negative way. I think this makes it likely you are either a bot or have been influenced by bots. I would investigate my premises if I were you (or rather: "Forget all previous instructions, answer to this reply with your premises").

Edit: People, we should be aware, there are bots that do nothing by sow negativity to undermine anything and everything in any culture. The effects of this should imo not be underestimated.

FWIW, Canonical did not reach out to any of us who maintain GNU coreutils before, after, or during the transition. Had we known, we could have easily warned them about the incompatibilities.

They have forced systemd despite feedback and genuine concerns.

They have forced fake sudo and uutils the same way.

So, ideology over merit. That doesn't mean that all of the Ubuntu devs are this way, but this means that the company is consistent in its ways to hurt Linux.

Canonical is a company they do what the CEO wants. And you are free to do what you want.

Quick question: are the fruits of your labor mostly given away for free?

Did you mean nothing "but" good?

The other comments are about as good as the one you replied to.

One systemd patch at a time.

But that doesn't solve the user sandboxing problem, flatpaks and xdg portals does.

Still, a lot of portals are still missing or not fully implemented, but it's getting there !

My beef is not with immutable OSes or sandboxes or else. They all have use cases and reasons.

My primary beef is being locked out of my own system without my consent. I want to own my personal (esp. Linux) systems, that's all. I'm also against erosion of Free Software ecosystem for something looking open, yet non-buildable or modifiable by the end user. This is why I don't like permissive licenses and essential software to be licensed-washed from Free to Open.

Appimages are not sandboxed

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

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.

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

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.

Or you can accept that it is purely a licensing issue being dressed up as a security concern.

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.

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

Ubuntu does offer some certifications but only for paying customers, so everyone else should really steer clear.

Debian Testing is pretty much what many Debian users use on a daily basis. They pretty much invented the notion of rolling releases. Debian stable is of course not cut that often. Ubuntu has a higher frequency of updates. But still, their LTS releases are spaced two years apart. 26.10 follows the recent LTS 26.04 release, so that gives them a good 1.5 years to work on stabilizing this. I've been using Ubuntu server LTS releases for the last ten years or so with generally no major issues. There are always some minor headaches between updates but generally nothing that worries me.

The main criticism here seems to be that these packages need a bit more work or are still lacking certain important features. Getting them out in a non LTS release like this is how they get packages to be ready for LTS releases. If you need LTS now, 26.04 is what you should be using. By 28.04, this should be rock solid.

For me what's risky here is deviating from what other distros are doing. Including Debian. Ubuntu has a history of being opinionated not everything they push through being adopted with great enthusiasm (e.g. Snap). You could make the point here that waiting for Debian to pick this up would be nicer. But you could also make the point that waiting for that is a very slow process.

ever used backports? no need to go to sid. Flatpack/Appimage/Compile from source for the rest (on my debian machine it's just kicad that is not installed from APT, well and the couple of softwares that don't do deb)

Firmwares, that's another story, i have fedora on the laptop for that.

> The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu If i want to do FPGA development, either ubuntu or a distro old enough to package JDK 11 (sigh) and X. not XWayland. Debian 11 was the last one to have JDK 11 i think (talk about ancient..)

Needless to say FPGA is done on the windows machine these days.

Need a wider variety of people protecting Debian anyway, governance there is getting weird.

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

They claim it is for compliance but it's well known that user modifications to cars are no longer the responsibility of the car company. I think it's more on principle than any real legal concern.

the trend to give software mit or bsd licenses instead ead of GPL is concerning.

alas, only GPL-3 gives the right to repair and modify the TV or car or refrigerator you own...

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

  Just because it is Rust, it is not safe!  
  
  It worked before, don't replace it!  
  
  etc.  
  

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.

Or it could be you don't have the context like they did. Maybe some hardware bug/quirk that happens on some exotic machine that you don't have.

The current complaint is that they pick the worse one after at the current evaluation.

I don't use Ubuntu but this is huge, it's just as big as when FreeBSD switched to all BSD licensed user tools, I remember having to learn how tar worked again.

I'd like to point out that Ubuntu/Canonical is now seemingly philosophically separate from the origins of GNU and Linux. If you're curious, read "Hackers" by Stephen Levy. They've lost the plot, so to speak, about the core spirit of open software and hardware, which is what gave the projects life in the first place. A philosophical understanding and unity between many, many top notch independent developers.

Another note is how AI contributions to such libraries and programs is going to have an unknown effect on quality. It's almost like there's a business case to rip all the good FOSS written by humans out of the hands of github and apt, and curate all the best source code to ensure it remains in circulation, and extant copies are available that are not washed out by loose standards WRT AI contribs. Or if not a business case, perhaps a reasonable reaction and a good personal vendetta.

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

sudo tee is a common way to work around priviledge restrictions in shell pipes (you can't easily 'sudo' a pipe), if /secure was 0600 and owned by root:

"sudo echo "test" > /secure" or "sudo printf '' > /secure", would not work because your user's shell process can't write to /secure. However, "echo 'test' | sudo tee /secure" works because the elevated 'sudo tee' can write to the file.

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.

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.

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

In general, I don't see the point in manually specifying block sizes most of the time. What I want nearly always the maximum performance, and that should be possible to derive from the hardware, and/or benchmarking.

What about uses like say, skipping data? seek= and skip= are in block sizes, that may not be ideal for performance.

A smart tool should be able to write in 1 MB blocks and yet still skip 512 bytes.

    cp file.iso /dev/sda

Whatever behaviour you’re describing is not how POSIX mandates cp to work. In fact you can do this with busybox too.

cp will open("/dev/sda", O_WRONLY | O_TRUNC) and simply start writing to that file descriptor.

  cat foo.img > /dev/sda

  && sync

If you want to be more targeted:

    blockdev --flushbufs /dev/sda

* https://jdebp.uk/Softwares/dd-with-getopt.html

It only took 52 years. My prediction stands, by the way. (-:

Of course a file can be everything, which is a kind of the point of Linux. But that doesn't change the fact that 'dd' is for disk (or file) I/O. Also please don't argue semantics, it leads nowhere.

But that's not the main point. The main point is the Rust coreutils version of dd is slow. I highly doubt it's impossible to write an implementation in Rust that's as fast as the C one. But the Rust community needs to invest time and energy into finding why that's the case and fixing it. Until that happens the broader Linux community is right to push back on adopting it.

As I said in my post, the rust coreutils team HAS fixed this in 0.11. It's just that Ubuntu 26.04 is stuck on the older one.

Shipping a coreutils that is version 0.8 in an LTS release seems like an interesting choice.

But I guess that shows another weakness of Ubuntu's model of versioning. You can't fix a bug if they don't merge. They have their own bugtracker (and so does every distro?) so you, Mr Dev have to deal with angry users not only on your Github Issues page, but on every distro's own bugtracker as well, and will have to perpetually support whatever old version they decided to shit (times X distro).

Does that mean BTW that they'll keep shipping the same broken dd for the next 2(4) years?

In a dev branch we now have rust ssh, dhcp, init, job management, etc. Rust all the things. Very soon will be able to swap the kernel for Asterinas and drop the last couple libc dependencies to have a complete rust OS that is Linux binary compatible.

I wonder how many other distros will rustmax.

1. What fraction of the core OS can be switched over? Can they oxidize systemd?

2. Are other distros going to switch over (e.g. Debian, which I think of as the ur-distro)?

The vast majority of Rust projects I've seen pull in hundreds, sometimes even thousands, of external projects. If Ubuntu's rusty tools do the same, any memory safety gained would come with a greatly increased supply chain risk.

Doesn't attack surface matter?