IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

GNOME sur Xorg, c'est fini : avec Ubuntu 25.10, Canonical scelle le sort de Xorg, Wayland s'imposant définitivement comme l'avenir du desktop Linux

Le , par Stéphane le calme

36PARTAGES

7  0 
GNOME sur Xorg, c’est fini : avec Ubuntu 25.10, Canonical scelle le sort de Xorg, Wayland s'imposant définitivement comme l’avenir du desktop Linux
« Questing Quokka » marque la fin d'une ère dans l'expérience graphique Linux

Ubuntu Linux 25.10, surnommée "Questing Quokka", marque un tournant significatif dans l'évolution de la distribution. Canonical, l'entreprise derrière Ubuntu, a discrètement mis fin au support de GNOME s'exécutant sur Xorg. Désormais, la session par défaut "Ubuntu" utilisera exclusivement Wayland. Cette transition majeure est en parfaite adéquation avec la stratégie de GNOME de supprimer complètement le support de Xorg avec la version 49 de son environnement de bureau.

Ce changement n'est pas anodin et représente une étape cruciale pour l'avenir d'Ubuntu. En effectuant cette bascule dès la version 25.10, Canonical offre aux utilisateurs et aux développeurs un cycle de publication complet pour s'adapter à cette nouvelle réalité avant la sortie d'Ubuntu 26.04, la prochaine version avec support à long terme (LTS). Cette approche progressive vise à minimiser les perturbations et à permettre une transition en douceur vers la technologie Wayland.


Jusqu’ici, Ubuntu permettait aux utilisateurs de choisir entre Wayland et Xorg lors de la connexion à leur session GNOME. Cette flexibilité disparaîtra dans Ubuntu 25.10, attendu en octobre 2025 : la case « Ubuntu on Xorg » ne sera tout simplement plus disponible dans GDM, l’écran de connexion par défaut.

Ce choix est motivé par l’évolution même de GNOME, l’environnement de bureau phare de la distribution. GNOME 49, qui sera embarqué dans Ubuntu 25.10, désactive Xorg par défaut, et GNOME 50, prévu pour début 2026, abandonnera totalement sa prise en charge. Canonical anticipe donc cette transition pour garantir une stabilité maximale avant sa prochaine version LTS (Long Term Support), Ubuntu 26.04.

Avec Ubuntu 25.10 « Questing Quokka », nous franchissons une étape importante dans l'évolution du bureau Ubuntu en supprimant la session Ubuntu basée sur Xorg. À partir de cette version, la session « Ubuntu » dans GDM fonctionnera exclusivement sur Wayland. Cette décision suit la feuille de route de GNOME en amont et s'aligne sur notre stratégie à long terme qui consiste à fournir une expérience de bureau sécurisée, performante et moderne.

Pourquoi ce changement ?

Au cours des derniers cycles, l'expérience Wayland a mûri de manière significative, notamment en améliorant le support des pilotes Nvidia, en offrant un modèle de sécurité plus robuste, un support stable pour la plupart des flux de travail quotidiens, une meilleure isolation de la pile graphique et un meilleur support du tactile et du hiDPI.

Pendant ce temps, maintenir les sessions X11 et Wayland introduit une dette technique et augmente la charge de maintenance, limitant notre capacité à innover efficacement.

GNOME prévoit de supprimer le support de Xorg pour GNOME 49. Nous prenons des mesures proactives dans la version 25.10 pour préparer nos utilisateurs et notre écosystème à cette échéance.
Pour mémoire, Wayland est un protocole de serveur d'affichage, ainsi qu'une bibliothèque logicielle libre disponible sur les systèmes d'exploitation GNU/Linux. Il fournit un moyen pour les gestionnaires de fenêtres composites de communiquer directement avec les applications graphiques ainsi que le matériel vidéo. Il a été développé comme une alternative moderne au serveur Xorg (une implémentation du protocole X Windows System ou X11), utilisé sous les distributions Linux. Il permet notamment aux compositeurs 3D d'être utilisés comme serveurs d'affichage primaires, au lieu d'exécuter le compositeur 3D comme extension sous le serveur d'affichage (2D) Xorg.


Wayland, enfin prêt pour le grand saut ?

Wayland n’est pas nouveau : le protocole a été présenté comme le successeur naturel de Xorg depuis plus d’une décennie. Mais son adoption a longtemps été freinée par des problèmes de compatibilité et de maturité. Aujourd’hui, ces obstacles sont largement levés.

L'adoption de Wayland apporte plusieurs améliorations notables qui bénéficieront grandement à l'expérience utilisateur :
  • Meilleur support des pilotes Nvidia : Wayland résout bon nombre des problèmes historiques rencontrés avec les pilotes propriétaires de Nvidia sous Xorg, offrant une intégration plus fluide et des performances améliorées.
  • Une couche de compatibilité avec Xwayland pour permettre aux applications X11 (l'ancien système d'affichage) de fonctionner dans un environnement Wayland. C'est une solution de compatibilité pour les applications qui n'ont pas encore été portées vers Wayland.
  • Amélioration du comportement des écrans tactiles : les interactions tactiles sont plus réactives et naturelles sous Wayland, ce qui est un atout majeur pour les appareils équipés d'écrans tactiles.
  • les performances graphiques sont meilleures sur Wayland avec une gestion plus efficace du rafraîchissement de l’écran, Wayland gère nativement mieux la mise à l'échelle des interfaces sur les écrans HiDPI, garantissant une clarté et une netteté optimales sans les problèmes de flou ou de taille rencontrés parfois avec Xorg.
  • Sécurité renforcée : la conception de Wayland est intrinsèquement plus sécurisée que celle de Xorg, car elle isole mieux les applications les unes des autres, réduisant ainsi les risques de vulnérabilités.
  • Performances améliorées : Wayland est conçu pour être plus efficace et léger que Xorg, ce qui peut se traduire par des performances globales accrues, une consommation d'énergie réduite et une meilleure fluidité de l'interface utilisateur.


Une stratégie cohérente avant Ubuntu 26.04 LTS

Canonical a choisi de faire cette transition dans une version intermédiaire (non-LTS) afin de disposer de six mois pour recueillir les retours des utilisateurs, corriger les derniers bugs et stabiliser l’expérience.

Ce choix s’inscrit aussi dans une dynamique plus large :
  • Fedora utilise Wayland par défaut depuis Fedora 25 sortie en novembre 2016. Cette version a marqué une étape importante car elle a été la première distribution Linux majeure à remplacer, par défaut, le serveur d'affichage X.Org par Wayland pour l'environnement de bureau GNOME.
  • Red Hat et GNOME Foundation travaillent activement à supprimer les dépendances à Xorg.
  • Le monde Linux dans son ensemble évolue vers une unification autour de Wayland, qui promet de simplifier la pile graphique tout en la modernisant.

Implications pour les utilisateurs

Bien que cette transition offre de nombreux avantages, elle pourrait impacter certains utilisateurs qui dépendent encore de Xorg pour des flux de travail spécifiques. Des applications plus anciennes ou certains outils qui s'appuient fortement sur les fonctionnalités de Xorg pourraient nécessiter des ajustements ou des alternatives. Cependant, il est important de noter que Xorg lui-même ne disparaît pas complètement du paysage Linux ; il peut toujours être utilisé avec d'autres environnements de bureau.

Cette décision stratégique d'Ubuntu reflète une tendance plus large dans l'écosystème Linux, où Wayland est de plus en plus considéré comme le futur du serveur d'affichage graphique. En franchissant ce pas, Ubuntu 25.10 pave la voie à une expérience utilisateur plus moderne, plus performante et plus sécurisée pour ses futures versions.

Citation Envoyé par Canonical
Ce que cela signifie en pratique

L'écran de connexion (alimenté par GDM) ne proposera plus l'option Ubuntu sur Xorg.

Toutes les sessions basées sur GNOME Shell et Mutter sont désormais réservées à Wayland et les utilisateurs qui s'appuient sur des comportements spécifiques à X11 ne pourront pas utiliser l'environnement de bureau GNOME sur Xorg.

Si vous avez toujours besoin de X11

Nous comprenons que certains utilisateurs dépendent encore de l'implémentation de X11 par Xorg ; par exemple, dans les configurations de bureau à distance, ou dans les flux de travail hautement spécialisés.

Si vous avez spécifiquement besoin de Xorg, vous pouvez installer et utiliser un environnement de bureau non-GNOME. Xorg lui-même ne disparaît pas, mais seulement la prise en charge de Xorg par GNOME.

Cela ne signifie pas que les applications X11 ne fonctionneront plus sur Ubuntu. X11 est pris en charge par XWayland et la plupart des applications X11 fonctionneront sur la session Wayland d'Ubuntu de manière transparente. Dans de nombreux cas, aucun changement n'est nécessaire.
Ubuntu 25.10 : le début d’un futur sans Xorg

Avec Ubuntu 25.10, Canonical ne se contente pas de suivre le mouvement : il l’accélère. En supprimant GNOME sur Xorg sans fanfare, la distribution envoie un message clair : le futur du desktop Linux est sous Wayland. Une décision technique, mais aussi stratégique, qui prépare le terrain pour une version LTS 26.04 à la fois plus stable, plus rapide et plus sécurisée.

Les nostalgiques de Xorg peuvent toujours se tourner vers d’autres saveurs d’Ubuntu ou sessions alternatives. Mais pour Ubuntu GNOME, le cap est désormais fixé, sans retour possible.

Source : Canonical

Et vous ?

Wayland est-il vraiment prêt pour une adoption grand public sans compromis ?

Le retrait de Xorg dans GNOME est-il une avancée ou une forme de dictat technologique ?

Quelles sont, selon vous, les applications ou les cas d'usage qui risquent le plus d'être impactés négativement par l'abandon de Xorg par défaut ? Y a-t-il des domaines (comme le partage d'écran avancé, certains outils de développement, ou des jeux) où Wayland doit encore prouver sa maturité ?

Peut-on encore parler de « choix » dans l’univers libre lorsque certaines options sont simplement supprimées ?

La compatibilité XWayland suffit-elle à garantir une transition sans douleur ?

Avez-vous déjà rencontré des bugs ou limitations sous Wayland par rapport à Xorg ?

Quel environnement de bureau utilisez-vous et pourquoi rester ou non avec GNOME ?

Pensez-vous que Canonical aurait dû attendre la version LTS pour forcer cette transition ?
Vous avez lu gratuitement 59 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de chown6471
Nouveau Candidat au Club https://www.developpez.com
Le 25/06/2025 à 22:20
C'est tout de même affligeant de constater non-seulement de déclarer la mort clinique de X11, mais au surplus de dresser la liste des bienfaits de Wayland.... tout en réalisant l'exploit de ne pas souffler mot de ce qui constitue certainement l'un des plus grands retentissements dans le monde du FOSS de ces derniers années, survenu le 5 juin dernier : le fork de Xorg par le développeur Enrico Weigelt alias Metux.

Alors, au risque d'être un peu long, et même si certains parmi vous se sont déjà informés sur cette histoire, laissez-moi par charité informer M. le Calme mais aussi ceux de nos amis développeurs qui ne connaissent peut-être pas très bien X11, des évènements concernant cette pierre angulaire du monde Unixien, qu'il a passés sous silence au profit d'une écume qui ne rend que très partiellement compte de la réalité.

Dans les faits, il convient tout d'abord de rappeler que c'est une société commerciale que vous connaissez tous Red Hat (détenue par IBM) qui a commencé le développement de Wayland il y a plus de... 15 ans !! Oui. Vous avez bien lu. Et devinez quoi : ce sont également des équipes de Red Hat qui étaient supposées effectuer la maintenance évolutive de X11 sous l'égide de la fondation Xorg...

A ce stade, vous les voyez venir (IBM et Red Hat) : pourquoi s'enquiquiner à maintenir deux logiciels concurrents quand on est certain d'être en train de développer la huitième merveille du monde ?

Et bien c'est exactement ce qu'il s'est passé : Red Hat s'est arrangé pour que le tronc du code source de X11 soit vitrifié, d'une part en assignant la majorité de ses développeurs sur le développement de Wayland, et d'autre part (pire), en n'effectuant aucune nouvelle release des près de 3000 corrections que des développeurs tenaces de l'équipe avaient programmées. Certaines de ces corrections dataient de plusieurs années.

C'est en constatant que Red Hat était sur le point de jeter le projet Xorg à la poubelle qu'Enrico a récupéré le code source du projet et l'a transféré sous Github le 5 juin dernier. La réaction de Red Hat ne s'est pas fait attendre : il a été immédiatement banni de leur mailing lists ainsi que de la fondation Xorg.

Le projet XLibre est donc là, et succède à Xorg que cette fondation -- honte à elle -- n'essaye même plus de maintenir, sous la pression conjointe d'IBM et de Red Hat qui auront décidément tout fait pour se débarrasser de X11 afin de laisser la place à leur étron logiciel propriétaire : Wayland, suivant le principe connu et introduit par les pratiques de Microsoft sous le nom "EEE" : Embrace, Extend, Extinguish, principe industriel qui consiste à adopter un logiciel ou standard existant, puis à l'étendre en développant en interne des extensions propriétaires le rendant incompatible avec le logiciel ou standard initial, puis à l'éteindre, en utilisant sa force de frappe commerciale pour lui substituer sa propre version modifiée. C'est ce qui est en train de se passer pour X11...

Alors, vous allez dire : est-ce que XLibre et son équipe de passionnés vont faire le poids face à Red Hat ?

La question est ouverte, mais il faut savoir que la première release de XLibre, numérotée 25.0.0.0, a été publiée le weekend dernier et que déjà la distribution Linux OpenMandriva aurait intégré XLibre dans ses dépôts de code et que BSD, un acteur majeur du monde Unix, a semble-t-il l'intention de supporter XLibre. On peut ainsi espérer que d'autres vont suivre...

Cette précision me permet d'introduire ce qui fait que l'histoire n'est pas encore écrite, car lorsque je précise que BSD a l'intention de supporter XLibre, il s'agit presque ici d'une question existentielle pour cet UNIX de Berkeley qui, bien qu'étant le plus souvent utilisé pour ses qualités de serveur (sans affichage graphique fenêtré), ne dispose que de X11 pour lui offrir une couche graphique, tandis que les auteurs de Wayland auraient récemment indiqué qu'ils comptaient dédier Wayland uniquement à Linux, ce qui, par ricochet, rendrait ainsi tous les autres Unix inéligibles à son utilisation et orphelins d'une couche graphique...

Vous pensez que ça ne compte pas ? Pour ceux d'entre vous qui utilisent un ordinateur Apple au quotidien, rappelez-vous que votre merveilleux bureau MacOSX n'existe QUE parce qu'il a été développé sur la base d'un serveur d'affichage modulaire et portable, qui avait déjà bénéficié de plusieurs décennies d'amélioration, et unique en son genre : X11, et surtout parce que la licence de ce logiciel a permis à Apple d'utiliser à bon compte (gratos) cette base de code pour vous refourguer ensuite à des tarifs indécents son serveur XQuartz.

Alors oui, ça compte ...

Ce que ne vous dit pas cet article qui passe l'histoire essentielle sous silence, c'est qu'en réalité, Wayland n'apporte rien de bien nouveau par rapport à X11, en tout cas rien qui n'eût pu être modifié dans X11 pour le faire évoluer suivant un processus de maintenance corrective bien rodé chez les développeurs...

En pratique, Wayland n'apporte que deux fonctions réellement un peu neuves :

1) Le support du HDR : des corrections proposées par les mainteneurs de X11 pour supporter HDR attendraient déjà depuis des mois d'être intégrées dans le code X11 suivant informations recueillies par mes soins sur le fil de discussion Telegram de XLibre, et

2) Sécurisation de l'affichage. C'est vrai que sur ce point, X11, conçu dans les années 80, n'avait pas eu à faire face aux problèmes de sécurité que l'on connaît aujourd'hui. Exemple : désactiver la possibilité de créer des copies d'écran de certaines applications sensibles. L'équipe de XLibre vient déjà, en seulement quelques jours, d'inclure des correctifs majeurs permettant de renforcer d'une manière intelligente et mesurée la sécurité des applications X11...

Alors comme vous le voyez, en quelques jours/semaines seulement, libéré du joug de son oppresseur, XLibre est parvenu à se hisser fonctionnellement au niveau des nouveautés de Wayland...

Mais il y a l'autre face du miroir : est-ce que Wayland est réellement la merveille annoncée ? Et bien (et parlant ici comme développeur), pas vraiment...

...Car pour concevoir Wayland, c'est bien simple : Red Hat a viré de X11 tout ce qui en faisait l'unicité et sa puissance, à commencer par son support réseau et son architecture historique Client Serveur.

On s'en fout aussi, dites-vous ? Pas vraiment... Pendant qu'avec votre laptop MacBook/Windows, vous êtes obligés d'installer un logiciel Remote Desktop sur votre gros ordi Mac ou Windows qui dort dans le bureau de votre logement, pour pouvoir y accéder ensuite à distance à partir de votre laptop à votre travail, et bien, avec X11 vous n'avez besoin de... rien ! Pourquoi ? Parce que X11 a été conçu pour les universités américaines, à une époque où les serveurs de calcul coûtaient une telle blinde, que les étudiants travaillaient sur de simples petits terminaux bon marché munis de dispositifs graphiques rudimentaires, qu'avec ces terminaux, ils déclenchaient à distance leurs programmes de calcul qui s'exécutaient sur le serveur auxquels ils étaient connectés, et que grâce au protocole de X11, l'affichage graphique des programmes (fenêtres, boutons, etc) était déporté sur leurs terminaux qui ne faisaient donc qu'afficher (sans calculer) les ordres graphiques que le serveur leur envoyait via ce protocole. Ainsi, de cette manière, un étudiant à l'Université de Washington pouvait avec son simple terminal déclencher l'exécution d'un logiciel sur un serveur du MIT dans le Massachusetts et interagir avec son interface utilisateur sur son terminal...

Et vous savez quoi ? 40 ans plus tard, de nombreux Unixiens continuent d'utiliser cette fonctionnalité essentielle de X11, qu'on nomme souvent X11 Forwarding, tous les jours dans le monde entier. Moi y compris.

Et bien, en s'amputant par souci de simplification de cette architecture (ou par flemme), Wayland s'est tout simplement privé d'une partie essentielle des fonctions de X11, réduisant ainsi le dispositif d'affichage modulaire sophistiqué et évolutif de X11 à un simple moteur de compositing vidéo central (X11 disposant pour sa part aussi d'un module de compositing, fonctionnant en mode délégation), qui au passage, plus de 15 ans après le début de sa conception, ne fait toujours pas l'unanimité et donne des signes clairs de manque de fiabilité, suivant les cas d'utilisation...

Mais cela ne s'arrête pas là, parce que non content de s'amputer de son architecture client-serveur, Red Hat a aussi mis en place dans Wayland un modèle de sécurité tellement mal foutu que chaque application Wayland s'exécute désormais dans une fenêtre confinée dans une sorte de bulle sécurisée qui l'isole complètement des autres fenêtres, au point que plus d'une vingtaine des applications essentielles et/ou courantes de Linux (exemples : création de copies d'écran, FFmpeg, OBS, etc) sont actuellement soit complètement cassées ou soit fonctionnellement diminuées.

Alors me direz-vous, ça va s'arranger... Et bien, si vous me disiez cela alors que Wayland avait deux ou trois ans d'existence et qu'il s'agissait d'un simple projet open source développé par des passionnés sur leur temps libre, je pourrais volontiers l'admettre... Mais, dans les faits, ce projet est sponsorisé depuis son démarrage par les subsides généreux d'IBM/Red Hat et il a plus de 15 ans d'existence... Y aurait pas un problème, des fois, ou bien les journalistes qui passent leur temps à glauser sur les qualités de Wayland font-ils exprès de ne pas remarquer l'éléphant en plein milieu du couloir ?

Si j'ajoute enfin à cela, pour disons... "nuancer" l'enthousiasme débordant peu objectif de M. le Calme, que Wayland, pour son fonctionnement optimal, ne supporte que des cartes graphiques récentes et n'est guère plus capable que X11 de bien supporter les cartes graphiques Nvidia dont les drivers posent un problème à tout le monde Unix/Linux, n'apportant ici encore aucune valeur réellement ajoutée par rapport à son concurrent, alors que X11 continue quant à lui de supporter et de s'exécuter correctement sur des matériels plus anciens,

Je crois que vous aurez compris que si Red Hat a tenté de tuer Xorg en arrêtant volontairement sa maintenance, c'est d'abord et avant tout parce qu'ils sont parfaitement conscients que la médiocrité de leur Wayland ne leur permettra pas de l'imposer sur le moyen/long terme contre un logiciel historique, X11, qui bon an mal an, et en dépit de l'absence d'une vraie release dont Red Hat et Xorg ont tout fait pour empêcher la publication depuis 2020, continue de parvenir à fonctionner et de répondre aux besoins de millions d'utilisateurs, pour des besoins quotidiens, bureautiques, multimédias et même de gaming où Linux se pose désormais de plus en plus en concurrent sérieux de Windows.

Et si on considère uniquement le gaming, qui est aujourd'hui le domaine le mieux à même et susceptible de gagner dans le futur de nouveaux utilisateurs Linux agacés par les pratiques de Windows, force est de constater que les benchmarks les plus sérieux sont bien incapables de départager Wayland de X11 en matière de FpS... de ce point de vue, Wayland est donc incapable de se démarquer sérieusement de son aîné de 25 ans en dépit des moyens investis par Red Hat...

L'histoire n'est donc pas encore écrite, mais ce qui est certain, c'est que celle qui l'est déjà ne correspond pas vraiment à ce que cet article laisse entendre, et qu'il est partant important d'entendre d'autres voix...

A bon entendeur...
6  1 
Avatar de Bardaz
Nouveau Candidat au Club https://www.developpez.com
Le 23/06/2025 à 12:41
Cette action de Canonical est aussi une réaction au fork de Xorg, XLibre et c'est très dommage de ne pas citer cette histoire.
https://github.com/X11Libre/xserver

Pour remettre en contexte Xorg est abandonné volontairement par RedHat malgré les différentes contributions à celui-ci RedHat souhaite imposer Wayland même si c'est une catastrophe comparé à Xorg. Pour cela RedHat a censuré le développeur majoritaire de Xorg et bloqué toute contributions. Un des avantages du Desktop Linux c’était aussi pendant des décennies l'accessibilité. Avec Wayland pour le moment c'est zéro pointé et donc une totale régression sur ce point. En revanche apparemment ce serait plus secure.
https://www.dedoimedo.com/computers/wayland-2024.html

Par contre l'avenir du desktop Linux, d'après RedHat ça passe quand même par la censure des contributions à Xorg. Le plan de la direction c'est GNOME, Wayland, Systemd. Ubuntu a suivi, pas le choix ils dépendent de GNOME maintenant.

Xorg fonctionne très bien actuellement bénéficie des drivers des différentes marques avec des performances intéressantes mais alors pourquoi donc abandonner et bloquer toutes les contributions à celui-ci, si ce n'est pas un choix motivé par une prise de pouvoir en vue d'un remplacement des développeurs. Enfin bonne nouvelle Xlibre est sorti avec les patchs que RedHat bloquait comme quoi finalement c'etait possible et ça reste toujours mieux que Wayland.
4  0 
Avatar de Bardaz
Nouveau Candidat au Club https://www.developpez.com
Le 24/06/2025 à 7:04
Dommage de ne pas avoir parlé de Xlibre sur cette news également comme sur l'autre précédente.
XLibre c'est le fork de Xorg qui s'améliore rapidement. Je vois pas comment vous avez pu louper ça c'est le scandale du moment.

C'est pas génial non plus, il y a des bugs car le dev principal tente de faire table rase de certaines choses quitte à casser des fonctionnalités, par contre c'est très réactif et corrigé rapidement. Coté support dans nos distribs, on profite des années du bénéfice de Xorg. Dans un contexte industriel c'est intéréssant ça permet de garder la brique logicielle sans subir de heurts.

Une intervention des développeurs KiCAD et de l'état catastrophique du support Wayland:
https://www.kicad.org/blog/2025/06/K...land-Support/#

Je trouve ça dommage d'imposer la solution Wayland à toute l'industrie car c'est une solution non mature. Quid des sessions remote qui marchaient pas sous Wayland, c'est se tirer une balle dans le pied alors qu'on avait un desktop Linux pas trop mal pour l'entreprise. Ça envoie également un message "Suivez-moi ou ... suivez-moi" C'est pas tellement dans la veine du libre habituellement, ça me chagrine cette manière de forcer et de ne laisser aucun choix. Les agendas de RedHat (pardon IBM maintenant) et Canonical et n'oublions pas Microsoft ne sont pas les notres.
4  0 
Avatar de tenchirock
Nouveau Candidat au Club https://www.developpez.com
Le 23/06/2025 à 23:16
En parlant de sécurité, maintenant qu'il y a un fork que redhat ne peux pas empêcher de progresser comme elle le fait depuis des années avec xorg, la 1ere release de xlibre aussi ajoute une couche de sécurité et une compatibilité conservée avec NVIDIA !
3  0 
Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 23/06/2025 à 21:13
bonjour, on ne parle pas non plus de Radeon , il ne fonctionne alors qu'avec Nvidia !!!!!, et tous les logiciels qui font appel à X11 ou du moins à ses library ??? l'article ne va pas assez loin.
3  2 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 24/06/2025 à 21:53
Citation Envoyé par Bardaz Voir le message
[...]C'est pas tellement dans la veine du libre habituellement, ça me chagrine cette manière de forcer et de ne laisser aucun choix. Les agendas de RedHat (pardon IBM maintenant) et Canonical et n'oublions pas Microsoft ne sont pas les notres.
C'est pourtant dans la veine de ces boîtes: systemd, pulseaudio, ...

Wayland suit la même logique: implémenter le plus possible dans Gnome pour tuer la concurrence, et laisser les autres bureaux crever par manque de fonctionnalités / bugs. Un peu comme systemd et ses soit-disant standards ouverts, mais avec un rythme de développement impossible à suivre pour n'importe quel clone.

J'espère que XLibre va bien prendre. Peut-être qu'il aura aussi du support des BSD.
1  0 
Avatar de Bardaz
Nouveau Candidat au Club https://www.developpez.com
Le 26/06/2025 à 0:14
Citation Envoyé par calvaire Voir le message
d'un autre coté, en tant que développeur, c'est vite ingérable si faut supporter plusieurs api dans un meme os.
C'est pas faux. En général dans le monde Linux, aucun problème on a pas mal d'exemple de petite distros qui virent systemd et proposent deux ou trois init en toute transparence. La problématique actuellement vient justement du coté opposé qui cherche à imposer des solutions GNOME, LibAdwaita, Systemd, Pulseaudio, Wayland et qui casse toute l'inter-opérabilité qui fonctionnait correctement avant.

Citation Envoyé par calvaire Voir le message
mon code généralement c'est je supporte que systemd, et jusqu'à présent je testais sur sur x11, mais si toutes les distribs se mettent à wayland je vais plus que tester sur wayland.
Je ne sais pas de quoi tu as besoin coté systemd mais si je prends la méthode runit on a:
Code : Sélectionner tout
ln -s /etc/sv/<service> /var/service/
C'est littérralement en syntaxe et en réel un simple lien symbolique. Difficile de faire à la fois plus simple et plus juste coté Unix.

Citation Envoyé par calvaire Voir le message
Meme chose pour l'api graphique je ne code que sur opengl, mac impose metal donc le monde apple se privera de mes logiciels.

Je ne suis qu'un petit développeur qui code des petits softs dans mon coins, j'ai pas les resources et les motivations de supporter 15000 trucs inutile. J'attends un minimum de standards.

Pour les packages j'ai une lib qui me les faits sinon je n'en supporterais qu'un seul (deb ou snap je pense) et le reste c'est tar.gz et demerde toi.
Je trouve ça très bien un tar.gz personnellement, nos machines sont des monstres et personne ne compile c'est d'un ridicule. Pour les dépendances, les entrées et le make make install ça se gère très bien avec du bash sans avoir besoin de générer des paquets. Si le logiciel trouve son public il y auras certainement des packageurs, après je raisonne comme si ton logiciel était libre je ne me suis pas mis à la place d'un éditeur propriétaire.

Citation Envoyé par calvaire Voir le message
Au moins sur wndows et android c'est vite réglé. un exe et un apk, les api sont les memes chez tous le monde et longtemps rétro compatible.
Rien ne t'empêche d'aller vers ce monde commercial et de faire payer tes versions précompilés avec un script pour les entrées menus, bureau, etc. Le bon exemple c'est Icculus qui nous faisaient des portages encore valide 20 ans plus tard et ça avec des technos de lépoque.

Citation Envoyé par calvaire Voir le message
Faire des guerres sur ces conneries (wayland vs x11, systemd vs sysinit, deb vs snap vs rpm....) ca ne fait que faire chier les dev de bonne volonté qui veulent proposer des releases sur linux.
Exactement et personne ne souhaite la guerre. Surtout pas les particuliers ou les PME qui n'ont pas d'energie à mettre dedans et surtout pas les multinationales qui veulent imposer leurs solutions en silence. Mais, comme tu vois on choisis pas, l'important c'est d'en discuter pour se détourner des solutions qui nous enferment un peu trop et donc finissent par porter préjudice à l'ensemble de la chaîne des acteurs du développement logiciel.
1  0 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 26/06/2025 à 8:41
Citation Envoyé par Bardaz Voir le message
Exactement et personne ne souhaite la guerre. Surtout pas les particuliers ou les PME qui n'ont pas d'energie à mettre dedans et surtout pas les multinationales qui veulent imposer leurs solutions en silence. Mais, comme tu vois on choisis pas, l'important c'est d'en discuter pour se détourner des solutions qui nous enferment un peu trop et donc finissent par porter préjudice à l'ensemble de la chaîne des acteurs du développement logiciel.
ca demande déja une énergie de faire du dev multiplateforme, par exemple supporter windows/linux, supporter android encore plus car c'est un autre monde le mobile.

Sous linux, systemd moi perso je le code le service dans /systemd.

j'ai bien un jenkins qui tourne pour me faire mes builds, mais lance des conteneurs debian, une vm windows, donc je suis sur que ca tourne sur debian/windows, le reste...
Pour android pour l'instant j'ai pas encore regardé comment automatisé, alors je fais 1 release par mois max que je test à la main, au lieu de 1 release/semaines pour windows/linux.
Faut faire des choix, je préfère avancer dans mon code que d'avancer sur le multiplateforme. Je supporte le plus générique (base debian avec systemd).

C'est des petits projets open sources qui me rapporte pas d'argent et qui me rapporteront jamais (c'est pas le but) je précise.
Pour mac, j'ai pas de mac et j'ai pas envie de dépenser de l'argent la dedans pour un projet gratos. Si demain mes projets avec une rosse commu et m'offrait un mac, je suis meme pas sur de faire cette effort, dans le sens ou le monde apple ne m'attire pas plus que ca, le mac serait juste dans un placard a prendre la poussiere.
Un fan de mac peut toujours rejoindre le projet sur github et proposer des mr par contre, mais que je pourrais pas tester.

C'est des projets (enfon plutot poc fonctionnel) adressé à un publique d'expert: c'est un systèmes d'exploitation formellement vérifiés, une base de donné matriciel massivement distribué...
juste pour m'amuser, le seule ROI que j'en retire c'est 3 lignes sur le cv.
0  0 
Avatar de Bardaz
Nouveau Candidat au Club https://www.developpez.com
Le 26/06/2025 à 9:45
Citation Envoyé par calvaire Voir le message
ca demande déja une énergie de faire du dev multiplateforme, par exemple supporter windows/linux, supporter android encore plus car c'est un autre monde le mobile.

Sous linux, systemd moi perso je le code le service dans /systemd.

C'est des petits projets open sources qui me rapporte pas d'argent et qui me rapporteront jamais (c'est pas le but) je précise.
Pour mac, j'ai pas de mac et j'ai pas envie de dépenser de l'argent la dedans pour un projet gratos. Si demain mes projets avec une rosse commu et m'offrait un mac, je suis meme pas sur de faire cette effort, dans le sens ou le monde apple ne m'attire pas plus que ca, le mac serait juste dans un placard a prendre la poussiere.
Un fan de mac peut toujours rejoindre le projet sur github et proposer des mr par contre, mais que je pourrais pas tester.

C'est des projets (enfon plutot poc fonctionnel) adressé à un publique d'expert: c'est un systèmes d'exploitation formellement vérifiés, une base de donné matriciel massivement distribué...
juste pour m'amuser, le seule ROI que j'en retire c'est 3 lignes sur le cv.

j'ai bien un jenkins qui tourne pour me faire mes builds, mais lance des conteneurs debian, une vm windows, donc je suis sur que ca tourne sur debian/windows, le reste...
Pour android pour l'instant j'ai pas encore regardé comment automatisé, alors je fais 1 release par mois max que je test à la main, au lieu de 1 release/semaines pour windows/linux.
Faut faire des choix, je préfère avancer dans mon code que d'avancer sur le multiplateforme. Je supporte le plus générique (base debian avec systemd).
Franchement je te comprends, et je suis surement mal placé car je ne touche pas à systemd dans mon travail, j'ai aucune idée des contraintes en production. J'y suis encore attaché sur des vm perso base Debian malgré moi.

En tout cas c'est rationnel et personne ne va te le reprocher. Ce qu'on exprime c'est un passé où ça fonctionnait de manière universelle et qu'aujourd'hui à priori cela ne sera plus le cas. Tout comme toi, les développeurs n'ont pas l'energie et le temps d'aller voir les autres solutions. Des solutions qui n'ont pas été pensés pour s'imposer mais pour communiquer.

Il y a eu une guerre de chapelle avec systemd, la joute verbale à tourner parfois au ridicule et tout a été dit. Par la suite, cela s'est accéléré. LibAdwaita non compatible, on arrête le support des spécificités du 32 bits (une plaie pour l'industrie), allez on recode les outils core qui fonctionnent depuis mini les années 90 avec maintenance dans un truc moins bien. Toujours les mêmes, des entreprises de la tech avec une grosse force de frappe et qui souhaitent que Linux avance dans leur sens.

Grand bien leur fasse, je n'ai aucun problème avec ça. Qu'ils développent leurs OS dans leurs coin avec leurs standards mais pourquoi vouloir à tout pris casser le coté communautaire ou le phagocyter. Leur vision d'une communauté c'est "Tout le monde utilise ma solution et je ne partage pas le pouvoir de décision", super friendly... Pourquoi prendre le nom Linux si ce n'est dans le cadre d'une prise de pouvoir. L'objectif du coup de ces posts est d'en parler, d'avoir des billes vu que ça commence à tourner vinaigre ces histoires pour nous, les petits acteurs du libre. Après, chacun fait son choix technique sans critiques.
0  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 26/06/2025 à 14:30
Pour ceux que ça intéresse, (peut-être calvaire, puisqu'il publie des applications sous Linux), le lien vers l'éditeur de KiCad sur les problèmes qu'ils rencontrent avec Wayland et ce qu'ils ont décidé de faire: https://www.kicad.org/blog/2025/06/K...yland-Support/

Il y a le paragraphe suivant qui est assez éloquent:
Why These Issues Persist

These problems exist because Wayland’s design omits basic functionality that desktop applications for X11, Windows and macOS have relied on for decades—things like being able to position windows or warp the mouse cursor. This functionality was omitted by design, not oversight.

The fragmentation doesn’t help either. GNOME interprets protocols one way, KDE another way, and smaller compositors yet another way. As application developers, we can’t depend on a consistent implementation of various Wayland protocols and experimental extensions. Linux is already a small section of the KiCad userbase. Further fragmentation by window manager creates an unsustainable support burden. Most frustrating is that we can’t fix these problems ourselves. The issues live in Wayland protocols, window managers, and compositors. These are not things that we, as application developers, can code around or patch.
Comme je disais plus haut, je pense que la stratégie de Red Hat est de faire mourir tout ce qui n'est pas Gnome, en rendant la tâche de développer maintenir un gestionnaire de fenêtres ridiculement absurde, avec leur notion de "compositors". Il y a aussi des trucs totalement délirants et incompréhensibles, comme le fait de ne plus faire de décoration côté serveur mais uniquement côté client (histoire que les fenêtres aient toutes une tête différente moche au lieu d'avoir une décoration unifiée)...

Citation Envoyé par calvaire Voir le message
ca demande déja une énergie de faire du dev multiplateforme, par exemple supporter windows/linux, supporter android encore plus car c'est un autre monde le mobile.
Oui, clairement.

Citation Envoyé par calvaire Voir le message
Sous linux, systemd moi perso je le code le service dans /systemd.
Si c'est juste le service, ce n'est pas ça qui va poser souci aux autres. Ceux qui veulent pourront toujours faire leurs propres scripts d'init.

Ce qui fait râler, c'est que ce soit disant système d'init phagocyte en fait petit à petit tous les autres services et programmes (crontab, logs, sudo, etc), et que les remplacements ont en général beaucoup de bugs, changent les options, etc (normal, puisque l'équipe de développement de systemd n'a pas la taille pour gérer tout les composants d'un système). C'est tout simplement l'équivalent de ce développeur que vous avez tous déjà rencontré au boulot qui réinvente la roue sans arrêt (en moins complet) pour l'intégrer à son propre framework.

Donc tant que tu ne commences pas à faire dépendre le code de tes programmes des API de systemd, ils resteront "portables" - même si cela demande aux utilisateurs/mainteneurs de packages de faire un peu de scripting.
0  0