Comment by devereaux | Hacker News Reader

Comment by devereaux | Hacker News Reader

Parent Full thread

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)

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

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?

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.

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

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.

A lot of people who use containers are also fans of immutable infrastructure, which may be where some of the disconnect is here. Even before containers got popular there were a lot of shops that had disabled SSH into their machines to discourage the "artisan" server mentality.

I also don't know anyone who roles containers manually by hand- generally speaking they're automated (using things like dockerfiles and provisioning scripts, which are often right in the repository storing the code), making rolling a new container easier than trying to upgrade a single library.

Generally speaking, I am not a big fan of restricting options. Having SSH is very helpful in case of a catastrophe requiring immediate attention.

Let's leave these emergencies aside. I prepare binaries, and deploy them to servers. The deployment contains several "moving parts", so there are many tests to validate deployment and make sure that all parts work well together.

There is also a rolling deployment, to compare the performance of current version N to N-1 and N-2 on multiple axis, and catch weird regressions. When something that could not be caught in tests goes wrong (recently, a cascading issue caused by an increase in latency due to a change in the routing), I have to see what's happening on one of the live instances. I have to tweak things there.

Doing the equivalent of git bisect with binaries running on many servers is not fun.

If a feature or a fix only impacts one shared library, I would LOVE to be able to roll only that to part of the deployment fleet and see if it fixes the issue -- and roll a different mix of library to another small part of the deployment, etc.

Consider I am testing x different version of library X and y different versions of library Y. I could do that just as well with xy=N different static binaries, but if I can do with the master and x+y dynamic libraries, I believe it makes my life easier.

Live A/B testing is not really possible if the difference is a few percent in efficiency - you have to wait to have enough samples and do statistical tests to see if 1900 samples per time unit on average on servers A, B and C is a regression compared to 2000 samples on average on server D, E and F. If I could test combinations of versions, I could compare more easily server A with library X version x to server B with library X version X-1 to server C with library X version x and library Y version y-1, etc.

xy vs x+y seems small, but increase x and y, add many dimension, and you really start to want more "breathing room".

Reply on news.ycombinator.com