Hacker News Reader

Comment by jabot | Hacker News Reader

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

View on HN

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.

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

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.

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.

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.

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?

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

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

>I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"...

Well, implement it yourself then. It's really not hard to live without, though. I don't know about this loop you're talking about but I just do this:

    int len = snprintf(NULL, 0, "fmt", ...);
    char *foo = malloc(len + 1);
    snprintf(foo, len, "fmt", ...);

Easy to wrap that up in your own asprintf function if you would find that useful. And in practice writing a lot of these functions is going to happen anyway when someone ports your non-portable code to another system.

>Well, implement it yourself then.

Yeah, let's reinvent the wheel anytime something is not available on all platforms in the world, wether or not you intent to target them...

If I target GNU systems, why can't I use GNU features ? If people really want to port my code, let them do so.

I did not know that the return value of snprintf is actually the length of the string that would be produced. I assumed I'd just get some error code - which would require re-trying with some larger buffer, thus the "loop".

Thanks for that :-)

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.

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

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.

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.

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.

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

Reply on news.ycombinator.com