357
points
anttiharju
Joined 294 karma
I like to try understanding how things and people work to help people.
I have a $dayjob, but I am here as myself. Opinions are my own.
Feel free to get in touch via hn@anttiharju.dev
- Feels heavily AI-written, em dashes and the filler.
- Any resources you'd recommend for the k3s+NixOS setup? Been eyeing the same
- I found it interesting that the rollback rate remained more or less constant despite size differences.
- ghostty with tmux has served me well
- Reminds me of cdk8s if one is looking for a framework if it can be called that
cdk8s.io
- Flatcar Linux has looked decent
- Talos' KubeSpan is backed by Sidero-hosted disovery service that cannot be self-hosted without a commercial license
- All pure functions have complexity?
- Checking the first one
> Intel staging area for llvm.org contribution. Home for Intel LLVM-based projects.
Seems like they use it to contribute to upstream which is business as usual?
- Zsa voyager is low profile, you aware of that?
Happy user for 1+ year here
- Responding to an anecdote with another is fair I suppose
- > This already the case today, you can't run your bank's app or government eID apps on anything but Google or Apple devices.
Fairphone 6 with e/OS begs to differ. Dutch phone with a French OS. No issues.
- Love the writing style
- I think most of the pain with GitHub Actions goes away if you use actionlint, action-validator, prettier/yamlfmt in a single ci job to validate your setup. Can even add them as git hooks that automatically stage changes and give quick feedback when iterating.
- Or just use composite actions, it's not 2020 anymore.
Templating GitHub Actions is very powerful (I've worked with such a setup) but it has its own headaches and if you don't _need_ custom tooling better to not have it.
I can wish for improvements on the native setup without reaching out for the sledgehammer.
- I think YAML anchors in GitHub Actions are very welcome, for example for DRYing the push/pull_request 'paths:' filters [1].
Now only if they supported paths filter for `workflow_call` [2] event in addition to push/pull_request and my life would be a lot easier. Nontrivial repos have an unfortunate habit of building some sort of broken version of change detection themselves.
The limit of 20 unique workflow calls is quite low too but searching the docs for a source maybe they have removed it? It used to say
> You can call a maximum of 20 unique reusable workflows from a single workflow file.
but now it's max of 4 nested workflows without loops, which gives a lot of power for the more complex repos [3]. Ooh. Need to go test this.
[1] https://docs.github.com/en/actions/reference/workflows-and-a...
[2] https://docs.github.com/en/actions/reference/workflows-and-a...
[3] https://docs.github.com/en/actions/how-tos/reuse-automations...
It didn't try to maximise by how much it won, but just that it won. Apparently it changed the meta for human pkayers.
If you have the time for it, the movie/doc is worth watching https://youtube.com/watch?v=WXuK6gekU1Y