Staudey For what it's worth, I still think these days it's better, and less error-prone, to disable the "Use native runtime" option.
Anecdotally, I'd have to disagree. With the exception of the odd Mesa issue and library mismatch, I've never had to disable LSI to get a game to work. That's in over 5 years on Solus. And I've tested almost everything in my library at this point. I haven't even needed to force 32bit any time recently. If it doesn't run with Native, for me it also failed to run with their runtime.
[unknown] LSI is not well maintained, and Valve / Steam have a reason to work on the same issues LSI solved with their SteamDeck releasing.
You seem to be under the impression that there's something about LSI which needs to change on a regular basis and this really isn't the case. The only thing we've really needed to deal with is whitelisting or blacklisting the odd library when Valve changes the requirements for their Runtime. Almost all of the maintenance is in the native libraries themselves and the deps we require for our steam
package.
I also think you have a bad assumption here: Valve's focus is on Proton, not native Linux applications. They see it as a way to sidestep all of the various compatibility issues with libraries and to exploit their Windows library for other platforms. And in that scenario, our Proton compatibility with native libraries has worked with everything I've thrown at it, provided it scores well in the ProtonDB in general
Yes, so that every Arch user in existence doesn't spam Steam with bug reports for things that aren't their fault. On Solus, we take responsibility for our runtime compatibility and it yields very few issues the vast majority of the time.
kaktuspalme I agree on that, I had more errors with it being on, some games didn't work at all.
Bug reports welcome. This is almost always down to a missing library or one that we need to blacklist from libintercept because the vendored version needs to be used. These are quite easy to fix.