You can always rebuild the dockerfile, or create an account increasing your pull limit, or just host all the free infrastructure they’ve already built, or use competitors providing the same service with the risk of them doing exactly the same in the future. The difference with docker hub and just mirroring a linux repo is docker made it really easy for people who don’t need it to get into infra weeds but the complexity was always there.

> or just host all the free infrastructure they’ve already built, or use competitors providing the same service

That would be more reasonable if they didn't go out of their way to make doing so painful: https://github.com/moby/moby/issues/7203

I don't see how that particular issue is relevant here. Add a port number to the reference, problem solved.

The reality is, DockerHub (though originally called the Docker Index), was the first Docker image registry to even exist, and it was the only one to exist when image references were created.

Now, I would say there are definitely some issues you could have referenced here that would be more relevant (e.g. mirrors only working for DockerHub).

They're OCI images now, and Docker was largely a stolen idea from UNIXes* (unices?), including the term containers. As much as I like what Podman to open it up using Containerfiles and not defaulting to this, it might as well go even farther tweak the standard a bit - provide something like Dockerfile that's less golang-inspired and more linux-inspired, and improve the format for images - so the industry can move on from Docker lock-in.

* https://www.aquasec.com/blog/a-brief-history-of-containers-f...

Gee thanks for explaining the container ecosystem to me.

Docker wasn't stolen from anything. It built on top of existing things, even worked on new things, and provided a nice abstraction to everything.

> provide something like Dockerfile that's less golang-inspired and more linux-inspired

What? Is the thing that's golang inspired the image references? OK...

Co-opted it is what I mean by stole.

The Dockerfile takes from golang IMO, it's intentionally very low on syntax. Just like go's text/template and html/template.

That's what makes it approachable (though I don't agree it has an semblance to go other than "FROM <ref>" being fully qualified (minus the carve-out for Hub), but even then it can absolutely act more like a local import if you have an image with that ref locally (or you can even override it in your build command in a couple of different ways).

Also note, Docker can build whatever format you want, it just defaults to the Dockerfile format, but you can give it whatever syntax parser you want.

There is nothing Go-like about Dockerfiles. The file naming seems to be an offshoot of Heroku's "Procfile" convention. I have no idea where the syntax came from, but it's superficially a very simple "SHOUTYCOMMAND arguments...\n" grammar with no structure beyond sequence-of-lines. Perhaps it's the more imperative cousin of the ".env" files popular with web devs.

I guess it's kind of like assembly where COMMAND foo is like INSTRUCTION foo. Maybe it just clicked for me and I can't think of a syntax I'd prefer for it. Which now has me wondering about modeling syntaxes for other things on it.

For some reason it reminded me of the WAC model from WebAssembly component model https://component-model.bytecodealliance.org/creating-and-co... No particular comparison, but I'd like to understand how constructing a container image might compare to constructing a wasm module from components.

Yeah I switched to podman, I don’t even have docker installed anymore :)

> Countless other tools and workflows and experiences have been built on that free assumption of availability

Cannot help but notice that, had Microsoft offered such a sweet deal, this place would've been ablaze with cries of "Embrace, extend, extinguish" and suchlike. (This still regularly happens, e.g., when new Github features are announced). Perhaps even justifiably so, but the community has failed to apply that kind of critical thinking to any other company involved in open source. If your workflow is not agnostic wrt where you pull images from, it is kind of silly to blame it on Docker Inc.

Having said that, it is definitely a problem for many. I work at a technical university and I am sure colleges/research institutes will hit the limit repeatedly and easily.

Too right. Now I'm starting to wonder how long my gmail account will remain free, and for that matter how long my HN account will remain free.

The data mining is probably too profitable to ever lose customers over required paid gmail accounts.

Well, neither of them store and serve multi-gigabyte files, so probably longer than docker hub?

Not a new concept. If you aren't paying you are the product. Increasingly capitalism demands the product also pay. Buckle up, late stage capitalism continues.

Sometimes you're the product, other times you're the raw material ready to be crushed up into a fine powder and mixed with 20 additives known only by numbers, and thoroughly homogenized to make the product.

"Late stage capitalism" doesn't exist. There are only consumers that exercise their rights as consumers (as in decades past) and those that don't (as now). If you don't do anything about companies treating you badly, then don't get surprised when they do.

Its so easy and yet…you can’t be bothered to maintain the registry and ecosystem. I have an idea, why not pay someone to do it?

I can't seem to parse this reply. I never said any of it was easy. Quite the opposite, in fact. The community was all too happy to embrace an ecosystem provided by a for-profit company just precisely because it made things easy (and the company was not Microsoft).

And I am not saying Docker is wrong to try and monetize. People have built entire business models on top of way more mundane things than the Docker Hub.

"foo.com will always be there and privide free, unlimited use" is the primary example of "clouded" thinking.

And yet the Debian package manager has been there, provided free for so long that it was around to watch the dot-com boom and then the bust and then watch the rise of the public cloud afterwards.

Sure you can’t expect things to be available free forever, except many software package repositories have been available, free, forever. We have countless software package managers (apt, brew, pacman), countless language library managers (npm, maven, CPAN) and countless other tools that have had free and relatively unmetered access for literally a generation.

If anything, “Software X will always be a CLI installation away, free, forever” is an old Linux expectation that’s existed for over 30 years and not some “cloud” mentality.