12345ieee

This seems a cry for help in website form, is the author ok?

Unix users are THE tool to restrict tool permissions, at any given time there's 20+ services on a Unix machine that run in their user.

And where did they put it? On the biggest US platform.

Someday we'll get there, someday.

I struggle to see the beauty in a gargantuan lean proof constructed by 100 different people

Why does it need to be beautiful? Once you proved it it's true and you can use its consequences in math, sciences and engineerings.

Oh no, imagine the people that save human lives having high salaries, the horror.

If you, like me, are in the software field, know that this is likely the most comfortable job even invented by humanity, we should really be paid just above the poverty line in exchange.

I've been using it professionally for years.

As long as you don't use their exclusive DBaaS, moving away is easier than from other places, as egress traffic is free.

The user experience though, stuff of nightmares...

The early theorists of capitalism didn't imagine that advanced psychology (that didn't even exist back then) would be used to convince people to buy $product.

Messages of that sophistication are always dangerous, and modern advertising is the most widespread example of it.

The hostility is more than justified, I can only hope the whole industry is regulated downwards, even if whatever company I work for sells less.

The fact is that being Debian is boring, and JS (python/rust/...) is *cool*.

Give it a few more decades, hopefully it'll be boring by then, the same way, say, making a house is boring.

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.

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.

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

They closed a bug from 2005, respect.

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.

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.

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.

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.

I feel like this doesn't capture what I want out of a custom helm chart.

I want the values.yaml to express business logic, like feature flags or external endpoint configuration, so that the Delivery team can easily read and update it.

The complex infrastructural components should derive from the business config and deploy the needed infrastructure to support it.

Still, I wish I had this tidy list of working kubernetes yaml templates years ago, when we started rolling our charts where I work. I'm definitely checking out some of the resources to see if there is some cool parameter I can steal, thanks for sharing.

As other comments say, this is missing packed unions, which is the best solution I've found while writing a memory editor.

See: https://github.com/scanmem/scanmem/blob/c6045a8677f37a51b976...