Donating Docker Distribution to the CNCF | Hacker News Reader

Donating Docker Distribution to the CNCF

docker.com

124 pointsCSDude22 comments

This has been in the works for a while! It's exciting to see core components being officially put into the hands of the community.

Docker distribution is the second implementation of a container registry ever (the first was written in Python by Docker and was later forked into Quay) and is at the core of many of the commonly used container registries like Docker Hub and Harbor. This repository became the basis for the OCI distribution specification[0], which is now the standard for distributing container images (and more[1]).

[0]: https://github.com/opencontainers/distribution-spec

[1]: https://github.com/opencontainers/artifacts

Sadly when I see this and their recent move with Docker Hub, I think they are pushing source code on the community to better spent/preserved their diminishing cash.

I think I understand the difficult position that they are in, and I'd rather they do that than fall to sell to some large entity their name recognition and their IP.

It's a sad story, but they have changed the entire industry, and I'm happy that they found a way to make their contribution open and sticky.

> I think I understand the difficult position that they are in, and I'd rather they do that than fall to sell to some large entity their name recognition and their IP.

I think GitHub has done pretty well under Microsoft's ownership. There was a story a few years back, Microsoft tried to buy Docker but apparently Docker wanted more money than Microsoft was offering. Maybe they now wish they'd said "yes".

A big company like Microsoft can afford to have some loss-leaders in their ecosystem. So could Amazon or Google, but I personally think Microsoft would have been a better steward of Docker than Amazon or Google would have.

Of course, Microsoft is a private for-profit corporation, whose benevolence is not guaranteed to last forever, and has even done some malevolent things in its past. But Microsoft's benevolence may well last longer than Docker's financial ability to offer free services can.

Unfortunately their offerings have gotten worse since the announcement. I've noticed significantly longer queue/build times in my org compared to a year ago.

I suspect it also future proofs them a little. People will be less afraid of using Docker tools if they think the tools could outlive Docker the company.

This is not true. A lot of people are using this code, it is the basis for the registries at GitHub (the new one), GitLab, Digital Ocean, Harbor (already in CNCF), Mirantis and many more, as well as Docker Hub. Having this as a project in the Docker GitHub org rather than as open governance just doesn't make sense with so many users. We are not "pushing it on the community" people are already using this code in production and making changes to it.

Why call this "distribution"?

This is going to be impossible to Google.

How many people are setting up their own container registries?

This doesn't need a catchy name. It's a piece of "if you're the person deploying this, you already know us" infrastructure, similar to Enterprise-grade hypervisors or Internet backbone switches.

it's not about "catchiness", it's about being able to have a unique moniker, so whoever is searching for it can find it. "Distribution" immediately is going to clash with the multitude of linux distributions. They could have named it "image-distribution", "container-image-distribution", "cidistribution", whatever.. just something that makes it easier to find via search.

Never having heads of this before, I just popped over to Google and searched for "docker distribution" and this was the very first result. I don't think Google is going to care much if you use hyphens or spaces to separate words like that.

I suppose as long as everyone knows the etymology of this "distribution" and remembers to use the word docker before it, then it should be fine. Probably a conversation best had 10 years from now. :)

...which is what I meant by "catchiness": the ability to have a context-free unique name. Not all products need context-free unique names. Heck, not all products even need names.

ISO/ANSI standards and RFCs, for example, are just numbers. You can actually Google the most famous of these ("9001" gets you the ISO standard; "2616" gets you the RFC; etc.); but on average this doesn't work, because those numbers are small and collide with other meaningful numbers in other namespaces†. (Things like electronics part numbers, for example.)

With any of these identifiers, the thing you do instead of just punching the ID into a search engine, is to first search for either 1. the website of the entity you know owns the thing, or 2. some kind of "catalog" site; and then plug the otherwise-non-unique identifier in there. Your identifier, despite not being unique generally, is unique when put in the context of a domain-specific keyspace.

In this case, the keyspace is "CNCF projects", or maybe "implementations of OCI specifications." The specification for these registries is called the "OCI Distribution" spec, just like the specification Docker containers obey is the "OCI Container" spec.

Look at the list of Apache Foundation projects: https://projects.apache.org/projects.html — how many of these have names that have no hope of being searched unless you know to prefix "Apache" to them? Chemistry? Drill? Flex? Portals? Streams, for goodness sake?

And this is why I said that it wasn't important because only very specific people need to stand up their own container registries: all those people already know enough about container registries to intuitively prefix "Docker" or "OCI" or "CNCF" on their search query; or to go to those projects and navigate from there.

This would be a problematic name if random people needed to install it after a word-of-mouth conversation. But they don't, any more than random people need to find the manual for the exact model of Juniper network switch in their ISP's head-end. Only their ISP's network engineer needs to do that—and that fellow has had rather a lot of exposure to Juniper products, and so likely already has their support site bookmarked. (And probably has the physical copies of the manuals, too, if they still print those.)

------

† Tangent: it'd be a fun project/blog post, to go through the Google search results for the search-terms "0" through "9999", and categorize the top results by keyspace. How many times do RFCs "win"? Etc.

> With any of these identifiers, the thing you do instead of just punching the ID into a search engine, is to first search for either 1. the website of the entity you know owns the thing, or 2. some kind of "catalog" site; and then plug the otherwise-non-unique identifier in there. Your identifier, despite not being unique generally, is unique when put in the context of a domain-specific keyspace.

Nit-picky perhaps but DOIs are extremely unlikely to be used elsewhere to mean something else. In a search engine you'll get either the original article or articles that cite it. The reason you'd use something else to get to the article is that there's a single location for all of them to be resolved, and even then people will still just google them. In fact, googling them can be more reliable when they've not been correctly registered.

It's not really counter to the general point, they're not useful for products and perhaps I misread your statement but DOIs absolutely work as "just look for this string".

You're right; DOIs aren't a good example. Edited to remove.

In the case of DOIs, https://dx.doi.org/${DOI} should also return the target article with no need to search.

Only if correctly registered :) it does usually work but I'm always surprised at how frequently they don't. I work with large amounts of them though, which tends to bring out the edge cases. Googling can be more reliable, and typically safe given how unique they tend to be (again, weirdly not always). A bonus is you may get results for related pages that reference your wanted paper

The Apache projects page literally lists "Apache" in front of each of the projects you just mentioned. If I go to the apache streams github page it's url is https://github.com/apache/streams not https://github.com/streams/streams.

Contrast that when I go to the Docker distribution github page the url is https://github.com/distribution/distribution. You don't see anything wrong with that nomenclature? I'm the only one?

I just searched “Docker distribution” on Google and the first result was the GitHub repository for this, so it apparently is not.

I think it is a confusing name because "Docker Distribution" sounds like a distribution of the Docker daemon and/or client, not the container registry.

If they called it something like "OpenHub", "OpenRegistry", whatever – those may be boring unoriginal names, but would have made it more obvious at first glance what exactly it was

They've managed to hit a new high score for a README [0] full of sound and fury: only one sentence of actionable information "The specification can be found here."

[0] https://github.com/opencontainers/distribution-spec

That is not the project, this is https://github.com/distribution/distribution

Reply on news.ycombinator.com