Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Open Image Spec

I'm wondering if this will eventually merge with the ACI that Rocket implements.



That seems unlikely, based off the bad blood developing between CoreOS and Docker. See the links below:

https://github.com/docker/docker/issues/9538

https://github.com/docker/docker/issues/10643


Wow, those are some pretty hostile words coming from Shykes.

> Coming up with a new "standard", then criticizing the established open-source project for failing to implement it, is a common tactic

> One last fact, which you might find funny: one of these alternative implementations of Docker's image distribution system is developed by CoreOS, the very same vendor which is propping up this so-called standard

> Do you know how many complaints I received, since Docker was created, that I didn't "comply" with this or that self-proclaimed standard? Dozens

> But [CoreOS] never did, because as competing commercial vendors their interest is to weaken and fragment the Docker standard, not contribute to it.

~~

> based off the bad blood developing between CoreOS and Docker

You know, I think this is really 1-way... I have not see anything along these levels of hostility coming from the CoreOS camp.


> You know, I think this is really 1-way... I have not see anything along these levels of hostility coming from the CoreOS camp.

Personally, I agree with you, just trying to stay neutral with my comment. Recently went to a CoreOS meetup in NYC and from what I can tell the CoreOS guys seem super nice and very knowledgeable, nothing else I've seen anyone representing them say or do in public suggests any malice against Docker.


Looks like spam accounts / repeated behaviour which reported these bugs. Even though Shykes isnt the best pr guy in the world.


I'd hardly call 2 issue tickets "spam accounts"... and the first one definitely isn't -- there's years of activity.


I really do not use docker nor coreos, but I wonder what the huge demand is for standardizing this. At least it looks a little suspicious for me while browsing through those 3 tickets.


> but I wonder what the huge demand is for standardizing this.

Containerization on Linux is really poised to be the "next big thing", enabling all sort of new workflows, deployments, etc. In order for it to really take off, people need a universal standard image format which is portable to other implementations. There must be multiple competing implementations. It must avoid vendor "lock-in".

Back when virtualization was getting off the ground, there was no standardized format. Every vendor had their own format, and all were completely incompatible with one another. This made migrations incredibly painful, sometimes impossible.

It created a "vendor lock-in" even when it came to the open source hypervisors -- ie. once you decided on a product, you were stuck.

The OVF (Open Virtualization Format) came along after years of this... not without it's imperfections -- but it was a real life saver in a great many ways. Vendors and open-source projects alike started to support the format, allowing users to export their VM's and import them into a different hypervisor with relative ease -- no weird hacky work-arounds, no re-imaging your vm, no nonsense.

~~~~

For this kind of industry-changing technology, it's more important to have an open standard than an open implementation.


Uses for a standard format are:

Alternate implementations of docker run (e.g. Garden), although a daemonless mode for Docker may satisfy most of these cases.

Alternatives to docker build (plenty of room for innovation here IMO).

Alternative registries.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: