[pecg]

GNU stands for a philosophy of freedom, thus guixsd won't provide official repositories for installing proprietary software, some users don't like it, even though they might be interested in the technological approach of the system.

GNU utilities, are not only unsexy, they are bloated and messy, and prone to failure; the GNU implementations (coreutils: grep, cat, tail, etc) of standard UNIX tools are not done with simplicity in mind.

But hey, after all GNU is Not Unix. For those of us, who really appreciate the UNIX philosophy still have OpenBSD, which is the only light in a world of chaos, in my opinion.

[jolmg]

> GNU utilities, are not only unsexy, they are bloated and messy, and prone to failure; the GNU implementations (coreutils: grep, cat, tail, etc) of standard UNIX tools are not done with simplicity in mind.

I've heard people say how GNU code is bloated and messy many times before, but never that they're prone to failure. I've never had any failure myself with any GNU code. Can you give some examples of failures you've experienced?

Also, I'm looking at the coreutils source right now, and it's not as messy as I was expecting. true.c is only a pageful with 80 lines, many of which are simply because of the license comment and the usage() function for --help. cat.c and tail.c also seem reasonably understandable. Biggest complaint I can make is that there's cases where spaces and tabs are mixed in the indentation, but I've long resigned myself to expect that in projects that have more than 1 major contributor.

I do, however, think that glibc and gcc are pretty messy. I tried looking for the definition of fopen() in openbsd's libc and found it in less than 30 seconds by grepping. I still haven't found glibc's. gcc seems to rely heavily on its own extensions, because I don't understand what's going on here:

    int
    main (int argc, char **argv)
    {
      toplev toplev (NULL, /* external_timer */
                     true /* init_signals */);

      return toplev.main (argc, argv);
    }

That looks like a function prototype in a function definition, but it seems to mean an assignment going by the next line. Then in toplev.c, we have:

    int
    toplev::main (int argc, char **argv)
    {

That looks like C++, but the file extension is ".c"...

You know what? Nevermind. Comparing the code for true.c and cat.c between glibc and openbsd's libc, I do rather like how clear openbsd is in its code. Damn. Sexy is a good word. Now I understand why people speak so well of it. I don't even need grep, the source file hierarchy is so clear. Looking back at GNU's true.c, I don't even understand half of what's going on there in those 80 lines, and it turns out that true.c is also the source for false.c, it just #include "true.c".

TL;DR I agree that GNU utilities are messy. I'm not sure of the bloated aspect, because I do like that utilities have internationalized documentation built-in, but that seems to be bloat by openbsd's standards. And I wouldn't know of them being prone to failure, because I never had one with them.

EDIT: Huh. I wanted to reply to Hello71, but there's no reply link under his post. Anyone know why? Anyway, yeah, I saw a comment in the file mentioning that over a line that referred to stdout. Can't check now because I'm away from the computer. I didn't really understand the reason though.

[pasabagi]

I love your post. It's really nice to watch somebody go through an honest and curious appraisal of a position.

[int0x80]

It is c++. The file is .c but whatever. They use a lot of c++.

I agree with you however. Having worked with the code gnu relies a lot on macros & a lot of auto generated code. The code is a big mess, imposible to tackle if you dont spend a huge amount of time on it.

A lot of symbols are generated through #defines and pastting (X macros) so you cant grep shit for one.

[voxadam]

That reminds me; I wonder how the uutils project[1] is doing. While I still haven't gotten around to giving Rust a shot I think their idea of reimplementing coreutils in the language has merit.

[1] https://github.com/uutils/coreutils

[vthriller]

> I've heard people say how GNU code is bloated and messy many times before, but never that they're prone to failure.

Just have a look at changelog for coreutils [0]. Sure it's very long, especially if you're not following its releases, sure it's full of weird edge cases that you might've never encountered (I'm certainly way too lazy to go as far as to look for those rare bugs that I stumbled upon years and years ago but there definitely were some), but this, IMO, is a great illustration of how GNU (or, rather, GNU coreutils) code is "prone to failure"—mainly because it sometimes tries to do way too much.

[0] http://git.savannah.gnu.org/cgit/coreutils.git/plain/NEWS

[maskros]

Since you mention 'true' ... I can't help but think of Rob Pike's diatribe https://twitter.com/rob_pike/status/966896123548872705

[pecg]

The most "iconic" example of failure most be the shellshock bug in bash, though the time in which it was fixed should be applauded.

[Hello71]

speaking of true --help, did you know that GNU true can exit non-zero? the exact way is left as an exercise to the reader :)

(if you're actually trying it at home, remember that "true" is virtually always a builtin. AFAIK there is no legitimate way to have shell builtin true return non-zero. (overwriting the command doesn't count :P))

[jolmg]

Huh. The reply link appeared.

Anyway, yeah, there's a commented line mentioning that:

    /* Note true(1) will return EXIT_FAILURE in the
       edge case where writes fail with GNU specific options.  */
    atexit (close_stdout);

Makes sense. If you:

    $ /bin/true --version >& -

it fails because it was not able to write what you asked it to stdout.

[josefx]

By specification it should not print anything or fail in any way http://pubs.opengroup.org/onlinepubs/9699919799/utilities/tr... .

[JdeBP]

You'll find that the FreeBSD and NetBSD codebases (for base) are similarly structured and similarly written.