11 ms·

Death to shared libraries. The headaches they cause are just not worth the benefit. I have been dreaming of someone cresting a system devoid of them.

speed_spread 4y ago
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 problem rather than an inherent issue of the model. I think we're actually just getting the hang of it with stuff like Nix and containers.
- 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).
- 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.
onlyrealcuzzo 4y ago
What are the headaches with shared libraries? Assuming that you pin the version of the library you need, two applications using the same library /shouldn't/ cause issues. In most *nix systems - each instance of a shared library has its own data.
- rattlesnakedave 4y ago
  “ Assuming that you pin the version of the library you need, two applications using the same library /shouldn't/ cause issues.” Then why bother?
- waynecochran 4y ago
  I am assuming you know the answer to the question if you have been developing code for awhile. What makes the problem worse is that it is transitive. I link against Colmap libs, which links against Ceres libs, which links against OpenMP, … these are ever changing code bases and I have to create executables that run on local machines, Azure cloud machines, AWS cloud machines, … chafed down shared lib mismatches becomes a nightmare.
ksec 4y ago
I dont disagree. But wondering if I am missing anything other than the usual cons such as Memory usage, code ( Storage ) size and longer compile time.
- waynecochran 4y ago
  I understand the motivation for shared libs is the reduced memory footprint for large common libs. I have an alternative idea that avoids the headaches of shared lib mismatches and still can reduce the memory footprint. Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. No version mismatch headaches.
  - 8organicbits 4y ago
    I think often the binaries will have been compiled against slightly different versions. With dynamic linking, I can swap 1.0.1 for 1.0.2 or 1.0.3 without issue. The hash would require an exact match, which is likely rare.
    - waynecochran 4y ago
      I want an exact match. That is what I developed and tested against. A change, however small, can have unintended consequences. Changing versions is a huge issue from a reliability point of view.
  - eru 4y ago
    Wouldn't you want to randomise some stuff to make attacks harder? (Sorry, I forgot the details.)
  - cesarb 4y ago
    > Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. It's not actually "code" which is being shared, but instead the memory pages containing that code (the sharing granularity is a single page, since sharing works by pointing the page table entries on each process to the same physical page). So either you'd have to force page alignment for each and every function (highly wasteful, since the page size is at least 4096 bytes), or you're reinventing shared libraries but using a hash instead of a version.
hlsnqp 4y ago
So next time a library such as OpenSSL has a critical security vulnerability that needs to be patched, you'd rather every single binary that has it statically linked is updated, rather than a single shared library file?
- rattlesnakedave 4y ago
  Google “OpenSSL dependency conflict” and view the results. There is significantly more work going on when OpenSSL releases and update than “just update the single shared library file.” Applications often need to be updated as well, so you may as well just statically link the new binary.
  - nicce 4y ago
    It really depends on whether the bug is in API or not. If it is not, it is likely that upgrading only the shared library is enough.
    - convolvatron 4y ago
      How lovely to live in a world where api contracts are absolute and complicated internal behaviors never conflict in unforeseen ways. We’ve really gotten on top of the software complexity problem
      - hedora 4y ago
        That's exactly the problem deb files and apt solve (via integration testing and documenting antidependences.)
      - arinlen 4y ago
        > How lovely to live in a world where api contracts are absolute and complicated internal behaviors never conflict in unforeseen ways. Some libraries managed to preserve API contracts throughout the years just fine. Even in C++, a language which does not establish a standard ABI, has frameworks which have not been breaking the ABI throughout multiple releases, such as Qt.
encryptluks2 4y ago
I used to feel the same way. In an ideal world all packages would be automated and developers would have a way to alert packaging tools that a new version is release, so that it can be run through CI/CD and users would get new packages almost instantaneously without any breaking changes. However, until that happens there is nothing wrong with shared libraries. They exist for good reason. They save bandwidth and ensure that you're not getting old libraries.
- waynecochran 4y ago
  The save bandwidth? Do you mean memory? You want to link against the exact same code you developed and tested your program with. Ensuing you get and exact match is critical for robust code.
  - encryptluks2 4y ago
    Yes, dynamic libraries save a descent amount of bandwidth when installing packages. Also, for the most part no I don't want the exact libraries always. If library creators have a security fix then I want the one with the fix, and there are plenty of times I've seen developers create something and barely maintain it afterwards. Package maintainers are really good at keeping packages for necessary libraries.
icedchai 4y ago
You could try DEC Ultrix. (Oh, did you mean a modern system?)
benreesman 4y ago
When it comes to mandatory dynamic linking, it's always a Beautiful Day for an auto-da-fé: death is too good for mandatory `glibc` and `libstdc++`. As for a system devoid of it, I have grand plans, but for now: people do it with Docker every day! That's what Docker is. It's not broadly technically feasible right now to get a low-friction static link on a mainstream distro with mainstream libraries, but life, erm, technology Finds a Way. For now that's Docker, but the modest </s> enthusiasm around it shows that people want a way out pretty fucking bad and there will be better options soon.
- arinlen 4y ago
  > As for a system devoid of it, I have grand plans, but for now: people do it with Docker every day! That's what Docker is. No, Docker really isn't what you think it is. Docker isolates processes, and provides a convenient platform independent way to deliver stand alone applications, complete with software defined networking and file system abstraction, at the expense of shipping the whole tech stack, including everything plus the kitchen sink like full blown web servers. Thus a .DEB package which otherwise would be 10MB ends up being a Docker image often weighing over 100MB. And pray tell what's Docker's solution to software updates? Well, it's periodic builds that force downstream dependencies and users to re-download payloads of well over 100MB a pop. And you advocate this as an alternative to shared libraries? Who in their ri
  - benreesman 4y ago
    I advocate `musl`/etc. and LLVM as an alternative to `fuck.this.so.0.0.4 -> ...`. I switched from Docker to Nix some time ago (because of many of the pain points you mention). But in a world where native applications worked on any kernel >= the one it was built on, you'd rapidly find out that bin-packing the webserver and webcrawler into a finite list of SKUs (which is where all this container mania originated) via namespaces and cgroups are really not problems that most Docker users have, and there are much simpler ways to get two versions of `node.js` looking at two different sets of libraries. Because you can't reliably know what devilry just stomped all over your `/usr/lib/x86_64/...` or whatever, you kind of have to eat that 100MB image if you want software that worked on Tuesday to still work on Friday. It's a sad state of affairs, but This Too Will Pass. Getting the word out that the reason Docker saves your ass on reproducibility is emulation of static linking behind the FSF's back will accelerate that process.
arinlen 4y ago
> Death to shared libraries. The headaches they cause are just not worth the benefit. Completely disagree. Even though one size does not fit all, anyone who makes sweeping statements about static libraries is just stating to the world how they are completely oblivious regarding basic software maintenance problems such as tracking which software package is updated, specially those who are not kept up to date on a daily basis.
- waynecochran 4y ago
  I like the old school days of just building everything from source. Similarly the Linux Kernel was statically built -- before modules. I knew the whole system from top to bottom.
- nicoburns 4y ago
  If there was a standard for specifying which static library a binary has linked, this would be a non-issue.
  - arinlen 4y ago
    > If there was a standard for specifying which static library a binary has linked, this would be a non-issue. You just gave a non-sequitur answer that rings as rational and true as stating that if the Pope would fly he would be an Airbus A330. Limiting which static library you can link to means absolutely nothing to the problems created by static linking, and how shared libraries solve all of them without any meaningful tradeoff at all.
  - CuriousCosmic 4y ago
    In a sense there kinda is. Pre-linking is a way to statically specify the lookup for a given shared library in an ELF executable. It's still kinda dynamic linking because the file is loaded at runtime but there's no library lookup, it's just "load this file at this path into address space while we load the rest of the main executable". Before PIC there would have been a bit more of a distinction but nowadays static and dynamic libraries are really only distinguished by where the symbols are (unless you want to be able to dynamically load and unload after startup).
SkyMarshal 4y ago
> I have been dreaming of someone cresting a system devoid of them. Doesn’t that pretty much already exist now with immutable system builds, eg Fedora Silverblue, GUIX, NixOS? Each package pulls in its own dependencies with the specified version and config, and then no changes can be made once the system is built. Only way to update is to rebuild the system with the updated versions. Costs more disk space but that is cheap these days, and solves shared dependency hell.
goodpoint 4y ago
Absolutely not. Dynamic libraries are crucial for security. Static linking again and again has proved to be a security nightmare. It makes security updates dependent from upstream release or full rebuilds making things difficult.
- spc476 4y ago
  But aren't you dependent from upstream anyway? Or do you recompile from source the broken dynamic library? In my experience, most sysadmins these days don't compile from source.
  - goodpoint 4y ago
    No to both. The Linux distribution you use is responsible for backporting patches, fixing the vulnerability, building updated packages, testing them and sending the updates. You get targeted security updates without changes in any other functionality.
- naasking 4y ago
  Proved to whom, when, and in what context? Systems that were designed for easy reproducible builds from the ground up are fairly new, so how sure are you the context hasn't changed?
deleted 4y ago
[deleted]
SuperSandro2000 4y ago
Which is not feasible for misters like qt WebKit or chromium.

speed_spread 4y ago

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 problem rather than an inherent issue of the model. I think we're actually just getting the hang of it with stuff like Nix and containers.

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).
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.

onlyrealcuzzo 4y ago

What are the headaches with shared libraries? Assuming that you pin the version of the library you need, two applications using the same library /shouldn't/ cause issues. In most *nix systems - each instance of a shared library has its own data.

rattlesnakedave 4y ago
“ Assuming that you pin the version of the library you need, two applications using the same library /shouldn't/ cause issues.” Then why bother?
waynecochran 4y ago
I am assuming you know the answer to the question if you have been developing code for awhile. What makes the problem worse is that it is transitive. I link against Colmap libs, which links against Ceres libs, which links against OpenMP, … these are ever changing code bases and I have to create executables that run on local machines, Azure cloud machines, AWS cloud machines, … chafed down shared lib mismatches becomes a nightmare.

ksec 4y ago

I dont disagree. But wondering if I am missing anything other than the usual cons such as Memory usage, code ( Storage ) size and longer compile time.

waynecochran 4y ago
I understand the motivation for shared libs is the reduced memory footprint for large common libs. I have an alternative idea that avoids the headaches of shared lib mismatches and still can reduce the memory footprint. Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. No version mismatch headaches.
- 8organicbits 4y ago
  I think often the binaries will have been compiled against slightly different versions. With dynamic linking, I can swap 1.0.1 for 1.0.2 or 1.0.3 without issue. The hash would require an exact match, which is likely rare.
  - waynecochran 4y ago
    I want an exact match. That is what I developed and tested against. A change, however small, can have unintended consequences. Changing versions is a huge issue from a reliability point of view.
- eru 4y ago
  Wouldn't you want to randomise some stuff to make attacks harder? (Sorry, I forgot the details.)
- cesarb 4y ago
  > Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. It's not actually "code" which is being shared, but instead the memory pages containing that code (the sharing granularity is a single page, since sharing works by pointing the page table entries on each process to the same physical page). So either you'd have to force page alignment for each and every function (highly wasteful, since the page size is at least 4096 bytes), or you're reinventing shared libraries but using a hash instead of a version.

hlsnqp 4y ago

So next time a library such as OpenSSL has a critical security vulnerability that needs to be patched, you'd rather every single binary that has it statically linked is updated, rather than a single shared library file?

rattlesnakedave 4y ago
Google “OpenSSL dependency conflict” and view the results. There is significantly more work going on when OpenSSL releases and update than “just update the single shared library file.” Applications often need to be updated as well, so you may as well just statically link the new binary.
- nicce 4y ago
  It really depends on whether the bug is in API or not. If it is not, it is likely that upgrading only the shared library is enough.
  - convolvatron 4y ago
    How lovely to live in a world where api contracts are absolute and complicated internal behaviors never conflict in unforeseen ways. We’ve really gotten on top of the software complexity problem
    - hedora 4y ago
      That's exactly the problem deb files and apt solve (via integration testing and documenting antidependences.)
    - arinlen 4y ago
      > How lovely to live in a world where api contracts are absolute and complicated internal behaviors never conflict in unforeseen ways. Some libraries managed to preserve API contracts throughout the years just fine. Even in C++, a language which does not establish a standard ABI, has frameworks which have not been breaking the ABI throughout multiple releases, such as Qt.

encryptluks2 4y ago

I used to feel the same way. In an ideal world all packages would be automated and developers would have a way to alert packaging tools that a new version is release, so that it can be run through CI/CD and users would get new packages almost instantaneously without any breaking changes. However, until that happens there is nothing wrong with shared libraries. They exist for good reason. They save bandwidth and ensure that you're not getting old libraries.

waynecochran 4y ago
The save bandwidth? Do you mean memory? You want to link against the exact same code you developed and tested your program with. Ensuing you get and exact match is critical for robust code.
- encryptluks2 4y ago
  Yes, dynamic libraries save a descent amount of bandwidth when installing packages. Also, for the most part no I don't want the exact libraries always. If library creators have a security fix then I want the one with the fix, and there are plenty of times I've seen developers create something and barely maintain it afterwards. Package maintainers are really good at keeping packages for necessary libraries.

icedchai 4y ago

You could try DEC Ultrix. (Oh, did you mean a modern system?)

benreesman 4y ago

When it comes to mandatory dynamic linking, it's always a Beautiful Day for an auto-da-fé: death is too good for mandatory `glibc` and `libstdc++`. As for a system devoid of it, I have grand plans, but for now: people do it with Docker every day! That's what Docker is. It's not broadly technically feasible right now to get a low-friction static link on a mainstream distro with mainstream libraries, but life, erm, technology Finds a Way. For now that's Docker, but the modest </s> enthusiasm around it shows that people want a way out pretty fucking bad and there will be better options soon.

arinlen 4y ago
> As for a system devoid of it, I have grand plans, but for now: people do it with Docker every day! That's what Docker is. No, Docker really isn't what you think it is. Docker isolates processes, and provides a convenient platform independent way to deliver stand alone applications, complete with software defined networking and file system abstraction, at the expense of shipping the whole tech stack, including everything plus the kitchen sink like full blown web servers. Thus a .DEB package which otherwise would be 10MB ends up being a Docker image often weighing over 100MB. And pray tell what's Docker's solution to software updates? Well, it's periodic builds that force downstream dependencies and users to re-download payloads of well over 100MB a pop. And you advocate this as an alternative to shared libraries? Who in their ri
- benreesman 4y ago
  I advocate `musl`/etc. and LLVM as an alternative to `fuck.this.so.0.0.4 -> ...`. I switched from Docker to Nix some time ago (because of many of the pain points you mention). But in a world where native applications worked on any kernel >= the one it was built on, you'd rapidly find out that bin-packing the webserver and webcrawler into a finite list of SKUs (which is where all this container mania originated) via namespaces and cgroups are really not problems that most Docker users have, and there are much simpler ways to get two versions of `node.js` looking at two different sets of libraries. Because you can't reliably know what devilry just stomped all over your `/usr/lib/x86_64/...` or whatever, you kind of have to eat that 100MB image if you want software that worked on Tuesday to still work on Friday. It's a sad state of affairs, but This Too Will Pass. Getting the word out that the reason Docker saves your ass on reproducibility is emulation of static linking behind the FSF's back will accelerate that process.

arinlen 4y ago

> Death to shared libraries. The headaches they cause are just not worth the benefit. Completely disagree. Even though one size does not fit all, anyone who makes sweeping statements about static libraries is just stating to the world how they are completely oblivious regarding basic software maintenance problems such as tracking which software package is updated, specially those who are not kept up to date on a daily basis.

waynecochran 4y ago
I like the old school days of just building everything from source. Similarly the Linux Kernel was statically built -- before modules. I knew the whole system from top to bottom.
nicoburns 4y ago
If there was a standard for specifying which static library a binary has linked, this would be a non-issue.
- arinlen 4y ago
  > If there was a standard for specifying which static library a binary has linked, this would be a non-issue. You just gave a non-sequitur answer that rings as rational and true as stating that if the Pope would fly he would be an Airbus A330. Limiting which static library you can link to means absolutely nothing to the problems created by static linking, and how shared libraries solve all of them without any meaningful tradeoff at all.
- CuriousCosmic 4y ago
  In a sense there kinda is. Pre-linking is a way to statically specify the lookup for a given shared library in an ELF executable. It's still kinda dynamic linking because the file is loaded at runtime but there's no library lookup, it's just "load this file at this path into address space while we load the rest of the main executable". Before PIC there would have been a bit more of a distinction but nowadays static and dynamic libraries are really only distinguished by where the symbols are (unless you want to be able to dynamically load and unload after startup).

SkyMarshal 4y ago

> I have been dreaming of someone cresting a system devoid of them. Doesn’t that pretty much already exist now with immutable system builds, eg Fedora Silverblue, GUIX, NixOS? Each package pulls in its own dependencies with the specified version and config, and then no changes can be made once the system is built. Only way to update is to rebuild the system with the updated versions. Costs more disk space but that is cheap these days, and solves shared dependency hell.

goodpoint 4y ago

Absolutely not. Dynamic libraries are crucial for security. Static linking again and again has proved to be a security nightmare. It makes security updates dependent from upstream release or full rebuilds making things difficult.

spc476 4y ago
But aren't you dependent from upstream anyway? Or do you recompile from source the broken dynamic library? In my experience, most sysadmins these days don't compile from source.
- goodpoint 4y ago
  No to both. The Linux distribution you use is responsible for backporting patches, fixing the vulnerability, building updated packages, testing them and sending the updates. You get targeted security updates without changes in any other functionality.
naasking 4y ago
Proved to whom, when, and in what context? Systems that were designed for easy reproducible builds from the ground up are fairly new, so how sure are you the context hasn't changed?

deleted 4y ago

[deleted]

SuperSandro2000 4y ago

Which is not feasible for misters like qt WebKit or chromium.