L'alpha 1 de GNOME 49 a été publiée lundi, sous la forme d'une image ISO de 1,9 Go. En attendant la sortie de la version finale de l'environnement, attendue pour le mois de septembre, cette première alpha permet de mesurer, dans la pratique, les conséquences de la bascule de X11 vers Wayland, mouvement que suivra Ubuntu à partir de la 25.10.
Annoncée et préparée de longue date, la désactivation par défaut de l’ancien serveur graphique X11/Xorg ne signifie pas la fin de la compatibilité avec les applications qui l'exploitent, puisque ces dernières pourront toujours être lancées dans une session Wayland au moyen de la couche de compatibilité Xwayland.
Cette alpha 1 est également l'occasion de mettre à jour de nombreux modules (voir le changelog) et d'acter la suppression de Totem, au profit du nouveau lecteur vidéo Showtime, ou la disparition du module Devhelp, remplacé par Manuals.
Commentaires (24)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 08/07/2025 à 10h23
Le 08/07/2025 à 11h58
Mais il est vrai que côté KDE Plasma, wayland apporte pas mal de confort d'utilisation.
Le 08/07/2025 à 14h21
Tu parles du fait que X11 est désactivé mais pas encore supprimé de GNOME ?
Le 08/07/2025 à 20h45
Le 08/07/2025 à 14h39
Mais surtout sans jamais aboutir à au moins, un consensus général sur le "comment l'utilisateur de l'API devrait faire".
C'est le même problème que la fameuse "intégration à un OS" qui consiste à copier des raccourcis dans un répertoire... Mais ce n'est pas les mêmes répertoires; mais ce n'est pas pareil ici ou là.
Ce n'est pas comme si on avait pas le recul nécessaire depuis les terminaux Wyse (ou autre).
En fait dans le cas présent c'est Wayland (le dernier né) qui devrait porter le "protocole méthodologique" (on va appeler cela comme ça). Et de fournir non pas un mode de compatibilité pour lui même. Mais une lib permettant aux systèmes de gestion de fenêtre ex: X11) de pouvoir faire fonctionner les applications qui utilisent ce nouveau protocole.
L'universalité n'est toujours pas le "leitmotiv" de tous ces gens. Et cela ferait un bien fou je pense.
Modifié le 08/07/2025 à 17h04
Bah... heu... ca existe: libweston, c'est-à-dire l'implémentation de référence de Wayland
Ou alors j'ai pas compris ce que tu voulais dire ?
Le 08/07/2025 à 17h21
C'est valable pour tout. L'exemple suivant est juste plus facile.
Ex la définition d'un bouton sur JavaxFX et .Net. Tu as les mêmes concepts derrière. Mais quand on regarde les fichiers de design (les xml)... Bon, y'a comme une dissonance cognitive quelque part.
On devrait avoir ce genre de chose pour tout un tas de truc. Ça permet de se raccrocher à quelque chose de solide. Bien évidement, il faut aussi que cela évolue. Ex l'ajout de fonction dédiées au tactile pour les éléments d'une interface.
On est loin de d'avoir une standardisation éprouvée et reconnu.
Tout le monde veut imposer son truc sans pour autant être légitime. Ça ressemble à une course de...
Pourtant tout le monde aurait à y gagner.
Le 08/07/2025 à 18h13
Enfin tu donnes l’exemple du bouton qui est pourtant l’élément le plus simple, et pourtant rien que standardiser cela demanderait de se mettre d’accord sur des centaines d’aspects : est-ce que la couleur est personnalisable ? Est-ce qu’un bouton peut être divisé en deux ? Comment ? Est-ce qu’il peut contenir une image ? Est-ce qu’un bouton peut avoir un état « rester enfoncé » ?
Tous les éditeurs auront des avis différents sur chacun de ces aspects et pourtant en cas de standardisation ils devront tous supporter l’ensemble des décisions. Et on parle juste du bouton.
On l’a vaguement fait pour le web et ça nous a mis dans une situation où il est quasi impossible de voir naître un nouveau browser avec un nouveau moteur tellement l’implémentation du standard est compliquée.
Je suis 100% pour standardiser plein de trucs mais il faut que le process embarque tous les acteurs et qu’il ne rende pas l’arrivée de nouveaux acteurs trop compliqué techniquement.
Sans compter que les choix des uns et des autres sont tous légitimes et défendables : quel que soit notre avis personnel sur la question, certains préfèrent la manière de faire d’Apple, d’autres de KDE, d’autres de Gnome … tous ont les avantages de leurs inconvénients et tous ont des préceptes qui sont incompatibles avec les autres.
Le 09/07/2025 à 11h31
NB: J'utilise le mot RFC pour "truc posé sur le papier".
Effectivement mais je n'incluait ces gus dans le tas. Le plus drôle étant que ces politiques de marchand qu'ils appliquent leur font du tort à terme. Ex: La bataille de l'ODF ou Microsoft a finit pas le mettre par défaut (en premier) quand on sauvegarde dans ses suites bureautique. Ça se pose là quand même. Et il y a le danger. Comme le comportement d'Oracle (MySql/openOffice). Adobe : PDF... . Le même genre de boite qui siège à la "linux fundacheun". Fin de digression.
Pour le bouton : En substance ce que je préconise c'est un peu comme pour le réseau. On a un tas de RFC pour le "comment que l'internet c'est foutu". Ça a débouché sur HTTP, POP3 et IMAP quand même. Coté développement en dehors de la méthodologie (Adjaïïïïle) et l'organisation, c'est un peu le désert.
Pour recentrer sur le bouton. On sait que c'est un élément graphique qui est réactif et qui appelle une fonction (ou méthode). Je vois 3 choses. Le graphique (X,Y, margin, padding, etc. Et cela ne concerne pas que le web), la dépendance d'un système d'observation (le framework), et la liaison avec du code (référencer, rendre accessible).
Rien n'empêche de faire 3 RFCs pour cela. D'ailleurs coté réseau on ne s'en prive pas. Ces nouvelles bibles seraient suffisamment granulaires pour que l'on puisse changer l'un ou l'autre au gré des évolutions. Et surtout pouvoir passer de l'un à l'autre dans de bonnes conditions. Et rien n'empêche de les faire grossir un peu.
Il y aura toujours quelqu'un pour ne pas être d'accord. Souvent par intérêt mercantile. Mais un vélo dit bicycle... ça a au moins deux roues. Il y a quand même des trucs qu'on peut faire. Poser sur le papier des choses.
Et au delà du bouton, il faut voir la choses de manière globale. On peut avoir des avis tranchés la dessus. Je pense cependant que c'est mieux d'avoir un truc qui fait référence que de ne rien avoir.
Il y a un mec dans les années 60 qui a dit un truc du genre. "Un ordinateur personnel ça doit avoir un système embarqué, un écran pour voir les données et un dispositif pour entrer les données et commandes" (on ne parlait même pas de code mais de bouton).
Actuellement si on cherche la lumière divine du code et de comment doivent être les choses (du genre du paragraphe précédent). Même les définitions les plus basiques. On se rend vite compte que ce que l'on trouve ressemble parfois à des écrits de cultes corporatiste. C'est très étrange.
@127.0.0.1 Tu focalises sur Wayland. Je parle en général. Mais aussi, Wayland ne fait autorité que pour lui même. Le mot autorité dans le sens de reconnu (avec contribution de gens qui apportent leurs solutions) pour faire des systèmes/serveurs de fenêtre.
@ragoutoutou J'ai utilisé le mot "standard" dans le sens de "recette de cuisine" pas "obligation". Le même principe que les RFCs. Quoiqu'il faut s'accrocher pour les lire parfois.
Pour les standards; IP est passé de 4 à 6. Et du changement entre les deux, il y en a une masse. C'est pourtant resté des standards.
Je n'ai pas proposé de faire de l'immuable. Au contraire. C'est quand on commence à poser les choses que l'on s'aperçoit qu'il faut laisser des portes ouvertes pour évoluer.
Par exemple. Pourquoi n'y aurait-t-il qu'un seul kernel en RAM ? Les pieuvres ont bien plusieurs "cerveau". Ha oui tiens! S'il y avait une RFC qui décrit ce qu'est un kernel et ses fonctions, elle ne dira pas qu'il ne doit y en avoir qu'un seul en RAM.
Avoir le papier, est à mon sens meilleur. Et rien n'empêche de faire des RFCs supplémentaires pour faire évoluer. On l'a bien fait pour le mail (RFC822, RFC2822).
@Tous
Alors on me dira: "Oui mais faut organiser tout ça. Tu n'y pense pas". Bah... Y'a l'IETF qui le fait pour le "ternet". Donc heu... Mais ou est donc la "Coder Engeneering Task Force" et ses famous "guidelines for how the shit is done to achieve enlightenment" ?
Je pense, à force de voir exactement les mêmes concepts avec des noms différents dans une multitude de produit qu'il manque ce tronc commun bien définit. Ou posé sur le papier. "Universel" quelque part. Vous me direz : "c'est du bon sens". Oui heu... Sauf que c'est pas du gout ou à la porté de tous...
Le 09/07/2025 à 13h14
X11 en RFC, ils ont essayé, mais ça a été rejeté à tous les niveaux...
X11 est un standard initialement élaboré par les grands éditeurs de plateformes unix qui n'a quasi plus évolué depuis 1987, le passage de XFree86 à X.org en 2004 ressemblait juste à un vol de cadavre. Alors je ne veux pas minimiser le travail de X.org pour toutes les améliorations cosmétiques, mais de trop nombreux problèmes de fond, déjà reprochés en 1990, sont restés non-adressés...
A un moment, il faut être raisonnable et faire son deuil d'une technologie qui a dit son dernier mot il y a 17 ans.
Modifié le 08/07/2025 à 19h35
- Wayland est une spécification. Clairement documentée.
- Le projet est géré par freedesktop.org (l'ancien X Desktop Group).
- La spécification évolue: la v1.0.0 date de Octobre 2012 (12+ ans). La dernière version v1.24.0 est sortie hier.
- Il y a un consensus auprès de tout ceux impliqués dans le dev/maintenance de X ou Wayland pour mettre X a la retraite et passer sur Wayland.
Y a que certains utilisateurs qui râlent parce qu'ils ne voient pas l'intérêt de changer pour simplement faciliter la vie des dev/mainteneurs de X. Idem pour Systemd d'ailleurs. Bref, des utilisateurs avec des grands idéaux sur ce que devrait être l'avenir de Linux, mais qui n'écoutent pas l'avis de ceux qui développent le bouzin.
Le 08/07/2025 à 21h15
Beaucoup ne sont pas d'accord avec Wayland, car il ne reprend pas toutes les fonctionnalités que X11 permettaient. Certaines applications deviennent difficilement utilisable à cause de ça (j'ai l'exemple de Kicad en tête, mais ce n'est pas la seule). Et le problème, c'est que c'est inhérent à la structure même de Wayland et du protocole qui présente certaines lacunes par rapport à X11.
Et il y a tellement pas de consensus, que certains dev de X11 ont forké X11 pour créer XLibre, justement car ils en avaient marre que certains, en interne, mette des bâtons dans les roues aux développements de X11.
Systemd a été (et est toujours) une très bonne initiative qui a permis de faciliter grandement le développement, le déploiement et la maintenance, de services et de leurs dépendances, en proposant une syntaxe unifiée et portable.
Wayland n'a rien uniformisé du tout, car il n'y avait rien à uniformiser. Wayland n'est pas venu avec des gains en vitesse super folle (tout au mieux, 1 ou 2% pour certains jeux, mais avec des perfs catastrophique pour d'autres).
Pire, Wayland risque de sacrément créer une rupture, notamment avec les *BSD.
Les discussions sont nourries. Et si on fait abstraction de la part d'utilisateurs râleurs car c'était mieux avant (il y en aura toujours), on est vraiment loin d'un consensus. C'est pas pour rien que Wayland existe depuis 17 ans (de mémoire) et n'est toujours pas pleinement adopté.
Quand un truc fait vraiment consensus, c'est comme avec systemd. En moins de 5 ans, les dés sont jetés.
Modifié le 08/07/2025 à 23h51
Le passage a Wayland s'est véritablement débloqué quand NVIDIA a arrêté de forcer EGLStream.
Ce projet semble mort né: https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts
Le modèle de X n'était pas sécurisé et tout a été revu de zéro, pour de bonnes raisons que pas grand monde ne conteste.
Ça ne veut pas dire grand chose "ne pas être d'accord avec Wayland". Des gens qui râlent, il y en a. Moins que pour systemd de ma perception. Déjà aujourd'hui ça ne m'étonnerait pas que la majorité des utilisateurs Linux (desktop ou handheld) soient sur Wayland, c'est le défaut depuis longtemps sur Ubuntu/Fedora, sans même compter les Steam Deck.
Le 09/07/2025 à 00h29
Maintenant, deux possibilités :
- ou bien repartir de zéro (ce qui a été choisi)
- ou bien rompre la compatibilité avec X11 pour "forger" X12 (casser la compatibilité tout en gardant quelque chose de "proche").
Wayland ne reprend pas toutes les fonctionnalités de X11. Et cela pose problème pour un certain nombre d'applications. Je ne parle pas de la transparence réseau qui ne sert plus beaucoup aujourd'hui (et ça encore, a priori, on peut l'émuler). Non, une application ne peut pas positionner ses propres fenêtres par exemple. Dans le cas d'application multi-fenêtres comme KiCad, c'est un souci, car à l'ouverture de l'application, l'utilisateur est obligé de remettre les fenêtres manuellement comme il le souhaite.
De même que le glisser/déposer entre fenêtre d'une même application n'est apparemment pas possible avec Wayland.
Pour le consensus, le seul qu'il y ait vraiment, c'est que X11, en l'état, ne pouvait pas perdurer ad vitam eternam. Le chemin choisi lui, ne le fait pas, justement car il oblige à revoir quasiment toute la pile graphique.
Moins de gens sont impactés. Les premiers sont ceux qui développe des toolkits graphique (Gtk, Qt, etc.). Les seconds sont ceux qui font des applications directement en utilisant le protocole X11 (qui permet de faire pas mal de chose en soit, comme dessiner des lignes, du texte, des rectangles, etc., ce que ne permet pas Wayland qui ne connait des buffers)
Le 09/07/2025 à 14h55
La traditionnelle approche Unix.
Exact. C'est la responsabilité de Wayland de positionner les fenêtres.
De mon point de vue, c'est d'ailleurs mieux que ca soit sous le contrôle de Wayland (et donc de l'utilisateur) plutôt que sous le contrôle de l'appli.
Effectivement c'est un problème pour toutes les applis qui sont multi-fenêtres.
Mais bon, faut vivre avec son temps. La norme c'est qu'une appli soit cantonnée dans sa fenêtre. C'est tout de même plus simple pour alt+tab, ou afficher dans la taskbar.
Surement. Mais nulle doute que ca finira par arriver.
D'ailleurs une première étape est franchie avec l'arrivée de KDE 6.4 dans OpenBSD.
Certes en mode xorg pour l'instant. Mais KDE se focalisant sur Wayland...
Le 09/07/2025 à 16h10
Le 10/07/2025 à 08h43
Moi aussi je déplace la fenêtre de preview sur l'autre écran, notamment quand je fais du plantUML et que je ne suis pas chez moi sur mon écran large (le 3440x1440px c'est d'enfer pour ça) et donc que la preview est trop serrée.
Le 09/07/2025 à 11h52
Je cite : "No, simply a vote of no confidence". C'est du doigt mouillé.
Pour le projet lui même on voit ceci
"3.1k stars"
"Excluding merges, 33 authors have pushed 1,412 commits to master and 1,864 commits to all branches. On master, 864 files have changed and there have been 17,103 additions and 34,576 deletions."
Il a 512 (haha 2^9) contributeurs.
L'avenir nous le dira, mais je pense que cela ne ressemble pas un truc à l'abandon pour le moment.
Le 09/07/2025 à 13h26
J'ai envie de dire "on s'en tape des bsd" ... pas que je n'aime pas ces systèmes mais je ne vois aucun intérêt à essayer d'aligner les mondes GNU/Linux et BSD sur ce point là...
Les GNU/Linux font leurs trucs, les BSD font les leurs, c'est bien, c'est de la diversité, on est pas à la recherche du plus petit dénominateur commun.
Concernant KiCad, je vois bien pourquoi c'est chiant, et en même temps, je pense que plus que leurs fenêtres, c'est leurs raccourcis de design qui sont peut-être mal placés.
Le 09/07/2025 à 13h52
Demain, potentiellement, Gnome ne sera plus dispo sur les BSD. C'est peut être pas un problème en soit. Mais c'est une conséquence tout à fait plausible.
Si des logiciels aussi important disparaissent des BSD, ce sera un coup dur porté à l'écosystème, risquant aussi de limiter la diversité.
Kicad est une application spécifique, qui a plus de 30 ans et qui ne doit pas être trop mal foutu car c'est quand même une référence dans son domaine, comme peut l'être Gimp dans le sien.
Un usage spécifique nécessite souvent des designs spécifiques. Je me garderai bien de porter un quelconque jugement sur le bien fondé ou non du design.
Par contre, je note juste qu'en l'état actuel des choses, l'application perd plusieurs fonctionnalité, et que les développeurs eux-mêmes ni pourront rien..
Petit aparté pour que les choses soient claires. Je ne suis pas contre Wayland. Je réagissais au fait que Wayland faisait consensus (ce qui n'est pas le cas). La transition "forcée" vers Wayland me semble déjà beaucoup plus problématique, justement à cause des pertes de certaines fonctionnalités.
Je pense que Wayland est allé trop loin dans l'over-security, au point de faire disparaitre des fonctionnalités pourtant disponible sous les autres OS (je dépasse donc le cadre de X11 pour aborder comment ça se passe aussi sous Windows ou MacOS).
Le 09/07/2025 à 14h40
Si Gnome est réellement important pour BSD, implémenter Wayland ne devrait pas être trop problématique, et sinon, il y a d'autres environnements desktop qui peuvent faire le boulot.
Sinon, pour KiCad, je ne pense pas que les changements nécessaires à produire une interface mono-fenêtre soient impossibles. Si tu prend Gimp en référence, je me dois de te rappeler que gimp a été à ses débuts un beau merdier multi-fenêtres et que le projet a réussi à rectifier le tir en présentant une interface plus structurée. Je suis certain que KiCad pourrait faire de même si l'expérience utilisateur sous linux a de l'importance pour ses auteurs.
Le 09/07/2025 à 16h06
Des bibliothèques comme jQuery ont vu le jour et ont été très populaire en leur temps car justement, elles apportaient une couche d'abstraction et d'indépendance vis-à-vis des navigateurs.
Ce n'est qu'après coup que cela a été standardisé (enfin, le HTML est venu beaucoup plus tôt, c'était après plus une question de respect des standards que d'un manque de standardisation)
Non. On est d'accord. Tout est toujours possible. Mais pour reprendre Gimp (et je me souviens très bien de ces fenêtres que je détestais, toujours en train de les chercher ^^), la migration ne s'est pas faite en un jour. Il a fallu beaucoup de temps. Tout comme il a fallu beaucoup de temps pour migrer de Gtk2 à Gtk3 (près de 10 ans)
Le 09/07/2025 à 02h00
D'un point de vue sécurité X11 n'est pas quelque-chose de solide, on a appris à vivre avec ses défauts, mais c'est loin d'une solution parfait. Xorg lui-même a ses propres problèmes d'architecture sécurité impossibles à corriger sans casse.
Redémarrer avec une architecture plus nouvelle et plus rectifiable avec le temps est une approche bien plus raisonnable que de s'accrocher à des protocoles datés et des architectures obsolètes.
"Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides."
- Henry Ford
Le 14/07/2025 à 12h19
Le vrai changement c'est que SSH s'occupe lui-même d'identifier le client de manière sécurisée au lieu de simplement faire passer le username et password sur la ligne.
Il existerait donc un "Secure X" qui se contenterait de rendre la connexion sécurisée en identifiant le client et en chiffrant les communications. Une fois que le client est identifié positivement, cela permet de le sandboxer (il ne voit que les fenêtres - et clipboard - qu'il a lui-même créées, par exemple, les autres lui apparaissant simplement comme intégralement noires et inertes)
Et maintenant que j'y réfléchis, ben les navigateurs sont arrivés à faire de la sécurité, du sandboxing, etc. sans casser les sites existants. Si un site demande le contenu du clipboard et que je n'ai pas envie, ben il le voit pas...
Quant à Henry Ford, il s'avance un peu. Les gens auraient probablement dit "des locomotives qui n'ont pas besoin de rails".
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?