Ubuntu revient en partie sur son passage forcé au tout 64 bits

Ubuntu revient en partie sur son passage forcé au tout 64 bits

Vision contre réalité

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

25/06/2019 8 minutes
117

Ubuntu revient en partie sur son passage forcé au tout 64 bits

La récente décision de Canonical de se passer de moutures 32 bits pour Ubuntu 19.10 et les versions ultérieures crée plus de remous que prévu. Valve prévoit de couper le support de la distribution pour Steam alors que Wine est bien embêté.

La semaine dernière, Canonical annonçait l’inévitable : dès la prochaine version d’Ubuntu, attendue comme d’habitude pour octobre, le système ne sera plus disponible qu’en 64 bits. Cette décision rejaillit tant sur les variantes officielles (Kubuntu, Xubuntu, etc.) que les distributions dérivées, dont Mint. Elle entraine donc de nombreux systèmes dans son sillage.

Elle était cependant prévisible, car le matériel purement 32 bits est devenu très rare et des plateformes importantes ont déjà fait le grand saut ou s’y préparent activement (macOS par exemple). Les avantages sont nombreux en termes de sécurité, de performances et surtout de maintenance, puisque de nombreux paquets ne nécessitent alors plus d’entretien.

Pourtant, ce sont bien ces paquets dont dépendent certaines applications, et pas des moindres. 

Valve dit non, Wine y songe très sérieusement

L'inévitable survient peut-être trop tôt. Ce qui s’apparentait à une « simple » décision technique provoque désormais de sérieux remous, malgré une FAQ officielle qui a rapidement montré ses limites.

On commence avec Valve, qui prévoit tout simplement la fin du support de son client Steam pour Ubuntu 19.10 et les versions ultérieures. Du moins si rien ne change. Pourquoi ? Parce que l'application repose encore largement sur des bibliothèques 32 bits. C’est cependant loin d’être le souci principal de Valve : de nombreux jeux en ont également besoin.

Dans l’immédiat, préparer un client 64 bits de Steam dans les mois qui viennent ne résoudrait donc pas le problème.

Steam Linux

Un développeur de Canonical s’est d’ailleurs amusé à tester des jeux venant de GOG sur une préversion d’Ubuntu 19.10. Le constat est sans appel : de nombreux titres ne fonctionnent tout simplement pas sur un système purement 64 bits (ce qu’Ubuntu 19.10 ne sera pas vraiment, nous y reviendrons). On peut donc envisager une situation similaire avec Steam.

La décision ne fait sans doute clairement plaisir à personne, et surtout pas à Valve. Après tout, Ubuntu est la distribution GNU/Linux la plus utilisée. Ne plus supporter la distribution risque fort d’ennuyer de nombreux joueurs, surtout avec les investissements massifs de l’entreprise dans le développement autour de l’API Vulkan.

Pour Wine, la situation est tout aussi compliquée. Ces bibliothèques 32 bits sont essentielles pour simuler l’environnement 32 bits de Windows, de nombreux logiciels fonctionnant sous la plateforme de Microsoft étant encore prévus pour cette architecture. Une situation qui n’évolue que lentement.

Rien ne pousse en effet les développeurs à basculer, à moins de besoins spécifiques comme les performances. Pour les abonnés Office 365 par exemple, les applications ne sont fournies en 64 bits par défaut que depuis moins d’un an.

Les clarifications de Canonical : bonnes et mauvaises nouvelles

L’éditeur s’est assez vite rendu compte d’un problème d’interprétation de son annonce. Oui Ubuntu 19.10 ne sera fourni qu’en 64 bits, mais cela ne signifie pas que les bibliothèques de compatibilité 32 bits en seront supprimées. Les soucis seraient-ils résolus pour autant ? Non, car le support technique vient s’en mêler.

Pour comprendre le choix de Canonical, rappelons qu’il existe deux cycles pour Ubuntu. D’une part, les versions classiques tous les six mois, accompagnées d’un support de neuf mois. D’autre part, les versions LTS (Long Term Support) tous les deux ans, avec un support de cinq ans. La majorité des utilisateurs sont dans le cycle classique, dont le support couvre les six mois entre deux versions, et trois mois supplémentaires pour laisser le temps aux « retardataires ».

Un support qui, dans les grandes lignes, ressemble à celui de Chrome ou Firefox, et qui ne vaut donc surtout que pour la version en cours. Comment intégrer dès lors des bibliothèques qui ne bénéficieront plus d’aucun support puisque Canonical cesse tout développement sur les paquets 32 bits ? C’est justement le choix de l’éditeur : intégrer les bibliothèques d’Ubuntu 18.04, la dernière LTS disponible, dont tous les paquets sont de fait supportés pour cinq ans.

Traduction : les paquets fournis dans la 19.10 seront ceux fournis un an et demi auparavant, supprimant au passage les diverses améliorations qui avaient été implémentées. On pense notamment à Mesa, cité par Steve Langasek de chez Canonical. En outre, il faudrait que les applications cherchant à les exploiter soient lancées depuis des snaps.

Entre scepticisme et compromis

Cette approche rend une partie des développeurs de Wine dubitatifs. Henri Verbeet notamment envisage la même décision que Valve : « Je pense que ne pas construire de paquets pour Ubuntu 19.10 est la seule option réaliste. Ce serait probablement une bonne idée de placer une petite explication sur la page de téléchargement ». Et d’expliquer que Wine pourrait fonctionner sur Ubuntu 19.10, mais « nous devrions construire et fournir toutes nos dépendances nous-mêmes ».

Il faut savoir également que la plupart des paquets 32 bits ne seront pas installés par défaut, mais disponibles dans le dépôt LTS correspondant actuellement à Ubuntu 18.04. C’est le cas de Mesa, avec une petite exception quand même, Langasek pointant des améliorations apportées sur le support du matériel dans cette même branche LTS.

Mais pour l’émulateur PlayStation PCSX2, le mouvement signifie bien le retour à la branche 1.4, plutôt que l’actuelle version 1.5. La situation est d’autant plus complexe qu’une application graphique a non seulement besoin de Mesa, mais aussi d’un pilote en 32 bits. Il y a fort à parier que les constructeurs se débarrasseront avec plaisir de l’ancien code pour ne plus se limiter qu’au 64 bits, avec la simplification que l’on imagine.

Dans le cas d’un snap 32 bits, Langasek imagine l’inclusion par exemple des pilotes NVIDIA libres 32 bits dans le paquet amd64, qui serait alors exposé aux conteneurs les réclamant. En clair, c’est tout le 32 bits qui se retrouvera dans quelques mois affublé de l’étiquette « legacy », avec un support technique limité à la seule sécurité.

Au-delà des applications courantes, la décision ne sera pas sans poser problème avec certains pilotes, particulièrement pour des périphériques un peu anciens. Canonical a repéré notamment des soucis avec les imprimantes Brother.

Un rétropédalage reste possible

Canonical ne pouvait qu’espérer une coupure nette et franche, mais ce type de mouvement se fait rarement de manière « propre » en informatique. En l’occurrence, la décision a beaucoup plus d’impact que le petit 1 % de machines 32 bits.

Au point qu’actuellement, il reste possible que l’éditeur soit contraint de revenir sur sa décision et la décaler. Canonical a voulu être proactif, mais subit une levée imprévue de boucliers des développeurs. Steam et Wine sont deux produits emblématiques : Ubuntu a beau être la distribution la plus utilisée, elle a besoin d’applications pour garder son intérêt.

L’utilisateur « moyen » ne sera peut-être pas touché, mais le risque de rencontrer une incompatibilité est loin d'être négligeable. Si la polémique enfle, Canonical pourrait faire face à un retour de bâton. La version 19.04 finira en effet par se mettre automatiquement à jour vers la 19.10, et les utilisateurs pourraient voir d’un très mauvais œil la moindre cassure dans une compatibilité, que ce soit dans un jeu, un émulateur ou une imprimante.

Si l’éditeur décide de poursuivre, il devra copieusement communiquer. Le point même sur lequel il est attaqué actuellement par les développeurs.

Mise à jour : Ubuntu ne revient qu'en partie sur sa décision

Ubuntu a fait un demi-tour partiel. Comme nous l’évoquions hier, il s’agit bien d’une conséquence aux boucliers levés par les développeurs.

Canonical fournira une « sélection de bibliothèques 32 bits » qui ne seront dès lors plus limitées à leur mouture datant de la dernière LTS (Ubuntu 18.04). L’éditeur ajoute qu’un « processus communautaire » sera mis en place « pour déterminer quels paquets sont nécessaires au support d’anciens logiciels ». Cette décision s'applique pour l'instant aux prochaines versions 19.10 et 20.04.

L’éditeur annonce également un rapprochement avec certains développeurs, dont ceux de Wine. Mais la solution abordée est bien celle décrite hier dans l’article d’origine : l’utilisation des conteneurs logiciels. Selon Canonical, les Snaps et LXD sont une solution à long terme pour le support des vieux programmes 32 bits, jeux compris.

Il ne reste qu’environ quatre mois cependant pour réaliser l’ensemble des travaux.

117

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Valve dit non, Wine y songe très sérieusement

Les clarifications de Canonical : bonnes et mauvaises nouvelles

Entre scepticisme et compromis

Un rétropédalage reste possible

Mise à jour : Ubuntu ne revient qu'en partie sur sa décision

Commentaires (117)


Valve va se passer de macOS du coup ?


Je me disais bien que Steam et Wine allaient gueuler. <img data-src=" />



Pas de lib 32 bits, pas de Proton, DXVK, Wine etc…


Et mon imprimante qui a 6 ans et ses drivers 32bits.



Je commençais à apprécier disco dingo malgré tous les problèmes rencontrés.


Ah flûte moi qui me félicitais de pouvoir faire un pti jeu sous steam sans avoir à rebooter sous Windows <img data-src=" />





C’est pas un peu révélateur des limites de la techno quand elle va plus vite que les besoins ça quand même? Je comprends évidemment l’envie de ne pas avoir à maintenir l’ancien trop longtemps, mais apparemment beaucoup de secteurs ne ressentaient pas la nécessité de changer, difficile de le faire par pure envie du toujours plus…


On voit là toute la nécessité de forcer la libération du code des pilotes après un certain temps “d’abandon” par les constructeurs, afin que la maintenance soit reprise par la communauté et que le matériel puisse continuer à être utilisé.



Pour en revenir au sujet je ne pensais pas que cette décision aurait un tel impact, vu la faible représentativité du 32 bits de nos jours. Je pensais que tout cela pouvait être émulé sans trop de problèmes.


Stellaris a obtenu sa version 64 bits que TRES récemment et même encore cette année ont sorti des jeux en 32 bits (Sunless Skies par exemple pourtant fait avec Unity). Le 32 bits est là pour encore longtemps, trop tôt pour s’en séparer.



Surtout un OS qui est presque un oxymore avec le concept de jeux vidéo <img data-src=" />


Il n’y a pas de rapport entre le support des applications 32bits et le support des pcs 32bits.

Le second consiste à avoir un noyau 32bits et le support matériel, et est un boulet à se traîner.

Le premier ne consiste qu’à proposer les libraires compilées pour 32bits.



Un exemple : Arch linux a abandonné le support des pcs en 32bits, mais Wine et Steam tournent très bien.








Furanku a écrit :



Pour en revenir au sujet je ne pensais pas que cette décision aurait un tel impact, vu la faible représentativité du 32 bits de nos jours. Je pensais que tout cela pouvait être émulé sans trop de problèmes.





Tout le 32bits est “émulé” sans problème de nos jours, c’est juste qu’il faut avoir accès aux bibliothèques en 32bits pour pouvoir faire cette émulation. Justement ce que Canonical veut supprimer dans les prochaines versions d’Ubuntu.









Salamandar a écrit :



Il n’y a pas de rapport entre le support des applications 32bits et le support des pcs 32bits.

Le second consiste à avoir un noyau 32bits et le support matériel, et est un boulet à se traîner.

Le premier ne consiste qu’à proposer les libraires compilées pour 32bits.



Un exemple : Arch linux a abandonné le support des pcs en 32bits, mais Wine et Steam tournent très bien.



… Parce qu’Arch Linux dispose, dans sa version 64 bits uniquement, d’un dépôt officiel nommé Multilib et qui contient justement une liste de bibliothèques et applications 32 bits rendues compatibles pour un usage sur une Arch 64 bits.

Lorsque le site officiel d’Arch Linux a annoncé l’abandon progressif du 32 bits (d’abord la fin des ISO d’installation en février 2017, puis la suppression des dépôts 32 bits en novembre de la même année), il a bien été précisé que le dépôt Multilib ne serait pas concerné. Et c’est là là différence avec Ubuntu : Arch n’est plus installable en 32 bits (enfin, si : des gens ont mis en place Arch Linux 32, mais ce n’est qu’une version communautaire), mais elle maintient l’usage de bibliothèques logicielles 32 bits pour ceux qui en ont besoin. Et ces bibliothèques sont maintenues en même temps (au pire à un ou deux jours près) que leurs versions 64 bits.



Pour Ubuntu, en revanche, les utilisateurs vont apparemment devoir se contenter de garder la dernière version LTS en date de ces bibliothèques 32 bits (pourquoi ne pas avoir gardé au moins les versions de 19.04 ?), et rien ne dit que la prochaine LTS fera une mise à niveau globale de ces dernières.



Ben oui, ça fait quand même quelques années que la plupart des distribs ne fournissent plus de version pour les proco x86 32-bit, mais au moins elles gardent les libs de compatibilité pour ceux qui veulent/doivent encore faire tourner des applications 32-bit.



Chaque année depuis au moins 6 ans, quand on met à jours les OS au boulot, on ne réinstalle pas les bibliothèques de compatibilité 32-bit, et chaque fois, ça ne prend pas 1 semaine pour qu’on vienne nous demander d’en installer quelques-unes <img data-src=" />


Moi je vois ça comme une bonne nouvelle, comme ça les gens laisseront une chance a fedora <img data-src=" />




Au point qu’actuellement, il reste possible que l’éditeur soit contraint de revenir sur sa décision et la décaler.





La décaler une fois c’est ne jamais le faire au final : il y aura toujours quelqu’un pour râler et demander le 32 bits, même dans 10 ans.


@Vincent voilà bien un jugement d’opinion dont tu aurais pu utilement te passer :&nbsp;



“La semaine dernière,&nbsp;Canonical annonçait l’inévitable&nbsp;: dès la prochaine version d’Ubuntu, attendue comme d’habitude pour octobre, le système ne sera plus disponible qu’en 64 bits. Cette décision rejaillit tant sur les variantes officielles (Kubuntu, Xubuntu, etc.) que les distributions dérivées, dont Mint. Elle entraine donc de nombreux systèmes dans son sillage.Elle était cependant prévisible, car le matériel purement 32 bits est devenu très rare et des plateformes importantes ont déjà fait le grand saut ou s’y préparent activement (macOS par exemple).&nbsp;”

&nbsp;

Voilà bien un commentaire qui démontre une méconnaissance totale des enjeux.

Le nombre d’applications 32 bits employées dans le secteur publique, les entreprises privées représente très largement la majorité des applications. Les jeux ne sont que la partie émergée de l’iceberg.&nbsp;



Après, on peut légitimement arguer qu’une entité sérieuse aura pris des bases Debian ou Red Hat pour ses infra ou applis critiques, malgré tout Ubuntu n’est pas complètement inconnu côté desktop grâce justement à son aura de simplicité.



Canonical ne fait que se tirer une roquette à fragmentation entre les deux jambes. Quant à savoir comment ils ont pu prendre une décision aussi débile… Je n’ai pas d’opinion (j’ai lu quelques complotistes disant que MS est derrière, je ne comprends pas bien comment ils ont pu en arriver à cette conclusion XD)&nbsp;











Gats a écrit :



Tout le 32bits est “émulé” sans problème de nos jours, c’est juste qu’il faut avoir accès aux bibliothèques en 32bits pour pouvoir faire cette émulation. Justement ce que Canonical veut supprimer dans les prochaines versions d’Ubuntu.



Marrant comme un commentaire de 2,5 lignes traduit mieux les enjeux. XD



Début de rétropédalage, même si ce n’est pas encore très clair :https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-2…


Je pensais, lors de la première annonce, qu’ils maintiendraient le 32 bits dans des dépôts…. et bien je me suis bien planté. Je ne sais pas si cette position est réellement tenable&nbsp;<img data-src=" />




Au point qu’actuellement, il reste possible que l’éditeur soit contraint de revenir sur sa décision et la décaler

Et c’est donc le cas : Canonical va finalement garder un certain nombre de paquets 32 bits pour les besoins de WINE et consorts, mais compte faire passer tout le monde sur un système de conteneurs (ça va être encore très facile à faire mettre en place par les Michu, ça…) pour, à terme, se débarrasser pour de bon du 32 bits en natif dans Ubuntu.



Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS&nbsp;(Ubuntu.com)







Jarodd a écrit :



La décaler une fois c’est ne jamais le faire au final : il y aura toujours quelqu’un pour râler et demander le 32 bits, même dans 10 ans.



Ça, c’est sûr que, rien qu’avec les joueurs (la plupart des jeux vidéo ne se « périment » pas, et ils sont quasi tous qu’en 32 bits, ceux en 16 bits pouvant être lancés avec DOSBox ou ScummVM), on ne mettra pas fin à l’usage du 32 bits de sitôt, en vrai. ^^



Mais c’est l’éternel fossé entre les envies des développeurs (qui ne jurent que par les dernières technos à la mode et ne veulent plus entendre parler de celles datant du mois précédent) et les besoins réels des utilisateurs lambda (qui, eux, veulent juste que tout marche, quoi que ça puisse être, et sans avoir à bidouiller pour que ça marche).









TheKillerOfComputer a écrit :



Stellaris a obtenu sa version 64 bits que TRES récemment et même encore cette année ont sorti des jeux en 32 bits (Sunless Skies par exemple pourtant fait avec Unity). Le 32 bits est là pour encore longtemps, trop tôt pour s’en séparer.



Surtout un OS qui est presque un oxymore avec le concept de jeux vidéo <img data-src=" />









Salamandar a écrit :



Il n’y a pas de rapport entre le support des applications 32bits et le support des pcs 32bits.

Le second consiste à avoir un noyau 32bits et le support matériel, et est un boulet à se traîner.

Le premier ne consiste qu’à proposer les libraires compilées pour 32bits.



Un exemple : Arch linux a abandonné le support des pcs en 32bits, mais Wine et Steam tournent très bien.





Il faudrais malheureusement qu’un accord entre les différents os (windows, linux (les plus gros), et mac) afin d’empêcher les nouvelles (et j’insiste sur nouvelles) application d’utilisé le 32 bits, et de poussé (par l’affichage d’un message pour les applis 32 bits, a débuté une migration vers le 64 bits.



Si on ne force pas la main des dev ils resteront en 32 bits.

Bien entendu maintenir le support 32 bits pendant cette conversion.



Moi je trouve ça clair : support des dépendances des gros projets communautaires ou commerciaux, et abandon du reste. Ça permet d’éteindre l’incendie sans vraiment répondre à la question. La justification est en revanche bien bancale (je ne comprend pas vraiment ce que les failles des processeurs viennent faire dans ce débat).


Ce qui n’est pas clair, c’est qu’il reste à constituer la liste des paquets, et la partie sur les conteneurs qui selon moi ne répondent pas au problème (potentielles incompatibilités en cas de version différente avec l’hôte pour certains paquets, comment avoir un Mesa à jour pour le support HW, …).



Pour les failles des processeurs, je pense qu’ils parlent de l’année dernière : au moment de la sortie de la 18.04, il n’y avait pas de KPTI (pour Meltdown) sur les kernels 32 bits. Mais il me semble que pour Spectre tout y était, et c’est effectivement un peu hors sujet quand on parle des librairies 32 bits utilisées avec un kernel 64 bits.


“On commence avec Valve, qui ne prévoit tout simplement&nbsp;la fin du support



=&gt; Du coup, Valve ne prévoit pas la fin du support ou bien Valve prévoit la fin du support ?

Soit il manque soit il y a un truc en trop ahah








DanLo a écrit :



“On commence avec Valve, qui ne prévoit tout simplement&nbsp;la fin du support



=&gt; Du coup, Valve ne prévoit pas la fin du support ou bien Valve prévoit la fin du support ?

Soit il manque soit il y a un truc en trop ahah





De toute façon perso un service qui me dit change d’os car notre service marche pas dessus j’ai juste envie de lui dire va te faire voire donc arrêté le support n’est pas une solution (je trouve étrange que leur store (qui n’a rien a voir avec les jeux), ne soit toujours pas en 64 bits).



maintenant il faudra (et pas que sur linux) trouver une solution au vieux jeux 32 bits qui ne sont plus supporté.



C’est marrant, moi c’est plutôt l’OS qui me dit de changer de logiciel que j’ai envie d’envoyer promener…





Plaisanterie mise à part, c’est purement symbolique. Initialement, Valve conseillait Ubuntu car c’était le seul OS Gnu/Linux officiellement supporté (même si dans la pratique ça fonctionnait sur d’autres distributions). Ils vont juste cesser de conseiller Ubuntu, c’est pas violent comme incitation à changer d’OS.


Pour le 32 bits, et pour les vieux PC, Raspberry Pi desktop marche très bien. Il n’est disponible qu’en 32 bits justement.


Oui, mais ce que veulent les gens, c’est faire tourner des logiciels 64 ou 32 bits (ou 16 ou 8, ne soyons pas sectaires) dans leur OS 64 bits sur leur processeur(s) 64 bits. Pour ça il y a à peu près n’importe quelle distribution sauf bientôt celles basées sur Ubuntu. <img data-src=" />


Bon…



Linux Mint + utilisateur de Wine pour Anyrail + imprimante Brother = triple sodo pour moi si j’ai bien compris…








Trit’ a écrit :



Mais c’est l’éternel fossé entre les envies des développeurs (qui ne jurent que par les dernières technos à la mode et ne veulent plus entendre parler de celles datant du mois précédent) et les besoins réels des utilisateurs lambda (qui, eux, veulent juste que tout marche, quoi que ça puisse être, et sans avoir à bidouiller pour que ça marche).






  C'est plus compliqué que ça.       






 Pour la question des jeux vidéos, et après avoir eu l'occasion de perdre mon temps lire des débats de devs et de linuxiens fanatiques sur différents forums, souvent il ressortait que la définition d'un jeu pour certains d'entre eux n'est pas celui des joueurs mainstream. Quand ces derniers demandent du Stellaris/Total War: Warhammer II/GTA, les premiers répondaient Battle for Wesnoth ou Wormux... (je ne dis pas de mal des deux, j'ai joué au premier et bien aimé).       






 En fait, ils obtiennent leur fun dans leurs sessions de coding et leurs optimisations. Donc imaginer qu'un SuperTux ne soit pas aussi fun qu'un GTA, ça génère un kernel panic simplement car ce ne sont pas des joueurs mainstream, sinon des joueurs tout court...     

&nbsp;

Il ne serait pas étonnant que Canonical se soit fourvoyé par un a-priori similaire. Ils ont sous-estimé les attentes du marché et donc la gène que leur décision causera. Alors que pourtant et avec les gros efforts des équipes de Wine et de Valve, aujourd'hui Linux est capable de lancer de vrais jeux.






 Cet OS a du mal à percer dans le marché desktop justement à cause des jeux, pas la peine d'en rajouter... et donc l'idée d'éxiger un master en ingénierie informatique pour faire demain par des conteneurs ce qu'on fait aujourd'hui grâce à Wine et Valve, c'est outrageant.       






 Microsoft l'a bien compris, le marché a une grosse inertie et il est préférable de faire avec plutôt que de lutter. Résultat, la compatibilité avec les anciens Windows est plutôt solide, et même IE a duré longtemps pour éviter que les entreprises ne se sauvent...       

&nbsp;







Aëlisya a écrit :



Il faudrais malheureusement qu’un accord entre les différents os (windows, linux (les plus gros), et mac) afin d’empêcher les nouvelles (et j’insiste sur nouvelles) application d’utilisé le 32 bits, et de poussé (par l’affichage d’un message pour les applis 32 bits, a débuté une migration vers le 64 bits.




  Si on ne force pas la main des dev ils resteront en 32 bits.        

Bien entendu maintenir le support 32 bits pendant cette conversion.





&nbsp;



 L'affichage du message que tu proposes va ennuier l'utilisateur, pas le développeur.       






 Le malaise principal, ce sont les jeux. Une application est plus maléable, surtout aujourd'hui car ils sont pour beaucoup libres/open-source, donc plus susceptibles d'être updaté que durant le passage 16 bits &gt;32 bits.       

&nbsp;

Car un jeu, par définition il ne meurt pas de suite. On peut avoir envie de refaire une partie d'échecs à tout moment, comme on peut vouloir refaire un bon vieux OpenTTD (Transport Tycoon n'avait pas envie de mourrir). Et leur complexité fait que la communauté peut ne pas pouvoir faire un clone libre (entre recoder un Transport Tycoon et un GTA, j'imagine que ce ne doit pas être la même difficulté).

&nbsp;

Problème, leur espérance de vie commerciale est dépassée pour beaucoup et parfois même pas deux ans après leur sortie. Ce qui fait que les exemples à la Stellaris ou même Eve Online qui voient l'arrivé d'une version 64 bits (pour EVE, ça date de quelques jours à peine ! en béta !) sont rares. Et contrairement à l'époque DOS vers Windows, là on a besoin d'une vraie puissance de calcul pour les faire tourner, donc autre chose qu'un DOSBox...








TheKillerOfComputer a écrit :



L’affichage du message que tu proposes va ennuier l’utilisateur, pas le développeur.




  Le malaise principal, ce sont les jeux. Une application est plus maléable, surtout aujourd'hui car ils sont pour beaucoup libres/open-source, donc plus susceptibles d'être updaté que durant le passage 16 bits &gt;32 bits.        

&nbsp;

Car un jeu, par définition il ne meurt pas de suite. On peut avoir envie de refaire une partie d'échecs à tout moment, comme on peut vouloir refaire un bon vieux OpenTTD (Transport Tycoon n'avait pas envie de mourrir). Et leur complexité fait que la communauté peut ne pas pouvoir faire un clone libre (entre recoder un Transport Tycoon et un GTA, j'imagine que ce ne doit pas être la même difficulté).

&nbsp;

Problème, leur espérance de vie commerciale est dépassée pour beaucoup et parfois même pas deux ans après leur sortie. Ce qui fait que les exemples à la Stellaris ou même Eve Online qui voient l'arrivé d'une version 64 bits (pour EVE, ça date de quelques jours à peine ! en béta !) sont rares. Et contrairement à l'époque DOS vers Windows, là on a besoin d'une vraie puissance de calcul pour les faire tourner, donc autre chose qu'un DOSBox...







C’est en effet réel cependant je pensait simplement a l’exemple du cadnas vert sur les navigateurs qui ont poussé les utilisateurs a se détourné des sites ne le proposant pas.



Sauf que le cadenas en question est un indicateur de sécurité (enfin non, mais il l’est devenu pour beaucoup et je n’ai de cesse que de contester ça à la moindre occasion), donc les utilisateurs y ont tenu compte.




     Là on parle d'un élement de "confort" pour les développeurs pour qu'ils ne fassent que du x64 only, et ça l'utilisateur n'y verra aucune importance. En fait, je ne serai pas étonné que cela fasse un peu à l'image des agents municipaux, où on pourrait dire que de jeter son déchet par terre, ça contribue à donner du travail à des gens. Et donc qu'utiliser encore le 32 bits, ça maintient quelques emplois...    






  Ma mentalité serait bien plus hostile encore contre les développeurs <img data-src=">







TheKillerOfComputer a écrit :



Sauf que le cadenas en question est un indicateur de sécurité (enfin non, mais il l’est devenu pour beaucoup et je n’ai de cesse que de contester ça à la moindre occasion), donc les utilisateurs y ont tenu compte.




      Là on parle d'un élement de "confort" pour les développeurs pour qu'ils ne fassent que du x64 only, et ça l'utilisateur n'y verra aucune importance. En fait, je ne serai pas étonné que cela fasse un peu à l'image des agents municipaux, où on pourrait dire que de jeter son déchet par terre, ça contribue à donner du travail à des gens. Et donc qu'utiliser encore le 32 bits, ça maintient quelques emplois...     






   Ma mentalité serait bien plus hostile encore contre les développeurs <img data-src=">







enfait le problème réside je pense en deux (j’ai fais des cours de devellopement et il y a deux enorme problème), 1 les cours actuelle n’explique pas comment codé pour du 64 bits (n’explique meme pas que la configuration par défaut est en 32 bits)(il est possible que cela s’applique que a l’unif ou je suis allée, mais au vu du marché du dev je doute).



Ensuite les chef de boite de dev prefère resté pareille pour rien changer ni reformé, ce qui bloque les école car elle apprenne au étudiant ce qui leur sera utile dans le boulot donc le 32 bits.



Un joli serpent qui se mort la queue donc.



Sans oublier les boites qui se font un pognons fous qui ne font pas le changement, suffi de voir le nombre d’outils windows toujours en 32 bits.

Ou steam qui gagne un fric de fous, mais qui a toujours un launcher en 32.



donc a mon avis les devs sont a moitier responsable car influencé par des conviction financière de leur patron



J’ai une Brother multifonction en Wi-Fi qui marche très bien sur Fedora pour info. Leur sh d’install est bien foutu d’ailleurs.



Après, pour les imprimantes, reste la solution d’un Cups sur un Pi par exemple.



Mais bon, comme je disais sur l’autre actu, à un moment faut se lancer… Certains l’ont déjà fait (me semble qu’AIX est 64bits uniquement, mais le public est plus restreint <img data-src=" /> , MacOS aussi je crois) et au pire, la virtualisation existe.


Le 3264 bits est un problème assez cocasse je trouve. J’ai des vieux ordis en 32bits only (HP T5740).&nbsp;

* Le kernel de certaines distro de retro gaming (toutes d’ailleurs) n’est plus trop testé en 32bits. Leur distro ne fonctionne plus (mise à jour intégrée de la version x.xx vers la y.00 -&gt; plus compatible avec mon T5740)

et recompiler le userland en 32 bits sur un ancien kernel ne fonctionne bien sûr pas du 1er coup, il faut passer des heures pour réussir à passer les messages d’erreur, tout cela pour que ça ne fonctionne toujours pas. a l’inverse, un lecteur audio comme volumio est une plaie à installer sur un ordi 64 bits comme un NUC: la distro n’est qu’en mode 32 bits, avec des pilotes limités, et certains NUC sortent avec un BIOS un peu trop léger sur la couche de compatibilité 32 bits



Bref… aaaarrggggg…








Aëlisya a écrit :



enfait le problème réside je pense en deux (j’ai fais des cours de devellopement et il y a deux enorme problème), 1 les cours actuelle n’explique pas comment codé pour du 64 bits (n’explique meme pas que la configuration par défaut est en 32 bits)(il est possible que cela s’applique que a l’unif ou je suis allée, mais au vu du marché du dev je doute).&nbsp;



On ne code pas vraiment en 32 ou 64bits. On utilise des outils qui compilent en 32 ou 64 bits ou les deux.

Le choix de distribuer en 32 ou 64 bits dépend de la cible.



Le problème soulevé par Wine et Steam, c’est qu’il font fonctionner de vieux jeux qui ne PEUVENT plus être recompilés par ce que:

* la boite a fermé

* les outils n’existent plus

* les outils n’existent qu’en 32bits

* les sources n’existent plus

* le code a été optimisé à mort et cela provoque des bugs en 64 bits



Mais les nouveaux logiciels ne devraient pas poser de problème, tant qu’ils n’ont pas de dépendance x86



Exemple de dépendance pourrie:

* Minecraft fonctionnait jusqu’à l’année dernière sur un Core 2 duo avec Intel GMA

* Minecraft évolue et a besoin de shaders pour l’eau -&gt; les dev mettent à jour la libraire d’affichage qu’ils utilisent

* Implicitement, Minecraft demande maintenant openGL4.4 pour ces nouveaux shaders

* Dans les faits, Minecraft devient incompatible avec tout PC avec une carte Intel GMA, HD3000, HD4x000, bref tout PC portable sans carte dédiée de plus de 4 ans (alors que le HD4600 par exemple va aussi vite qu’en geforce 630)

Je ne suis pas sûr qu’ils avaient voulu cette cassure. Plusieurs joueurs autour de moi jouaient à Minecraft (Java) sur de vieux coucous.



PS: au fait, la compatibilité Linux sous FreeBSD elle supporte le 32bits?









Commentaire_supprime a écrit :



Bon…



Linux Mint + utilisateur de Wine pour Anyrail + imprimante Brother = triple sodo pour moi si j’ai bien compris…



Pareil dans un sens, puisque je comptais basculer sur Mint.

Vu que je n’accroche pas du tout avec Fedora (je ne sais pas pquoi, mais aucune de leurs interfaces que j’ai pu tester m’a donné envie d’y rester…), je sens que je vais passer sur du Debian pur ou du OpenSuSe, voire carrément faire le cinglé et partir directement sur Arch <img data-src=" />



et arrêtez d’ergote sur une évolution en 64 bits ,alors oui sa va impacter de nombreux logiciels et et jeux ,mais n’oubliez pas que valve et consoeur ce sont fait bien du beurre sur leur plateforme et qu’il est temps pour eux d’évoluer et de faire le nécessaire pour suivre et passe au 64 bits ,ils l’on bien fait autre part pourquoi pas sous cet os, et quand on crée un logiciel qui nous a rapporte de l’argent sous 32 bit ,dite moi on est pas foutu de rendre le même service et logiciels sous du 64 bits ??? étonnant non pour des programmeurs en informatique…..


c’est un fait avéré ,mais a ce jour; il est temps de dire adieu a ces jeux ou logiciels qui ont bien vécu et donc soit de les oublie ,soit d’en recrée des nouveaux et j’entend s’adapter a l’évolution de l’informatique ,et de son matériel ; ce qui normalement devrais être le sens meme de la vie de l’informaticien …


l’absence de 16bit, sous Windows, m’ennuie aussi. Véridique.



Sauf qu’ici on ne parle pas d’un nouveau PC, avec un&nbsp; OS fraichement installé. On parle d’une mise à jour qui bloque le fonctionnement de programmes, du jour au lendemain.


Je finis par le plus faire que jouer, alors quel que soit l’OS ce qui m’intéresse c’est le catalogue jouable.



ça a si bien évolué wine?

Car mes derniers essais de steam sous linux étaient pauvres en jeux, et c’était compliqué. Et wine me faisais l’équivalent d’un raspberry: un jouet pour bricoleurs.


Ce n’est pas un jugement de valeur, s’il s’appuie sur des chiffres.


J’ai hâte qu’on nous parle du bug de l’an 2038 à cause des librairies 32bits toujours en utilisation à cette date <img data-src=" />



Pour ceux qui connaisse pas :https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038


Dans la maj de l’article, en anglais il est aussi stipulé que canonical discute avec valve








cyberkronos a écrit :



et arrêtez d’ergote sur une évolution en 64 bits ,alors oui sa va impacter de nombreux logiciels et et jeux ,mais n’oubliez pas que valve et consoeur ce sont fait bien du beurre sur leur plateforme et qu’il est temps pour eux d’évoluer et de faire le nécessaire pour suivre et passe au 64 bits ,ils l’on bien fait autre part pourquoi pas sous cet os, et quand on crée un logiciel qui nous a rapporte de l’argent sous 32 bit ,dite moi on est pas foutu de rendre le même service et logiciels sous du 64 bits ??? étonnant non pour des programmeurs en informatique…..







Le problème ne vient pas de STEAM. On peut imaginer qu’il ne soit pas si difficile pour eux de passer en 64 bits. Mais le plus important, le contenu de la bibliothèque, demande encore très souvent le 32 bits.







cyberkronos a écrit :



c’est un fait avéré ,mais a ce jour; il est temps de dire adieu a ces jeux ou logiciels qui ont bien vécu et donc soit de les oublie ,soit d’en recrée des nouveaux et j’entend s’adapter a l’évolution de l’informatique ,et de son matériel ; ce qui normalement devrais être le sens meme de la vie de l’informaticien …





Ou pas.

Il est actuellement toujours relativement facile de supporter le 32 bits sous Linux, pourquoi s’en priver.

De plus tous les utilisateurs linux / joueurs ne sont pas des “informaticiens”.



Et merci pour ta sainte parole, mais on va s’en passer, surtout quand elle est si mal exprimée.



Tout a fait, je me traîne un win 32 bits a cause d’un vieux scanner qui fonctionne très bien mais qui n’a pas de driver 64bits et je refuse d’en acheter un neuf a cause de ca&nbsp;<img data-src=" />

Et manque de bol, il est mal supporté par linux.


Transport Tycoon <img data-src=" />








dematbreizh a écrit :



Ce n’est pas un jugement de valeur, s’il s’appuie sur des chiffres.







Tu as raison, ce n’est pas un jugement de valeur, c’est la démonstration qu’il n’a rien compris des enjeux au moment de la rédaction de l’article initial.



Justifier l’abandon de tout support du 32 bits par le nombre de machines purement 32 bits est une connerie sans nom. C’est ne pas comprendre que l’on perd ainsi la possibilité de faire tourner tout logiciel n’existant qu’en 32 bits.



La seule chose que justifie le faible nombre de machines purement 32 bits, c’est de ne plus supporter les distributions 32 bits.



Resident Evil 2 Remake a environs 120 FPS avec Proton ou bien Wine 4.1 sur Ubuntu. <img data-src=" />








Trit’ a écrit :



Mais c’est l’éternel fossé entre les envies des développeurs (qui ne jurent que par les dernières technos à la mode et ne veulent plus entendre parler de celles datant du mois précédent) et les besoins réels des utilisateurs lambda (qui, eux, veulent juste que tout marche, quoi que ça puisse être, et sans avoir à bidouiller pour que ça marche).







Y’a plus que ça. Certains développeurs sont inconscient et fonce tête baissée vers la nouveauté, d’autres sont conscient des enjeux de sécurité lorsqu’il s’agît d’abandonner de vieilles technos, et d’autres encore n’en ont vraiment rien à secouer de maintenir de l’ancien (les éditeurs de pilotes d’imprimante, par exemple). Les utilisateurs, eux, veulent effectivement que tout marche sans se soucier de quoi que ce soit… M’enfin c’est pas magique, y’a rien qui fonctionne ad vitam si tu ne t’en soucies pas un minimum. Et ils (nous, en fait, je m’inclue dedans) sont plus ou moins inconscients des enjeux de sécurité, de norme, d’unification, et plus largement des mécanismes qui supporte la technologie qu’ils utilisent. On se plaint par exemple que les pilotes d’imprimantes ne soient pas maintenus… mais à aucun moment ça fait parti des critères d’achat ou d’éventuelles revendications auprès des fabricants. Comment veux-tu avoir des exigences dans un domaine, et qu’elles soient prises en compte, si tu ne t’impliques pas un minimum ? :/









Aëlisya a écrit :



Il faudrais malheureusement qu’un accord entre les différents os (windows, linux (les plus gros), et mac) afin d’empêcher les nouvelles (et j’insiste sur nouvelles) application d’utilisé le 32 bits, et de poussé (par l’affichage d’un message pour les applis 32 bits, a débuté une migration vers le 64 bits.



Si on ne force pas la main des dev ils resteront en 32 bits.

Bien entendu maintenir le support 32 bits pendant cette conversion.





C’est pas aussi simple que ca: par exemple chez Microsoft, l’équipe de développement a expliqué plusieurs fois pourquoi ils ne voulaient PAS migrer Visual Studio en 64bits. Pour résumer (très vite), les binaires seraient plus gros et l’empreinte mémoire supérieure (les pointeurs étant sur 8 octets au lieu de 4 notamment).









Aëlisya a écrit :



C’est en effet réel cependant je pensait simplement a l’exemple du cadnas vert sur les navigateurs qui ont poussé les utilisateurs a se détourné des sites ne le proposant pas.





Ce ne sont pas les utilisateurs qui se sont détournés des sites “Sans le cadenas vert”, ce sont les utilisateurs qui&nbsp; ont été détournés par Google qui les a favorisé dans ses résultats de recherche. Ce n’est pas la même chose.



C’est bien parce que les exploitants de sites internet n’ont plus le choix que la transition s’effectue vers le https, pas parce que l’utilisateur le demande.









cyberkronos a écrit :



c’est un fait avéré ,mais a ce jour; il est temps de dire adieu a ces jeux ou logiciels qui ont bien vécu et donc soit de les oublie ,soit d’en recrée des nouveaux et j’entend s’adapter a l’évolution de l’informatique ,et de son matériel ; ce qui normalement devrais être le sens meme de la vie de l’informaticien …





Euh, oublier les envies et les besoins pour favoriser l’évolution de la techno et des marchands de matos, c’est totalement absurde.

Ça résume bien ce concept: “L’informatique permet de faire plus vite ce qu’on avait pas besoin de faire avant.”



Perso en tant que dev ce qui m’intéresse c’est que l’utilisateur trouve son compte. Pas de lui compliquer la vie pour que je puisse tester un nouveau truc. (en projets persos par contre spa pareil…)

&nbsp;





dematbreizh a écrit :



Je finis par le plus faire que jouer, alors quel que soit l’OS ce qui m’intéresse c’est le catalogue jouable.



ça a si bien évolué wine?

Car mes derniers essais de steam sous linux étaient pauvres en jeux, et c’était compliqué. Et wine me faisais l’équivalent d’un raspberry: un jouet pour bricoleurs.





Steam s’est installé super facilement, là j’ai Pillars of Eternity qui tourne vraiment bien, mais bon ma liste n’est pas typique du gamer (Factorio, Baldur, quelques jeux coops, CS pour la pause au boulot).









cyberkronos a écrit :



c’est un fait avéré ,mais a ce jour; il est temps de dire adieu a ces jeux ou logiciels qui ont bien vécu et donc soit de les oublie ,soit d’en recrée des nouveaux et j’entend s’adapter a l’évolution de l’informatique ,et de son matériel ; ce qui normalement devrais être le sens meme de la vie de l’informaticien …



Tu parles à quelqu’un qui a encore son atari 800XL en état de marche :-)&nbsp;



Je te rejoins en partie - car si dans la partie grand public de l’informatique on peut se permettre de jeter les vielles choses facilement, ce n’est pas le point de vue de l’industrie - où j’ai rencontré des logiciels qui ont parfois 20ans ou + et sont encore maintenus.



Après soyons clairs: un vieux système n’a pas besoin du dernier linux. On peut le laisser dans son jus. La difficulté actuellement est de trouver un état cohérent entre l’appli 32 bits et les systèmes qu’on peut télécharger - sans se soucier des correctifs de sécurité.

&nbsp;

Par contre, quand on a besoin des correctifs de sécurité à passer ou de nouvelles fonctionnalités, ça se gâte. Parfois sous Linux (ou autre - VMS par exemple) on est bloqué sur un noyau, un compilateur, une lib proprio et une simple recompilation est impossible - il faudrait backporter, ce qui n’est pas toujours économiquement viable.

&nbsp;





the_cat a écrit :



J’ai hâte qu’on nous parle du bug de l’an 2038 à cause des librairies 32bits toujours en utilisation à cette date <img data-src=" />



Pour ceux qui connaisse pas :https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038



Les programme 32bits peuvent aussi utiliser des 64bits, beaucoup sont corrigés. A l’inverse, des programmes 64bits codent encore la date à l’ancienne mode. Et on peut imaginer que certains systèmes intégrés (appliances) qu’on achèterait maintenant pour 10 ans n’ont pas de correctif.









cyberkronos a écrit :



et arrêtez d’ergote sur une évolution en 64 bits ,alors oui sa va impacter de nombreux logiciels et et jeux ,mais n’oubliez pas que valve et consoeur ce sont fait bien du beurre sur leur plateforme et qu’il est temps pour eux d’évoluer et de faire le nécessaire pour suivre et passe au 64 bits ,ils l’on bien fait autre part pourquoi pas sous cet os, et quand on crée un logiciel qui nous a rapporte de l’argent sous 32 bit ,dite moi on est pas foutu de rendre le même service et logiciels sous du 64 bits ??? étonnant non pour des programmeurs en informatique…..



Valve n’est pas foutu de modifier les jeux qui ne leur appartient pas en 64 bits, non… Parce qu’ils n’ont juste pas le droit.









dematbreizh a écrit :



l’absence de 16bit, sous Windows, m’ennuie aussi. Véridique.



Sauf qu’ici on ne parle pas d’un nouveau PC, avec un  OS fraichement installé. On parle d’une mise à jour qui bloque le fonctionnement de programmes, du jour au lendemain.







Il me semble que DosBox permet de lancer des logiciels 16bit (je ne pense pas qu’ils tournent sur autre chose qu’un DOS). Puis tu peux faire un petit raccourcis/script qui execute le programme via dosbox : double clic, paf ça lance le programme.









CryoGen a écrit :



Le problème ne vient pas de STEAM. On peut imaginer qu’il ne soit pas si difficile pour eux de passer en 64 bits. Mais le plus important, le contenu de la bibliothèque, demande encore très souvent le 32 bits.

Ou pas.

Il est actuellement toujours relativement facile de supporter le 32 bits sous Linux, pourquoi s’en priver.

De plus tous les utilisateurs linux / joueurs ne sont pas des “informaticiens”.



Et merci pour ta sainte parole, mais on va s’en passer, surtout quand elle est si mal exprimée.







En soit, de ce que j’ai compris, ce n’est pas la facilité de “supporter” le 32bit qui pose problème, c’est de garder les bibliothèque à jour, compatibles et sécurisés. On peut voir 2 intérêts dans le fait de forcer l’utilisation de conteneur :

* freezer dans un environnement fonctionnel un programme qui pouvait casser à la moindre MaJ.

* isoler du système les éventuelles faille de programmes/bibliothèque plus maintenu.




Le problème des librairies 32 bits et des jeux n’est pas le seul qui a agité la communauté Ubuntu ces derniers jours, même si pour l’autre les développeurs maintiennent leur position : comme Canonical délaisse le Desktop&nbsp; pour se concentrer sur les serveurs et les objets connectés, les équipes bossant sur la version classique sont ultra-réduites, et ils commencent à remplacer - dans les applis par défaut et même de manière définitive, les deb par des snaps : ainsi, à partir de la 19.10 Chromium sera uniquement disponible en snap et plus dans les paquets deb…



https://community.ubuntu.com/t/please-do-not-use-snap-into-ubuntu-its-too-early/…



Alors oui les snaps permettent des mises à jour plus faciles sur les anciennes versions, Chromium demandait un travail colossal pour l’adapter à chacune des versions supportées, mais ils ont encore plein de défaut (de jeunesse) : 1er démarrage très long, beaucoup plus de place prise sur le disque du fait que chacun embarque toutes ses librairies nécessaires, le confinement fait que par défaut les applications ne peuvent écrire sur une autre partition que /home (il faut le configurer pour chacune individuellement) ni “communiquer” entre elles…



Bref techno pas encore mûre pour le grand public, à voir si pour la 20.04 il y aura là aussi rétro-pédalage ! <img data-src=" />


Oui bon après de la même façon qu’Ubuntu voulait interdire (de fait) les apps 32 bits, comme Apple l’a déjà fait, Valve pourrait faire le même choix sur sa plateforme pour s’assurer de la compatibilité.



Je ne dis pas que ça serait une bonne idée, juste que c’est une possibilité et qu’ils n’ont rien fait ces dernières années pour pousser au passage au 64 bits alors qu’ils devaient bien sentir que ça allait arriver.








Pseudooo a écrit :



Ce ne sont pas les utilisateurs qui se sont détournés des sites “Sans le cadenas vert”, ce sont les utilisateurs qui&nbsp; ont été détournés par Google qui les a favorisé dans ses résultats de recherche. Ce n’est pas la même chose.



C’est bien parce que les exploitants de sites internet n’ont plus le choix que la transition s’effectue vers le https, pas parce que l’utilisateur le demande.





Corrections : C’est bien parce que les exploitants/commanditaire de sites internet n’ont plus le

choix que la transition s’effectue vers le https, pas parce que

l’utilisateur le demande ou que le développeur n’écoute que lui-même.









ErGo_404 a écrit :



Oui bon après de la même façon qu’Ubuntu voulait interdire (de fait) les apps 32 bits, comme Apple l’a déjà fait, Valve pourrait faire le même choix sur sa plateforme pour s’assurer de la compatibilité.



Je ne dis pas que ça serait une bonne idée, juste que c’est une possibilité et qu’ils n’ont rien fait ces dernières années pour pousser au passage au 64 bits alors qu’ils devaient bien sentir que ça allait arriver.



Virer 90% du catalogue, ca m’étonnerait que ca soit une idée qui leur plaise…









cyberkronos a écrit :



et arrêtez d’ergote sur une évolution en 64 bits ,alors oui sa va impacter de nombreux logiciels et et jeux ,mais n’oubliez pas que valve et consoeur ce sont fait bien du beurre sur leur plateforme et qu’il est temps pour eux d’évoluer et de faire le nécessaire pour suivre et passe au 64 bits ,ils l’on bien fait autre part pourquoi pas sous cet os, et quand on crée un logiciel qui nous a rapporte de l’argent sous 32 bit ,dite moi on est pas foutu de rendre le même service et logiciels sous du 64 bits ??? étonnant non pour des programmeurs en informatique…..





Comme dit dans l’article, le problème n’est pas tant le client Steam que les jeux, en majorité en 32 bits. Valve peut adapter le client, mais il ne peut pas modifier tous les jeux, surtout quand ils ne sont pas les siens.





Citan666 a écrit :



@Vincent voilà bien un jugement d’opinion dont tu aurais pu utilement te passer :&nbsp;



“La semaine dernière,&nbsp;Canonical annonçait l’inévitable&nbsp;: dès la prochaine version d’Ubuntu, attendue comme d’habitude pour octobre, le système ne sera plus disponible qu’en 64 bits. Cette décision rejaillit tant sur les variantes officielles (Kubuntu, Xubuntu, etc.) que les distributions dérivées, dont Mint. Elle entraine donc de nombreux systèmes dans son sillage.Elle était cependant prévisible, car le matériel purement 32 bits est devenu très rare et des plateformes importantes ont déjà fait le grand saut ou s’y préparent activement (macOS par exemple).&nbsp;”

&nbsp;

Voilà bien un commentaire qui démontre une méconnaissance totale des enjeux.

Le nombre d’applications 32 bits employées dans le secteur publique, les entreprises privées représente très largement la majorité des applications. Les jeux ne sont que la partie émergée de l’iceberg.&nbsp;



Après, on peut légitimement arguer qu’une entité sérieuse aura pris des bases Debian ou Red Hat pour ses infra ou applis critiques, malgré tout Ubuntu n’est pas complètement inconnu côté desktop grâce justement à son aura de simplicité.



Canonical ne fait que se tirer une roquette à fragmentation entre les deux jambes. Quant à savoir comment ils ont pu prendre une décision aussi débile… Je n’ai pas d’opinion (j’ai lu quelques complotistes disant que MS est derrière, je ne comprends pas bien comment ils ont pu en arriver à cette conclusion XD)&nbsp;





Marrant comme un commentaire de 2,5 lignes traduit mieux les enjeux. XD





&nbsp;



fred42 a écrit :



Tu as raison, ce n’est pas un jugement de valeur, c’est la démonstration qu’il n’a rien compris des enjeux au moment de la rédaction de l’article initial.



Justifier l’abandon de tout support du 32 bits par le nombre de machines purement 32 bits est une connerie sans nom. C’est ne pas comprendre que l’on perd ainsi la possibilité de faire tourner tout logiciel n’existant qu’en 32 bits.



La seule chose que justifie le faible nombre de machines purement 32 bits, c’est de ne plus supporter les distributions 32 bits.





Je vous trouve un peu durs, alors que l’intégralité du papier vient justement détailler les vrais problèmes entrainés par la décision de Canonical.



Ce sont bien eux qui ont parlé du petit 1 % de machines et de leur vision de ce que serait un avenir merveilleux tout en 64 bits. Mais je pense que le sous-titre montre assez clairement ce que j’en pense. L’émulation 32 bits, Mesa, les pilotes, le forcing vers les conteneurs, la nécessité de ne laisser personne de côté, le probable rétropédalage (qui survenait quelques heures après), la vacuité d’une situation où un système très utilisé se retrouverait sans des applications très courantes, les économies sur le support, tout ça est dans le papier.



Mais le mouvement reste inévitable. Ce qui n’empêche pas que Canonical s’est précipité, ce que là encore je dis dans le papier. Ce n’est pas parce que ça se fera forcément dans les années qui viennent que ça doit se faire tout de suite sans presque aucune préparation. Même là avec leur annonce d’hier soir, ne laisser que quatre mois semble vraiment très court.



+1

Je suis étonné que MS ou Valve n’exigent pas au moins au nouveaux jeux ou programmes d’être au moins en 64bits. Libre aux dévellopeurs de proposer du 32 bits aussi.

Cela facilitera la transition ultérieu

Apple a procédé ainsi pour ses iPhones.

J’ignore où en est Google avec Android.



De même Apple impose aussi que les applications pour IPhone fonctionne aussi en IPv6 only. À ma connaissance rien de tel prévu chez MS et Google.

La transition IPv4 -&gt; IPv6 sera longue.


Android c’est en cours également, à compter du 1er août les devs auront l’obligation de proposer une version 64 bits à toutes leurs nouvelles apps et mises à jour.


Sous Windows, par défaut, un projet un “Any CPU” soit, AMD64, ARM64, x86, ARM32 (du moins pour les applications universelles), mais le 32bits reste privilégié.



Pour des tas de logiciels, passer en 64bits se limite à recompiler, j’ai moi aussi du mal avec cette logique de rester uniquement en 32bits. Après, ça peut aussi être lié à des dépendances ou un manque de temps.



Dans mon boulot, on reste encore en 32 bits (sauf pour les serveurs ou on va sans doute basculer en 64bits), car il faut qu’on mette à jour le code de vieilles dépendances (pour lesquelles on a heureusement le source).


C’est sûr que non et ils auraient tord. Mais ils pourraient quand même inciter à faire le changement, à défaut de supprimer le catalogue existant.

Par exemple, en réduisant légèrement leur commission sur les jeux 64 bits, ou en proposant des formations ou je ne sais quoi.

Ils ont CHOISI de ne rien faire, et en cela je trouve qu’ils sont responsables aussi.








TheKillerOfComputer a écrit :



Pour la question des jeux vidéos, et après avoir eu l’occasion de&nbsp;perdre mon temps&nbsp;lire des débats de devs et de linuxiens fanatiques sur différents forums, souvent il ressortait que la définition d’un jeu pour certains d’entre eux n’est pas celui des joueurs mainstream. Quand ces derniers demandent du Stellaris/Total War: Warhammer II/GTA, les premiers répondaient Battle for Wesnoth ou Wormux… (je ne dis pas de mal des deux, j’ai joué au premier et bien aimé).&nbsp;



En fait, ils obtiennent leur fun dans leurs sessions de coding et leurs optimisations. Donc imaginer qu’un SuperTux ne soit pas aussi fun qu’un GTA, ça génère un kernel panic simplement car ce ne sont pas des joueurs mainstream, sinon des joueurs tout court…



Moi non plus, je suis pas un gamer, mais je vais pas pour autant dire à quelqu’un qui veut son AAA qu’il va devoir se contenter de 0AD (excellent au demeurant, mais Age of Empires&nbsp;qui est son inspiration directe, c’était… il y a 20 ans ! Faudrait penser à entrer dans le XXIe siècle et ne pas se contenter du XXe pour les jeux disponibles nativemement sur le manchot, sans passer par des bidouilles comme Wine pour y parvenir).







tazvld a écrit :



Il me semble que DosBox permet de lancer des logiciels 16bit (je ne pense pas qu’ils tournent sur autre chose qu’un DOS).&nbsp;



Heu, avant Windows 95, Windows et tous ses programmes n’étaient qu’en 16 bits (sauf sur Windows NT 3.x, mais ce n’était pas la même branche d’OS et ils n’étaient réservés qu’aux entreprises jusqu’à XP). Et ils ne sont pas utilisables sous DOSBox (sauf à y installer Windows 3.x, ce qui est faisable).



La différence d’Apple (et de Google), c’est surtout qu’ils maîtrisent toute la chaîne et surtout qu’il n’y a qu’une chaîne de compilation et a priori une option à changer pour tout compiler en 64 bits.

C’est sûrement plus complexe pour les applis desktop.

Mais c’est possible, il faut juste laisser plus de temps (par exemple, annoncer qu’ils feront le changement dans 2 ans, ce qui laisse le temps de s’adapter pour la plupart des devs).


Pourquoi il font pas comme Arch ? Le dépôt multilib a toujours les librairies 32-bits, faisant que Steam et les jeux marchent très bien.



Perso j’utilise carrément steam-native, qui remplace une bonne partie du runtime Steam par des libs installées sur le système, ça fait le taf.








Edtech a écrit :



Sous Windows, par défaut, un projet un “Any CPU” soit, AMD64, ARM64, x86, ARM32 (du moins pour les applications universelles), mais le 32bits reste privilégié.





Any CPU c’est que sous .Net hein, parce qu’il y’a de l’IL derrière ;)









Edtech a écrit :



Sous Windows, par défaut, un projet un “Any CPU” soit, AMD64, ARM64, x86, ARM32 (du moins pour les applications universelles), mais le 32bits reste privilégié.



Pour des tas de logiciels, passer en 64bits se limite à recompiler, j’ai moi aussi du mal avec cette logique de rester uniquement en 32bits. Après, ça peut aussi être lié à des dépendances ou un manque de temps.



Dans mon boulot, on reste encore en 32 bits (sauf pour les serveurs ou on va sans doute basculer en 64bits), car il faut qu’on mette à jour le code de vieilles dépendances (pour lesquelles on a heureusement le source).





je suis personnellement d’accord, toute les grosse boite de dev on toujours le code source de leur logiciel donc recompiler poserais pas problème.



Si comme le cas de l’https on avait 90% des logiciel (sans les jeux anciens), en 64 bits, le nombre de librairie 32 bits supporté par les os diminuerais beaucoup et ainsi la taille de l’os lui même.









ErGo_404 a écrit :



La différence d’Apple (et de Google), c’est surtout qu’ils maîtrisent toute la chaîne et surtout qu’il n’y a qu’une chaîne de compilation et a priori une option à changer pour tout compiler en 64 bits.

C’est sûrement plus complexe pour les applis desktop.

Mais c’est possible, il faut juste laisser plus de temps (par exemple, annoncer qu’ils feront le changement dans 2 ans, ce qui laisse le temps de s’adapter pour la plupart des devs).





je doute grandement, il suffi de voir le GDPR (RGPD), ils ont tous attendu le dernier moment pour raler qu’il n’avaient pas le temp, alors qu’il avais eu plusieurs année de préparation.



Donc a moins de les forcés par un blocage progressif OU une amélioration financière, rien ne changera seul.



La mise en place de la RGPD est autrement plus complexe, elle remet souvent en question toute l’organisation des boîtes qui étaient un peu limites sur la gestion des données personnelles, qui plus est l’incitation n’était pas très forte, les risques sont limités pour les petites boîtes. Alors que disparaître de la plus grosse boutique de jeux, c’est un risque énorme pour un éditeur.



Et valve aurait pu faire un déploiement progressif, en gros garder les vieux jeux tel quels mais refuser les nouveaux jeux non 64 bits. Ca aurait au moins amorcé le mouvement.








Trit’ a écrit :



Moi non plus, je suis pas un gamer, mais je vais pas pour autant dire à quelqu’un qui veut son AAA qu’il va devoir se contenter de 0AD (excellent au demeurant, mais Age of Empires&nbsp;qui est son inspiration directe, c’était… il y a 20 ans ! Faudrait penser à entrer dans le XXIe siècle et ne pas se contenter du XXe pour les jeux disponibles nativemement sur le manchot, sans passer par des bidouilles comme Wine pour y parvenir).





Le facteur nostalgie a aussi son importance.



Et malheureusement tous les jeux n’ont pas de remake alors que certains peuvent être indémodables, et d’autres ont parfois des versions récentes catastrophiques faisant qu’on préfère rester sur les anciens touss Heroes of Might and Magic 7 touss, et la compatibilité Linux n’est pas encore aujourd’hui une garantie.



Beaucoup ont eu droit à des tentatives de remake communautaire compatible Linux au passage mais qui n’ont jamais été achevés, ou ont dévié de façon si considérable que ça n’a rien à voir avec l’original. Par exemple, Total Annihilation a vu Spring TA (et Zero-K) qui a peu de choses à voir sinon les unités… Quelqu’un semble parti pour un VRAI remake à ce que j’ai lu, et j’espère que cette fois c’est la bonne car l’original a de serieux soucis avec le multijoueur sur systèmes modernes… sauf qu’il ne sera sûrement pas compatible Linux, en tout cas il n’en faisait pas mention.



D’autres ont des remakes en cours de développement, mais encore assez instables pour pouvoir y jouer sans soucis (CorsixTH, etc.).



Il y a parfois des versions remastered… qui ajoutent des problèmes qui n’existaient pas avant. Je citerai Heroes of Might & Magic 3 - HD Edition… qui n’a pas ses addons de l’époque, curieusement… et dont la qualité graphique est discutable (ont-ils juste passé les textures à l’agrandisseur ?)… et qui n’est pas compatible Linux (lol ?) et au final on préfère resortir l’original patché avec heroes3hd+ (un excellent patch communautaire) qui tourne bien avec WINE.

&nbsp;

Et parfois, il y a des licences qui se portent bien, qu’on aime bien jouer, mais défois on ressort une vieille version parce que c’était plus simple (Civnet, etc.), moins fouilli graphiquement… Juste toi et le challenge, rien au milieu.

&nbsp;



“Ubuntu a fait un demi-tour partiel.” J’aime beaucoup cette expression et toutes ses formes dérivées.



Elles me rappellent ma jeunesse et le fâmeux “Monsieur a son avenir devant lui, mais il l’aura dans le dos chaque fois qu’il fera demi-tour…” du SAR RABINDRANATH DUVAL !



&nbsp;








ErGo_404 a écrit :



La différence d’Apple (et de Google), c’est surtout qu’ils maîtrisent toute la chaîne et surtout qu’il n’y a qu’une chaîne de compilation et a priori une option à changer pour tout compiler en 64 bits.

C’est sûrement plus complexe pour les applis desktop.&nbsp;&nbsp;



Exemple de complexité:&nbsp;Comment choisir entre office x86 et office x64



Office en entreprise doit être installé en 32 ou 64bits selon les logiciels autour. Certains vieux logiciels ne pourront pas ouvrir office x64, tandis que Office 32bits a des limitations de fonctionnalités (comme Powerpivot qui manque). Dans le même temps, de nouveaux logiciels en .Net “Any CPU” tenteront d’accéder à office dans leur mode d’exécution (x64 ou x86), ce qui crée un beau bazar.



De même certains programmes Java ont un lien vers une DLL 32bits -&gt; il faut Java 32 bits…









Trit’ a écrit :



Moi non plus, je suis pas un gamer, mais je vais pas pour autant dire à quelqu’un qui veut son AAA qu’il va devoir se contenter de 0AD (excellent au demeurant, mais Age of Empires qui est son inspiration directe, c’était… il y a 20 ans ! Faudrait penser à entrer dans le XXIe siècle et ne pas se contenter du XXe pour les jeux disponibles nativemement sur le manchot, sans passer par des bidouilles comme Wine pour y parvenir).





Techniquement, Android tourne sur Linux. Ce qui fait de Linux le premier OS de jeux vidéo <img data-src=" /> .







Trit’ a écrit :



Heu, avant Windows 95, Windows et tous ses programmes n’étaient qu’en 16 bits (sauf sur Windows NT 3.x, mais ce n’était pas la même branche d’OS et ils n’étaient réservés qu’aux entreprises jusqu’à XP). Et ils ne sont pas utilisables sous DOSBox (sauf à y installer Windows 3.x, ce qui est faisable).





Windows 3 (3.13.11) était 16bit ?! ha ouai, tiens. Je ne le savais même pas.



Effectivement, il faut installer Windows 3.X sur DOSbox du coup. Mais je viens de voir ça sinon :http://www.columbia.edu/~em36/win31dosbox.html qui semble être effectivement une version un peu plus automatisé.



Pour les vieux jeux et les vieilles applications (hors ligne) je pense qu’il sera toujours possible de les faire tourner dans un environnement dédié (à l’image de DosBox pour les jeux DOS), en revanche, STEAM aura du mal à contrôler son DRM.



Il n’y a que l’accès au réseau qui nécessite d’assurer un Maintien en Condition de Sécurité.








tazvld a écrit :



En soit, de ce que j’ai compris, ce n’est pas la facilité de “supporter” le 32bit qui pose problème, c’est de garder les bibliothèque à jour, compatibles et sécurisés. On peut voir 2 intérêts dans le fait de forcer l’utilisation de conteneur :

* freezer dans un environnement fonctionnel un programme qui pouvait casser à la moindre MaJ.

* isoler du système les éventuelles faille de programmes/bibliothèque plus maintenu.







Oui c’est pas mal comme solution effectivement. Mais ca veut dire qu’il faut repack tous les jeux dans ce cas.




Il tourne sur un noyau&nbsp; Linux très, très modifié. <img data-src=" />


Derrière une grosse VM Java. Mais ça reste linux tout en bas, en creusant très très profond.



Linux est l’OS le plus utiliser pour jouer, et même le plus utilisé tout court, et il y en a encore qui râlent…


Généralement quand on dit Linux, on parle bien évidemment de GNU/Linux, et donc de Linux desktop. <img data-src=" />


Nous parlions de cette partie de l’article “Elle était cependant prévisible, car le matériel purement 32 bits est devenu très rare et des plateformes importantes ont déjà fait le grand saut ou s’y préparent activement (macOS par exemple).” Et je suis désolé, là, c’est bien toi qui parles (en reprenant peut-être ce qu’a dit Canonical, mais cela n’apparaît pas).



Par contre, oui, je suis un peu dur par rapport à l’ensemble de l’article où tu émettais des réserves sur leur décision.



Quant à mon “connerie sans nom”, pour éviter les ambiguïtés, cela visait Canonical.



Si Canonical délaisse le desktop (ce qui a l’air d’être la cas), je vais chercher une autre distrib en remplacement à la fin de la vie de ma 18.04.


C’est un détail ça. C’est linux, c’est tout. Et Android, c’est aussi une licence Libre, ça serait du Apache 2.0 et du GPLv2. Alors bon, c’est de la bataille de clocher tout ça. Il faut arrêter de se disperser, arrêter de perdre son temps à développer un bureau qui n’a jamais rencontré de succès depuis pratiquement 30ans (28ans d’échec, même Kasparov aurait eu l’esprit d’abandonné) et se concentrer sur ce qui fonctionne.








TheKillerOfComputer a écrit :



Le facteur nostalgie a aussi son importance.




Et malheureusement tous les jeux n'ont pas de remake alors que certains peuvent être indémodables, et d'autres ont parfois des versions récentes catastrophiques faisant qu'on préfère rester sur les anciens *touss* Heroes of Might and Magic 7 *touss*, et la compatibilité Linux n'est pas encore aujourd'hui une garantie.     





Beaucoup ont eu droit à des tentatives de remake communautaire compatible Linux au passage mais qui n’ont jamais été achevés, ou ont dévié de façon si considérable que ça n’a rien à voir avec l’original. Par exemple, Total Annihilation a vu Spring TA (et Zero-K) qui a peu de choses à voir sinon les unités… Quelqu’un semble parti pour un VRAI remake à ce que j’ai lu, et j’espère que cette fois c’est la bonne car l’original a de serieux soucis avec le multijoueur sur systèmes modernes… sauf qu’il ne sera sûrement pas compatible Linux, en tout cas il n’en faisait pas mention.



D’autres ont des remakes en cours de développement, mais encore assez instables pour pouvoir y jouer sans soucis (CorsixTH, etc.).



Il y a parfois des versions remastered… qui ajoutent des problèmes qui n’existaient pas avant. Je citerai Heroes of Might & Magic 3 - HD Edition… qui n’a pas ses addons de l’époque, curieusement… et dont la qualité graphique est discutable (ont-ils juste passé les textures à l’agrandisseur ?)… et qui n’est pas compatible Linux (lol ?) et au final on préfère resortir l’original patché avec heroes3hd+ (un excellent patch communautaire) qui tourne bien avec WINE.

&nbsp;

Et parfois, il y a des licences qui se portent bien, qu’on aime bien jouer, mais défois on ressort une vieille version parce que c’était plus simple (Civnet, etc.), moins fouilli graphiquement… Juste toi et le challenge, rien au milieu.

&nbsp;





+1 Il y a tellement de bon jeux avant les années 2010 ou même 2000.

Qui n’est jamais retourner sur un jeux que tu as retourné plusieurs fois étant gamin ?

Ou même refait une partie de multi/coop avec des potes que tu connais depuis x années sur un jeux qui est archaïque mais tellement délirant ?

La nostalgie, se rappeler, c’est comme les photos ou les romans… on y retourne que pour le plaisir…



Quand je vois comment certain jeux son remastériser… non non et encore non.

[oups]On est pas des nazis qui veulent cramer des bouquins ![\oups]









dylem29 a écrit :



Généralement quand on dit Linux, on parle bien évidemment de GNU/Linux, et donc de Linux desktop. <img data-src=" />





Euh non. Quand on dit linux, on dit linux, donc le noyau.

C’e s t ce qui permet d’avoir l i nux sur des smarts, des routeurs, des RPi, etc. et de retrouver ses petits …



Toi peut-être, mais la majorité des gens, quand ils parlent de&nbsp; Linux, ils veulent dire “GNU/Linux”.



&nbsp;


Oui, enfin non, du point libertés des utilisateurs, c’est pas du tout la même chose. Android est un système pas mal fermé (va te débarrasser facilement des services Google par exemple ou des applis préinstallées).



Quant à abandonner le desktop pour Linux, les millions d’utilisateurs qui ont décidé d’utiliser Linux au quotidien en lieu et place de Windows/MacOS te remercient.

Il y a +800 M d’utilisateurs sous Windows 10 d’après MS (https://news.microsoft.com/bythenumbers/en/windowsdevices ). Si on extrapole à partir du graph des OS de NetMarketShare (avec tous les défauts que cela peut avoir) (https://netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filt… ), cela nous donne environ 2 milliards d’utilisateurs d’un pc dont Linux représente 2% (https://netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filt… ) soit environ 40 millions d’utilisateurs sous Linux.

Ce n’est pas beaucoup comparé au total et au poids que représentent les serveurs pour Linux, mais on est quand même un certain nombre qui ne seraient pas très content qu’on suive des avis comme le tien.



Après, la dispersion des ressources pour faire un n-ième DE qui ne change pas grand-chose ou une n-ième distribution qui reprend les mêmes bases que tant d’autres, c’est autre chose. Mais abandonner complètement le bureau pour Linux, non merci.




dont Linux représente 2%





Cela me rappelle une certaine courbe de Gauss. <img data-src=" />


Tu as une source qui permet d’affirmer cela ?


Une source pour expliquer que Linux est sous GPLv2 ? <img data-src=" />


Étant donné que le grand public ne sait même pas ce qu’est un noyau, j’en déduis que quand les gens disent “J’ai installe Linux sur mon PC”, ils parlent de GNU/Linux (Ubuntu, Debian…) et non pas du noyau seul.



Même chez les informaticiens&nbsp; GNU/Linux est raccourcit en “Linux”. Dans un CV, je n’ai jamais vu GNU/Linux, même dans les offres d’emplois, je vois toujours “Linux” avec parfois des noms de distributions.


OK, donc, ta source est le doigt mouillé.



Personnellement, je parle de distribution LInux, je n’apprécie pas l’accolement de GNU qui ressemble à une appropriation injustifiée, il n’y a pas que des logiciels GNU dans une distribution Linux. Ce n’est pas parce que Hurd est à la ramasse qu’il faut que GNU impose son nom dans les distributions Linux.



C’était bien la peine de créer une licence libre avec la GPL pour ensuite réclamer quand on utilise ses logiciels !



Enfin, pour ceux qui savent faire la différence entre le noyau Linux et une distribution Linux, beaucoup n’ont pas adopté ou se sont opposés à l’appellation GNU/Linux.


Ah mais je n’ai jamais dit que ça venait d’une source quelconque



Je pourrai te dire la même chose en ce qui concerne le mot crypté (que beaucoup de monde utilisent) et chiffré. <img data-src=" />



Pour ce qui est&nbsp; de&nbsp; GNU/Linux, je ne fais qu’écouter notre cher Richard Stallman. <img data-src=" />



PS : N’empêche, à chaque fois que je réponds à un com de fred42, je sais que je vais me faire démolir. <img data-src=" />


Il n’y a pas appropriation injustifiée lorsque l’on parle d’une licence. Une licence n’est pas un droit de propriété c’est un contrat. Dans le cas de GNU un contrat à destination de l’utilisateur sans question mercantile.



Que l’appropriation d’usage de Linux passe par une communauté de dévs soit.

Mais je crois que personne n’empêche de faire des drônes de combat avec le noyau Linux dedans…



Dans ce cas il faudrait réécrire la GPL et y inclure des clauses de moralité. Du genre.





The Software shall be used for Good, not Evil.


Ça fait 2 fois que tu parles de licence GPL alors que le sujet est les logiciels du projet GNU. Merci d’intervenir sur un sujet qui te dépasse. Je t’ai filtré parce que tu racontes souvent n’importe quoi, donc évite de me répondre (surtout des bêtises), la notification me dérange pour rien.



Je te refiltre immédiatement.








fred42 a écrit :



Ça fait 2 fois que tu parles de licence GPL alors que le sujet est les logiciels du projet GNU. Merci d’intervenir sur un sujet qui te dépasse. Je t’ai filtré parce que tu racontes souvent n’importe quoi, donc évite de me répondre (surtout des bêtises), la notification me dérange pour rien.



Je te refiltre immédiatement.





intéressant surtout que (meme si mal exprimer et documenté), ce qu’il dit n’est pas faux.



Si tu veux une source de ce qu’il dit je t’invite a te rendre sur un site méconnu qu’est Wikipedia :

https://fr.wikipedia.org/wiki/Linux#Controverse_autour_du_nom&nbsp;pour ceux ne voulant pas chercher il est parler de “L’usage du seul nom Linux, le plus répandu parmi le grand public, est défendu notamment par Linus Torvalds, créateur du noyau Linux. Le principal argument des promoteurs de cette appellation est l’argument de simplicité : « Linux » est plus court à écrire et prononcer que « GNU/Linux »”.



Information confirmée par :&nbsp;https://www.howtogeek.com/139287/the-great-debate-is-it-linux-or-gnulinux/&nbsp;

ou ils citent son message :&nbsp;



We’ll end with a quote from Linus Torvalds in 1996:



Umm, this discussion has gone on quite long enough, thank you very much.



It doesn’t really _matter_ what people call Linux, as long as credit is given where credit is due (on both sides).&nbsp; Personally, I’ll very much continue to call it “Linux”.



il ne m’a fallu que 2 minutes afin de confirmer ce qu’il disait (en prenant en exemple le créateur même du noyau).









dylem29 a écrit :



Ah mais je n’ai jamais dit que ça venait d’une source quelconque



Je pourrai te dire la même chose en ce qui concerne le mot crypté (que beaucoup de monde utilisent) et chiffré. <img data-src=" />



Pour ce qui est  de  GNU/Linux, je ne fais qu’écouter notre cher Richard Stallman. <img data-src=" />



PS : N’empêche, à chaque fois que je réponds à un com de fred42, je sais que je vais me faire démolir. <img data-src=" />







Ben, moi, quand je parle de linux, par défaut, c’est aux distributions Linux que je fais allusion.



Sinon, je précise quand je parle du noyau.



Mais bon, je n’ai pas de prétentions d’universalisme sémantique à ce sujet, c’est vous qui voyez.









Aëlisya a écrit :



intéressant surtout que (meme si mal exprimer et documenté), ce qu’il dit n’est pas faux.



Si tu veux une source de ce qu’il dit je t’invite a te rendre sur un site méconnu qu’est Wikipedia :

https://fr.wikipedia.org/wiki/Linux#Controverse_autour_du_nompour ceux ne voulant pas chercher il est parler de “L’usage du seul nom Linux, le plus répandu parmi le grand public, est défendu notamment par Linus Torvalds, créateur du noyau Linux. Le principal argument des promoteurs de cette appellation est l’argument de simplicité : « Linux » est plus court à écrire et prononcer que « GNU/Linux »”.



Information confirmée par : https://www.howtogeek.com/139287/the-great-debate-is-it-linux-or-gnulinux/ 

ou ils citent son message : 



We’ll end with a quote from Linus Torvalds in 1996:



Umm, this discussion has gone on quite long enough, thank you very much.



It doesn’t really _matter_ what people call Linux, as long as credit is given where credit is due (on both sides).  Personally, I’ll very much continue to call it “Linux”.



il ne m’a fallu que 2 minutes afin de confirmer ce qu’il disait (en prenant en exemple le créateur même du noyau).







Si en plus, c’est l’inventeur du zinzin qui le dit, pourquoi chercher la complication ?



Et ça ose demander des sources histoire d’éviter de questionner la valeur. Formidable. <img data-src=" />








Idiogène a écrit :



Et ça ose demander des sources histoire d’éviter de questionner la valeur. Formidable. <img data-src=" />





bah j’en ai trouvée des sources, c’est juste que certaine personne (je ne vise personne, car je n’ai pas assez vu ses messages pour le jugé sur ce point car tous le monde peut faire des erreurs), saute un poil trop vite au conclusion quand il y a visiblement malentendu entre deux personne.



Je pense sincèrement qu’il y a eu un malentendu.

Mon précédent message n’avais que pour but de clarifier le malentendu, nullement jugé son message.



Il n’y a pas de malentendu, juste une querelle sur le style.



Je trouve gonflé d’exiger des sources inexistantes sur une problématique non traitée à ma connaissance de l’appropriation culturelle des termes issus de l’informatique. Le marketing étant un puissant outil de non-pensée vu de l’extérieur et renvoyant fatalement chacun à une prise de position individuelle supposant un travail personnel visant à répondre à la question posée. <img data-src=" />


Ça fait des années que j’ai viré Multilib de ma gentoo notamment du fait que la plupart des packages mettaient des plombes à compiler à chaque màj. Je n’ai eu aucun pb (à part Wine qui c’est viré en dépendance)



Pour les quelques vieilleries toujours en 32bit, je pense qu’il faut envisager simplement l’émulation : où serait le pb à avoir Steam ou Wine exécuté dans une VM ?








Aëlisya a écrit :



1 les cours actuelle n’explique pas comment codé pour du 64 bits (n’explique meme pas que la configuration par défaut est en 32 bits)(il est possible que cela s’applique que a l’unif ou je suis allée, mais au vu du marché du dev je doute).



Ensuite les chef de boite de dev prefère resté pareille pour rien changer ni reformé, ce qui bloque les école car elle apprenne au étudiant ce qui leur sera utile dans le boulot donc le 32 bits.



Un joli serpent qui se mort la queue donc.



A mois de coder en assembleur, n’importe quel programme compilera en 32 ou 64bits.









fofo9012 a écrit :



Ça fait des années que j’ai viré Multilib de ma gentoo notamment du fait que la plupart des packages mettaient des plombes à compiler à chaque màj. Je n’ai eu aucun pb (à part Wine qui c’est viré en dépendance)



Pour les quelques vieilleries toujours en 32bit, je pense qu’il faut envisager simplement l’émulation : où serait le pb à avoir Steam ou Wine exécuté dans une VM ?



Emulation = grosse perte de perfs.



Ce problème de compatibilité des jeux vidéos avec les nouvelles versions des OS, me pose problème aussi sauf que j’ai abandonnée l’idée de pouvoir faire tourner les jeux sur les dernière version des OS.



Je me rappelle notamment d’une mise à jour Windows 7 qui à fait que certain jeux ne fonctionnait plus du tout.

Il fallait lancer une commande en powershell pour désactiver une sécurité et les jeux fonctionnait à nouveau.



Bref, je pense que la meilleure solution est soit de garder son matos quand on est “GAMER” ; soit ce remonter des machines optimisée (avec matos d’occasion) pour faire tourner les vieux jeux sur les OS d’époque.



Idem pour le retrogaming sur console, même si là il y a encore des problématique de version (console castrée sur la capacité a générer un signal RGB,….)


Ils sont rares, mais quelques applis conçues à l’époque de win 3.11 étaient 16bit, et ces vieilleries ne peuvent donc plus tourner sans un PC préparé avec un vieil OS.


C’est ça.

J’ai récupéré un PC vieillissant de mes parents pour lequel j’ai installé XP: ça me permet de jouer sans problème aux jeux Dos.



Mon rêve serait de récupérer un ordinateur Tandy, le premier clavier auquel j’ai touché sous DOS.


Quel est le problème dans le fait de garder des libs 32 bits dans un système en 64 bits ?

Trop grosse taille de l’image ? Problèmes de compatibilité ?








fofo9012 a écrit :



A mois de coder en assembleur, n’importe quel programme compilera en 32 ou 64bits.





Oui mais ce que je trouve dommage, c’est que le dev doit le découvrir par lui même il n’y a ni explication ni meme valorisation du 64 Bits.









fofo9012 a écrit :



Pour les quelques vieilleries toujours en 32bit, je pense qu’il faut envisager simplement l’émulation&nbsp;: où serait le pb à avoir Steam ou Wine exécuté dans une VM ?






 Tu n'as sûrement pas essaié ^^      






VMWare est le meilleur dans le domaine, il émule au mieux une Geforce 6200 (2004) en équivalent performance -en étant très généreux- et il supporte DirectX 10.      






Virtualbox fait au mieux une Rage 128 en équivalent performance (1998, aouch), et il ne va pas au delà de DirectX 9.     





Je n’ai pas testé QEMU mais je doute que ce soit mieux, là je parle de ceux potentiellement utilisables par Mme Michu (et encore).



Bref, les jeux anciens “mais pas trop” du genre de Civilization V ne pourront pas être lancés sur le second en DirectX 10 (et pourtant on ressent la différence sur l’hôte par rapport au mode 9), et seront dans les deux cas injouables de toute façon.




La solution du GPU Passthrough est possible pour que l'émulateur puisse profiter de 95 % des performances de la carte graphique et donc offrir de quoi jouer... Mais ça réclame une carte mère adaptée (VT-d requis), deux cartes vidéos (une dédiée à la VM, une à l'hôte) et des connaissances techniques pour la mise en service. Mme Michu est incapable de faire ça, alors que depuis l'implication de Valve et les progrès de WINE de ces derniers temps, il n'est pas rare de voir des distributions Linux avec Steam pré-installé (Manjaro Linux, etc.) et facilitant donc l'usage à optique gaming.   






De fait, se débarrasser du 32 bits aujourd'hui est impossible et stupide. C'est beaucoup trop tôt, seuls les non-joueurs ne seront pas génés, et ça rendra Linux toujours plus incompatible avec le marché Desktop.


Lire l’argument “64 bits c’est l’avenir, 32 bits c’est le passé” pour justifier cette décision, sur NextInpact ça me déprime

Tu sens que les gens ne saisissent pas les enjeux et en sont loin

Oui pas d’arguments de ma part non plus, ils ont été développés précédemment par d’autres, pas la peine que je me fatigue à essayer de convaincre des gens qui refusent de l’être








Aëlisya a écrit :



Oui mais ce que je trouve dommage, c’est que le dev doit le découvrir par lui même il n’y a ni explication ni meme valorisation du 64 Bits.



Il ne faut pas généraliser ton cas perso : Je ne sais pas quel langage ou quelle “école” tu parles, mais on n’apprend pas l’informatique sans étudier ni l’assembleur, ni le fonctionnement d’un compilateur.

J’ai fini mes études avant le 64bit grand public, il a toujours été évident que l’impact serait une simple recompilation, le débat de l’époque étant les gains / pertes de vitesse selon la taille plus grosse en 64bits (@ + longue, un peu plus lente à charger) et contrario le gain sur les “double” traité dans un unique registre 64bits, au lieu de deux précédemment.



Le noyau ou les pilotes ne sont pas impactés tout ça reste en 64bit.



Tu compiles les lib en 64 et 32bits donc :




  • Les temps de compilations sont doublés, =&gt; Temps machine / pollution

  • le stockage doublé, =&gt; Impact utilisateur et pollution

  • le temps d’installation est doublé, =&gt; Gène utilisateur



    Le plus grave est que les dépendances sont infernales, ça génère du boulot inutile pour les devs déjà pas trop nombreux. Et pendant qu’un dev corrige un pb de dépendance 32bit d’un package qui fonctionne parfaitement nativement il ne bosse pas à améliorer le reste.



    Tout ce merdier pour 2 packages (WIne et Steam) alors que tout le reste est nativement compilé en 64bit depuis plus de 15ans…


J’imagine donc dans ce cas qu’il serait toujours possible d’enlever les libs 32 bit de l’image standard, et de les proposer au téléchargement si besoin.



Bien qu’il soit important de garder des images et des systèmes “propres”, j’estime que garantir une compatibilité avec les anciens logiciels est extrêmement important. Autant pour les logiciels d’entreprise et de bureautique, on pourrait dire “bah ils n’ont qu’à mettre à jour” (et encore, cela n’est souvent pas possible, soit parce que le produit n’existe plus / trop cher / moins ergonomique maintenant…), mais pour les produits figés, comme les jeux vidéo, cela veut dire qu’ils deviendraient incompatibles avec les systèmes d’aujourd’hui (et qu’il sera très difficile pendant longtemps de les lancer en VM, cf le commentaire de TheKillerOfComputer juste au dessus), et qu’on perdrait donc une partie du patrimoine des JV.








fofo9012 a écrit :



Tout ce merdier pour 2 packages (WIne et Steam) alors que tout le reste est nativement compilé en 64bit depuis plus de 15ans…



C’est bien connu que Wine et Steam ne font tourner que des logiciels 64bits, et que pour les trucs 32bits ils peuvent tout recompiler, même ce qui ne leur appartient pas (comme on l’a déjà dit au moins 3 fois avant)… <img data-src=" />

C’est bien connu que 100% des autres logiciels et pilotes dispos sous Linux sont aussi en 64bits, même pour les matériels qui n’ont plus de support du constructeur. Tu devrais demander à Commentaire_Supprimé ce qu’il en pense pour son imprimante, il en a parlé un peu plus haut <img data-src=" />









Ailothaen a écrit :



J’imagine donc dans ce cas qu’il serait toujours possible d’enlever les libs 32 bit de l’image standard, et de les proposer au téléchargement si besoin.



Bien qu’il soit important de garder des images et des systèmes “propres”, j’estime que garantir une compatibilité avec les anciens logiciels est extrêmement important. Autant pour les logiciels d’entreprise et de bureautique, on pourrait dire “bah ils n’ont qu’à mettre à jour” (et encore, cela n’est souvent pas possible, soit parce que le produit n’existe plus / trop cher / moins ergonomique maintenant…), mais pour les produits figés, comme les jeux vidéo, cela veut dire qu’ils deviendraient incompatibles avec les systèmes d’aujourd’hui (et qu’il sera très difficile pendant longtemps de les lancer en VM, cf le commentaire de TheKillerOfComputer juste au dessus), et qu’on perdrait donc une partie du patrimoine des JV.







La moins mauvaise solution possible, c’est de garder des libs 32 bits pour la compatibilité, et de les faire charger sur les systèmes à la demande.



La perte de compatibilité 32 bits est un problème nettement plus sérieux et nettement plus difficile à gérer, et pas seulement parce qu’il faut se payer une nouvelle imprimante et avoir dans le luc celle qu’on a payé 80 € il y a de cela sept ans (salut Patch ! <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /> ).



Si en plus mon Anyrail devient inutilisable pour cause de lib 32 bits abandonnées pour Wine, je fais quoi, je me paye un win rien que pour imprimer et faire tourner un logiciel de planification de réseaux de trains miniatures ? Comme dit plus haut, Steam, c’est mille fois pire pour eux comme pour leurs clients…



Et puis, si ça fonctionne impect en 32 bits, pourquoi recoder en 64 quand on a toujours les librairies 32 bits sous le coude ? C’est pas gratuit une recompilation il me semble, sans parler des problèmes nouveaux qu’elle peut engendrer.



Mais quels softs ont besoin de ces librairies ? o.o


Des drivers par exemple.

Mon scanner Epson n’a pas de drivers 64 bits


De mémoire, il y avait au moins le Webex de Cisco, certaines fonctionnalités des vieilles versions de la suite ANSYS, et certaines fonctionnalités de vieilles version d’Abaqus.








fofo9012 a écrit :



Tout ce merdier pour 2 packages (WIne et Steam) alors que tout le reste est nativement compilé en 64bit depuis plus de 15ans…





Packages qui permettent de lancer -à en croire ce site- potentiellement 5481 jeux Windows.



Je suis d’accord, c’est un sacré merdier pour 5483 softwares <img data-src=" />



Et dans ta VM tu installes Ubuntu… ah non attend il manque de nouveau les libs 32 bits <img data-src=" />