5 ms·

> GNU is a blight on this Earth, do not let it infect your code. Can someone explain this sentiment to me? I know about licensing and philosophical criticisms,

by jabot 10y ago

> GNU is a blight on this Earth, do not let it infect your code. Can someone explain this sentiment to me? I know about licensing and philosophical criticisms, but are there any _technical_ faults?

pferde 10y ago
I think the author meant specifically GNU extensions to various POSIX functions, which can be a pain when trying to run code using them in non-GNU environment.
- jabot 10y ago
  Yes, that is a good point. However I thought that "blight" implies some actual technological inferiority. If there is some, I would like to know more about that.
mhd 10y ago
It's "All the world's a VAX" in its new form, where you depend on some language/library feature that's actually not in the standard (IIRC alloca and preprocessor extensions are common culprits). And then suddenly you're on a different platform and discover that you can't rely on that -- pretty bad if it's in a central part of your system (like trampolining functions for your toy lisp). On the other hand, you might run into the same issues if the standard support is sub par. People used to declare K&R-style functions for ages after ANSI was passed, and I wouldn't bet a central part of my system on C99.
- jabot 10y ago
  So in your opinion the problem is "only" one of portability to non-gnu systems? I thought the author also implied that GNU was technologically inferior and/or problematic. That would interest me...
  - mhd 10y ago
    Probably the ubiquitous "bloat" issue some die-hard C-heads have. But that's his prerogative, I was just pointing out that the specific context points towards portability issues.
    - duck2 10y ago
      There is quite a lot of GNU code written in C. However, since gnu is a political umbrella project which does not necessarily value code quality, we see a lot of unnecessary complexity arising from the focus on creating working "free" software and not minding the quality much. Anyone who ever touched GNU autotools will confirm that the bloat issue is real. No need to be a diehard C head.
Sir_Cmpwn 10y ago
Lots of GNU code flies in the face of these principles. A lot of GNU software encourages bad behaviors like using non-standard features (which makes for non-portable software). GNU software is also often very bloated and overengineered, and often found in critical places like glibc. Their coding styles are highly questionable and I disagree with a lot of their design decisions.
- jabot 10y ago
  Thanks for the reply. > GNU software is also often very bloated and overengineered, and often found in critical places like glibc. My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? > Their coding styles are highly questionable and I disagree with a lot of their design decisions. On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example?
  - Sir_Cmpwn 10y ago
    >My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? They are "protected", yes, but their mere presence encourages people to use them. There's no reason to use asprintf, but glibc makes it available so some software uses it. That software is now non-portable. >On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example? Maybe in a blog post someday.
    - jabot 10y ago
      > They are "protected", yes, but their mere presence encourages people to use them. There's no reason to use asprintf, but glibc makes it available so some software uses it. That software is now non-portable. I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"... On exposing non-portable functions/features: - OpenBSD does it (pledge) - Freebsd/NetBSD do it (kqueue) - ... I'm certain other systems do too I think _exposing_ non-portable features is ok, as long as you can't use them _accidentally_. Now, _if_ glibc fulfills that, the blame should fall on the (lazy) developer. If on the other hand glibc makes accidental use possible, then that is... bad for portability. > Maybe in a blog post someday. I would like to read that. :-) [edit: formatting...]
fpoling 10y ago
One of the most evil parts is /etc/nsswitch.conf that injects at runtime arbitrary shared libraries implementing various parts of GNU C library. That leads to proliferation of undocumented file formats and protocols that are hidden behind library interfaces. For example, Linux still does not have a sane DNS resolver interface that is useful without GNU-C library. With move to containers that lead to many issues like inability to resolve link-local names etc.
- jabot 10y ago
  > One of the most evil parts is /etc/nsswitch.conf that injects at runtime arbitrary shared libraries implementing various parts of GNU C library. That leads to proliferation of undocumented file formats and protocols that are hidden behind library interfaces. Are you opposed to dynamically linked libraries in general? Or do you simply oppose using them for name resolution? And how would you propose implementing NIS, LDAP/Kerberos, etc. without them (and without recompiling the libc itself)? > For example, Linux still does not have a sane DNS resolver interface that is useful without GNU-C library. With move to containers that lead to many issues like inability to resolve link-local names etc. Valid criticism. But that's not the GNU peoples' fault, IMHO - I mean, they have a working libc, it's not their fault that containers don't work with other libcs. (Or do i misunderstand you?)
  - fpoling 10y ago
    NIS, LDAP etc should have used a unix socket interface to talk system daemons using well-defined API. This is what happens in practice in any case, but it is done over hidden protocols unusable outside glibc. As for the resolver, then consider that on Ubuntu/Fedora etc. there is hack to set the nameserver in /etc/resolv.conf to 127.0.0.1 which runs a local caching resolver. However this is broken for local name resolution with multiple interfaces as DNS replies do not include interface name. So in a better world glibc simply talks to a system daemon using well-defined protocol. Instead right now to expose, say mdns into containers, one has to spend too much efforts with various hacks even if one does use glibc in a container application.
torrent-of-ions 10y ago
Is there anything popular which does not have a large amount of criticism directed towards it? Anything at all?

by jabot 10y ago

> GNU is a blight on this Earth, do not let it infect your code. Can someone explain this sentiment to me? I know about licensing and philosophical criticisms, but are there any _technical_ faults?

pferde 10y ago

I think the author meant specifically GNU extensions to various POSIX functions, which can be a pain when trying to run code using them in non-GNU environment.

jabot 10y ago
Yes, that is a good point. However I thought that "blight" implies some actual technological inferiority. If there is some, I would like to know more about that.

mhd 10y ago

It's "All the world's a VAX" in its new form, where you depend on some language/library feature that's actually not in the standard (IIRC alloca and preprocessor extensions are common culprits). And then suddenly you're on a different platform and discover that you can't rely on that -- pretty bad if it's in a central part of your system (like trampolining functions for your toy lisp). On the other hand, you might run into the same issues if the standard support is sub par. People used to declare K&R-style functions for ages after ANSI was passed, and I wouldn't bet a central part of my system on C99.

jabot 10y ago
So in your opinion the problem is "only" one of portability to non-gnu systems? I thought the author also implied that GNU was technologically inferior and/or problematic. That would interest me...
- mhd 10y ago
  Probably the ubiquitous "bloat" issue some die-hard C-heads have. But that's his prerogative, I was just pointing out that the specific context points towards portability issues.
  - duck2 10y ago
    There is quite a lot of GNU code written in C. However, since gnu is a political umbrella project which does not necessarily value code quality, we see a lot of unnecessary complexity arising from the focus on creating working "free" software and not minding the quality much. Anyone who ever touched GNU autotools will confirm that the bloat issue is real. No need to be a diehard C head.

Sir_Cmpwn 10y ago

Lots of GNU code flies in the face of these principles. A lot of GNU software encourages bad behaviors like using non-standard features (which makes for non-portable software). GNU software is also often very bloated and overengineered, and often found in critical places like glibc. Their coding styles are highly questionable and I disagree with a lot of their design decisions.

jabot 10y ago
Thanks for the reply. > GNU software is also often very bloated and overengineered, and often found in critical places like glibc. My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? > Their coding styles are highly questionable and I disagree with a lot of their design decisions. On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example?
- Sir_Cmpwn 10y ago
  >My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient? They are "protected", yes, but their mere presence encourages people to use them. There's no reason to use asprintf, but glibc makes it available so some software uses it. That software is now non-portable. >On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example? Maybe in a blog post someday.
  - jabot 10y ago
    > They are "protected", yes, but their mere presence encourages people to use them. There's no reason to use asprintf, but glibc makes it available so some software uses it. That software is now non-portable. I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"... On exposing non-portable functions/features: - OpenBSD does it (pledge) - Freebsd/NetBSD do it (kqueue) - ... I'm certain other systems do too I think _exposing_ non-portable features is ok, as long as you can't use them _accidentally_. Now, _if_ glibc fulfills that, the blame should fall on the (lazy) developer. If on the other hand glibc makes accidental use possible, then that is... bad for portability. > Maybe in a blog post someday. I would like to read that. :-) [edit: formatting...]

fpoling 10y ago

One of the most evil parts is /etc/nsswitch.conf that injects at runtime arbitrary shared libraries implementing various parts of GNU C library. That leads to proliferation of undocumented file formats and protocols that are hidden behind library interfaces. For example, Linux still does not have a sane DNS resolver interface that is useful without GNU-C library. With move to containers that lead to many issues like inability to resolve link-local names etc.

jabot 10y ago
> One of the most evil parts is /etc/nsswitch.conf that injects at runtime arbitrary shared libraries implementing various parts of GNU C library. That leads to proliferation of undocumented file formats and protocols that are hidden behind library interfaces. Are you opposed to dynamically linked libraries in general? Or do you simply oppose using them for name resolution? And how would you propose implementing NIS, LDAP/Kerberos, etc. without them (and without recompiling the libc itself)? > For example, Linux still does not have a sane DNS resolver interface that is useful without GNU-C library. With move to containers that lead to many issues like inability to resolve link-local names etc. Valid criticism. But that's not the GNU peoples' fault, IMHO - I mean, they have a working libc, it's not their fault that containers don't work with other libcs. (Or do i misunderstand you?)
- fpoling 10y ago
  NIS, LDAP etc should have used a unix socket interface to talk system daemons using well-defined API. This is what happens in practice in any case, but it is done over hidden protocols unusable outside glibc. As for the resolver, then consider that on Ubuntu/Fedora etc. there is hack to set the nameserver in /etc/resolv.conf to 127.0.0.1 which runs a local caching resolver. However this is broken for local name resolution with multiple interfaces as DNS replies do not include interface name. So in a better world glibc simply talks to a system daemon using well-defined protocol. Instead right now to expose, say mdns into containers, one has to spend too much efforts with various hacks even if one does use glibc in a container application.

torrent-of-ions 10y ago

Is there anything popular which does not have a large amount of criticism directed towards it? Anything at all?