I use Terraform with the Kubernetes Provider, which is also actively developed by HashiCorp itself.

Templating / injection of values has been much better, skipping the Helm Templating madness and relying on a set of tools that allow perform minting, security scans, generation of docs, unit tests and establish clear dependencies within Terraform, thanks to the graph model.

Helm Charts are a nice idea, but mistakes can happen really easy

This is the way. Remove Helm and Argo from your IaC entirely and manage as much as possible via Terraform with the hashicorp/kubernetes provider. It's simpler (fewer tools), and you also get:

- Clarity re: destruction of obsoleted/destroyed resources (rather than kubectl's "won't do it", Helm's "it depends on ten settings", and Argo's "I'll try my best but YMMV").

- Control over apply ordering if the k8s/tf default doesn't do it for you.

- Resource control as granular (or not, if you just want to write big multi-resource "kubernetes_manifest" blocks) as you want. You can move around, case-by-case, on the spectrum between "templated raw YAML copied from somewhere else" and "individual resources with (somewhat) strong typing/schema-awareness in code". As a bonus, if you do it fully granularly, there's no indirection via YAML happening at all, just per-resource Kubernetes API calls.

- A coherent story for moving ownership/grouping of k8s resources between different logical groups of stuff via terraform import/moved blocks.

- Vastly more accurate proposed-changes diff than Argo, Helm, or even Kubernetes itself can provide: tTerraform's core execution model is plan-as-canonical-changelist, while k8s/helm/argo added noop/proposed diffs as ancillary features of variable quality.

- The ability to mix in management of non-k8s resources (AWS/GCP/Azure/etc. stuff that k8s resources talk to), which is often simpler than deploying complex Kubernetes controllers that manage those same external resources. Controllers are great if you need lots of complex or self-serve management of external resources, but if you are only ever managing e.g. load balancers in one way in a few places, a big controller might be overkill versus doing it by hand.

The only big drawback of this approach is with CRDs. There's no way to have Terraform that deploys CRDs in the same plan as Terraform that refers to resources of those CRDs' types--not even if you conditionally "count = 0" deactivate management of the CRD resources based on variables or whatnot. To cope with this, you either have to get very good at targeted plan/applies (yuck), or plan/apply multiple Terraform modules in order (which is simple and a good practice, but results in more code and can be unwieldy at first).

All the other drawbacks I've heard to doing it this way are pretty silly, and boil down to:

1. "but everyone uses Argo/Helm!" Okay, lots of people smoke cigarettes too--and if you're deploying charts complex enough that you're having to get into the weeds with 'em, you've already gotten enough familiarity to easily port them into kubernetes-provider HCL anyway.

2. "I don't like Terraform/HCL". You do you, I guess, but 90% of the reasons people hate it boil down to either "you're using Terraform like it's 2016 and a lot of massive improvements were released circa 2018-2020", or "the Terraform model forces you to be rigorous and explicit rather than approximate and terse you're mad about it".

Relatedly, I was not impressed with the hashicorp/helm provider and routinely push for folks to go back to the regular Kubernetes provider instead. Architecturally the Helm provider is bad (let's indirect the already-too-complex templating constructs through another templating language! What could go wrong?), and its implementation is also not great--getting diagnostics/log output is harder than it should be, whether old resources are destroyed/replaced/updated-in-place is left left up to Helm itself in complex ways that break with the usual Terraform assumptions, and getting meaningful diffs is tricky (the "manifest" provider experiment exists but is experimental for a reason and causes terraform crashes--not just erroneous diff output--often).

And you can have policy as code, which is a big bonus.

+1 for multi module apply, for CRDs and infrastructure components that must be there, before they can be used from other resources

I'm Berlin was around 22-23 o'clock visible

Can confirm, I've seen pink/green glow over Berlin Sky (and pictures as well)

This is huge. jQuery is still my way to go for any website requiring some custom interaction that isn't available in vanilla js.

What isn't available in vanilla js?

I think it's probably a matter of things being easier: show()/hide() or simple animations versus futzing with style properties and CSS animations.

Diversification is the keyword

https://micjele.adduci.org - my personal site and blog

You've either got a typo in there or DNS issues.

Oh a typo from autocorrection

http://michele.adduci.org

Fries

I made a similar Project, where i embed a NFC Tag Label and use a NFC Reader to trigger the launch of Games on Batocera, using Zaparoo as Daemon.

The kids love it and it's easy to use

The binary relies on the runtime, so yes it is nice.

Forma instance, a static compiled and linked "hello world" in C on Linux is around ~785KB

> a static compiled and linked "hello world" in C on Linux is around ~785KB

Huh?

    $ musl-gcc -xc -static -Wl,-z,norelro -Wl,-z,nosectionheader -Wl,-z,noseparate-code -s - <<eof
    #include <stdio.h>
    int
    main(void) {
            static const char s[] = "Hello, World!\n";
            fwrite(s, (sizeof s)-1, 1, stdout);
    }
    eof
    $ ./a.out
    Hello, World!
    $ ls -l a.out
    -rwxr-xr-x 1 oguz oguz 4976 Jan 12 09:38 a.out

And if that's not enough

    $ musl-gcc -xc -static -nostdlib -fcf-protection=none -fno-asynchronous-unwind-tables -fomit-frame-pointer -Wl,-z,norelro -Wl,-z,nosectionheader -Wl,-z,noseparate-code -s - -lc <<eof
    #include <unistd.h>
    void
    _start(void) {
            static const char s[] = "Hello, World!\n";
            write(1, s, (sizeof s)-1);
            _exit(0);
    }
    eof
    $ ./a.out
    Hello, World!
    $ ls -l a.out
    -rwxr-xr-x 1 oguz oguz 487 Jan 12 09:58 a.out

Probably 785k unoptimized and unstripped with all debug info.

I'm sure that number is using glibc, not musl.

That's just because glibc is not designed for static linking. It works, but it doesn't exclude unused code, unlike with other libcs.

It does exclude unused code. But glibc has too many inter-object-file dependencies, so too much code gets used.

This aged very badly