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?
Why?
A discussion can’t happen.
And you don’t really expect everyone to be knowledgeable about every 500 aspects of every OS that can execute a program, do you?
If I was invited to a discussion round, I will obviously get myself up to date on the essentials.
But I already do sysadmin stuff at work, configuring multiple systems, administrating my home stuff the best I can.
I really don’t have the mental energy to keep up with an OS I currently only use as a server OS and as a (basically) gaming appliance.
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.
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?
You might want to catch up on a decade or so of Linux gaming progress before wading into a conversation about it with controversial takes…
Why?
A discussion can’t happen.
And you don’t really expect everyone to be knowledgeable about every 500 aspects of every OS that can execute a program, do you?
If I was invited to a discussion round, I will obviously get myself up to date on the essentials.
But I already do sysadmin stuff at work, configuring multiple systems, administrating my home stuff the best I can.
I really don’t have the mental energy to keep up with an OS I currently only use as a server OS and as a (basically) gaming appliance.
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.