Docker is deleting Open Source organisations - what you need to know

I'm not too familiar with docker infra at large, but could the docker hub in principle act just as a namespace such that the opensource projects could have the images hosted elsewhere, but docker hub just redirects them there, so saving on the bandwidth on those?

I suppose there are hand-wavy business reasons not to do that, but somehow I feel that would:

  1. Still keep themselves in the loop and relevant, owning the namespace/hub/main registry
  2. Offset the costs of those that they don't want to deal with (push them to ghcr or whatever)
  3. Preserve some notion of goodwill in not braking the whole dockerverse

Cargo and NPM and PyPi and RubyGems and likely others all definitely support this too.

From the article:

> If you are able to completely delete your organisation, then you could re-create it as a free personal account. That should be enough to reserve the name to prevent hostile take-over. Has Docker forgotten Remember leftpad? > > This is unlikely that large projects can simply delete their organisation and all its images. > > If that's the case, and you can tolerate some downtime, you could try the following: > - Create a new personal user account > - Mirror all images and tags required to the new user account > - Delete the organisation > - Rename the personal user account to the name of the organisation

Seems like no?

We cannot rename personal accounts on Docker Hub in 2023. There is no such feature in account settings, and here is the related issue: https://github.com/docker/roadmap/issues/44

So, at the moment, any public organization images are doomed to be lost, if they won't pay.

Many (most?) BitTorrent clients support web seeding[1] by a regular HTTP server.

A public registry could do web seeding, with bandwidth restrictions if needed, to ensure availability.

[1]: https://en.wikipedia.org/wiki/BitTorrent#Web_seeding

This is true, I can put nix apps in a container. It improves the reproducibility of builds, but it still wastes disk space, because the container is still based on layers and not packages.

> There is definitely a bit of a learning curve but the time investment is frequently over exaggerated

I'm not talking about the learning curve and its time investment, I'm talking about design problems. Nix's invasiveness is completely unnecessary in modern Linux, it makes its installation a very special case and requires lots of patches to just get stuff to work in nix. The fact that nix patches built binaries so that they point to correct shared libraries locations is a crutch which shouldn't be there in the first place.

It also tries to reimplement pretty much every package manager and build tool, even if they already work well and provide the reproducibility guarantees, including cargo, poetry, npm/yarn. This is a time investment, but it doesn't help me build software that is more robust and correct, that part is already handled for me. Instead, it just worsens the DX, as it forces me to use tools non-native to the ecosystem without first-class support for commonly used features.