4 ms·

Isn't it essential an alternate implementation of the same underlying spec? (appc). I don't think they need to "beat" docker to have a viable product.

fapjacks 11y ago
No, you're totally right. But Billy the Programmer who first looks at containerizing his application (or dev environment or whatever) is going to choose Docker, because that's what everyone else is doing. Not to sound trite, but most people defer technical decisions to other people. This is the reason so many Windows machines exist, and why it has such a huge market share: End users don't know and don't care, they just pick what the manufacturer installs on the device. They are outsourcing their technical decisions (exactly like most distros did with systemd and the Debian TC). It's the classic appeal to popularity, which is totally how most people (even technical people) make the decision of which software to use.
- IanCal 11y ago
  There's another reason too, if more people are using X then I'm far more likely to be able to find help getting over whatever problem I hit.
  - fapjacks 11y ago
    Yes totally this! I spend a huge amount of time in #docker on Freenode pointing people at resources to solve their problems. I am fairly regular in my "there is no right answer, just the best answer for your environment" attitude, but I always point exactly at what you've said: "But if you do it this way, there's a huge amount of prior work done solving this problem versus the way you want to go"...
bpicolo 11y ago
To be fair, docker defined appc.
- cyphar 11y ago
  No, Docker defined the open containers spec (runC). appc is something else.
cyphar 11y ago
> Isn't it essential an alternate implementation of the same underlying spec? (appc). No, appc and open containers are two separate specs. Not to mention that Docker doesn't actually implement the open containers spec (it hooks into libcontainer, which is the body of the implementation of the spec -- runC).

fapjacks 11y ago

No, you're totally right. But Billy the Programmer who first looks at containerizing his application (or dev environment or whatever) is going to choose Docker, because that's what everyone else is doing. Not to sound trite, but most people defer technical decisions to other people. This is the reason so many Windows machines exist, and why it has such a huge market share: End users don't know and don't care, they just pick what the manufacturer installs on the device. They are outsourcing their technical decisions (exactly like most distros did with systemd and the Debian TC). It's the classic appeal to popularity, which is totally how most people (even technical people) make the decision of which software to use.

IanCal 11y ago
There's another reason too, if more people are using X then I'm far more likely to be able to find help getting over whatever problem I hit.
- fapjacks 11y ago
  Yes totally this! I spend a huge amount of time in #docker on Freenode pointing people at resources to solve their problems. I am fairly regular in my "there is no right answer, just the best answer for your environment" attitude, but I always point exactly at what you've said: "But if you do it this way, there's a huge amount of prior work done solving this problem versus the way you want to go"...

bpicolo 11y ago

To be fair, docker defined appc.

cyphar 11y ago
No, Docker defined the open containers spec (runC). appc is something else.

cyphar 11y ago

> Isn't it essential an alternate implementation of the same underlying spec? (appc). No, appc and open containers are two separate specs. Not to mention that Docker doesn't actually implement the open containers spec (it hooks into libcontainer, which is the body of the implementation of the spec -- runC).