Re: Steam Deck: good news for Linux gaming, bad news for Debian?
(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
Reply to: