Steam on Linux defaults to providing a container based standard Linux environment which is independent of the underlying OS, providing access to all the expected software libraries and OS calls that games need to run.
This is integrated into SteamOS. It’s also available via Steam on any other Linux distro. (And if you wanted to you could cut that part out and run it without Steam.)
When running Windows games it even runs Proton within this container environment.
That gives you a single very predictable and version controlled software environment.
Meanwhile Windows randomly deprecates stuff that somebody might have invested tons of development effort into (silverlight, mixed reality, etc)
When talking about a container environment you are talking about WINE, arent you?
But if we are talking about native developed games, how would that look?
That sounds to me like 1st priority-development will be continued using Windows as a base + DirectX and reliance that WINE will somewhat manage that.
How would native Linux look for game devs in terms of platform targeting?
No, Wine (and Proton) is a compatibility layer (API translation, etc). Containers is an isolation method which hides the details of the OS from the software and gives it a standardized environment.
No matter what Linux distribution you run Steam on, the only thing you need to do is to get the container system up and running. Once that runs, all software that runs in these containers will run on that device.
So something akin to flatpak/snap?
Isnt that the purpose and source of controversy vs distributing them the usual way of repositories?
Edit: Had some time to read the README.
Very interesting. But that sounds, like a vendor lock-in. Essentially devs are forced to use the Steam SDK to make it executable on Linux or face the issue of checking the compatibility of every distro, no?
No, the container environment uses default open source libraries. You don’t add any Steam dependencies to make software run in that environment. You can run it without Steam too. It’s just that Valve are the ones maintaining and updating this particular packaging of containers. When Valve releases new versions of their container (including updated default system libraries), you have to test compatibility with it or stick to using an older one. Similar to how Windows software versions would work best with different Proton versions.
You can use the Steam SDK when using it, and you can also choose not to.
Flatpack is a separate thing, which only handles Linux software within the regular desktop environment (a different method for packing software dependencies, managing system permissions, etc). The main difference is that Flatpack software can integrate with the regular Linux desktop environment, but the container based solution is fully separate from it (runs in gaming mode).
Sounds interesting and eases my concern about the dependency on large corporations.
PS: What I meant by comparing Flatpack with the packaging from the SteamSDK is the general idea behind it (e.g. containerizing and isolating from the OS).
So what if Steam stops development of the SDK or turns evil?
What other choices do devs have if they want to keep their systems compatible with all distros?
It looks to me as if you can either rely on proton/WINE or be stuck with the SDK if you run native.
I run headless debian VMs at home on a proxmox HV and another NUC with Debian that does Docker tasks.
My steckdeck runs the stock OS and am not scared to tinker within it.
Never assumed to be a pro and would consider an amateur at best that isnt scared to tinker.
It’s just that I prefer convenience most of the time.
So then. These are my cards. Explain what I learned wrong about the fractured linux ecosystem.
So far I know that Arch, Debian and RHEL the biggest distro families are.
Edit: Very helpful. Downvoting instead of telling me where I am wrong.
(Yes my comment was provocative but @AbsolutelyNotAVelociraptor@sh.itjust.works should just tell where I am wrong if they are so sure of themselve).
Who supports that?
At least Windows is only one plattform in comparison to the bazillion linux-distros.
Same issue devs face with consoles vs PCs.
Steam on Linux defaults to providing a container based standard Linux environment which is independent of the underlying OS, providing access to all the expected software libraries and OS calls that games need to run.
This is integrated into SteamOS. It’s also available via Steam on any other Linux distro. (And if you wanted to you could cut that part out and run it without Steam.)
When running Windows games it even runs Proton within this container environment.
That gives you a single very predictable and version controlled software environment.
Meanwhile Windows randomly deprecates stuff that somebody might have invested tons of development effort into (silverlight, mixed reality, etc)
When talking about a container environment you are talking about WINE, arent you?
But if we are talking about native developed games, how would that look?
That sounds to me like 1st priority-development will be continued using Windows as a base + DirectX and reliance that WINE will somewhat manage that.
How would native Linux look for game devs in terms of platform targeting?
No, Wine (and Proton) is a compatibility layer (API translation, etc). Containers is an isolation method which hides the details of the OS from the software and gives it a standardized environment.
https://github.com/ValveSoftware/steam-runtime
No matter what Linux distribution you run Steam on, the only thing you need to do is to get the container system up and running. Once that runs, all software that runs in these containers will run on that device.
So something akin to flatpak/snap?
Isnt that the purpose and source of controversy vs distributing them the usual way of repositories?
Edit: Had some time to read the README.
Very interesting. But that sounds, like a vendor lock-in. Essentially devs are forced to use the Steam SDK to make it executable on Linux or face the issue of checking the compatibility of every distro, no?
No, the container environment uses default open source libraries. You don’t add any Steam dependencies to make software run in that environment. You can run it without Steam too. It’s just that Valve are the ones maintaining and updating this particular packaging of containers. When Valve releases new versions of their container (including updated default system libraries), you have to test compatibility with it or stick to using an older one. Similar to how Windows software versions would work best with different Proton versions.
You can use the Steam SDK when using it, and you can also choose not to.
Flatpack is a separate thing, which only handles Linux software within the regular desktop environment (a different method for packing software dependencies, managing system permissions, etc). The main difference is that Flatpack software can integrate with the regular Linux desktop environment, but the container based solution is fully separate from it (runs in gaming mode).
Sounds interesting and eases my concern about the dependency on large corporations.
PS: What I meant by comparing Flatpack with the packaging from the SteamSDK is the general idea behind it (e.g. containerizing and isolating from the OS).
You don’t need to use Steam to run games though…?
So what if Steam stops development of the SDK or turns evil?
What other choices do devs have if they want to keep their systems compatible with all distros?
It looks to me as if you can either rely on proton/WINE or be stuck with the SDK if you run native.
Proton often works better than native Linux versions of the same game.
Just use Proton. Seriously, if you haven’t gamed on Linux in a long time, it’s mind blowing how well it works.
Like I mentioned: I am gaming quite a bit (lately more on it than on my regular PC) on my SteamDeck.
Tell me you know don’t jack about linux without telling me you don’t know jack about linux in 25 words or less.
Well then: Clear it up.
I run headless debian VMs at home on a proxmox HV and another NUC with Debian that does Docker tasks.
My steckdeck runs the stock OS and am not scared to tinker within it.
Never assumed to be a pro and would consider an amateur at best that isnt scared to tinker.
It’s just that I prefer convenience most of the time.
So then. These are my cards. Explain what I learned wrong about the fractured linux ecosystem.
So far I know that Arch, Debian and RHEL the biggest distro families are.
Edit: Very helpful. Downvoting instead of telling me where I am wrong.
(Yes my comment was provocative but @AbsolutelyNotAVelociraptor@sh.itjust.works should just tell where I am wrong if they are so sure of themselve).
The other answer from @Natanael@infosec.pub tells you that now
Noticed and will be reading now.