Well, I consume more open source software that I will ever produce, so I am in a dept to the community. If it means working a bit more to make my contribution useful to others and fit it into the bigger whole, I will gladly do so.

Valve contributed to Linux before, so the fact that they don’t have any direct upstreaming plans right now indicates that something is causing friction.

I would avoid reading too much into it. They and their developers are still contributing on other stuff. Also when working together, there will always be some friction, in any public collaborative project ever.

Nothing of this is a burden, it is just part of being a good contributor that reads and follows the rules. Contributing is pretty easy, when you have read and are following the guides. If you haven’t already, you should give it a try.

I am pretty sure that this isn’t the first contribution of Valve to the Linux kernel. It sounds more to me like “works for me, don’t care about others” attitude. Which is not a good attitude to have when working in any collaborative project. (Not necessarily against the developers, could also be management.)

Well, it is about code quality. And the same codebase should work on different hardware, which is not something that is required in downstream forks.

But it is sad to see that the driver was submitted in the past, is still actively developed and improved, but there doesn’t seem to be plans of submitting them again.

Also I don’t think that a platform driver is so complicated that it requires such a long time for mainlineing. It not a filesystem or VPN.

On a more interesting topic, the SteamDeck platform drivers are still not merged into mainline Linux… :'(

Last news about it: https://www.phoronix.com/news/Steam-Deck-Platform-Driver-2024

I started using Fedora Silverblue on a tablet, seems to work fine so far, but requiring a reboot in order to install new system packages is a bit cumbersome and the process itself takes a while, but ordinary Fedora also doesn’t win any races when asked to install a new package

I think switching to FCOS or Flatcar on servers that just use containers makes sense. Since it lessens the burden of administrating the base system itself. Using butan/ignition might be unusual at first, but it also allows to put the base system configuration into a git repo, and makes initial provisioning using ansible or similar unnecessary. The rest of the system and services can be managed via portainer or similar software.

I also do not have long term experience with FCOS, but the advertised features of auto-update, rolling-release, focus on security and stability makes it a good fit for container servers, IMO.

An alternative to Debian on servers might also be Apline Linux. Which also has more a focus on network devices, but some people use it on a desktop as well.

If you have many different systems, and just want to learn to operate them all, maybe NixOS might be interesting. Using flakes, you can configure multiple machines from just one repo, and share configurations between them. But getting up to speed on NixOS might not be so easy, it has a steep learning curve.

Only really nice when not CLA is required and every contributor retains their copyright. Ente doesn’t seem to require a CLA.

Otherwise it allows the owner to just take the changes from their contributors and change the license at a later date.

Or other standard archiving formats like WARC.

There also is https://github.com/ArchiveBox/ArchiveBox which looks a bit similar.

It contains only code, no assets or textures.

I mod my games on my PC and sync it to my SteamDeck. I also sync the save files back and fourth, to continue playing on different devices. Mostly non-steam games.

I also sync my eBook collection to my eink reader with syncthing.

Everything is also mirrored to my always-on NAS, so syncing always works.

Environment variables isn’t a concept of just docker, but general native app programming. So look into the docs of your language.