6 ms·
> it looks a lot more like they took a Microsoft embrace-extend-extinguish approach to LXC That's overstating things slightly, since it appears no Docker emplo
by hosay123 12y ago
> it looks a lot more like they took a Microsoft embrace-extend-extinguish approach to LXC
That's overstating things slightly, since it appears no Docker employee has ever contributed a single line of code to the LXC implementation itself (that would be hard work, rather than bikeshedding userspace tools, after all). The kernel tree contains only one reference to a Docker bug, fixed by a Red Hat employee, while the LXC tree contains a single reference to a Docker bug, fixed by a Canonical employee who looks to be one of the LXC maintainers.
The reality is replacing Docker isn't all that hard, as we're now seeing with Rocket. The kernel interfaces aren't tied to it (hell, its clear from Git logs the LXC devs are barely even aware of it).
edit: It's simpler to look at Docker and Rocket for what they both are: commercial plays built on the work of others. That work hasn't magically disappeared somewhere, it still exists and is in use (albeit by a slightly less PR/buzz-aware side of the community).
A vendor-independent implementation of containers already exists, as it did long before Docker did. If people are serious about seeing the "container ecosystem" flourish, they should be contributing cash, employment offers, or employee time to the real people and projects doing the work (as opposed to publishing upset blog posts and writing fashionable Go code)
- VieElm 12y agoI'm pretty sure the CoreOS CTO, Brandon Phillips, has personally made many significant contributions to open source, just check his GitHub[1], and is a Linux kernel developer. He's been an open source contributor for a very long time. [1] https://github.com/philips?tab=repositories https://github.com/philips?tab=repositories
- hueving 12y agoHe meant docker doesn't contribute in that context.
- tlrobinson 12y agoJust curious, are you doing anything to support the container ecosystem, aside from publishing upset Hacker News comments? I think the strong interest in Docker demonstrates there's a need for a layer on top of LXC. It's open source, so what's the problem?
- tobbyb 12y agoOr it could mean as a funded company Docker has more resources than a low profile open source project like LXC to reach out and generate interest and adoption. There is undeniable confusion about LXC and Docker with a lot of folks whose first introduction to containers is via Docker who seem to think LXC is 'low level kernel capabilities' as it is mistakenly referred to on the Docker website, and since Docker was based on LXC they at least should be clear what LXC is. The fact that LXC is an advanced project baking since 2009, supported by Ubuntu since 2012 which provides perfectly usable Linux containers, wide choice of OS templates, features like unprivileged containers and is easier to use than Docker is often lost in the noise. LXC provides you system containers, Docker takes that base that to provide app containers, and there is definitely interest and value in that but it's a single use case of Linux containers. Would you want to reduce a container to an app for all use cases? To conflate a single use case to container technology itself is a mistake, apart from the fact that once you go down a custom container format you will need to expend engineering resources to figure out how to make a lot of things like clustering, services, apps, networking that expect a normal OS environment work with the constraints.
- girvo 12y ago> Would you want to reduce a container to an app for all use cases? Yes, I would. At least for the work I do, it's exactly what I require, and takes a lot of the work and thinking out of what I need to achieve. That's not a bad thing, and I'm not arguing that it's how it should be for everybody, but that's the best part about open-source, you can choose a different implementation or write your own on the same tooling :)
- coldtea 12y ago>it appears no Docker employee has ever contributed a single line of code to the LXC implementation itself (that would be hard work, rather than bikeshedding userspace tools, after all) You keep using this word, bikeshedding. I don't think it means what you think it means. http://en.wiktionary.org/wiki/bikeshedding http://en.wiktionary.org/wiki/bikeshedding http://www.urbandictionary.com/define.php?term=bikeshedding http://www.urbandictionary.com/define.php?term=bikeshedding TL;DR; it's about discussing/debating trivial details instead of the important characteristics of a system, not about working on easy stuff vs more hard programs.
- deleted 12y ago[deleted]
- kordless 12y ago> while neglecting the design of the power plant itself I think what hosay123 is trying to say is that LXC is the power plant and the tooling around it is Docker, which runs in userspace. Note I'm not trying to say that, I'm just saying things.
- coldtea 12y agoThat's what I got from his comment too. But the first difference (with bikeshedding) is that bikeshedding is not "doing the tooling around the power plant instead of the plant itself" but spending time discussing and designing some insignificant detail instead of the power plant. (That is: bikeshedding is getting lost in DEBATING the easy and incosequential details of an implemntation). Docker is neither "lost in discussion" (they're building things, and a lot, and fast), nor a trivial detail (that would be e.g. LXC code's tabs vs spaces convention etc).
- deleted 12y ago[deleted]
- pekk 12y agoWhat is the existing vendor-independent standard for packaging apps for containerization? Are you going to say tarball?