Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It’s worth noting that advantage (and in my belief the large adoption of containers generally) is only valuable to interpreted languages that dont allow static linking.

For statically compiled binaries I’ve not worried about different versions of libraries for my binaries for 20 years (and the technology is decades older than that).

I do appreciate the docker file format but largely because it’s become used for true virtualization systems like firecracker. Plain Linux “containers” largely offer me very little.



Containers are still valuable for statically-linked code, as ways of comprehensively namespacing resources. (In fact, the converse is true; containers are built on the resource-namespacing features of modern Linux, which in turn were inspired by Plan9 a distributed operating system building on *nix).


Right. But I’ve been able to use resource limits for my Linux processes for far longer than containers were popularized. With my processes anyway that’s the big win with namespaces.

That is to say, if you control the hosts and process then the container features are available with much less ceremony while if you are hosting someone else’s process (or they you) containers don’t provide enough isolation.


You're thinking of cgroups, which is what you gives you per-process group resource limits. Namespacing gives you quite a bit more than that. You can have all services running as the same user but still not able to see each other's data. You can have all services get a unique IP address even though they're on the same kernel. You can have them all listen on port 80. They can all read from the same socket file from their perspective but it won't actually be the same file. You can have them all use different DNS providers even though they're just delegating to /etc/resolv.conf. You can't do that with just static linking. Containers give you quite a bit more than incompatible dependencies being able to run on the same host, including features that can only be provided by a kernel, not a language runtime. They allow you to use arbitrarily many different languages. You can run third-party applications you can't rewrite in Java to get a WAR or force them to statically link.


I think the more fundamental advantage is on the dev side:

How do you reproducibly build that static binary in a dozen different developer's environments, and in CI?

In fact, containers kind of suck in prod environments.

For example:

- Kernel/binary mismatches break vDSO, and gettimeofday becomes 100x more expensive.

- Current apache can't run in Synology Docker any more, because they require a new kernel secure RNG (even for http).

- There's no reasonable built in story for persistent storage.

VM's and bare metal solved these issues long ago.


Worse, except for stuff like what was being done at Xerox, static linking was the only way for compiled languages.

Also on desktop systems, embedding resources into the binaries exists since the early 1980's, or just deliver every in the same directory like NeXTSTEP bundles, or what is called xcopy deployment on the PC world on homage how we used to do it on MS-DOS days.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: