Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Okay awesome. So then why is my base image called Ubuntu 18.04? It sounds like theres an OS there. That's why I intuitively assemble a model of there being an OS. Not that I'm asking you to explain, but that I wish educational content could start from a common place and explore why it's different.

View on HN

Different Linux distributions ship with various package managers / other userspace tooling. But they all run on top of the Linux kernel. I can see how having a base image called "Ubuntu 18.04" might make it seem like there's an entire OS running in the container but that's not the case. Check out this Ubuntu base image Dockerfile https://github.com/tianon/docker-brew-ubuntu-core/blob/bcdd3..., you can see that it's throwing a tarball for the root filesystem into the container (and some Docker-specific stuff), nothing crazy.

The kernel is a tiny, insignificant part of what makes Ubuntu Ubuntu.

Running an Ubuntu user land on top of some generic other Linux kernel will for almost all practical purposes feel the same as running real Ubuntu.

Ubuntu is just a collection of software. The most important piece of software in that collection is the Linux kernel.

That kernel is what is shared between different containers. You can have 5 copies of Ubuntu (or Debian, or Mint) in separate containers, but they're all using the same kernel. This is what makes containers much more efficient than multiple full VMs.

Depends what you mean by OS. There isn’t a kernel but there is an entire user space with an init process, so the GNU part of GNU/Linux.

In your example, the docker image makes a certain presumption - the presumption is that the OS that the host is going to run is Ubuntu-ish and 18.x generation-ish and probably runs on a 64bit amd_64. So unless your code is very complicated, then probably by pulling Ubuntu 18.04 libraries and setting some linker rules things are going to work on most systems.

Reply on news.ycombinator.com