I use k8s at work and have built a k8s cluster in my homelab… but I did not like it. I tore it down, and currently using podman, and don’t think I would go back to k8s (though I would definitely use docker as an alternative to podman and would probably even recommend it over podman for beginners even though I’ve settled on podman for myself).

1. K8s itself is quite resource-consuming, especially on ram. My homelab is built on old/junk hardware from retired workstations. I don’t want the kubelet itself sucking up half my ram. Things like k3s help with this considerably, but that’s not quite precisely k8s either. If I’m going to start trimming off the parts of k8s I don’t need, I end up going all the way to single-node podman/docker… not the halfway point that is k3s.
2. If you don’t use hostNetworking, the k8s model of traffic routes only with the cluster except for egress is all pure overhead. It’s totally necessary with you have a thousand engineers slinging services around your cluster, but there’s no benefit to this level fo rigor in service management in a homelab. Here again, the networking in podman/docker is more straightforward and maps better to the stuff I want to do in my homelab.
3. Podman accepts a subset of k8s resource-yaml as a docker-compose-like config interface. This lets me use my familiarity with k8s configs iny podman setup.

Overall, the simplicity and lightweight resource consumption of podman/docker are are what I value at home. The extra layers of abstraction and constraints k8s employs are valuable at work, where we have a lot of machines and alot of people that must coordinate effectively… but I don’t have those problems at home and the overhead (compute overhead, conceptual overhead, and config-overhesd) of k8s’ solutions to them is annoying there.

Here’s a potentially unpopular opinion… Games that target the Proton API are actually native Linux games. Proton isn’t virtualization or emulation, it’s just an API that happens to be mostly compatible on both Windows and Linux. Other than the kernel itself, Linux has never had one true API to do anything… there’s always more than one option to target (as you note with your Wayland/x11 example, but also pulse, alsa, pipewire, the list is endless). Proton is an API that’s available on Linux, and programs that target the Proton API are Linux programs in every way that matters.

The question isn’t native vs proton. The question is whether proton is a good API. At the moment, it’s an API that offers pretty good cross platform compatibility with windows, which is hugely valuable to developers and they’re using Proton for that reason and even testing against it. That’s good for us as users and for gaming on Linux.

If Windows evolves their versions of the proton APIs in ways that break compatibility and are difficult to fix, we may find that game devs complain on our behalf to avoid breaking their Linux builds. If Proton begins to suck compared to alternatives, and enough people are playing games on Linux with Proton, devs will organically start to look at other porting options more seriously. But Proton is both a way to kickstart the chicken/egg problem, and itself may just actually be a good API to develop Linux games against.