Using RPis can be a huge PITA, if you'd like to do something a bit more complex with the hardware. HDMI, the video decoders are all behind closed doors with blobs on top of blobs and NDAs.
RPi SoCs are some of the weirdest out there. It boots from the GPU ffs.
I’m surprised anybody works at bcom these days.
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
I don't know why but Artifact Hub never shows up in Google search when you search for "web site with helm charts". Hopefully this gives it a boost.
Ironically (in the context of this submission) Bitnami has a "--schema" option to their README generator, which is why so many of their charts ship with .schema.json files: https://github.com/bitnami/readme-generator-for-helm/tree/2....
There are likely other "give me a schema for this example JSON/YAML file" but almost certainly wouldn't come with the nice {"description":""} blocks, nor the {"required":false} that an annotated .yaml can offer
While digging up that link, I also spotted the tag line in their GitHub org which is hilarious https://github.com/bitnami#:~:text=trusted%20by%20ops
Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
---
As for the "only string values for annotations," I think you mean patternProperties:
{
"$schema": "http://json-schema.org/draft-07/schema",
"type": "object",
"properties": {
"annotations": {
"type": "object",
"description": "this is the description of the annotations key itself",
"additionalProperties": false,
"patternProperties": {
"^[a-z][a-z0-9./]+$": {
"type": "string",
"description": "holds the value of the annotation"
}
}
}
}
}
annotations:
alpha: 123
annotations:
_: xxx
0xcafebabe: denied
If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format
I might use Helm charts for initial deploys of operators, but that's about it.
Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.
Sometimes the limitations of kustomize annoy me, but we find ways to live with them
But, if it helps, my mental model of Kustomize is "it's a sequence of JSON Patch [1] operations"[2] which makes it absolutely stellar for mutating someone else's helm chart[3] (or yaml) since you can target anything for updating to your needs
My secondary complaint is that even JetBrains don't have good support for it, which makes working with them extra hard mode
1: https://www.rfc-editor.org/rfc/rfc6902.html
2: it's a very "functional programming language" mental model https://kubectl.docs.kubernetes.io/references/kustomize/kust...
3: https://kubectl.docs.kubernetes.io/references/kustomize/buil...
We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.
So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.
Replacing with hash is a neat idea, might start doing that too.
Yet somehow, all we have is YAML templating?
1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories. 2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config
- Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/)
- Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks)
- Stores copies/versions/etc of each installation in the server so you have metadata for troubleshooting/operations/etc without having to keep it in some external system in a custom way.
- Allows a user who doesn't know anything about K8s to provide some simple variables to customize the installation of a bunch of K8s resources.
- Is composeable, has templates, etc.
So basically Helm has a lot of features, while Kustomize has... one. Very different purposes I think. You can also use both at the same time.
Personally I think Helm's atomic deployment feature is well worth it. I also love how easy it is to install charts. It feels a bit like magic.
Realistically, a plain helm install without any values rarely if ever gives you the deployment you need, so you have to study the chart anyways.
> rollback on failure
This is hardly unique to helm.
> history metadata without (...) some external system
In 2025 you should probably be using gitops anyways, in which case the git repo is your history.
works for me most of the time
> This is hardly unique to helm.
So what? The guy was asking what is nice about Helm vs Kustomize. Does Kustomize have rollbacks?
> In 2025 you should probably be using gitops
Gitops is literally just "hey I have some configs in Git and I run some command based on a checkout", i.e. infrastructure as code in a git repo. Gitops does not track live server metadata and deployment history. I don't get why people over-inflate this idea.
Please check https://opengitops.dev/
I believe(!) that the "rollback" that helm attempts to put back all the mutated objects, which it can - in theory - do because it maintains the previous state in the Secret objects that contain the rendered(?) and the values for the prior revision
try:
for obj in manifest_objects:
kubectl_apply(obj)
revisions.push(manifest_objects)
except:
old_revision = revisions.pop()
for obj in old_revision:
kubectl_apply(obj)
Very very little else seems to bring this basic sense to Kubernetes. Metacontroller kind of could do that. Crossplane's whole business is this, but it's been infra-specialized: but the Crossplane v2.0 release is trying to be much more generally useful. https://docs.crossplane.io/v2.0-preview/whats-new/ . Would love other examples of what does composition in Kube.
Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.
In true GitOps, I think it's should be default on.
You can read a comparison with Helm here: https://www.ohayocorp.com/anemos/docs/comparison/helm
P.S. I am the author of the tool.
There is another category of users who want a way to mange multiple vendor offerings in a consistent manner into their clusters. If they're all packaged with Helm, the user can have standard process and tooling to do that. It's done for K8s apps what containers did for executables.
Is it great? No, see the grief and pain in sibling threads. Are there alternatives? Sure. But Helm is sort of a standard at this point, warts and all.
I work for a vendor that sells to the second category usually, my chart has some 45 images with some intricate hooks for install and upgrade, subcharts, multiple namespaces, etc. You'd be hard pressed to repackage our stuff for every release we give you.
But damn oh damn does Broadcom feel like a good fit for this statement.
From ticket https://github.com/bitnami/charts/issues/35164:
> Now – August 28th, 2025: Plan your migration: Update CI/CD pipelines, Helm repos, and image references
> August 28th, 2025: Legacy assets are archived in the Bitnami Legacy repository.
From README https://github.com/bitnami/charts/blob/4973fd08dd7e95398ddcc...:
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
What are users expected to do exactly?
Once the cleanup is complete, the mainline "bitnami" repository on DockerHub will contain only a limited subset of Bitnami Secure Images (at this moment available at "bitnamisecure"). These are hardened, security-enhanced containers intended for development or trial use, providing a preview of the full feature set available in the paid offering.
- Bitnami: https://hub.docker.com/u/bitnami - Bitnami Legacy: https://hub.docker.com/u/bitnamilegacy - Bitnami Secure Images: https://hub.docker.com/u/bitnamisecure
From the bottom of the post I know what they are hoping users will do:
> Suppose your deployed Helm chart is failing to pull images from docker.io/bitnami. In that case, you can resolve this by subscribing to Bitnami Secure Images, ensuring that the Helm charts receive continued support and security updates.
They don't want to give instructions that are too helpful. They want your company CC to be the easiest way to fix the problem they created.
https://aws.amazon.com/marketplace/pp/prodview-pwqgz3mnvxvok...
You can always follow the "contact sales" form and see if they give you a higher or lower number than that.
Fuck Wall St. greedy morons at Broadcom. Hubris will educate them the hard way as they fade in relevance.
All gone now. Sad.
Broadcom's continued ability to perform well while only serving ever more upmarket areas, & cutting everyone else loose (& generally giving no figs) is fantastically impressive.
The large majority of work done in OpenJDK is by Oracle employees.
Had it been for most of those players, Java 6 would have been the last version.
Corporate players came into play after Oracle acquired Sun. The fear that Oracle would do the same as LibreOffice pushed players like IBM to have their own Java distributions.
Of course Oracle having more support for OpenJDK is not surprising. However, the open nature and existing players already make it easier to fork / replace Java compared to Vmware.
What Google did with Android, it is hardly any different from Microsoft with J++, only that there the courts had another outcome.
Android with a Java subset and Kotlin, is hardly any different outcome than .NET with C#.
Corporate players came in, after money was available again, after the acquisition.
"James Gosling Triangulation's Interview on Google vs. Sun"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&t=3462s
"James Gosling on Android and Java"
https://www.youtube.com/watch?v=IT__Nrr3PNI&t=6245s
If Google actually cared about Java, they missed their opportunity to acquire Sun, own Java, do whatever they felt like doing with it for Android, and the rest of the industry, and best of all, they would never had to bother with any lawsuit.
Given how much the so called existing players contributed to save Java while Sun was going under, that is whishful thinking.
Last company was pretty heavy free user of Bitnami charts for various things but biggest being Redis clusters. I can't imagine they could convert everything into a cluster using their own charts before this kicks in. Very possible they end up tossing at least a year worth of licensing towards Bitnami.
[pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8
In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.
It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.
But again, anyone with any knowledge or experience of Broadcom saw this coming, so...
Doesn't this mean everything is still available, just in source form instead of binary? Could a situation like AlmaLinux/Rocky Linux etc. spin up where folks build a community-supported set of binaries from source?
> All existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be moved from the public catalog (docker.io/bitnami) to the Bitnami Legacy repository (docker.io/bitnamilegacy). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.
This sucks, I used to like the Bitnami container images (didn't need the Helm charts) because the images were consistent and consistently nice (documentation, persistent storage, configuration, sizes), but now I need to move off of those.
Basically, I'll need to move to the regular upstream images for:
* web servers (Apache2 because it's well suited for my needs, but the same would apply to Nginx and Caddy)
* relational DBs (MariaDB, though I'm moving over to MySQL 8 for any software that needs it due to their 11 release having compatibility issues with MySQL drivers; as well as PostgreSQL)
* key value stores (Redis)
* document stores (MongoDB)
* message queues (RabbitMQ and NATS)
* S3 compatible blob stores (MinIO and SeaweedFS)
* utility containers (like Trivy)
I'll stay away from Broadcom as much as possible.
Edit:
> Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.
Hmmm: https://github.com/bitnami/containers/tree/main/bitnami/mari... and https://github.com/bitnami/containers/commit/7651d48119a1f3f...
Could you tell more?
I could just use MariaDB drivers where available, but honestly MySQL seems more popular and the MariaDB SPAC and layoffs soured my view of them; ofc PostgreSQL is also nice.
I also know a ton of people and project who are now sort of screwed, because they can not possibly maintain a fork do to the Bitnami complexity, but there's also a reason why they didn't just do their own image.
This did feel inevitable.
ntqz•6mo ago
On that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
_1tan•6mo ago
bags43•6mo ago
The second highest risk is using USA based cloud with 66/100.
The first one was using Spring Boot everywhere 77/100. Till the end of 2025 we need to have migration path to something else with 2 PoCs done.
jchmbrln•6mo ago
radicalbyte•6mo ago
heisenbit•6mo ago
xienze•6mo ago
TYMorningCoffee•6mo ago
loloquwowndueo•6mo ago
mindcrime•6mo ago
terminalbraid•6mo ago
How do I reconcile this statement with VMWare holding the copyright which you will find unambiguously littered in the official Spring Boot repository?
Since you contend the contrary, who does in fact hold the copyright?
xienze•6mo ago
That said, I have noticed that the free support window for any given version is super short these days. I.e. if you’re not on top of constantly upgrading you’re looking at paid support if you want security patches.
jcrben•6mo ago
ntqz•6mo ago
If there's no money in it for them - reduction of staff or funding leading to slower releases and bugfixes
Moving some features like Spring Cloud / Spring Integration, or new development behind a paywall (think RHEL)
Big users (like Netflix, Walmart, JPMorgan, LinkedIn/Microsoft, etc) would likely be able to pay for it (until they moved off), but smaller companies and individual developers not so much
bbkane•6mo ago
Spring is so widely used that there are multiple "large enough" companies who could do this
somehnguy•6mo ago
bags43•6mo ago
- license change -> restricting features behind a paid tier (https://spring.io/blog/2025/04/21/spring-cloud-data-flow-com...)
- reducing headcount of people -> slow security patching + not following industry standards
- all eggs in one basket :)
- cut from major clouds (Azure Spring apps)
lapusta•6mo ago
Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.
I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.
latchkey•6mo ago
EdwardDiego•6mo ago
EdwardDiego•6mo ago
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.