Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?
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.
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.
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.
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.
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 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.
The Rust community seems to be the one making exciting innovative stuff nowadays. uucore is more complimentary as well, ripgrep and fd are much more interesting. Sure, there may be certainly kinks, as you pointed out. But Rust programs can be debugged. Can GNU programs innovate?
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:
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:
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.
Thanks for taking the time to respond to all my points!
Unfortunately, I find this confirms all my fears.
Whether or not ripgrep, fd, sd, et al. have some bugs left in them or not, the fact remains, when they do work (which is 99%+ of the time for most users), they are significantly more pleasant to work with. More pleasant = more use = more eyes = the bugs get fixed in the long run (as GNU should know from it's history!).
I wish everyone all the best, but I really do see a lot of these tools going the way of X.org in the next 10 years. Or, more likely, the way of csh.
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.
And it has every right to be, when it is discussing these topics. But not polluting the global namespace and not using global variables is not an advanced request!
Comments
Hi, co-maintainer of GNU coreutils!
Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?
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.
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.
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.
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.
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 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.
The Rust community seems to be the one making exciting innovative stuff nowadays. uucore is more complimentary as well, ripgrep and fd are much more interesting. Sure, there may be certainly kinks, as you pointed out. But Rust programs can be debugged. Can GNU programs innovate?
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.
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:
On the other hand GNU find can visit arbitrarily deep directories: ripgrep has similar issues: GNU grep handles this fine: > 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...
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.
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.
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.
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.
Individual GNU projects are free to innovate as much or as little as they want.
Thanks for taking the time to respond to all my points!
Unfortunately, I find this confirms all my fears.
Whether or not ripgrep, fd, sd, et al. have some bugs left in them or not, the fact remains, when they do work (which is 99%+ of the time for most users), they are significantly more pleasant to work with. More pleasant = more use = more eyes = the bugs get fixed in the long run (as GNU should know from it's history!).
I wish everyone all the best, but I really do see a lot of these tools going the way of X.org in the next 10 years. Or, more likely, the way of csh.
And it has every right to be, when it is discussing these topics. But not polluting the global namespace and not using global variables is not an advanced request!