3 ms·
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 Docke
by 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 agoHappened 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 agoCompletely agree and we try hard to do just that.