GNOME sur Xorg, c�est fini : avec Ubuntu 25.10, Canonical scelle le sort de Xorg, Wayland s'impose

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.

Envoy� par Bardaz

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

d'un autre cot�, en tant que d�veloppeur, c'est vite ing�rable si faut supporter plusieurs api dans un meme os.

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


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.

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.

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

Envoy� par calvaire

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.

Envoy� par calvaire

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 - Visualiser dans une fen�tre � part

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.

Envoy� par calvaire

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.

Envoy� par calvaire

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.

Envoy� par calvaire

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.

Envoy� par Bardaz

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.

Envoy� par calvaire

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.

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

Envoy� par calvaire

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.

Envoy� par calvaire

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.