Ask HN: Why hasn't x86 caught up with Apple M series?
423 points by stephenheron 2d ago 608 comments
Ask HN: Best codebases to study to learn software design?
100 points by pixelworm 4d ago 90 comments
The Deletion of Docker.io/Bitnami
160 zdkaster 81 8/28/2025, 4:37:12 AM community.broadcom.com ↗
This is such a naive take. Bitnami images were a sign of goodwill, a foot in the door at places were the hardened images were actually needed. They just couldn't compete with the better options on the market. This isn't a way to fix it, it's extortion. This is the same thing Terraform Cloud did, and I don't think that product is doing so hot.
> Essentially, Bitnami has been the Jenkins of the internet for many years, but this has become unsustainable.
It's other people's software, so it's very rich of Bitnami to accuse anyone of freeloading when their only contribution is adding config options to software that maybe corresponds to a level 2 on the OperatorFramework capability scale[1] - usually more of a 1.
[1]: https://operatorframework.io/operator-capabilities/
But that does not work in 2025. You are expected to make money from the get-go and are left with only enterprise customers and boy, that category is hard, as everyone is competing for that slice.
Also, I'm a little bit wondering at how much all of this is really copyrightable in the end. Because if you keep it private I understand, but here it is basically for each package just a few lines, recipes to build the components that they don't own. Like trying to copyright the line "make build".
And it might be each the single and obvious way to package the thing anyway.
And speaking at the built artefacts, usually a binary distribution of third party open source software with common license should preserve the same rights to the user to access the source code, the instructions to build, and the right to redistribute...
The images themselves have official replacements (for example, looking at https://hub.docker.com/u/bitnami why wouldn’t I use Node or Postgres images from the official sources instead).
I have no idea how many people actually used their helm charts though.
Not that it ever worked well, we had to scale it to 1 because the quorum would constantly break into unrecoverable states.
Have a look at https://github.com/bitnami/containers/tree/main/bitnami/post... as example.
It might be worth a commercial license for some of their current user-base, no doubt.
Instead of a simple package of the software based on some familiar base, you get some weird enterprise garbage that follows strange conventions and a nightmare when you need to customize anything.
It's a shame that competition for this position has been ramping up lately.
Sadly, it feels like an inevitability at this point.
The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
I know Broadcom inherited Bitnami as part of an acquisition and legally have no obligation to do anything, but ethically (which is why they are evil, not necessarily criminal) they absolutely have a duty to minimise the damage, which is 100% within their power & budget as others have pointed out.
And this is before you even consider all the work unpaid contributors have put into Bitnami over the years (myself included).
And sure, we can go ahead and discuss how this being free incurs no SLAs or guarantees. That's correct, but does not mean that such a short time frame is both rude and not a high quality of offering a service. If I look at how long it would take us to cancel a customer contract and off-board those...
And apparently it costs $9 to host this for another month? Sheesh.
The European Union Cyber Residence Act has the potential to drastically change the open source ecosystem.
The new regulation pushes the due diligence for security according to the Act towards any entity making a commercial offer based on open source software.
Caveat emptor!
For any enterprise, that means that they either do extensive documentation and security on open source components they use or they use foundation or enterprise-backed products.
Note that pure uncommercial open source projects are exempt from the Act.
I see this as a chance; we can still create open and free software, and those of us who desire financial compensation from those who make money with their work can offer as a necessary compliance framework as a service via a different entity.
> BSI is effectively democratizing security and compliance for open source so that it doesn’t require million-dollar contracts from vendors with sky-high valuations.
I suppose 50k isn't a million dollar contract, but it's certainly also not "democratizing" anything
But. What they are offering is considered "development" regardless of what you are using it for? In other words, NOT a production environment, because they aren't giving you a production environment (or at least what they define as a production environment.) What they give you for free is the "latest" and on a Debian system.
What they offer as "secure" is running on Photon OS and goes through a security pipeline, etc. They aren't holding anything back aside from the services they provide.
But on topic: why not create docker.io/bsi and let /bitnami as is without new updates? Then nothing breaks; it just won’t be possible to do upgrades. You’ll then figure out why and possibly seamlessly switch to your own build or BSI.
https://stagex.tools
As the only multisigned, full source bootstrapped, reproducible, and container native distro that exists, it does not matter what registry you pull from because the digest is the same everywhere.
We publish all images to both dockerhub and quay and signature checks pass either way so mirror anywhere you want.
Anyone claiming they need to host in a particular registry for security is gaslighting you.
The way I see it, a software project has only (1) code you maintain or pay someone to maintain for you, and/or (2) throwaway code that you will eventually need to replace with an incompatible version.
Nothing wrong with a project that is just gluing throwaway code because it's a gamble that usually pays off. But if that code is from third-party dependencies, just don't believe for a second that those dependencies (or any compatible forks) will outlive your project, or that their developers have any incentive at all to help you maintain your project alive.
You do it when you have a bunch of automated integrations with you and you have to break them. The lights arent on at the client: their dev teams are focused on other things, so you have to wake them up to a change that's happening (either by causing their alerting to go off, or their customers to complain because their site is broken)
It's also used in utility power supplies to describe line voltage going below spec. It's considered a dangerous condition in that context too, as lots of non-smart equipment tend to run at higher amperage at lower voltage and/or fail to start/run and catch fire.
1: https://developerhelp.microchip.com/xwiki/bin/view/products/...
It refers to a situation where a system is deliberately designed to fail (usually for short periods of time), to still provide some level of service while alerting others that the system is soon to be turned off.
You intentionally break something just a little to force dependents to notice, before turning it off completely
I thought it was an analogy to the electrical problem: flickering lights due to high demand.
Over time it will limit adoption and ultimately just make everyone go back to the native open source offering, cutting bitnami/Broadcom out of the loop.
Broadcom really took the open source community backwards with this move IMO.
So good riddance, as far as I'm concerned. I recommend anyone to avoid using them, and switch to official images or to build them yourself if they're not provided. That's the more secure approach, anyway.
Aside of having to re-mount the data disk and move things around manually; the -ha chart has numerous other issues where it always requires the master to be node-0. And with pods being rescheduled within a statefulset, good look having the master be on node-0. If there was an outage and the master is anywhere else, node-0 will just 'wait' for a master to come online, time out and shoot itself in the head thinking it is in a network partition and that retrying may help.
The algorithm implemented by postgresql-ha turned out to be plain broken. Only able to survive pods neatly shutting down.
It's not always a 5 minute job to switch to a different image with different configuration and retooling required.
Fortunately, I started moving us away from Bitnami a little while ago because they started giving me the ick some time back, but a few stragglers remain.
If you're Bitnami it probably made sense to do it the image the way they did, but for everyone else, it's just a massive complication.
Personally I don't understand why anyone would have opted to use the Bitnami images for most things. They are really large and complex images and in most cases you'd probably be better of building your own images instead.
My guess is that there's a very small overlap between people who want to maintain Docker images, and the people who chose to run Bitnamis images.
These aren't just for your laptop, they're supposed to be able to run in prod
I'm still stuck with 3 bitnami charts that I keep updated by building from source, which includes also building the images, all on our private registry.
I would argue that if you run Kubernetes, then you frequently already have the resource to maintain your own images.
At my previous company, we used it because of the low CVE counts. We needed to report the CVE count for every Docker image we used every month, so most of the images were from Bitnami.
There are many enterprise companies freeloading on Bitnami images, and I’m surprised it took Broadcom this long to make this change.
It's time to build your own from core / foundational images - something I recently learned and now seek to master.
The Photon images provide many other benefits not previously available to users of Debian images, including:
With FrankenPHP, I can't imagine why I'd choose Bitnami anymore.
Edit: As I see it's true.
Source code for OCI images: https://github.com/bitnami/containers/tree/main/bitnami
Charts: https://github.com/bitnami/charts/tree/main/bitnami
If you look at the folders there, you'll see that all of the older Dockerfiles have been removed, even for versions of software that are not EOL.
For example:
PostgreSQL 13 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 14 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 15 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 16 (gone): https://github.com/bitnami/containers/tree/main/bitnami/post...
PostgreSQL 17 (present): https://github.com/bitnami/containers/tree/main/bitnami/post...
> The source code for containers and Helm charts remains available on GitHub under the Apache 2.0 license.
Ofc they're all still in the Git history: https://github.com/bitnami/containers/commit/7651d48119a1f3f... but they must have a very interesting interpretation of what available means then.
[1] https://github.com/continusec/htvend
We'll see :)