Im not the one you replied to, but I wish I had this experience.

I have a k3s install on my homelab, and every helm chart I come across has some new set of assumptions about my cluster baked in and there are often at least one misconception breaking the ability to simply use the helm chart as-is.

Whether its storage container classes, some default ingress config, or something else entirely, I find that the best case is that I write so much yaml into the helm chart I might as well have written the entire thing myself, or it straight up doesn’t work (and I then write custom yaml myself anyway)

However, I have enough applications I’ve converted from app specific installation guides (either assuming bare metal or docker compose) that I’ve extracted patterns that work for my cluster into a basic template I use.

I clone the template, change the app name, add/delete a few parts as needed for the app, and I commit a copy of it into my argoCD directory that deploys out to the cluster.

Its declarative, and that counts for a lot. But its not very encapsulated.

I dunno, maybe I’m just using it wrong. I’m self taught and this isn’t part of my day job. But I haven’t experienced helm as “just works” at all.

The FSF explanation of why they dislike Anubis could just as easily apply to the process of decrypting TLS/HTTPS. You know, something uncontroversial that every computer is expected to do when they want to communicate securely.

I don’t fundamentally see the difference between “The computer does math to ensure end-to-end privacy” and “The computer does math to mitigate DDoS attempts on the server”. Either way, without such protections the client/server relationship is lacking crucial fundamentals that many interactions depend on.