> a very known fact for all unix grey beards

The co-inventor of Unix, Ken Thompson, and the Unix team engineer and author of The Unix Programming Environment, Rob Pike, are both big advocates of static linking. They designed Go and made a big point of emphasising static linking. Pike: "Shared libraries are obviously a good idea until you've actually used them. Whether it's obvious or not that they're a bad idea is mostly a matter of how close you are to trying to get them to work." He wrote the first windowing system for Unix, which surely qualifies him as a greybeard.

It's a shame they didn't roll a proper package manager with the language toolkit. Having your executable depend on having some lib installed is quite a pain. But how do you share libraries properly then? Especially without a proper way of bundling deps in your code...

Using cargo always makes me feel at ease when writing Rust. Haven't dabbled with linkers though.

And rust binaries all link the rust libs statically(you can change linking), maybe because it is easier to distribute static binaries that work everywhere than to distribute a bunch of libraries without official channel(your os distributions).

The same Rob Pike also stated that UNIX is past its due date.

> it is a very known fact for all unix grey beards ...

It doesn't get more "unix greybeard" than Ken Thompson, the original bearded creator of Unix. And his latest project suggests he is pro static linking.

Go packaging philosophy goes against that. but go is also released in a good enough state and things are being done right on the fly.

As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL.

The solution, is to bump the version in the dockerfile, rebuild, and deploy.

This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.

Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.

Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.

when it works for containers, it would have worked just the same for shared lib, but with one less step.

containers: update the lib, rebuild.

sane software: update the lib.

now, to the complicated case which containers claim to solve, when the lib update breaks compatibility.

container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways.

sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.

Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.

I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good

with shared libraries containers are an option just fine

Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.