4 ms·

I'm not really sure why the proponents of this split don't just put their efforts into improving one of the alternatives which are already available (e.g. rkt).

I'm not really sure why the proponents of this split don't just put their efforts into improving one of the alternatives which are already available (e.g. rkt). A split would seem to be a bad outcome allround (confusion in the market, divided resources, duplicated features), whereas competing products might bring out the best in each other. Also it does seem a little odd to me to see people suggesting that Docker needs to be more stable and "boring" (from this article https://medium.com/@bob_48171/an-ode-to-boring-creating-open-and-stable-container-world-4a7a39971443#.gux8c0bx2 https://medium.com/@bob_48171/an-ode-to-boring-creating-open... referenced in the main link) to fit in with other projects in this space like Kubernetes, when it seems that most/all of these projects including Kubernetes are moving as fast as each other...

gtirloni 10y ago
The container runtime is a basic building block. If it moves too fast (and in broken ways), stuff on top of it breaks. If Intel processors came with a completely new instruction set in every generation, it'd be hell. I don't think people are suggesting that Docker Inc. should be boring. The criticism is more targeted towards Docker Engine, the container runtime.
- raesene6 10y ago
  Personally I think the entire container space moves too quickly to be a good target for stable long lived services. Pretty much every element is under fast development. Stability is more the attribute of more mature services like Virtual machines, which have been around as a heavily used technology for quite a long time now...
alauda 10y ago
I don't think rkt is a valid candidate. People are already used to the basic of Docker command. There is no reason to change to something else. If rkt decides to reproduce the feature set, how is that different from a fork?
- raesene6 10y ago
  So the challenge, to me, is that if you fork docker, then people are going to have to get used to a different command structure anyway as the forks will diverge. One of the reasons to avoid a fork is the confusion caused by two kind of similar but not quite the same implementations that diverge slowly over time. rkt is unlikely to just copy the feature set of Docker, but they provide competition in implementing new ideas and as it's not intended to be identical there's less confusion.
- creshal 10y ago
  > People are already used to the basic of Docker command. The tiny amount of existing early adopters can be made to adopt something else one more time.
  - lmickh 10y ago
    Not to mention that they constantly break the Docker api and interactions. Knowing the commands today is not helpful in the future. Once you get past "docker run <image>" so much has changed the last couple of years that it is pointless to hold that up as a virtue.
- Svenskunganka 10y ago
  People being used to the Docker commands is a very weak reason rkt isn't a valid candidate. Let's not forget the most important aspect of rkt, and that is that it follows the container spec standard.
falcolas 10y ago
IMO, they shouldn't get behind rkt, because it too is owned and primarily developed by a company who uses it as a commodity to sell their own products as well, and the same concerns arising from Docker wholly owning development against Docker Engine could very easily arise against rkt as well. I believe an independent project managed by a board of shareholders would be better for us all.
- raesene6 10y ago
  I'd agree that if it seems that containerization is a fundamental part of an OS that it would make sense to have a neutral platform for it. That said there were containerization efforts in this area in the past (e.g. LXC) which never really seemed to attract the same kind of traction as Docker. Ultimtely if people want to create containers, it's entirely possible to do with pure linux commands and no upper-level software at all, it's just Docker makes it much easier/nicer to achieve :)
  - bogomipz 10y ago
    I think that LXC was on a good path if you were an Ubuntu shop, however I think that tying LXD to Openstack was an odd choice.
    - tribaal 10y ago
      How is LXD tied to openstack? You can use LXD in exactly the same way you used LXC (with a nicer CLI interface, no less). nova-lxd adds lxd as a "hypervisor" choice for openstack, but it's a completely optional way to use it. Try it on ubuntu right now: sudo apt-get install lxd; lxc list (yes, the client for lxd is called lxc, it's kind of confusing. Sorry.) Disclaimer: I work for Canonical, but not on LXD (I use it daily outside of openstack though)
  - falcolas 10y ago
    > Ultimately, if people wanted to create [text files], it's entirely possible to do with pure linux commands with no upper level software at all, it's just [Sublime Text] makes it much easier/nicer to achieve. It's absolutely possible (see: Bocker), but not a very productive way to go about things. It's much more productive to take an existing technology and make it better than to start from scratch (yet again), especially with permissive licenses like those used in Docker Engine.
jjuel 10y ago
The funny part about this is CoreOS is talked about being one of the players in the article, and they are the developers of rkt.
- raesene6 10y ago
  Indeed, I did think that was rather odd...
- robszumski 10y ago
  From the article: > Spokespeople from ... CoreOS denied any knowledge of Docker-related talks.

gtirloni 10y ago

The container runtime is a basic building block. If it moves too fast (and in broken ways), stuff on top of it breaks. If Intel processors came with a completely new instruction set in every generation, it'd be hell. I don't think people are suggesting that Docker Inc. should be boring. The criticism is more targeted towards Docker Engine, the container runtime.

raesene6 10y ago
Personally I think the entire container space moves too quickly to be a good target for stable long lived services. Pretty much every element is under fast development. Stability is more the attribute of more mature services like Virtual machines, which have been around as a heavily used technology for quite a long time now...

alauda 10y ago

I don't think rkt is a valid candidate. People are already used to the basic of Docker command. There is no reason to change to something else. If rkt decides to reproduce the feature set, how is that different from a fork?

raesene6 10y ago
So the challenge, to me, is that if you fork docker, then people are going to have to get used to a different command structure anyway as the forks will diverge. One of the reasons to avoid a fork is the confusion caused by two kind of similar but not quite the same implementations that diverge slowly over time. rkt is unlikely to just copy the feature set of Docker, but they provide competition in implementing new ideas and as it's not intended to be identical there's less confusion.
creshal 10y ago
> People are already used to the basic of Docker command. The tiny amount of existing early adopters can be made to adopt something else one more time.
- lmickh 10y ago
  Not to mention that they constantly break the Docker api and interactions. Knowing the commands today is not helpful in the future. Once you get past "docker run <image>" so much has changed the last couple of years that it is pointless to hold that up as a virtue.
Svenskunganka 10y ago
People being used to the Docker commands is a very weak reason rkt isn't a valid candidate. Let's not forget the most important aspect of rkt, and that is that it follows the container spec standard.

falcolas 10y ago

IMO, they shouldn't get behind rkt, because it too is owned and primarily developed by a company who uses it as a commodity to sell their own products as well, and the same concerns arising from Docker wholly owning development against Docker Engine could very easily arise against rkt as well. I believe an independent project managed by a board of shareholders would be better for us all.

raesene6 10y ago
I'd agree that if it seems that containerization is a fundamental part of an OS that it would make sense to have a neutral platform for it. That said there were containerization efforts in this area in the past (e.g. LXC) which never really seemed to attract the same kind of traction as Docker. Ultimtely if people want to create containers, it's entirely possible to do with pure linux commands and no upper-level software at all, it's just Docker makes it much easier/nicer to achieve :)
- bogomipz 10y ago
  I think that LXC was on a good path if you were an Ubuntu shop, however I think that tying LXD to Openstack was an odd choice.
  - tribaal 10y ago
    How is LXD tied to openstack? You can use LXD in exactly the same way you used LXC (with a nicer CLI interface, no less). nova-lxd adds lxd as a "hypervisor" choice for openstack, but it's a completely optional way to use it. Try it on ubuntu right now: sudo apt-get install lxd; lxc list (yes, the client for lxd is called lxc, it's kind of confusing. Sorry.) Disclaimer: I work for Canonical, but not on LXD (I use it daily outside of openstack though)
- falcolas 10y ago
  > Ultimately, if people wanted to create [text files], it's entirely possible to do with pure linux commands with no upper level software at all, it's just [Sublime Text] makes it much easier/nicer to achieve. It's absolutely possible (see: Bocker), but not a very productive way to go about things. It's much more productive to take an existing technology and make it better than to start from scratch (yet again), especially with permissive licenses like those used in Docker Engine.

jjuel 10y ago

The funny part about this is CoreOS is talked about being one of the players in the article, and they are the developers of rkt.

raesene6 10y ago
Indeed, I did think that was rather odd...
robszumski 10y ago
From the article: > Spokespeople from ... CoreOS denied any knowledge of Docker-related talks.