4 ms·

You're just embracing another set of problems. Shared libraries were introduced for a reason. The are complex to handle, but that's a long standing tooling prob

• shrimp_emoji 4y ago
  >Shared libraries were introduced for a reason. Lack of storage and bandwidth in the 1970s
  • goodpoint 4y ago
    False. The main reason was to avoid having to maintain and update multiple copies.
• arccy 4y ago
  nix and containers actually eliminate all the benefits of shared libraries while still having all their problems
  • naasking 4y ago
    Non-deterministic and unpredictable behaviour is a bigger problem than whatever benefits you think shared libraries provide. That's why so many people here prefer static linking, and that's what Nix gives you even for dynamic linking.
• rattlesnakedave 4y ago
  “Shared libraries were introduced for a reason.” I’m pretty sure the reason is “X11 was large and badly factored, and people who should have known better thought it would save disk space.” The problems they claim to solve are updates across applications at once, but in the enterprise how often does that actually happen? Application authors still have to test against the new version, and sysadmins still have to roll out the changes required to support the update. In practice they may as well statically link. Let’s not forget the problems they introduce are significant. Implementations are complex. Applications become less portable. ABI versioning is a pain (versioned symbols are gross). Semantic changes in the shared lib cause chaos. Exec is slower because of the linking done at load time. Dynamic libs are bigger than static ones, AND they’re loaded into memory. More difficult to verify the correctness of a given executable. The alleged “benefit” here really does not outweigh the cost. If we were doing static linking from the beginning, it’s difficult to say if we would have wound up with things like docker or nix in the first place.
  • edflsafoiewq 4y ago
    Surely the main reason is that the linked library may actually be different on different machines. Stuff like Open GL.
  • cesarb 4y ago
    > If we were doing static linking from the beginning, it’s difficult to say if we would have wound up [...] We were doing static linking from the beginning, at least on Unix. Dynamic linking came later.
    • IshKebab 4y ago
      And on Mac.
  • a9h74j 4y ago
    Plenty of support for static linking, I am seeing. Would static linking conceivably make sandboxing, jailing, etc easier? Compared to all the effort which goes into dynamic linking, I suspect it would be better spent on sandboxing (both mechanism and UX).
  • guenthert 4y ago
    > Exec is slower because of the linking done at load time. Oh, cry me a river. 30 years ago the performance impact was known and was very well worth the trade-off. Machines are orders of magnitude faster now and consequently the impact less significant. Next thing, you're telling me X11 is slow.
• alkonaut 4y ago
  Yes. But the other set of problems exists anyway. Even if you drop in a new system version of a shared library, you still need to consider what other versions are used apart from the system library. Any app (other than those provided by a system package manager of course) can have a local version different from the system version and any app can have linked it statically?
• flohofwoe 4y ago
  > Shared libraries were introduced for a reason. Those reasons were floppy disks and RAM that was measured in kilobytes though.