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