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

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

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.

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

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.

  $ 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

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

  $ find a | wc -l
  16384

  $ (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)

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

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.

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

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

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

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.

Which situation do you think looks worse, admitting to having biological research facilities (unrelated to weaponry), or having Russians invade, take over one of said research facilities, and run with whatever story they want to justify their war?

Have you seen any evidence for the bio-weaponry claim?

> to be fair the world genuinely believes COVID spontaneously manifested directly next to a US funded COVID research site, so perhaps the gap is really that wide.

You would need more evidence than proximity to prove that.