Live data from Hacker News

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

blog.alexellis.io

501–510 of 764 posts

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

#501
post #402

Earlier quoted context omitted.

It's strikingly trivial to self-host docker images in AWS ECR and to run your own CICD platform with safe deployments using EC2, the AWS SDK and the Docker SDK. A super basic process that monitors one GitHub repo is ~150 LOC. EDIT: I just confirmed that GPT-4 can write this program. Have fun!

Thank you if you can share this prompt.

Literally just ask it to do it. I've been asking ChatGPT just now to write me a bunch of bash scripts I've procrastinated doing. Holy crap that thing is pretty awesome!

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

#502

Earlier quoted context omitted.

>> 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…

> 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.

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

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

#503

As an SRE Manager, this is causing me a hell of a headache this morning. In 30 days a bunch of images we depend on may just disappear. We mostly depend on images from relatively large organizations (`alpine`, `node`, `golang`, etc), so one would want to believe that we'll be fine - they're all either in the open source program or will pay. But I can't hang my hat on that. If those images disappear, we lose the abilit…

That's why better to have NetBSD + pkgsrc combo for servers.

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

#504
post #477

As an SRE Manager, this is causing me a hell of a headache this morning. In 30 days a bunch of images we depend on may just disappear. We mostly depend on images from relatively large organizations (`alpine`, `node`, `golang`, etc), so one would want to believe that we'll be fine - they're all either in the open source program or will pay. But I can't hang my hat on that. If those images disappear, we lose the abilit…

> If those images disappear, we lose the ability to release and that's not acceptable. This shines light on why it is so risky (from both availability and security perspectives) to be dependent on any third party for the build pipeline of a product. I have always insisted that all dependencies must be pulled from a local source even if the ultimate origin is upstream. I am continuously surprised how many groups simpl…

Likewise. I've always insisted on building from in-house copies of external dependencies for precisely this kind of scenario. It astonishes me the number of people who didn't get why. Having things like docker rate-limiting/shutdowns, regular supply chain attacks, etc has been helping though.

Slightly related: actually knowing for sure that you've got a handle on all of the external dependencies is sometimes harder than it should be. Building in an environment with no outbound network access turns up all sorts of terrible things - far more often than it should. The kind that worry me are supposedly self-contained packages that internally do a bunch of "curl | sudo bash" type processing in their pre/post-install scripts. Those are good to know about before it is too late.

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

#505
post #478

Earlier quoted context omitted.

> Maybe take control of mission critical dependencies and self-host? Last few years prove that this option is a no-go - they just don't do such things ! Independence ? Self-sufficiency ? Security ? Local, fast access ? Obviousness ? No payment required ? Avoid at all costs !

> Last few years prove that this option is a no-go - they just don't do such things ! Who are "they"?

Busy DevOps crews?

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

#506
post #477

As an SRE Manager, this is causing me a hell of a headache this morning. In 30 days a bunch of images we depend on may just disappear. We mostly depend on images from relatively large organizations (`alpine`, `node`, `golang`, etc), so one would want to believe that we'll be fine - they're all either in the open source program or will pay. But I can't hang my hat on that. If those images disappear, we lose the abilit…

> If those images disappear, we lose the ability to release and that's not acceptable. This shines light on why it is so risky (from both availability and security perspectives) to be dependent on any third party for the build pipeline of a product. I have always insisted that all dependencies must be pulled from a local source even if the ultimate origin is upstream. I am continuously surprised how many groups simpl…

I run a local Ubuntu mirror for the work systems I manage, for this reason.

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

#507
post #423

Earlier quoted context omitted.

> 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 techn…

>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, eve…

There's Ada.

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

#508

Earlier quoted context omitted.

First of all, want to say, that sounds deeply frustrating. Secondly, if this is a serious worry. I would recommend creating your own private docker registry. https://docs.docker.com/registry/deploying/ Then I would download all current versions of the images you use within your org and push them up to said registry. It’s not a perfect solution, but you’ll be able to pull the images if they disappear and considering t…

As someone who maintains the registries we use globally at work, +1. I know people groan at running infrastructure, but the registry software is really well documented and flexible. If you don't need to 'push', but only pull - configuring them as pull through caches is nice for availability and reliability -- while also saving from nickle/diming. They will get things from a configurable upstream, proxy.remoteurl . Co…

All good points but while this saves you from the docker images disappearing it does nothing to solve the issue of those images no longer receiving important security updates and bug fixes going forward.

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

#509

Earlier quoted context omitted.

The images you mention (alpine, node, golang) are all so-called “Docker Official Images”. Those are all the ones without a slash as the namespace separator in them: https://hub.docker.com/search?q=&type=image&image_filter=off... They are versioned and reviewed here: https://github.com/docker-library/official-images I don't expect them to go away. Disclosure: I maintain two of them (spiped, adminer).

"don't expect" or "for certain"? Can't really plan ahead without some kind of certainty.

Unless you're hosting the infrastructure yourself, you can't ever be certain. No one can know for sure what Docker will decide to do in the future. The entire company could shut down tomorrow.

But it seems to me that Docker official images are no more at risk of deletion today than they were a week ago.

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

#510

I think it's an interesting challenge with FOSS infrastructure in general, and I'm surprised it isn't more of an issue. Docker's storage is heavier than most, but what about other repositories like maven central, and npm? There must be significant costs associated with running those. These tools are all the backbone of modern software dev, and need a business model. It's reasonable that consumers should pay for the b…

https://mvnrepository.com/repos/central

That has Maven Central as 34TB, which seems reasonable.

Docker is extremely inefficient in comparison, it was 15PB two years ago: https://www.docker.com/blog/scaling-dockers-business-to-serv...

Post reply on HN