Live data from Hacker News

A new upstream project to break up Docker into independent components

github.com

231–240 of 321 posts

Re: A new upstream project to break up Docker into independent components

#231
post #103

Earlier quoted context omitted.

> So moby now uses containerd Correct. Moby uses containerd because Docker uses containerd. > which I guess is not related to systemd You guessed correctly. > even though systemd also has its own container system Correct I believe systemd uses a tool called nspawn to isolate processes in containers. We don't use systemd/nspawn, but I think it would be a cool customization to build a Moby assembly that uses systemd. >…

>> or is this whole endeavor to break away from linux dependencies? > Moby works great with Linux and will continue to. In fact you can build a complete custom Linux system with Moby, thanks to LinuxKit. (But you can also target an existing Linux system, LinuxKit is optional). I think the question was more along the lines of "Are these changes being made to add support for other Operating Systems?" and less "Are you…

Docker the company looking into other host OSs would make sense to me for two reasons:

- RedHat eating Docker's lunch, and dominating Linux development

- the somewhat questionable practice of using Docker as a GPL-circumvention device (eg. commercial images pulling a Debian/Ubuntu userland on first load), though I'm unsure about the legal implications

Re: A new upstream project to break up Docker into independent components

#232
post #174

Earlier quoted context omitted.

> Also, isn't it kind of ironic that you built your company on OSS and then invited a well known destroyer of OSS onto your main stage? I think I missed this; who are you referring to? I scrolled through the list and didn't recognize anyone that I would consider a "destroyer of OSS" so I'm not sure if I missed something, if you're just exaggerating or a little bit of both.

I suspect he's upset that now Microsoft are being co-operative with open source the open source companies are reciprocating. Incentive structures be damned, the evil M$ must be fought, here, I brought this knife to cut my nose off with! (+5, Insightful)

I think he's referring to Oracle.

Re: A new upstream project to break up Docker into independent components

#233
post #229

Earlier quoted context omitted.

Many people really love the name Docker. Could you explain the reasoning behind the need for a new name? I ask this because would it not have been a better choice to name the other releases differently. For example: Docker (docker/docker) = open source development. Docker CE (docker/docker-community) = free product release Docker EE (docker/docker-enterprise) = commercial product release based on Docker CE (private).…

We're separating the upstream open-source project , and the downstream open-source product under 2 different names, because a lot of people in the open-source community asked us to. It's a common concern in the free software community that having an open-source project too tightly coupled to a single company's product is a bad thing. Moving the upstream open-source project into Moby, and keeping the downstream open-s…

I for one think it's fantastic that you were open to modeling the project in this way. It seems to me that there is a lot of hostility thrown at Docker in this thread because people assumed the worst based on a comment in a pull request. This is a good thing for Docker and a good thing for the Docker community and containerization in general.

Re: A new upstream project to break up Docker into independent components

#234
post #214
post #75

Hi all, Docker founder here. It appears that the explanation in the pull request is not very clear. Sorry about that. We didn't expect the PR to be the first thing people read: there is a new website at mobyproject.org. Unfortunately Github is struggling under the load, and I can't update the PR text to clarify. Here is an updated version with some clarifications: Docker is transitioning all of its open source collab…

Hey Solomon, here are some 'starters for 10': - Who will be able to use the Docker trademark? If someone built a fork of Docker CE from Moby, can they still call it Docker? What about distribution packagers? - Right now a single binary ('docker') is used to build images and runs clusters (among other things). As the monolith is broken down, will the new binaries still be named/branded 'docker'? Will there be rules ab…

> Who will be able to use the Docker trademark?

Docker.

> If someone built a fork of Docker CE from Moby, can they still call it Docker?

No.

> What about distribution packagers?

We're still working this out, with the guidance of a few distro packagers. There will most likely be a change of some sort, but don't want to rush anything until we are certain that it won't break users.

> Right now a single binary ('docker') is used to build images and runs clusters (among other things). As the monolith is broken down, will the new binaries still be named/branded 'docker'?

Yes. The same 'docker' binary will continue to exist. We are going to spin it out into its own repository under the docker github org. It will only act as a client, and we will encourage the development of a healthy ecosystem of alternative clients.

> Will there be rules about packaging only some of them?

Basically only Docker can create something called "Docker". Everything else will be regular open-source project rules: build, patch, package any way you want.

> Will Docker CE/EE still have a single binary for all purposes?

It depends on the target platform. Docker for Linux is a deb or rpm package with several binaries. Docker for AWS is a Cloudformation template. Docker for Mac is a Mac application with a very complex array of components built in. etc.

Re: A new upstream project to break up Docker into independent components

#235

Earlier quoted context omitted.

This idea isn't cynical, it's branding. The whole point of creating a brand like Moby is to trigger conversations about what level of service you're getting when you say you're using "Moby" vs. "Docker". The CTO hears they're using "Moby", which for the first time may make the CTO realize that some of the infrastructure for his business is relying on unsupported technology (or maybe he intuitively realized it but now…

Why do we keep equating OSS to "unsupported"? Some of the OSS I use is far better supported than licensed software. Drop an issue on GitHub and it gets fixed in a few weeks. - a CIO

Because without a legal contract to cover support, you don't have someone that contractually has to answer your call.

You might not care about this, and many don't. You're running the risk that the maintainers won't pack up shop and stop maintaining the project, and that you & your team will need to inherit the project.

Other way of looking at it, is that if you're a business, you always should pay for your software, even if it's open source. Because you will one way or another: through your team, or through the risk that free riding brings.

Re: A new upstream project to break up Docker into independent components

#237

Earlier quoted context omitted.

This idea isn't cynical, it's branding. The whole point of creating a brand like Moby is to trigger conversations about what level of service you're getting when you say you're using "Moby" vs. "Docker". The CTO hears they're using "Moby", which for the first time may make the CTO realize that some of the infrastructure for his business is relying on unsupported technology (or maybe he intuitively realized it but now…

The object "Docker" has been in dissonance for quite a while now, both by the company's perspective and the consumer's perspective. I think rationalizing it as a "brand" move is a bit simplistic. It is a FACT that individuals are unable to use the term "Docker" on anything they would like to create and share with others. This has been enforced with takedown notices and legal entities getting involved in "protecting"…

"I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. "

This seems to be a much higher level construct , like PaaS or Lambda, than what Docker provides.

Docker was more of a bottom-up wake up call to those upper layers that lower layer technology usability still matters.

Re: A new upstream project to break up Docker into independent components

#238
post #165

Earlier quoted context omitted.

where's the Rocket Hub? Seriously how long is Docker Hub expected to float up there? Some are good quality, all the versions of tomcat for example. How long can such quality continue to exist?

That would be https://quay.io/ , but also the internet. Since rkt (or appc discovery rather) just relies on DNS/URL hierarchy to refer to images. Any web server can be a "registry". OCI doesn't have an equivalent to discovery yet, but presumably it'll be something similar to the appc spec ( https://github.com/appc/spec/blob/master/spec/discovery.md )

I'm one of the people working in the OCI community. Discovery/distribution is something that I care alot about personally and the whole "any web server can be a registry" idea is definitely where I want OCI to go with this. As someone who helps develop a distribution (openSUSE / SUSE Linux Enterprise) my opinion is that the current state of distribution really needs to be improved.

I also recently talked to some CoreOS devs at Dockercon and have started considering extending rkt to better support OCI runtimes (and images though images are "supported" at the moment). Exciting times.

Re: A new upstream project to break up Docker into independent components

#239

Earlier quoted context omitted.

Why would you lead with a legitimate question and then finish with an outright insult?

How can software be insulted? Software doesn't have feelings.

This logic is the reason it sucks to be an open-source maintainer.

Re: A new upstream project to break up Docker into independent components

#240
post #229

Earlier quoted context omitted.

Many people really love the name Docker. Could you explain the reasoning behind the need for a new name? I ask this because would it not have been a better choice to name the other releases differently. For example: Docker (docker/docker) = open source development. Docker CE (docker/docker-community) = free product release Docker EE (docker/docker-enterprise) = commercial product release based on Docker CE (private).…

We're separating the upstream open-source project , and the downstream open-source product under 2 different names, because a lot of people in the open-source community asked us to. It's a common concern in the free software community that having an open-source project too tightly coupled to a single company's product is a bad thing. Moving the upstream open-source project into Moby, and keeping the downstream open-s…

Wouldn't it be better to leave the open source project where it was, and move the product elsewhere?
Post reply on HN