6 ms·

The only reason dynamic libraries are worse (beside speed) is the dependency hell. Put the dynamic libraries INSIDE the container and you can upgrade them when

The only reason dynamic libraries are worse (beside speed) is the dependency hell. Put the dynamic libraries INSIDE the container and you can upgrade them when/if you want, while nothing will be broken during a systemic upgrade where you don't chose to update them.

tedivm 8y ago
In an environment like this the only difference between static and dynamically linked libraries is that the dynamically linked ones can be upgraded without needing to recompile. Other benefits- such as not needing to ship as much data- disappear, and the negatives (such as speed) remain. In this context then there doesn't seem to be much of a benefit towards dynamic linking. Most people are going to rebuild the container completely rather than enter it to upgrade a library, or if it's a distributed program they're just going to grab the latest version- being able to upgrade components individual is not a use case that I see being all that important.
- devereaux 8y ago
  Then I guess we have different opinions, because I would only update the parts of the container that need updating, and I wouldn't touch what isn't broken - just like how I do a apt-get upgrade more often than a apt-get dist-upgrade: because even if it should all work fine in theory, in practice it doesn't. I am mostly interested by gains in security, gains in maintainability, and gains in simplicity. Dynamic libraries reduce the number of parts that need to be managed, reducing overall complexity. Also, if I remember correctly, UWP apps in windows are managed a bit like that, with the equivalent of a xdelta (binary diff) Being able to update just one or a few libraries would be handy in other cases - not just critical exploits. On top of my head, the first use case I see is old apps, those which have deployed say years ago, where the compilation scripts/recipe/call it whatever you want have been lost and the employees left, and you need to change one piece of the whole for whatever reason. There's totally a place for static binaries, but it is a very specific one, where you have special constraints (ex: when I update a remote server, I want to have a static busybox)
  - mitchty 8y ago
    > I am mostly interested by gains in security, gains in maintainability, and gains in simplicity. Dynamic libraries reduce the number of parts that need to be managed, reducing overall complexity. I'd argue they do no such thing, the complexity is still there, only now your users can upgrade libraries and potentially break your app in ways you never expected. Lets take openssl as an example, i've seen upgrades of that break applications easily. Your app should take any dependency change as a new version or patch upgrade. And if you're releasing a new version of the application, what gain did a library provide? About none. I've seen it from both static and dynamic sides, I vastly prefer static binaries cons to the cons I've seen from dynamic libraries.
    - webmaven 8y ago
      How would this impact the sort of incremental app updates that Chrome (for example) does using Omaha? eg. would dynamic linking result in smaller or simpler deltas compared to static linking?
      - mitchty 8y ago
        How would static libssl affect say a binary diff versus dynamic? Should be in the noise floor for decent binary diff algorithms. I seem to recall chrome uses that to essentially patch things in place. I'd have to look but I highly doubt for say elf binaries that a binary diff patch would be more than dynamic. Ignoring updating the static library portion itself that is.
        webmaven 8y ago
        > Ignoring updating the static library portion itself that is. Don't ignore that, it's exactly the context I was thinking of (and under discussion).
        mitchty 8y ago
        Well its no different amount of difference you'd have for libssl then obviously. With a binary diff algorithm if libssl.a doesn't change then its just your changes. If you update just libssl, then its the diff of those bits. If both its both, I can't speak to how much that is as I've never done it. Test it and look at the sizes of the diffs. You'd be updating ssl somewhere, be it package manager or not.

tedivm 8y ago

In an environment like this the only difference between static and dynamically linked libraries is that the dynamically linked ones can be upgraded without needing to recompile. Other benefits- such as not needing to ship as much data- disappear, and the negatives (such as speed) remain. In this context then there doesn't seem to be much of a benefit towards dynamic linking. Most people are going to rebuild the container completely rather than enter it to upgrade a library, or if it's a distributed program they're just going to grab the latest version- being able to upgrade components individual is not a use case that I see being all that important.

devereaux 8y ago
Then I guess we have different opinions, because I would only update the parts of the container that need updating, and I wouldn't touch what isn't broken - just like how I do a apt-get upgrade more often than a apt-get dist-upgrade: because even if it should all work fine in theory, in practice it doesn't. I am mostly interested by gains in security, gains in maintainability, and gains in simplicity. Dynamic libraries reduce the number of parts that need to be managed, reducing overall complexity. Also, if I remember correctly, UWP apps in windows are managed a bit like that, with the equivalent of a xdelta (binary diff) Being able to update just one or a few libraries would be handy in other cases - not just critical exploits. On top of my head, the first use case I see is old apps, those which have deployed say years ago, where the compilation scripts/recipe/call it whatever you want have been lost and the employees left, and you need to change one piece of the whole for whatever reason. There's totally a place for static binaries, but it is a very specific one, where you have special constraints (ex: when I update a remote server, I want to have a static busybox)
- mitchty 8y ago
  > I am mostly interested by gains in security, gains in maintainability, and gains in simplicity. Dynamic libraries reduce the number of parts that need to be managed, reducing overall complexity. I'd argue they do no such thing, the complexity is still there, only now your users can upgrade libraries and potentially break your app in ways you never expected. Lets take openssl as an example, i've seen upgrades of that break applications easily. Your app should take any dependency change as a new version or patch upgrade. And if you're releasing a new version of the application, what gain did a library provide? About none. I've seen it from both static and dynamic sides, I vastly prefer static binaries cons to the cons I've seen from dynamic libraries.
  - webmaven 8y ago
    How would this impact the sort of incremental app updates that Chrome (for example) does using Omaha? eg. would dynamic linking result in smaller or simpler deltas compared to static linking?
    - mitchty 8y ago
      How would static libssl affect say a binary diff versus dynamic? Should be in the noise floor for decent binary diff algorithms. I seem to recall chrome uses that to essentially patch things in place. I'd have to look but I highly doubt for say elf binaries that a binary diff patch would be more than dynamic. Ignoring updating the static library portion itself that is.
      - webmaven 8y ago
        > Ignoring updating the static library portion itself that is. Don't ignore that, it's exactly the context I was thinking of (and under discussion).
        mitchty 8y ago
        Well its no different amount of difference you'd have for libssl then obviously. With a binary diff algorithm if libssl.a doesn't change then its just your changes. If you update just libssl, then its the diff of those bits. If both its both, I can't speak to how much that is as I've never done it. Test it and look at the sizes of the diffs. You'd be updating ssl somewhere, be it package manager or not.