4 ms·

Brandon, let me respectfully ask you 3 questions: 1) As you very well know, Docker is already working on cryptographic signature, federated DNS based namespace

by shykes 12y ago

Brandon, let me respectfully ask you 3 questions: 1) As you very well know, Docker is already working on cryptographic signature, federated DNS based namespace and simple hosting on object stores. If you "would like to see convergence", why didn't you join the effort to implement this along with the rest of the Docker community? The design discussion has been going on for a long time, the oldest trace I can find is at https://github.com/docker/docker/issues/2700 https://github.com/docker/docker/issues/2700 , and the first tech previews started appearing in 1.3. Yet I can't find a single trace of your participation, even to say that you disagree. If you would like to see convergence, why is that? 2) You decided to launch a competing format and implementation. That is your prerogative. But if you "would like to see convergence", why did you never inform me, or any other Docker maintainer, that you were working on this? It seems to me that, if your goal is convergence, it would be worth at least bringing it up and test the waters, ask us how we felt about joining the effort. But I learned about your project in the news, like everybody else - in spite of having spent the day with you, in person, literally the day before. 3) Specifically on the topic of your pull request (which we also received without any prior warning, conveniently on the same day as your blog post). So now we have 2 incompatible formats and implementations, which do essentially the same thing. Once we finish our work on cryptographic signature, federated dns based naming etc, they will be functionally impossible to distinguish. How will it benefit Docker users to have to memorize a new command-line option, to choose between 2 incompatible formats which do exactly the same thing? I understand that this creates a narrative which benefits your company, CoreOS. But can you point to a concrete situation where a user's life will be made better by this? I can't. I think it's 100% vendor posturing. Maybe it's bad PR for me to say this. But it's the truth. Give me a concrete user story and I will reconsider.

stonogo 12y ago
There is nothing "respectful" about anyone's behavior on either side of this trainwreck, and calling each other out on a web forum isn't going to help anything.
xnxn 12y ago
I've got a use case. ACI support would let me use containers without being coupled to Docker's registry. I really don't want to run that software, and I really, really don't want to rely on Docker Hub. ACI's use of existing standards for their "registry" implementation is a major draw for me.
- conradk 12y ago
  Actually, I think you don't have to rely on Docker's registry: - you can simply use Dockerfiles and build your own images, - apparently, it seems like you can host your own registry [1] - you can even use a service run by CoreOS, ie Quay, to host your Docker images [2] I'm not sure I understand what you mean by "I really don't want to run that software". Does it mean you don't want to use Docker ? [1] https://blog.docker.com/2013/07/how-to-use-your-own-registry/ https://blog.docker.com/2013/07/how-to-use-your-own-registry... [2] https://quay.io/ https://quay.io/
  - xnxn 12y ago
    To clarify, I don't want to run my own registry and I don't want to rely on any third party for image hosting. I just want to pull tarballs from a dumb file server. No need to run a registry for that, and no one company has a privileged position in the namespace. It's maddening, because I love Docker-the-concept but not Docker-the-implementation nor Docker-the-ecosystem. I honestly do understand how many would find the UX of "Docker, Inc. at the center of things" to be a refreshing convenience, but to me that notion is frustrating and repellent, as much so as if Git remotes defaulted to GitHub.
    - bmelton 12y ago
      > I just want to pull tarballs from a dumb file server. Is there something I'm missing that you couldn't just use wget? If you have the URIs, I can't imagine how pulling down an image by name would be more than a quarter-page Python script, even if you include the untarring and such.
      - 12y ago
panarky 12y ago
> How will it benefit Docker users to have to memorize a new command-line option User here. I couldn't care less about a new command-line option, but it would be worth a lot if I could run any image on any platform. If you claim this is "all about the user" then talk more about what the user gains or loses. Is the biggest downside really just another command-line option? Docker already has a metric fuckton[1] of command-line options, what's one more? Impugning the motives of your competitor is at best an irrelevant distraction, and at worst an indictment of your own motives. [1] https://docs.docker.com/reference/commandline/cli/ https://docs.docker.com/reference/commandline/cli/
- rdtsc 12y ago
  > but it would be worth a lot if I could run any image on any platform. That technology exists, it is called a VM. Any platfrom that supports x86 for example will run any x86 compatible image. You can use wrappers and scripts like Vagrant on top of it. Or if you want all hosting managed as a pool of resources (storage, CPU) try something like oVirt. http://www.ovirt.org/About_oVirt http://www.ovirt.org/About_oVirt
  - vidarh 12y ago
    And VMs far more heavy-weight and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads
    - rdtsc 12y ago
      > and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads I was responding to one reason -- which is "running any image on any platform". > why people prefer containers to VMs for some types of workloads Sure but there are no magic unicorns underneath, knowing what you get from a technology requires some understanding on how it works. Saying things like "I want very lightweight but also want it to run any image on it" is asking for a trade-off. Or a complicated multi-host cabaility based platform.
philips 12y ago
shykes, I will follow up to all of this on the proposal on GitHub.

by shykes 12y ago

stonogo 12y ago

There is nothing "respectful" about anyone's behavior on either side of this trainwreck, and calling each other out on a web forum isn't going to help anything.

xnxn 12y ago

I've got a use case. ACI support would let me use containers without being coupled to Docker's registry. I really don't want to run that software, and I really, really don't want to rely on Docker Hub. ACI's use of existing standards for their "registry" implementation is a major draw for me.

conradk 12y ago
Actually, I think you don't have to rely on Docker's registry: - you can simply use Dockerfiles and build your own images, - apparently, it seems like you can host your own registry [1] - you can even use a service run by CoreOS, ie Quay, to host your Docker images [2] I'm not sure I understand what you mean by "I really don't want to run that software". Does it mean you don't want to use Docker ? [1] https://blog.docker.com/2013/07/how-to-use-your-own-registry/ https://blog.docker.com/2013/07/how-to-use-your-own-registry... [2] https://quay.io/ https://quay.io/
- xnxn 12y ago
  To clarify, I don't want to run my own registry and I don't want to rely on any third party for image hosting. I just want to pull tarballs from a dumb file server. No need to run a registry for that, and no one company has a privileged position in the namespace. It's maddening, because I love Docker-the-concept but not Docker-the-implementation nor Docker-the-ecosystem. I honestly do understand how many would find the UX of "Docker, Inc. at the center of things" to be a refreshing convenience, but to me that notion is frustrating and repellent, as much so as if Git remotes defaulted to GitHub.
  - bmelton 12y ago
    > I just want to pull tarballs from a dumb file server. Is there something I'm missing that you couldn't just use wget? If you have the URIs, I can't imagine how pulling down an image by name would be more than a quarter-page Python script, even if you include the untarring and such.
    - 12y ago

panarky 12y ago

> How will it benefit Docker users to have to memorize a new command-line option User here. I couldn't care less about a new command-line option, but it would be worth a lot if I could run any image on any platform. If you claim this is "all about the user" then talk more about what the user gains or loses. Is the biggest downside really just another command-line option? Docker already has a metric fuckton[1] of command-line options, what's one more? Impugning the motives of your competitor is at best an irrelevant distraction, and at worst an indictment of your own motives. [1] https://docs.docker.com/reference/commandline/cli/ https://docs.docker.com/reference/commandline/cli/

rdtsc 12y ago
> but it would be worth a lot if I could run any image on any platform. That technology exists, it is called a VM. Any platfrom that supports x86 for example will run any x86 compatible image. You can use wrappers and scripts like Vagrant on top of it. Or if you want all hosting managed as a pool of resources (storage, CPU) try something like oVirt. http://www.ovirt.org/About_oVirt http://www.ovirt.org/About_oVirt
- vidarh 12y ago
  And VMs far more heavy-weight and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads
  - rdtsc 12y ago
    > and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads I was responding to one reason -- which is "running any image on any platform". > why people prefer containers to VMs for some types of workloads Sure but there are no magic unicorns underneath, knowing what you get from a technology requires some understanding on how it works. Saying things like "I want very lightweight but also want it to run any image on it" is asking for a trade-off. Or a complicated multi-host cabaility based platform.

philips 12y ago

shykes, I will follow up to all of this on the proposal on GitHub.