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 reference community images on Docker Hub, a huge percentage of which are about to disappear, apparently all at once 29 days from now.
From a business perspective particularly, this looks like suicide to me - if you teach everybody "oh this guide uses Docker commands, it must be outdated & broken like all the others" then you're paving a path for everybody to dump the technology entirely. It's the exact opposite of a sensible devrel strategy. And a huge number of their paying customers will be affected too! Most companies invested enough in Docker tech to be paying Docker Inc right now surely use >0 community images in their infrastructure, and they're going to see this breakage. Docker Inc even directly charge for pulling lots of images from Docker Hub right now, and this seems likely to actively stop people doing that (moving them all to GHCR etc) and thereby _reduce_ the offering they're charging for! It's bizarre.
Seems like a bad result for the industry in general, but an even worse result for Docker Inc.
It’s constantly getting rate limited in CI then we have to re-run tests due to flappy failures. Maybe it’s an easy fix or something we did wrong, but we have a parallel system on DockerHub that just works™
> Can I use Quay for free?
> Yes! We offer unlimited storage and serving of public repositories. We strongly believe in the open source community and will do what we can to help!
I love this comment because I only read the above, started thinking about how I would do it, then was like "ah! I'll reply...", and then saw it and changed course
iirc gitlab's free tier has a storage and bandwidth limit which applies to the container registry too. That makes gitlab a no go if you want to share containers widely.
Just did this yesterday, it was surprisingly easy. I used the HashiCorp Vault secrets plugin for GitHub and pushed containers via GitHub Actions, so for me it became more secure than storing and retrieving a docker hub API key.
It's on ours where I work, which is why we use Gitea to clone the various open source projects we use to our own servers. With binary level deduplication the amount of data stored is actually incredibly small. I think the unduplicated storage is like 50GB, and the deduplicated is like 10GB?
applies very much to Github, and for all of their services, not just containers. The elephant in the room, hardly needs to be mentioned I would think (Microsoft). We are only a few years into that regime.
Serious question, though: how many services have they offered over the years that were free to anyone?
Free to existing Windows users, perhaps, but free to the world doesn’t seem like something Microsoft was historically in a position to offer, much less later kill.
Hotmail/outlook.com and OneDrive are two services that Microsoft has been offering for decades, for free (with a storage limit, but that’s nothing weird), no Windows required.
It's not randomly and suddenly killing off services, but rather suddenly (and not randomly) changing the pricing structure when companies have been committing to the point of lock-in for years on the free tier.
Unlike Docker Inc, GitHub (via Microsoft) do have very deep pockets & their own entire cloud platform, so they can afford to do this forever if they choose.
And their entire marketing strategy is built around free hosting for public data, so it'd take a major shift for this to disappear. Not to say it's impossible, but it seems like the best bet of the options available.
Is it practical to set up a redirect in front of a Docker registry? To make your images available at example.com/docker-images/abc, but just serve an HTTP redirect that sends clients to ghcr.io/example-corp/abc? That way you could pick a new host now, and avoid images breaking in future if they disappear or if you decide to change.
That's different - that's about changing the _client_ configuration. I'm looking to change the server instead, so that the client can use an unambiguous reference to an image, but end up at different registries depending on the server configuration. In a perfect world, Docker Hub would let you do this to migrate community projects away, but even just being able to manually change references now to a registry-agnostic URL would be a big help.
Shouldn't be any security risk there AFAICT. Just hard to tell if it's functionally supported by typical registry clients or if there are other issues that'd appear.
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 of decisions that are clearly being made because they can't work out how to build a business around what is at it's core a nice UI for Linux containers. My hope is that before the inevitable shuttering of Docker Inc another organisations (ideally a coop of some variety, but that's probably wishful thinking) pops up to take over the bits that matter, and then hopefully we can all stop trying to keep up with the latest way in which our workflows have been broken to try and make a few dollars.
Podman is great and is first class citizen on Fedora. It also integrates nicely with SystemD.
My only gripe with it is not many developers provide podman configuration on their install pages like they do with docker compose
I'm using docker-compose with a podman VM for development on a mac. Works ok so far. It wasn't quite slick enough when Docker pulled the licence switch last year, but the experience in the last couple of months has been pretty painless.
Tangent: Why is the misspelling "SystemD" so common, when it has always been "systemd"? I would understand "Systemd" or "SYSTEMD" or something, but why specifically this weird spelling?
> System D is a manner of responding to challenges that require one to have the ability to think quickly, to adapt, and to improvise when getting a job done.
> The term is a direct translation of French Système D. The letter D refers to any one of the French nouns débrouille, débrouillardise or démerde (French slang). The verbs se débrouiller and se démerder mean to make do, to manage, especially in an adverse situation. Basically, it refers to one's ability and need to be resourceful.
> But then again, if [calling it systemd] appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?).
Fortunately you can use docker-compose with Podman these days.
(There have been a few false starts so I'm specifically referring to the vanilla unmodified docker-compose that makes Docker API calls to a UNIX socket which Podman can listen to).
It’s literally OCI compatible, integrates with systemd and LSM, and runs rootless by default. Podman is 100000% better designed on the inside with the same interface on the outside.
Rootless networking is still a mess with no IP source propagation and much slower performance.
So for most users docker with userNS-remapping is actually a better choice.
Also systemd integration isn't a plus for me, I don't want to deal with SystemD just to have a container start on startup.
You're right, it's both easier and simpler since no daemons are involved. podman-compose has the same command-line interface and has worked ok for me so far (maybe 3 or 4 years at this point).
Podman-compose isn't fully compatible with the new compose spec.
Also I really don't care if docker has a daemon or not, for me it offers feature like auto starting containers without bothering with SystemD, and auto updates using watchtower and the docker socket.
And since podman doesn't have an official distro package repo like docker, you are stuck use whatever old version shipped in your distro without recent improvements, which is important for a very active development project.
> Also I really don't care if docker has a daemon or not, for me it offers feature like auto starting containers without bothering with SystemD
Bingo, the "pain" of the daemon (it's never cause a single problem for me? Especially on Linux, on macOS I've occasionally had to go start it because it wasn't running, but BFD) saves me from having to touch systemd. Or, indeed, from caring WTF distro I'm running and which init system it uses at all.
I don't understand what the issue is. Don't use an LTS distro if you want up to date software. Fedora and Arch are up to date for Podman. Alpine seems to be one minor version behind.
I want stability for the system and a newer podman version.
I do this all the time with docker, install an LTS distro and then add the official docker repos.
So I'm not in the details of this but I understand from k8s slack that there is a fixed GCP budget for image hosting and Kubernetes is getting through it too quickly which is why they're moving the registry domain to a generic one from a GCP specific one, to allow for other funding to be found and used.
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
> 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-reliable bandwidth.
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?
We are talking about replacing the docker hub and the like, what people "should" be doing and what happens in the real world are substantially different. If this hypothetical replacement can't serve basic existing use cases it is dead at the starting line.
Archive.org does this with theirs. If there are no seeds (super common with their torrents—IDK, maybe a few popular files of theirs do have lots of seeds and that saves them a lot of bandwidth, but sometimes I wonder why they bother) then it'll basically do the same thing as downloading from their website. I've seen it called a "web seed". Only place I've seen use it, but evidently the functionality is there.
I'm pretty much convinced the people at Docker have explicitly made their "registry" not be just downloadable static files purely to enable the rent-seeking behavior we are seeing here...
While that's true, for the amount of network traffic they're likely moving around, I wonder where they're placing their servers.
eg something like AWS with massive data transfer costs, vs something else like carefully placed dedicated/colocation servers at places which don't charge for bandwidth
If it's AWS, they've surely got a huge discount. No way they're paying 8+x normal big-fish CDN rates for transfer. At their scale, it would have easily been worth the effort to move to something cheaper than AWS long ago, or else to negotiate a far lower rate.
If I can't use it as a daemon-focused package manager that works more-or-less the same everywhere with minimal friction without having to learn or recall the particulars of whatever distro (hell, on my home server it even saves me from having to fuck with systemd) and with isolation so I can run a bunch of versions of anything, I'll probably just stop using it.
Everything else about it is secondary to its role as the de facto universal package manager for open source server software, from my perspective.
... of course, this is exactly the kind of thing they don't want, because it costs money without making any—but I do wonder if this'll bite them in the ass, long-term, from loss of mindshare. Maybe building in some kind of transparent bandwidth-sharing scheme (bittorrent/DHT or whatever) would have been a better move. I'd enable it on my server at home, at least, provided I could easily set some limits to keep it from going too nuts.
image hosting is not that expensive at scale. i can put an image on ECR and pay for bandwidth and storage at what is really not very good rates, and it still comes out way cheaper than paying for what docker hub wants me to pay.
How is a tool developed by, and strongly pushed by (to the point of strongarming customers to transition to their tool, features lacking be damned) a corporation, especially one owned by IBM, filling the role of a coop-developed tool?
I think that Docker can have a viable business plan but they had terrible execution.
At my previous position, I wanted to use DockerHub more heavily but the entire experience was like a bootstrap project someone did as a university assignment. Many advanced features for organizations were lacking (SSO/SAML) that we would have happily paid for.
I am usually an early adopter but I keep coming back to Docker since Podman is still very rough around the edges, especially in terms of "non-direct" usage (aka other tools)
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.
Is this a matter of developers constantly relearning the lesson of the folly of only supporting the current top thing, or is it a lot harder to support more than one?
I don't know how "hard" it is, but in my particular case I wanted to use this from intellij. It actually works, but the issue is that the docker emulation socket isn't where the ide expects it, and I haven't found a way to tell it where to look for.
The devil is in the details. For example, docker has a DNS service at 127.0.0.11 it injects into /etc/resolv.conf, while podman injects domain names of your network into /etc/hosts. Nginx requires a real DNS service for its `resolver` configuration.
Besides the advertising, it's very close to being a drop-in replacement but their pace isn't closing that gap quick enough (or maybe they don't want to, or it isn't possible, idk I'm just a user) so you get a false sense of confidence doing the simple stuff before you run into a parity problem.
Podman is interesting. I like the architecture problems it solves with respect to Docker but the way they went about it was typical big business Red Hat. Dan Walsh, Podman's BDFL it seems, basically stood in front of RHEL / OpenShift customers for years bashing Docker even when a majority of the things he was claiming were less than half baked. RHEL made sly moves like not supporting the Docker runtime, even at a time when it put their customers in an awkward spot before containerd won the k8s runtime war. Podman is backed by much larger corporate machinery. If anyone thinks that Podman "winning" is a good thing then you've played right in to Walsh's antics. RHEL wants nothing more than to have no friction when selling all the "open source" tooling you may need in your enterprise.
Podman wasn't built out of necessity but out of fiscal competitive maneuvering. And it's working. I see so many articles on the "risks" of Docker vs Podman. The root wars are all over the place. Yet... The topic is blown way out of proportion by RHEL for a reason: FUD all in the name of sales. Is there merit to the claim? For sure. Docker's architecture was originally built up as client/server for a different purpose. That didn't play out and the architecture ended up being a side effect of that. But we don't see container escape nearly as much as Red Hat would like us to believe. I keep paying Docker because I don't want to live in Red Hat's world, with their tooling that they can just lock out of other platforms once they feel like it. No thanks.
RedHat has not won any systemd war. From all the distributions out there using systemd, RedHat is the one that uses the least amount of systemd features.
They are even going so far as disabling features.
Sometimes they even backport systemd features from more recent versions, disable them but leave man pages in the original state.
Even the /usr split isn't progressing at all.
I too find Red Hat's poor documentation hygiene a pain in the arse. But as for the disabled system features, I think that they all fall into the category of experimental/unproven sort of features that overlap with other existing RHEL components. Every enabled feature has a cost in the form of support burden.
Those are not "systemd features", they are components within the systemd suite. Using systemd-init has never required that you use every component within the systemd suite (e.g. ntp, network management, etc.)
I'm not sure why it's so hard for anyone to find this on their own. OpenShift forced users to use CRI-O and RHEL removed Docker as part of the Yum repository.
OTOH, Docker didn't want to support a lot of features that enterprise customers wanted, like self-hosted private registries, because they wanted people using Dockerhub.
And wasn't the runtime problems because Docker was very very late to adopting CGroups v2?
Yes exactly. GP is misinformed on history. Red hat didn't sabotage anything. Docker took forever to update to cgroups V2, and that broke it for distros like fedora that are up to date. The user had to downgrade their kernel in order to use docker, but if they did everything else worked fine.
While you have a valid point with cgroups I never stated anything about "sabotage". So let's not play the misinformed card and then go on making things up.
As for Red Hat and their games of not supporting Docker, even after cgroups were addressed Red Hat never officially supported Docker as a runtime. How do I know this? Because at the time I was working with paying clients of RHEL/OpenShift and was on calls regarding said customers being forced to use inferior (their words) RHEL tooling. So while your history may have not seen the games Red Hat was playing, they surely were.
>Podman is backed by much larger corporate machinery. If anyone thinks that Podman "winning" is a good thing then you've played right in to Walsh's antics.
I'm not making a moral judgement. I'm just saying that docker had serious technical problems and docker the business sucked at monetizing it.
Docker played into red hat's tactics. I've never heard of Matt Walsh and frankly, I've wanted rootless containers for years before I ever heard of podman.
>Podman wasn't built out of necessity but out of fiscal competitive maneuvering.
Becuase red hat is a business not a charity.
I doubt they would have built a better docker if docker wasn't refusing to improve.
Podman winning is good. Red Hat consistently does things right, for example their quay.io is open source, unlike Docker Hub and GitHub Container Registry. The risks of not using rootless containers weren’t blown way out of proportion, because rootless containers really are much more secure. Not requiring a daemon, supporting cgroup v2 early, supporting rootless containers well and having them as the default, these are all good engineering decisions with big benefits for the users. In this and many other things, Red Hat eventually wins because they are more open-source friendly and because they hire better developers who make better engineering decisions.
> In this and many other things, Red Hat eventually wins because they are more open-source friendly and because they hire better developers who make better engineering decisions.
We must be talking about a different Red Hat here. Podman, with breaking changes in every version, that is supposedly feature and CLI complete with Docker, but isn't actually, is winning because it's more open source friendly or better technically? Or systemd, written in a memory unsafe language (yes, that is a problem for something so critical and was already exploited at least a couple of times), using a weird special format for it's configuration, where the lead dev insults people and refuses to backport patches (no, updating systemd isn't a good idea) won "because it was more open source friendly"? Or OpenShift that tries to supplant Kubernetes stuff with Red Hat specific stuff that doesn't work in some cases (e.g. TCP IngressRoutes lack many features), is winning "because it was more open source friendly"?
No, Red Hat are just good at marketing, are an established name, and know how to push their products/projects well, even if they're not good or even ready (Podman is barely ready but has been pushed for years by this point).
>Or systemd, written in a memory unsafe language (yes, that is a problem for something so critical and was already exploited at least a couple of times)
What memory safe language 1) existed in 2010 and 2) is thoroughly portable to every architecture people commonly run Linux on and 3) is suitable for software as low-level as the init?
Rust is an option now but it wasn't back then. And Rust is being evaluated now, even though it's not quite ready yet on #2.
Go, although with it's GC it's debatable to what extent it's suitable for very low level software.
And honestly the language choice was only the tip of the iceberg, it took years of people adapting before systemd became usable. And it still doesn't handle circular dependencies better than arbitrarily which is ridiculous, literally one of it's main jobs is to handle dependencies.
You may have a healthy dislike for the corporate behemoth that is RH / IBM, but, to my mind, Docker, Inc is worse: they keep more things closed, and they literally pressure for money.
I mean, I wish guys like FSF would have produced a viable Docker alternative, but this hasn't happened, at least yet.
I first found Podman when looking for alternatives when Docker broke on my laptop in the midst of all the Docker Desktop licensing changes. Frankly, I use it because it has been more stable lately, not because of any long run marketing campaign from Red Hat. I suspect a lot of its userbase will be in a similar place as the experience with Docker continues to degrade.
> Docker should have been a neat tool made by one enthusiast, just like curl is.
I have nothing but mad respect for Daniel Stenberg. 25 years of development of great software, for which he had been threatened[1] and had ridiculous US travel visa obtaining issues[2].
I read the travel issues post you linked, but am not seeing the causal link you’re drawing between development of software and visa issues. Was there more to the story?
I may have remembered incorrectly, which post was it. Here[1], in the paragraph titled "Why they deny me?" (unlinkable), Daniel hints at the possibility that this may have been due to development of (lib)curl which is used for malware creation by 3rd parties. There was no proof though.
Ah, that makes sense. I have no dog in the fight and am far from the emotion of having a visa delayed in this circumstance. I would say that it was much more likely to be some level of incompetence than malice, having dealt with large government bureaucracies myself.
The most superficial (and likely) reason to me seems to be that he uses haxx.se. I really wonder what kind of investigation they do. If they just start with Google, this one might come up immediately.
There was a period where the US was treating public key encryption like arms exports, and involved in spreading the technology outside the US as tools were in us.govs sht list
After a report from RSA Security, who were in a licensing dispute with regard to the use of the RSA algorithm in PGP, the United States Customs Service started a criminal investigation of Zimmermann, for allegedly violating the Arms Export Control Act.[5] The United States Government had long regarded cryptographic software as a munition, and thus subject to arms trafficking export controls. At that time, PGP was considered to be impermissible ("high-strength") for export from the United States. The maximum strength allowed for legal export has since been raised and now allows PGP to be exported. The investigation lasted three years, but was finally dropped without filing charges after MIT Press published the source code of PGP
Because he was competing with a private military contractor, and the US government is a wholly owned subsidiary of the MIC: or often acts like it is. Customs should have told RSA "no", "this is a private contract dispute", "hire a lawyer and file suit". Of course it was much more than that. Zimmerman put real privacy protecting encryption in the hands of the public, and the Many Eyes (that included state allies and adversaries) couldn't have that. But they needn't have worried: decades on the public is still ignorant about encryption, except as a marketing term, and most have no idea what a key pair is or what to do with it. Fraud around unauthorized access to government and commercial accounts is rampant (you _have_ set up and secured your online identity on your government's social security and revenue collection sites, haven't you?). That could have been prevented by early adoption and distribution of key pairs, alongside a serious public education campaign. Problem is, that would be at cross purposes with the goal of keeping the public uneducatable. Better for them to while away their time watching cable TV or delving into the latest conspiracy theory (pro or con).
Ridiculous? This is pretty common issue for anyone who travels to US. Visa may be denied for whatever reason and tough luck on appeal. I am EU citizen and had similar experience just for visiting Iran on tourist trip. Do not even ask about guys from India, Pakistan or less fortunate countries.
And it got even worse with pandemic. US required vaccination for very long time, long long after it was relevant. Maybe they still do, frankly I do not care to look at this point!
I think biggest WTF here is why international organization like Mozilla is organizing company wide meetup in US, and not in country with liberal visa entry policy such as Mexico!
I applied for US travel visa as a citizen of Poland in 2012 and was denied travel due to "wrong type of visa". I was planning to visit my employer and spend 1-2 weeks traveling across the country. Apparently both business and travel visas were inappropriate for these purposes. To add, I was questioned in a US consulate/embassy (can't remember) in Warsaw by a person who repeatedly refused to speak in English, insisted on Polish and I, as a native Polish speaker, had issues understanding them. Poor experience.
This was not a case for Swedish citizens, which is mentioned at the beginning of Daniel's linked post. Sweden is a member of ESTA[1] and Daniel traveled to the US multiple times before being denied travel (with still valid ESTA) and only then applied for a visa.
Yeah. I treat one-man small business serving mainly one big client to be comparable. On paper it's B2B, in reality it's working for the client and if the client is small business' main source of income, it's pretty much an employment.
Differences, in Poland at least, are that small business owner in this scenario is not protected by employment laws (3-months notice layoff, max 3 months salary-equal damages liability etc) and uses company's (EU)VAT registration number instead of personal social security number equivalent (PESEL number). It eases abroad contract agreements, invoicing and allows serving more clients easily. Company existence can also be validated on EU VIES[1] website quickly.
In the visa case, I have of course used the "paper" phrasing as in reality I was, and am, only employed by my own small business.
Ridiculous does not mean uncommon. Situations can be both common and ridiculous (absurd).
I'm American, but I have enough friends and family from other countries (my wife is an Iranian passport holder) to know what you're talking about and how difficult it can be.
People suffering from psychosis can create "facts" supporting their ideas and believe in them. Usually it's the stuff like "someone follows me", "someone wants to hurt me". Psychosis is the entry point to schizophrenia which is more or less, an illness in which brain makes stuff up and the ill person cannot differentiate facts from hallucinations.
Of course it is. What in the parent's post is different from that? The parent post's first sentence is, "People suffering from psychosis can create 'facts' supporting their ideas and believe in them."
It's not just people suffering from psychosis who do that.
"29% believe aliens exist and 21% believe a UFO crashed at Roswell in 1947. [...]
5% of respondents believe that Paul McCartney died and was secretly replaced in the
Beatles in 1966, and just 4% believe shape-shifting reptilian people control our world by
taking on human form and gaining power. 7% of voters think the moon landing was fake." -- https://www.publicpolicypolling.com/wp-content/uploads/2017/...
"Belief in both ghosts and U.F.O's has increased slightly since October 2007, by two and five percentage points, respectively. Men are more likely than women to believe in U.F.Os (43% men, 35% women), while women are more likely to believe in ghosts (41% women, 32% men) and spells or witchcraft (26% women, 15% men)." -- https://www.ipsos.com/en-us/news-polls/belief-in-ghosts-2021
"A new Associated Press-GfK poll shows that 77 percent of adults believe [angels] are real. [...] belief in angels is fairly widespread even among the less religious. A majority of non-Christians think angels exist, as do more than 4 in 10 of those who never attend religious services." -- https://www.cbsnews.com/news/poll-nearly-8-in-10-americans-b...
The other day some one mentioned any of these surveys consistently have about a 5% troll rate.
The 77% belief in angels is bizarre though. Like I believe in the possibility of aliens, the universe is quite large. Although I think all spacecraft sightings are almost certainly just mundane stuff from spy planes to weather balloons, etc. I even believe in the possibility of ghosts being real, more likely some strange phenomenon we can't explain that we might misidentify as ghosts. But angels?
One man's angel is another man's ghost or alien though I guess.
Indeed. According to [1], it would appear 58% of the US officially believes in angels by creed (Protestant, Catholic, Mormon, Orthodox, Jewish, or Muslim). Only 11% are atheist or agnostic, and there's a 30% group that's religious but "unaffiliated" or "other". I totally buy that two thirds of "religious but unaffiliated or other" would believe in angels.
The difference here is that to the religious mind, angels are credible in a way that UFOs, ghosts, and magic are not. (The irreligious mind probably finds them all equally credible, hence the disconnect.)
Put another way, it would not surprise me that someone who was "religious but not affiliated" might have a high regard for the Bible. Angels figure prominently in the Bible, and hence fall in that bucket.
I'm surprised aliens is the low one here. The exact question is "Do you believe aliens exist, or not?", not something more specific like little green men in flying saucers abducting cows.
The universe is large. In the tiny slice we can observe well enough to draw conclusions, Wikipedia currently lists 62 "potentially habitable exoplanets". I'd be much more surprised by intelligent life being unique to Earth than by there being many planets harboring intelligent life, or to answer the question as asked: I believe aliens exist.
If you have your name all over the place, I guess that it bound to happen eventually. Curl is used by millions of people which makes Daniel Stenberg kind of a celebrity. With so many users, there have to be some crazies like the "I will slaughter you" guy.
It must be a common occurrence among famous software people, I wonder how they deal with that. Do they actively hide their real identity, for example by using a proxy for licensing, do they just ignore such madness, is it a burden or on the opposite, they enjoy their fame?
There are lots of high functioning but harmless crazy people out there . I used to work for a government job and I found one of the most common tells was exactly what this "slaughter" person did. They love to list dozens of agencies to you for no reason. They have no authority so they hope they can borrow it from your fear of a random place. I cannot tell you how many emails/calls I have had left that fit this pattern, dozens at least.
>I have talked to now: FBI FBI Regional, VA, VA OIG, FCC, SEC, NSA, DOH, GSA, DOI, CIA, CFPB, HUD, MS, Convercent
Bonus Tell: They also love to say they are a doctor or PHD of something or often say PHD in multiple subjects.
I remember someone abusing a ticketing system I had to work with for reporting technical issues with a vast computer network, raising a ticket with an attachment from some absolute nutcase in multicolored manyunderlined .RTF format which was like as you described as "hate mail" in the subject line and the ticket being closed as "not hate mail", still makes me chuckle every time I think about that
In all fairness, curl is purely a software tool. Docker is arguably more like a service. As such, it creates costs for and direct dependency on the entity behind it.
Docker is a software tool. Docker Hub is a service. If Docker didn't stand up Docker Hub the equivalent services from GitHub, Google et al would have competed on a more even playing field.
It's almost like they created intentional ambiguity here when they renamed the company (dotCloud) to match the name of the open source tool, then renamed the open source project behind the tool to something else (Moby), but kept it for the command line tool, while also combining the name Docker into their product offerings, including Engine and Deskop, that handle completely different parts of managing containers. That's not even including registries, dockerfiles, Compose, Swarm, etc. and the ambiguity around where those sit in the a Venn diagram.
Lots of orgs figure out how to piggy back the “service” part of whatever they’re doing on free or sponsored infrastructure, though. Homebrew, for example, has been doing a lot of the same stuff on Travis and GH Actions since forever.
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 thousand/year. Or you might just use Podman for free, and prefer it due some of the design differences.
At the very least, a lot of these firms, with VC pressure, overstayed their welcome as private enterprises and should have sold themselves to a larger firm.
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?
Postman's strength is not in the HTTP client part. It is in the SaaS part, ad I think their valuation (even though overblown) mostly reflects their corporate penetration and the willingness of many companies to pay a small amount for their services.
Centralizing and sharing your API descriptions, test suites and plans, the various ad-hoc queries people usually keep in their notes or on Slack (and lose), handling involved auth stuff which is a hassle with curl, etc.
I think they gravitate towards the same area as swagger.io or stoplight.io, but from the direction of using the existing APIs.
API schemas and test suites are usually stored as code in some sort of SCM. I googled "postman maven" and "postman gradle" and found nothing official so I guess they have nothing except stand-alone workspaces.
API registry is a useful tool with modern love for nanoservices when a team of five somehow manages ten of those but I don't see anything similar done by Postman. Two of the service registries I know of were implemented in-house for obvious reasons.
Pretty much the entire "gig economy" is full of hot air and survives on regular influxes of VC money despite massive losses every year. The business model doesn't frickin work.
The hope from investors was that they would be investing into what would ultimately become a monopoly that could extract rents to repay them (not very competitive market of them, but that's tipping the hat a little isn't it...) but the funny bit is there's like 5-7 competitors in the US alone doing the same thing.
Here's a take: maybe this is just a natural monopoly situation, and if we like the convenience of gig delivery but don't like the high prices per order or that gig workers don't get sufficient pay, health insurance or other benefits, how about we just nationalize it?
You know, the same way we did for everything that wasn't food or groceries before? USPS Courier service sounds like an idea to me.
Nationalize it? No way. Besides I like rich investors ponying up money so my ride/food is more convenient and cheaper! It won’t last, but then what does?
Indeed. Docker should've been plumbing. They could've had a really nice business with developer tools on top of the core bits, but they decided to try to jump straight to enterprise and did a number of things to alienate partners and their broader community.
Instead of adding value to Docker they're just trying to find the right knobs to twist to force people into paying. And I think people should pay for value when they're using Docker substantially for business. But it seems like a very short-minded play for cash disregarding their long-term relationship with users and customers.
All that said: They have to find revenue to continue development of all the things people do like. I'd encourage people to ask if the things they've gotten for free do in fact have value, and if that's the case, maybe disregard the ham-fistedness and pony up if possible.
Last time I check rent is not free, food is not free, bus ticket is not free. No reason why software should be free.
Open source was invented by big co as a "marginalized your complement" strategy, not the ideal that is marketed as. As an evidence, I do not see any cloud vendor open source their code?
> Open source was invented by big co as a "marginalized your complement" strategy, not the ideal that is marketed as.
> In 1983, Richard Stallman launched the GNU Project to write a complete operating system free from constraints on use of its source code. Particular incidents that motivated this include a case where an annoying printer couldn't be fixed because the source code was withheld from users.
> Last time I check rent is not free, food is not free, bus ticket is not free. No reason why software should be free.
You are welcome to sell your software. You are welcome to be replaced if you can't compete. You don't have to sell your software and we don't have to buy it. You can and will be competed with.
Trying to build a multimillion dollar venture off a UI - even a good UI - is probably unwise. It does not seem to be going well for Docker who has gone from no competitors to multiple and all of those competitors are open source.
From your very link, 1983's GNU Project was not the first piece of Open Source software.
From your link: The first example of free and open-source software is believed to be the A-2 system, developed at the UNIVAC division of Remington Rand in 1953
> Software was not considered copyrightable before the 1974 US Commission on New Technological Uses of Copyrighted Works (CONTU) decided that "computer programs, to the extent that they embody an author's original creation, are proper subject matter of copyright"
FOSS before 1974 looks.. funny. It existed! But it did not look like the modern FOSS movement.
Even post 1974 and pre-GNU, FOSS-ish text editors and such existed. This was still the era when licenses were often non-standard and frequently did not exist. Handing your friend a copy of a program was the norm, regardless the actual legal situation (which itself was probably vague and unspecified).
for users to download resources from ifps you either need to install the client (which quite resource intensive) or use the gateways (which is just a server and cost money to run).
also the speed and reliability are nowhere good enough for serious works.
Yeah, but curl is used to access and download all sorts of data, which are all hosted by multi-million dollar companies. Just like git downloads and uploads data to git repositories. curl and git are valuable, but so is GitHub, and websites in general. The problem is that they haven't found a way to monetize docker hub.
FWIW, Docker was not intended originally to be a tool for commercialization; it grew out of dotCloud, which open sourced the tool as a last-ditch-effort of sorts, if memory serves.
Yeah! I should be able to get 50x value from software and not pay for it /s
The open source community that carrier Docker on its back and is now bending over. Let this be a lesson to you. If you're building open source, maybe stick to open source solutions in your tech stack and if it's not there build it. This is what Apache does for the Java ecosystem.
I don't have sympathy, the writing was on the wall and this isn't the first time it's happened to the community.
> If you're building open source, maybe stick to open source solutions in your tech stack and if it's not there build it. This is what Apache does for the Java ecosystem.
Docker was created by dotCloud for a different purpose than it ended up as. I think they are owed credit for what has become an incredibly elegant solution to many problems, and how great the user experience has always been.
Compare it to other corporate-managed tools like Terraform and Ansible. Both of them have horrible UX and really bad design decisions. Both make me hate doing my job, yet you can't not use them because they're so popular your company will standardize on them anyway. Docker, on the other hand, is a relative joy to use. It remains simple, intuitive, effective, and full of features, yet never seems to suffer from bloat. It just works well, on all platforms. There were a few years of pain on different platforms, but now it's rock solid.
And to be fair to them, their Moby project is pretty solidly open-source, and if Docker Inc dies, the project will continue.
I’m yet to be entirely sold on that, mostly because I think Nix the language isn’t anywhere near as accessible as Dockerfiles, but I’ll be the first one cheering if Nix does manage to take over.
Completely agree on the complexity criticism, but this interactive tutorial (that literally embeds a full nix interpreter in the browser) went a looooooong way towards making Nix files not just look like arcane incantations to me, and doesn't take very long to do:
if at some point you realize "oh... this is just JSON with a different syntax, some shorthands, and anonymous or library functions," you're on the right path
You might be interested in Devbox (http://jetpack.io/devbox)! We built Devbox because we were frustrated with our Docker based dev environments, and our goal is to provide the power of Nix with a more accessible interface (similar to yarn or other package managers).
docker-compose seems necessary only because you have your "official postgres dockerfile" and your self-built "web app dockerfile" (and maybe other things like an ElasticSearch dockerfile)
Docker files seem necessary only because... well put it this way, think of a Docker image as "the cached result of a build that just so happened to succeed even though it was entirely likely not to, because Docker builds are NOT deterministic."
Now enter Nix, where builds are more or less guaranteed to work deterministically. You don't need to cache them into an "image" (well, the artifacts do get cached locally and online at places like https://www.cachix.org/), and the only reason they can do that is because they too are deterministically guaranteed to succeed, more or less), which means you can just include any and all services you need. (Unless they need to run as separate machines/VM's... in which case I suppose you just manage 2 nix files, but yes, "composing" in that case is not really fleshed out as a thing in Nix, to my knowledge)
except you cant deploy Nix files, and even if you could, better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer.
> better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer.
lol, "tell me you never used Nix without telling me you never used Nix" because it literally guarantees that, each project is a pure environment with no outside influences. THAT IS LITERALLY ITS ENTIRE PURPOSE OF EXISTENCE lolol
I absolutely guarantee you that you will have more reproducible builds with Nix than with Docker. I know, because I've worked with both of them for months on end, and I've noticed that it pains me to work with Docker more than it pains me to work with Nix (hey, it's not perfect either, but perfect is the enemy of good in this case)
First you are tightly coupling your CI to your developers machine, that in itself is already a pretty bad idea. Second, if one employee wants to install htop on their machine, then every employee will have to install it, this can quickly become a problem when you have 500+ developers. Third, I think you missed the first part on the second quote, you are FORCING every developer to not only use linux but also to use one distribution that is pretty niche.
> First you are tightly coupling your CI to your developers machine
It's not like you can't configure builds differently based on an ENV variable, which is exactly what most build tools already do.
> Second, if one employee wants to install htop on their machine, then every employee will have to install it
There's actually a way to install things on the fly on first use. That way, if you never use it, it will never install. If you use it more than once, it will use the locally-cached version. Next?
> this can quickly become a problem when you have 500+ developers.
Nope. Already answered. Plus, you can allow some things into the "pure" environment if you wish. Harmless things like btop or htop, for example.
> Third, I think you missed the first part on the second quote, you are FORCING every developer
What part of "everyone has to use slow-ass non-deterministically-building Docker" is NOT "FORCING" every developer to use something? LOLOL. Plus, on Macs (which USED to be my preferred dev machine) it's slow as fuck, which is why I had to switch to a linux laptop anyway, which is why I said "fuck this" and installed NixOS and went to town instead.
> to not only use linux but also to use one distribution that is pretty niche.
First of all, wow, you are naïve. No good thing DID NOT start out "niche". Literally every technology I've gotten into except for ASP.CRAP was "niche" when I got into it- from Ruby, to Postgres, to Elixir, to Jquery (at the time)... Do not judge things based on their popularity because that's the Appeal to Popularity fallacy. Judge things based on their promise, young padawan. And Nix... promises much.
On systems that have the same containerization feature that Docker requires, i.e., Linux systems with recent kernels, you can use nix-bundle¹ or the flakes-based experimental command inspired by it, `nix bundle`² to generate an all-in-one binary that you can run without installing Nix on the target.
Of course, I can do a lot of record revenue and earnings selling five dollar bills for $4. I'm curious what a path to profit would look like...is this kind of squeeze the only way to get there?
I agree given the usual definition of "net earnings", but private companies often represent earnings in creative ways that exclude obvious costs (hey Uber!).
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.
Getting out of a self inflicted problem isn't so easy. They have spent a long time trying. For example, putting distribution in the CNCF, working with the OCI on specs (like the distribution spec), making it possible to use other registries while not breaking the workflows for existing folks, and even some cases of working with other registries (e.g., their MCR integration with Docker Hub that offloads some egress and storage).
The root namespace problem was created by an early stage startup many years ago. I feel for the rough spot they are in.
It's a self inflicted problem they've doubled down on, though, and that self inflicted problem is also the reason for their success. If docker hub could be removed in a config, the value add of docker the company is significantly diminished. It's hard to feel sorry for a company who actively pursued lock-in, and didn't make any real attempts at avoiding it (you know what would help? A setting to not use docker hub, or to use a specific repo by default), and who have built an enormous company on a value add that is a monkey's paw, and they've known that all along.
edit: https://github.com/moby/moby/pull/10411 this is the change that would _actually_ solve the problem of docker squatting the root namespace, and they've decided against it because it would make dockerfiles less portable (or really, it would neuter docker.io's home as the default place images live)
I fail to follow. If DockerHub is the part that actively burns money, why stick with it? If, say, Docker Desktop is the part that actively brings profits, why would it be afflicted if the users used a different image registry? Most companies, except the smallest ones, use their own registry / mirror anyway.
Even better, the registry may continue to exist, but would (eventually) stop storing the images, and start storing .torrent files for the actual downloads. Seeing an image from the GitHub release page would be enough for most smaller projects (yes, BT supports HTTP mirrors directly).
I suspect that dockerhub isn't the part that bleeds money, I suspect like many tech companies the part that bleeds money is sales costs and developer costs (see gitlab). Unfortunately I can't prove that though.
Docker downsized from 400(!) to 60 people a few years back, and a quick search on Google says they're now back up at 600 employees again. They have ARR of $50M [0] , which is probably a little short of paying 60 people SV salaries, but it's nowhere near enough to pay for 600 people.
As regards to the registry problem, "most companies" I suspect don't follow best practices and in fact do end up using docker hub for things like public images, but more importantly _there is no way to enforce this in the tool, and docker have refused to implement this when given a PR_.
I don't. Because there is this pattern from VCs to fund business models that involve dumping millions in resources as Open Source on the world and then owning a part of the ecosystem.
Docker originally wanted to "own" everything, if CoreOS hadn't pushed for the OCI spec, debalkanizing containers, Docker would have a near monopoly on the container ecosystem.
At this point Docker is just the command, and it is a tire fire of HCI gaffs.
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...
I'm not familiar with the 'root namespace squatting' or the typo issue. Do you mean the image namespace as described here: https://www.informit.com/articles/article.aspx?p=2464012&seq... or is there something else? What sort of typo would cause problems?
it will push a container with my secret application to the public docker hub, assuming I am logged in (which of course I am, because docker rate limits you if you don't). I don't ever want to do that, ever, under any circumstances, and it's just not possible to opt out of whiel using docker.
if you did `docker tag supersecret/app:latest && docker push` instead of `docker tag registry.corp.com/supersecret/app:latest` guess where your code just went?
Same on the pull side, if you wanted your corp's ubuntu base rather than just `docker pull ubuntu`.
Based on what? How is that more likely than just them being able to finally generate revenue, considering they started focusing on that a few years ago? I don't get your comment at all
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" instead of "podman run" for example. Docker needs to be the obvious #1 for starting a container on a single machine.
> their core offering must be the leader if they want to survive. Devs must want to use "docker run" instead of "podman run"
If their core offering is container hosting, they should be able to make a company out of that even without the client. After all jfrog and cloudsmith are more per less just that, as is github.
> 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.
I mean, OCI and containerd exist. You can have "Docker" containers without the Docker just fine. Just need to replace the user tooling, which I assume podman does? (never used it)
> they can't work out how to build a business around what is at it's core a nice UI for Linux containers.
It's quite a shame (for the lack of better wording) that the better, simpler and more intuitive a free product is, the harder it is to make money from it by selling support.
I think that the best way to go from here, would be building companion products and supporting the whole ecosystem. By companion products, I mean other standalone apps/services, not just GUI for existing one.
> Unfortunately Docker the company appears to be dying, this is the latest in a long line of decisions that are clearly being made because they can't work out how to build a business around what is at it's core a nice UI for Linux containers.
It should have been just a small company, doing this, and making some money for their trouble instead of whatever it is they're trying to be.
That might be possible for soemthing that "only" writes and distributes software (that can also work on levels of success much less stellar than sqlite), but when you try to pull off hosting services at internet scale like docker hub did, with some free tiers, it's just not feasible to include it all in the bills of user subset that is actually willing and able to pay. The playbook is always the same: "maybe we could do that high impact free tier if we had more funding?" and that "whatever it is they're trying to be" is an implicit consequence of that, that ambition comes with the funding. "just a small company" mean bootstrapped, and bulk hosting like docker hub would simply not happen.
I'd like to see something resembling the Linux model. In the case of Docker, a foundation built around a suite of open source tools that's contributed to by pledges from all the big companies that use the tool. Maybe that means podman has a reliable source of funds for maintenance and improvement.
What I don't like is having these critical tools directly in the hands of a single for-profit corporation, at least where it can be avoided.
If we want that I feel like there should be a community buy out. Just so that they have something to return to investors. Just so that they have incentive to play nice and not Hudson-up the process. You shouldn't be able to build a critical piece of infrastructure and have nothing to show for it. Community buy-out should be a viable exit plan.
> My hope is that before the inevitable shuttering of Docker Inc another organisations (ideally a coop of some variety, but that's probably wishful thinking)
Indeed. We should all be equal in that venture: Ain't nobody here but us chickens.
Why didn't Docker ever offer managed container hosting? That seems like the obvious logical next step when you create a tool for easy deploys. Instead it's 2023 and we finally get that with Fly.io.
I must be missing something obvious, because otherwise I feel like I'm going insane.
> Tutum is not a real PaaS, it runs containers in the user infrastructure and can be easily adapted to run on-premise
Which doesn't sound like managed container hosting to me. Their site is gone though so I'm not really sure. There was 0 discussion around their shutdown, if they did have a managed solution I'm curious why it failed. Too early?
Can't comment specifically on this or that "dying company", but it is a bit disappointing that after, how many, four decades of open source? and the obvious utility of that paradigm, it still seems a major challenge to build sustainable open source ecosystems. This means we can't really move on and imagine grander things that might build on top of each other.
Its not clear if that is due to:
i) competition from proprietary business models
ii) more specifically the excessive concentration of said proprietary business models ("big tech")
iii) confusion from conflicting objectives and monetisation incentives (the various types of licenses etc)
iv) ill-adapted funding models (venture capital)
v) intrinsic to the concept and there is no solution
vi) just not having matured yet enough
What I am driving at is that building more complex structures requires some solid foundations and those typically require building blocks following some proven blueprint. Somehow much around open source is still precarious and made up. Ideally you'd want to walk into the chamber of commerce (or maybe the chamber of open source entities), pick a name, a legal entity type, a sector and get going. You focus on your solutions, not on how to survive in a world that doesn't quite know what to make of you.
Now, corporate structures and capital markets etc took hundreds of years to settle (and are still flawed in many ways) but we do live in accelerated times so maybe its just a matter of getting our act together?
It's still doing better than it could be. Big tech companies have played way nicer than they had to, focusing more on vague long-term presence than on immediate profits, and imo continue to do so to a lesser extent. There always comes a point when the innovation is done and they lock things down again, but even then they have to fight their own employees.
With lots of open source licenses, there is no copyleft. Without copyleft, for profit companies can simply take the hard work, add a little on top, make it proprietary, and sell it. Customer mentality is to use the most comfortable thing, without paying attention on whom they depend, often choosing the proprietary offer, because of feature X.
There are healthy ecosystems, even some partially replacing docker, some with more daily updates than I can process, but they have copyleft licenses in place and are free software, to ensure contributions flow back. Companies can still make profit, but not from adding a minimalistic thing and making it proprietary. They need to find other ways.
First time I saw Docker, I thought "that's great, but how do they make money?" They're selling a cloud containers service while also giving the software away to their direct competitors for free. Maybe I was too ignorant to understand their business model? But now I'm thinking I was right.
To me is the opposite, Docker promotes bad software development practices that in the end will hurt you. In fact most of the time when you hear that you need Docker to run a software is because that software is so badly written that installing it on a system is too much complex.
Another bad use of Docker that I've seen is because people cannot figure out how to write systemd units, that is damn simple (just spend a day to read the documentation and learn the tools that you need). Of course that makes administering the system so much complex because you cannot use the benefits that systemd will give you (thus you start using iperoverengineered tools like kubernetes to just run a webserver and a database...).
I'm maybe oldschool but i use Dockers as a last resort, and prefer to have all the software installed properly on a server, with the use of Ansible as a configuration management tool. To me a system that uses Docker containers is much more difficult to manage in the long run, while a system that doesn't use it is more simple, thus less things that will break, thus if I need to make a fix in 10 years I ssh in the system, edit the program with vim, rebuild and restart the service, no complex deploy pipeline that break, depend on external sources that may be taken down (as is the case) and similar stuff.
I think you are letting your specific feelings and head-canon about purity be mistaken for solid technical arguments.
If you’re sshing to boxes, editing things by hand and slinging ad-hoc commands around then your frame of reference is so far away from understanding it’s value proposition that it’s probably pointless to discuss it.
> To me is the opposite, Docker promotes bad software development practices that in the end will hurt you. In fact most of the time when you hear that you need Docker to run a software is because that software is so badly written that installing it on a system is too much complex.
I think one reason you may be seeing downvotes here is that you have specific projects in mind, and without you naming them, others who haven't used such projects don't see how real the phenomenon is.
I was recently helping a friend work through some Nix configuration and he told me about a couple of different projects he used where deploying the software any way other than via Docker was treated as either officially or de facto unsupported. In some cases, dependencies are not even exhaustively named in the documentation. When users ask questions in community channels (often on Discord) about what the software's requirements are, they are (at least sometimes) directed to just use the pre-baked Docker images instead of receiving real answers to their questions.
This is second-hand info for me. I don't know how bad it really is, or how common, either. But that kind of thing a absolutely screams to me, too, 'very few of us actually know how this thing works'.
Still, sharing that sentiment without giving a specific account of software that you've seen fall into this trap is likely to be dismissed and downvoted. Maybe it would be helpful to give some concrete examples of what you brought all that to mind for you.
Docker was always ‘oh we have too many moving parts in the deployment pipeline, let’s add Yet Another Thing. That will fix it’
It never fixed anything.
Except you need to pay for pinning IPFS files to actually persist. And there-in lies the crux. People don't got money to pay for their small time docker containers.
The cost of some of the IPFS hosts that will give you a dropbox of sorts still end up costing roughly the $20/month similar to the Docker $25/month for a team account.
It was always unbelievable too me how much they hosted for free. I recklessly pushed over 100gbs of containers the last years, all free. Never made sense to me, even google doesn't do this anymore.
Looking at the rates of enterprise storage costs compared to what Google or Apple charges consumers - I was surprised by how subsidized people's photo libraries are.
Apple does a pretty bad job of it then, because I have a local copy of my entire photo library too on an external hard drive. It’s quite nice really, cloud storage plus a local copy. I guess it’s somewhat of a moat because switching to some other cloud provider or my own system will be more expensive?
No I’m saying that Apple Photos literally copies to a local library automatically if you have a mac and open Photos.app. I didn’t even have to set it up. My partner did the same thing, and she’s decidedly not tech savvy. It’s one of the only reasons I ended up paying for Apple One for the 2TB cloud storage, is because of how easy they made it.
And it's different in more ways than one. Hosting the images is just one fraction of the features that you get with Apple or some other provider. Searching, albums, sharing, are all baked in services that are still cheaper than, say, going through S3 and having a bucket with similar storage.
They are not, but actual usage is typically a single-digit % of promised space. So power users are served at cost (or even at loss), but the overwhelming majority of users are actually overpaying for what they use.
I just compared the price of 2TB on backblaze B2 and Google Drive, they were roughly the same price. Google doesn't charge for bandwidth, but it's also against the ToS to do anything that would result in lots of downloads anyway.
Google also charges a flat rate for 2TB with the next lowest plan being 200GB. So the majority of users are paying for 2TB but not using anything close to that much. I suspect consumer storage is also much easier to offload to hard drives and tape backups while files on S3/B2 would mostly require SSDs with some probably being stored in ram.
We are even using Docker Hub to store and distribute VM images... The so-called "container disk image" format is sticking a qcow2 file in a Docker image and storing it on a Docker registry.
Is there any progress on podman for Windows or any other way of running containers on Windows? I cannot wait for the day the development community doesn't need to rely on anything from this company.
Podman Desktop runs podman machine for me at startup.
Containers set to restart automatically don’t restart across podman machine restarts but that hasn’t upset my workflow much (at all?). I just start containers as I need them.
I wonder if VSCode’s Remote Container stuff works with Podamn on windows. The Docker Desktop + VSCode + Remote Container Dev + the ESP-IDF tooling is the nicest way to do production ESP32 dev with multiple ESP-IDF version (and even without that is just much simpler to get up and running on Windows, despite the rube Goldberg machine-esque description of it)
I've been playing around with it recently on macos and Podman is still a bit hit or miss. It seems mostly to be around assumptions of permissions. I switched over to colima (which is specifically for macos) and have had next to no issues though. Hopefully podman is able to tick off those last few boxes and make it properly stable in this use case.
Is there something in particular missing? I have been using Podman for Windows almost daily for the past six months. There is no management GUI built-in like Docker for Windows, but I have not found that be a problem at all.
It actually sounds reasonable to me? They have an open source program, the article says its open source definition is "too strict" because it says you must have "no pathway to commercialization".
I mean why should you expect someone to host gigabytes of docker images for you, for free?
Well, it's how they established themselves in the market. Without being friendly to open source projects they wouldn't have had that marketing and wouldn't exist as a company.
So now they destroy their foundations and learn whether they 10x or fold. Pretty standard VC playbook so I assume that's the driving force here.
> the article says its open source definition is "too strict" because it says you must have "no pathway to commercialization"
What a load of crap. Free Software's "0th freedom" is the ability to use the program for whatever purpose you wish. The definition of Open Source is even looser than that. They are asking their "Open Source" users to make their software non-free, by restricting its use cases.
Anyway, the writing has been on the wall for a long while. If you haven't moved off Docker Hub yet, now is the time.
I have been building this for 5+ years, and offer a community edition for free while the hosted version is paid. Once the community edition starts costing money there will be even less reason to continue supporting it, it already causes a lot of extra work and problems that I'm otherwise uncompensated for.
Gitlab's Open Source program has similar restrictions, and it's just kind of weird. Like, there are multiple companies actually making money off of Xen; but because Xen is owned by a non-profit foundation (with a six-digit yearly budget), and the foundation isn't trying to profit, it still qualifies. (As does, for instance, the GNOME project.)
OTOH, somewhere else in this context it was mentioned that curl is almost entirely maintained by one guy who makes money from consulting; and because of that, he wouldn't qualify.
So if you're either small enough to be a side hobby project, or large enough to have your own non-profit, you can get it for free; anywhere in between and you have to pay.
Personally I'd be happy for Xen to pay for Gitlab Ultimate, except that the price model doesn't really match an open-source project: we can't tell exactly how many people are going to show up and contribute, so how can we pay per-user?
Yea, people are really spoiled due to more than a decade of VC and general investing cashburn offering tons of services for free. But at the end of the day there are costs and companies will want to recoup their money.
The problem with just replacing GitHub isn't the source code hosting part. There's tons of alternatives both commercial and open source. The problem is the cost of CI infrastructure and CDN/content/release hosting.
Even moderating said CI infrastructure is a nightmare. freedesktop.org which uses a self-hosted gitlab instance recently had to shutdown CI for everything but official projects because the crypto mining bots attacked over the last few days hard and fast.
It actually seems pretty reasonable to let BigTech host stuff, so long as you know the rug pull is going to come. Let the VCs light money on fire hosting the stuff we use for free, then once they stop throwing money at it figure out a plan B. Of course you should have a sketch of your plan B ready from the start so you are prepared.
If you view all of this "free" VC subsidized stuff as temporary/ephemeral you can still have a healthy relationship with it.
This is how I've been living for many years and it has saved me many thousands of dollars, which is a significant amount of money here. The various "cloud" free tiers cost them at least $600 for the past year alone. Same for free CI offerings, etc. Thank you VCs and BigCo for not cutting out regions that are probably net negative for you overall (I guess it may be serious money for me, but doesn't even register on the radar at their scale).
BitTorrent will solve the distribution problem but not magically provide more storage. Someone still has to foot the bill for storing gigabytes (or terabytes) worth of docker images.
Have a free client that seeds any images that you download, and a paid for one that doesn't. Now you have all those who don't want to pay providing your storage and bandwidth.
This is an excellent use of p2p incentives. Share to pay.
Tricky bit is, for some users, you’ll either abandon them with no way to share or you will still be paying their ingress/egress fees when their client falls back to your TURN server if NAT hole punching fails.
You’ll also have to solve image expiration gracefully. Hosting a “publish as much as you want” append-only ledger isn’t going to scale infinitely. There needs to be garbage collection, rate limiting, fair-use policies, moderation, etc. Otherwise you’re still going to outstrip your storage pool.
It should probably work like ipfs, with pinning services. You can pin (provide a server that stores and shares the contents) yourself, or pay for a commercial pinning service (or get one from an OSS-friendly org, etc).
This doesn't make sense as an argument at all. If there isn't anyone using the image, no one will have it on their computer... Sure - but that isn't as much of an issue if you have a build file that constructs the image up from more basic parts. Secondly, the popular files get way way faster with the more their used/downloaded.
Torrent is a phenomenal *wonderful* system to distribute Machine Learning weights, docker images, and databases.
It's a developers dream for a basic utility of distributing data.
Potentially ipfs could be useful too, but idk much about it specifically.
One of the most revolutionary and fundamental tools to be made is a basic way / template / paradigm which constructs databases in a replicable way, such that the hash of the code is mapped to the hash of the data. Then the user could either just download the data or reproduce it locally, depending on their system's capabilities, and automatically become a host for that data in the network.
I think something like IPFS would be perfect for that, you have some layers pulled in your storage anyways.
big projects could self host easily, as their popularity would quickly give them enough seeds to not need to provide much traffic themselves.
also I think adapting docker way of storing layers as tars is fundamentally broken, maybe with combination with something like ostree as a storage to decrease duplicates we could really cut a lot of storage.
imagine how much unique content does your average docker image have? 1 binary and maybe few text files? rest is probably os and deps anyways.
The economics of hosting an image registry are tough. Just mirroring the npm registry can cost $100s per month in storage for tiny little tarballs.
Hosting GB images in an append-only registry, some of which get published weekly or even daily, will burn an incredible amount of money in storage costs. And that’s before talking about ingress and egress.
There will also be a tonne of engineering costs for managing it, especially if you want to explore compression to push down storage costs. A lot of image layers share a lot of files, if you can store the decompressed tarballs in a chunk store with clever chunking you can probably reduce storage costs by an order of magnitude.
But, at the end of the day, expect costs for this to shoot into the 6-7 digit USD range per month in storage and bandwidth as a lower bound for your community hosted image registry.
you just have to host the recipe and the hash/meta-data
c'mon. This is not amateur hour. Hosting the whole thing only made sense for docker because their plan was always to do this microsoft style play.
If you assume you are either open source or fully closed enterprises, the problem is very, very easy to solve. and cheap. Just relinquish full control of being able to close all the doors for a fee, like they are doing now.
Rerunning a glorified series of bash scripts on every install doesn’t work at any sort of scale. This is why we’ve moved away from configuration over ssh to either:
1) deterministic builds with centralized caches
2) snapshots
Docker has some features of (1) but is really (2).
You absolutely do not want to download the recipe to build a Docker image instead of the image itself.
Further, the base images have no recipe. They are a tarball of a slimmed down pristine base os install.
The funny thing is that I don't think anyone has ever had to pay a Linux distribution for hosting packages of their open source software... :thinking face:
I don't think we will receive enough donations to cover infrastructure costs, let alone maintainers' salaries.
Even core-js sole maintainer failed to raise enough donations to feed his own family, despite the library is used by at least half of the top 1000 Alexa websites. [0]
People (and also big-techs) just won't pay for anything they can get for free.
Codeburg is more strict for blocking projects at the moment. Wikiless is blocked by Codeburg for using the Wikipedia puzzle logo but is still up and unchanged on GitHub.
Side note: what did happen to Travis? I was just googling them yesterday because they were everywhere. They even came with the GitHub education package.
Seems based on some of my research that they've completely exited the free side of the business. All of their plans are now paid and the cheapest plan is $64/year
It wasn't a good business to be in anyway. I don't think any of these freebie devops businesses are all that smart. They're not a "business", they're a feature of someone else's business. And as soon as they catch up then you're done.
Also they’re surprisingly expensive: things like spam and cryptocurrency mean that you need a fairly large abuse prevention team which is expensive but has no customer-visible benefits. GitHub has that too but as you said they at least have the rest of the business with which to recoup that cost.
I suspect GitHub actions put a massive dent in their product usage. I seem to remember they started to cut costs and restrict free usage some years back too, and that was the beginning of the end.
My first thought on this was good riddance. The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well.
However it looks like the main effect is going to be moving more of open source onto GitHub, aka under Microsoft's control, and the level of faith people have in Microsoft not destroying their competitor for profit is surreal.
>> Docker, the company, is failing. Docker, the container technology, is alive and very well.
Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more. I don't think it matters much that k8s uses CRI-O but docker needs to be #1 for running a container on a single machine. Yet, they seem to be letting that slip away because it is not directly monetizable. Software businesses need to be creative - invest a lot into free things, which support monetization of others. If you want low risk returns, buy T-bills.
> Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more.
I've used "Docker" as in "containerization", since they are often used synonymously and the grandparents intent was definitely to criticize the latter. Docker itself will quite likely stay around as a name, but I have no faith in the company.
The company has never been good though. The technology was great, but they never found a way to monetise it properly, and their whole approach to outreach, community, and developer experience was terrible. Their support, non-existent.
In fact, I'd go as far as to say that, given the ubiquity of their product, I can't think of a worse way a company could have performed. It's been about 10 years now since it really took off, and in that time, the technology has been great, but dealing with the company, always been difficult.
Nah, you just didn't look carefully enough. Docker the technology has been recurring amateur hour of screwups. For example, they hashed the downloaded data but forgot to compare the hash to expected value.
The only thing "great" about Docker was the rough idea of easy-to-transport filesystem images that could run just about anywhere, and the fact that they managed to make that kind of thinking mainstream.
Docker either came up or popularized the idea that completely dominates how almost all services work today. That is something imo. It is obvious in hindsight maybe but not in 2012.
I disagree with you. I've used it in production for almost a decade now. There have been issues sure, but name me a single production-level technology that hasn't had problems?
- Microsoft Windows: Various versions of Windows have had critical security vulnerabilities over the years, leading to widespread malware outbreaks like WannaCry and NotPetya.
- OpenSSL: In 2014, the Heartbleed bug was discovered in OpenSSL, which left millions of websites vulnerable to attacks that could steal sensitive data.
- Apache Struts: In 2017, the Equifax data breach was caused by a vulnerability in Apache Struts, a popular open-source framework for building web applications.
- Boeing 737 Max: In 2018 and 2019, two deadly crashes were caused by a software flaw in the flight control system of the Boeing 737 Max airplane.
- Google Cloud: In 2020, a widespread outage of Google Cloud services caused disruptions for many businesses and organisations that rely on the platform for their operations.
Many things have had individual bad incidents. Docker has had many, and they've been of incredibly naive kind. To compare Docker to the kind of careful engineering done in e.g. airplanes is just silly. The commits to Docker ("Moby") have historically been underwhelming. Docker is to containers as what MongoDB was to NoSQL.
It seems the company is slowly trying to make users pay for it. Not too long ago it was free for companies, then they made companies pay to use it. Now they're making people pay to store images.
In the next few years I would be surprised if they didn't introduce a new way to monetize it, leading up to removing the use of any docker executable at all without payment.
Many will come to comment "that's absurd, and you could just use an old executable you already downloaded prior to them halting it's circulation", etc. But I do think the writing is on the wall here with Docker continually getting greedy.
If they don't monetize the use of Docker containers in general by making users pay to run them, they have other options like spyware and ads - e.g. install telemetry in the base of the system somehow to sell the personal data they receive from all images*, etc.
* I know this may not work directly as I've stated it, just giving the flavor of idea
> It seems the company is slowly trying to make users pay for it
I appreciate that pun ;)
> Many will come to comment "that's absurd, and you could just use an old executable you already downloaded prior to them halting it's circulation", etc.
I don't see this as absurd at all. The problem Docker has is that it failed to use it's market share. Making these moves now that easy alternatives exists (Podman, open registries, k8s etc) just doesn't have the pull and alienates their remaining customers.
I don't have any issue with Docker charging for things. If they can get away with charging $0.50 every time someone types docker ps, great. Unfortunately that isn't the reality as competition exists. Eventually bad monetization strategies will lead to business decline.
What state are you thinking of? The containers are ephemeral and the dependencies are well specified in it. You can complain about shipping Ubuntu, but the rest of this doesn’t make sense.
Makes perfect sense to me, sadly. The dependencies are specified in excessively, that's why everyone is shipping Ubuntu. This is caused by and further facilitates the development style of "do not track what we use, just ship everything". Also, the dependencies are specified in container images, which themselves are derivative artifacts and not the original source code, and these dependencies often change in different container builds with no explicit relevant change.
There are three practical problems as a result:
- huge image sizes with unused dependencies delivered as part of the artifact;
- limited ability to share dependencies due to inheritance-based model of layers, instead of composition-based model of package managers;
- non-reproducibility of docker images (not containers) due loosely specified build instructions.
Predicting future comments, nix mostly fixes these issues, but it has a bunch of issues of its own. Most importantly, nix is incredibly invasive in development process, adopting it requires heavy time investments. Containers also provide better isolation
It doesn't have to be a choice of containers or nix though. You can put your nix built applications into a container just fine. You can also pull an image from somewhere else and shove nix stuff into it as well.
There is definitely a bit of a learning curve but the time investment is frequently over exaggerated. I see it as similar to the borrow checker in rust. Yes, you have to spend some time and also learn about the rules. But it helps you build software that is more robust and correct. Plus once you're into it you save significant time not having to deal with dependencies especially when bringing on new people
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.
This isn't what I was talking about, I'm all for being as pure as possible, dial the reproducibility and isolation to the max. Unfortunately, Nix itself as an application is not isolated. It requires a unique installation process to be available for users, because it wants to manage its store at the root level (/nix/store/), but I hear the situation is different on macOS. Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one.
> Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one.
If you fully package it. If you use something like an buildFHSUserEnv[0] that's not true.
There is also nix-autobahn and nix-alien for automatically running foreign binaries on a more ad-hoc basis or to generate a starting point for packaging.
>The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well.
This was my first thought when I learned of Docker.
I have a hard time calling myself an 'Engineer' when there are so many unknowns, that I'm merely playing around until something works. I insist on being called a Programmer. It pays better than 'real' engineering. Why not embrace it? (Credit toward safety critical C and assembly though, that's engineering)
Developer/Programmer/Engineer titles are mostly meaningless because they mean different things at different companies. You can go wayback and call yourself a coder.
As someone that does what you consider "engineering", my current project is containerized because I've lost too much of my life to debugging broken dev environments. The person who ships safety critical releases at most companies isn't a developer that's deeply familiar with the code, it's usually a distracted test engineer with other things to do that may not be very tech-saavy. Anything I can do to help them get a reproducible environment is great.
I remember back around 2009, our org had this horrible open source program, which shall not be named, foisted upon us by an excitable bloke who had heard wondrous things from the university where it had been developed. Well, we had a bitch of a time getting it running. Instructions and build scripts were minimal. We thrashed around.
I noted to someone that this felt less like a product and more like a website and set of scripts ripped from a working system. A few of us were shipped up to the originating university for a week to hob-knob with the people in charge of it. Toward the end, during the ritual inebriation phase, I managed to find out that they had never actually attempted to install it on a clean system. This had truly been ripped from a working system. And I thought to myself, "How horrible."
Now, I am admittedly pants at Linux. No good at all. But there is something about Docker and similar technologies that says, "Yes, we threw our hands in the air and stopped trying to make a decent installation system."
> "Yes, we threw our hands in the air and stopped trying to make a decent installation system."
I mean what do you expect, it goes along so nicely with "Yes, we threw our hands in the air and stopped trying to architect coherent software systems."
I doubt the real™ engineers at NASA and SpaceX know everything their proprietary closed-source Matlab-to-FPGA tooling is actually doing under the hood.
can't say for spaceX, but most NASA glue is built in house. close to zero proprietary ones.
maybe the vlsi is closed. but that is "industry standard" i guess. rest is a bunch of mathy-language du jour held together with python or something.
...opaque docker containers going to prod doesn't have a excuse other than inefficient orgs fulled by VC or Ad money. Or maybe they do, but you won't excuse them using NASA as an example :)
The only real moat they seem to have here is that "FROM" in a Dockerfile, "image:" in a docker-compose.yml file, and the docker command line default "somestring" as an image to "hub.docker.com:somestring".
They pushed that with the aggressive rate limiting first though, which caused a lot of people to now understand that paragraph above and use proxies, specify a different "hub", etc.
So this move, to me, has less leverage than they might have intended, since the previous move already educated people on how to work around docker hub.
At some point, they force everyone's hand and lose their moat.
Right, it's a little different than my summary, but the main point was that they educated everyone that there's a way around that with specific image names, or a proxy, etc. If they push hard enough, the internet will route around them, distros will ship a patched docker, preset environment variables, or a docker->podman alias, etc. They will lose control over the "root namespace".
Docker have a responsibility to _their_ customers, not just OpenFaas and other open source projects. _Docker's_ customers rely on them to provide a safe and reliable service. If Docker allows these projects to be taken over by nefarious actors, then the risk falls to _their_ customers, not the Open Source projects that they've broken with.
It is kinda strange that developers who should be aware of their own costs think that these sort of services will be free forever or even available and never end. Specially when clearly there is not much monetization going on. Unlike when services are offered with adds.
Big players can carry the costs, but what can small ones really do once money runs out?
Image hosting at scale is an expensive business and Docker are not the only ones trying to manage the costs.
Kubernetes is currently in the process of changing the main repository for their images because, as I understand it, they're burning through their free GCP credits an an unsustainable rate.
Ideally Docker Hub would be an industry funded effort, but that would require co-operation and funding from the major tech. players, and I have a feeling that in an era of cost cutting, that might be harder to achieve than it was in the past.
Squatting and the effects of malware and poison images is my primary concern here.
One of the things the docker api has going for it is that it is hash based. Aside from the first time, it doesn’t seem far fetched for a docker api client to refuse or warn based on comparing the new download’s hash to the previous hash.
Not a lot of people pull by hash; they pull by tag. Tags are not immutable, so the image I get from "python:3.11" today will almost certainly change due to security updates and I will be none the wiser.
I can see that. A human specifiable name is important.
My proposal is that each time an image is pulled, the hash is recorded and retained even if the underlying container image is removed. When the same image is pulled again, if the files change from the previous hash, either fail or warn the user.
I can see how pinning to a specific patch version is not a great idea and that "python:3.11" keeps people from pinning to an insecure version.
As long as we don’t share ownership in these platforms, nothing will ever truly belong to us. For Docker, the software, a Libre alternative is Podman. Instead of GitHub, use Codeberg, an open organization and service.
Now we need a Docker registry cooperative owned by everyone.
Is there any drop in replacement for dockerhub? I’m concerned about all my random oss containers (like ruby-latest) that may come from orgs that aren’t able or willing to pay.
You can run the docker registry inside dokku. It's fantastic. I have an endpoint that is private for pushing with credentials, and a public endpoint that is open. This requires a little mucking around with the nginx configuration of the app, but totally doable.
Aws seems to have mirrored some of docker hub for us (docker/library images seem to be hosted clones) and has their own public repos as well (not just docker hub’s images):
Without entering into the specifics of this situation, I don’t understand the hate for Docker the company. They are providing a huge service for the community and looking for ways to make money from it to make it sustainable. I would give them a bit more empathy/benefit of the doubt as they iterate on their approach. Somewhere, somehow, someone has to pay for that storage and bandwidth whether directly or indirectly (I am old enough to remember what happened with sourceforge so I rather them find a model that works for everyone)
If you inconvenience all users (by devastating the "ecosystem" of publicly available images) in order to extort money from a few users (some organizations will pay up, at least temporarily) you should expect hate.
The only benefit of doubt Docker deserves is on a psychological plane: evil or stupid?
It’s a long standing hate for me that isn’t limited to just Docker, companies that used “we’re free” to obtain massive growth only to turn around and switch monetization models completely once they’ve become the dominant player in the market. It’s a massive distortion on the market, driving companies that tried to be fiscally sound from the start into irrelevancy while extremely inefficient ventures become the market leaders on account of superior funding.
Or to put it another way, Docker should have been focused on sustainability from the start and not dangled a price they knew couldn’t last in front of people to increase adoption.
I agree they deserve to get paid, but there are better ways than essentially holding customers’ data and URLs hostage. The problem is they are trying to extract money from other open-source developers who are at least as cash-strapped as them.
Plus, I doubt they will get many people to actually start paying. People will simply move to other storage (like Github) and switch the URLs. Docker is fully open-source and works without docker.io, they don’t really have a position here except owning the name.
IMO they just need to edit / clarify that open-source developers and organizations won’t need to pay, only those who presumably should have the funds. And take a more passive stance: bug people with annoying messages like Wikipedia does, and threaten shutting down docker.io altogether if they don’t somehow get funding (some people will complain about this too but more will understand and will be sympathetic). Wikimedia, Unix/Linux, Mozilla, etc. as well as Homebrew/cURL/Rust all seem to be doing fine as nonprofits without creating huge controversies like this.
Initially it's great if you can get all the FOSS to play in your technology walled garden. Subsidize it with VC cash.
Downside is it generates a ton of traffic that is hard to monetize. Sooner or later it reaches a point where it can't be subsidized and then you get pay up or get out decisions like this.
One question I haven't seen yet is 420 USD? Is that what it costs to serve the average FOSS project? Or is that number a bad Elon style joke? If they came out with "We've calculated X as actual costs. We're making no margin on this but can't free lunch this anymore" that would go down a lot better I think.
After Docker announced rate limiting for the hub this was an anticipated move. Was just the matter of time.
The only recommendation to everyone: move away or duplicate.
One of the strategies I am yet to test is the synchronization between gitlab and github for protected branches and tags and relying on their container registries. Thus (at least) you provide multiple ways to serve public images for free and with relatively low hassle.
And then for open source projects’ maintainers: provide a one command way to reproducibly build images from scratch to serve them from wherever users want. In production I don’t want to depend on public registries at all and if anything I must be able to build images on my own and expect them to be the same as their publicly built counterparts. Mirroring images is the primary way, reproducing is the fallback option and also helps to verify the integrity.
> Mirroring images is the primary way, reproducing is the fallback option and also helps to verify the integrity.
I suspect the latter will become more common over time. I can count on no fingers the number of open source projects which I’ve encountered which have production-grade container images. Once you need to think about security you need to build your own containers anyway and once you’ve done that you’ve also removed the concern of a public registry having issues at an inopportune moment.
Some self promotion but I have built a project that aims to solve some of these issues in Kubernetes.
https://github.com/xenitAB/spegel
I have avoided a couple of incidents caused by images being removed or momentarily not reachable with it. It would at least mitigate any immediate issues caused by images being removed from Docker Hub.
756 comments
[ 3419 ms ] story [ 4746 ms ] threadSetup 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.
The issue I worry about is the millions of blog posts, CI builds, docker-compose files, tutorials & individual user scripts who all reference community images on Docker Hub, a huge percentage of which are about to disappear, apparently all at once 29 days from now.
From a business perspective particularly, this looks like suicide to me - if you teach everybody "oh this guide uses Docker commands, it must be outdated & broken like all the others" then you're paving a path for everybody to dump the technology entirely. It's the exact opposite of a sensible devrel strategy. And a huge number of their paying customers will be affected too! Most companies invested enough in Docker tech to be paying Docker Inc right now surely use >0 community images in their infrastructure, and they're going to see this breakage. Docker Inc even directly charge for pulling lots of images from Docker Hub right now, and this seems likely to actively stop people doing that (moving them all to GHCR etc) and thereby _reduce_ the offering they're charging for! It's bizarre.
Seems like a bad result for the industry in general, but an even worse result for Docker Inc.
They're taking a big chunk of open source and tossing it in the garbage.
https://aws.amazon.com/ecr/pricing/
It’s completely free for public repositories.
https://xkcd.com/356/
I guess I'll be moving our (FOSS) container images to GitHub Registry... but what a pain :/
I don't think they're likely to be a cost-effective differentiator against what Docker are now charging.
AWS also charges you to host things in S3. Is it hastening its demise too?
This argument is just weird to me.
> GitHub's Container Registry offers free storage for public images.
But for how long?
the subtitle of the web era
applies very much to Github, and for all of their services, not just containers. The elephant in the room, hardly needs to be mentioned I would think (Microsoft). We are only a few years into that regime.
Free to existing Windows users, perhaps, but free to the world doesn’t seem like something Microsoft was historically in a position to offer, much less later kill.
And their entire marketing strategy is built around free hosting for public data, so it'd take a major shift for this to disappear. Not to say it's impossible, but it seems like the best bet of the options available.
Is it practical to set up a redirect in front of a Docker registry? To make your images available at example.com/docker-images/abc, but just serve an HTTP redirect that sends clients to ghcr.io/example-corp/abc? That way you could pick a new host now, and avoid images breaking in future if they disappear or if you decide to change.
[1] https://stackoverflow.com/a/67351972
Shouldn't be any security risk there AFAICT. Just hard to tell if it's functionally supported by typical registry clients or if there are other issues that'd appear.
If they choose. It's in fashion right now to fire people and squeeze free tiers.
I don't know if container signature tools support multiple registry locations though.
Can we stop this madness already?
Unfortunately Docker the company appears to be dying, this is the latest in a long line of decisions that are clearly being made because they can't work out how to build a business around what is at it's core a nice UI for Linux containers. My hope is that before the inevitable shuttering of Docker Inc another organisations (ideally a coop of some variety, but that's probably wishful thinking) pops up to take over the bits that matter, and then hopefully we can all stop trying to keep up with the latest way in which our workflows have been broken to try and make a few dollars.
> System D is a manner of responding to challenges that require one to have the ability to think quickly, to adapt, and to improvise when getting a job done.
> The term is a direct translation of French Système D. The letter D refers to any one of the French nouns débrouille, débrouillardise or démerde (French slang). The verbs se débrouiller and se démerder mean to make do, to manage, especially in an adverse situation. Basically, it refers to one's ability and need to be resourceful.
Source: https://en.wikipedia.org/wiki/System_D
> But then again, if [calling it systemd] appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?).
(There have been a few false starts so I'm specifically referring to the vanilla unmodified docker-compose that makes Docker API calls to a UNIX socket which Podman can listen to).
https://www.redhat.com/sysadmin/podman-compose-docker-compos...
Also systemd integration isn't a plus for me, I don't want to deal with SystemD just to have a container start on startup.
Regardless that has never bothered me since I'm only using podman or docker for local development...
https://github.com/containers/podman/pull/16141
Also I really don't care if docker has a daemon or not, for me it offers feature like auto starting containers without bothering with SystemD, and auto updates using watchtower and the docker socket.
And since podman doesn't have an official distro package repo like docker, you are stuck use whatever old version shipped in your distro without recent improvements, which is important for a very active development project.
Bingo, the "pain" of the daemon (it's never cause a single problem for me? Especially on Linux, on macOS I've occasionally had to go start it because it wasn't running, but BFD) saves me from having to touch systemd. Or, indeed, from caring WTF distro I'm running and which init system it uses at all.
Hmm... https://github.com/containers/podman
I found that on: https://podman.io/ so, I'm pretty sure it's official.
Image hosting is expensive at scale, and someone's got to pay for the compute/storage/network...
As far as DockerHub goes, the OSS hosting costs do need to be solved, but surely they can be.
Ideally it'd be great to see the industry fund it, but with budget cuts in tech. I'm not sure that'll happen...
Bit Torrent would beg to differ.
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-reliable bandwidth.
Nobody's CI should be depending on an external download of that size.
the .torrent file format, and clients, include explicit support for HTTP mirrors serving the same files that's distributed via P2P.
Downloading tens or hundreds of megabytes of exactly the same image, on every CI run, on someone else's expense, is expectedly unsustainable.
eg something like AWS with massive data transfer costs, vs something else like carefully placed dedicated/colocation servers at places which don't charge for bandwidth
While you're probably right, I've seen dumber things happen so I wouldn't completely rule out the possibility. :wink:
If I can't use it as a daemon-focused package manager that works more-or-less the same everywhere with minimal friction without having to learn or recall the particulars of whatever distro (hell, on my home server it even saves me from having to fuck with systemd) and with isolation so I can run a bunch of versions of anything, I'll probably just stop using it.
Everything else about it is secondary to its role as the de facto universal package manager for open source server software, from my perspective.
... of course, this is exactly the kind of thing they don't want, because it costs money without making any—but I do wonder if this'll bite them in the ass, long-term, from loss of mindshare. Maybe building in some kind of transparent bandwidth-sharing scheme (bittorrent/DHT or whatever) would have been a better move. I'd enable it on my server at home, at least, provided I could easily set some limits to keep it from going too nuts.
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's as if they had no idea how things work at large enterprises that are older than most Docker employees.
I find myself shaking my head at a lot of their technical decisions too.
Podman seems to me to be a case study for how to do this right.
Once I simlinked the socket, everything worked.
Connect to Docker Daemon with -> TCP Socket -> Engine API URL -> unix:///run/user/$UID/podman/podman.sock
This is an unfortunate part IMHO. podman is not a docker drop-in replacement, but it is advertised as such.
Podman wasn't built out of necessity but out of fiscal competitive maneuvering. And it's working. I see so many articles on the "risks" of Docker vs Podman. The root wars are all over the place. Yet... The topic is blown way out of proportion by RHEL for a reason: FUD all in the name of sales. Is there merit to the claim? For sure. Docker's architecture was originally built up as client/server for a different purpose. That didn't play out and the architecture ended up being a side effect of that. But we don't see container escape nearly as much as Red Hat would like us to believe. I keep paying Docker because I don't want to live in Red Hat's world, with their tooling that they can just lock out of other platforms once they feel like it. No thanks.
Explain please. This sounds like you're accusing RH of sabotaging Docker, or planning to. That's a very serious accusation requiring proof.
Turns out hanging out in someone else’s cathedral can have some pretty big benefits.
See * https://bugzilla.redhat.com/show_bug.cgi?id=1962257 * https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/...
Sometimes they even backport systemd features from more recent versions, disable them but leave man pages in the original state. Even the /usr split isn't progressing at all.
Meanwhile Fedora has implemented all these changes, which according to https://www.redhat.com/en/topics/linux/what-is-centos-stream, should be the upstream for CentOS.
I would say RedHat dropped the ball on systemd and has no intention of supporting any of the new features in any of their systems.
Plenty of references to this: https://crunchtools.com/docker-support/
Even though, at the time, CRI-O was a much worse option. Yes, Red Hat plays competitive lockout games all day long. This is just a singular example.
And wasn't the runtime problems because Docker was very very late to adopting CGroups v2?
As for Red Hat and their games of not supporting Docker, even after cgroups were addressed Red Hat never officially supported Docker as a runtime. How do I know this? Because at the time I was working with paying clients of RHEL/OpenShift and was on calls regarding said customers being forced to use inferior (their words) RHEL tooling. So while your history may have not seen the games Red Hat was playing, they surely were.
I'm not making a moral judgement. I'm just saying that docker had serious technical problems and docker the business sucked at monetizing it.
Docker played into red hat's tactics. I've never heard of Matt Walsh and frankly, I've wanted rootless containers for years before I ever heard of podman.
>Podman wasn't built out of necessity but out of fiscal competitive maneuvering.
Becuase red hat is a business not a charity.
I doubt they would have built a better docker if docker wasn't refusing to improve.
We must be talking about a different Red Hat here. Podman, with breaking changes in every version, that is supposedly feature and CLI complete with Docker, but isn't actually, is winning because it's more open source friendly or better technically? Or systemd, written in a memory unsafe language (yes, that is a problem for something so critical and was already exploited at least a couple of times), using a weird special format for it's configuration, where the lead dev insults people and refuses to backport patches (no, updating systemd isn't a good idea) won "because it was more open source friendly"? Or OpenShift that tries to supplant Kubernetes stuff with Red Hat specific stuff that doesn't work in some cases (e.g. TCP IngressRoutes lack many features), is winning "because it was more open source friendly"?
No, Red Hat are just good at marketing, are an established name, and know how to push their products/projects well, even if they're not good or even ready (Podman is barely ready but has been pushed for years by this point).
What memory safe language 1) existed in 2010 and 2) is thoroughly portable to every architecture people commonly run Linux on and 3) is suitable for software as low-level as the init?
Rust is an option now but it wasn't back then. And Rust is being evaluated now, even though it's not quite ready yet on #2.
Not no ecosystem, but yes it's way smaller... probably even smaller than Rust, yes.
> and it brings us back to point #2.
I seriously doubt it. Ada is supported directly in gcc; why would it have any worse platform coverage than anything else?
And honestly the language choice was only the tip of the iceberg, it took years of people adapting before systemd became usable. And it still doesn't handle circular dependencies better than arbitrarily which is ridiculous, literally one of it's main jobs is to handle dependencies.
I mean, I wish guys like FSF would have produced a viable Docker alternative, but this hasn't happened, at least yet.
I have nothing but mad respect for Daniel Stenberg. 25 years of development of great software, for which he had been threatened[1] and had ridiculous US travel visa obtaining issues[2].
[1] https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/
[1] https://news.ycombinator.com/item?id=26192025
[2] https://daniel.haxx.se/blog/2020/11/09/a-us-visa-in-937-days...
[1] https://daniel.haxx.se/blog/2018/07/28/administrative-purgat...
There was a period where the US was treating public key encryption like arms exports, and involved in spreading the technology outside the US as tools were in us.govs sht list
After a report from RSA Security, who were in a licensing dispute with regard to the use of the RSA algorithm in PGP, the United States Customs Service started a criminal investigation of Zimmermann, for allegedly violating the Arms Export Control Act.[5] The United States Government had long regarded cryptographic software as a munition, and thus subject to arms trafficking export controls. At that time, PGP was considered to be impermissible ("high-strength") for export from the United States. The maximum strength allowed for legal export has since been raised and now allows PGP to be exported. The investigation lasted three years, but was finally dropped without filing charges after MIT Press published the source code of PGP
They tried to ruin the man.
Ridiculous? This is pretty common issue for anyone who travels to US. Visa may be denied for whatever reason and tough luck on appeal. I am EU citizen and had similar experience just for visiting Iran on tourist trip. Do not even ask about guys from India, Pakistan or less fortunate countries.
And it got even worse with pandemic. US required vaccination for very long time, long long after it was relevant. Maybe they still do, frankly I do not care to look at this point!
I think biggest WTF here is why international organization like Mozilla is organizing company wide meetup in US, and not in country with liberal visa entry policy such as Mexico!
This was not a case for Swedish citizens, which is mentioned at the beginning of Daniel's linked post. Sweden is a member of ESTA[1] and Daniel traveled to the US multiple times before being denied travel (with still valid ESTA) and only then applied for a visa.
[1] https://esta.cbp.dhs.gov/
Probably you answered an officer (or airline worker) that you were gonna "work" there, not just visit your employer for an event?
Differences, in Poland at least, are that small business owner in this scenario is not protected by employment laws (3-months notice layoff, max 3 months salary-equal damages liability etc) and uses company's (EU)VAT registration number instead of personal social security number equivalent (PESEL number). It eases abroad contract agreements, invoicing and allows serving more clients easily. Company existence can also be validated on EU VIES[1] website quickly.
In the visa case, I have of course used the "paper" phrasing as in reality I was, and am, only employed by my own small business.
[1] https://ec.europa.eu/taxation_customs/vies/#/vat-validation
I'm American, but I have enough friends and family from other countries (my wife is an Iranian passport holder) to know what you're talking about and how difficult it can be.
I was born in a third-world country, and ended up getting tourist visas to the EU, US, and Canada. US was by far the easiest - for me anyway.
If you want a large global meeting in a safe country (I would never in my life go to Mexico) there will be visa issues.
Wow that's clearly someone with serious mental issues :( I hope he could find some help for his condition.
Possibly there was no defense contract at all.
"29% believe aliens exist and 21% believe a UFO crashed at Roswell in 1947. [...] 5% of respondents believe that Paul McCartney died and was secretly replaced in the Beatles in 1966, and just 4% believe shape-shifting reptilian people control our world by taking on human form and gaining power. 7% of voters think the moon landing was fake." -- https://www.publicpolicypolling.com/wp-content/uploads/2017/...
"Belief in both ghosts and U.F.O's has increased slightly since October 2007, by two and five percentage points, respectively. Men are more likely than women to believe in U.F.Os (43% men, 35% women), while women are more likely to believe in ghosts (41% women, 32% men) and spells or witchcraft (26% women, 15% men)." -- https://www.ipsos.com/en-us/news-polls/belief-in-ghosts-2021
"A new Associated Press-GfK poll shows that 77 percent of adults believe [angels] are real. [...] belief in angels is fairly widespread even among the less religious. A majority of non-Christians think angels exist, as do more than 4 in 10 of those who never attend religious services." -- https://www.cbsnews.com/news/poll-nearly-8-in-10-americans-b...
The 77% belief in angels is bizarre though. Like I believe in the possibility of aliens, the universe is quite large. Although I think all spacecraft sightings are almost certainly just mundane stuff from spy planes to weather balloons, etc. I even believe in the possibility of ghosts being real, more likely some strange phenomenon we can't explain that we might misidentify as ghosts. But angels?
One man's angel is another man's ghost or alien though I guess.
The difference here is that to the religious mind, angels are credible in a way that UFOs, ghosts, and magic are not. (The irreligious mind probably finds them all equally credible, hence the disconnect.)
Put another way, it would not surprise me that someone who was "religious but not affiliated" might have a high regard for the Bible. Angels figure prominently in the Bible, and hence fall in that bucket.
[1] https://en.wikipedia.org/wiki/Irreligion_in_the_United_State...
https://slatestarcodex.com/2013/04/12/noisy-poll-results-and...
The universe is large. In the tiny slice we can observe well enough to draw conclusions, Wikipedia currently lists 62 "potentially habitable exoplanets". I'd be much more surprised by intelligent life being unique to Earth than by there being many planets harboring intelligent life, or to answer the question as asked: I believe aliens exist.
https://en.wikipedia.org/wiki/List_of_potentially_habitable_...
It must be a common occurrence among famous software people, I wonder how they deal with that. Do they actively hide their real identity, for example by using a proxy for licensing, do they just ignore such madness, is it a burden or on the opposite, they enjoy their fame?
>I have talked to now: FBI FBI Regional, VA, VA OIG, FCC, SEC, NSA, DOH, GSA, DOI, CIA, CFPB, HUD, MS, Convercent
Bonus Tell: They also love to say they are a doctor or PHD of something or often say PHD in multiple subjects.
That's some Google-level naming strategy there.
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 thousand/year. Or you might just use Podman for free, and prefer it due some of the design differences.
At the very least, a lot of these firms, with VC pressure, overstayed their welcome as private enterprises and should have sold themselves to a larger firm.
Centralizing and sharing your API descriptions, test suites and plans, the various ad-hoc queries people usually keep in their notes or on Slack (and lose), handling involved auth stuff which is a hassle with curl, etc.
I think they gravitate towards the same area as swagger.io or stoplight.io, but from the direction of using the existing APIs.
API registry is a useful tool with modern love for nanoservices when a team of five somehow manages ten of those but I don't see anything similar done by Postman. Two of the service registries I know of were implemented in-house for obvious reasons.
Pretty much the entire "gig economy" is full of hot air and survives on regular influxes of VC money despite massive losses every year. The business model doesn't frickin work.
The hope from investors was that they would be investing into what would ultimately become a monopoly that could extract rents to repay them (not very competitive market of them, but that's tipping the hat a little isn't it...) but the funny bit is there's like 5-7 competitors in the US alone doing the same thing.
Here's a take: maybe this is just a natural monopoly situation, and if we like the convenience of gig delivery but don't like the high prices per order or that gig workers don't get sufficient pay, health insurance or other benefits, how about we just nationalize it?
You know, the same way we did for everything that wasn't food or groceries before? USPS Courier service sounds like an idea to me.
Instead of adding value to Docker they're just trying to find the right knobs to twist to force people into paying. And I think people should pay for value when they're using Docker substantially for business. But it seems like a very short-minded play for cash disregarding their long-term relationship with users and customers.
All that said: They have to find revenue to continue development of all the things people do like. I'd encourage people to ask if the things they've gotten for free do in fact have value, and if that's the case, maybe disregard the ham-fistedness and pony up if possible.
Last time I check rent is not free, food is not free, bus ticket is not free. No reason why software should be free.
Open source was invented by big co as a "marginalized your complement" strategy, not the ideal that is marketed as. As an evidence, I do not see any cloud vendor open source their code?
> In 1983, Richard Stallman launched the GNU Project to write a complete operating system free from constraints on use of its source code. Particular incidents that motivated this include a case where an annoying printer couldn't be fixed because the source code was withheld from users.
from https://en.m.wikipedia.org/wiki/History_of_free_and_open-sou...
> Last time I check rent is not free, food is not free, bus ticket is not free. No reason why software should be free.
You are welcome to sell your software. You are welcome to be replaced if you can't compete. You don't have to sell your software and we don't have to buy it. You can and will be competed with.
Trying to build a multimillion dollar venture off a UI - even a good UI - is probably unwise. It does not seem to be going well for Docker who has gone from no competitors to multiple and all of those competitors are open source.
From your link: The first example of free and open-source software is believed to be the A-2 system, developed at the UNIVAC division of Remington Rand in 1953
FOSS before 1974 looks.. funny. It existed! But it did not look like the modern FOSS movement.
Even post 1974 and pre-GNU, FOSS-ish text editors and such existed. This was still the era when licenses were often non-standard and frequently did not exist. Handing your friend a copy of a program was the norm, regardless the actual legal situation (which itself was probably vague and unspecified).
But you don't have to host curl? Who's gonna put the money to host all the images and bandwidths that ten of thousands of companies use but never pay?
for users to download resources from ifps you either need to install the client (which quite resource intensive) or use the gateways (which is just a server and cost money to run).
also the speed and reliability are nowhere good enough for serious works.
Alternatives:
- Virtual registry that builds and caches image chains on-demand, locally
- Maybe a free protocol like Bit Torrent to store and transfer the images
Bandwidth and storage is not ultimately not free, it has to be paid for.
The open source community that carrier Docker on its back and is now bending over. Let this be a lesson to you. If you're building open source, maybe stick to open source solutions in your tech stack and if it's not there build it. This is what Apache does for the Java ecosystem.
I don't have sympathy, the writing was on the wall and this isn't the first time it's happened to the community.
You mean this Apache: https://github.com/apache ?
Compare it to other corporate-managed tools like Terraform and Ansible. Both of them have horrible UX and really bad design decisions. Both make me hate doing my job, yet you can't not use them because they're so popular your company will standardize on them anyway. Docker, on the other hand, is a relative joy to use. It remains simple, intuitive, effective, and full of features, yet never seems to suffer from bloat. It just works well, on all platforms. There were a few years of pain on different platforms, but now it's rock solid.
And to be fair to them, their Moby project is pretty solidly open-source, and if Docker Inc dies, the project will continue.
And Nix is worlds better than even this. Imagine!
https://nixcloud.io/tour/
if at some point you realize "oh... this is just JSON with a different syntax, some shorthands, and anonymous or library functions," you're on the right path
We're open source and rapidly adding features, you can check us out on Github at https://github.com/jetpack-io/devbox
https://nixos.org/download.html for any linux, AFAIK
nix-shell is amazing for installing binaries, but actually wiring up and running the services doesn't seem like a solved problem.
Unless Nix expects a separate tool to do this once binaries are installed, of course.
Docker files seem necessary only because... well put it this way, think of a Docker image as "the cached result of a build that just so happened to succeed even though it was entirely likely not to, because Docker builds are NOT deterministic."
Now enter Nix, where builds are more or less guaranteed to work deterministically. You don't need to cache them into an "image" (well, the artifacts do get cached locally and online at places like https://www.cachix.org/), and the only reason they can do that is because they too are deterministically guaranteed to succeed, more or less), which means you can just include any and all services you need. (Unless they need to run as separate machines/VM's... in which case I suppose you just manage 2 nix files, but yes, "composing" in that case is not really fleshed out as a thing in Nix, to my knowledge)
NixOps and nix-deploy: EXIST! https://arista.my.site.com/AristaCommunity/s/article/Deploy-...
> better be sure that every employee is using Nix and have the same configuration. The whole point of docker is to make reproducible builds everywhere, not just your computer.
lol, "tell me you never used Nix without telling me you never used Nix" because it literally guarantees that, each project is a pure environment with no outside influences. THAT IS LITERALLY ITS ENTIRE PURPOSE OF EXISTENCE lolol
I absolutely guarantee you that you will have more reproducible builds with Nix than with Docker. I know, because I've worked with both of them for months on end, and I've noticed that it pains me to work with Docker more than it pains me to work with Nix (hey, it's not perfect either, but perfect is the enemy of good in this case)
How?!
It's not like you can't configure builds differently based on an ENV variable, which is exactly what most build tools already do.
> Second, if one employee wants to install htop on their machine, then every employee will have to install it
There's actually a way to install things on the fly on first use. That way, if you never use it, it will never install. If you use it more than once, it will use the locally-cached version. Next?
> this can quickly become a problem when you have 500+ developers.
Nope. Already answered. Plus, you can allow some things into the "pure" environment if you wish. Harmless things like btop or htop, for example.
> Third, I think you missed the first part on the second quote, you are FORCING every developer
What part of "everyone has to use slow-ass non-deterministically-building Docker" is NOT "FORCING" every developer to use something? LOLOL. Plus, on Macs (which USED to be my preferred dev machine) it's slow as fuck, which is why I had to switch to a linux laptop anyway, which is why I said "fuck this" and installed NixOS and went to town instead.
> to not only use linux but also to use one distribution that is pretty niche.
First of all, wow, you are naïve. No good thing DID NOT start out "niche". Literally every technology I've gotten into except for ASP.CRAP was "niche" when I got into it- from Ruby, to Postgres, to Elixir, to Jquery (at the time)... Do not judge things based on their popularity because that's the Appeal to Popularity fallacy. Judge things based on their promise, young padawan. And Nix... promises much.
1: https://github.com/matthewbauer/nix-bundle
2: https://github.com/NixOS/bundlers
Ooh let me try...
"except you can't deploy Dockerfiles"
With docker you deploy the artifact, same with Nix. Nix can also create docker images.
> , and even if you could, better be sure that every employee is using Nix and have the same configuration.
How is this different than employees needing to have the same docker version?
In a large org, either will likely be provisioned.
> The whole point of docker is to make reproducible builds everywhere, not just your computer.
No.
Docker doesn't make reproducible builds, it makes repeatable builds.
The whole point of Nix is to make reproducible builds everywhere.
The easiest one is NixOS, and that'll be enough for most people, provided that they're okay using it as the OS for their servers.
The other is Disnix, which is a bit more cumbersome but also more flexible, and works fine for deploying Nix-based software to other systems.
I've linked it a few times in this thread already for that reason.
Edit: see https://devenv.sh/containers/
Docker the company is crushing 2022-2023… record revenue and earnings
The root namespace problem was created by an early stage startup many years ago. I feel for the rough spot they are in.
edit: https://github.com/moby/moby/pull/10411 this is the change that would _actually_ solve the problem of docker squatting the root namespace, and they've decided against it because it would make dockerfiles less portable (or really, it would neuter docker.io's home as the default place images live)
Even better, the registry may continue to exist, but would (eventually) stop storing the images, and start storing .torrent files for the actual downloads. Seeing an image from the GitHub release page would be enough for most smaller projects (yes, BT supports HTTP mirrors directly).
Docker downsized from 400(!) to 60 people a few years back, and a quick search on Google says they're now back up at 600 employees again. They have ARR of $50M [0] , which is probably a little short of paying 60 people SV salaries, but it's nowhere near enough to pay for 600 people.
As regards to the registry problem, "most companies" I suspect don't follow best practices and in fact do end up using docker hub for things like public images, but more importantly _there is no way to enforce this in the tool, and docker have refused to implement this when given a PR_.
[0] https://techcrunch.com/2022/02/01/docker-makes-comeback-reac...
I don't. Because there is this pattern from VCs to fund business models that involve dumping millions in resources as Open Source on the world and then owning a part of the ecosystem.
Docker originally wanted to "own" everything, if CoreOS hadn't pushed for the OCI spec, debalkanizing containers, Docker would have a near monopoly on the container ecosystem.
At this point Docker is just the command, and it is a tire fire of HCI gaffs.
if you did `docker tag supersecret/app:latest && docker push` instead of `docker tag registry.corp.com/supersecret/app:latest` guess where your code just went?
Same on the pull side, if you wanted your corp's ubuntu base rather than just `docker pull ubuntu`.
This is really not much different from https://news.ycombinator.com/item?id=35133510 case.
However, their core offering must be the leader if they want to survive. Devs must want to use "docker run" instead of "podman run" for example. Docker needs to be the obvious #1 for starting a container on a single machine.
If their core offering is container hosting, they should be able to make a company out of that even without the client. After all jfrog and cloudsmith are more per less just that, as is github.
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.
It's quite a shame (for the lack of better wording) that the better, simpler and more intuitive a free product is, the harder it is to make money from it by selling support.
I think that the best way to go from here, would be building companion products and supporting the whole ecosystem. By companion products, I mean other standalone apps/services, not just GUI for existing one.
It should have been just a small company, doing this, and making some money for their trouble instead of whatever it is they're trying to be.
What I don't like is having these critical tools directly in the hands of a single for-profit corporation, at least where it can be avoided.
I m doing that personally but I m very hesitant about mentioning that to $job.
Indeed. We should all be equal in that venture: Ain't nobody here but us chickens.
I must be missing something obvious, because otherwise I feel like I'm going insane.
It was later shut down.
1: https://venturebeat.com/business/docker-acquires-container-d...
> Tutum is not a real PaaS, it runs containers in the user infrastructure and can be easily adapted to run on-premise
Which doesn't sound like managed container hosting to me. Their site is gone though so I'm not really sure. There was 0 discussion around their shutdown, if they did have a managed solution I'm curious why it failed. Too early?
1: https://news.ycombinator.com/item?id=16665130 2: https://web.archive.org/web/20180328234733/https://docs.dock...
Its not clear if that is due to:
i) competition from proprietary business models
ii) more specifically the excessive concentration of said proprietary business models ("big tech")
iii) confusion from conflicting objectives and monetisation incentives (the various types of licenses etc)
iv) ill-adapted funding models (venture capital)
v) intrinsic to the concept and there is no solution
vi) just not having matured yet enough
What I am driving at is that building more complex structures requires some solid foundations and those typically require building blocks following some proven blueprint. Somehow much around open source is still precarious and made up. Ideally you'd want to walk into the chamber of commerce (or maybe the chamber of open source entities), pick a name, a legal entity type, a sector and get going. You focus on your solutions, not on how to survive in a world that doesn't quite know what to make of you.
Now, corporate structures and capital markets etc took hundreds of years to settle (and are still flawed in many ways) but we do live in accelerated times so maybe its just a matter of getting our act together?
There are healthy ecosystems, even some partially replacing docker, some with more daily updates than I can process, but they have copyleft licenses in place and are free software, to ensure contributions flow back. Companies can still make profit, but not from adding a minimalistic thing and making it proprietary. They need to find other ways.
That's it. Pushover licenses are not helping at all.
No, I don't work for redhat. I'm glad a ... ?less? corporate entity / ?more? open source entity has pretty much gotten a replacement up.
Another bad use of Docker that I've seen is because people cannot figure out how to write systemd units, that is damn simple (just spend a day to read the documentation and learn the tools that you need). Of course that makes administering the system so much complex because you cannot use the benefits that systemd will give you (thus you start using iperoverengineered tools like kubernetes to just run a webserver and a database...).
I'm maybe oldschool but i use Dockers as a last resort, and prefer to have all the software installed properly on a server, with the use of Ansible as a configuration management tool. To me a system that uses Docker containers is much more difficult to manage in the long run, while a system that doesn't use it is more simple, thus less things that will break, thus if I need to make a fix in 10 years I ssh in the system, edit the program with vim, rebuild and restart the service, no complex deploy pipeline that break, depend on external sources that may be taken down (as is the case) and similar stuff.
If you’re sshing to boxes, editing things by hand and slinging ad-hoc commands around then your frame of reference is so far away from understanding it’s value proposition that it’s probably pointless to discuss it.
I like nix - it’s probably the right direction, but just compare the UX to Docker. Comparatively Docker absolutely nailed it.
Just like Visual Basic 6, it's super-easy to get started with a Dockerfile, but nigh-on impossible to create a quality result with it.
Nix needs reproducible builds as well, which is a limiting factor. What’s nice about Docker is that it’s flexible enough to actually get stuff done.
It doesn't have to be, Nix lets you choose your level of purity and it can build docker containers.
- devenv
- devbox
- others i'm forgetting
I think one reason you may be seeing downvotes here is that you have specific projects in mind, and without you naming them, others who haven't used such projects don't see how real the phenomenon is.
I was recently helping a friend work through some Nix configuration and he told me about a couple of different projects he used where deploying the software any way other than via Docker was treated as either officially or de facto unsupported. In some cases, dependencies are not even exhaustively named in the documentation. When users ask questions in community channels (often on Discord) about what the software's requirements are, they are (at least sometimes) directed to just use the pre-baked Docker images instead of receiving real answers to their questions.
This is second-hand info for me. I don't know how bad it really is, or how common, either. But that kind of thing a absolutely screams to me, too, 'very few of us actually know how this thing works'.
Still, sharing that sentiment without giving a specific account of software that you've seen fall into this trap is likely to be dismissed and downvoted. Maybe it would be helpful to give some concrete examples of what you brought all that to mind for you.
The huge bandwidth requirements are an incentive to keep images small.
The cost of some of the IPFS hosts that will give you a dropbox of sorts still end up costing roughly the $20/month similar to the Docker $25/month for a team account.
It doesn't seem unreasonable to have the client automatically pin/seed the container it pulls.
Looking at the rates of enterprise storage costs compared to what Google or Apple charges consumers - I was surprised by how subsidized people's photo libraries are.
Google also charges a flat rate for 2TB with the next lowest plan being 200GB. So the majority of users are paying for 2TB but not using anything close to that much. I suspect consumer storage is also much easier to offload to hard drives and tape backups while files on S3/B2 would mostly require SSDs with some probably being stored in ram.
https://github.com/kubevirt/kubevirt/blob/main/containerimag...
That has not seemed to have happened here, or not happened well.
Nobody expected it to be free forever; I think we expected the transition to be a lot more orderly. There have been years to prepare.
Podman Desktop runs podman machine for me at startup.
Containers set to restart automatically don’t restart across podman machine restarts but that hasn’t upset my workflow much (at all?). I just start containers as I need them.
And when GitHub starts similar shenanigans, move out to where? I am old enough to know the we can't trust BigTech and their unpredictable behaviors.
Eventually we need to start a Codeberg like alternative using Prototype funds to be self reliant.
1: https://codeberg.org/ 2: https://prototypefund.de/
I mean why should you expect someone to host gigabytes of docker images for you, for free?
So now they destroy their foundations and learn whether they 10x or fold. Pretty standard VC playbook so I assume that's the driving force here.
What a load of crap. Free Software's "0th freedom" is the ability to use the program for whatever purpose you wish. The definition of Open Source is even looser than that. They are asking their "Open Source" users to make their software non-free, by restricting its use cases.
Anyway, the writing has been on the wall for a long while. If you haven't moved off Docker Hub yet, now is the time.
I have been building this for 5+ years, and offer a community edition for free while the hosted version is paid. Once the community edition starts costing money there will be even less reason to continue supporting it, it already causes a lot of extra work and problems that I'm otherwise uncompensated for.
This is exactly the reasoning Docker is using, so it seems reasonable?
OTOH, somewhere else in this context it was mentioned that curl is almost entirely maintained by one guy who makes money from consulting; and because of that, he wouldn't qualify.
So if you're either small enough to be a side hobby project, or large enough to have your own non-profit, you can get it for free; anywhere in between and you have to pay.
Personally I'd be happy for Xen to pay for Gitlab Ultimate, except that the price model doesn't really match an open-source project: we can't tell exactly how many people are going to show up and contribute, so how can we pay per-user?
https://github.com/hinshun/ipcs
All this centralised dependence talk is frustrating (it's expensive, no free lunch etc;) when it's largely been a solved problem for decades.
The problem with just replacing GitHub isn't the source code hosting part. There's tons of alternatives both commercial and open source. The problem is the cost of CI infrastructure and CDN/content/release hosting.
Even moderating said CI infrastructure is a nightmare. freedesktop.org which uses a self-hosted gitlab instance recently had to shutdown CI for everything but official projects because the crypto mining bots attacked over the last few days hard and fast.
If you view all of this "free" VC subsidized stuff as temporary/ephemeral you can still have a healthy relationship with it.
Tricky bit is, for some users, you’ll either abandon them with no way to share or you will still be paying their ingress/egress fees when their client falls back to your TURN server if NAT hole punching fails.
You’ll also have to solve image expiration gracefully. Hosting a “publish as much as you want” append-only ledger isn’t going to scale infinitely. There needs to be garbage collection, rate limiting, fair-use policies, moderation, etc. Otherwise you’re still going to outstrip your storage pool.
One of the most revolutionary and fundamental tools to be made is a basic way / template / paradigm which constructs databases in a replicable way, such that the hash of the code is mapped to the hash of the data. Then the user could either just download the data or reproduce it locally, depending on their system's capabilities, and automatically become a host for that data in the network.
big projects could self host easily, as their popularity would quickly give them enough seeds to not need to provide much traffic themselves.
also I think adapting docker way of storing layers as tars is fundamentally broken, maybe with combination with something like ostree as a storage to decrease duplicates we could really cut a lot of storage.
imagine how much unique content does your average docker image have? 1 binary and maybe few text files? rest is probably os and deps anyways.
The difference between GitHub and Docker is that GitHub is profitable.
Hosting GB images in an append-only registry, some of which get published weekly or even daily, will burn an incredible amount of money in storage costs. And that’s before talking about ingress and egress.
There will also be a tonne of engineering costs for managing it, especially if you want to explore compression to push down storage costs. A lot of image layers share a lot of files, if you can store the decompressed tarballs in a chunk store with clever chunking you can probably reduce storage costs by an order of magnitude.
But, at the end of the day, expect costs for this to shoot into the 6-7 digit USD range per month in storage and bandwidth as a lower bound for your community hosted image registry.
c'mon. This is not amateur hour. Hosting the whole thing only made sense for docker because their plan was always to do this microsoft style play.
If you assume you are either open source or fully closed enterprises, the problem is very, very easy to solve. and cheap. Just relinquish full control of being able to close all the doors for a fee, like they are doing now.
1) deterministic builds with centralized caches
2) snapshots
Docker has some features of (1) but is really (2).
You absolutely do not want to download the recipe to build a Docker image instead of the image itself.
Further, the base images have no recipe. They are a tarball of a slimmed down pristine base os install.
Even core-js sole maintainer failed to raise enough donations to feed his own family, despite the library is used by at least half of the top 1000 Alexa websites. [0]
People (and also big-techs) just won't pay for anything they can get for free.
[0]: https://github.com/zloirock/core-js/blob/master/docs/2023-02...
Did GitHub just eat them?
However it looks like the main effect is going to be moving more of open source onto GitHub, aka under Microsoft's control, and the level of faith people have in Microsoft not destroying their competitor for profit is surreal.
Docker, the company, is failing. Docker, as in containerization technology, is alive and very well.
(edited for clarity)
Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more. I don't think it matters much that k8s uses CRI-O but docker needs to be #1 for running a container on a single machine. Yet, they seem to be letting that slip away because it is not directly monetizable. Software businesses need to be creative - invest a lot into free things, which support monetization of others. If you want low risk returns, buy T-bills.
I've used "Docker" as in "containerization", since they are often used synonymously and the grandparents intent was definitely to criticize the latter. Docker itself will quite likely stay around as a name, but I have no faith in the company.
In fact, I'd go as far as to say that, given the ubiquity of their product, I can't think of a worse way a company could have performed. It's been about 10 years now since it really took off, and in that time, the technology has been great, but dealing with the company, always been difficult.
Nah, you just didn't look carefully enough. Docker the technology has been recurring amateur hour of screwups. For example, they hashed the downloaded data but forgot to compare the hash to expected value.
The only thing "great" about Docker was the rough idea of easy-to-transport filesystem images that could run just about anywhere, and the fact that they managed to make that kind of thinking mainstream.
- Microsoft Windows: Various versions of Windows have had critical security vulnerabilities over the years, leading to widespread malware outbreaks like WannaCry and NotPetya.
- OpenSSL: In 2014, the Heartbleed bug was discovered in OpenSSL, which left millions of websites vulnerable to attacks that could steal sensitive data.
- Apache Struts: In 2017, the Equifax data breach was caused by a vulnerability in Apache Struts, a popular open-source framework for building web applications.
- Boeing 737 Max: In 2018 and 2019, two deadly crashes were caused by a software flaw in the flight control system of the Boeing 737 Max airplane.
- Google Cloud: In 2020, a widespread outage of Google Cloud services caused disruptions for many businesses and organisations that rely on the platform for their operations.
Should I continue?
Many will come to comment "that's absurd, and you could just use an old executable you already downloaded prior to them halting it's circulation", etc. But I do think the writing is on the wall here with Docker continually getting greedy. If they don't monetize the use of Docker containers in general by making users pay to run them, they have other options like spyware and ads - e.g. install telemetry in the base of the system somehow to sell the personal data they receive from all images*, etc.
* I know this may not work directly as I've stated it, just giving the flavor of idea
I appreciate that pun ;)
> Many will come to comment "that's absurd, and you could just use an old executable you already downloaded prior to them halting it's circulation", etc.
I don't see this as absurd at all. The problem Docker has is that it failed to use it's market share. Making these moves now that easy alternatives exists (Podman, open registries, k8s etc) just doesn't have the pull and alienates their remaining customers.
There are three practical problems as a result: - huge image sizes with unused dependencies delivered as part of the artifact; - limited ability to share dependencies due to inheritance-based model of layers, instead of composition-based model of package managers; - non-reproducibility of docker images (not containers) due loosely specified build instructions.
Predicting future comments, nix mostly fixes these issues, but it has a bunch of issues of its own. Most importantly, nix is incredibly invasive in development process, adopting it requires heavy time investments. Containers also provide better isolation
There is definitely a bit of a learning curve but the time investment is frequently over exaggerated. I see it as similar to the borrow checker in rust. Yes, you have to spend some time and also learn about the rules. But it helps you build software that is more robust and correct. Plus once you're into it you save significant time not having to deal with dependencies especially when bringing on new people
> 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.
Typically yes, but Nix actually allows you to be less pure to save time and pick your most economic point on the reproducibility continuum.
I'm fairly sure there was an article about this... ah here it is:
https://www.haskellforall.com/2022/08/incrementally-package-...
Yes, for cache hits to happen it has to be this way as far as I remember.
There is a project called nix-portable though that I've seen some HPC users report success with:
https://github.com/DavHau/nix-portable
> Applications packaged with Nix also require special treatment to run in Nix environment, with paths rewritten and binaries patched to support Nix filesystem structure instead of the traditional Linux one.
If you fully package it. If you use something like an buildFHSUserEnv[0] that's not true.
There is also nix-autobahn and nix-alien for automatically running foreign binaries on a more ad-hoc basis or to generate a starting point for packaging.
0: https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
This was my first thought when I learned of Docker.
I have a hard time calling myself an 'Engineer' when there are so many unknowns, that I'm merely playing around until something works. I insist on being called a Programmer. It pays better than 'real' engineering. Why not embrace it? (Credit toward safety critical C and assembly though, that's engineering)
EDIT: Programmer of 15 years here
I noted to someone that this felt less like a product and more like a website and set of scripts ripped from a working system. A few of us were shipped up to the originating university for a week to hob-knob with the people in charge of it. Toward the end, during the ritual inebriation phase, I managed to find out that they had never actually attempted to install it on a clean system. This had truly been ripped from a working system. And I thought to myself, "How horrible."
Now, I am admittedly pants at Linux. No good at all. But there is something about Docker and similar technologies that says, "Yes, we threw our hands in the air and stopped trying to make a decent installation system."
I mean what do you expect, it goes along so nicely with "Yes, we threw our hands in the air and stopped trying to architect coherent software systems."
maybe the vlsi is closed. but that is "industry standard" i guess. rest is a bunch of mathy-language du jour held together with python or something.
...opaque docker containers going to prod doesn't have a excuse other than inefficient orgs fulled by VC or Ad money. Or maybe they do, but you won't excuse them using NASA as an example :)
They pushed that with the aggressive rate limiting first though, which caused a lot of people to now understand that paragraph above and use proxies, specify a different "hub", etc.
So this move, to me, has less leverage than they might have intended, since the previous move already educated people on how to work around docker hub.
At some point, they force everyone's hand and lose their moat.
Big players can carry the costs, but what can small ones really do once money runs out?
Kubernetes is currently in the process of changing the main repository for their images because, as I understand it, they're burning through their free GCP credits an an unsustainable rate.
Ideally Docker Hub would be an industry funded effort, but that would require co-operation and funding from the major tech. players, and I have a feeling that in an era of cost cutting, that might be harder to achieve than it was in the past.
One of the things the docker api has going for it is that it is hash based. Aside from the first time, it doesn’t seem far fetched for a docker api client to refuse or warn based on comparing the new download’s hash to the previous hash.
My proposal is that each time an image is pulled, the hash is recorded and retained even if the underlying container image is removed. When the same image is pulled again, if the files change from the previous hash, either fail or warn the user.
I can see how pinning to a specific patch version is not a great idea and that "python:3.11" keeps people from pinning to an insecure version.
Now we need a Docker registry cooperative owned by everyone.
You can build a pyramid with a non-profit, but that does not mean it owned by everyone.
Pyramids are problematic, as governance are a nightmare.
Is there another container hosting site?
https://cloud.google.com/container-registry/docs/pulling-cac...
https://gallery.ecr.aws/
edit: typo
The only benefit of doubt Docker deserves is on a psychological plane: evil or stupid?
Or to put it another way, Docker should have been focused on sustainability from the start and not dangled a price they knew couldn’t last in front of people to increase adoption.
Plus, I doubt they will get many people to actually start paying. People will simply move to other storage (like Github) and switch the URLs. Docker is fully open-source and works without docker.io, they don’t really have a position here except owning the name.
IMO they just need to edit / clarify that open-source developers and organizations won’t need to pay, only those who presumably should have the funds. And take a more passive stance: bug people with annoying messages like Wikipedia does, and threaten shutting down docker.io altogether if they don’t somehow get funding (some people will complain about this too but more will understand and will be sympathetic). Wikimedia, Unix/Linux, Mozilla, etc. as well as Homebrew/cURL/Rust all seem to be doing fine as nonprofits without creating huge controversies like this.
Initially it's great if you can get all the FOSS to play in your technology walled garden. Subsidize it with VC cash.
Downside is it generates a ton of traffic that is hard to monetize. Sooner or later it reaches a point where it can't be subsidized and then you get pay up or get out decisions like this.
One question I haven't seen yet is 420 USD? Is that what it costs to serve the average FOSS project? Or is that number a bad Elon style joke? If they came out with "We've calculated X as actual costs. We're making no margin on this but can't free lunch this anymore" that would go down a lot better I think.
The only recommendation to everyone: move away or duplicate.
One of the strategies I am yet to test is the synchronization between gitlab and github for protected branches and tags and relying on their container registries. Thus (at least) you provide multiple ways to serve public images for free and with relatively low hassle.
And then for open source projects’ maintainers: provide a one command way to reproducibly build images from scratch to serve them from wherever users want. In production I don’t want to depend on public registries at all and if anything I must be able to build images on my own and expect them to be the same as their publicly built counterparts. Mirroring images is the primary way, reproducing is the fallback option and also helps to verify the integrity.
I suspect the latter will become more common over time. I can count on no fingers the number of open source projects which I’ve encountered which have production-grade container images. Once you need to think about security you need to build your own containers anyway and once you’ve done that you’ve also removed the concern of a public registry having issues at an inopportune moment.
I have avoided a couple of incidents caused by images being removed or momentarily not reachable with it. It would at least mitigate any immediate issues caused by images being removed from Docker Hub.