collinfunk

> 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 speaking generally I would caution against putting too much weight into benchmarks.

> 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 macOS machines for testing. But we seem to do well enough with a shared system that Adélie Linux kindly allows the compile farm [1] to use, along with some additional CI machines.

[1] https://portal.cfarm.net/

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] https://github.com/coreutils/gnulib/commit/c599eba7bed3baa30...

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 mention of LLM usage.

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 operates on two file descriptors, allowing you to safely modify file metadata after the fact. macOS has clonefile, clonefileat, and fclonefileat [2]. Sadly, there is no way to operate on two file descriptors. The best you get is fclonefileat, which operates on a source file descriptor. Solaris has reflink and reflinkat, which operate on two paths, the latter relative to file descriptors [3]. In that case, one needs to be careful opening the destination to make changes to the metadata.

GNU coreutils has support for reflinks on Linux and macOS. But I've been thinking about adding support for Solaris as of late [4]. Sadly, I don't use it enough to test it as much as I would like.

Hopefully, a few years down the line the interfaces converge, and it is as simple as hard linking.

[1] https://man7.org/linux/man-pages/man2/FICLONE.2const.html [2] https://www.manpagez.com/man/2/clonefile/ [3] https://docs.oracle.com/cd/E86824_01/html/E54766/reflinkat-3... [4] https://lists.gnu.org/archive/html/coreutils/2026-09/msg0012...

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 versions, probably somewhere in my archived mail. But I don't remember if it was fileutils-3.9 or earlier.

I co-maintain GNU coreutils, so I am interested in reading them. If you have them, you can email me privately or on the public mailing list. Both are listed on the homepage [2].

[1] https://ftp.gnu.org/old-gnu/fileutils/ [2] https://www.gnu.org/software/coreutils/

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 program implementations themselves.

When you say that no one bothered to do this testing until uutils existed, it feels like you are discrediting our work. Any other implementation is free to use our test suite, as long as they respect its licensing. Doing so is relatively straightforward; you just need to point a shell variable to the place with the just-built binaries.

Note that the man pages are a quick reference explaining the options. A lot of gotchas and further explanations are located in the texinfo manual, which is over 300 pages in PDF form [1]. If you notice areas where it could be improved, I would be happy to review your bug report sent to bug-coreutils@gnu.org.

[1] https://www.gnu.org/software/coreutils/manual/coreutils.html

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 released a fixed version of their software (at least at the time of publishing).

The bug was reported on a public mailing list, which is sadly common nowadays [1]. After my workday, during which I was not able to review the report, I wrote a script to confirm the bug was real, since I was seeing way too many slop reports at the time. Then I sent a patch before going to bed [2]. A third party then graciously shared the patch on oss-security [3], which all distributions follow. There is no need to make a new release, which is harder for the distributions than simply applying a small patch.

Perhaps I am just unlucky in my interactions, but I feel like this entitlement is too common among software security people. Note that I see zero return in spending time working on Inetutils, and I find other projects I work on more interesting.

[1] https://lists.gnu.org/archive/html/bug-inetutils/2026-03/msg... [2] https://lists.gnu.org/archive/html/bug-inetutils/2026-03/msg... [3] https://www.openwall.com/lists/oss-security/2026/03/12/4

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 one, shadow-rs, is totally vibe-coded, and the README mistakenly says the original shadow is GNU software under the GPL, which is neither true. If 14/14 are relicensing, or in that one case, what is thought to be relicensing, the simple explanation is that it is an explicit goal of the project.

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.

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

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 replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1].

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

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.

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

Note that STF did not fund GNU coreutils. They funded uutils.

> Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?

Most GNU projects don't have a large overlap, if any overlap at all, between their active contributors. I suspect they behave far more independently than you expect. Also, GNU didn't invent locales, if that is what you are getting at.

> As it stands I am generally averse to using GNU tools because my feeling is that they will be slow, clunky and exhibit arcane behavior in particular edge cases. ripgrep is significantly faster than GNU grep -R; fd than GNU find, etc.

Those programs have their imperfections as well. Particularly, they don't account for arbitrary limits like PATH_MAX. See 'fd' stops before visiting the deepest directory without altering it's exit code:

  $ mkdir -p $(yes a/ | head -n $((16 * 1024)) | tr -d '\n')
  $ fd a | wc -l
  3119
  $ echo ${PIPESTATUS[@]}
  0 0

On the other hand GNU find can visit arbitrarily deep directories:

  $ find a | wc -l
  16384

ripgrep has similar issues:

  $ (while cd $(yes a/ | head -n 1024 |  tr -d '\n'); do :; done > /dev/null 2>&1; echo a > a)
  $ rg '^a$' a
  rg: a/[...]/a: File name too long (os error 36)

GNU grep handles this fine:

  $ grep -r '^a$' a
  a/[...]/a:a

> For example, before LLMs were common, I once had to spend an entire day getting GNU flex and GNU bison to generate code that was: a) properly prefixed with a custom prefix, not yy_ et. al and b) did not use global variables.

Flex isn't a GNU project. I don't use or contribute to Bison, but I am pretty sure that is here:

https://www.gnu.org/software/bison/manual/bison.html#Multipl...

> I would have understood if, for backwards compatibility, this was gated behind a --sane flag or similar, but the GNU manuals were, at least at the time, under the confusing impression that what I was doing was advanced usage and used semi-fancy terms like "re-enterant" to describe what should be the normal behavior. I had to toggle several different knobs, some working for macros, others for functions, and the knobs were different for flex and bison.

Again, I don't contribute to Flex or Bison. I also do not use them. However, I will note that understanding the programs require some complex topics, specifically formal languages and automata. I am not entirely surprised that some of the documentation can be a bit difficult to understand.

> POSIX locales in particular are an anti-feature, and I say this as a non-English native, so uutils adding support for them feels like bug-compatibility with GNU, not feature-compatibility.

They are also widely supported by other implementations. It would be harmful to everyone if we were to disregard them. Also, as I mentioned previously, they were not invented by GNU.

> Other issues involve the dynamic linking requirements of glibc and of the nsswitch in a world that would increasingly prefer to link things statically.

I am a committer to glibc, but this isn't really my area of focus. You are free to discuss it on libc-help@sourceware.org if you'd like.

> I am really saddened if the reaction is just that GNU is the old and stable is the main argument here. Because when you read many GNU documents and manpages, written years ago, you get the feeling that the original authors were looking to do things properly, make breaking changes where they were sane (hence POSIXLY_CORRECT), innovate (Emacs), and overall would not have been particularly swayed by the "old and stable" argument of traditional Unix distributions at the time.

We make breaking changes. I recently changed 'printenv' and 'env' to safely quote their output. I will note though that although you want us to make more changes like this, others get quite angry at us when we do. Even changes that aren't breaking cause angry mailing list messages. We can't make everyone happy.

> Can GNU programs innovate?

Individual GNU projects are free to innovate as much or as little as they want.

Note, I am a co-maintainer of GNU coreutils. Whether that makes my opinion relevant, biased, or both, you can decide. :)

I really wished the documented their benchmarking methodology here, or at least cautioned the reader not to jump to conclusions based on the benchmarks shown.

GNU 'sort' performance can drastically be altered by the locale in use, the input, and the arguments given to the --buffer-size and --parallel options. GNU 'sort' is fairly conservative in how many threads it will use by default, and in my experience, much more so than uutils. This is because throwing more threads at 'sort' may make it faster (or may not), but also risks running out of memory. This is an issue with uutils, which is poor at deciding when to use external sorting:

  $ export LC_ALL=C
  $ for i in {a..z}; do yes $i | head -n $(numfmt --from=iec 512M) | tr -d '\n' >> input; done
  $ time sort input > /dev/null

  real 0m24.245s
  user 0m0.896s
  sys 0m19.161s

Here is the same command using the latest uutils commit compiled with 'make PROFILE=release':

  $ time uu-sort input > /dev/null
  Killed                     uu-sort input > /dev/null

  real 2m53.560s
  user 1m40.634s
  sys 0m59.847s

The process gets killed by the OOM killer. This is likely because uutils 'sort' decides to use 18 threads, instead of the 1 used by GNU 'sort'. I find it a bit frustrating that benchmarks are thrown out without any methodology or citations, because they are often trusted without question. These could be benchmarks from before uutils had localization, which was the case before 2025, and treated LC_ALL=en_US.UTF-8 as LC_ALL=C. In that case, of course it would be much faster than GNU coreutils, but it also means uutils would give you the wrong results for non-ASCII characters. There is, as shown above, much more considerations beyond speed that seemingly never get the time of day next to flashy benchmarks...

When did this occur? I am a GNU maintainer, and have never heard such a thing from the FSF. The GNU Coding Standards and other similar texts leave the decision to support non-free platforms up to the maintainer.

I co-maintain GNU coreutils and wrote the Neon 'wc -l' code, for reference.

Based on my quick look at the source code, it looks like this program can handle ASCII whitespace. GNU coreutils uses iswspace, which is locale-aware. That limits how much we can optimize. We could probably add more optimization if the current locale is ASCII, e.g., LC_ALL=C on GNU/Linux.