Hacker News Reader

Also:

> Instead of free use of Docker Desktop until now, this software suite is now available for rent after the transition phase until the end of January 2022, starting at $5 per user/month, provided it is for professional use.

> Here, Docker Desktop includes the Docker Engine, docker-cli, docker-compose and a credential helper, among others.

At least docker-compose (and probably also docker service + cli, since it is included in Debian) is FOSS. While they might be included in Docker Desktop, they are certainly available separately, so paying for the licence is in no way obligatory when using docker.

Yeah, the main benefit of docker desktop is packaging up a nice Linux VM on Mac/Windows, plus some UI features. There’s a reason ’Docker Desktop for Linux’ came so much later.

Dunno, I think WSL2 is actually better on that front. Just do the super secure "curl get.docker.com|bash" in it and you're golden. Even better UX then docker desktop if you specifically don't want a GUI

I think there are benefits to using Docker on Windows without relying on WSL2, especially when you need to run windows containers that depend on HypervV. I've worked at a few .Net shops that were stuck with .Net Framework with no clear, not easy way to modernize, so perhaps a compromise is containerize the applications into Windows containers.

Doesn’t wsl2’s docker rely on the windows docker desktop? Because there’s no systemd in wsl2, the regular docker service wouldn’t run anyway.

Docker doesnt need systemd

I wrote a comment for the general comment section, but wanted to respond to your comment as it contains valid criticism.

1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise...

>> You are right. That's a mistake.

2. k8s did'nt remove dockershim for political reason..

>> That is a valid point and the official story. Imho I think the acquisition was nevertheless something that played an accelerating role in this, since it happened relatively soon after the acquisition. Mirantis acquired Docker Enterprise in November 2019, and the end of Dockershim support was announced in 2020. I've heard that from a few other people as well. BUT this is just rumor, so you might be right.

3. Rate limits have nothing to do with the container runtime..

>> This is 100% true. Nevertheless, dockerhub is part of Docker and therefore a rate limit on the official Docker registry is something that has made our customers switch registry to other registry providers or implement their own container registry. Therefore, they are getting rid of this service, which is part of the Docker-only ecosystem, so its usage in enterprises is decreasing.

4. RedHat support switched to Podman as it is on of their products..

>> It only makes sense for RedHat to support Podman since it's from their own product forge. You are right about that. That said, there are a lot of companies using RH and paying for it, which automatically leads to a decrease in Docker usage vs Podman. Less use of Docker means more use of Podman. Last but not least, RedHat would not invent Podman if there was no need for an independent tool to Docker. Podman helps in some areas where Docker lacks features, such as support for pods, rootless mode, etc.

Thanks for your criticism! It is appreciated and helps us to do better.

> The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror.

What I never understood is why they didn’t just properly handle this with mirrors like any package manager does; why is this a problem for docker, but not for yum / apt / etc?

I have to admit that these rate limits have accelerated my migration to alternatives like quay.io

A guess: it takes a long time to get a reliable network of mirrors (mostly spent building relationships with institutions, like universities, with both the bandwidth/infrastructure you need and the willingness to lend it for free), and Docker is quite new.

Why would anyone give a for product company free stuff? You don't get to have it both ways. It's either open source or it's not and from what I've seen of docker, it's very closed.

Docker is a for-profit company. The question wasn't "how do we ensure that this stays available?" but "how do we make money from this?".

To that I say that Docker is a great example of terrible choices on how to monetize their technology, this being one of them.

By default container images are not signed (there is notary, but it's not commonly used - maybe notary V2 will change that - and I think the signature changes depending on the registry it's hosted on anyway?) which make it inconvenient to mirror.

Now, why are we still producing new package formats without mandatory signatures (containers, npm, cargo, etc) is not really clear to me. I guess everyone must think "those old crazy Unix folks signing their Deb and Rpm must have had their crazy reasons, but we have no reason to do the same" :) a more cynical thinking would say "it makes it inconvenient to mirror things and easier to build a business from the central repository" :)

There's also the conspiracy : "it's the CIA who infiltrated docker to get access on every server in the world" ;)

This is a quite reasonable attack vector for US cyber-offense.

The layers have checksums so couldn't you store the metadata centrally and mirror the checksummed blobs?

What is rate limited on docker hub is fetching the image manifest, rather than the blobs, so that wouldn't work I think.

https://docs.docker.com/docker-hub/download-rate-limit/#defi...

I believe that adding key handling as a necessary step for npm, docker, and similar registries isn't a good idea.

But it would be easy to sign all packages: if the author has decided not to use signatures the registry adds it's own signature, at any moment the author can choose to start using their own keys in place of the registrie's

They opposed to add support to private mirrors in the software, probably to retain their monopolistic position

https://github.com/moby/moby/pull/34319

You can setup pull through caches, function basically the same as a mirror of you have pulled an image before.

https://docs.docker.com/registry/recipes/mirror/

The details are wrong, but I think there's some merit in the general thought:

"Docker the company is having trouble monetizing their products...so I'm unsure about their future"

And, so the follow on of:

"Can I use compatible tools that don't depend on Docker, the company, as much?"

Makes some sense.

> To execute the images Podman then uses e.g. the mentioned containerd,

Another wrong thing. Podman directly controls the runtime (crun or runC). It does not talk with containerd like Docker.

Right. This is a major selling point of podman in Red Hat material.