3 ms·

It might be worth pointing out that Alupis (OP), and Shykes (Docker creator), have had somewhat of a flame war on HN since Rocket was announced.

Alupis 12y ago
I wouldn't really call it a flame war... more or less pointing out issues with Docker the company. I feel it's greatly important since container technology is poised to become a very big thing in the Unix ecosystem and we should take a moment to think about the motives of a commercial for-profit company such as Docker, before we embed it into everything. Shykes seems to take issue with me pointing these things out, as I would expect him to. Anyway, that does not change the content of Shykes' message on Github, which makes it outstandingly clear he, and Docker, have absolutely zero intention of collaborating openly on a standardized container format. They had zero intention of creating a standard format prior to the Rocket announcement, and just last night have published their own proprietary and incompatible specification which they now call the standard. That's not collaboration...
- fluidcruft 12y ago
  Is there anything technically wrong with the Docker format, or do you just have doses of Lovecraftian fear and uncertainty to offer?
  - Alupis 12y ago
    The issue with the Docker format is that there was no format, at least a standardized one. The image format has changed, and without a formal format specification, it's subject to future change. That makes it difficult to rely on when building 3rd party tools, or alternative runtimes. I'd argue that a single, universal standardized container format specification is crucial for such a piece of technology that will soon be (is?) at the heart of all application deployments, both servers and desktops. We can look at the OVF specification[1] for a clear example of why this is necessary. Back in 2007 the top hypervisor vendors (VMware, Dell, HP, IBM, Microsoft and XenSource) collaborated and created thhe OVF spec which would allow a virtual machine which conformed with the spec to be portable between any of their hypervisors. This enabled users to switch at-will, and provided great orchestration between clusters of heterogeneous hypervisors. We've seen how successful a format is when a single for-profit company self-declares their format as the "standard" for all others to adhere to -- .RPM promoted by Red Hat. Even today, there are systems that do not use RPM's because there never was a consensus around what that format should look like -- It was just declared one day it was the standard because they had market share.[2] A world where one becomes locked into any single vendor for any piece of technology is not good to say the very least. An inter-operable, collaborated standard is what is necessary. [1] http://en.wikipedia.org/wiki/Open_Virtualization_Format http://en.wikipedia.org/wiki/Open_Virtualization_Format [2] http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_RPM_package_format http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_R...
    - belak 12y ago
      we should take a moment to think about the motives of a commercial for-profit company such as Docker, before we embed it into everything. Shykes seems to take issue with me pointing these things out, as I would expect him to. What about the motives of CoreOS, also a for profit company? I'd argue that a single, universal standardized container format specification is crucial for such a piece of technology that will soon be (is?) at the heart of all application deployments, both servers and desktops. Correct me if I'm wrong, but doesn't the new container proposal do the exact opposite of this? Why not collaborate with Docker on a container format? From the Github post: But here's a suggestion for you. If you were to complain that Docker's image format and runtime specification, as massively adopted as it is, is not appropriately documented, and it could be made easier to produce alternate implementations - then I would completely agree with you. You state that Docker has absolutely zero intention of collaborating openly on a standardized container format however they explicitly invite help into standardizing and documenting theirs, which is currently the most commonly used. This is the last thing I'm going to leave here. http://xkcd.com/927/ http://xkcd.com/927/ It may not be the most credible of sources, however it makes the point I am trying to make quite well. Making an additional standard when there is already something well established does nothing but fragment the ecosystem. You may be questioning the motives of Docker, Inc, however that leaves the rest of us to question the motives of CoreOS. I did not seen ANY efforts at collaboration by CoreOS before they released their own container format/runtime. Especially in the passive-agressive (mostly agressive) way in which they did it. If their motives were truely to create a "single, universal standardized container format specification", the first step would have been to at least attempt to work with Docker to create this. Instead of this happening, this whole argument has turned into a pissing match between the two companies. Seriously, both companies need to set aside their differences and have a real discussion about this, not just doing things on the internet to piss each other off.
- debacle 12y ago
  It was a PR filtered flame war.

Alupis 12y ago

I wouldn't really call it a flame war... more or less pointing out issues with Docker the company. I feel it's greatly important since container technology is poised to become a very big thing in the Unix ecosystem and we should take a moment to think about the motives of a commercial for-profit company such as Docker, before we embed it into everything. Shykes seems to take issue with me pointing these things out, as I would expect him to. Anyway, that does not change the content of Shykes' message on Github, which makes it outstandingly clear he, and Docker, have absolutely zero intention of collaborating openly on a standardized container format. They had zero intention of creating a standard format prior to the Rocket announcement, and just last night have published their own proprietary and incompatible specification which they now call the standard. That's not collaboration...

fluidcruft 12y ago
Is there anything technically wrong with the Docker format, or do you just have doses of Lovecraftian fear and uncertainty to offer?
- Alupis 12y ago
  The issue with the Docker format is that there was no format, at least a standardized one. The image format has changed, and without a formal format specification, it's subject to future change. That makes it difficult to rely on when building 3rd party tools, or alternative runtimes. I'd argue that a single, universal standardized container format specification is crucial for such a piece of technology that will soon be (is?) at the heart of all application deployments, both servers and desktops. We can look at the OVF specification[1] for a clear example of why this is necessary. Back in 2007 the top hypervisor vendors (VMware, Dell, HP, IBM, Microsoft and XenSource) collaborated and created thhe OVF spec which would allow a virtual machine which conformed with the spec to be portable between any of their hypervisors. This enabled users to switch at-will, and provided great orchestration between clusters of heterogeneous hypervisors. We've seen how successful a format is when a single for-profit company self-declares their format as the "standard" for all others to adhere to -- .RPM promoted by Red Hat. Even today, there are systems that do not use RPM's because there never was a consensus around what that format should look like -- It was just declared one day it was the standard because they had market share.[2] A world where one becomes locked into any single vendor for any piece of technology is not good to say the very least. An inter-operable, collaborated standard is what is necessary. [1] http://en.wikipedia.org/wiki/Open_Virtualization_Format http://en.wikipedia.org/wiki/Open_Virtualization_Format [2] http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_RPM_package_format http://en.wikipedia.org/wiki/Linux_Standard_Base#Choice_of_R...
  - belak 12y ago
    we should take a moment to think about the motives of a commercial for-profit company such as Docker, before we embed it into everything. Shykes seems to take issue with me pointing these things out, as I would expect him to. What about the motives of CoreOS, also a for profit company? I'd argue that a single, universal standardized container format specification is crucial for such a piece of technology that will soon be (is?) at the heart of all application deployments, both servers and desktops. Correct me if I'm wrong, but doesn't the new container proposal do the exact opposite of this? Why not collaborate with Docker on a container format? From the Github post: But here's a suggestion for you. If you were to complain that Docker's image format and runtime specification, as massively adopted as it is, is not appropriately documented, and it could be made easier to produce alternate implementations - then I would completely agree with you. You state that Docker has absolutely zero intention of collaborating openly on a standardized container format however they explicitly invite help into standardizing and documenting theirs, which is currently the most commonly used. This is the last thing I'm going to leave here. http://xkcd.com/927/ http://xkcd.com/927/ It may not be the most credible of sources, however it makes the point I am trying to make quite well. Making an additional standard when there is already something well established does nothing but fragment the ecosystem. You may be questioning the motives of Docker, Inc, however that leaves the rest of us to question the motives of CoreOS. I did not seen ANY efforts at collaboration by CoreOS before they released their own container format/runtime. Especially in the passive-agressive (mostly agressive) way in which they did it. If their motives were truely to create a "single, universal standardized container format specification", the first step would have been to at least attempt to work with Docker to create this. Instead of this happening, this whole argument has turned into a pissing match between the two companies. Seriously, both companies need to set aside their differences and have a real discussion about this, not just doing things on the internet to piss each other off.
debacle 12y ago
It was a PR filtered flame war.