The current app container model as it is takes the form of binary images managed by a de facto runtime that enforces namespace, cgroup and other boundaries by using kernel subsystems for logical partitioning.

Unlike system containers like LXC, appc means you now have an explosion of the state space whereby every container has their own independent copy of a host OS, yet relies on the semantics of its container manager to function, i.e. it is not easily introspectable with vanilla tools.

So you end up needing to build a small parallel userspace to handle things like service discovery, orchestration and provisioning, networking bridges, location transparency, resource scheduling and taken to its logical conclusion you start running a user-mode kernel (Mesos) on top of a base OS kernel (Linux) to provide further abstractions of OS resources and run extended versions of OS processes called frameworks.

I don't know if it's too early to tell, but I think people might have dug themselves into a ditch where in an attempt to escape the limitations of their kernel and userland, they've only expanded it with a concurrent layer and must maintain both.

> So you end up needing to build a small parallel userspace to handle things like service discovery, orchestration and provisioning, networking bridges, location transparency, resource scheduling

Or you install a PaaS, which does these for you. I've worked on Cloud Foundry, OpenShift is a competitor. Both are far superior to rolling your own.

Yes, agreed, there are already many good OSes that can run containers fine. I run many "containers" (jails) on FreeBSD, I don't need a specialized OS for this. SmartOS can do this well. And like you said, Debian would be fine running Docker or whatever else.

I'm not so sure. General purpose distros are beholden to many interests that are likely to be irrelevant to "just" running containers, and likely to affect decision making regarding features, schedules, and priorities. One of the major advantages of Linux is that it can be customized to suit particular needs; I'm not sure why it is "baffling" to take advantage of that capability to specialize based on narrow and specific use cases.

But it's Docker so we have to rebuild everything multiple times now: six new distributions, twenty new app schedulers, fifty new network stacks. Because Docker.

Well CoreOS (for example) has a different update model, much more frequent, failover back to previous image in case of error and so on, that should help uptime overall. And it has a minimal config that can be set in a single config file. It is a different model.

It's all part of the Docker/Container cash grab I'm afraid.

There is still big amount of specialized software and things like tuned kernels, enhanced networking and so on in such OSes.

For example CoreOS comes with lots of tools helping to orchestrate and manage those clusters.

A specialized kernel package, etc. can be made for any distro.

And after that will be named `AnotherBrandNewOs`.

Why? A new kernel config doesn't change the fact that I'm running <insert distro here>.

edit: the joke flew over my head.

>> `AnotherBrandNewOs`

> Why?

This is kind of irony about today situation in the world of OSes.