[subhobroto]

I am a big fan which is why I am saying this: you're dismissing the kernel and ABI surface is a huge assumption that must hold true for your comment to hold stavros.

If you had said "unikernels" I would have had no arguments to make.

[stavros]

What do you mean? Statically linked programs depend on the kernel too.

[subhobroto]

right - that's precisely what I meant. I read your comment "Containers are just statically-linked programs for the rest of us." as "containers can be replaced by statically-linked programs".

If you didn't imply that, I apologize.

If you did mean that, I disagree with you precisely because your point works if you only care about dependency management - it falls apart on system state. A static binary is a process on the host and shares the same process space, network stack, and filesystem.

OTOH, a container is a jail (the primary usecase): I can't cgroup a static binary's memory usage or give it a virtual network interface without reimplementing "container lite". Containers aren't just 'statically linked programs' - they allow me to use the kernel as a hypervisor for isolated environments.

What they are though, a messy but practical compromise to Unikernels - which was my last point in our GP.

[stavros]

Oh, no, I meant that containers serve the same purpose as statically linked programs for languages that can't do that. Eg if you want to deploy a Python codebase, a container is a good way to include all dependencies.

I didn't mean "containers don't have any advantages compared to statically linked programs".

[r_lee]

I 100% thought you were yelling a the clouds lol. see it way too often on HN