Discussion :

[Bardaz]

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.

[kain_tn]

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

[calvaire]

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.

[chown6471]

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

[Bardaz]

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.

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.

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.

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.

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.

[calvaire]

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.

[Bardaz]

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.

[kain_tn]

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

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.

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.

[Alex]

Canonical publie Ubuntu 25.10 avec GNOME 49 comme bureau par défaut, le noyau Linux 6.17 pour une compatibilité plus large avec les systèmes ARM64 et RISC-V, et le chiffrement TPM pour plus de sécurité

Ubuntu 25.10 « Questing Quokka » est officiellement disponible sous la forme d'une version à court terme prise en charge jusqu'en juillet 2026, avec une mise à niveau directe vers Ubuntu 26.04 LTS en avril prochain. Cette version introduit GNOME 49 comme bureau par défaut, fonctionnant exclusivement sur Wayland avec les pilotes NVIDIA qui prennent désormais en charge la mise en veille et la reprise. Il est livré avec le noyau Linux 6.17, qui offre une meilleure durabilité des SSD, des performances EXT4 améliorées et une compatibilité plus large avec les systèmes ARM64 et RISC-V.

Ubuntu est une distribution Linux basée sur Debian et composée principalement de logiciels libres et open source. Développée par la société britannique Canonical et une communauté de contributeurs selon un modèle de gouvernance méritocratique, Ubuntu est disponible en plusieurs éditions officielles : Desktop, Server, et Core pour l'IoT et les appareils robotiques. Ubuntu est publié selon un cycle de publication de six mois, avec des versions à support à long terme (LTS) publiées tous les deux ans.

Plusieurs rapports ont révélé quelques particularités d'Ubuntu 25.10. Avec Ubuntu 25.10, Canonical prévoit d'utiliser davantage de composants système écrits en Rust et, jusqu'à présent, la plupart des discussions ont porté sur la transition vers Rust Coreutils « uutils » à la place de GNU Coreutils. Il a également été confirmé que Canonical prévoit d'utiliser sudo-rs par défaut en remplacement de sudo. Le projet sudo-rs est en développement depuis plusieurs années en tant qu'implémentation de sudo basée sur Rust, avec une mémoire sécurisée, qui peut servir de remplacement.

En outre, Ubuntu Linux 25.10 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.

Récemment, Ubuntu 25.10 « Questing Quokka » est officiellement disponible sous la forme d'une version à court terme prise en charge jusqu'en juillet 2026, avec une mise à niveau directe vers Ubuntu 26.04 LTS en avril prochain. Cette version introduit GNOME 49 comme bureau par défaut, fonctionnant exclusivement sur Wayland avec les pilotes NVIDIA qui prennent désormais en charge la mise en veille et la reprise, offrant des animations plus fluides, des panneaux de configuration améliorés et de meilleures options d'accessibilité sur les écrans de verrouillage et de connexion. Nautilus ajoute une fonction de recherche améliorée avec des filtres, un sélecteur de date et une meilleure navigation au clavier. Loupe remplace Eye of GNOME comme visionneuse d'images, et Ptyxis prend le relais en tant que nouveau terminal accéléré par GPU avec des onglets, des connexions à distance et une barre d'en-tête rouge pendant les sessions élevées.

Les notifications système sont désormais moins intrusives, affichant les mises à jour via des alertes et une icône dans la barre d'état système au lieu d'ouvrir de nouvelles fenêtres. La sécurité fait un grand pas en avant avec le chiffrement complet du disque optionnel soutenu par TPM, qui permet le déverrouillage automatique via TPM 2.0 ou une phrase de passe, la gestion des clés de récupération étant assurée par le Centre de sécurité et le Firmware Updater.

Sous le capot, Ubuntu 25.10 adopte dracut pour la gestion du démarrage, introduit sudo-rs basé sur Rust pour une gestion plus sûre des privilèges et remplace GNU coreutils par rust-coreutils. Il est livré avec le noyau Linux 6.17, qui offre une meilleure durabilité des SSD, des performances EXT4 améliorées et une compatibilité plus large avec les systèmes ARM64 et RISC-V. L'inclusion de Mesa 25.2.3 affine encore les performances graphiques avec une compilation plus rapide des shaders, un meilleur ray tracing AMD RDNA3 et une conformité totale avec Vulkan 1.4 pour les GPU Arm Mali.

Jon Seager, vice-président de l'ingénierie Ubuntu chez Canonical, a commenté : « Ubuntu 25.10 est une déclaration d'intention pour la prochaine version LTS d'Ubuntu en 2026. Canonical continue de fournir un système d'exploitation Linux résilient et performant qui a gagné la confiance des particuliers et des entreprises, des fabricants et développeurs aux sociétés du Fortune 500, sur tous les types de matériel, des appareils IoT aux centres de données modernes. Je suis particulièrement satisfait des progrès réalisés en matière d'utilitaires sécurisés pour la mémoire et des améliorations apportées à notre chiffrement complet du disque soutenu par TPM. »

GNOME 49 et améliorations de l'accessibilité

Ubuntu 25.10 intègre GNOME 49. Cette mise à jour introduit des commandes multimédia et d'alimentation sur l'écran de verrouillage, une accessibilité améliorée et des paramètres de luminosité HDR. Les utilisateurs trouveront également deux nouvelles applications : Loupe, une visionneuse d'images moderne, et Ptyxis, un nouvel émulateur de terminal. Ces ajouts s'inscrivent dans le cadre d'un effort plus large visant à moderniser l'ensemble des applications d'Ubuntu. En sélectionnant l'option « installer les extras restreints » dans le programme d'installation, vous activerez désormais la prise en charge d'un plus grand nombre de codecs Bluetooth (AAC) et l'enregistrement d'écran accéléré par le matériel dans GNOME, ce qui améliorera encore les performances.

Conformément à la loi européenne sur l'accessibilité (EAA), Canonical poursuit ses efforts de longue date pour rendre Linux facile à utiliser pour tous. L'App Center et les panneaux de configuration d'Ubuntu offrent une meilleure prise en charge du mode contraste élevé, de la navigation au clavier et de la lecture d'écran. L'écran de connexion introduit également un menu d'accessibilité plus visible, facilitant l'accès aux technologies d'assistance dès le départ.

Des chaînes d'outils de nouvelle génération améliorent l'expérience des développeurs

Ubuntu 25.10 est livré avec OpenJDK 25, la dernière version de Java, et les dernières versions en amont pour Python (3.14 RC3), Golang (1.25) et GCC (15). Rust 1.85 sera la version par défaut, et 1.88 est également disponible. Un aperçu du nouveau compilateur du langage Zig est disponible dans cette version pour amd64 et arm64.

De plus, cette version comprend un aperçu de .NET 10, la prochaine version LTS de .NET dont la sortie est prévue en novembre. Canonical continue d'améliorer l'expérience des développeurs .NET sur Ubuntu grâce à un plugin .NET Snapcraft amélioré qui optimise la prise en charge des configurations monorepo et offre une meilleure expérience de développement avec MSBuild grâce à des attributs de drapeau personnalisés. De plus, les outils populaires de Powershell sur Windows sont désormais disponibles dans Ubuntu sur les plateformes arm64, ppc64el et s390x via le snap Powershell.


Implémentations basées sur Rust de sudo et coreutils pour une sécurité mémoire améliorée

Canonical s'engage à accroître la résilience des logiciels système critiques dans Ubuntu en adoptant des implémentations modernes de composants clés tels que sudo et coreutils. Dans le cadre de cette initiative, Ubuntu 25.10 utilise sudo-rs, une nouvelle implémentation Rust de l'outil sudo. Bien que le sudo basé sur Rust soit le sudo par défaut dans cette nouvelle version, l'outil sudo traditionnel reste disponible pour les utilisateurs qui en ont besoin.

L'introduction d'un sudo sécurisé en mémoire offre de nombreux avantages par rapport à l'implémentation traditionnelle. Pour les utilisateurs, la réduction de la surface d'attaque dans l'outil sudo améliorera la sécurité globale d'Ubuntu. Canonical invite les utilisateurs à tester l'outil et à faire part de leurs commentaires avant son inclusion dans la prochaine version Ubuntu 26.04 LTS.

« Chez Trifecta Tech Foundation, notre objectif est de rendre les composants essentiels tels que sudo plus sûrs et plus robustes pour tous », a déclaré Erik Jonkers, président de Trifecta Tech Foundation. « L'arrivée de sudo-rs dans Ubuntu est une grande réussite qui nous réjouit énormément. Nous félicitons Canonical d'avoir mis l'accent sur la sécurité de la mémoire et les remercions pour leur collaboration au cours des derniers mois afin de préparer sudo-rs pour la version 25.10. Nous sommes convaincus qu'en travaillant ensemble et en tenant compte des commentaires, nous pouvons faire de cette transition une transition transparente qui améliorera la sécurité des utilisateurs d'Ubuntu. »

De même, Ubuntu 25.10 est la première version majeure de la distribution Linux à adopter l'implémentation de coreutils par uutils, qui est une réimplémentation complète du paquet GNU coreutils traditionnel en Rust, avec pour objectifs principaux la compatibilité et la sécurité de la mémoire.


Améliorations de la sécurité de la plateforme avec le chiffrement complet du disque (FDE) basé sur TPM

Ubuntu 25.10 offre une prise en charge expérimentale du chiffrement complet du disque (FDE) basé sur TPM, qui permet de garantir que tout le contenu du disque est chiffré et inaccessible au repos. Un TPM, ou Trusted Platform Module, est une puce que l'on trouve dans la plupart des ordinateurs modernes.

Le FDE basé sur TPM est une méthode de sécurité qui utilise le Trusted Platform Module pour stocker des clés cryptographiques afin de chiffrer le disque dur, rendant les données illisibles sans la clé correcte au moment du démarrage. Les nouvelles fonctionnalités comprennent la prise en charge et la gestion des phrases de passe, la régénération de la clé de récupération et une meilleure intégration avec les mises à jour du micrologiciel, ainsi que la stabilisation des composants de base du système afin de préparer la voie pour la prochaine version LTS d'Ubuntu. Les utilisateurs soucieux de la sécurité peuvent tester cette implémentation FDE dans la version 25.10, mais elle n'est pas encore recommandée pour les environnements de production.

Suite à l'intégration initiale de Network Time Security (NTS) dans Ubuntu 25.04, Questing Quokka est livré avec NTS activé par défaut. NTS renforce la sécurité du protocole NTP (Network Time Protocol) en fournissant une couche cryptographique d'authentification pour le processus de synchronisation horaire. Cela augmente la résilience contre les attaques de type « man-in-the-middle » et autres risques de sécurité similaires. NTS utilise le protocole TLS (Transport Layer Security) pour garantir que les données temporelles proviennent d'une source fiable.


Le noyau Linux 6.17 offre une virtualisation imbriquée et des charges de travail confidentielles améliorées.

Conformément à l'engagement de Canonical à activer les dernières fonctionnalités et la prise en charge du matériel, Ubuntu 25.10 est livré avec le dernier noyau Linux, version 6.17.

Ubuntu 25.10 offre un accès anticipé à la fonctionnalité de virtualisation imbriquée sur Arm, suite à son inclusion dans le noyau Linux en amont. La virtualisation imbriquée permet aux fournisseurs de cloud et aux développeurs d'exécuter des hyperviseurs à l'intérieur de machines virtuelles, ce qui permet des pipelines CI/CD avancés, des environnements de test flexibles et une isolation plus forte des charges de travail. Ubuntu 25.10 introduit la prise en charge de cette technologie sur des plateformes telles que NVIDIA Grace et AmpereOne, ouvrant la voie à une utilisation plus large et à la maturité de la virtualisation imbriquée sur Arm.

Bhumik Patel, directeur du développement de l'écosystème serveur, division Infrastructure, Arm, a déclaré : « À mesure que l'infrastructure cloud devient plus dynamique, la capacité à exécuter des charges de travail imbriquées en toute sécurité est essentielle pour faire évoluer les services de manière efficace tout en conservant une isolation forte et une flexibilité opérationnelle. Ubuntu 25.10 permettant la virtualisation imbriquée sur les plateformes basées sur Arm, tant dans le cloud que sur site, les développeurs et les opérateurs peuvent faire progresser le développement et le déploiement de cette puissante fonctionnalité. En collaboration avec Canonical, nous accélérons l'adoption de solutions cloud sécurisées et évolutives basées sur Arm. »


Cette dernière version intermédiaire d'Ubuntu jette également les bases d'une prise en charge native d'Intel TDX avec Ubuntu 26.04 LTS comme système d'exploitation hôte. Intel TDX est une technologie qui crée des machines virtuelles isolées au niveau matériel pour le calcul confidentiel, ce qui la rend idéale pour prendre en charge les salles blanches de données et les charges de travail confidentielles liées à l'IA. Les noyaux Ubuntu 25.10 seront livrés avec la prise en charge de l'hôte Intel TDX, permettant aux entreprises d'exécuter et de bénéficier d'une assistance pour le calcul confidentiel dans leurs centres de données ou leurs clouds privés.


Nouveau profil RVA23 pour une adoption accélérée de RISC-V

Avec Ubuntu 25.10, Canonical adopte le RVA23 récemment ratifié comme profil de base pour ses versions RISC-V. Le RVA23 contribue à accélérer la croissance de l'écosystème RISC-V en garantissant la compatibilité entre les différentes implémentations RISC-V. Cette initiative précoce aligne Ubuntu sur les solutions de classe RVA23 qui arrivent sur le marché et permet de procéder rapidement à des tests rigoureux, à la correction des bogues et au triage des problèmes. Cet effort permet de préparer Ubuntu 26.04 LTS pour le RVA23 et fournit à l'écosystème RISC-V une feuille de route et un objectif prévisibles.

Andrea Gallo, PDG de RISC-V International, a déclaré : « RISC-V International se réjouit de voir Canonical adopter le profil RVA23 pour Ubuntu. RVA23 a été ratifié afin d'accélérer la mise en œuvre généralisée de RISC-V dans les chaînes d'outils et les systèmes d'exploitation, de jeter les bases de processeurs d'applications modernes hautement performants prenant en charge les vecteurs et les hyperviseurs, et d'assurer la compatibilité binaire au niveau des applications. Notre collaboration avec Canonical renforce l'écosystème logiciel RISC-V et favorise l'adoption de RISC-V dans les applications d'entreprise, de l'IoT au HPC. »


À propos de Canonical

Canonical, l'éditeur d'Ubuntu, fournit des solutions de sécurité, d'assistance et des services open source. Son portefeuille couvre les systèmes critiques, des plus petits appareils aux plus grands clouds, du noyau aux conteneurs, des bases de données à l'IA. Avec une clientèle composée de grandes marques technologiques, de start-ups émergentes, d'administrations et d'utilisateurs particuliers, Canonical fournit des solutions open source fiables pour tous.

Source : Canonical

Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Canonical publie Ubuntu 25.04 Plucky Puffin, avec Linux 6.14, GNOME 48, des "devpacks" pour des frameworks populaires comme Spring, et des améliorations de performance sur une large gamme de matériel

Ubuntu célèbre ses 20 ans : il y a 20 ans, Ubuntu sortait sa version 4.10 "Warty Warthog", changeant à jamais l'écosystème Linux, et en octobre 2024 sortait Ubuntu 24.10 "Oracular Oriole"

Le noyau Linux 6.17 est officiellement disponible avec des gains pour les ordinateurs portables Intel/AMD, des améliorations en matière de stockage et de réseau, ainsi qu'une latence réduite

[luigifab]

C'est fou ça, la 25.10 fonctionne encore moins bien que la 25.04 dans VirtualBox ! pas de réseau (un bug avec l'ipv6), le fait d'ajouter une résolution d'écran ne fonctionne pas (vu que la taille d'écran en fonction de la taille de la fenêtre ne fonctionne pas).

Et je comprends pas pourquoi (Ubuntu-MATE) l'écran de bienvenue apparaît après l'autologin, passé un temps il apparaissait avant, ce qui faisait que MATE se chargeait dans la bonne langue.

[RedGuff]

@luigifab Bonjour. Il faut rester en LTS, svp. Merci.

[pascalbaudry]

Merci à chown6471 pour son intervention instructive.

Je ne suis pas surpris que les développeurs de Xubuntu ne retiennent pas Wayland, leur mot d'ordre c'est la fiabilité.

"Ubuntu 25.10 est lancé avec GNOME 49, le noyau Linux 6.17, le chiffrement TPM et bien plus encore" : je ne suis pas foutu de comprendre le dixième des évolutions d'Ubuntu mais je me pose la question de savoir si Canonical a recruté beaucoup de "Yesmens".

[pascalbaudry]

C'est fou ça, la 25.10 fonctionne encore moins bien que la 25.04 dans VirtualBox ! pas de réseau (un bug avec l'ipv6), le fait d'ajouter une résolution d'écran ne fonctionne pas (vu que la taille d'écran en fonction de la taille de la fenêtre ne fonctionne pas).

Et je comprends pas pourquoi (Ubuntu-MATE) l'écran de bienvenue apparaît après l'autologin, passé un temps il apparaissait avant, ce qui faisait que MATE se chargeait dans la bonne langue.

Le problème d'affichage souvent rencontré sous Ubuntu (et dérivés) c'est le non respect du rapport de définition de l'écran H/V dans le choix de l'affichage. Lorsque ce rapport n'est pas respecté Canonical a du mal à traiter l'affichage, alors que cela ne pose aucun problème sous MS.