Apart from the other things people mentioned here, I recently deployed pinchflat-ngx: it subscribes to youtube channels and produces an RSS feed of videos it downloaded. I had issues with the using the RSS feed from youtube directly - it appears to break more often than not. That pinchflat feed I use in my miniflux instance.

I tried both voidauth and authelia and found that I really like that you can (actually must, as far as I’ve seen) configure authelias OIDC clients as configuration files. That fits a gitops style approach much better when paired with e.g. sealed secrets. It was a real pain to figure out that authelia configuration, hard agree on that… The official helm chart felt way too over-parametrized and is badly documented. The project website has a lot of basically-copy-paste configs for all kinds if self hosted software though.

There are certainly different kinds of developers writing different types of tests. I usually only write the tests first if I‘m adding a critical functionality to some method or function already present. However having automated tests can help you when you can‘t easily understand the code or when you want to refactor that code to make sure you‘re not breaking existing functionality.

What you‘re describing with external devs often happens when these devs can‘t access the real data - plus you often want these tests to be automated, which usually brings with it the requirement of atomicity, i.e. you want one test run running in parallel with another not effecting each other. That usually doesn‘t work well with a real database (unless you really take your test engineering to the overengineered tier).

Another point to keep in mind - many distros now ship Podman instead of Docker, with Fedora being at the forefront of that change. If you‘re currently running Docker, you might want to check if your setup is drop-in compatible with Podman as some images will not work (usually related to permission or user switching, privileged ports).

Ingress controllers usually use the standard k8s services. In fact metal-lb allows workloads (like the nginx ingress controller) in the cluster to use services of type LoadBalancer, which is the default configuration. This results in an actual IP being made available to your ingress controller.

To get nginx ingress to use the external clients IP, you can configure the ingress controllers traffic policy. Using the helm chart, I used these values:

controller:
          service:
            # this has a bunch of downsides, but allows source-ip based access white/deny listing.
            externalTrafficPolicy: Local

For the ingress IP, I configured metal-lb to receive traffic on a static IP (using IP4AddressPool and L2Advertisement CRDs from metal-lb), which is then used for the port forwarding. I’ve never tested it because I only have a single worker node, but I expect the metal-lb controller will continue receiving traffic to that same static IP if a node goes down.

I would always recommend good old Debian for a mostly „it just works“ experience. You‘ll find debian packages for most if not all the things you mentioned. Alternatively you could go the steeper route and use an immutable OS like Fedora CoreOS or Fedora Silverblue for a more desktopy experience.

Hardware wise I‘ve been told the Intel NUC kits work wonders, or similarly specced boxes from Asia. You might get like 32GB RAM, a fairly recent CPU for <400€. Personally I‘m using a 12 year old Mac Mini until it dies, running debian.

63.03% rejecting it is less than I had expected. I was expecting 70% or more, so maybe there is hope for the matter to be reiterated upon in the coming years.

that is some creative citing to get to this headline… on the other hand, wtf bird