A new upstream project to break up Docker into independent components • Hacker News Board

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

#261

Post by cookiecaper » Fri, Apr 21, 2017, 1:17 AM UTC

shykes wrote: post #69

bru wrote: post #5

More information can be found there: https://github.com/moby/moby/pull/32691 > Docker is transitioning all of its open source collaborations to the Moby project going forward. Should I understand that the core team wants to keep the brand "Docker" but use it in a commercial way, while Moby will be the underlying open source code? Is it Docker/Moby = RHEL/Fedora ? or Docker/Moby = Mongodb.com/Mongodb.org?

Docker/Moby = RHEL/Fedora

Except that you claim Docker will continue to have Docker CE (Fedora equivalent) and Docker EE (RHEL equivalent). These products will continue to be issued by Docker Inc., will they not? Will "Docker CE" be released as "Moby" in the future? If so, how will it be distinguished from the "Moby Project", which is just a bunch of "building blocks"?

If Moby is the name of a collection of subsystems that are drawn upon to build user-ready container platforms like Docker, isn't GNU userland/Linux kernel->(Fedora/Red Hat)->Red Hat Inc. as Moby->(Docker CE/EE)->Docker Inc.?

Perhaps a better way to explain it is that Moby is a "containerization kernel/core" a la Linux or an "open containerland" a la GNU. The term "framework" may be a little more accessible at the cost of diminishing street cred by appealing more to web devs than old-school system devs. These fancy words probably shouldn't be a problem since it seems only developers would be interested in Moby anyway (instead of end users who would want to use a Moby distribution).

With a little bit of finesse, this could've probably been construed as the boon for the open-source community that it seems you originally intended. "Docker Inc. donates its core technology to the open-source community and invites competitors to use it as the base of their own products." Too late to right the ship?

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

#262

Post by shykes » Fri, Apr 21, 2017, 1:19 AM UTC

alsadi wrote: post #146

shykes wrote: 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…

Tell us more about trademark and branding guidelines. What do you allow a downstream implemented by others to be called without requiring trademark fees ex by parties similar to amazon (public cloud) or ovh (data center) or redhat/fedora (software vendor) and even nvidia (cuda docker-like) . For example fedora and firefox has strict trademark policy eventhough they are opensource. Can I call my tool moby-something?

For the Docker trademark, we will adopt guidelines similar to other open-source products, such as Ubuntu or Red Hat Enterprise Linux.

For Moby, there is no need for a strict trademark policy because Moby is a "meta-platform". In other words downstreams don't run Moby: they build their own specialized platform with moby. So they don't need to worry about the Moby trademark anymore than they need to worry about the trademark of gcc or make. Anyone who uses Moby to build their platform will be more than welcome to say "built with Moby".

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

#263

Post by ambicapter » Fri, Apr 21, 2017, 2:01 AM UTC

cookiecaper wrote: post #258

frightening wrote: post #244

Earlier quoted context omitted.

> that it's too tied to the Docker product and company That's good news. So you're setting up some sort of foundation so that Docker is no longer a gatekeeper for the upstream stuff? I didn't see that in the announcement.

They're essentially attempting to distinguish their commercial offerings from the upstream open-source project. They are cornering the name "Docker" for themselves since it has a lot of name recognition. This has pros and cons. Red Hat and Mozilla both learned they had to be aggressive with trademarks, as people were distributing sabotaged builds under their product names. That's why Firefox in Debian is called IceWe…

> I keep hoping the containerization fad will go back in the bottle

Is this because containerization in of itself should go back in the bottle, or do you think that people are just taking it too far?

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

#264

Post by solarengineer » Fri, Apr 21, 2017, 2:04 AM UTC

Rapzid wrote: post #236

mos_basik wrote: post #209

Earlier quoted context omitted.

OpenSolaris, OpenSSO, OpenOffice...

ZFS is the one that got away.

Illumos is a fork of the OpenSolaris code base. We still call the file system ZFS, and all the operating systems (including Illumos) that use ZFS are working together on the OpenZFS project.

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

#265

Post by justincormack » Fri, Apr 21, 2017, 2:26 AM UTC

riquito wrote: post #134

shykes wrote: 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. >…

If Moby depends on LinuxKit, why the LinuxKit's README ask you to build the Moby tool as first thing, and all the examples imply using moby? Shouldn't LinuxKit be agnostic of the existence of Moby?

You can use the LinuxKit components independently, but right now the easy way is to use the Moby tool. Sorry about the confusion though, we are trying to make it clearer.

Here is a summary we wrote earlier for Moby https://mobyproject.org/#moby-and-docker

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

#266

Post by tescherm » Fri, Apr 21, 2017, 2:31 AM UTC

throwawaydc2017 wrote: post #216

ilovecaching wrote: post #153

Earlier quoted context omitted.

Do you know that keeping your users in a constant state of confusion is not the way to convince them that you're building a stable and secure product? 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? Plus, I want my DockerCon money back. What exactly did you announce besides multi-stage builds at the general sessions that is actually…

> Plus, I want my DockerCon money back. What exactly did you announce besides multi-stage builds at the general sessions that is actually benefiting Docker users? I don't care about your plumbing and constant rebranding, other than finding it very discouraging, I want to know what you're actually doing with your product this year. I guess nothing. I was annoyed at the fact that I paid $150 extra for a workshop, "Dock…

Hey throwawaydc2017 sorry to hear that. I was one of the presenters, was there anything that you wanted to have covered that wasn't? If you have time could you email store-feedback@docker.com with more info?

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

#267

Post by shykes » Fri, Apr 21, 2017, 2:44 AM UTC

matt4077 wrote: post #247

jacquesm wrote: post #157

Earlier quoted context omitted.

> "Docker Community Edition" That's not Docker. That's Moby.

It is. Only the underlying technology is renamed, "Docker Community Edition" will continue to exist.

That's correct. There is no change to Docker CE or Docker EE. We are adding a 3d thing, upstream from both of them: Moby. We use Moby to assemble all the pieces of Docker. You can also use it to assemble all the pieces of other things like Docker, and maybe in the process collaborate with Docker on the common parts.

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

#268

Post by venture_lol » Fri, Apr 21, 2017, 2:47 AM UTC

api wrote: post #73

So devops conferences will no longer sound like "Docker docker Docker? Docker. Docker docker docker docker? Ahh, Docker docker Docker docker docker." Now they'll sound like "Moby moby moby...?" This seems absurd from a branding point of view. I personally find this a little bit vindicating. I'm 39, which is like 120 in programmer years. I feel like one of the advantages of being an "old" (in quotes!) programmer is th…

Static and dynamic linking are just 2 sides of the same coin.

Any language, as it grows and takes on larger tasks, its dependencies will also grow.

Build time dependency management, distribution, and run time dependency management are different phases that would still need to be managed

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

#269

Post by 616c » Fri, Apr 21, 2017, 3:07 AM UTC

problems wrote: post #192

ThrowawayR2 wrote: post #185

Earlier quoted context omitted.

Well, guess I'll do the detective work. Here's a link to the Docker blog that has the two keynotes: https://blog.docker.com/2016/06/dockercon-general-session-vi... Guest speakers for the last (second) general keynote were: -Guest speaker #1: Docker and Microsoft demo by Mark Russinovich, CTO Microsoft Azure -Guest speaker #2: Docker at ADP by Keith Fulton, CTO, ADP And just somehow I sense that the parent poster isn'…

> (What makes the objection doubly silly is that Mark Russinovich isn't the usual corporate drone one might expect. He's the guy who did the Sysinternals tools and several editions of the "Windows Internals" reference on the architecture of the Windows OS.) From Sysinternals to the Azure CTO... what a weird transition. That guy has had an interesting career.

And most entertainingly those Sysinternals were open source originally and were immediately close sourced after he was hired during fierce negotiations by Microshaft and many angry at him for thumbing them publicly, especially for the NT SKU registry change debacle.

https://en.m.wikipedia.org/wiki/Sysinternals

(Interestingly citation needed; people still circulate the code on BitTorrent of very old copies.)

Ironically a MSer told me he was famous for his infamous condition he be a Senior Engineer with an unorthodox, exceptional contractual or understood conditions: no painful managing other MS people. This only changed when made the CTO of Azure.

No idea if that's rumor's true. He's a personal hero and I'm yet to read his novel about cyber war (yes, you heard me).

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

#270

Post by sandGorgon » Fri, Apr 21, 2017, 3:08 AM UTC

alexk wrote: post #191

sandGorgon wrote: post #124

@shykes - so im one of the lonely few that love Docker Swarmkit (not Swarm - cos, that would be too confusing right !). I have spent a lot of time in the Kubernetes ecosystem (including several SIG) and value the batteries-included setup that Docker Swarm brings. More recently, I was part of a discussion where Kubernetes has decided to roll its own logging infrastructure, while leaving important parts like log rotati…

> More recently, I was part of a discussion where Kubernetes has decided to roll its own logging infrastructure, while leaving important parts like log rotation still undecided.... driving me even closer to the Docker ecosystem. Can you please refer to this particular discussion and link to it here, I would like to make sure that this indeed is what happened.

For independent reasons, I would rather not go into it because the discussion became borderline heated. My perspective was that it was inconsiderate to not give a path for kubernetes logging to work with journald which is now default on Redhat, Ubuntu, Debian and Coreos. I don't say journald should be the only supported format...But it's wasteful to have the pendulum swing the whole other way.

The last known proposal is here https://github.com/kubernetes/community/blob/master/contribu...

You can check the rotation part. Btw, yes I am aware there was increased journald support added in 1.6 . And I'm hoping that more reasonable minds prevail.

I get very worried when people say "the format+kubectl cli is more important. we will figure out the mechanics of easy stuff like logrotation later. until then you can use a cronjob. systemd is obviously a monopoly."