I guess that depends on who you ask at Docker...
To be fair, the filing of this "Docker is not compatible with ACL" issue is a bit premature when the spec barely exists yet.
Especially when the request was not worded as "we're trying to standardize this, want to help out", but "we ARE the standard, comply with us".
CoreOS comes off in this exchange looking the very worst sort of VC vaporware wannabes, and that's what I'm going to remember a year or two down the line (assuming they even still exist at that point) if faced with an actual choice involving them.
I had no negative opinion about either company but to me it's clear Solomon has come off very poorly and undiplomatic from this whole exchange. CoreOS has done nothing wrong, they are not obligated to do whatever Docker Inc. or Solomon wants them to do. And of course neither does Docker have to do whatever CoreOS maintainers might want of them, but one side is mudslinging and bickering while the other isn't, very childish IMHO.
EDIT: Let the users work this out, if Rocket fulfills a need for some people better than Docker does for CoreOS then it will become clear overtime. Docker does need leadership, but not by picking pointless fights.
I think the users have already decided, pretty much everyone uses docker already.
Nope. For forking Linux, changing the behaviour and then telling Linux to comply with it he has bitten several heads off though.
Maybe I missed it, but I never got the impression that CoreOS was as bullish as you say. If Docker wasn't moving in the direction of container standardization, then someone needed to step up and do it, and I'm glad CoreOS is doing so.
The final container standard 1.0 might not be based on CoreOS's proposal at all, and hopefully it's more compatible with today's de facto Docker containers, but the important thing is that standardization is part of the conversation now.
What is Solomon supposed to do? He explained very clearly his thoughts about standards. It's actually a very reasonable (if a bit defensive) response.
Docker should adhere to the App Container Image (ACI) specification.
I might not have used the same tone as Solomon here but the issue is not exactly worded diplomatically either, particularly given the current tone right now around these two projects.
Nonetheless, I don't think it's written strongly at all. It's a succinct, plainly worded feature request. My favorite kind.
It's a snarky bug report. It's like asking the Linux kernel to adhere to Microsoft' standards. Except in this case it would be a start-up with vaporware. I hope CoreOS makes rocket into something awesome, but it pretty arrogant to assume the huge project would start following a standard of a 3 day old project.
And regards to @shykes response, he was right on all points. Who in their right mind would adopt a supposed "Standard" written only 3 days ago? Doesn't matter who wrote it, it is just very unreasonable to accept a Standard without putting it through the test of time. This is a Standard, once in place you can't really change later, so aren't you glad that they didn't just jump on things?
Also, if you are in Docker's position, why would you want to risk limiting yourself to a single standard? Things change, fads change, people come up with better ideas, etc... No one knows. Some may want a much simpler spec (I for one), others may want something more thorough and detailed, etc. Just let the people decide the standard and let it run it's course, eventually the best will come out on top.
As someone who hasn't invested a lot of time in evaluating CoreOS yet I would be interested in hearing about what other pain points you encountered. The reboot to update requirement seems straightforward given what they state in their documentation https://coreos.com/using-coreos/updates/
Rocket & App Container Spec Overview by Brandon Philips - (https://www.youtube.com/watch?v=GYgpaAZMe-E)
Rocket Tutorial and Demo by Kelsey Hightower - (https://www.youtube.com/watch?v=E9WVjxaRkKU)
Google Hangout with CoreOS: Rocket and the App Container Spec - (https://www.youtube.com/watch?v=U3UmFQbUsN8)
Maybe I'm missing something, but this completely ignores that the biggest security issue is people and process. You can't require people to have good process. IMHO, requiring gpg signatures WEAKENS security, because the people that don't care or don't have strong security requirements are going to play fast and loose with their keys. If you don't require gpg signatures, you can let those people signal their lack of security by having "naked" images. (ie: a security audit will catch that really fast and then force a reasoned discussion about key trust)
Requiring gpg signatures gives the illusion that all of the images are somehow more secure.
People have too many opinions about stuff.