What does HackerNews think of steam-runtime?

> Where is it written that steam-run will magically execute most binaries without patching them?

Somewhere in here: https://github.com/ValveSoftware/steam-runtime

:p

But I do get what you're saying. Once Flakes are default, I hope people start a proper push to clear up documentation and streamline the development process. The end-result is amazing, and the perfect OS/packaging system for my needs. The means of getting there... need a lot of work. I'm along for the ride either way.

I think they have something a bit like a container built into Steam: https://github.com/ValveSoftware/steam-runtime

> Game developers would be fine to target a single distro like Ubuntu 22.04.

Valve has its own container-only Linux distribution, the "Steam Runtime" (https://github.com/ValveSoftware/steam-runtime ); especially for games distributed on Steam, it probably makes more sense to target that distribution instead of Ubuntu.

FWIW, these days Valve tries to solve same problems with their steam runtime[0][1]. Still doesn't seem easy, but looks like almost workable solution.

[0] https://github.com/ValveSoftware/steam-runtime

[1] https://archive.fosdem.org/2020/schedule/event/containers_st...

I think your mistake was that you failed to account for the cultural differences between Windows and Linux users. For most Linux users and Developers a bug report is a positive thing rather than just a cost. Linux users are used to being more involved in the bug reporting process, and that includes reporting issues early and with more details - often even things they already figured out how to fix for themselves.

If you are being overwhelmed by bug reports from Linux users the Solution is to let those users triage, categorize and maybe even fix issues amongst themselves by having a publicly acessible tracker. Just like with forums for your game, you might even find people that will moderate those bug trackers for you. Valve realized this early in the Steam for Linux beta and have been using GitHub issues [0] for all of their Linux ports.

As for the differences between Linux distributions, I think the concerns are greatly overblown. The biggest difference between Desktop Linux distributions boils down in the versions of various libraries that they ship. For most of those you don't need to care at all and should ship your own version (or use the Steam Linux Runtime [1]). Base system libraries (glibc, OpenGL, Vulkan, audio) that you can't ship (because they contain hardware specific code that needs to get updates even after your game is EOL, or for other reasons) tend to provide strong backwards compatibility so you only need to target an old enough version to cover all the Linux distributions you want to support. A complicated one is the C++ standard library since some graphics drivers will depend on that - I recomment statically linkingyour own version and not exporting/importing any C++ symbols in your program.

I agree with others here that it is fine to only guarantee support for a limited set of Linux distributions (e.g. current Ubuntu LTS). However you should not consider reports from other distributions as a nuisance but rather as an early warning system or "linter" that will let you know about potential problems that users on your supported distribution (or even your users on other operating systems) may encounter in the future.

Next you can have various windowing systems, window managers and audio systems (even on one Distribution). Just ignore those: Don't interface directly with Xlib or pulseaudio but instead use a proven abstraction that takes care of the different quirks for you: SDL. That is, assuming you are not already using an engine with mature Linux support. Even if there is a quirk not handled in SDL, your users now are empowered to debug SDL themselves and fix the issue there, benefitting everyone. SDL will also make it easier to support future systems: if you never talk to Xlib and GLX directly, SDL can give you Wayland support for free.

Finally you have drivers. This isn't really much different than under Windows. Like with Linux distributions, issues with one driver often point towards things that just happen to work correctly in another vendor's driver but could break in the future. Having testing on more drivers is a good thing. Compared to Windows however, there is one big advantage: With the exception of Nvidia (and the proprietary AMD driver, but no need to care about that one) you (and savy users) have full source access to those which makes debugging some issues a lot more feasible. But further than that, they are also developed in the open with a public bug tracker [3] which gives you direct access to the developers. You can even chat with them on IRC if you like - just make sure that you are not wasting their time any more than you consider your users are wasting your time by reporting bugs.

I have also seen many concerns in this thread that bad reviews from Linux users will tarnish their score. First, realize that Steam reviews are always relative compared to expectations. If you manage those expectations, you can limit negative reviews - that goes for Linux users just as for anyone else. But Linux users can also help your game by recommending it to others. While the same is true for Windows users, those initial Linux users are easier to reach because there is less market saturation (especially in some genres). Using just the raw Linux sales percentage does not necessarily give you a full view of what sales you have gained by releasing a Linux port. To be fair, there will also be Linux customers that would have bought the Windows version, but either way % sales and revenue impact is not a 1:1 relation.

In conclusion, I think the main problem Windows developers face when targetting Linux are not technical issues (which there are of course) but one of cultural differences. Once you overcome those and learn how the Linux ecosystem works, you can use it to your advantage.

[0] https://github.com/ValveSoftware/steam-for-linux/issues

[1] https://github.com/ValveSoftware/steam-runtime

[2] http://libsdl.org/

[3] https://gitlab.freedesktop.org/groups/mesa/-/issues

No, Steam runtime: https://github.com/ValveSoftware/steam-runtime

When your game runs under Steam runtime, the real distribution is (almost) irrelevant - everything in your address space is supplied by the runtime, the things you get from the host system is the kernel/kernel modules and services you talk to via IPC (i.e. X11/Wayland, Pulseaudio).

It solves the problem of what version of what library is installed (if at all, maybe user removed it as "bloat") on the host system. You get known set of binaries that you can test against / coherent SDK target like with Windows or Mac.

Valve seem to have been addressing that with their runtimes.

See https://github.com/ValveSoftware/steam-runtime

There is the steam linux environment [1] which is pretty standard for native linux builds on steam. And that works independently of the distribution steam is actually installed on. I think it should be possible to use it without steam too..

[1] https://github.com/ValveSoftware/steam-runtime

Target the steam runtime. All popular distros will either support it out of the box or have an overlay to do it. And it doesn't change very often.

Open source is a million times easier. Your source is available. It's up to the distro's maintainer of your package to deal with compiling and binary compatibility.

https://github.com/ValveSoftware/steam-runtime

This isn't what the parent meant. He's talking about this: https://github.com/ValveSoftware/steam-runtime