Ubuntu et fin du 32 bits : Valve calme le jeu à son tour
Tout va bien... pour l'instant
Le 27 juin 2019 à 15h35
6 min
Logiciel
Logiciel
Après certains aménagements annoncés par Canonical suite à sa décision radicale sur le 64 bits, Valve réagit à son tour. L’éditeur explique pourquoi, même en l’état, la transition sera délicate.
Rappel des faits. Canonical a annoncé il y a une dizaine de jours qu’à compter de la prochaine Ubuntu (19.10 en octobre), plus aucune version 32 bits du système ne serait proposée. La décision rejaillit sur les variantes officielles et les distributions Linux basées sur Ubuntu, notamment Mint. Le changement est donc important.
Plus précisément, l’éditeur annonçait ne plus vouloir faire aucun travail sur le moindre paquet 32 bits. Pour que le support puisse néanmoins se poursuivre, Canonical avait décidé qu’Ubuntu 19.10 et les versions suivantes intégreraient les moutures 18.04 des paquets 32 bits, afin qu’ils bénéficient du support de cinq ans de cette version LTS.
Très insuffisant selon de nombreux développeurs, dont ceux de Steam et de Wine. Dans notre premier article, nous évoquions la possibilité d’un rétropédalage tant les réactions étaient vives. Ce qui se produisait finalement quelques heures plus tard : l’éditeur annonçait qu’une « sélection de bibliothèques 32 bits », basée sur un « processus communautaire » de choix, continuerait finalement d’être mise à jour, au moins pour Ubuntu 19.10 et 20.04. En outre, des discussions actives étaient lancées avec les développeurs, notamment de jeux.
C’est dans ce contexte qu’intervient l’explication de Valve, qui exprime toute la difficulté du virage pris par Ubuntu.
Le problème de Steam n’est pas Steam
Pour Valve, Canonical a fait les choses correctement : ils ont averti de leur choix et l’ont expliqué en détail aux développeurs. Le père de Steam comprend que la décision du tout 64 bits est dans l’intérêt du projet Ubuntu. Mais l’intérêt du projet n’est pas forcément celui de tous les utilisateurs, particulièrement ceux friands de jeux.
Proposer un client Steam en 64 bits n’aurait en soi rien de vraiment compliqué. Il est en grande partie basé sur du contenu web, embarque un moteur de rendu tiré de Chromium ainsi qu’une bonne partie des dépendances nécessaires. Mais proposer un tel client n’aurait aucun intérêt si les jeux proposés par la plateforme ne suivent pas le mouvement.
Valve évoque des « milliers de jeux » ne pouvant fonctionner qu’en 32 bits, soit la « vaste majorité » du catalogue accessible depuis Linux.
Face à la décision de Canonical, Valve n’avait que deux choix : suivre le mouvement et communiquer autour d’une inévitable cassure dans la ludothèque des utilisateurs, ou les avertir de ne pas passer à Ubuntu 19.10.
Dans les deux cas, une communication lourde de sens puisqu’elle revient à choisir entre renoncer à des jeux ou changer de système d’exploitation. Les versions courantes d’Ubuntu ne sont en effet supportées que 9 mois et sont mises automatiquement à jour quand la suivante sort. On connait néanmoins la décision initiale de Valve – l’arrêt du support d’Ubuntu – puisqu’elle est responsable en grande partie des discussions actuelles.
Le ciel se dégage pour Valve
Les aménagements proposés par Canonical et la volonté de restaurer le dialogue avec les développeurs semblent suffisants pour Valve, en tout cas pour l’instant.
« Nous ne sommes toujours pas particulièrement emballés par le retrait de la moindre fonction existante, mais un tel changement dans le plan est extrêmement bienvenu et nous permettra de continuer à travailler sur des améliorations au modèle de distribution de Steam, sans causer de nouveaux maux de tête aux utilisateurs. Au vu des informations que nous avons jusqu’ici sur cette nouvelle approche, il semble probable que nous pourrons continuer de supporter officiellement Steam sur Ubuntu. »
Valve précise dans son billet travailler depuis un moment déjà à une autre manière de distribuer Steam et ses jeux sur Linux. Il évoque un paysage des distributions largement transformé avec les années et les besoins de s’adapter. Les options proposées initialement par Canonical, largement centrées sur les conteneurs logiciels, sont en fait déjà examinées depuis un moment par Valve.
Problème, l’éditeur n’aurait eu que quatre mois pour transformer intégralement son architecture de distribution. Un délai irréaliste, que nous avions souligné dans notre premier article. Valve résume : « […] nous aurions dû laisser tomber tout ce qui nous faisions et nous précipiter pour supporter le nouveau modèle à temps pour [Ubuntu] 19.10. Nous ne pensions pas pouvoir le faire sans transférer une partie du problème à nos utilisateurs ».
Et maintenant ?
Les utilisateurs de Steam peuvent s’estimer « sauvés », puisque la continuité des fonctions semble assurée à court et moyen termes. Les plans de Canonical courent jusqu’à Ubuntu 20.04 qui aura l’avantage d’être LTS. Tous ses composants seront donc garantis cinq ans.
Mais qu’il s’agisse de Canonical ou de Valve, une vision commune émerge : la distribution logicielle s’apprête à changer. Ce mouvement n’est d’ailleurs pas isolé au seul cas Ubuntu/Steam, loin de là. Dans le monde des serveurs, les conteneurs prennent le pas, comme en témoigne le succès de solutions comme Kubernetes. Chez Microsoft, il se murmure depuis longtemps que les conteneurs pourraient régler le souci de la compatibilité nécessaire avec Win32, que l’éditeur traine comme un boulet.
Pendant que Valve réfléchit à son modèle futur, il annonce dans la foulée avoir repéré d’autres distributions Linux qui pourraient s’avérer de très bonnes plateformes de jeu. Et de citer notamment Arch Linux, Manjaro, Pop!_OS et Fedora, comme autant de moyens de prévenir Canonical qu’Ubuntu n’est pas le seul système d’exploitation. Parmi les Linux, il trône néanmoins. On ne renonce pas si facilement à une telle plateforme.
Mais le constat est valable dans les deux sens. Les efforts de Canonical dans le monde des serveurs et des objets connectés sont manifestes, tandis que le rythme des nouveautés se ralentit depuis un moment dans le « desktop ». Il ne serait donc pas étonnant que l’entreprise cherche à y réduire ses coûts. Par exemple en ne gardant qu’une édition 64 bits. Mais on ne s’impose pas comme la distribution Linux la plus populaire sans y gagner certaines « responsabilités » au passage.
En attendant, Valve précise qu’il devrait en dire plus prochainement sur les améliorations en préparation. L’éditeur espère « qu’elles aideront à améliorer les expériences de jeu et desktop à travers toutes les distributions ». Autant viser large, car il suffit de lire les pages de commentaires sous l’annonce pour s’apercevoir que chacun a une idée précise de ce que serait la solution idéale.
Ubuntu et fin du 32 bits : Valve calme le jeu à son tour
-
Le problème de Steam n’est pas Steam
-
Le ciel se dégage pour Valve
-
Et maintenant ?
Commentaires (44)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 27/06/2019 à 17h13
Plus adapté aux snaps à mes yeux pour un logiciel grand public, je préfère l’AppImage. Molotov, par exemple, tourne sans soucis sur toutes mes machines amd64. Ce n’est pas du 32 bits, mais il n’y a aucune bibliothèque à installer, la gestion des DRMs ne pose pas de souci, les mises à jour se font toutes seules, mon profil est conservé après les mises à jour, et au premier lancement ça a proposé de s’intégrer à mon bureau, ce qui se traduit par une entrée dans le menu multimedia de XFCE. Praticité 100%.
Une autre solution pour Valve, s’ils veulent vraiment être natifs .deb pour Ubuntu serait de maintenir les bibliothèques de compatibilité 32 bits dans un dépôt tiers, pourquoi pas en coopération avec Wine, ces 2 projets étant le plus concernés par cette dépréciation dans Ubuntu.
Le 27/06/2019 à 17h21
Juste pour précision parce que l’article est un peu ambigu : on peut dors et déjà utiliser steam sur d’autres distros qu’ubuntu. Perso je l’ai sur fedora.
Le 27/06/2019 à 17h35
Sauf que valve ou wine n’ont certainement pas envie de gérer eux-mêmes le support de toutes ces dépendances, c’est pas vraiment leur job et c’est énormément de boulot.
Le 27/06/2019 à 17h45
Le 27/06/2019 à 18h12
ils feraient bien d’aller voir du coté de manjaro, ils auraient une version “stable” tout en ayant le multilib d’arch
Le 27/06/2019 à 18h27
Le 27/06/2019 à 18h43
D’où l’intérêt, au moins pour Valve, de distribuer une AppImage.
Un seul binaire, pas de dépendance (quelques niveaux minimum de certaines bibliothèques courantes), et puisqu’on est entre geeks une distribution par torrent, ça limitera les coûts de bande passante.
Pour Wine, par contre, c’est compliqué :-/
Le 27/06/2019 à 18h47
Le 27/06/2019 à 20h26
Et CentOS est la seule distrib officiellement supportée par Intel pour les pilotes vidéo. Ça n’empêche les autres distros de fonctionner ;)
EDIT : je parle des pilotes d’encodage/décodage vidéo
Le 27/06/2019 à 20h27
Héhé, copaing Manjaro !
Le 27/06/2019 à 21h07
À vrai dire, la bascule vers la seule vraie distrib universelle : Debian, est la plus facile à faire ;-)
Le 27/06/2019 à 21h26
J’adore Linux, Ubuntu, mais ça concerne combien d’utilisateurs ?
Le 28/06/2019 à 02h29
Sauf que l’on ne veut pas forcément de “conteneurs” en tant que joueurs.
Le 28/06/2019 à 07h05
Le 28/06/2019 à 07h09
Depuis le début de cette affaire on lit que les jeux sont dans la majorité des cas en 32bits , pourquoi ???
Cela fait tout de même 15 ans que les processeurs 64 bits sont sur le marcher….
Le 28/06/2019 à 07h18
Tu sais qu’il y a 15 ans, on était déjà en 2004 ? Et bien figure toi qu’on a pas attendu cette année là pour créer des jeux !
De plus avoir un processeur 64bits ne suffit pas à pouvoir faire tourner un jeu 64bits : il faut aussi que l’OS soit 64 bits, ainsi que toutes les bibliothèques utilisées par le jeu.
Et combien en 2004 avait un système 64bits ? Windows XP 64 bits n’est sorti qu’en 2003 !
Combien sont restés en 32 bits sous vista (2007) et 7 (2009) ?
Le 28/06/2019 à 07h55
Le 28/06/2019 à 09h36
Mine de rien, l’info la plus spectaculaire de ces deux dernières news tient quand même dans ces deux mots : Valve communique. " />
Le 28/06/2019 à 09h57
Le 28/06/2019 à 11h15
Le 28/06/2019 à 11h40
Le 28/06/2019 à 11h51
Je parle de mods, pas de DLCs. Les premiers sont conçus par les joueurs et peuvent être amenés à modifier des fichiers du jeu, les derniers sont une excuse commerciale des concepteurs pour se refaire du cash.
Or le principe de base des conteneurs (des vrais, pas une machine virtuelle comme ton exemple), c’est d’être read-only. Ça complique beaucoup les choses, même en passant par de l’injection DLL et autres… Et aussi c’est plus lent à en croire des topics sur les SNAP d’Ubuntu par ci par là…
Donc autant je peux voir un intêret notable à mettre en conteneur des applications comme le navigateur, client email ou autres assez génants qu’on peut au passage en profiter pour bien séparer du reste et augmenter la sécurité, autant un jeu vidéo… en quoi est-ce pertinent ?
Le 28/06/2019 à 12h51
Le 30/06/2019 à 09h14
Le 30/06/2019 à 11h30
Et pourtant ça arrivait plus fréquemment qu’on ne pourrait le penser " /> (excellente référence " />)
Le 01/07/2019 à 22h13
C’est pas si simple, la plupart du temps l’upstream ne supporte pas vraiment telle arch ou telle distro, et les distros font donc le boulot spécifique de test et d’intégration. Rien que pour avoir une idée du boulot que ça représente, il suffit de regarder ce que font Debian et Gentoo pour maintenir des archis supplémentaires.
Le C est “portable” mais il y a toujours des subtilités (qui peuvent se transformer en problèmes majeurs) pour être compatible avec une archi spécifique.
De plus quand une distro intègre une librairie il faut forcément faire des tests spécifiques, intégrer les mises à jour des sécurités, etc. Donc au final intégrer correctement les libs 32 bits c’est beaucoup de boulot. Le gros risques est de le faire à moitié et de louper des failles de sécurités ou bugs majeurs.
Le 02/07/2019 à 10h20
Si on regarde l’enquête sur le matériel et les logiciels de steam de juin 2019, il y a 0.76% des utilisateurs qui ont Linux. Steam revendique 90 millions d’utilisateurs actifs par mois dans le monde. On arrive à 684 000 utilisateurs steam utilisant linux dans le monde en mode grosse louche.
Le 03/07/2019 à 18h00
Merci !
Donc beaucoup de bruit pour peu d’utilisateurs. Incluant les steambox qui ont un support dédié par Vavle…
Le 28/06/2019 à 13h34
Le 28/06/2019 à 14h18
Mais pas forcément de l’utilisateur. Et parfois c’est juste à l’excès : Les programmes/jeux achetés dans le Store Microsoft (UWP donc) sont dans des répertoires inaccessibles : on n’a pas les droits de base, seul TrustedInstaller les a… On ne sait jamais, l’utilisateur pourrait les effacer par erreur " /> ou un pirate passerait par un jeu. Non mais sérieusement ?
Le 28/06/2019 à 15h05
Je ne pense pas que l’usage de containers apporte en lui-même des difficultés significatives.
Par exemple avec Docker, le fichier source d’un container c’est une suite de commandes comme copier tel dossier, lancer telle commande etc… qui servent à initialiser la machine. Point important, qui fait une bonne part de la puissance du concept, tu peux hériter d’un container de base pour le spécialiser. Ca revient à avoir la même recette, plus tes propres commandes, comme ajouter tels fichiers, remplacer celui-ci par celui-là etc…
L’action de modder se transformerait donc de changer tel ou tel fichier dans le dossier du jeu en créer un docker dérivé qui via une série de commande automatise les modifs à faire et génère un nouveau container moddé. Ca pourrait donc même être plus facile.
Le 28/06/2019 à 20h43
J’ajoute aussi que les containers ne sont pas totalement read-only. Sinon, comment on gèrerait les sauvegardes ou la config? Avec les technos de type docker, on peut créer des volumes pour gérer ces choses-là (et donc exposer/partager des fichiers sur le host)
Mais même, est-ce vraiment à ça que valve pense quand ils parlent de containers? Est-ce qu’ils ne partiraient pas sur leur propre techno, ou un dérivé? J’ai pas l’impression que l’aspect “immutable” soit ce qui les intéresse.
Le 29/06/2019 à 10h43
En fait, Canonical a juste rappelé un truc intéressant de l’IT en faisant sa première annonce.
De la même manière que pour Windows XP et sa fin de vie, au final l’informatique qui va à toute vitesse est aussi incroyablement immobiliste.
Cela fait des décennies que l’architecture 64bits existe pour le grand public (et qu’elle est quasi aussi vieille que le 32bits), elle est depuis la règle au niveau du hardware, mais pourtant les éditeurs de softwares continuent de fournir des logiciels compilés pour du 32bits.
Au final, ces cris d’alarme et de panique sont avant tout un aveux d’échec à mes yeux. Plutôt que d’aller de l’avant, ces éditeurs préfèrent hurler au scandale parce qu’un acteur a mis un coup de pied dans la fourmilière.
Le 29/06/2019 à 12h22
Le 29/06/2019 à 13h20
Mais du coup c’est quoi la surcharge de travail à sortir une librairie ou une application en 32bits en plus du 64bits ? Je pensais naïvement qu’il “suffisait” de le dire au compilateur et de corriger les éventuels bugs spécifiques (ce qui doit être plus ou moins complexe en fonction de quoi on parle bien sûr) ?
Et du coup, c’est quoi la surcharge de travail pour une distribution ? Après tout, ils ne développent pas les librairies, ils se contentent de les assembler, configurer etc. pour en faire un tout cohérent, non ? Il leur “suffit” en gros de configurer leurs fermes de build pour construire des versions 32bits des paquets voulus non ?
(Je simplifie, bien sûr que Canonical et d’autres éditeurs de distributions contribuent activement au code de nombreux paquets voire créent de nouveaux projets de zéro pour leurs besoins.)
Parce que Canonical ne manque pas trop de moyen par rapport à des distributions plus communautaires (btw I use arch) qui arrivent à maintenir des versions 32bits des librairies non ?
Le 29/06/2019 à 13h28
Le 29/06/2019 à 13h56
Le 29/06/2019 à 15h55
Le 29/06/2019 à 22h48
Tout le monde s’en moque des licences et nous le savons tous les deux " /> et il y a plus d’un exemple de jeu qui ne serait rien sans modding.
Le 30/06/2019 à 00h48
Le 30/06/2019 à 07h10
Le 30/06/2019 à 08h30
Oui, et de plus, il ne faut pas réduire le rôle de Canonical à du packaging. Parmi la pléthore de libs, ils doivent bien en maintenir eux-même une certaine partie, il ne font pas que se reposer sur le travail des autres.
Le 30/06/2019 à 08h39
Le travail de maintenance est le même qu’ils fournissent des libs 32 bits ou non dans leur distribution.
Comme d’autres distributions fournissent du 32 bits, ils doivent les maintenir aussi s’il y a des spécificités 32 bits.
Seul le travail de packaging pour leur distribution est à prendre en compte pour justifier leur choix.
Le 30/06/2019 à 08h50