This is painfully reductionist. The mount namespace is only one of multiple namespaces (eg. pid, network, user, etc.) that containers utilize. Security doesn't stop at linking and shipping binaries.

That's not true.

Docker/containers do far more than just bundle shared libraries. We use a container for almost all of our CI builds. Our agents are container images with the toolchains, etc installed. It also means it's trivially easy to reproduce the build environment for those occasional wtf moments where someone has an old version of <insert tool here>.

But if the tools were all statically linked, couldn't you ship a zip with the binaries needed for building?

How do you update those tools and make sure you've deleted all the old versions? What do you do to avoid the problem of a developer SSH'ing and apt-get installing a build dependency?

Tools aren't the only part of the environment though. Setting the JAVA_HOME environment variable for a build can dramatically change the output, for example. Path ordering might affect what version of a tool is launched.

They also mean that our developers don't need to run centos 7, they can develop on windows or Linux, and test on the target platform locally from their own machine.

Setting JAVA_HOME matters, again, because the Java runtime environment is essentially dynamically linked to the Java program you’re running.

The nice thing about fully statically linked executables can just be copied between machines and ran. If Java worked this way, the compiler would produce a (large) binary file with no runtime dependancies, and you could just copy that between computers.

Rust and Go don’t give you a choice - they only have this mode of compilation.

Docker forces all software to work this way by hiding the host OS’s filesystem from the program. It also provides an easy to use distribution system for downloading executables. And it ships with a Linux VM on windows and macos.

But none of that stuff is magic. You could just run a VM on macos or windows directly, statically link your Linux binaries and ship them with scp or curl.

The killer feature of docker is that it makes anything into a statically linked executable. You can just do that with most compilers directly.

java home is an example. CC is another one for most C build systems, goroot.

> But none of that stuff is magic.

I never said it was, I simply said that docker does more than statically link binaries.

>You could just run a VM on macos or windows directly, statically link your Linux binaries and ship them with scp or curl.

https://news.ycombinator.com/item?id=9224

> The killer feature of docker is that it makes anything into a statically linked executable.

The killer feature of docker is it gives you an immutable*, versionable environment that handles more than just scp'ing binaries.

> CC is another one for most C build systems, goroot.

The benefit docker provides here is giving users a simple, reproducible, downloadable environment with no external dependencies.

I'm not saying Docker is useless in the current build environment. On the contrary - Having a convenient way to sandbox, ship and execute arbitrary execution environments and statically linked executables is really useful.

I think this is such a great idea we should make debian work closer to this model. Nix is a fantastic step in this direction and it'd be great if more distributions followed suit.

Debian and friends fill your hard drive with of weird, non-reproducible versions of various dynamically linked libraries. The fact I can't take a binary on my x86_64 linux machine and run it on your x86_64 linux machine is an embarrassment. Moving toward static linking and fully reproducible builds would be a tremendous help here.

Docker feels like a kludgy hack. I'd love a world where docker isn't necessary because its best ideas have been lowered into the OS itself.

Indeed, you could. Linus takes backward compatibility more than a little seriously.

Where does static linking come into play? Why can't you ship a zip with binaries and libraries?

It's plenty common for binary distributions of software to come as tgz files. That's usually including a bunch of .so files.

> It's plenty common for binary distributions of software to come as tgz files. That's usually including a bunch of .so files.

Yes, and compatibility across distros / releases is very hit-and-miss, because they usually ship certain libraries and rely on the OS for others.

I’m not sure whether it’s possible to ship every library without running into ODR issues, but at that point, you’d loose all of the advantages of dynamic linking anyway.

No idea, but it has been common since forever, and of course you miss the advantages of dynamic linking (the ability to update libraries separately) which is the whole point.

Docker provides much more isolation than a dynamic libraries.

Static linking is not a new thing. It was there since a beginning. Dynamic linking is a new thing compared to it.

> Docker provides much more isolation

The very opposite. You can do all the sandboxing you want without needing docker and you will avoid docker's big attack surface.

Not without machine code analysis. That's a pretty big attack surface itself if you're relying on it for safety properties.

I don’t disagree, but I think there’s a productive middle ground here.

Docker has cleared become popular because it drastically eases application deployment and cleanup.

Static linking also solves a huge number of these problems, and in a generally better way.

Docker has overhead, an associated attack surface, bulky artifices, etc but it yields very nice benefits for workload isolation (env configs, storage mounts, etc) as well as cross OS/arch builds.

Is there a solution that combines the best of these options? A super-slim docker for statically linked apps that combines the ease of deployment with a much smaller footprint?

> A super-slim docker for statically linked apps that combines the ease of deployment with a much smaller footprint?

I feel like this could be a simple shell script, at least for 99% of real-world use cases.

Not really, you'd still have a problem of building with possibly conflicting system dependencies, packaging (a dev team that can build its own .debs or .rpms is a rarity), ease of deployment / distribution, and running multiple instances. Developers don't want to deal with that crap.

That is so wrong. I use docker to build things which I cannot build on my host system because the host and build have incompatibilities. Static locking would not solve this.