I did not say it is "removed", though. :)

It also does not "hide" it.

https://www.howtogeek.com/733522/docker-for-beginners-everything-you-need-to-know/

Not sure, which resource explains how #Docker works in the best way, but essentially, a container is derived from an image, which (container) only depends on the host's Kernel. Everything else is the container's doing.

Naturally, you usually wouldn't want ultra low level programs to be run inside a container, but this wouldn't make much sense, either way.

Everything else is fine inside containers.

As for your statement regarding "development" & "small setups" I have to oppose that strongly, in its entirety.

I barely setup any app without a Dockerfile, because it's a waste of time & I also do not want to pollute my servers with some Dev crap, because what feels like every Dev on GitHub must create his own shit, without respecting generalised standards.

Especially #Frontend projects are extremely invasive & annoying.

If the project does not deliver a ready made Dockerfile, I create one myself, ad-hoc. No problem.

The only times you get issues with Alpine, is if the maintainers did some nasty stuff, like depending on specific non-portable APIs, etc. Then yeah, you might not be able to `musl` that stuff.

However, even then, you can still use Debian or Ubuntu as a fallback base image, which will work for everything.

If there is ever something that does not work at all inside a #Docker container, it's in 99.9999999999999% of cases the Dev's fault for programming the project in the most non-portable, system-dependent & weirdly discaring way possible.

Like, when they inherently hardcode #SystemD calls into the program. I mean, come on, what the hell is wrong with you...

Needless to say, I naturally run #Kubernetes on my amd64 servers & self-made Docker Compose setups on my #RaspberryPi's.