Yeah, this is pretty textbook selection bias.

I’m not saying it doesn’t suck for this person, but product market fit is a thing for open source too. If people need it they’ll use it and contribute until something better comes along. If not, your idea wasn’t the one. That doesn’t mean it’s not possible. Nearly my whole life runs on open source software, so it’s pretty clearly sustainable.

over the years, using “open source” has become an excuse to avoid paying for software

Um. Yes. And to be blunt: obviously. And in return, I give away software I create for free whether people need it or not, and try to give back in the form of contributions too. But I’ve never once given up my day job for it. Would that be nice? Maybe. But open source software is more frequently sustained by passionate people using and expanding it for their own projects and not by expecting people to pay you for your efforts when you’re likely not paying (nodejs, github, ahem) for the software you’re building it on anyway.

I do all my Linux kernel development, and especially compilation, on my steam deck.

I’m currently playing Lego City Undercover on my steam deck, which is only as crashy as the switch version, and it’s great because my 10 year old is also playing it on the switch, as is my 4 year old. Obviously we all play it differently but it’s been a fun couple of weeks all playing the same game.

Not to mention you really can’t hide that other drive from windows, and I’m sure a lot of the security tools would start screaming about new storage added when not expected. Data Loss Prevention is a big deal and random storage showing up doesn’t often mean the user has good things planned.

Ah yes. BIND v1.

I’m also running arch. Unfortunately I’ve been running mine long enough that it’s just my own bespoke Ansible playbooks for configs that have morphed only as required by breaking changes or features/security I want to add. I think the best way to start from scratch these days is kubeadm, and I think it should be fairly straightforward on arch or whatever distro you like.

Fundamentally my setup is just kubelet and kubeproxy on every node, the oci runtime (CRIO for me), etcd (set up manually but certs are automated now) and then some k8s manifests templated and dropped into the k8s manifest folder for the control plane on 3 nodes for HA. The more I think about it, the more I remember how complicated it is unless you want a private CA. Which I have and love the convenience and privacy it affords me (no CTL exposing domain names unless I need public certs and they’re public anyway).

I have expanded to 6 nodes (5 of which remain, RIP laptop SSD) and just run arch on all of them because it kinda just works and I like the consistency. I also got quite good at the arch install in the process.

If you’ve got >=3 machines and >=3 devices, I’d suggest at least strongly considering Rook. It should allow for future growth and will let you tolerate the loss of one node at the storage level too, assuming you have replication configured. Which (replication params) you can set per StorageClass in case you want to squeeze every last byte out for cases where you don’t need storage-level replication.

I’ve run my own k8s cluster for years now, and solid storage from rook really made it take off with respect to how many applications I can build and/or run on it.

As for backup, there’s velero. Though I haven’t gotten it to work on bare metal. My ideal would be to just use it to store backups in Backblaze B2 given the ridiculously low cost. Presumably I could get there with restic, since that’s my outside-k8s backup solution, but I still haven’t gotten that set up since it’s much more cloud-provider friendly.