Discussion :

[Jade Emy]

Ubuntu sera la première grande distribution Linux à adopter sudo-rs, une réimplémentation à sécurité mémoire de l'utilitaire sudo largement utilisé, écrit dans le langage de programmation Rust.

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. Le projet sudo-rs est maintenu par la fondation à but non lucratif Trifecta Tech Foundation, qui a confirmé le projet de Canonical d'utiliser sudo-rs par défaut avec Ubuntu 25.10.

En 2023, Amazon Web Services a financé un projet de réécriture de sudo et su dans le langage de programmation Rust afin d'augmenter la sécurité de la mémoire pour les logiciels largement utilisés et pour améliorer davantage la sécurité Linux/open-source. Cette initiative confirme une tendance à remédier aux nombreuses vulnérabilités liées à des problèmes de sécurité de la mémoire.

C'est dans cette optique que Ubuntu 25.10 devrait adopter par défaut l'utilitaire sudo-rs. Sudo-rs est une réimplémentation à sécurité mémoire de l'utilitaire sudo, largement utilisé, écrit dans le langage de programmation Rust. Cette décision s'inscrit dans le cadre d'un effort plus large de Canonical visant à améliorer la résilience et la maintenabilité des principaux composants du système. Sudo-rs est développé par la Trifecta Tech Foundation (TTF), une organisation à but non lucratif qui crée des blocs de construction sécurisés et open source pour les logiciels d'infrastructure.

La décision d'adopter sudo-rs est conforme à l'engagement de Canonical d'augmenter prudemment mais volontairement la résilience des logiciels système critiques, en adoptant Rust. Rust est un langage de programmation qui offre de solides garanties en matière de sécurité de la mémoire et qui élimine de nombreuses vulnérabilités qui ont historiquement affecté les logiciels traditionnels basés sur le langage C.

Sudo-rs fait partie de l'initiative Privilege Boundary de la Trifecta Tech Foundation, qui vise à gérer l'escalade des privilèges à l'aide d'alternatives sûres pour la mémoire.

Bien qu'aucun logiciel - quel que soit le langage - ne soit parfait, nous pensons que la transition vers Rust dans la programmation des systèmes est un pas en avant vital. Il est très excitant de voir Ubuntu s'engager en faveur de sudo-rs et jouer un rôle de premier plan pour faire avancer les choses.

Préparation à l'adoption générale par les distributions Linux

Pour préparer l'adoption générale, les mainteneurs de sudo-rs achèveront les travaux décrits dans le plan de travail de l'étape 5 du projet :

• La prévention des évasions de l'interpréteur de commandes (NOEXEC) à gros grain sur Linux
• La possibilité de contrôler les profils AppArmor
• sudoedit
• La prise en charge des noyaux Linux antérieurs à la version 5.9, utilisée par Ubuntu 20.04 LTS.

Canonical sponsorise cette étape pour faire de sudo-rs une implémentation encore meilleure de la commande sudo. Avec les fonctionnalités ci-dessus, plus d'utilisateurs et d'administrateurs système devraient être en mesure d'utiliser sudo-rs sans aucun changement dans leur flux de travail actuel.

Les responsables de sudo-rs s'en tiennent à l'approche "moins c'est plus" : certaines fonctionnalités du sudo original ne seront pas implémentées dans sudo-rs si elles ne servent que des cas d'utilisation très spécialisés. Les mainteneurs poursuivent leur collaboration avec Todd Miller, le mainteneur de sudo en place depuis plus de trente ans, améliorant ainsi indirectement le sudo original en tant que sous-produit de cet engagement.

Je suis ravi d'investir dans des logiciels critiques de bas niveau. Ubuntu est le système d'exploitation Linux le plus largement déployé, et en choisissant d'adopter sudo-rs, j'espère accélérer le chemin vers une adoption plus large à travers l'écosystème Linux.

Canonical prévoit de faire de sudo-rs la version par défaut d'Ubuntu 25.10. Cela laissera le temps aux utilisateurs finaux d'effectuer des tests d'acceptation et permettra de s'assurer que sudo-rs a été testé avant d'être inclus dans la prochaine version de support à long terme (LTS) : Ubuntu 26.04 LTS, qui sera supportée pendant au moins 12 ans. Nous sommes impatients d'apprendre de la communauté comment nous pouvons encore améliorer sudo-rs.

Voici l'annonce de Canonical :

Adoption de sudo-rs par défaut dans Ubuntu 25.10

Introduction

Suite à la publication de Carefully But Purposefully Oxidising Ubuntu, Ubuntu sera la première distribution Linux majeure à adopter sudo-rs comme implémentation par défaut de sudo, en partenariat avec la Trifecta Tech Foundation.

Le changement sera effectif à partir de la sortie d'Ubuntu 25.10.

Qu'est-ce que sudo-rs ?

sudo-rs est une réimplémentation de l'outil sudo traditionnel, écrit en Rust. Il est développé par la Trifecta Tech Foundation (TTF), une organisation à but non lucratif qui se concentre sur la construction de composants d'infrastructure sécurisés et open source. Le projet fait partie de l'initiative Privilege Boundary de la Trifecta Tech Foundation, qui vise à gérer l'escalade des privilèges à l'aide d'alternatives sûres pour la mémoire.

La commande sudo a longtemps servi de moyen défacto d'escalade des privilèges sous Linux. Comme décrit dans le billet original, Rust fournit de fortes garanties contre certaines classes de problèmes de sécurité de la mémoire, ce qui est essentiel pour les composants à la limite des privilèges.

L'équipe sudo-rs collabore avec Todd Miller, qui maintient le sudo original depuis plus de trente ans. sudo-rs ne doit pas être considéré comme une bifurcation, mais plutôt comme une poignée de main entre plusieurs générations de systèmes sécurisés. Tout au long du développement de sudo-rs, l'équipe TTF a également contribué à l'amélioration de l'implémentation originale de sudo.

Le projet sudo-rs est conçu pour remplacer l'outil original. Pour la grande majorité des utilisateurs, la mise à jour devrait être complètement transparente pour leur flux de travail. Cela dit, sudo-rs n'est pas une réimplémentation « aveugle ». Les développeurs ont adopté une approche « moins, c'est plus ». Cela signifie que certaines fonctionnalités de la version originale de sudo peuvent ne pas être réimplémentées si elles ne servent qu'une niche, ou si elles sont considérées comme des pratiques « dépassées ».

Erik Jonkers, président de la Trifecta Tech Foundation, explique : "Bien qu'aucun logiciel - quel que soit le langage - ne soit parfait, nous pensons que la transition vers Rust dans la programmation des systèmes est un pas en avant vital, et il est très excitant de voir Ubuntu s'engager en faveur de sudo-rs et prendre les devants pour faire avancer les choses."

Sponsoriser l'adoption par le grand public

L'adoption par le grand public d'un substitut à un outil aussi universellement connu s'accompagne de responsabilités. Avant de s'engager à livrer sudo-rs dans Ubuntu 26.04 LTS, nous testerons la transition dans Ubuntu 25.10. Nous sponsorisons également le développement de certains éléments spécifiques, qui se sont manifestés en tant que jalon 5 dans le projet en amont :

• Prévention des évasions de shell à gros grain (NOEXEC) sur Linux
• La possibilité de contrôler les profils AppArmor
• Une implémentation de sudoedit
• La prise en charge des noyaux Linux antérieurs à la version 5.9

Le dernier point peut sembler déplacé, mais comme Ubuntu 20.04 LTS est toujours supporté, sans ce travail, il pourrait y avoir des situations où sudo ne fonctionnerait pas si, par exemple, un conteneur OCI 26.04 LTS était exécuté sur un hôte 20.04 LTS !

L'équipe a également déjà commencé à travailler pour s'assurer que la suite de tests est aussi compatible que possible avec Ubuntu, afin de s'assurer que tout problème soit détecté rapidement.

Il ne s'agit pas seulement de livrer un nouveau binaire. Il s'agit de définir une direction. Nous n'abandonnons pas le C, ni même ne réécrivons tous les utilitaires nous-mêmes, mais en choisissant de remplacer l'un des outils les plus critiques pour la sécurité du système par une alternative sûre pour la mémoire, nous faisons une déclaration : la résilience et la durabilité ne sont pas optionnelles dans l'avenir de l'infrastructure ouverte.

Progrès de coreutils

Depuis l'annonce initiale, nous avons travaillé dur pour définir plus clairement un plan de migration vers uutils coreutils dans la version 25.10 et au-delà. De la même manière que nous nous sommes engagés avec la Trifecta Tech Foundation, nous sponsorisons également le projet uutils pour nous assurer que certaines lacunes clés sont comblées avant la livraison de la version 25.10. Le parrainage couvrira principalement le développement du support SELinux pour les commandes courantes telles que mv, ls, cp, etc.

La première étape du développement du support SELinux a été d'ajouter le support des tests automatisés dans Github Actions, depuis lors les mainteneurs ont commencé à travailler sur l'implémentation réelle.

L'autre fonctionnalité que nous sponsorisons est la prise en charge de l'internationalisation. Actuellement, certaines implémentations d'utilitaires (comme sort) ont une compréhension incomplète des locales, et peuvent donc produire des résultats inattendus. Nous espérons que ces deux fonctionnalités seront disponibles à temps pour la version 25.10, et nous continuerons à travailler avec le projet uutils tout au long du cycle 26.04 LTS afin de combler les lacunes que nous aurons identifiées dans la version intermédiaire.

L'une des principales préoccupations soulignées dans le billet de Julian concerne la taille des binaires. Nous avons quelques astuces pour réduire cette taille, et des discussions ont déjà été entamées en amont dans Debian sur la manière d'y parvenir. Il y a aussi des implications de sécurité, comme le manque de support d'AppArmor pour les binaires multi-appels. Nous travaillons actuellement avec les amonts respectifs pour discuter de la résolution systématique de ce problème, mais dans l'intervalle, nous pourrions avoir besoin de construire de petits binaires enveloppants pour permettre la compatibilité avec les profils AppArmor existants dès le départ.

Mécanismes de migration

Julian Klode a posté récemment sur le Discourse Ubuntu un plan d'empaquetage qui nous permettra à la fois de migrer de manière transparente vers uutils coreutils, mais aussi de fournir un moyen pratique pour les utilisateurs de se retirer et de revenir à GNU coreutils s'ils le souhaitent, ou s'ils identifient une lacune dans la nouvelle implémentation. Je m'attends à ce que cela soit rare, mais nous voulons nous assurer qu'il est aussi facile que possible de revenir en arrière, et nous documenterons cela en détail avant la publication.

Remplacer coreutils n'est pas aussi simple que d'échanger les binaires. En tant que paquet Essential, son remplacement doit fonctionner immédiatement au déballage sans dépendre des scripts du mainteneur, et sans conflit de fichiers entre les paquets. Pour résoudre ce problème, nous introduisons de nouveaux paquets coreutils-from-utils et coreutils-from-gnu, ainsi que coreutils-from lui-même.

Le travail d'empaquetage nécessaire pour passer à sudo-rs est un peu moins compliqué qu'avec coreutils. Le paquet est déjà disponible dans Ubuntu (que vous pouvez toujours tester sur Ubuntu 24.04, 24.10 et 25.04 avec oxidizr 5 !), mais contrairement à coreutils, sudo n'est pas un paquet Essential, nous pourrons donc utiliser le système Debian alternatives pour la transition.

Résumé

Les choses avancent bien. Nous avons établi des relations solides et productives et nous sponsorisons le travail en amont pour rendre ces transitions viables.

Nous avons une stratégie pour migrer l'implémentation par défaut de coreutils et de sudo dans Ubuntu 25.10, ce qui permettra un retour en arrière transparent dans les cas où cela est souhaité. Alors que sudo-rs sera l'implémentation par défaut dans la version 25.10, le sudo original restera disponible pour les utilisateurs qui en ont besoin, et nous recueillerons des commentaires pour assurer une transition en douceur avant la version 26.04 LTS.

De plus, nous avons commencé à étudier la faisabilité de fournir SequoiaPGP et de l'utiliser dans APT à la place de GnuPG. SequoiaPGP est une nouvelle bibliothèque OpenPGP qui met l'accent sur la sécurité et la correction, écrite en Rust. Les mainteneurs de GnuPG ont récemment bifurqué vers le standard OpenPGP et ne sont plus en conformité avec celui-ci. Sequoia fournit une alternative moderne à GnuPG avec un comportement strict, et est déjà utilisé dans plusieurs autres systèmes. Plus de détails à venir !

Restez à l'écoute !

Sources : Trifecta Tech Foundation; Canonical, l'éditeur d'Ubuntu

Et vous ?

Pensez-vous que cette décision 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

Systemd v256 présente run0 : Une alternative plus sûre à sudo, une nouvelle approche de l'élévation de privilèges sécurisée, visant à éliminer progressivement les binaires SUID traditionnels

Que pensent les développeurs du noyau Linux de Rust ? Le langage est pour d'aucuns une opportunité de combler les faiblesses du C en sécurisation de la mémoire des logiciels et un cancer pour d'autres

[Markand]

Comme beaucoup, je suis passé à doas. Simple, efficace et un fichier de configuration compréhensible en 3 mots.

[air-dex]

Quitte à partir en transition, pourquoi ne pas abandonner bash au profit de Powershell qui est bien mieux conçu ?

[meylodie]

Quitte à partir en transition, pourquoi ne pas abandonner bash au profit de Powershell qui est bien mieux conçu ?

Non non non non…

[meylodie]

Comme beaucoup, je suis passé à doas. Simple, efficace et un fichier de configuration compréhensible en 3 mots.

Dans le détail, quels avantages y trouvez-vous, par rapport à l'actuel sudo ?

[papajoker]

A noter que systemd embarque run0 depuis la version 256
systemd 257 c'est déjà dans unbutu 25.04 il me semble

https://linux.developpez.com/actu/35...traditionnels/

un fichier de configuration compréhensible en 3 mots.

Clairement pas le cas avec run0, puisqu'il utilise la config polkit (c'est du javascript dans 36 fichiers), mais au moins on a la même config polkit/run0 ce qui est un avantage.

[disedorgue]

Moi, j'attend le futur langage frameto...

[Christophe]

Quitte à partir en transition, pourquoi ne pas abandonner bash au profit de Powershell qui est bien mieux conçu ?

D'une part PowerShell est un produit Windows, pas Linux, d'autre part reste à démonter qu'il est mieux.

MAis apperemrent il y a une version Linux :
https://learn.microsoft.com/fr-fr/po...powershell-7.5

Ca doit être limité ou surtout utile pour gérer une machine Wndows à distance.

[air-dex]

Non non non non…

D'une part PowerShell est un produit Windows, pas Linux, d'autre part reste à démonter qu'il est mieux.

MAis apperemrent il y a une version Linux :
https://learn.microsoft.com/fr-fr/po...powershell-7.5

Ca dit être limité ou surtout utile pour géer une machine Wndows à distance.

De Powershell je vois surtout :

• Des noms de commandes qui ont du sens, avec leur nomenclature claire "Verbe-Nom" et la volonté de limiter les verbes pour ne pas partir dans tous les sens. Du coup on se retrouve avec des noms bien plus clairs et logiques les uns par rapport aux autres qu'en Bash. C'est plus facile de voir le lien entre un New-Item, un Remove-Item, un Copy-Item et un Move-Item, qu'entre un touch, un rm, un cp et un mv. C'est plus cohérent et logique, et donc plus facile à retenir.
• Des alias pour s'assurer une petite rétrocompatibilité avec des script cmd ou bash simples, ainsi que pour ne pas perdre ceux qui viennent de cmd ou de Bash.
• Des commandes non-WYSIWYG qui facilitent l'utilisation de leurs résultats. C'est simple, pas comme en Bash où il faut se farcir des commandes sed ou awk absolument imbittables pour parser les résultats retournés.
• Une gestion un minimum carrée des paramètres passés aux scripts.
• La puissance de .NET qui propulse Powershell. C'est plus simple pour manipuler des strings dans un script, par exemple.
• Désormais un minimum de multiplateforme, là où Bash et cmd bon voilà quoi.

Certes Powershell n'est pas parfait, surtout sur Linux. Mais on sent que ceux qui l'ont conçu se sont posés les bonnes questions et y ont bien répondu sur bien des aspects. C'est pour ça que je le qualifie "bien conçu", pour ne pas dire "moderne".

Par opposition au bon vieux Bash à papa et ses utilisateurs sous syndrome de Stockholm quand il s'agit de commandes des enfers telles que awk et sed, ou encore des noms de commandes avec peu de liens et de logique entre eux.

[Christophe]

En mode interactif, je préfère les commandes courtes telles que cp, rm. mais si cela gène on peut créer des aliases. sur les commandes elles-mêmes ou sur les commandes avec paramètres.
sed et awk sont puissants mais complexes, mais ce sont des commandes externes à Bash. Et il y en a plein d’autres plus simples, plus limitées mais plus facile (commandes pouvant être remplacées par sed et Awk par exemple).

Ce qui ressemblerait le plus au PowerShell sous Linux serait Python.
Powershell est un peu comme une amélioration de cmd d'une part, et intégration de vbscript (amélioré) d'autre part. Il n'a pas tout à fait le même objectif que Bash

Bash est adapté au monde unix/linux, PowerShell au monde Windows

Il est toujours possible d'utiliser Bash sous Windows notamment avec WSL ou PowerShell sous Linux avec les limitations afférentes aux fonctionnements différentes des 2 OS, mais pour être efficace, mieux vaut utiliser l'outil natif de l'OS. Le contraire va être très rarement pertinent.

[Ti-Slackeux]

De Powershell je vois surtout :

• Des noms de commandes qui ont du sens, avec leur nomenclature claire "Verbe-Nom" et la volonté de limiter les verbes pour ne pas partir dans tous les sens. Du coup on se retrouve avec des noms bien plus clairs et logiques les uns par rapport aux autres qu'en Bash. C'est plus facile de voir le lien entre un New-Item, un Remove-Item, un Copy-Item et un Move-Item, qu'entre un touch, un rm, un cp et un mv. C'est plus cohérent et logique, et donc plus facile à retenir.

Je vois pas ou est le problème :
rm : remove
cp : copy
mv : move
cd : change directory
sed : stream editor
pwd : print working directory
rmdir : remove directory
mkdir : make directory

Et c'est pareil dans d'autres langages comme l'assembleur ou dans du langage dédié à la robotique.

Par opposition au bon vieux Bash à papa et ses utilisateurs sous syndrome de Stockholm

Dat LOL ! Je vais même pas relever.

[disedorgue]

A part pwd et cd, je ne vois pas le rapport avec bash ou autre sh

sed,awk,mv,rm,ls,... sont des commande unix/linux/gnu qui n'ont rien à voir avec le shell

powershell intègre peut-être des builtin qui permettent de ce passer de ces commandes, mais en bash, on peut aussi s'en passer sauf pour mv et rm , tous le reste est faisable sans commandes externes

[papajoker]

Mais pourquoi alimenter le troll ?

utilisateurs sous syndrome de Stockholm

Pourtant ms aime, puisqu'il propose pour windows 2 commandes dignes de grand-pap

je ne vois pas le rapport avec bash ou autre sh

typique d'un troll, il ne sait même pas de quoi il parle. perso je ne suis même pas avec bash ou zsh dans mon terminal et cela ne m'empeche pas d'utiliser sudo (ou run0) à l'occasion.

[air-dex]

Je vois pas ou est le problème :
rm : remove
cp : copy
mv : move
cd : change directory
sed : stream editor
pwd : print working directory
rmdir : remove directory
mkdir : make directory

Je n'ai pas dit que les noms de commandes n'avaient pas de signification. Je dis surtout qu'il n'y a pas de cohérence entre eux. Certains manipulant les dossier finissent en -dir, d'autres juste avec un -d. chdir ne serait-il pas plus logique que cd ? De même quand on crée, pourquoi touch pour un fichier et mkdir pour un dossier, alors que les deux créent quelque chose de nouveau ? C'est quoi la logique dans le nommage des commandes ? En quoi c'est mieux que ce que fait MS avec Powershell ?

De même, montrez-moi la simplicité des commandes sed et awk si elles le sont au lieu de préférer ne même pas en parler. Ça m'intéresse tellement elles me rebutent ces deux commandes des enfers.

Merci de me répondre clairement et en argumentant avant de me traiter de troll.

[Christophe]

pour sed et awk, tu as pleins de commandes alternatives plus simples et plus spécialisés.

sed n'est pas qu'une commande, il peut être vu comme un éditeur de texte non interactif.
Dans les grandes lignes sed servant à faire des traitements par ligne, awk des traitements par champs.

Ce sont des outils puissants, et du coup complexes.

Mais comme ça a été évoqué, c'est hors sujet, l'article parlant du remplacement de la commande sudo par sa version Rust.

[Stéphane le calme]

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.

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 ?

[Bardaz]

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.

[Anthony]

Kubuntu 25.10 n'inclura pas de session de bureau Plasma X11 par défaut, rejoignant ainsi la version standard d'Ubuntu dans sa volonté de privilégier Wayland à l'avenir

Kubuntu 25.10 n'inclura pas de session de bureau Plasma X11 par défaut, rejoignant ainsi la version standard d'Ubuntu dans sa volonté de privilégier Wayland à l'avenir. La variante officielle d'Ubuntu, qui est fournie avec l'environnement de bureau KDE Plasma et les technologies associées, ne proposera ainsi qu'une session d'affichage Wayland pour les nouvelles installations dans Kubuntu 25.10, qui sortira le 9 octobre 2025.

La décision de Kubuntu reflète la stratégie de Canonical dans Ubuntu 25.10, qui abandonne la prise en charge de GNOME s'exécutant sur Xorg. Avec Ubuntu Linux 25.10, surnommée « Questing Quokka », 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.

Pour rappel, Kubuntu est un système d'exploitation libre de type GNU/Linux. C'est un projet visant à utiliser l'environnement graphique KDE à la place de Unity puis de Gnome au sein d'Ubuntu. Le projet Kubuntu est une distribution dérivée d'Ubuntu, car tous deux partagent exactement la même base, les mêmes logiciels, les mêmes dépôts APT, le même nom de code et le même cycle de développement.

La récente décision n'est pas vraiment surprenante et fait écho à l'annonce selon laquelle Ubuntu 25.10 sera exclusivement compatible avec Wayland (même si cela s'explique par le fait que les développeurs GNOME en amont sont en train de supprimer le code qui permet à GNOME Shell de fonctionner sur Xorg/X11).

Les développeurs KDE prévoient également de supprimer progressivement la prise en charge de X11 (sans date butoir précise, mais probablement d'ici la sortie de KDE Plasma 7). Ils ont séparé le code Wayland et X11 en deux paquets distincts dans la dernière version KDE Plasma 6.4.

Rik Mills, développeur chez Kubuntu, a clarifié les plans concernant le protocole du serveur d'affichage pour la prochaine version, en répondant à un utilisateur qui demandait si les sessions X11 seraient supprimées :

« Pour l'instant, nous avons l'intention d'intégrer Wayland par défaut dans l'ISO et les installations, mais les utilisateurs qui souhaitent conserver une session X11 pourront toujours installer X11 », a déclaré Rik Mills, développeur chez Kubuntu.

Les plans peuvent changer, mais l'intention est claire.

Pourquoi Kubuntu 25.10 abandonne X11

Tout comme GNOME, les développeurs de KDE estiment que l'ajout de nouvelles fonctionnalités, l'exploitation des nouvelles capacités matérielles et l'amélioration de la sécurité du bureau se feront plus rapidement sans avoir à maintenir et à contourner l'ancien code Xorg.

Cependant, KDE Plasma 6.4, qui sera probablement la version KDE utilisée dans Kubuntu 25.10, fonctionne toujours dans une session X11 (alors que GNOME 49 ne fonctionnera probablement pas).

Si cela fonctionne toujours, pourquoi le supprimer ?

Rik Mills, de Kubuntu, explique plus en détail : « Il est très improbable que nous puissions prendre en charge la session X11 dans la version 26.04 LTS, donc, comme pour le bureau Ubuntu, il vaut probablement mieux supprimer ce pansement dans la version 25.10 et se concentrer sur Wayland ».

Ubuntu 25.10 n'inclut plus les paquets Xorg dans son « seed » (ensemble de paquets requis) pour les ordinateurs de bureau, laissant ainsi aux versions officielles le soin de les ajouter à leurs seeds respectifs (si elles le souhaitent).

Kubuntu ne le fait pas ; les dernières ISO quotidiennes d'Ubuntu 25.10 reflètent le changement vers Wayland uniquement et n'intègrent plus de session Plasma X11.

La prise en charge de X11 est toujours disponible dans la version 25.10

Si vous préférez ou avez besoin de X11, vous avez toujours le choix.

Vous pouvez installer une session X11 dans Kubuntu 25.10 en récupérant le paquet plasma-session-x11 depuis les dépôts questing à l'aide d'apt ou d'un autre outil, puis en sélectionnant la session Xorg dans SSDM, l'écran de connexion KDE, et en vous connectant normalement.

Les mises à niveau depuis Kubuntu 25.04 ne devraient pas être affectées ; les paquets de session Xorg ne seront pas désinstallés lors de la mise à niveau.

Il n'est pas forcément nécessaire d'utiliser X11. Un grand nombre d'applications et d'outils plus anciens conçus pour X11 fonctionnent sous Wayland (via XWayland) sans problème ou presque. Il est vrai que la prise en charge du matériel plus ancien dans Wayland peut varier, mais vous avez tout de même le choix.

D'autres versions d'Ubuntu, notamment Xubuntu, Ubuntu Budgie, Ubuntu Unity et Ubuntu Cinnamon, devraient continuer à offrir la prise en charge de X11 dans leurs programmes d'installation/installations par défaut respectifs pour ce cycle.

Plus la rupture avec le passé sera radicale, plus les développeurs d'applications tiers seront incités à s'adapter ou à adopter les protocoles Wayland et les portails de bureau. C'est une bonne chose, car Wayland offre une sécurité et des performances supérieures à celles du système X11, vieux de plusieurs décennies.

Source : Rik Mills, développeur chez Kubuntu

Et vous ?

Quel est votre avis sur le sujet ?
Trouvez-vous cette décision de Kubuntu crédible ou pertinente ?

Voir aussi :

L'environnement de bureau GNOME 48 "Bengaluru" est officiellement disponible, avec un triple buffering dynamique, le protocole de gestion des couleurs Wayland et une nouvelle fonctionnalité de bien-être

Linux Ubuntu 24.10 utilisera par défaut Wayland pour les utilisateurs de NVIDIA, car NVIDIA s'est adapté à Wayland, qui est désormais la norme

[JPLAROCHE]

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.

[tenchirock]

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 !