Hacker News Reader

> 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)

I'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

He meant docker doesn't contribute in that context.

Just 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?

Or 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.

> 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 :)

>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://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.

> 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.

That'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).

What is the existing vendor-independent standard for packaging apps for containerization? Are you going to say tarball?

Rocket uses a tarball.

As does OpenVz for its templates (for it's running containers it uses a directory in the host filesystem)

> And thus the need for Rocket.

Actually, I'm going to say: thus the need for Cloud Foundry.

I work for Pivotal Labs and I'm secondment to the CF Buildpacks team, so I'm biased. And this shouldn't be construed as official opinion, it's just mine.

Cloud Foundry is led by Pivotal, but we run it openly. Anyone can follow our repos[1][2] and our Tracker projects. The entire platform is being signed over into an independent Foundation with more than 30 paid members[3] (including Docker Inc). The whole project is being written the Pivotal Labs way. Everything is TDD, everything is pair programmed.

If I had to bet a company on a platform, I'd bet it on us. We're building the first and only truly independent, truly open source, truly open core, truly multi-company PaaS that is available.

You can buy support and hosting from us, IBM, HP and a series of mid-tier providers right now. You can do it in the public cloud or in a disconnected datacentre.

Oh, and we're going to have baked-in Docker support with our next-gen executor (Diego), in addition to Warden system we developed before Docker was released.

[1] https://github.com/cloudfoundry/

[2] https://github.com/cloudfoundry-incubator/

[3] http://cloudfoundry.org/about/index.html#the-cloud-foundry-f...

The comparison with systemd is unfair. Docker wants to be "batteries included, but swappable/removable". If you don't like host management, orchestration, build, etc., you can disable that specific component and put another one; and none of those components are strictly necessary.

Contrast with systemd, where it's impossible to use anything else, and the attitude of the maintainers is "our way or the highway" when people beg them to continue to support alternatives.

Compare Docker to frameworks like Django or Rails, which come with everything you need (templating, ORM, url mapping, etc.) but where each thing is replaceable if you don't like it; versus Rocket which would be like Flask or Sinatra, which are smaller and require to be combined with other things to be useful. Nothing wrong with either approach; but if the comparison is right, we can expect Docker to provide "reasonable defaults", and some people building some specific apps to use Rocket because they just want to run things and they don't need build/orchestration/API/etc (or they need special versions of those components).

Jerome don't forget that Django is monolithic. Docker is modular (ie swarm and machine are entirely separate binaries).

You can use Django as swappable libraries. I worked on some projects at Google that used Django for the request routing, templates, and helpers, but completely swapped out the ORM for Google's own RPC system. Jinja2 is basically the Django templating language pulled out into its own library; before it existed, people would just use django.template. Some folks just use the ORM and request routing and then stick a JSON serializer on top to send data to an Angular SPA.

Systemd is a fair comparison.

Systemd is a modular system, and it's also possible to not install different components if you want. Most of the components aren't strictly necessary.

I think your community is begging you to continue to support alternatives. You just aren't listening.

I am listening. Walk me exactly through how you think we should support alternatives, and why you think we're not. I will work it out right here with you.

Well, I think that was my limit right there. If the above message got downvoted, I really don't see any constructive way to have a conversation here. I think I tried.

Come say hi on irc if you want to talk some more. We (the 200-ish people from all horizons on #docker-dev) don't bite.

Happy hacking everyone.

Speaking only for myself, while I have no significant beef with Docker, I've found the general tone of your comments to be slightly off-putting. If others feel the same way, that might explain the downvotes.

I think it boils down to the tension between HN as a place for uninvolved commenters to discuss articles, and as a place for the subjects of those articles to engage in that discussion. Not to slight your intentions, but a comment like "I will work it out right here with you." comes across as an attempt to wrest control of the conversational dynamic, not to mention a little confrontational. For better or for worse, that's something that doesn't really fly when you have an obvious vested interest.

This is not meant as criticism, just food for thought that might help explain the frosty reception you've been getting around here.

I read it differently. I read it as: "it seems you have a key issue but I disagree with you. However, if you clarify your issue I will stay here and discuss it in the open right now."

Same here. I perceived it as very friendly and helpful.

>comes across as an attempt to wrest control of the conversational dynamic

And why shouldn't he do that? He's the one who sweated his ass to create the program, the other guy is just some random user who got it for free (and open source) and complains for something.

"slightly off-putting" Argh, we are in a forum, this is communication deprived of non-verbal cues. Just focus on the intent and the information. I think shykes deserves more than judging of his tone. I also think it is cool he is hanging out here managing (mis)information. Are you all jealous or something? You have the chance to ask anything you want to someone who is the driving force behind a project of which the implications are hard to overestimate. And you find his tone off-putting.

I'm just a biologist but if any of the big names in my field (say, Hans Clevers, is that a stretch?) would be approachable on a forum, man that would great!!

(I didn't downvote you, just FTR.)

I think this is the kind of thing that might be at issue: https://github.com/docker/docker/issues/6791 [1] (I realize that the ticket is not closed, I just bring it up as an example of something that I see as counter to commoditization and thus counter to my goals as a user.)

One of the issues that I personally have with docker (much as I love it) is that it also wants to be a process supervision "framework" (for lack of a better word). I don't want that, I want a reliable way to supervise a docker-started process from whatever supervisor daemon that I want (whether that be systemd, runit, or whatever). This is not really for ideological reasons -- I want something that integrates properly into my distribution of choice, not something that wants to be a system unto itself.

[1] ... I'm obviously not the submitter of this issue. I just stumbled upon it during a related search.

I understand, but the problem is that to "just run a container" Docker needs to manage global system state and synchronize with other docker instances. Right now that is done with the daemon. How do I do this without? CoreOS's answer is basically "systemd should do all that". But to me that is not an acceptable answer. I don't want to tie Docker to systemd. It's already too monolithic as it is. Do we really want to absorb the docker daemon's functionality into it too? Because that's exactly what CoreOS is proposing with Rocket. I think that's a flawed design and the opposite of composable.

I'm well-acquainted with Docker's architecture and some of the ways it's used in the field. I wouldn't call it modular. It might be well-factored and even separated into multiple modes and repos, but that's not modularity; that's just good code.

When you ship batteries, people depend on the batteries and that means you can't really swap them when you want to because things stop fitting. It doesn't help that all of this is baked by default into a single monolithically versioned binary with an API whose documentation isn't nearly rigorous or stable enough to promote alternative implementations.

I like Docker or I wouldn't be here commenting, but you know what would make me love Docker? If every piece was pipeable CLI command.

Like...

    docker-listen tcp://,... | docker-run --image-tar=blah --container-tar=blah | docker-monitor --log-file=blah | docker-swarm --orchestrator-socket=orch.sock | docker-link --port=some.other.machine:port

I know this is a crazy rethinking of how Docker's APIs work, but I think that fact perfectly demonstrates my point about how un-modular Docker really is as far as its users are concerned.

I don't think it's crazy. I think it's cool and your points completely valid.

A good question we have to ask is how do we get from where we are, to the desired end state that you describe? There's nothing stopping it from happening, it's a fork away with a good chance of upstream contribution.

Today that's through proposals and discussions in freely available on github, irc, and mailing lists for the docker project and which we call fire hose of information symbolically.

Maybe we're missing an additional avenue for input and creativity. What do you think?

I think a model similar to git's "plumbing and porcelain" [1] could work well.

[1] http://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Por...

FWIW, as a startup cofounder with a non-technical partner who likes to do design/copyediting tweaks, the ability to do "docker up" and have it bring the whole system up on Linux, Mac, and cloud is a huge sell. I know how pipes work and can memorize a half dozen commands, but my cofounder certainly does not, and any tweaks she can do on her own is work that I don't have to.

I don't think there's any danger as long as everything is open and interchangeable, and you can steer clear of Docker (the company) even if you like Docker (the format). So far that's basically the case with all of the Docker projects.

Ideally in the future, Docker will become an HTTP for servers, with standardized and competing servers/clients/services. I like the idea of that future. Publically, the Docker folks seem open to it.

However, I do see where you're coming from. As a for profit Docker has every incentive (perhaps even fiduciary duty) to pull the good ol' technology bait-and-switch: get Docker on every server, and the create a Kafkaesque technology dilemma to squeeze the dollars out of everyone who bought in. Microsoft's playbook has plenty of tips on how to do this.

I guess the only solution as a Docker user is to be hypersensitive to any sign that Docker wants to start locking the technology to the company. When you can imagine the day you can't use Docker (the containers) without Docker (the company), it's time to run the other way fast.

But I can't see that day yet, and I hope I never do. And I hope Docker as a company can find a way to grow without using that oldest, sleaziest trick in the book.

We should probably note this 'shingler' account was created exactly at the same time this post was submitted to HN, and this is the account's first comment... in support of this article.

I'll leave you to decide what that means...

Probably has something to do with this: https://twitter.com/solomonstre/status/540559322070392834

Your post had exactly 5 re-tweets when you posted your comment just now (not exactly an onslaught of new listeners rushing to HN for the first time).

Regardless -- Your twitter post came almost 30 minutes after the account above was created and 30 minutes after this article was submitted to HN.

Nope. Just a longtime HN user who finds more honest and productive discourse in anonimity.

Frankly I'm not sure what the sockpupperty accusation is about, since I'm not particularly promoting any direction.

Docker's overreach seems to resemble the overreach of Joyent in the io.js world. It's really hard to regain trust and momentum once the community starts to question you; in economic terms this would be termed as "a spike in transaction costs." If I were Docker, my next project would be a meetup/presentation/etc explaining how my new initiatives are for the benefit of the community, rather than just self-serving wheel reinvention. This isn't a consumer-facing business; the opinions of concerned developers can make or break them.

> my next project would be a meetup/presentation/etc explaining how my new initiatives...

You mean like the conferences they held before they even had a viable product?

Docker has stampeded onto the scene with zero competition, and the Parent comment is totally right -- we should take a good minute and consider that we are head-first rushing to implement everywhere a product made and perpetuated by a for-profit company who's end goal is literally to be on every server and be the de facto implementation so that once they start to monetize the product, you will have little choice but to funnel support funds into their company.

That's petrifying to me, because it means if realized, my company will be at the whims of Docker, not the other way around.

Furthermore, the backlash from the Docker creator himself the other day on the announcement by CoreOS, it really seems Docker never anticipated ever having any competition in this space, and have taken active steps to ensure they are their own custom thing that is not compatible with other existing or future container implementations.

Perhaps this will change now, and they will work with CoreOS to clearly define a universal specification for a container which can be portable between any implementation, but signs show they don't feel it's in their company's best interest to do so (and honestly it isn't in their best interest, but it's in the community's best interest for sure).

> You mean like the conferences they held before they even had a viable product?

The conference was awesome and there was plenty to announce at that point. It certainly helped drive home the conceptualization of containerization for many.

> we should take a good minute and consider

You're right we should consider - except what you're doing is making charges like;

"we are head-first rushing", "perpetuated by a for-profit company", "my company will be at the whims of Docker"

And other fear in this thread without providing your audience with the context of: - for profit companies backing an innumerable number of major technologies in a variety of fields since technology was a thing - most of the development of Docker happens outside of Docker Inc - the project has an independent governance board - the project has been nothing but the epitome of successful transparent open source

If Docker ends up achieving a cohesive ecosystem of holistically designed pieces solving one of the most difficult unsolved problems (a class of problems, really) in modern computing benefiting so many then is it really a problem paying Docker Inc for first class support to all of that? I imagine there are already companies selling support for Docker other than Docker Inc

It seems like you're the one imagining there is going to be no competition, honestly.

  > if Docker could have just stuck to running containers

Do you argue the same for Amazon with AWS? They should have just stuck to running VMs on EC2 backed by S3? Amazon should not have added databases, scaling, load balancing, caching, DNS, email, search, analytics, etc. and left that up to the community to provide? Do you argue that Amazon has taken an embrace-extend-extinguish approach to AWS?

AWS started as an open-source community project boasting contributions from over 650 contributors?