The grand-parent is correct that lxd is a newly introduced competitor to Docker.
I won't comment on whether it's good or bad, but it's an objective fact that canonical decided to reimplement what Docker does rather than contribute to it.
Docker Inc CEO Ben Golub:
Current meme gets it wrong. Ubuntu lxd is complementary, not
@docker replacement. Joyent brings Docker to SmartOS.
http://zd.net/1uB3Aly
That being said, if they do somehow manage to get hardware assisted containment for containers, I see it as a no-brainer for docker to adopt it as soon as it is reasonably possible. Are there any plans (that you can speak of) regarding something like this, or are you waiting for LXD to be more than vaporware at this point?
> it's an objective fact that canonical decided to reimplement
> what Docker does rather than contribute to it.
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.
https://github.com/docker/docker/pull/5797
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.