It can also be done on Linux. Docker might not be able to do it, but that's because of its architecture and the language it's written in. There's no kernel limitation like that.

I think Joyent has pushed the limits of what is possible in that area with their tech. From the dev/ops point of view I run docker container / images and they "translate" docker api calls into smartos/opensolaris/illumos zones. NB I don't know much about those OSs/projects.

Docker has a nice and evolving API and OS zones provide an amazing core technology.

Right, but that's because they don't actually run Docker. They have a much better designed manager process that creates LX-branded zones.

My point was that "Linux containers" (so tools like LXC, or runc, or others) are more than capable of being used in this way. Docker has a variety of architectural and other problems that result in it not being as friendly to this kind of use case.

So when you run "docker containers" on Joyent they just untar the image and run it in an LX-branded zone. There is no Go or other problems and they sure as hell don't run Docker as root in their control plane.

Yeah yeah, sorry for not being clear. I understand that they don't use docker and just make their api to quack like a docker.

What are some container technologies that could be used for this right now?

Namespaces and cgroups (using overlayfs to get page cache sharing for the main process mappings in each container). This is a bit of a coy response, but if you have a usecase where other container solutions have a high start-up cost -- write your own. You can write a basic container runtime in tens of lines of shell script.

For existing container glue -- you could probably do this with runc (though unfortunately we are also written in Go) and the architecture is such that runc has no long-running process (only your container continues running after we've set it up). I believe LXC can also produce similar tenancy (and they're written in C which avoids quite a few of the Go problems).

chroot, cgroup, and the systemd run facilities (systemd-nspawn for example).

pivot_root, not chroot. chroot is vulnerable to many trivial escapes.

Probably, but for Solaris it’s native out-of-the-box technology.

What about the language limits the number of containers?