new | show | ask | jobs Github

jstanley 4 days ago

> 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.

▲

PunchyHamster 4 days ago | parent | next [-]

Legacy apps are far nicer if they are containerized.

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 ?

▲

stavros 4 days ago | parent | prev | next [-]

Containers are just statically-linked programs for the rest of us.

▲

subhobroto 4 days ago | parent [-]

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 4 days ago | parent [-]

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

▲

subhobroto 4 days ago | parent [-]

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 4 days ago | parent [-]

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 4 days ago \| parent [-]
		I 100% thought you were yelling a the clouds lol. see it way too often on HN

▲

turtlebits 3 days ago | parent | prev [-]

The problem is that running programs isn't always trivial.

I have no interest in going back to the hell that is deploying a java app.