Live data from Hacker News

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

blog.alexellis.io

211–220 of 764 posts

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

#211
post #3

Can we just get the big three cloud players to make a new public repo? They’ve got oodles of bandwidth and storage, plus the advantage that a lot of access would be local to their private networks. Setup a non-profit, dedicate resources from each of them spendable as $X dollars of credits, and this problem is solved in a way that works for the real world. Not some federated mess that will never get off the ground.

Consensus on a new repo for public community images would help, but it isn't the biggest problem (as the author notes, GHCR does that already, and GitHub seem pretty committed to free hosting for public data, and have the Microsoft money to keep doing so indefinitely if they like). The issue I worry about is the millions of blog posts, CI builds, docker-compose files, tutorials & individual user scripts who all refer…

Yeah that's going to be the real issue, all the niche unmaintained images that no one is going to pick up the pieces for.

They're taking a big chunk of open source and tossing it in the garbage.

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

#212

Docker the tool has been a massive benefit to software development, every now and then I have a moan about the hassle of getting something bootstrapped to run on Docker, but it's still worlds better than the old ways of managing dependencies and making sure everyone on a project is aligned on what versions of things are installed. Unfortunately Docker the company appears to be dying, this is the latest in a long line…

I'd like to see Docker succeed. They invented / formalized the space and deserve credit for that. They are probably doing the right thing with some of their development tooling (though maybe that should just be spun off to Microsoft) and ensuring images do not contain badware is something companies will pay for. However, their core offering must be the leader if they want to survive. Devs must want to use "docker run…

> I'd like to see Docker succeed. They invented / formalized the space and deserve credit for that.

If by succeed, you mean they deserve to have revenue, I disagree.

They spun some cool work out of dotCloud when it failed. They seemed to delay thinking about how they'd monetize the work, and sort of fell into charging for developer tooling after their orchestration play lost to kubernetes.

At this point, I think of Docker the company as a wannabe Oracle. They are desperate for money, and are hoping they can fool you into adopting their tech so they can ransom it from you once you rely on it. If that sounds appealing to you, I'd say go for it.

For me, that situation seems worse than what I do without containers at my disposal. In other words, the solution is worse overall than the problem.

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

#213
post #87
post #3

Can we just get the big three cloud players to make a new public repo? They’ve got oodles of bandwidth and storage, plus the advantage that a lot of access would be local to their private networks. Setup a non-profit, dedicate resources from each of them spendable as $X dollars of credits, and this problem is solved in a way that works for the real world. Not some federated mess that will never get off the ground.

aws already have one https://gallery.ecr.aws/

Unlimited free downloads inside AWS. First 5TB of outbound transfer free. Then $0.09/GB for additional transfer.

https://aws.amazon.com/ecr/pricing/

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

#214
Could IPFS possibly be a good distributed (and free?) storage backing for whatever replaces DockerHub for Open Source, as opposed to using something like GitHub? We'd still need a registry for mapping the image name to CID, along with users/teams/etc., but that simple database should be much cheaper to run than actually handling the actual storage of images and the bandwidth for downloading images.

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

#215

Earlier quoted context omitted.

> That's a neat idea but probably unworkable in practice. Container images need to be reliably available quickly; there is no appetite for the uncertainties surrounding the average torrent download Bittorrent seems to work quite well for linux isos, which are about the same size as containers, for obvious reasons. IMO, the big difference is that, with bittorrent, it's possible to very inexpensively add lots of semi-r…

Nobody is going to accept worrying about whether the torrent has enough people seeding in the middle of a CI run. And your usual torrent download is an explicit action with an explicit client, how are people going to seed these images and why would they? And what about the long tail?

Nobody needs to be seeding if only one download is active. You could self host an image at home on a Raspberry Pi and provide an image in a minute.

Nobody's CI should be depending on an external download of that size.

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

#217

Earlier quoted context omitted.

Docker should have been a neat tool made by one enthusiast, just like curl is. Instead it has a multi-million dollar company behind it, and VC's who demand profits from a thing that shouldn't have ever had a business plan.

It seems like another symptom of zirp/cheap money. Lots of ideas that could have been a neat feature or tool somehow ended up raising $500M of funding with no viable plan on ever monetizing. The fact that the product is successful but after a decade they barely make $50M/year of revenue against $500M of lifetime funding is crazy. As a user, you can work at a company with a billion in revenue and barely owe them a few…

Some time ago I learned that Postman Labs that produces a nice but not-a-rocket-science HTTP client raised $433M at multi-billion valuation and has 500 employees. Isn't it astonishing?

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

#218
post #107

Earlier quoted context omitted.

Docker Hub is a massive expense when you consider the data storage and egress. To do that for open source projects you have to wither (a) have a lot of income to cover such an expense, (b) a pile of VC funding to cover the expense, or (c) pile on the debt paying for it while you grow. (b) and (c) can only live on so long.

That's a self inflicted problem by docker hub squatting the root namespace, though.

This was the initial pebble that lead to Podman existing via Red Hat. No Red Hat customer wanted to pull or push to DockerHub by default due to a typo. No PRs would be accepted to change it and after dealing with customer frustration over and over...

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

#219

Earlier quoted context omitted.

As someone who's been bitten by this, I'm not sure if it's an issue with podman itself as much as the tools which expect docker. It could be argued that podman is not a docker drop-in replacement, but I expect more and more tools to pick it up.

> It could be argued that podman is not a docker drop-in replacement This is an unfortunate part IMHO. podman is not a docker drop-in replacement, but it is advertised as such.

Worth remembering is that Docker supports Windows containers. That’s a hard requirement for many enterprises.

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

#220

Earlier quoted context omitted.

>> Image hosting is expensive at scale, and someone's got to pay for the compute/storage/network.. Bit Torrent would beg to differ.

That's a neat idea but probably unworkable in practice. Container images need to be reliably available quickly; there is no appetite for the uncertainties surrounding the average torrent download

People who need "reliably available quickly" can pay or set up their own mirror. Everyone else can use the torrent system.
Post reply on HN