Containers should just be the new static binary. Instead, we have Docker "Daemon"'s that can crash.
However, I've also been thinking about ways to defend against hostile containers. And it turns out that a lot of the tricks you need to do are very hard if you don't use a daemon and are impossible if you don't want to pollute the host namespaces.
I've spoken to Vish (the author) and we'll see if we can include some of my architecture reworks into railcar or if I'll go off and do my own thing.
Oh, and by the way, if you like runc's design you should probably go look at rkt. I'm planning on putting in the work to make rkt work without systemd, but the really nice thing about rkt is that it's architecture is also completely daemonless.
lxc and lxd have quite a large amount of very interesting technology and features. lxd has live migration and a whole host of other cool features, and lxc is quite well designed from my experience. Also the developers are quite clever folks IMO. I've been bouncing some of my ideas for a new container runtime off them, since they also have seen the issues I've seen with the current state of things.
The big difference is that lxc/lxd is designed to "boot" an operating system as a container, not just to run a single application. While there is actually no significant technical difference between the two usecases, the features that have grown out of each runtime are tailored for those usecases. lxc lets you log into a console (in the same way you would on a physical box) and do a full getty login. runc has tools for managing containers in a far more "micro-service" sense.
I really wish that the lxc folks had helped us with the OCI, but I have a feeling their usecases are so different to us that it's unlikely we could reach agreement in the spec. Overall though, lxc definitely has a place and it's a shame more people don't try it out.
https://www.kernel.org/doc/Documentation/admin-guide/binfmt-...