5 ms·

Dynamic linking is a key innovation that we abandon at our own peril. Only those who are comfortable living in the world dynamic linking creates can agitate for

Dynamic linking is a key innovation that we abandon at our own peril. Only those who are comfortable living in the world dynamic linking creates can agitate for its removal. In a way, advocates of pure static linking are like anti-vaccine advocates. Here's a killer application of dynamic linking: NSS. It's wonderful to be able to extend applications with new notions of names and addresses. Remember the bad old days when /etc/passwd parsing was hardcoded and you had a choice of either local users or NIS, and that choice was baked into every application? PAM is another good example. By the way: there's no such thing as static linking in Windows. All system calls go through ntdll.dll. (In fact, the actual system call numbers are scrambled with every service pack.) This property allows wonderful things, including a pure _userspace_ implementation of 32-bit compatibility for an otherwise pure 64-bit kernel.

vezzy-fnord 11y ago
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/ http://busybox.net/~vda/unscd/). And this: http://www.nico.schottelius.org/blog/nscd-bugs/ 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.2Fother_user_databases 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/auth_approval.3?query=authenticate&sec=3 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...
- quotemstr 11y ago
  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.
- quotemstr 11y ago
  > 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/ 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.)
  - vezzy-fnord 11y ago
    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.
  - justincormack 11y ago
    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.
    - 11y ago

vezzy-fnord 11y ago

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/ http://busybox.net/~vda/unscd/). And this: http://www.nico.schottelius.org/blog/nscd-bugs/ 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.2Fother_user_databases 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/auth_approval.3?query=authenticate&sec=3 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

quotemstr 11y ago
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.
quotemstr 11y ago
> 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/ 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.)
- vezzy-fnord 11y ago
  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.
- justincormack 11y ago
  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.
  - 11y ago