[sirius87]

> model of sending around megabytes-to-multigigabytes of VMs is inherently too expensive

Yes. I think automated build pipelines running 24x7 that could request even for the oldest version of a sizable image without caching at their end is part of the issue. There was no limit that I'm aware of on the no. of tags/versions per image or per OSS account on DockerHub, so just like package repositories, effectively every image had to be available forever and each image was of significant size. I don't believe storage and network tx costs have reduced at the same rate as increase in adoption of build pipelines and automation.

Same issue exists for apt, NPM, Maven, PyPi, or any other repository, but yes, the storage requirement should be significantly smaller.

Aside: Because Java has been around for so long in enterprises, many have learned over time to set up registries internally - a combination of wanting to host private packages securely on prem and protecting from downtime, supply-chain attacks. JFrog Artifactory is pretty commonly seen. However, IIRC npm registry was not easy to self-host on prem in the early days, and many enterprises had their private packages hosted on npm.

[Datagenerator]

The ISO mirrors of every Linux / BSD* have been successful for decades. Decentralized repositories could solve many problems. Add Bittorrent as acceptable usage pattern like the free AI community is using to solve it even further, the Internet was not designed to be centralized IMHO.

[fweimer]

The difference is that the average distro user cannot just push a new ISO image to the mirror network, say after changing some installer defaults (or more realistically, push a new QCOW2 image). There's also a substantial delay between mirror pushes and the update being ready for installation everywhere, something that developers probably would not accept in their pipelines.