13 ms·

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:2

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

ganelonhb 11d ago
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…
teekert 13d ago
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.
- collinfunk 13d ago
  I have. It has been an open bug upstream for years as well.
  - teekert 13d ago
    ok, that's concerning, if you post it here I'll vote for it (after confirming).
    - JdeBP 12d ago
      The Launchpad bug is https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2167206 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 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.
- jeffbee 13d ago
  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.
  - collinfunk 13d ago
    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/2150305 https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/215...
    - jabl 12d ago
      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.
      - b112 12d ago
        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.
  - gdevenyi 12d ago
    Reporting bugs _at all_ in Ubuntu has never worked for me.
- mixmastamyk 13d ago
  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.
  - baq 12d ago
    Fork Ubuntu and threaten their business model, that’ll get their attention. Only half joking.
    - yjftsjthsd-h 12d ago
      Ubuntu is the fork; just use Debian.
    - tjoff 12d ago
      There are plenty of Ubuntu forks?
    - geokon 12d ago
      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
      - drdexebtjl 12d ago
        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.
      - pessimizer 12d ago
- LtWorf 12d ago
  My experience is that filing bug reports to ubuntu is a complete waste of time. Not sure if it's different for paying users.
- Symbiote 12d ago
  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 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils
  - rwmj 12d ago
    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/12253 https://github.com/uutils/coreutils/issues/12912 https://github.com/uutils/coreutils/issues/12912
- oefrha 12d ago
  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/86808 https://discourse.ubuntu.com/t/ubuntu-26-04-1-lts-released/8...
- mort96 12d ago
  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.
  - sick_of_slop 12d ago
    [dead]
  - here_to_learn 12d ago
    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.
  - dirtikiti 10d ago
    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.
- mkj 11d ago
  The 26.04.01 upgrade LTS is delayed from it too, not just interim releases. https://lists.ubuntu.com/archives/ubuntu-announce/2026-August/000326.html 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.
amelius 13d ago
Let them first fix Snap.
- 0x696C6961 12d ago
  They need to kill snap ...
  - cute_boi 12d ago
    Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.
    - ChocolateGod 12d ago
      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.
    - petre 12d ago
      I'll avoid it at this point anyway. The Rust coreutils is another reason for that. Snap, monetizing updates, telemetry, enough is enough.
      - voakbasda 12d ago
        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.
    - tancop 12d ago
      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.
dark-star 13d ago
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?
- secondcoming 13d ago
  That way of thinking just means it'll never be fixed
  - gpm 13d ago
    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 https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
    - sylvestre 9d ago
      Because Collin reported it in Ubuntu too :)
  - abirch 13d ago
    "The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds
    - dfox 13d ago
      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.
    - LtWorf 12d ago
      It's complicated to do it yourself when upstream won't accept your code.
IshKebab 13d ago
I mean, that should work... but you can see why that would be considered low priority right?
lynx97 12d ago
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."
froh 12d ago
to enable GPL free embedded Ubuntu, field tested on all platforms (because it happens to be the default).
barbarkaragul 12d ago
Hi, this is not a one bug.when the change app flags not working or not happening. I was measured with bsd and busybox.
znpy 12d ago
And that’s why i keep ubuntu far from my computers…
monegator 12d ago
but it segfaulted in a memory safe way.
- m00dy 12d ago
  sarcasm detected here :D
  - stevefan1999 11d ago
    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)
    - pjmlp 9d ago
      What new ideas? Standard ML features from 1983?!
maxhou 12d ago
I tried switching a buildroot based CI server to the 26.04 One Makefile statement triggered a bug in rust ln: src/%: @ln -sfn $(DIR)/foo src In parallel build, we would get random failure: ln: Already exists 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.
PunchyHamster 12d ago
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
Perepiska 12d ago
It can fail blazingly fast!
- ganelonhb 11d ago
  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!”
  - Perepiska 6d ago
    Not pain but annoying fly.
nottorp 12d ago
But this is totally not a memory ownership bug! It's some other kind of bug!
HackerThemAll 12d ago
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...
- kd913 12d ago
  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.
flossly 12d ago
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.
tored 12d ago
It is Year of the Linux Desktop, not Year of the Linux Cli.
sick_of_slop 12d ago
[dead]

ganelonhb 11d ago

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…

teekert 13d ago

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.

collinfunk 13d ago
I have. It has been an open bug upstream for years as well.
- teekert 13d ago
  ok, that's concerning, if you post it here I'll vote for it (after confirming).
  - JdeBP 12d ago
    The Launchpad bug is https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2167206 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 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.
jeffbee 13d ago
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.
- collinfunk 13d ago
  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/2150305 https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/215...
  - jabl 12d ago
    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.
    - b112 12d ago
      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.
- gdevenyi 12d ago
  Reporting bugs _at all_ in Ubuntu has never worked for me.
mixmastamyk 13d ago
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.
- baq 12d ago
  Fork Ubuntu and threaten their business model, that’ll get their attention. Only half joking.
  - yjftsjthsd-h 12d ago
    Ubuntu is the fork; just use Debian.
  - tjoff 12d ago
    There are plenty of Ubuntu forks?
  - geokon 12d ago
    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
    - drdexebtjl 12d ago
      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.
    - pessimizer 12d ago
LtWorf 12d ago
My experience is that filing bug reports to ubuntu is a complete waste of time. Not sure if it's different for paying users.
Symbiote 12d ago
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 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils
- rwmj 12d ago
  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/12253 https://github.com/uutils/coreutils/issues/12912 https://github.com/uutils/coreutils/issues/12912
oefrha 12d ago
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/86808 https://discourse.ubuntu.com/t/ubuntu-26-04-1-lts-released/8...
mort96 12d ago
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.
- sick_of_slop 12d ago
  [dead]
- here_to_learn 12d ago
  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.
- dirtikiti 10d ago
  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.
mkj 11d ago
The 26.04.01 upgrade LTS is delayed from it too, not just interim releases. https://lists.ubuntu.com/archives/ubuntu-announce/2026-August/000326.html 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.

amelius 13d ago

Let them first fix Snap.

0x696C6961 12d ago
They need to kill snap ...
- cute_boi 12d ago
  Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.
  - ChocolateGod 12d ago
    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.
  - petre 12d ago
    I'll avoid it at this point anyway. The Rust coreutils is another reason for that. Snap, monetizing updates, telemetry, enough is enough.
    - voakbasda 12d ago
      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.
  - tancop 12d ago
    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.

dark-star 13d ago

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?

secondcoming 13d ago
That way of thinking just means it'll never be fixed
- gpm 13d ago
  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 https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
  - sylvestre 9d ago
    Because Collin reported it in Ubuntu too :)
- abirch 13d ago
  "The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds
  - dfox 13d ago
    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.
  - LtWorf 12d ago
    It's complicated to do it yourself when upstream won't accept your code.

IshKebab 13d ago

I mean, that should work... but you can see why that would be considered low priority right?

lynx97 12d ago

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

froh 12d ago

to enable GPL free embedded Ubuntu, field tested on all platforms (because it happens to be the default).

barbarkaragul 12d ago

Hi, this is not a one bug.when the change app flags not working or not happening. I was measured with bsd and busybox.

znpy 12d ago

And that’s why i keep ubuntu far from my computers…

monegator 12d ago

but it segfaulted in a memory safe way.

m00dy 12d ago
sarcasm detected here :D
- stevefan1999 11d ago
  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)
  - pjmlp 9d ago
    What new ideas? Standard ML features from 1983?!

maxhou 12d ago

I tried switching a buildroot based CI server to the 26.04 One Makefile statement triggered a bug in rust ln: src/%: @ln -sfn $(DIR)/foo src In parallel build, we would get random failure: ln: Already exists 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.

PunchyHamster 12d ago

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

Perepiska 12d ago

It can fail blazingly fast!

ganelonhb 11d ago
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!”
- Perepiska 6d ago
  Not pain but annoying fly.

nottorp 12d ago

But this is totally not a memory ownership bug! It's some other kind of bug!

HackerThemAll 12d ago

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

kd913 12d ago
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.

flossly 12d ago

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.

tored 12d ago

It is Year of the Linux Desktop, not Year of the Linux Cli.

sick_of_slop 12d ago

[dead]