My post was not about Steam, I think we all wholeheartedly agree. My comment was more about the swap to Proton coming out of the blue, and that’s on the developer. It’s so tricky with live services tho, how to balance the level of implementation effort vs platform support, I get it - but not blindside those that want that native Linux client support (because that’s what they signed up for)
And I agree on the 1080p/720p argument! The what if can be: “Ok, time for me to peace out”.
Except you’re actually getting A. You buy a license for Linux, it can run on Linux. Why does it matter how it is achieved? As long as you’re getting full support, it doesn’t.
Or look at it another way: If you didn’t know Proton existed you wouldn’t even know it’s in use. All that matters is that it works.
If I bought the native client, I’d want the native client for that… you can’t override personal preference, it isn’t yours - right? As in, you have yours, and I have no right to tell you what matters or doesn’t matter to you.
Right but the fact of the matter is you didn’t. You bought a usage license for a software and platform, not the specific method how it is delivered.
The license entitles you to use the software, and it entitles you to support on one or multiple specific platform(s). Nowhere in the license agreement would it say anything about how that is achieved, because it doesn’t matter from a product perspective. What matters in terms of the contract is that a) it works and b) if it doesn’t work that you can receive support.
It’s not a matter of opinion, it’s a matter of the contract you made when you bought the license. And if that license doesn’t fit your preferences, you bought the wrong product.
Now that just sounds like “buying isn’t owning…” /jk
I think this is the whole crux of the issue. If they decide to not support Linux anymore, and pull a Rockstar move with the anticheat lock-down to Windows only, you bought the wrong product.
Ok ok…Very fair comment. I got lost in my own head a bit. He lost access to the method of accessing the game that he preferred and paid for.
I don’t notice much difference between proton and native myself, other than I have to go edit the preferences to tell it to use proton. It’s not much of a loss to me nor do I have a preference either way. I haven’t noticed proton games running any worse.
I still dislike the principal removing a feature after sale, though I admit in this case it’s of little consequence.
You know, when this happened with Rust and/or Rocket League, Valve honored refund requests regardless of the player’s play time and ownership time. The big deal in that case was that the developers also used anti-cheat that they refused to make exceptions for Proton and such. If the game doesn’t use anticheat or anything like that, then I would just use Proton. I have a few games that work better in Proton than natively.
IMO Valve should just adopt AppImage (or make their own package format) to solve the dependency problem. As I said above the Steam Runtime just doesn’t cut it. It’s nice that it’s there but when games break even with it, then what’s the point.
An AppImage can be run even after years when packaged properly, and it is updateable (even if it weren’t, binary patching and delta-updates have been solved a while ago). Like… literally, I just ran an AppImage that was built in 2019 and it still works the same way it did at the time.
AppImage is a fairly small project even after all these years so they could use some support. Especially the integration into the desktop is still a bit rough at times (AppImageLauncher exists but it’s basically a one-man-project and has various rough edges).
Flathub at least has actually no policy on how long old package versions are retained, so in theory it is possible for older platform SDKs to just disappear, which would make anything that depends on them impossible to install. And that of course is an issue when the specific problem you’re trying to tackle is that your applications never get rebuilt and therefore require ancient dependencies.
And besides that, there’s not really a benefit to doing it with Flatpak over AppImage. When you require 20 different versions of a dependency for 20 different games then the whole idea of Platform SDKs getting used for multiple applications goes down the drain and you require the same amount of disk space (Flatpaks might actually require more because AppImage is using SquashFS and compression).
Also, Flatpaks due to their nature inherently allow downgrading of packages, which game developers might not want for one reason or another. So Valve would also have to prune their Flatpak repository of “unwanted” older versions as well.
And then there is also the issue with authentication on said repo. I don’t think Flatpak repos allow any kind of authentication so anyone with the repo URL could just download any game at any time, and not every game requires Steam to run, which in that case would make them effectively free for grabs.
I think AppImages in this case are just easier to control. You send a file to the client and that’s it. For updates you can either ship an entire new AppImage, binary-diff-patch it, or use AppImage’s built-in update mechanism.
Or in simple terms: Flatpaks aren’t great for an environment where the applications are never updated.
Personally I believe the answer forward lies with QEmu, a minimal Linux build and a minimal system that brings up Mesa running on Venus. After that, load whatever game you want on top of it.
File overhead: less than 50MB
Performance overhead: less than 10%
Compatibility levels: