[shykes]

Yeah we used to call it "standalone mode", it was pretty neat but really confused users (it would auto-detect whether to go daemon mode or not, so behavior became contextual and hard to troubleshoot).

Yes, managing communication or other centralized resources is harder that way which is a challenge for "embedded Docker". Rocket does not have this problem because it relies on systemd to manage all this centrally under the hood. So you get "daemonless" as long as you sweep everything under the giant systemd rug :)

[mpasternacki]

It doesn't need to be systemd, and that's the beauty of Rocket's design: it is composed of individual, well defined pieces with precise boundaries and areas of responsibility. As I wrote, my main practical concern now is to get something container-like working on FreeBSD. Docker is useless here unless it's wholly ported; Rocket is useful even if I don't use its code and go with (even partial) implementation of the spec.

From my practical POV, my options now are: port Docker (NOPE), reimplement Docker (NOPE GOD WHY), port Rocket (Maybe?), reuse spec and pieces of Rocket's code in my own opinionated NIH plumbing (Hell yeah, somebody did the thinking part for me! The spec is usable!), or write own opinionated NIH plumbing from scratch (why would I if there's a decent spec to lean on?).

[Alupis]

This is truly why Rocket is so interesting. The App Container Spec is what is missing from Docker. They had their chance to implement a common universal spec which others could implement independently, but didn't do so. Now CoreOS is picking up the ball and running. I don't see any option for Docker other than to work with CoreOS to form this universal specification, or to adhere to the specification after it's been finalized.