> I know you wanted to "choose boring tech" to just run some containers.
The people advocating for boring tech generally aren't interested in containers.
You can just run programs.
The people advocating for boring tech generally aren't interested in containers.
You can just run programs.
If your app is just a blob that can be run it is fine, but many languages make it more complicate.
I wonder if just putting app into .appimage + using systemd for some of the separation would be a sweet spot ?
If you had said "unikernels" I would have had no arguments to make.
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.
I didn't mean "containers don't have any advantages compared to statically linked programs".
I have no interest in going back to the hell that is deploying a java app.