As to everything else, I manage CoreOS clusters with docker for now, and while this came out of the blue (seems like for Docker folks as well) I'm happy to see what happens as a result. I'm not sure why there are hurt feelings over the announcement, didn't find anything particularly in bad taste and what exactly is wrong with promoting your new product?
The CoreOS team isn't under any obligation to docker to contribute however anyone on the docker team want's them too. Even if these issues have been discussed before they've clearly taken a different path and that's within their right, not sure where mud is being slung. Where this will lead who knows, but hopefully there will still be good collaboration between different groups as they pursue their own goals that align with their needs.
EDIT: I haven't actually looked at the code, so if somebody wants to prove what I'm saying wrong please do. I'm basing what I know off the announcement.
Often, starting from scratch is better. This is especially true when the goals or philosophy of the two projects are fundamentally different and incompatible, even if they perform similar tasks. Again, linux vs windows example applies.
That said, you're on point: this is forking the community. A hard fork, too.
"Unfortunately, a simple re-usable component is not how things are playing
out. Docker [much to our dismay] now is building tools for launching cloud
servers, systems for clustering, and a wide range of functions: building
images, running images, uploading, downloading, and eventually even overlay
networking, all compiled into one [big and nasty] monolithic binary running
primarily as root [how insecure is that?] on your server. The standard
container manifesto was removed [those flip-floppers!]. We should stop
talking about Docker containers, and start talking about the Docker
Platform [since we can focus attention on our efforts that way]. It is not
becoming the simple composable building block we had envisioned [which puts
our offerings at a disadvantage]."
"We still believe in the original premise of containers that Docker
introduced, so [unlike those silly Docker people] we are doing something
about it."
Later on, they specifically say: "the Docker process model ... is fundamentally flawed"
"We cannot in good faith continue to support Docker’s broken security model..."
All these may be valid criticisms, but even ignoring my potentially off-base annotations it's difficult to read their announcement as anything other than "Docker is broken and can't be fixed". It's reminiscent of political attack ads which focus on the shortcomings of your opponent rather than the strengths of your own platform.Or, taking the announcement as intended, "We were interested in the direction Docker started in, they have since pivoted. We were more interested in the direction than Docker itself".
Yes, there is some mild-mannered disparagement in the announcement, but it's hard to characterise it as 'slinging mud', and it's not really fair to disparage it with the name-calling you're injecting.
Right now I'm already taking a Dockerfile, exporting it to a tar, and then running systemd-nspawn -- I love Dockerfiles, I love being able to grab a postgres server and get it up quickly from Docker Hub, but I didn't need or want the rest of docker.
If both Docker and Rocket support ACI, then you have a composable image layer, and that means people aren't locked into either ecosystem just to build images of their applications.
ACI :: Docker-tar-format to me is like QCOW2 :: VMDK. Wouldn't it be cool if projects like Packer[1] didn't have to exist, because the image format of Virtual Machines was open and documented as an independent standard?
[1] - https://www.packer.io/
However I think it makes more sense to do this on the actual Docker format which everyone already uses... That way you get the benefit of increased openness without the drawback of fragmentation. I have the impression I've been pretty vocal in asking for help in making this happen, and wish these guys had stepped in to help instead of forking. I pretty distinctly remember pitching this to them in person.
So, I'll re-iterate my request for help here: I would like to improve the separation between the Docker runtime and packaging system, and am asking for help from the community. Ping me on irc if you are interested.
Whether the work on a standard container format happens inside or outside of Docker, it would result in a format presumably a bit different from how Docker containers are now (e.g. not overlay-layered by default, since most build tooling wants to just output an atomic fileset.) And either way, work would then occur to make Docker support that standard format.
The only real difference is that, in this approach, the ecosystem also gets a second viable runtime for these standard containers out of the deal, which doesn't seem like a bad thing. You can't have a "standard" that is useful in a generic sense without at least two major players pulling it in different directions; otherwise you get something like Microsoft's OpenDocument format.
One could have just as easily said the same thing when the Docker format was introduced. The OpenVZ template format works well and is very similar to the proposed ACI format. The Docker format hasn't been without issue/problems.
[1] - http://en.wikipedia.org/wiki/Open_Virtualization_Format
Is what I should have quoted in my reply. Nobody was talking about using one instead of the other. Though, it'd be easy enough to run, for instance, CoreOS from an OVF image to run containers from. Though, I feel like you and I are just stating the obvious at this point. Wouldn't you agree?
Sigh!
This'll be the last version of Parallels that I buy (thanks Yosemite)
Before Rocket/ACI there wasn't even a contender for Containers. Now there is a published spec. Start there. Iterate.
[1] http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS+469-20...
[2] http://www.iso.org/iso/home/store/catalogue_tc/catalogue_det...
~~~
Frankly, shykes and other Docker employees shouldn't be commenting here. It only serves to make them look petty with any attempt of a "rebuttal" and, as shykes put it, "sling mud". CoreOS made a grand announcement, and yes it competes with Docker... but just let it play out.
Frankly, there is a lot of things Rocket aims to do that are more appealing to me. Security being one of them, and a standardized container specification is another. If anything, it will make Docker compete better.
Can you give three examples of this happening?
Interesting to see you resort to calling your users "trolls" simply because they feel it's not good for you, the head of Docker, to respond off-the-cuff and angry about a PR announcement from a competitor.
> that it is better to take the high road and refrain from answering, and let the company make an official answer
Your company already released an official announcement 2+ hours ago (with much of the same rhetoric as your post here). Seems you didn't even follow your own advice.
> I'm just calling you a troll, and it's for implying that
> a cabal of Docker employees somehow manipulates and
> suppresses the public conversation about containers for
> the profit of their employers.
Really? This strikes you as a good idea?For the first time in Docker's short history, it's future and mission are being directly challenged. This is your response? (it won't be the last time Docker is directly challenged).
Imagine if Microsoft went around rattling the cage every time Apple released some product -- it would make them look pretty petty pretty quickly. Just get out there and compete. Produce a superior product and the market will speak.
You mean like this? https://www.youtube.com/watch?v=eywi0h_Y5_U FIVE HUNDRED DOLLARS FOR A PHONE?
In all seriousness, you made a few blaming statements early on in this thread which is the most likely reason got the reaction you did from Solomon. I'm not opposed to people making observations, but speaking for others really has no place here!
Specifically talking about the "PR machine" comment. Say what you mean!
If they just quietly gave an ambiguous non-disparaging statement like "we're forking because we're unhappy with the direction Docker is taking", it would seem frivolous and ill-considered, and nobody would know on what points the fork would be aiming to distinguish itself.
This statement needs to be made, the way it was made, for the same reasons any project announcement is made: it needs to announce that it exists, and why it exists. It's the same as Docker's "debut" blog post(s).
Every schism needs its 95 Theses, and the odds favor the ones who can read them, understand them, and take them into consideration.
---
Disclaimer (re https://twitter.com/kenperkins/status/539528757711622145): I make edits to my comments after posting, usually posting a line or two then fleshing them out over time. If I make a change that conflicts with a statement in an earlier revision, I'll note it: otherwise I'm pretty much just composing live.