(Disclosure: I work for Collabora, and I'm currently working on the Steam Runtime.)
On Sat, 17 Jul 2021 at 13:48:32 +0100, Samuel Henrique wrote: > As some of you already seem, we have very good news for the Linux > gaming community, although somewhat bad for Debian: ... > https://www.steamdeck.com/en/tech > Operating System: SteamOS 3.0 (Arch-based) I think this is still good for Debian, although arguably less good for Debian than it might have been if it was directly based on Debian like the earlier-generation Steam Machines were. Rather than thinking "ugh, this isn't Debian", I'm thinking of this as "good, this is modern Linux", and in particular not Windows! SteamOS 2 is stuck on Debian 8, which is a long way out of support at this point, so SteamOS needed a significant amount of work to catch up with the last ~ 6 years of development somehow. You might notice from https://repo.steampowered.com/steamos/dists/clockwerk/ that packaging metadata for a Debian-9-based version appeared at one point, although I don't think any packages appeared in that repository. Obviously, as a Debian developer, the route I would have tried first for that work would be to rebase onto a newer version of Debian - either a stable release, or testing, or their own testing-like snapshots of unstable like Ubuntu does - but Valve have chosen to rebase on Arch instead. I am not the right person to say why, sorry. Arch and Debian are not actually a million miles apart: they're both package-based binary distributions in a nearly-FHS directory layout (unlike for example NixOS), using glibc and GNU userspace (unlike for example Alpine), booting with systemd by default (unlike for example Devuan), community-maintained rather than driven by a single corporate sponsor, with divergence from upstream generally being treated as a bug but tolerated if there's a good enough reason why it's necessary. (Of course, there are other distros that I could say similar things about, Debian's threshold for what is a good enough reason for divergence from upstream tends to be lower than Arch's, and we make different technical decisions in various places.) In terms of the upstream versions involved, Debian 11 is more like Arch than it is like Debian 8 (although obviously the packaging and OS layout are rather different!) so this still seems better for Debian in terms of having the games that run successfully on the Steam Deck also run successfully on Debian (and Ubuntu, and Fedora, and other modern distributions). I would hope that if Valve later decide that they need to be basing a future SteamOS release on something that has periodic stable releases and a security update story other than "upgrade everything", the obvious choice would be Debian - but we'll have to see what happens. > the gaming side of Linux still > receives major improvements with new releases of things like Proton You might have noticed that https://www.steamdeck.com/en/developers emphasizes Proton over native Linux games at the moment, as a way to get a broader range of games available, and the publicity videos seem to be mostly (entirely?) things like Jedi: Fallen Order that are Windows(-and-Proton)-only. Valve have said they're looking into getting a solution for Windows "anticheat" mechanisms under Proton, which are one of the biggest gaps in what Proton can do at the moment. Anything they do to improve Proton is going to benefit Arch and Debian equally. Current versions of Proton run in a container that is mostly Steam Runtime 2 (+ graphics stack from the host system). Steam Runtime 2 is very heavily based on Debian 10, with selected packages like SDL backported. A Steam Runtime 3 prototype based on Debian 11 exists, although there's no public release of it at the moment; if Proton starts requiring newer versions of something, it would be natural to assume that the priority of getting that prototype released will suddenly go up :-) Similarly, it is possible to set native Linux games to be run in a container via the "Steam Linux Runtime" compatibility tool, although it isn't the default. Until recently, this was Steam Runtime 1 (based on Ubuntu 12.04) plus the graphics stack from the host system. As of a recent update, it's changed to Steam Runtime 2, with a few libraries taken from Steam Runtime 1, and the host system's graphics stack as before - so a combination of a Debian derivative, an old Ubuntu derivative and the host system. I'm hoping that will result in better compatibility for games that implicitly assumed they were actually running on something newer than Steam Runtime 1. These benefit ordinary Linux systems like Debian just as much as the Steam Deck - perhaps more, because if the Steam Deck is running an Arch derivative, it will always need to be up-to-date (because that's the only way to get security updates in a rolling release), whereas non-rolling-release systems can easily have libraries that are older than those in a runtime container. I'm also hoping that in future it'll be possible for native Linux games to be flagged as targeting a newer Steam Runtime container, so that we can escape from the assumption that libraries from 2012 are sufficient, although this isn't currently possible and I certainly can't make any promises (most of the necessary work for this would have to happen in the proprietary parts of Steam, rather than in the Steam Runtime). You'll notice that the Steam Runtime is *not* based on Arch, and also not based on testing/unstable: a constantly-moving rolling release is the opposite of what's desirable here. The direction I'm trying to go in with the Steam Runtime is that each native Linux game and each Proton version can rely on everything staying at a particular version, except for the graphics drivers (which need to be up-to-date in order to support new hardware) and their dependencies such as glibc (which in practice tend to be very good at staying backwards-compatible). There's more on this in: https://github.com/ValveSoftware/steam-runtime/tree/master/doc > The reasons for the switch have not been publicized, but I think we're > safe to assume it's because Debian is not fit for the majority of the > desktop/gaming users, at least not officially (since testing is not a > supported release). I remember having some issues due to SteamOS being > based on stable. These are the people who need to be able to run the > most up-to-date packages, especially drivers and kernel (backports is > not always there). The issue with SteamOS 2 is less that it's based on stable, and more that it's based on a very old stable. Debian stable is up to 2 years behind, but for SteamOS 2 it's more like 6 years. For Debian stable, yes, hardware support can be a problem, particularly at a late stage in the release cycle; there have been various plans in the past to mitigate that, including backports, making testing double as an Arch-like rolling release ("constantly usable testing"), and even on at least one occasion an "-and-a-half" release that bundled an updated kernel and some updated drivers, like Ubuntu LTS's HWE (hardware enablement) updates. Anyway, enough email-writing, time to get back to Assassin's Creed Odyssey, under Proton, in a Debian-10-based Steam Runtime 2 container, on a Debian 11 machine :-) smcv
