[lomnakkus]

(I didn't downvote you, just FTR.)

I think this is the kind of thing that might be at issue: https://github.com/docker/docker/issues/6791 [1] (I realize that the ticket is not closed, I just bring it up as an example of something that I see as counter to commoditization and thus counter to my goals as a user.)

One of the issues that I personally have with docker (much as I love it) is that it also wants to be a process supervision "framework" (for lack of a better word). I don't want that, I want a reliable way to supervise a docker-started process from whatever supervisor daemon that I want (whether that be systemd, runit, or whatever). This is not really for ideological reasons -- I want something that integrates properly into my distribution of choice, not something that wants to be a system unto itself.

[1] ... I'm obviously not the submitter of this issue. I just stumbled upon it during a related search.

[shykes]

I understand, but the problem is that to "just run a container" Docker needs to manage global system state and synchronize with other docker instances. Right now that is done with the daemon. How do I do this without? CoreOS's answer is basically "systemd should do all that". But to me that is not an acceptable answer. I don't want to tie Docker to systemd. It's already too monolithic as it is. Do we really want to absorb the docker daemon's functionality into it too? Because that's exactly what CoreOS is proposing with Rocket. I think that's a flawed design and the opposite of composable.