3 ms·

Another one is everyone in the 90's believed shared libraries were a major innovation and therefore to be used everywhere. They turn out to be bringing fairly

Another one is everyone in the 90's believed shared libraries were a major innovation and therefore to be used everywhere. They turn out to be bringing fairly little benefit (minuscule disk space saving) and giant drawbacks (the vaunted "your software will be upgraded / bugfixed behing your back" which instead turned out to be a configuration nightmare and an exponential multiplication of the attack surface for would be attackers) To this day, I dread to try an run an old binary that was linked against shared libraries say 5 years ago on a modern system. Chances of it working are quasi zero, and good luck trying to reconstitute the tree of shared libraries that are recursively required to get that binary to run, glibc often being the worst offender of the lot.

zajio1am 2y ago
They are. Static linking may be okay for small and simple libraries, but as a user, i do not want multiple versions of a complex library linked inside applications, each with slightly different behavior. And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype.
- IshKebab 2y ago
  > And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype. I don't think many people have problems with the idea that core system libraries could be dynamically linked. But Linux distros take this to a ridiculous extreme. I absolutely do not care if a bug in libgmp means my package manager updates the 2 apps I have installed that use it instead of 1 library. Would be really interesting to see some actual stats about this though. How many library projects do people have installed that are depended on by more than say 3 apps? I'm guessing it's under 100. I think that's the approach Flatpak takes with it's "runtimes" and it seems like a very sensible one.
  - zajio1am 2y ago
    Even if you just use 2 apps that depends on 1 library, there may be tens or hundreds of such apps in the distribution repository (which is, btw, the case for libgmp). A bug in such library would force distribution maintainers to release new packages for all these applications, instead of just one. I think that if the library is independent upstream project, then there is no reason why it should not be dynamically-linked independent package in distributions.
    - IshKebab 2y ago
      > A bug in such library would force distribution maintainers to release new packages for all these applications, instead of just one. Surely that's automated?
      - RetroTechie 2y ago
        > Surely that's automated? Doesn't matter. You'd rather update X separate packages (of unknown size & potentially different maintainers or update policies) to fix 1 bug in a library they all happen to use? Shared libraries are a good thing, period. Implemented poorly? Fix that instead, rather than include everything & the kitchen sink in every single app.
  - throwaway2046 2y ago
    >Would be really interesting to see some actual stats about this though. Drew DeVault did some tests on this subject and published the results here: https://drewdevault.com/dynlib.html https://drewdevault.com/dynlib.html
dralley 2y ago
Dynamic linking isn't a bad idea for, say, the top 100 libraries on the system. There it can be genuinely quite useful. Beyond that though, the returns diminish quickly.
uecker 2y ago
Shared libraries are critical for security updates.
- IshKebab 2y ago
  Not if you are using a package manager.
  - uecker 2y ago
    If you security update all the packages all the time if some compiled dependency needs updating, then you have all the disadvantages of shared libraries the parent complained about but with much more effort and cost. Or in other words, the perceive simplicity of static linking comes form pretending that something is now a stable dependency you can freeze that does not need to update or which you can update at your own schedule. This is not true because of security issues. The advantage that you can run the same binary independent from the shared library context even in ten years is only true if you do not care that security issues in the binary remain unfixed for 10 years.
dspillett 2y ago
In the 90s, even right at the end of them but especially earlier on, space was far more expensive – even a miniscule saving could be worth a bit of faf (faf in terms of dev & admin time, and a small efficiency hit at the CPU). Also, RAM was expensive and shared libraries allow some of that to be saved too if your OS is bright enough. Back then the benefits really were apparent, especially for common core libraries (libc in particular). Of course these days storage and RAM are both massively cheaper, and there are a plethora of variants even for what might previously have been the core version of something, so the benefits are minimised. We've seen similar with JS libs over more recent years: first everyone had their own copy, costing bandwidth and meaning every site/app dev had to update their version when there was a security issue. Then CDNs became a thing for libraries & such, reducing the bandwidth cost and (unless you pinned at a specific minor version) making security/efficiency updates easier. Now as shared sources for JS and the like that are potentially a privacy or security issue, and treeshaking & such can reduce the payload for most uses, we've swung back and (almost) everyone has their own version, as-is or crunched into a bundle. Package management, the likes of which wasn't available in the 90s, deals with the updating of JS libs even if everyone has local versions (they get updated on next build, unless holding back to full test a new release), but that in itself is a security concern due to supply-chain attacks.
deleted 2y ago
[deleted]

zajio1am 2y ago

They are. Static linking may be okay for small and simple libraries, but as a user, i do not want multiple versions of a complex library linked inside applications, each with slightly different behavior. And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype.

IshKebab 2y ago
> And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype. I don't think many people have problems with the idea that core system libraries could be dynamically linked. But Linux distros take this to a ridiculous extreme. I absolutely do not care if a bug in libgmp means my package manager updates the 2 apps I have installed that use it instead of 1 library. Would be really interesting to see some actual stats about this though. How many library projects do people have installed that are depended on by more than say 3 apps? I'm guessing it's under 100. I think that's the approach Flatpak takes with it's "runtimes" and it seems like a very sensible one.
- zajio1am 2y ago
  Even if you just use 2 apps that depends on 1 library, there may be tens or hundreds of such apps in the distribution repository (which is, btw, the case for libgmp). A bug in such library would force distribution maintainers to release new packages for all these applications, instead of just one. I think that if the library is independent upstream project, then there is no reason why it should not be dynamically-linked independent package in distributions.
  - IshKebab 2y ago
    > A bug in such library would force distribution maintainers to release new packages for all these applications, instead of just one. Surely that's automated?
    - RetroTechie 2y ago
      > Surely that's automated? Doesn't matter. You'd rather update X separate packages (of unknown size & potentially different maintainers or update policies) to fix 1 bug in a library they all happen to use? Shared libraries are a good thing, period. Implemented poorly? Fix that instead, rather than include everything & the kitchen sink in every single app.
- throwaway2046 2y ago
  >Would be really interesting to see some actual stats about this though. Drew DeVault did some tests on this subject and published the results here: https://drewdevault.com/dynlib.html https://drewdevault.com/dynlib.html

dralley 2y ago

Dynamic linking isn't a bad idea for, say, the top 100 libraries on the system. There it can be genuinely quite useful. Beyond that though, the returns diminish quickly.

uecker 2y ago

Shared libraries are critical for security updates.

IshKebab 2y ago
Not if you are using a package manager.
- uecker 2y ago
  If you security update all the packages all the time if some compiled dependency needs updating, then you have all the disadvantages of shared libraries the parent complained about but with much more effort and cost. Or in other words, the perceive simplicity of static linking comes form pretending that something is now a stable dependency you can freeze that does not need to update or which you can update at your own schedule. This is not true because of security issues. The advantage that you can run the same binary independent from the shared library context even in ten years is only true if you do not care that security issues in the binary remain unfixed for 10 years.

dspillett 2y ago

In the 90s, even right at the end of them but especially earlier on, space was far more expensive – even a miniscule saving could be worth a bit of faf (faf in terms of dev & admin time, and a small efficiency hit at the CPU). Also, RAM was expensive and shared libraries allow some of that to be saved too if your OS is bright enough. Back then the benefits really were apparent, especially for common core libraries (libc in particular). Of course these days storage and RAM are both massively cheaper, and there are a plethora of variants even for what might previously have been the core version of something, so the benefits are minimised. We've seen similar with JS libs over more recent years: first everyone had their own copy, costing bandwidth and meaning every site/app dev had to update their version when there was a security issue. Then CDNs became a thing for libraries & such, reducing the bandwidth cost and (unless you pinned at a specific minor version) making security/efficiency updates easier. Now as shared sources for JS and the like that are potentially a privacy or security issue, and treeshaking & such can reduce the payload for most uses, we've swung back and (almost) everyone has their own version, as-is or crunched into a bundle. Package management, the likes of which wasn't available in the 90s, deals with the updating of JS libs even if everyone has local versions (they get updated on next build, unless holding back to full test a new release), but that in itself is a security concern due to supply-chain attacks.

deleted 2y ago

[deleted]