Not to mention their pro features keep breaking syntax of the community version, obviously with 0 transparency.

Now, of course they should get paid for the work they do, but these sort of "we were FOSS and surprise we're not anymore" are becoming commonplace and are always done hoping no one notices.

Most of us don't want to let a court decide if we compete with a very general distinction you describe, and can't afford lawyers to evaluate a 2 year old license without much case law.

Most of us prefer not to bring on a dependency in our project that is primarily designed to extract commercial value from users and is less friendly to contributors than similar open source projects.

It’s because big tech companies have spent millions to foster goodwill towards the OSI Open Source definition. And there’s a general feeling that software that fits that definition is pure and any that doesn’t is unclean.

Yeah, the distro for "Truly adventurous users" has never broken in a decade of use by myself and is essentially as bleeding edge as Arch.

It's just old ideas that get repeated even once they stop being true.

Just to be devil's advocate here, and pedantically point out that Debian Sid is not a "distro", I don't think it's correct to say that Debian unstable is "actually stable", because it's "unstable" from the perspective of Debian, not from a subjective, individual experience.

Debian release cycles have a strong focus on stability, and for those situations where it matters, like running a production server, that is a pretty important feature. Just because your desktop never broke doesn't mean it's not "unstable", it's more of a disclaimer that if you put serious things on top of it and it breaks, that's much more on you because you chose to go against maintainer advice.

For me personally, with exception of the Enterprise Linux family (Alma, Rocky etc.), there's no Linux distribution I'd rather run on a workhorse, production, long term deployment server than Debian.

> git itself has become a bloated product. There's like 2-3 ways to do everything now

can you elaborate?

After a decade of use I've seem some more cutesy porcelain popping up, but the commit-tree basic concepts have never changed.

The company I work at is using the same exact branching strategy I introduced when we moved to git, with essentially no discussion in the meantime.

It doesn't matter in O() notation.

You need to consider all the energy spent to bring those calories to you, easily multiplying your budget by 10 or 100.

> a logistical nightmare in practice

Could you elaborate? I'd like to learn from the errors of the past

[assuming you're using best practices etc] having your users log into a centralized VPN means that you've got all your different on-prem/DC services and services all in well-designed tightly-controlled VLANs with pinhole access network ACLs between them. additionally, you've got your VPN users in tightly-controlled role-specific VPN groups in their own IP pools that are again additionally tightly-controlled via network ACLs. all of this takes time to setup, run and monitor. unless you run a tight ship with automation helping many of these steps and layers, it can be a logistical nightmare. maybe that's GP meant.

They closed a bug from 2005, respect.

That's funny because it's about installing Office 97, and if you used Office 97 today you probably wouldn't miss anything from 27 years of new versions. So the use case is still there!

I used kustomize before switching to helm, it was a nightmare.

Kustomize is extremely limited and opinionated, which is great if your deployments have only kustomize-approved differences between them, but it has no way to write business-aware config files and at my typical 100 deployments/chart is was becoming megaduplicated.

Do y'all have an alternative? I like it a lot but seeing this thread I'm wondering if it's tunnel vision.

We are working on one, not intending to fully substitute for helm, at least not in the short term. But adding to what helm lacks like easy version updates, dependency mgmt and easy customization.

https://github.com/glasskube/glasskube

Would love to get some feedback on what could be done better.

Oh, I was referring more to the templating side. On the cluster management side I'm already on ArgoCD, can't imagine doing pure helm install.

Will add it to the "cool shit to check out" pile, thanks.

If you like it and it’s working for you, no harm in that. I don’t have a better alternative. Tend to just write my own thin tool on top of the raw kube api for my particular environment or use case. At the end of the day it’s a system that can be controlled via api like anything else. The yaml shenanigans are not strictly required.

generate manifests with https://cdk8s.io/docs/latest/plus/#getting-started (TS, Go, Java, Python) and apply them with kubectl/ArgoCD/etc.

it supports writing tests, and in general, it gives you familiar tools.

That's interesting, sounds like:

* a good trade on the templating side (swapping the helm go-template-like thingy with a real language)

* a loss on the cluster integration side, where I like the integration of helm with ArgoCD and would instead need to add a manifest generation step

Will add it to the "cool shit to check out" pile, thanks.

I use helm for parametrization, so I'd be happy to hear alternatives.

For secrets I'm a big fan of https://external-secrets.io/latest/ paired with a cloud vault, which allowed me to offload secret production/maintainance to the resource teams.

I tried using TF to manage kube manifests, I hated it all around and moved away immediately, so I agree with you.