KDE 6.8 : Wayland ou rien… Encore heureux, il y aura du temps pour s’adapter !

Il fallait bien que ça arrive. Après presque 30 ans de bons et loyaux services, le vénérable X11 tire sa révérence dans KDE. Plasma 6.8 sera Wayland-only, avec Xwayland comme béquille pour les vieilles applications. Autrement dit : si vous espériez encore lancer votre session X11 en douce, oubliez. C’est fini, terminé, enterré. Mais rassurez-vous, KDE 6.7 est prévu pour début 2027, dixit Phoronix. Je cite :

[…]Plasma X11 session support will remain supported into early 2027 with the Plasma 6.7 series.

Ce qui donne traduit :

[…]Le support de la session Plasma X11 sera supporté jusqu’en début 2027 avec la série Plasma 6.7

Soyons clairs : la majorité des distributions avaient déjà basculé par défaut sur Wayland. Fedora, Ubuntu, openSUSE… Tout le monde y est passé. KDE ne fait que suivre le mouvement, mais en coupant définitivement le cordon. Et pour les utilisateurs ? Dans 95 % des cas, vous ne verrez aucune différence. Vos applis tourneront via Xwayland, vos fenêtres s’ouvriront comme avant, et vous continuerez à râler sur le thème Breeze trop bleu.

Wayland – bien qu’incomplet sur certains plans – se veut plus « adaptée » : meilleure sécurité, moins d’héritage technique des années 1980. Dommage que cela fait une bonne dizaine d’années qu’on nous vend cela. Un Duke Nukem Forever si on peut le dire ainsi.

Évidemment, il y aura des grincheux. Ceux qui jurent que « X11 c’était mieux », que « Wayland casse mes raccourcis », ou que « mon logiciel de capture d’écran préféré ne marche plus ». Mais maintenir à la fois le support de X11/X11Libre et Wayland, ça doit coûter pas mal en terme de ressources.

KDE 6.8, c’est un peu comme dire adieu à Windows XP en 2014 : ça fait mal aux nostalgiques, mais c’est nécessaire. Wayland est là, qu’on le veuille ou non. Et si vous n’êtes pas contents… Il vous reste encore Cinnamon, Xfce, ce qui reste de Mate. J’utilise Gnome avec sa session Wayland sur mon ordinateur portable, et pour le moment, ça va… Pour le moment 🙂

Le cycle de 2 ans pour les distributions Linux en fixed release : une évidence qui crève les yeux.

On nous vend depuis des années l’idée que les distributions Linux en fixed release doivent tenir un cycle de publication « raisonnable ». Traduction : pas trop court pour éviter l’usine à gaz, pas trop long pour ne pas finir en fossiles. Et pourtant, certains projets persistent à croire qu’un cycle de 3, 4 ou même 5 ans est viable. Pas vraiment au final.

Le problème des cycles trop longs ? Il y en a trois.

  1. Logiciels obsolètes : attendre 3 ans pour une mise à jour majeure, c’est condamner l’utilisateur non professionnels à traîner des versions dépassées de sa suite bureautique ou de son environnement de bureau. Dans un monde où Firefox (cycle mensuel) ou LibreOffice (cycle semestriel avec mises à jour mineures mensuellement), c’est suicidaire.
  2. Sécurité : maintenir pendant des années des paquets vieillissants, c’est multiplier les patchs et les rétroportages. Autant dire que c’est une sacrée utilisation de ressources pouvant être théoriquement employées ailleurs.
  3. Attractivité : qui veut installer une distribution figée dans le passé ? Les utilisateurs non professionnels finissent par migrer vers des des fixed releases plus dynamiques, voire des rolling release pour les plus courageux.

Deux ans, c’est une limite plutôt pragmatique, pour plusieurs raisons.

  1. Rythme des projets en amont : la majorité des logiciels libres suivent un cycle rapide, d’un mois à six mois en moyenne. Deux ans, c’est déjà généreux.
  2. Charge de maintenance : les équipes de développement ont souvent pris pour habitude de ne conserver que deux versions en même temps. La version actuelle et celle qui l’a précédé. Un exemple ? LibreOffice, avec une version « ancienne » dite stabilisée et une récente qui est plus dynamique. Mais la version ancienne reste utilisable.
  3. Équilibre entre utilisateurs et développeurs : deux ans, c’est assez long pour garantir une certaine stabilité. Tout en restant gérable.

Il y a un seul cas où les deux ans ne sont pas applicables, c’est celui du monde de distributions à destination des entreprises. Comme ce sont des entités qui changent rarement le matériel informatique – du moins tant que celui-ci n’est pas rincé – un cycle long est préférable. Mais ce sont souvent des distributions adossées à de grosses structures comme RHEL qui est maintenue par IBM. Ce qui nécessite de rétroporter des patchs, d’utiliser des paquets universels quand la vieillesse commence à se dévoiler.

Pour conclure ? Si on se place dans le monde de l’utilisateur non professionnel, les deux ans sont la limite acceptable. Ni trop court, ni trop long, ce cycle est donc idéal. Reste le problème de rétroporter les correctifs de sécurité, mais la plupart des fixed release contournent leur fixité en ce qui concerne les navigateurs en utilisant par exemple la version ESR (long terme) de Mozilla Firefox.

C’est sûrement le seul contre-exemple (du moins, c’est celui qui me vient directement à l’esprit) dans la tradition de ne bouger qu’à la marge des fixed releases.

Maltraiter la Void Linux, dernière mode en date dans le petit monde des distributions GNU/Linux ?

Il y a parfois des tendances qui sont étranges. Outre le fait qu’un nombre non négligeable de distributions sont souvent des remastérisations des principales distributions mères (Archlinux, Debian, Fedora, Gentoo, OpenSuSE, Slackware) voire des principales distributions filles (Manjaro, Ubuntu ou une de ses saveurs principalement), il y a d’autres projets, moins nombreux qui utilise la base Void Linux pour exister.

Cette tendance est surtout visible dans la deuxième quinzaine d’octobre 2025. En suivant les propositions et ajout à l’index de Distrowatch, j’ai pu constater la présence de :

Pour les ajouts à l’index. Dans la liste d’attente ?

Ce qui fait 6 ajouts en l’espace d’une poignée de jours, ce qui est non négligeable. Si on en croit l’index de Distrowatch, il n’y a que 3 distributions basées sur la Void Linux, ce qui n’est quasiment rien.

J’ai parlé de la Noid dans une vidéo des pitreries du libre.

Si on sort le thème, le prompt et le dépôt tiers, c’est une base Void qui doit être reproductible en quelques minutes depuis une Void Linux Xfce. Et non, je n’ai pas envie de montrer comment faire. La flemme 😀

Pour conclure ? il faut espérer pour la Void Linux que la tendance va se calmer un peu. Mais de voir qu’une nouvelle base est utilisée avec peu ou pas de modifications majeures, ça fait bizarre.

Fin d’expérience avec la NixOS. Quel bilan ?

Voila, un mois est passé – à quelques heures près ! – depuis le billet où j’annonçais le début de l’expérience. Je m’attendais à une expérience un peu « pépère » et je n’ai pas été déçu.

L’ensemble a été assez conservateur, et mis à part les changements de noyaux ou de Mozilla Firefox, je n’ai pas constaté énormément de différences. Je pensais avoir droit à une migration de LibreOffice 25.2.x vers la 25.8.x. Mais non, cela sera sûrement réservé à la NixOS 25.11, nom de code « Xanthusia ». Dommage. Les vagues de mises à jour arrivent en moyenne toutes les 36 à 48 heures.

Outre le défaut de la place prise qui devient rapidement problématique, comme je l’ai précisé dans mon billet de mi-chemin, j’ai utilisé au moins deux fois par semaine le duo sudo nix-collect-garbage -d && sudo nixos-rebuild switch pour récupérer de la place. Qui se comptait parfois en centaines de Mo… Et j’ai joué le fou furieux : je ne gardais au maximum que 2 générations, celle utilisée par défaut et la génération pile avant.

Autre point que j’ai trouvé laxatif, c’est la difficulté à avoir un changelog apporté par chaque mise à jour du système. Il faut employer une ligne de commande avec une option expérimentale pour avoir les changements entre les diverses générations présentes sur l’installation. C’est nix profile diff-closures --profile /nix/var/nix/profiles/system --extra-experimental-features nix-command. C’est quand même étrange que lister les changements d’une génération à une autre soit considéré comme expérimental ! Bizarre !

Comment conclure ? La distribution a tenu le choc, elle est suffisamment solide. Il est dommage de devoir perdre du temps pour se faire son fichier /etc/nixos/configuration.nix selon ses propres goûts. C’est plutôt chronophage. Même si une fois que c’est fait, on n’a plus besoin d’y toucher – sauf modifications apportées par un montée en version – que très rarement.

NixOS ? Comme je l’ai dit – et ma courte expérience le confirme – c’est une distribution pensée par des geeks pour des geeks. Pas le genre de distributions que je mettrais dans les mains de n’importe qui.

Un trop plein d’environnements de bureau dans le monde du logiciel libre ?

J’ai souvent critiqué la divers…dispersion dans le monde des distributions GNU/Linux qui fait que n’importe qui, partant d’une base précise avec un fond d’écran différent et un navigateur autre que celui du projet d’origine devienne une distribution. C’est à cause de cela qu’il y a plusieurs années j’ai inventé l’acronyme « DGLFI » pour Distribution GNU/Linux Franchement Inutile.

Or, dans les commentaire sur l’article parlant de la version bêta du Cosmic Desktop Environment, certaines personnes m’ont fait remarquer qu’il y avait de plus en plus d’environnement, et que ça devient illisible. Voyons cela. Heureusement, je ne parle des gestionnaires de fenêtres dont un nouveau apparait chaque semaine ou presque !

Si on reste dans les environnements dont le développement est des plus actifs, on a par ordre alphabétique :

  • Cinnamon (qui n’est plus un fork de Gnome 3.x depuis la version 2.0 en 2013)
  • Gnome
  • KDE
  • LXQt
  • Xfce

La plupart ont un cycle de publication régulier, allant de 6 mois (Gnome et KDE principalement) à 2 ans (Xfce). Pas de Deepin ni de Budgie qui semblent ne bien fonctionner qu’avec leurs distributions attitrées. Pourquoi n’ai-je pas listé Mate Desktop ? Pour deux raisons :

  1. La première est que son développement s’est tellement ralenti qu’il y est passé d’une version annuelle à une au bout de deux ans et demi. Cf la page d’accueil du projet.
  2. La deuxième ? Sur son GitHub, sur la quarantaine de composants qui constituent l’environnement, seul trois ou quatre ont une version de développement disponible, du moins au 25 septembre 2025, moment où je rédige cet article.

Quant à l’idée de fusionner les codes de Mate Desktop et Xfce, cela doit tenir plus du cauchemar qu’autre chose. Quant à Cosmic Desktop Environment, il est encore trop jeune pour être listé dans les environnements de bureau majeurs.

Continuer la lecture de « Un trop plein d’environnements de bureau dans le monde du logiciel libre ? »