What i find odd is that he is ranting as if it is a code problem when it is a package manager problem.
Unless i am badly off the mark, ld will use soname to tell lib v1.0 from v1.1 or v5.97. But the problem is with package manager flatly refusing to have anything to do with installing multiple lib versions side by side.
That is, if they have the same package name. End result is that one distro use glib3.xyz to designate glib 3.x, while another use glib-3.xyz Yet another use glib.3.xyz.
They all hold the same files, but for the package managers they are different packages. And will resolve dependencies based on that.
Applying containers and/or sandboxes to this is a Will E. Coyote solution...
It is not just this. It is also that RHEL 6 will have libfoo4, while Ubuntu 14.04 will have libfoo6, and then Debian Wheezy will have libfoo5. Even if the way the packages dependencies were expressed (libfoo-1-3 vs. libfoo3) were the same, the constant ABI breakage would be harmful.
But that problem is largely because of what i started out with, that their package managers can't handle having multiple version of libfoo installed under the same package name. Even tough ld and friends can via soname.
So they "avoid" it by insisting on using a specific version for the duration of the distro version.
Actually, everything that enables Docker is provided by the OS. AppArmor, SELinux, cgroups are all isolation capabilities provided by Linux. What you're seeing is libraries building on it finally becoming high-level enough that regular people are able to take advantage of them.
Right, but the fact that such large ecosystems have originated out of these high-level abstractions (on top of Docker you have all the container clustering and orchestration platforms, homegrown PaaS and whatnot) shows that there is indeed something lacking.
What the OP probably meant is that none of these solutions are actually a seamless part of the workflow when using the OS.
Isolation is possible in a multi-user system with text-mode apps (ncurses and such), just xorg presents a privilege hole that can't be easily plugged. One way to do it may be to run a separate instance of X inside the container and access it via VNC from the host system.
Wayland is another, probably simpler, alternative.
One thing, though: Docker itself presents a privilege hole that can't be easily plugged, too. That's a large part of why I've expressed alarm upthread.
