SteamOSとArch Linuxの関係についての迷信は、少し正しておく必要がある。この二つはイコールではないし、SteamOSを使っているからといって"I use Arch btw"と言えるわけではない。
最近Arch LinuxでGalgameを遊んでいたら、ほぼ同じテスト条件なのに、SteamゲームのProtonがわけのわからないクラッシュを連発して、もううんざりした。Debianに戻したら全部問題なくなったので、この問題について話してみる。
愚見ながら、Arch Linux & CachyOSのようなローリングリリースはゲーム用途には向いていない。半ローリングリリースのFedora ＆ Bazziteもだめで、百戦錬磨のDebian StableかUbuntu LTSでないと信頼できない。昔の自分がよくArch Linuxでゲームする気になったものだと思うが、今はもうDebianを使っている。
もう一つ考慮すべき点は、ProtonDBへゲーム互換性を報告するとき、追跡可能で安定したシステムバージョンを使いたいということだ。テストプラットフォームは安定しているべきで、常に変化し続けるシステムであるべきではない。
SteamOS公式サイトの資料によれば、SteamOS 3.0以降が実際にArch Linuxをベースに開発されているのは確かだ。しかし、SteamOSはimmutableなシステムであり、ユーザーはシステムファイルを変更できないし、変更すべきでもない。システムのOTA更新のたびに新しいimageをダウンロードして旧版を上書きする。それにSteamOSはローリングリリースではなく、システム更新のスケジュールはValveという商業企業が決めるものであって、Arch Linuxのローリング更新ではない。
Valveには自社のSteam Deck & Steam Machineの製品体験を守る必要があり、参照可能なコンソールプラットフォームになることを目指しているので、更新をあまり急進的にすることはできない。たとえば2026年の安定版SteamOS 3.7.8では、デスクトップモードのKDEデスクトップはまだ5.27系だが、Arch LinuxのKDE 6.0はすでに2024年にリリースされている。SteamOS 3.8.0のKDE 6はいまもベータ版のままだ。現在のSteamOSのメイン画面コンポジタ、Gamescopeの戦略は、XWaylandでX11ゲームを動かしつつ、WaylandのHDRサポートも享受するという継ぎ接ぎの戦略によって成り立っている。将来的に純Waylandへ進めるかどうかには、大きな疑問符が付く。
Valveは「システム全体」としてのSteamOSとSteamクライアントが安定していることを確認してからでなければ、更新をリリースできない。
一方、Arch Wikiによれば、Arch Linuxのソフトウェア更新スケジュールは固定されていない。各ソフトウェアにはそれぞれ異なるメンテナーがいて、オープンソースコミュニティが安定したと判断すればリリースされる。全民公募テストでbugを拾うようなもので、テスト期間は十分に長くない。
このやり方の利点は、問題があればすぐ発見して修正できることだ。欠点は、現在のシステムが完全に安定しているかどうかを誰も保証できないことだ。変数が多すぎる。
Arch Linuxはインストール直後の状態ではそもそもグラフィカルインターフェースがない。いわゆる「デフォルト値」は存在せず、一つの「全体」もないので、全面的にテストしてから更新をリリースすることは難しい。小さなパッケージ更新一つでKDEデスクトップが吹き飛ぶ可能性もある。
Arch LinuxにおけるSteamクライアントは、オープンソースコミュニティがValveのリリースしたインストールパッケージをもとに改変したものだ。Steamクライアント本体にはProtonの実行を満たすための独自Runtimeがあり、できるだけOSのlibraryへ依存しないようにしているとはいえ、Arch LinuxシステムのコンポーネントはやはりSteamクライアントに影響する。ランダムに問題が出るのだ。
リリースモデルから見ると、SteamOSは数あるローリングLinuxディストリビューションよりもずっと安定している。SteamOSに近い体験を持ちながら、なおかつ安定しているローリングリリースを実現するのはかなり難しい。
現時点のSteamOSはまだ特定の数機種のハードウェアにしか対応していない。もし将来、本当にオープンソースの汎用x86イメージファイルをリリースしたら、彼らのGithub issue ticketは爆発的に増えるのではないか……。
