3 ms·

> it's an objective fact that canonical decided to reimplement > what Docker does rather than contribute to it. What was the reason that Docker reimplemente

by 23david 12y ago

> it's an objective fact that canonical decided to reimplement > what Docker does rather than contribute to it. What was the reason that Docker reimplemented much of LXC rather than contribute patches upstream? Latest LXC supports features that Docker's reimplementation doesn't, and it seems likely to get further ahead feature-wise now that Ubuntu is pouring more resources into LXC/LXD.

shykes 12y ago
You forgot to quote the part where I said "I won't comment on whether it's good or bad". Canonical doesn't need to justify itself to me, no more than the Docker maintainers need to justify themselves to you. It's just how open-source works: you weigh the pros and cons of re-using vs re-implementing, make a decision, and see if the community follows you. In the case of Docker, the community followed. In the case of lxd, I guess we'll see. Either way, more choice and competition means the user wins.
- 23david 12y ago
  Happened to find the pull request discussing the lxc-driver issue. It sounds like there was some interest in contributing upstream, but it didn't really go anywhere. https://github.com/docker/docker/pull/5797 From the thread, it seems like the concern was just that lxc-exec wasn't well maintained and the lxc interfaces weren't stable since it was undergoing heavy development. I think that's changed recently with both lxc and docker now post 1.0 release and 'production-ready'. Docker still uses LXC if you want it to via the lxc-exec driver and the --lxc-conf option. It's just not the default, which probably makes sense since the lxc options mainly apply for advanced users. So by default, Docker uses libcontainer for a simpler installation experience. But for advanced users, using the lxc driver is an option to look into. IMO, Docker wins if it continues to play nicely with the other open-source projects people use with Docker, and also give credit where due.
  - shykes 12y ago
    Completely agree and we try hard to do just that.

by 23david 12y ago

shykes 12y ago

You forgot to quote the part where I said "I won't comment on whether it's good or bad". Canonical doesn't need to justify itself to me, no more than the Docker maintainers need to justify themselves to you. It's just how open-source works: you weigh the pros and cons of re-using vs re-implementing, make a decision, and see if the community follows you. In the case of Docker, the community followed. In the case of lxd, I guess we'll see. Either way, more choice and competition means the user wins.

23david 12y ago
Happened to find the pull request discussing the lxc-driver issue. It sounds like there was some interest in contributing upstream, but it didn't really go anywhere. https://github.com/docker/docker/pull/5797 From the thread, it seems like the concern was just that lxc-exec wasn't well maintained and the lxc interfaces weren't stable since it was undergoing heavy development. I think that's changed recently with both lxc and docker now post 1.0 release and 'production-ready'. Docker still uses LXC if you want it to via the lxc-exec driver and the --lxc-conf option. It's just not the default, which probably makes sense since the lxc options mainly apply for advanced users. So by default, Docker uses libcontainer for a simpler installation experience. But for advanced users, using the lxc driver is an option to look into. IMO, Docker wins if it continues to play nicely with the other open-source projects people use with Docker, and also give credit where due.
- shykes 12y ago
  Completely agree and we try hard to do just that.