Valve's Steam Frame Is Reinventing Arch Linux On ARM

SYNTHÈSE STRUCTURÉE

Contexte : le Steam Frame et l’essor du jeu ARM Linux

L’intervenant explique que le Steam Frame est le seul nouveau matériel Valve non encore sorti, et qu’il l’intéresse surtout parce qu’il s’agit d’un appareil ARM tournant sous Linux. Il rappelle que « avant il y a quelques années, on ne faisait pas ça », mais que des projets comme Box64 et FEX (sponsorisé par Valve) ont changé la donne. Il mentionne même des projets comme GameNative et GameHub sur Android, qui permettent de jouer à ses jeux Steam directement sur son téléphone, sans streaming, en exécutant localement les binaires Windows via ces couches de traduction.

Le problème de base : Arch Linux ne supporte pas ARM officiellement

SteamOS est basé sur Arch Linux, mais Arch Linux n’a pas de port officiel pour l’architecture AArch64 (ARM 64 bits). Le projet Arch Linux ARM (ALARM) existe, mais l’intervenant le qualifie de « pas exactement bien maintenu ». Il précise que « baser quelque chose sur ALARM, c’est un peu comme tout faire soi-même ». Un effort de portage existe dans le mainline, mais il est « tellement, tellement loin d’être quelque chose sur lequel on voudrait construire un SteamOS ».

HoloCore : le port AArch64 pur d’Arch Linux

Collabera a publié un billet de blog détaillant la construction d’un port AArch64 d’Arch Linux pour HoloCore. L’intervenant cite le billet : « Valve a utilisé une version adaptée d’Arch Linux dans ses produits. Chez Collabera, nous avons travaillé avec Valve sur HoloCore, un port AArch64 pur d’Arch Linux, pour servir de base à l’OS du Steam Frame. » Ce n’est pas un simple fork : l’objectif est de pouvoir rejouer l’intégralité de l’historique des paquets Arch Linux pour AArch64, à n’importe quel point dans le temps.

Deux défis majeurs : compilation croisée et CI reproductible

Le billet de Collabera identifie deux problèmes principaux :

1. Construire des binaires pour une architecture étrangère (non x86-64) à partir des versions récentes des paquets Arch.
2. Créer un système d’intégration continue (CI) capable de déterminer les bonnes dépendances au fur et à mesure qu’Arch Linux évolue (rolling release).

L’intervenant insiste : « Ce n’est pas juste une question de prendre les dernières versions et de compiler, et tout fonctionne. » Il faut notamment recalculer l’ordre de construction de l’arbre des dépendances, car les commits poussés dans le dépôt Git d’Arch ne sont pas toujours dans un ordre valide pour une reconstruction.

Le problème de la cible mouvante (rolling release)

Arch Linux étant une distribution rolling release, les paquets et leurs chaînes de dépendances avancent constamment. L’intervenant explique : « Arch Linux ne va pas s’arrêter de faire ce qu’il fait. Si vous voulez construire sur quelque chose de plus lent comme Ubuntu ou Debian, ce problème n’existe pas. Mais Arch Linux, c’est une cible en mouvement permanent. » Il donne l’exemple de Rust : pour reconstruire Rust 1.91, il faut d’abord avoir 1.90, qui nécessite 1.89, et ainsi de suite jusqu’à la version utilisée lors du bootstrap. Il prévient : « Je sais ce que vous allez dire. Rust, c’est mal. Ce n’est pas un problème de Rust. Rust n’est qu’un exemple. »

Les transitions de noms de bibliothèques partagées (so-name)

Un autre casse-tête technique concerne les transitions de so-name (shared object names), comme libc.so.6. L’intervenant détaille : « Quand une bibliothèque comme ICU ou GPGME (nécessaire à Pacman) change de version, le gestionnaire de paquets existant dépend de l’ancienne version, mais le paquet que l’on construit doit dépendre de la nouvelle. Il faut donc que les deux versions soient disponibles simultanément sans conflit. »

Le temps, ennemi numéro un

Rejouer un historique de construction vieux de plusieurs mois ou années pose des problèmes concrets : sources déplacées, projets migrés vers d’autres hébergeurs, checksums Git modifiés (passage de hash courts à longs), etc. L’intervenant résume : « Le temps est le plus grand ennemi quand on essaie de rejouer une séquence de construction historique. » Il ajoute que, heureusement, « en tant qu’utilisateur, vous n’avez pas à gérer ça » grâce au travail des mainteneurs de distribution.

Problèmes d’infrastructure modernes

Les pipelines CI doivent aujourd’hui faire face à des limitations de débit et des blocages de la part des services amont, qui se défendent contre les bots et les crawlers IA. L’intervenant mentionne aussi les paquets « simplement incompatibles avec l’architecture AArch64 » et nécessitant des correctifs supplémentaires, sans oublier « les cas particuliers et les erreurs humaines ».

L’outillage développé par Collabera

Pour résoudre ces problèmes, Collabera a développé un ensemble d’outils capables de :

• Calculer l’arbre de construction complet,
• Résoudre la chaîne de dépendances,
• Rejouer les constructions d’Arch Linux depuis un bootstrap initial jusqu’à un instantané donné du dépôt Git,
• Inclure toutes les reconstructions intermédiaires nécessaires.

Ce système est basé sur GitLab CI et permet des constructions reproductibles. L’intervenant précise que « l’outillage n’est pas encore prêt à être publié, mais l’équipe y travaille ».

Vers un suivi en continu d’Arch Linux

L’étape suivante est de faire passer ce système d’une reconstruction historique à un suivi en temps réel d’Arch Linux. L’intervenant cite le billet : « Ce travail servira de base à un système CI en fonctionnement continu, capable de suivre Arch Linux lui-même. Nous travaillerons avec le projet amont Arch Linux pour aider aux efforts de portage vers AArch64. » Il commente : « Comprenez-vous pourquoi les gens disent que c’est la mort d’ALARM ? Cela va dans la direction d’un support ARM64 complet dans le projet principal. »

Une approche ouverte et communautaire

L’intervenant salue la méthode de Valve : « Ils auraient très bien pu faire leur truc en interne, tout garder propriétaire. Au lieu de ça, ils vont voir Collabera et disent : construisez ça, et ne le construisez pas que pour nous. Laissez tout le monde en profiter. » Il mentionne aussi les financements de Valve pour KDE, FEX, et d’autres projets open source. Il conclut : « La façon dont Valve agit dans l’espace open source, c’est comme beaucoup de gens aimeraient que les entreprises se comportent. »

CONCEPTS CLÉS

• AArch64 : Architecture 64 bits d’ARM, également appelée ARM64. C’est la cible du port HoloCore.
• HoloCore : Nom interne du port AArch64 pur d’Arch Linux développé par Collabera pour Valve, destiné au Steam Frame.
• ALARM : Arch Linux ARM, un projet communautaire de portage d’Arch Linux vers ARM, jugé mal maintenu par l’intervenant.
• So-name (shared object name) : Identifiant d’une bibliothèque partagée (.so), dont les transitions de version peuvent casser les dépendances lors d’une reconstruction.
• Rolling release : Modèle de distribution où les paquets sont mis à jour en