Ubuntu et fin du 32 bits : Valve calme le jeu à son tour

Ubuntu et fin du 32 bits : Valve calme le jeu à son tour

Tout va bien... pour l'instant

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

27/06/2019 6 minutes
44

Ubuntu et fin du 32 bits : Valve calme le jeu à son tour

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.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le problème de Steam n’est pas Steam

Le ciel se dégage pour Valve

Et maintenant ?

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (44)


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.


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.


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.








jotak a écrit :



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.



Mais Ubuntu est la seule distrib officiellement supportée par Valve.



ils feraient bien d’aller voir du coté de manjaro, ils auraient une version “stable” tout en ayant le multilib d’arch








Patch a écrit :



Mais Ubuntu est la seule distrib officiellement supportée par Valve.







Je crois que SteamOS est supporté donc par voie de conséquence debian également.



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é :-/








Cumbalero a écrit :



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é :-/





n’oublions pas que le système proton de steam repose sur …. wine donc l’appimage ne réglera rien du tous



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


Héhé, copaing Manjaro !



À vrai dire, la bascule vers la seule vraie distrib universelle : Debian, est la plus facile à faire ;-)


J’adore Linux, Ubuntu, mais ça concerne combien d’utilisateurs ?


Sauf que l’on ne veut pas forcément de “conteneurs” en tant que joueurs.




Non seulement cela demandera des connaissances que nous n'avons pas (|et pas forcément envie d'avoir), mais en plus ça fige le programme. En clair, modder risque d'être impossible sauf si le jeu le permet pleinement de base, ce qu'il ne fait pas toujours (il y a des mods pour Anno 2070 par exemple... qui modifient des fichiers du jeu vu qu'il n'est pas moddable).      






Microsoft a subit des critiques en ce sens avec son Store et les subit toujours aujourd'hui.  Les joueurs préfèrent Steam ou autres beaucoup pour ça aussi...    






Hors de question de jouer avec des conteneurs. Serveurs, d'accord. Utilisation de base, à quoi bon sinon em****** les gens ?      






L'ingénierie pour le bien de l'ingénierie et non de l'utilisateur ne procure rien de bon sinon un élitisme plus fort (difficulté d'usage de ressources plus simple d'accès auparavant pour les débutants) et de la frustration.







Salamandar a écrit :



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



Je n’ai jamais dit que ca ne pouvait fonctionner ailleurs <img data-src=" /> Juste que Valve n’apporte pas de support sur les autres distros <img data-src=" />



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….


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) ?








linkin623 a écrit :



J’adore Linux, Ubuntu, mais ça concerne combien d’utilisateurs ?



&nbsp;



1% d’après Valve.



Mine de rien, l’info la plus spectaculaire de ces deux dernières news tient quand même dans ces deux mots : Valve communique. <img data-src=" />








TheKillerOfComputer a écrit :



Hors de question de jouer avec des conteneurs. Serveurs, d’accord. Utilisation de base, à quoi bon sinon em les gens ?&nbsp;



Perso je trouve intéressant d’avoir des conteneur pour de vieux jeux. Et ça n’empêche pas d’avoir du DLC, il suffit de fournir du stockage.

Ca a l’avantage d’uniformiser la distribution et de ne pas pourrir son OS par des librairies inutiles aux autres (genre Visual C++ runtime x versions, quasi une par appli). Supprimer le jeu est d’autant plus facile.

Maintenant, c’est complexe de packager ainsi des jeux qui ont des dépendances avec les drivers et des besoins d’accès direct machine.



Il y a quelques années, on a critiqué le format de distribution PBI de PC-BSD car il contenait toutes les bibliothèques et que du coup rien n’était partagé. Mais le résultat, c’est qu’il n’y avait pas de problème autre que le manque de place et de RAM.



En tout cas je rêve de lancer Wine sous Windows: actuellement pour jouer à un jeu (Pong: the next level), j’ai tenté de l’installer sous Windows 10 et maintenant je ne peux plus le désinstaller alors qu’il ne fonctionne pas.

-&gt; J’ai donc ressorti des CD et j’ai créé un “conteneur”: emulateur + Win95… Mais ça marche sous Windows ou&nbsp; Linux. Avec une espèce de sanbox Wine, ça pourrait être intéressant.









brice.wernet a écrit :



En tout cas je rêve de lancer Wine sous Windows: actuellement pour jouer à un jeu (Pong: the next level), j’ai tenté de l’installer sous Windows 10 et maintenant je ne peux plus le désinstaller alors qu’il ne fonctionne pas.

-&gt; J’ai donc ressorti des CD et j’ai créé un “conteneur”: emulateur + Win95… Mais ça marche sous Windows ou  Linux. Avec une espèce de sanbox Wine, ça pourrait être intéressant.



Pour toi ca serait nettement plus simple de passer par une machine virtuelle, vu ton but. Vu que tu es déjà sur 10, tu n’as plus qu’à activer HyperV pour en créer plutôt facilement <img data-src=" />









Patch a écrit :



Pour toi ca serait nettement plus simple de passer par une machine virtuelle, vu ton but. Vu que tu es déjà sur 10, tu n’as plus qu’à activer HyperV pour en créer plutôt facilement <img data-src=" />



Windows 95 ne semble pas passer sur hyperV.

J’ajoute: activer hyper-v, c’est l’activer “sous” Windows. J’ai eu des différences de comportement sur mon ancien ordi avec ça, notamment la gestion de l’énergie. La carte Wifi par exemple ne se mettait plus en veille, et je perdais de l’autonomie.



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 ?








TheKillerOfComputer a écrit :



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 ?





C’est effectivement pertinent pour figer une appli … ce qui est l’intérêt du développeur et du distributeur.



Maintenant, tant qu’on peut le lire, on doit pouvoir le modifier d’un façon ou d’une autre, que ce soit directement, par injection ou par détournement. On a bien moddé des jeux en injectant du code dans l’exe ou en faisant appel à d’autres DLL. Un conteneur, c’est un système de fichier dans un fichier finalement.









brice.wernet a écrit :



Il y a quelques années, on a critiqué le format de distribution PBI de PC-BSD car il contenait toutes les bibliothèques et que du coup rien n’était partagé. Mais le résultat, c’est qu’il n’y avait pas de problème autre que le manque de place et de RAM.





Le problème est le même que pour les binaires compilés en statique : tu fais comment pour combler les bugs/failles des libs embarquées quand le mainteneur du pkg/binaire arrête le support ?



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 <img data-src=" /> ou un pirate passerait par un jeu. Non mais sérieusement ?




     Alors oui on peut tout de même modifier par injection DLL ou autres, je le dis bien, sauf que ce n'est pas le même niveau de connaissances requis, par rapport à la simple modification des fichiers Python présents dans le répertoire du jeu (Civilization V par exemple).      






     Je n'ai pas les compétences requises pour forcer la main et je n'ai pas envie d'apprendre juste pour faire plaisir à des devs maniaques qui ont jugé fidélité au grand dieu des conteneurs (Amazon ?).           

&nbsp;

Alors oui, aujourd'hui les jeux sont souvent moddables sans devoir hacker, mais parfois insuffisamment. Civilization 6 par exemple ne permet pas de modder l'IA autant que le permettait son ancêtre le 5, étonnament... alors qu'elle en aurait GRAND besoin. Le risque que les dévs oublient quelque chose n'est pas nul.






     Non j'insiste, ce n'est pas pertinent pour les jeux vidéos sauf à pourrir la vie des usagers qui devront avoir un master en informatique juste pour contourner toutes les sécurités fixées à l'accès aux fichiers.    






     Même pour des petites choses, l'ingénierie pour l'ingénierie cause de gros dégats. Sur Eve Online, au moins la moitié des logiciels et sites web sont morts au moment où les devs sont passés du simple URL qui rendait un XML pour accéder à des données, à tout un bordel incluant des SSO Tokens à gérer. Mes fichiers Excel s'en rappellent encore, ils sont tous morts et je ne sais pas gérer des SSO Tokens par un tel soft, il me faudrait donc concevoir un site web ou un vrai logiciel avec navigateur intégré. C'est de la folie furieuse, du délire ingénieurique qui fait peut-être bander les dévs mais pas les utilisateurs.

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.


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.


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.








SebGF a écrit :



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.





C’ay à double tranchant : si à l’époque où le matos 64b s’est répandu les devs de softs avaient tout passé en 64b en obligeant un peu leurs utilisateurs à migrer ; du coup les fabricants de matos en auraient déduit que c’ay cool pour passer au 128b et on en finirait pas de migrer… un peu comme des pigeons, quoi… <img data-src=" />

Bon après okay, ça excuse pas les ceusses qui utilisent encore des machines des années 80 à disquettes souples au prétexte que ça fonctionne toujours…. <img data-src=" />



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 ?








Saymonz a écrit :



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 ?







C’est pas spécialement une question de moyens, mais Canonical se focalise plutôt sur le marché professionnel avec les produits server, le support, la virtu, l’Internet des Trucs, etc. Ils ont réduit les ressources allouées à Ubuntu Desktop.



Même si la compagnie a été créée et financée pendant longtemps par les fonds de Shuttleworth, celle-ci a trop longtemps été déficitaire et elle continue d’enregistrer des pertes. La seule fois où elle a enregistré de forts profits, c’est après l’abandon d’Unity et d’Ubuntu Touch vu qu’ils ont viré les devs du projet.









Saymonz a écrit :



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&nbsp; 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) ?



&nbsp;

Le build en lui-même est une toute petite partie de l’équation, en effet builder le 32bits en plus du 64bits n’est pas ce qui va poser beaucoup de soucis. En revanche, en terme de tests et de support, c’est une autre histoire. On multiplie la surface à couvrir, je ne sais pas si le coût a été chiffré, mais c’est certain qu’il y en a un.

&nbsp;

On peut voir aussi l’aspect sécurité, c’est d’ailleurs évoqué dans ce thread qui date de l’année dernièrehttps://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html : “Machines running i386 Ubuntu which are capable of running amd64

Ubuntu are vulnerable to the critical Meltdown vulnerability where they

wouldn’t be if they were running amd64.”



&nbsp;









TheKillerOfComputer a écrit :



Alors oui, aujourd’hui les jeux sont souvent moddables sans devoir hacker, mais parfois insuffisamment. Civilization 6 par exemple ne permet pas de modder l’IA autant que le permettait son ancêtre le 5, étonnament… alors qu’elle en aurait GRAND besoin. Le risque que les dévs oublient quelque chose n’est pas nul.



&nbsp; Mes fichiers Excel s’en rappellent encore, ils sont tous morts et je ne sais pas gérer des SSO Tokens par un tel soft, il me faudrait donc concevoir un site web ou un vrai logiciel avec navigateur intégré. C’est de la folie furieuse, du délire ingénieurique qui fait peut-être bander les dévs mais pas les utilisateurs.



Je ne crois pas que le modding soit une partie du contrat de licence permis (sauf avec doom peut-être :) )

Quand aux SSO tokens, soit c’est pour d’identifier (et potentiellement vendre des données) , soit c’est simplement pour sécuriser. Et ça ne fait pas “bande” les dev en général



Tout le monde s’en moque des licences et nous le savons tous les deux <img data-src=" /> et il y a plus d’un exemple de jeu qui ne serait rien sans modding.




    Pour les SSO, ça n'apporte rien en sécurité : l'ancien système permettait déjà d'expirer les URLs à tout moment depuis le site officiel au besoin. Au contraire, ça l'a même abaissé car les guildes ne peuvent plus exiger les informations de tous les personnages d'un compte (par une URL spéciale), seulement ceux enregistrés. Pratique pour les espions, mais pas pour les traquer.          

&nbsp;

L'implémentation du nouveau système est si ridicule qu'il faut parfois annoncer créer une application pour obtenir une "clé développeur" requise par l'application extérieure que l'on veut utiliser (EveMon, Cerebral, etc.) afin que ces derniers puissent accèder à toutes les données utilisateurs par SSO Tokens. Mon application s'appelle « Because CCP sucks » avec en description mon avis sur la branlette de leurs dévs.






    Et dans l'histoire, je vais devoir mettre plusieurs heures à apprendre un système (création Tokens, gestion de leur expiration et renouvellement, stockage, etc.) alors qu'auparavant, j'accédais à mes données en 30 secondes chrono (créer l'URL et obtenir le fichier XML en y allant). J'ai fait au plus simple : je fais sans plutôt que d'apprendre, je ne vois pas pourquoi je devrais m'adapter pour que des dévs puissent se branler... UNE seule application extérieure me permet encore d'avoir ce que je veux, mais depuis quelques mois le joueur ne donne plus de signes de vie. Si ça reste ainsi, à terme je jouerai moins car je perdrai l'accès à mes données quand le logiciel devra trop obsolète.   






    A aucun moment ils n'ont parlé des avantages pour les utilisateurs, normal car il y en a aucun. On a perdu en capacité de surveillance des membres, en facilité d'usage, etc. Ça a été crée uniquement pour eux-même.          











jotak a écrit :



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)






    Les volumes ne sont que des sortes de liens symboliques, et il faut que ça ait été prévu à l'avance. Le container en soi reste immutable, on ne touche pas au contenu en linkant un fichier Apache.conf extérieur par exemple.      






    Valve avait déjà fait des containers au début de Steam, bien que ce n'était que pour contenir les fichiers uniquement. Un fichier GCF contenait tout le jeu et n'était pas modifiable autrement que par Steam pour les updates, bien qu'on pouvait lire le contenu. Ils ont fini par abandonner, tous les jeux sont à l'air libre maintenant et ce n'est pas plus mal.








jotak a écrit :



&nbsp;

On peut voir aussi l’aspect sécurité, c’est d’ailleurs évoqué dans ce thread qui date de l’année dernièrehttps://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040310.html : “Machines running i386 Ubuntu which are capable of running amd64

Ubuntu are vulnerable to the critical Meltdown vulnerability where they

wouldn’t be if they were running amd64.”



&nbsp;





Ce lien parle explicitement des personnes utilisant la version 32bits d’Ubuntu sur du matériel pouvant supporter la version 64bits, pas l’utilisation libs 32bits sur un système 64bits.



Concrètement, tant que les fournisseurs upstream fournissent leurs librairies et programmes comme compatible 32bits, est-ce que Canonical va vraiment réaliser une économie en ne les packageant pas pour Ubuntu ?









Saymonz a écrit :



Concrètement, tant que les fournisseurs upstream fournissent leurs librairies et programmes comme compatible 32bits, est-ce que Canonical va vraiment réaliser une économie en ne les packageant pas pour Ubuntu ?







Même si ça peut être automatisé (et que ça doit très certainement l’être) jusqu’à la TNR et l’implémentation, ça reste des process qui ont un coût de maintenance.

Et si t’as plus personne pour le faire parce qu’ils réduisent les moyens alloués à ces tâches, oui ça fait une économie (pas forcément énorme je pense) à Canonical.



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 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.








TheKillerOfComputer a écrit :



Les volumes ne sont que des sortes de liens symboliques, et il faut que ça ait été prévu à l’avance. Le container en soi reste immutable, on ne touche pas au contenu en linkant un fichier Apache.conf extérieur par exemple.





Dans le cas où Valve réutiliserait une techno de containers immutables (ce qui n’est pas évident IMHO), la question, notamment pour les moddeurs, sera de savoir où sera la délimitation entre la partie mutable et la partie immutable (comme je disais, il y aura forcément une partie mutable, ne serait-ce que pour les settings du jeu). On peut imaginer que ce seront les développeurs des jeux qui feront ce choix, selon le degré d’ouverture du jeu, justement pour les mods. Finalement ça ne change pas grand chose à l’état actuel des choses : on trouve déjà des développeurs qui veulent compliquer au maximum la rétro-ingénierie (comme tu le disais plus haut) et d’autres qui sont plus ouverts, qui souhaitent “stimuler” la communauté.



Mais encore une fois, j’ai pas l’impression que Valve en ait quelque chose à carrer de l’immutabilité. Ce qui les intéresse c’est plus le gestion des dépendances, il me semble… Du coup ils pourraient très bien partir sur une techno / implémentation moins contraignante pour les moddeurs tout en gardant l’aspect “layers” pour les dépendances.

&nbsp;









TheKillerOfComputer a écrit :



Pratique pour les espions, mais pas pour les traquer.



T’es un espion et t’as pas 2 comptes ? <img data-src=" />



Et pourtant ça arrivait plus fréquemment qu’on ne pourrait le penser <img data-src=" /> (excellente référence <img data-src=" />)


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.


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.


Merci !



Donc beaucoup de bruit pour peu d’utilisateurs. Incluant les steambox qui ont un support dédié par Vavle…