4 ms·

I believe the original reasoning for Dynamic Linking wasn't performance gains, but security gains -- someone described the driving story to me as essentially a

by setr 6y ago

I believe the original reasoning for Dynamic Linking wasn't performance gains, but security gains -- someone described the driving story to me as essentially a found vulnerability in a very common library required updating and re-compiling everything on every system, scarring sysadmins globally and permanently; the space saving and performance aspects came up as later "bonuses". I have little memory of the details of the story, and I'm not 100% sure it's true, but it's a much more satisfying and reasonable argument for dynamic linking than performance/space. Of course, the more modern solution would probably be a good package manager -- if its trivial to recompile things, and track what needs to be recompiled, then dynamic linking seems to gain little, but bring in a lot of its own headaches (as we know today)

cryptonector 6y ago
The original reasoning for shared libraries was reducing memory footprint -- back then memory was scarce. We're talking back in the days of SVR2, the mid-80s. The original reasoning for ELF was that static link semantics suck. ELF's semantics are far superior (https://news.ycombinator.com/item?id=23656173 https://news.ycombinator.com/item?id=23656173).
bjourne 6y ago
Stallman and other GNU folks have claimed that they stuck with dynamic linking to foster cooperation between hackers. They knew that it wasn't a win performance-wise but they wanted to encourage hackers to help each other. The idea was that if someone found a bug in a library he or she depended on they would be "forced" to send the patch upstream rather than just fixing the bug in their local copy of the library. Thus they made dynamic linking the default in gcc and kept static linking as something of an after though. I read it on a mailing list a long time ago so I don't have a source.
tannhaeuser 6y ago
Don't forget that the principles of the LGPL (originally the "library GPL") were/are pretty much tied to the technical concept of a shared library object that an end-user can change, etc; IANAL so I can't say anything about the legal soundness of this interpretation. Moreover, in a recent discussion about this topic on HN, someone said the introduction of shared libs into the Linux user space was mainly in support of porting X Windows to Linux (supposedly because of binary video drivers or to accomodate MIT-licensed code?), but I haven't found any supporting reference for that. glibc's maintainer Ulrich Drepper also has pretty strong opinions on static linking [1]; no matter what you think about this technically, or Ulrich personally, his paper "How to write shared libraries" [2] is considered reference material on the subject. Personally, I think that the over-use of shared libs in the Linux userland clearly serves no purpose if users flock to entire new layers of abstractions (eg Docker-like containers) to isolate their app delivery from the IMHO overengineered mechanisms in ELF and ld.so with their multiple RUNPATHs, configs, loader scripts, and versioned glibc symbols (on top of build-time libtool/autootols) that still doesn't seem to get to the point. While the LSB effort for more uniform Linux distros isn't dead, it doesn't seem to be taken seriously. Idk, but maybe the GNU folks also see the lack of binary compat for Linux apps as a desideratum, to frustrate any and all attempts to ship binary apps? [1]: https://web.archive.org/web/20100527213559/http://people.redhat.com/drepper/no_static_linking.html https://web.archive.org/web/20100527213559/http://people.red... [2]: https://akkadia.org/drepper/dsohowto.pdf https://akkadia.org/drepper/dsohowto.pdf
- pjmlp 6y ago
  Without shared libraries, the only way to do plugins is via IPC. Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets. There is no free lunch as they say.
  - 08-15 6y ago
    > Without shared libraries, the only way to do plugins is via IPC. That's primitive superstition: - dlopen() works in statically linked programs too. - Even without dlopen(), you can load code dynamically. It's not magic, especially if the plugin is linked statically. - Besides, how is IPC bad? I take fcgi over Apache's modules any day.
    - pjmlp 6y ago
      dlopen is useless in static linked programs when the idea is to provide plugins after the fact. The idea of using plugins is exactly that various parts are able to ship them at various times during the lifetime of the applications. Patching files compiled statically is obviously not what one wants from plugins. Incidently plugins support is exactly why Go added support for dynamic linking into their toolchain.
      - 08-15 6y ago
        One of us is confused; I honestly don't know which one. Where is the problem in this scenario? My application (statically) linked provides a plugin interface. It works by calling dlopen() on the plugin and then passes a record of functions to the entry points. The plugin can be provided by a third party, and top make that easier, I provide an SDK (a header file). No file is patched, and I have no idea what this has to do with Go. Enlighten me?
        pjmlp 6y ago
        Your solution requires compiling everything from scratch in a single executable, that is not how plugins are supposed to be designed. We have been there before with solutions like graphics drivers for Borland's BGI library for their MS-DOS compilers. Where a driver interface is provided, and then each "plugin" registers themselves on application startup. Adding new plugins to an existing application in this scenario requires recompilation and updating the uses/#include being used for plugins, or patch the executable from an existing .obj file. If you are using dlopen on a third party binary instead of your own, then you are already using dynamic linking by definition, by loading third party code dynamically and revolving the proper address locations for all symbols. Go only had static compilation on the beginning as the only true way, but it failed short exactly in this scenario, to the point that eventually plugin package came to be and dynamic compilation support is now a feature of Go's toolchain as well, although many seem to still not be aware that Go compilers can also produced dynamic libraries.

by setr 6y ago

cryptonector 6y ago

The original reasoning for shared libraries was reducing memory footprint -- back then memory was scarce. We're talking back in the days of SVR2, the mid-80s. The original reasoning for ELF was that static link semantics suck. ELF's semantics are far superior (https://news.ycombinator.com/item?id=23656173 https://news.ycombinator.com/item?id=23656173).

bjourne 6y ago

Stallman and other GNU folks have claimed that they stuck with dynamic linking to foster cooperation between hackers. They knew that it wasn't a win performance-wise but they wanted to encourage hackers to help each other. The idea was that if someone found a bug in a library he or she depended on they would be "forced" to send the patch upstream rather than just fixing the bug in their local copy of the library. Thus they made dynamic linking the default in gcc and kept static linking as something of an after though. I read it on a mailing list a long time ago so I don't have a source.

tannhaeuser 6y ago

Don't forget that the principles of the LGPL (originally the "library GPL") were/are pretty much tied to the technical concept of a shared library object that an end-user can change, etc; IANAL so I can't say anything about the legal soundness of this interpretation. Moreover, in a recent discussion about this topic on HN, someone said the introduction of shared libs into the Linux user space was mainly in support of porting X Windows to Linux (supposedly because of binary video drivers or to accomodate MIT-licensed code?), but I haven't found any supporting reference for that. glibc's maintainer Ulrich Drepper also has pretty strong opinions on static linking [1]; no matter what you think about this technically, or Ulrich personally, his paper "How to write shared libraries" [2] is considered reference material on the subject. Personally, I think that the over-use of shared libs in the Linux userland clearly serves no purpose if users flock to entire new layers of abstractions (eg Docker-like containers) to isolate their app delivery from the IMHO overengineered mechanisms in ELF and ld.so with their multiple RUNPATHs, configs, loader scripts, and versioned glibc symbols (on top of build-time libtool/autootols) that still doesn't seem to get to the point. While the LSB effort for more uniform Linux distros isn't dead, it doesn't seem to be taken seriously. Idk, but maybe the GNU folks also see the lack of binary compat for Linux apps as a desideratum, to frustrate any and all attempts to ship binary apps? [1]: https://web.archive.org/web/20100527213559/http://people.redhat.com/drepper/no_static_linking.html https://web.archive.org/web/20100527213559/http://people.red... [2]: https://akkadia.org/drepper/dsohowto.pdf https://akkadia.org/drepper/dsohowto.pdf

pjmlp 6y ago
Without shared libraries, the only way to do plugins is via IPC. Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets. There is no free lunch as they say.
- 08-15 6y ago
  > Without shared libraries, the only way to do plugins is via IPC. That's primitive superstition: - dlopen() works in statically linked programs too. - Even without dlopen(), you can load code dynamically. It's not magic, especially if the plugin is linked statically. - Besides, how is IPC bad? I take fcgi over Apache's modules any day.
  - pjmlp 6y ago
    dlopen is useless in static linked programs when the idea is to provide plugins after the fact. The idea of using plugins is exactly that various parts are able to ship them at various times during the lifetime of the applications. Patching files compiled statically is obviously not what one wants from plugins. Incidently plugins support is exactly why Go added support for dynamic linking into their toolchain.
    - 08-15 6y ago
      One of us is confused; I honestly don't know which one. Where is the problem in this scenario? My application (statically) linked provides a plugin interface. It works by calling dlopen() on the plugin and then passes a record of functions to the entry points. The plugin can be provided by a third party, and top make that easier, I provide an SDK (a header file). No file is patched, and I have no idea what this has to do with Go. Enlighten me?
      - pjmlp 6y ago
        Your solution requires compiling everything from scratch in a single executable, that is not how plugins are supposed to be designed. We have been there before with solutions like graphics drivers for Borland's BGI library for their MS-DOS compilers. Where a driver interface is provided, and then each "plugin" registers themselves on application startup. Adding new plugins to an existing application in this scenario requires recompilation and updating the uses/#include being used for plugins, or patch the executable from an existing .obj file. If you are using dlopen on a third party binary instead of your own, then you are already using dynamic linking by definition, by loading third party code dynamically and revolving the proper address locations for all symbols. Go only had static compilation on the beginning as the only true way, but it failed short exactly in this scenario, to the point that eventually plugin package came to be and dynamic compilation support is now a feature of Go's toolchain as well, although many seem to still not be aware that Go compilers can also produced dynamic libraries.