My only fear: devs will push for "just enough" Steam Play compatiblity instead of a proper Linux port. A lot of big AAA games got post-launch Linux release. These can disappear
And yes, maybe it means we get less Linux native, I don't mind either. If it works on Linux and is supported on Linux, even if it's just via Wine, that's all I want.
(I genuinely can't believe I'm posting this comment completely un-ironically, but here we are).
Which is, I suspect, the reason why some gamedevs are hesistant. For Linux they not only need the QA track and development resources but might have to redevelop some engine customizations for Linux or the engine might not even support Linux at all. They're two steps removed from the people who would be responsible for making the engine work on Linux at all.
While internally each application will be a security nightmare, one-level up it's a godsend!
I wouldn't be surprised if that qubes-like OS will have a kernel that runs WASM natively. Emulation galore turtles all the way down
More emulation means more traction for Linux gaming. If windows can be dropped as a requirement for serious gaming, the Linux userbase will grow significantly, and this will help turn the tide.
Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. If you're shipping Linux binaries, you really should be linking statically! Any shared libraries you need, like OpenGL, you should load manually with dlsym.
A windows binary targeting Wine will not stop working just because some shared system library has been updated.
This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model.
Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.
That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
> That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems.
Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
Distributing the source code doesn't necessarily mean free software. Since those free software haters(idiots if you ask me), has no problem distributing game assets and compiled binary to the user, why is the source code exception?
If you are idiot enough to want the source code to be secret, just minify and uglify the source code. Uglified source code is as readable as compiled binary.
Advantage is that developers can package exactly those versions of the libraries that they tested with and know to be working.
Disadvantage is that if there's a security problem or bug in one of those libraries, you're dependent on the developer to release a new version of the Flatpak or Snap package.
Another disadvantage is that libraries can't be shared between applications, which increases hard drive and RAM usage.
A second important aspect of Flatpak and Snap packages, which is however not relevant to the discussion, is that the execution of the packaged applications is done in a sandboxed environment.
AppImage requires no runtime (or more accurately, it is part of the package) and is almost as portable as a statically linked binary, largely because it is (practically) a statically linked binary.
> I vaguely recall static binaries still depending on kernel versions, or something like that
This has to do with glibc. If you don't use glibc you don't really have to worry about it.
0) Application links to shared .so files in /usr/lib like libpcre.so. This is ordinary dynamic linking.
1) Application statically links all normal libraries like zlib and pcre, but still dynamically links to runtime systems like libc.so. I'll call this ordinary static linking. You can't "patch" a vulnerability in zlib without recompiling and redistributing, but on the other hand a zlib upgrade can't break your app either.
2) Application literally statically links everything (e.g. using musl instead of glibc). At this point the only dependency is the kernel you're running on. You need:
* obviously the kernel and architecture have to match. Can't run a 64-bit program on a 32-bit system without recompilation. Can't run a program compiled for linux on bsd.
* the kernel has to support whatever syscalls your application is using. If you're not using any fancy new functionality, you can get away with running on truly ancient kernels (e.g. 2.x linux)
* the kernel ABI must not break in the future. E.g. if linux changed the order of parameters to the open(2) call, that would be a breaking ABI change. Kernel devs are extremely careful to not do this, so I wouldn't worry about it.
The new packaging formats like Flatpak are based on containers. Your app thinks that it's using the "system" libpcre.so, but in actuality it's just being served the libpcre.so inside the container's filesystem (linked by the ld inside the container's filesystem, using the glibc inside the container's filesystem, and so on). So basically the same high level pro/cons as #2 above, but easier for users and developers.
Hardly.
It works extremely well for Linux distribution maintainers, and for the FOSS projects that work with this model in mind. Within the FOSS community, the platform model is excellent.
It doesn't work so well for proprietary application developers, who should just be using static libs because of this.
Of course... it's still a long and difficult road for Valve here, given how well emulation will need to work to accomplish this.
Some say there are games that have noticeable stutters or bottlenecks on Windows that doesn't share the same issues on Wine.
https://github.com/disks86/VK9
https://steamcommunity.com/games/221410/announcements/detail...
https://github.com/CnCNet/cnc-ddraw
https://github.com/CnCNet/ts-ddraw
Use case https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tib...
I remember that music! Good old days :)
I could not play Oblivion on Windows10 but worked on Wine for me.
* Ignores flags (so `steam --help` for instance just starts Steam the same way `steam` does)
* Ignores signals (including SIGTERM, I believe)
* Screws up my tiling window manager sometimes, so it probably ignores EWMH
I personally think Valve needs to just separate the core Steam functionality into some backend and allow users to write their own frontends.
===========
And now for an unrelated "Valve/Linux" rant while I'm here: Half-Life: Opposing Force has been unbeatable on Linux since its release. The final boss's death animation plays too quickly and the trigger to change to the next map never occurs. There's been an issue open on the ValveSoftware/halflife GitHub repo about this since 2013. And the real kicker? Someone (not a Valve employee) actually went through the source code and determined the cause of the problem[0]. It still hasn't been fixed.
===========
Screw it, I'll give you one more. Last time I checked, it was impossible to get Half-Life Dedicated Server running through steamcmd[1][2], because the necessary files never finished downloading. When I was trying to get this working, I eventually found a GitHub repo containing modified versions of some files that you could use to make steamcmd actually download everything. I was unable to find this repo again while writing this comment (but I didn't put that much effort into it).
</rant>
0. https://github.com/ValveSoftware/halflife/issues/917#issueco...
1. https://github.com/ValveSoftware/halflife/issues/928
2. https://steamcommunity.com/discussions/forum/14/129181688050...
https://github.com/FWGS/xash3d
It's also got an excellent Android port:
Even without emulation it is impressive how much of Steam's library is available on Linux.