Comment by vezzy-fnord | Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

Parent Full thread

In a way, advocates of pure static linking are like anti-vaccine advocates.

Holy fuck, this is one of the most absurd exaggerations I've read in some time. I'm assuming you have a very strong and convincing reason to justify this statement.

Here's a killer application of dynamic linking: NSS.

...

Really? NSS?

OK, so static NIS/YP may not be good at all, but that doesn't change that NSS and the nscd (name server cache daemon) have been amongst the buggiest and most brittle components in glibc, on top of glibc's sequential DNS resolution. It's so bad the Busybox developers had to write a single-threaded fork-based alternative just to deal with its inherent resource exhaustion issues (see the comments in this software: http://busybox.net/~vda/unscd/).

And this: http://www.nico.schottelius.org/blog/nscd-bugs/

musl libc (ever growing in popularity in embedded and other fields for its standards compliance, robustness and implementation simplicity) doesn't support NSS and doesn't intend to, instead researching several alternative methods, the third one probably optimal: http://wiki.musl-libc.org/wiki/Open_Issues#NIS.2FLDAP.2Fothe...

And if you think this problem hasn't been solved so much more elegantly before, look into the details of Plan 9's ndb and factotum.

PAM is another good example.

bsd_auth is much better: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

> musl libc

I'm conflicted on Musl. I like the idea. I like the focus on robustness. I like Felker's style [1]. But for God's sake, Musl refuses to implement basic operating system primitives we've had for decades, like dlclose(3), all because the author, from his necessarily limited perspective, just can't understand why someone would want those facilities.

I'm sticking with glibc until the Musl people decide they want robustness and feature parity.

By the way: PAM isn't "add in the bloat of additional backends". Dynamic loading of backends is the opposite of bloat.

There's absolutely no reason Felker can't greatly improve libc robustness and maintain at least source-level compatibility with a libc we've used for decades and that has many valuable features. Musl's sin is being gratuitously opinionated.

[1] http://ewontfix.com/, good for the most part. Wrong about 32-bit PIC being terrible. (What we really need is -fvisibility=hidden and -Bsymbolic by default.)

robustness and feature parity

Some features aren't worth having parity with, or at least need to be well rethought - and Felker has had a good track record with the latter in terms of thread-local storage, UTF-8 and other properties, so I'm looking forward to how the musl community settles the question of name directories.

Source level compatibility with glibc is a terrible idea, it is a huge and bloated system, which quite clearly has made a lot of mistakes - which it is gradually fixing some of. C is no longer a general purpose programming language, and needs to be used more carefully when it is needed, and Musl helps you do that. Use a safe language if you want more stuff.

Puritanism in system libraries helps nobody. What you consider "bloated" others consider essential. If you're responsible for the lowest-level userspace library on a system, one that every component uses to talk to every other component, you have no business foisting your opinion on the world.

glibc, buggy and hacky as it is, doesn't try to impose its opinions on you.

Source level compatibility means replicating the bugs, which is pointless, just use glibc if you want it to be identical. Musl is basically like the libcs of the BSDs, ie less stuff it just made up, just the standards compliant stuff. Add the other stuff to your own library.

> Source level compatibility means replicating the bug

No it doesn't. For example: we can fix the the glibc pthread_mutex_lock bug without affecting ABI or source compatibility.

Bugginess of one particular implementation (and let's be fair here -- most of the stuff in glibc is quite ugly and hacky, a direct consequence of the bazaar model) has nothing to do with dynamic linking. Both PAM and NSS have been used successfully in a dozen of other operating systems for decades, and that's dynamic linking that facilitated these technologies.

Are you arguing that glibc code quality will magically go up if they abandon dynamic linking?

I wasn't arguing against dynamic linking, but the parent poster's fervor at attacking its critics, and their poor example of a supposedly great thing it facilitated.

I'm not sure if you can blame glibc on bazaar practices. musl and glibc both have similar, BFDL-driven development models (well, glibc did until Drepper got booted, at least) yet musl has far better curation and attentiveness than glibc.

PAM and NSS have always been controversial (though PAM particularly) and better ways have been both developed and proposed.

bsd_auth runs in a subprocess and so can't make persistent modifications to the environment of the caller --- consider pam_limits or pam_env.

Reply on news.ycombinator.com