cryptocurrencies are ruining hardware availability (both GPU and now storage devices), the environment and now free cloud services. When are we gonna admit it? EDIT: typo
By cryptocurrencies do you just mean BitCoin? Most new crypto's use proof of stake which doesn't use up GPUs. Not heard it blamed for using up hard drives before.
Changes to Docker Hub Autobuilds
31–40 of 53 posts
Re: Changes to Docker Hub Autobuilds
#32Re: Changes to Docker Hub Autobuilds
#33cryptocurrencies are ruining hardware availability (both GPU and now storage devices), the environment and now free cloud services. When are we gonna admit it? EDIT: typo
When the sun is wrapped in a Dyson sphere covered in solar panels made from Jupiter’s mass?
Re: Changes to Docker Hub Autobuilds
#34Re: Changes to Docker Hub Autobuilds
#35Earlier quoted context omitted.
Just wait another week or two and we are going to see a similar story about GitHub Actions.
They did similar a few months ago, https://www.infoq.com/news/2021/04/GitHub-actions-cryptomini...
Re: Changes to Docker Hub Autobuilds
#36Should we look into implementing our own registry with AWS ECR or similar?
Re: Changes to Docker Hub Autobuilds
#37If this means a better experience for paying customers, I'm all for it. I have no problem with companies charging for their services.
If everyone and everything went paid-only, you'd see a lot less open source software get made. I may be ready to sink a bunch of time into that sorely-missing piece of software I know how to write, but I wouldn't be willing to throw a bunch of money in as well, and I'm sure lots of others would draw a line there.
Same thing with open-sourcing things created at work; it's a hard sell already, but with an ongoing financial commitment, not going to happen. So personally I'm very happy that lots companies still support this sort of thing with free services, and I really hope this kind of crypto cancer won't kill all of them eventually.
Re: Changes to Docker Hub Autobuilds
#38Do folks here have ideas of what will become the best place to host public Docker container images? Between this and the earlier changes to rate limit pulls, Docker Hub no longer seems like the ideal venue for reputable public images. Should we look into implementing our own registry with AWS ECR or similar?
Re: Changes to Docker Hub Autobuilds
#39If this means a better experience for paying customers, I'm all for it. I have no problem with companies charging for their services.
For example, I maintain a Docker image that builds statically-linked Rust binaries for Linux. It includes static versions of several C dependencies. It's useful mostly because setting up cross-compilation is really tricky and the details change occasionally.
I've been keeping it up to date for many years, and it has about 750k downloads (which is pretty decent for a compile-time-only Rust image). I don't mind maintaining it as a volunteer service for people who use it. But there's a good chance that I'll simply retire it, and that any paying Docker customers will need to figure out how to cross-compile weird C libraries on their own.
I'm not complaining. Docker owes me nothing, and I can just build images for my own use.
Re: Changes to Docker Hub Autobuilds
#40Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.
Agreed. Docker (actually, containers in general but docker tooling) made it so damn easy to get local, reproducible builds. It’s fantastic and made life so much easier for me professionally as a Software Engineer. I remember the early days when Docker had just released, all devs were super excited but nobody had run containers “in production”. AFAIK I believe it was mesos that was used widely for orchestrating contai…
All along it has always just felt way too imperative. It was too much of a sense that you were issuing commands at a system rather than declaring a desired end state. Kubernetes got this right from the get-go.