> rewrites of coreutils to be faster and cleaner (e.g. Busybox or various Rust projects) Note that busybox is under the GPL. As someone involved with coreutils, I can’t say anything specific without examples, but…
> The GNU versions work fine in macOS. Apple doesn’t want to distribute them, but that’s mean you can’t use them. We also test GNU coreutils on macOS. It is a bit tricky since the other maintainers and I don't own any…
Thanks for the kind words. :) However, the other maintainers, who have been doing it for many more years than I have, and various other authors are certainly more deserving than I am. I am similarly thankful to them.
They also copied some of our code, which is not very appreciated.
Glad you could get an older version works well for you. We probably would have tried to continue supporting it if we had access to it. I'm a bit sad I never got the chance to use it once.
Hi, one of the co-maintainers of GNU coreutils here. It is nice to hear things worked on HP-UX. I don't have access to it, and I don't think the other maintainers do either. See this commit [1]. [1]…
Yeah, it has binary packages nowadays as well, though.
Ironically, the maintainers of this repository are equally talented as vibe coders, since they simply maintain a markdown file and nothing else.
Yes, it is a deeply unserious list. I dislike LLMs, but if a bug is a bug, then I will fix it, typically without complaint. That is enough to get added to this list. The "curators" demand you accost reporters for any…
Interesting, thanks for the pointers!
In theory, I agree that it shouldn't be tricky. However, in practice, it is a bit tricky since all the different implementations have different ways to perform reflinks. Linux has FICLONE [1], which I prefer because it…
Hey, I perfectly understand if not. But do you have the sources that were used to build those binaries? The oldest version on the GNU ftp server is fileutils-3.13 [1]. I vaguely remember having some links to older…
The [2] link is uutils using the test suite that the GNU coreutils maintainers, including myself, created and continue to improve. This test suite has long predated uutils and gets equal, if not more, man-hours than the…
As the person who wrote the fix for this issue (and not the original code), I will just mention that I find this paragraph makes the author sound incredibly entitled: Shamefully, the inetutils project hasn’t actually…
As I have told the authors privately, I find it quite difficult to take their claim that they "don't care about licensing" seriously. 13/14 of the projects under uutils are relicensing GNU or GPL'd software. The other…
Only GNU sort uses threads. There is still some room for improvement there, if anyone wants to take a shot at it. :)
Canonical hasn't contributed anything to GNU coreutils in the time since the switch was announced, just to be clear.
Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could…
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…
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.
Glad to hear that I am not alone. I feel like launchpad is totally ignored half 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...…
I have. It has been an open bug upstream for years as well.
Legacy is a bit harsh... 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.
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…
Note that STF did not fund GNU coreutils. They funded uutils.
> rewrites of coreutils to be faster and cleaner (e.g. Busybox or various Rust projects) Note that busybox is under the GPL. As someone involved with coreutils, I can’t say anything specific without examples, but…
> The GNU versions work fine in macOS. Apple doesn’t want to distribute them, but that’s mean you can’t use them. We also test GNU coreutils on macOS. It is a bit tricky since the other maintainers and I don't own any…
Thanks for the kind words. :) However, the other maintainers, who have been doing it for many more years than I have, and various other authors are certainly more deserving than I am. I am similarly thankful to them.
They also copied some of our code, which is not very appreciated.
Glad you could get an older version works well for you. We probably would have tried to continue supporting it if we had access to it. I'm a bit sad I never got the chance to use it once.
Hi, one of the co-maintainers of GNU coreutils here. It is nice to hear things worked on HP-UX. I don't have access to it, and I don't think the other maintainers do either. See this commit [1]. [1]…
Yeah, it has binary packages nowadays as well, though.
Ironically, the maintainers of this repository are equally talented as vibe coders, since they simply maintain a markdown file and nothing else.
Yes, it is a deeply unserious list. I dislike LLMs, but if a bug is a bug, then I will fix it, typically without complaint. That is enough to get added to this list. The "curators" demand you accost reporters for any…
Interesting, thanks for the pointers!
In theory, I agree that it shouldn't be tricky. However, in practice, it is a bit tricky since all the different implementations have different ways to perform reflinks. Linux has FICLONE [1], which I prefer because it…
Hey, I perfectly understand if not. But do you have the sources that were used to build those binaries? The oldest version on the GNU ftp server is fileutils-3.13 [1]. I vaguely remember having some links to older…
The [2] link is uutils using the test suite that the GNU coreutils maintainers, including myself, created and continue to improve. This test suite has long predated uutils and gets equal, if not more, man-hours than the…
As the person who wrote the fix for this issue (and not the original code), I will just mention that I find this paragraph makes the author sound incredibly entitled: Shamefully, the inetutils project hasn’t actually…
As I have told the authors privately, I find it quite difficult to take their claim that they "don't care about licensing" seriously. 13/14 of the projects under uutils are relicensing GNU or GPL'd software. The other…
Only GNU sort uses threads. There is still some room for improvement there, if anyone wants to take a shot at it. :)
Canonical hasn't contributed anything to GNU coreutils in the time since the switch was announced, just to be clear.
Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could…
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…
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.
Glad to hear that I am not alone. I feel like launchpad is totally ignored half 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...…
I have. It has been an open bug upstream for years as well.
Legacy is a bit harsh... 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.
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…
Note that STF did not fund GNU coreutils. They funded uutils.