I think the point is that it's not magic, but a very clear and obvious system that's been created using native tools. I've run into a lot of people (including Senior SRE/DevOps people) who don't realise that Containers are just another process running on a system.

Sure, but his explanation of that point is vastly over simplifying what is happening. `Containers are chroot with a Marketing Budget` implies that they are basically the same when in fact the technology behind containers more or less completely rewrote the way that the kernel thinks of processes in order to work properly.

Rather than trying to associate containers with chroots, it would have been way better to go the other way. You ssh terminal? That is effectively a container. Xorg? Yea that's a container too and for convince they share the same resources. There is absolutely nothing that says that the desktop need run in the same namespace as init or that two users logged into the same machine need have the same view of the file system and networking setup. `ls /` from one user can return a completely different set than `ls /` from another and all of this is because containers are just processes, and processes are way more than just a pid in a table.

If that is how a system behaved, I, as a user, would pull my hair out.

"How can you not see that file? It's right there!"

It'd be a great way to cement job security in IT

To be fair I am right there with you, I was just pointing out how nifty they can be conceptually.

How is this for a real world example, that wifi interface that you configured via the GUI and clicked "do not share with other users" exists exclusively in your users namespace, ifconfig only shows it to you, other users simply don't see it and have no access to its routes? Is that a saner example of how this implementation can be used?

Practically, it can be done in a sane way like with Plan9's ubiquitous, per process vfs namespaces.

A container is not a process.

It’s an execution environment created by namespaces (mount, pid, network, others) and cgroups.

A container can house many processes.

^-- this!

Also, a container can house a container.. kind of. If you think of containers like file system inodes then there is a logical view of containers container1: (init -> dockerd) -> container2: (init -> dockerd) -> container3: (init -> dockerd) -> container4: (process) is perfectly feasible and from our view there is a hierarchy of containers, but in reality it would be possible assign a process in container4 to container1 and create all kinds of cool logical loops. This is effectively what a daemonset is in kubernetes. =)

In reality there is no such thing as a 'container'.

You can create an incredible self-intersecting mess of process namespaces.

It is not what you want to do in production.

Also, docker is an overengineered mess. Kubernetes only an couple of orders of magnitude more so.

On Windows and Macs Docker uses VMs ...

I think the DEV community really needs a new definition of "containers" and one that is not backed by implementation details of Docker Linux.

When running, containers aren’t anything more than composed process isolation primitives like chroot. Docker’s main innovation was the layering system, which made it feasible to build and distribute the large images required to ship an entire system in a container.