It's Now Been Six Years Since Valve Began Rolling Out Steam For Linux

[silmeth]

Requiring publishers to submit LLVM IR binaries à la Apple, to future-proof their catalog against shifts in the PC and console industries. Want to support some amazing new machine? No problem, translate the IR down to machine code and go.

I can dream, right?

The problem is, LLVM-IR is not machine independent.

LLVM-IR allows inline assembly, which by definition is not portable. Also many languages that can target LLVM-IR, ie. C, C++, Rust, etc. themselves allow conditional code compilation depending on the target (#ifdefs in C-likes, #[cfg()] in Rust), etc., and also inline assembly.

LLVM-IR code is typically optimization-friendly representation of the program, but already in a target-specific, non-portable form (depending on hardware architecture + operating system), in general you cannot recompile it to another target, you need the original source code (and… the original source code also might have target-dependent parts that first need to be ported), so it’s not that easy.

Apple AFAIK uses fat binaries – binaries containing native code for all supported architectures. I believe that’s also what MS is doing with their UWP (although I am not sure). Android with Dalvik is something like what you describe, it has a platform-independent code that gets compiled to native during installation, and new architectures might be added without breaking any existing apps.

JVM bytecode or WebAssembly would be better for target-agnostic applications than LLVM-IR. But JVM bytecode won’t happen here, because Oracle (although Google with Android+Dalvik does exactly this, they have money for legal battles with Oracle) and because of the garbage collector cost of JVM bytecode (again, Google decided to pay that cost, but then again, they also allow native libraries, incompatible with platforms they were not compiled for). WebAssembly is an open standard and does not impose a GC overhead, but it will take a lot of time until we get good, production-proven, optimizing compilers for WebAssembly.

But I can imagine a future in which the regular scenario for a desktop program is that C++ or Rust is first compiled to WebAssembly using a LLVM-based compiler and that gets uploaded to repo (eg. distribution’s repo, or Steam), then on the user’s or repo’s server side it is again compiled, again using LLVM-based compiler, to target native code.

[dungeon]

Well, Valve did whatever they can i guess. I used WINE even before, so i can't count this Proton as a plus just as a bonus

But to be honest i had PS4 all these years too, so best games i played there really

[schmidtbag]

Wow time sure flies.

And yet, despite how much Valve has helped the Linux desktop (whether directly or indirectly), people still gripe about them because of closed-source commercial software.

Well, Valve did whatever they can i guess. I used WINE even before, so i can't count this Proton as a plus just as a bonus

Valve is a pretty substantial contributor to Wine/Proton. They didn't just integrate it with Steam and call it a day, they're actually helping.

[dungeon]

Valve is a pretty substantial contributor to Wine/Proton. They didn't just integrate it with Steam and call it a day, they're actually helping.

Cool, but i used WINE for games since i think 0.9.x versions back in year 2006. so it is not a new thingie to me

They should push for native games and users should consider this just as a bonus, as WINE and Proton won't ever be perfect really

[reavertm]

The problem with steam machines was that the only people who wanted them, wanted them as PCs, but valve sold them as pseudo consoles and made steamos a console only os instead of general purpose os. If they'd just made a proper operating system for them that works as PC just as well as it would as a console, it would've been a lot more successful.

It was poorly marketed too.

Marketing.. given its use of PC components, it was first and foremost fairly expensive for performance it offered in PC games (no targeted optimisations that consoles receive allowing them to run similary looking titles on weaker hardware).

[schmidtbag]

Cool, but i used WINE for games since i think 0.9.x versions back in year 2006. so it is not a new thingie to me

Understood; I wasn't suggesting there was anything new. My point was more that Proton isn't just simply a re-branded Wine. It does function a little differently, and it removes a lot of the headaches involved in trying to install Windows games on Steam without needing the Windows version of Steam, as well as any of those other hacks that may threaten your account. So, it is a little different than what you may be used to.

They should push for native games and users should consider this just as a bonus, as WINE and Proton won't ever be perfect really

I 100% agree, but, Proton is at least a step in the right direction to encourage people to ditch Windows. Alluding to what I was saying before, using Wine to play Steam games has never been the most user-friendly experience, and it also hurts the statistics of the Steam survey.
Incentivizing devs to port their games to Linux is just one of many objectives to improve the overall Linux gaming ecosystem. Through Proton, people (like myself) can fully ditch Windows with relatively minimal effort. Getting rid of Windows is a major step forward to show publishers that people would use Linux if it were more compatible.

So far, this is proving to be true - the Steam survey is showing Linux users on the rise since Proton was released. It's not a big improvement, but, Valve also hasn't done much advertising with this, either (nor should they, since it isn't totally stable). I'm sure there are thousands of Windows gamers open to using Linux who aren't aware of Proton.

Anyway, I've mentioned this in another thread but I'll say it again: I think the best course of action for Valve is to improve the profit margins of devs who focus on Linux compatibility. So for example, let's say Valve gets 30% of the revenue for every game sold. If a dev/publishers tries getting a game on the Proton white-list, Valve would reduce their cut to maybe 25%. If the game has a native Linux port but isn't very well optimized, Valve reduces their cut to 20%. If the game is ported natively and performs roughly as good as it does in Windows, Valve reduces their cut to 15%. It doesn't matter whether the game is sold in Windows or not, those percentages will drop regardless. The point is so the publisher doesn't feel like they're wasting time and money on porting, so even if the game never gets sold in Linux, their expenses are still covered from Windows users.

[moilami]

I am happy and I think over time Linux will become technically strong in gaming and challenge Windows. That does not mean masses will move to Linux, though.

[pmorph]

It's gonna be the king of irony if Proton ends up being "the way" to have stable games on linux. Given the linux userspace mess, I wouldn't be surprised.

With the ever icreasing rate of change in IT, it could be that solutions like proton end up being the sane way to run any application software at all on modern systems. That, or sticking to left behind, legacy tech.

[makam]

Six years in, are you happy with the direction of Linux gaming?

While really thankful to Valve for all they did I have to say no. Native linux games (e.g. ported, not proton supported) are ~50% chance of outright failing, streaming doesn't work between nvidia and AMD machines (linux to linux but also windows to linux). Proton is almost as bad hit and miss as the "native" games, although honestly I think it might be the ticket to get things in a better shape.

~50%? Wow , your luck is crap. For me, native games worked ~99%. The only game I had problems with was War Thunder and it got fixed. And a lot of those problems were due to my meddling.

[Almindor]

~50%? Wow , your luck is crap. For me, native games worked ~99%. The only game I had problems with was War Thunder and it got fixed. And a lot of those problems were due to my meddling.

Yeah, for me it's ~50% and most of the time they just crash. Now granted I am on Arch which is not officially supported but that still tells you how much of a mismatch game the library hell on Linux is. Most of the time the crash is something funny-stupid like dbus message format incompatibility (coz the game is set to listen on an ancient dbug interface version) or some steam-packaged library being compiled with some compile-time switch that won't work with a dependency library on the system etc.

Just, you know the usual linux library hell.