La distribution AlmaLinux a publié sa version 10.2 Beta nommée "Lavender Lion", et elle fait un truc que la plupart des distros récentes refusent de faire : remettre du support 32-bit dans le système. 

Pas un retour total, on s'entend, mais des packages userspace i686 pour faire tourner du logiciel ancien, des pipelines de CI un peu datées et des conteneurs qui dépendent encore de bibliothèques 32-bit. Pas d'ISO d'install i686, ça reste enterré pour de bon. Mais bon, vos vieux binaires repartent sur un x86_64 propre.

C'est intéressant parce que Red Hat a clairement tranché de l'autre côté avec RHEL. Plus de support 32-bit, plus de x86-64-v2 sur la version 10, c'est marche ou crève. AlmaLinux, qui se positionne comme rebuild compatible RHEL, prend un chemin un peu différent en disant : on garde la compat mais on rajoute des trucs qui rendent la vie plus simple aux entreprises avec du legacy à maintenir. Y'en a beaucoup.

Côté nouveautés plus classiques, vous récupérez Python 3.14, PostgreSQL 18, MariaDB 11.8, Ruby 4.0 et PHP 8.4 dans les packages, plus SDL3, libkrun et le tooling FIDO Device Onboard. La beta intègre aussi déjà le patch pour la vulnérabilité Copy Fail (CVE-2026-31431), ce qui veut dire que les équipes d'AlmaLinux suivent vraiment de près les correctifs amont, sans attendre la stable pour les pousser.

Le truc à retenir, c'est qu'AlmaLinux est en train de devenir le RHEL "raisonnable" pour les boîtes qui ont du parc informatique vieillissant. 

Pendant que Red Hat optimise pour ses futurs gros clients cloud, AlmaLinux ramasse tous les autres : ceux qui ont encore une appli métier en 32-bit, ceux dont les serveurs ne valident pas x86-64-v3, ceux qui veulent juste que ça marche sans réécrire la moitié de leur stack.

Bref, choisir AlmaLinux plutôt que RHEL ressemble de plus en plus à une décision pragmatique.

Source : Phoronix

Jon Seager, VP Engineering chez Canonical, vient de poser sur le Discourse Ubuntu le plan IA de la distrib pour les 12 prochains mois. Et ça va saupoudrer partout, du speech-to-text amélioré aux workflows agentic, en passant par l'analyse automatisée des logs serveur. Le timing est limpide, et à peine Ubuntu 26.04 LTS est sortie que Canonical aligne déjà sa "next big thing".

Concrètement, vous tapez snap install nemotron-3-nano et tadaa, vous récupérez un modèle local pré-optimisé pour votre silicium (genre 2 à 4 Go selon la quantization), avec un endpoint API compatible OpenAI servi sur localhost. C'est ça, leurs fameuses Inference Snaps.

La liste tourne autour de Gemma 4 (Google DeepMind), Qwen-3.6-35B-A3B, Nemotron-3-nano, DeepSeek et Llama, et perso je trouve le choix plutôt cohérent vu qu'il colle aux modèles open weight les plus chauds du moment. Bien sûr, l'inférence est locale par défaut plutôt que cloud, l'idée étant d'éviter d'envoyer vos prompts chez un tiers chaque fois que vous demandez un résumé de log.

Côté technique, tout passe par la sandbox Snap pour gérer les permissions, ce qui change pas mal la donne par rapport à un binaire qui pourrait taper partout sur le disque.

Ubuntu 26.04 LTS embarque déjà la "prompting capability" qui permet d'autoriser ou refuser l'accès aux modèles app par app et les fonctionnalités attendues couvrent les ajustements caméra et micro (réduction de bruit, flou d'arrière-plan), l'accessibilité écran, l'automatisation du troubleshooting, et côté serveur, l'aide à l'interprétation des incidents pour les équipes SRE.

Pour ceux qui bossent sur des fermes de serveurs, à vrai dire c'est ce dernier point qui sera vraiment utile, parce que pour parser des logs à la main quand ça part en cacahuète, ça vaut le coup d'avoir une IA qui dégrossit.

Le hic dans ce thread Discourse, c'est l'absence de killswitch IA global comme le propose Firefox. Plusieurs utilisateurs demandent un opt-in clair plutôt qu'un opt-out diffus, et un alignement explicite avec la définition Open Source AI de l'OSI. La position de Canonical, c'est que désinstaller les Snaps IA = killswitch de fait, vu que toutes les features IA passeront par là. Pas de gros bouton rouge "désactive-moi tout ça" global, donc, mais un contrôle granulaire au niveau Snap, avec Ubuntu 26.10 qui arrive en mode preview "strictly opt-in" et un setup wizard à partir de 27.04 qui demandera à l'install si vous voulez ces features ou pas. Comme les LLMs sont trop gros pour rentrer dans l'ISO, ils sont téléchargés après coup, ce qui rend l'opt-in assez naturel à implémenter techniquement.

La réponse de Seager sur le débat est nette, "some features will use AI, and if you use those features, you'll be using some sort of AI model", mais il tempère quand même avec "not to force AI into every Desktop indiscriminately, but rather to enhance certain features where it makes sense". Bref, comme d'hab, ça en calmera certains, mais vu comment certains ont littéralement fondu un plomb quand Firefox a adopté ses fonctionnalités IA (locales et désactivables, je le rappelle), j'imagine que Ubuntu va se prendre sa petite shitstorm de "j'suis tout rouge et pas content" dans pas longtemps...

Cette ambiguïté fait d'ailleurs déjà grincer des dents sur certaines chaînes YouTube de barbus, où le terme "Microsoft 2.0" ressort déjà dans plusieurs vidéos critiques. Ahaha, c'est toujours le même gag ! Mais Canonical jure ses grands morts que ce sera différent... Tenez la citation officielle "Ubuntu is not becoming an AI product, but it can become stronger with thoughtful AI integration".

Et l'autre point qui va faire grincer des dents, c'est que Canonical confirme aussi accepter dans Ubuntu du code co-écrit avec une IA, en s'alignant sur la politique récente du kernel Linux qui a déjà ouvert la porte à ce type de contributions. À voir comment les puristes vont digérer ça, mais c'est en train de devenir la norme dans l'écosystème open source, alors autant que Canonical le dise franchement plutôt que de le faire en douce.

Maintenant pour les sceptiques qui veulent tester sans s'engager, la bidouille est simple. D'abord, vous laissez les Inference Snaps non installés (ils ne sont pas dans le seed par défaut). Ensuite, vous bloquez les capabilities IA dans snap connections. Et comme ça vous gardez la main sur ce qui tourne en local.

Après si vous voulez expérimenter, l'API OpenAI-compatible permet de faire pointer n'importe quelle app dessus avec deux lignes de config, ce qui est vraiment pratique pour comparer un modèle 3B local face à GPT-4 cloud sur des tâches précises. Sauf si votre machine n'a pas assez de VRAM, et là le modèle 3B va ramer comme un veau et vous reviendrez vite vers le cloud... pas glop.

Il reste quand même la vraie question, qui est celle de la transparence des datasets de training. Là dessus, Canonical n'a pas encore donné de réponse claire, et c'est probablement là que se jouera la confiance long terme.

Promettre l'open weight déjà c'est bien, mais expliquer comment les modèles ont été entraînés ça serait franchement mieux.

Bref, à surveiller dès Ubuntu 26.10 en octobre 2026 pour la preview opt-in, et plus largement à partir de 27.04 quand le setup wizard intégrera la question. Pour l'instant, la roadmap c'est surtout beaucoup d'intentions louables, mais bon, on en reparlera dans six mois.

Source : Phoronix

La première release candidate de Linux 7.1 est sortie, avec un tout nouveau pilote NTFS écrit pour le noyau, qui annonce des écritures multi-thread deux fois plus rapides et un montage de disque jusqu'à quatre fois plus véloce que l'ancien.

La sortie stable est prévue pour la mi-juin selon le calendrier de Linus Torvalds. Au total, la fenêtre de merge a vu passer plus de 13 000 commits, ce qui en fait une release plutôt costaude.

Le pilote NTFS dans Linux a une longue histoire compliquée. Pendant des années, le kernel a embarqué deux pilotes : ntfs en lecture seule maintenu par Anton Altaparmakov, et ntfs3 contribué par Paragon Software puis pratiquement abandonné depuis 2024.

La version qui débarque dans 7.1 est une réécriture complète, optimisée pour les usages dual-boot et les disques externes formatés en NTFS, qui restent monnaie courante quand on échange des fichiers avec Windows.

L'autre nouveauté, c'est l'activation par défaut de FRED, le mécanisme Flexible Return and Event Delivery développé par Intel pour remplacer le vieux système d'IDT et d'interruptions hérité du x86. Cette activation doit simplifier la gestion des exceptions et des appels système, avec moins de cycles perdus à chaque commutation de contexte. Sur les puces Intel récentes qui le supportent, c'est un petit gain de performance qu'on récupère sans rien faire.

Côté ménage, on vous en a déjà parlé , Linux 7.1 retire le support du i486, processeur sorti en 1989, et abandonne plusieurs vieux pilotes réseau et SoC qui n'avaient plus d'utilisateurs réels. Personne ne regrettera. Le kernel garde son équilibre entre support legacy et code moderne, en évacuant les morceaux qui coûtent en maintenance pour zéro retour visible.

Pour les utilisateurs de tous les jours, le gros impact ça sera cette affaire d'NTFS. Avoir un pilote rapide, fiable et maintenu directement dans le kernel mainline change la vie de tous ceux qui jonglent entre Linux et Windows sur la même machine. Plus besoin de dépendre de ntfs-3g en userspace ou de monter en lecture seule pour éviter les corruptions, ce qui était le quotidien de pas mal de gens depuis bien trop longtemps.

C'est aussi un bon indicateur pour l'écosystème : du code propre, écrit en interne, sans dépendre d'un éditeur tiers qui peut se désengager du jour au lendemain.

Linux 7.1 fait donc un gros ménage et règle un problème bien relou. Pour ceux qui galèrent avec leurs disques NTFS depuis bien longtemps, c'est une libération.

Source : Phoronix

Si vous tournez sur Ubuntu, Debian, Fedora ou RockyLinux, sachez que votre démon PackageKit a passé presque 12 ans à laisser une porte ouverte vers votre compte root. La Deutsche Telekom Red Team vient en effet de publier Pack2theRoot (CVE-2026-41651), une faille notée 8.8/10 qui permet à n'importe quel utilisateur local de devenir root sans mot de passe.

Pour corriger le soucis, mettez à jour vers PackageKit 1.3.5 ou le backport de votre distro. Pour vérifier votre version, c'est dpkg -l | grep -i packagekit sous Debian/Ubuntu, ou rpm -qa | grep -i packagekit côté Fedora et Rocky. Si vous êtes en 1.3.4 ou en dessous, considérez la machine comme exploitable.

Le bug est une race condition classique. En fait PackageKit vérifie vos droits, valide la transaction, mais utilise des données qui ont eu le temps de changer entre les deux. Un appel pkcon install bien chronométré et n'importe quel paquet s'installe en root, sans prompt Polkit . La liste des distros confirmées vulnérables couvre Ubuntu 18.04 à 26.04, Debian Trixie, RockyLinux 10.1, Fedora 43 et tout RHEL avec Cockpit.

Le détail marrant encore une fois c'est la méthode de découverte. La Telekom Red Team a tout simplement dirigé Claude Opus d' Anthropic vers la base de code de PackageKit, et c'est cette session d'audit assistée par IA qui a sorti la vuln. Les LLM commencent donc à trouver des bugs subtils que les audits humains ont laissé passer pendant plus d'une décennie. Tant mieux, ça va faire grimper le niveau de sécurité de nombreux projets !

Cette faille ancienne me rappelle BitPixie et son contournement de BitLocker resté en sommeil durant 20 ans. Le pattern est toujours le même, à savoir un composant système installé partout, qui cache un bug tout bête depuis siiii longtemps que plus personne ne l'audite avec un œil neuf.

Bref, merci Claude ^^

Source

Le noyau Linux est en train de retirer le support matériel des processeurs Baikal, fabriqués par Baikal Electronics en Russie. Pas juste les mainteneurs cette fois, le code lui-même. Les drivers et le support de la plateforme MIPS Baikal-T1 sont en cours de suppression dans les sources du noyau, après des années de tensions autour des sanctions internationales.

Pour remettre en contexte, le support du Baikal-T1 (un CPU MIPS double coeur P5600 cadencé à 1,2 GHz) et du SoC BE-T1000 avait été intégré au noyau Linux à partir de la branche 5.8. Baikal Electronics travaille sur des processeurs domestiques russes, en MIPS et en ARM, pensés pour réduire la dépendance de la Russie aux puces étrangères.

Le problème, c'est que l'entreprise est directement sanctionnée par les États-Unis, l'Union européenne et d'autres pays, avec le soupçon que ses puces puissent finir dans du matériel militaire.

En octobre 2024, une première étape avait été franchie. Onze mainteneurs russes avaient été retirés du fichier MAINTAINERS du noyau, dont Serge Semin, responsable du driver Baikal-T1 PVT et de la plateforme MIPS Baikal-T1.

Linus Torvalds avait tranché clairement : "C'est parfaitement clair pourquoi le changement a été fait, il ne sera pas annulé." Greg Kroah-Hartman, de son côté, avait invoqué des "exigences de conformité" liées aux sanctions américaines OFAC.

Mais à l'époque, le code restait. Les mainteneurs partaient, les drivers non. Du coup, un développeur de chez Baikal pouvait toujours soumettre un patch, même si trouver quelqu'un pour le merger devenait compliqué.

Jakub Kicinski, mainteneur du sous-système réseau du noyau, avait d'ailleurs refusé publiquement d'accepter des patches venant d'employés de Baikal Electronics, en invoquant un malaise personnel face à la situation.

L'étape en cours va plus loin. C'est le support matériel lui-même qui est en train d'être retiré. Concrètement, ça veut dire que les futures versions du noyau ne compileront plus pour cette plateforme, et que les distributions qui montent en version perdront le support natif de ces puces.

Pour les quelques machines qui tournent sur du Baikal-T1 en dehors de Russie (il y en a très peu), ça implique de rester sur un noyau ancien ou de maintenir un fork.

Côté Russie, Baikal Electronics maintient son propre fork du noyau Linux sur GitHub. Le projet n'est pas mort, il est juste découplé de l'upstream. Ça pose quand même une vraie question sur la viabilité long terme d'un fork désormais très isolé, sans les contributions de la communauté internationale.

Bref, Linux tranche dans le dur cette fois. Plus de mainteneurs, et bientôt plus de code non plus.

Source : Phoronix

Linus Torvalds a officialisé Linux 7.0 le 12 avril, et le passage à la version 7 a d'ailleurs été expliquée. Torvalds a dit dans son mail de release qu'il préférait simplement incrémenter le numéro majeur quand les mineures dépassaient la dizaine, histoire de ne pas se retrouver avec un Linux 6.23. Pas de révolution philosophique, juste du bon sens de mainteneur donc.

Derrière cette numérotation, le noyau embarque quand même un paquet de nouveautés qui vont directement impacter les utilisateurs AMD, Intel et ARM64, sans parler d'une petite révolution côté système de fichiers XFS.

La grosse annonce, c'est surtout le nouveau daemon xfs_healer, géré par systemd, qui surveille en temps réel les erreurs de métadonnées et les I/O fautifs. Quand il détecte un problème, il déclenche automatiquement la réparation pendant que la partition reste montée et utilisée, ce qui évite de démonter, de booter sur un live USB ou de croiser les doigts pendant un xfs_repair manuel.

Pour un serveur en prod, c'est énorme. XFS rattrape (et dépasse) ce que Btrfs et ZFS proposaient depuis des années sur ce terrain.

Côté Intel, les TSX (Transactional Synchronization Extensions) sont activées par défaut. Sur un CPU 10e génération ou plus récent, ça donne un léger boost sur les charges multithread. Le support de Nova Lake progresse aussi, et le noyau intègre les premiers bouts de Crescent Island, l'accélérateur IA maison d'Intel qui vise les datacenters.

AMD n'est pas oublié, avec de nouveaux blocs IP graphiques activés pour les futures Radeon. Côté ARM64, le kernel gère désormais les chargements et stockages atomiques de 64 octets, un ajout bas niveau qui profitera aux workloads concurrents. Et pour les amateurs de cartes ARM, le décodage vidéo matériel arrive sur toute une série de single-board computers Rockchip.

Ubuntu 26.04 LTS tournera sur Linux 7.0, donc tous les réglages de performance et de stabilité apportés par ce noyau seront directement exploités dans la prochaine LTS. Du coup, choisir Ubuntu cette année a du sens si vous avez du matos récent.

Dans son message de release, Linus évoque aussi la place grandissante de l'IA dans l'écriture de patches noyau. Il ne tranche pas, il observe. On sent qu'il y réfléchit sans vouloir se mouiller pour l'instant.

Bref, pas de révolution, mais le XFS auto-réparant justifie l'upgrade à lui seul pour qui tient vraiment à ses données.

Source : Techspot

Redox OS vient de publier son dernier rapport d'avancement et il y a du nouveau. En plus des progrès sur les pilotes graphiques et le bureau COSMIC, le projet open source a adopté une politique stricte : toute contribution générée par une intelligence artificielle sera refusée et son auteur banni. Carrément.

Du code IA ? Dehors.

Redox OS ne veut pas de code écrit par ChatGPT, Copilot ou tout autre modèle de langage. La règle est inscrite dans les directives de contribution du projet : toute soumission identifiée comme générée par un LLM (issues, merge requests, descriptions) sera immédiatement fermée. Et quiconque tente de contourner la règle se fait bannir du projet. Le tout est présenté comme non négociable.

Redox OS rejoint d'autres projets open source qui ont pris la même direction ces derniers mois, comme Fedora, Gentoo, le projet Rust lui-même ou LLVM, qui ont tous eu à gérer des vagues de contributions de mauvaise qualité générées par IA.

COSMIC, GPU et nouveau scheduler

En parallèle, le mois de mars a été productif côté technique. La démo libcosmic tourne désormais dans le compositeur COSMIC sur Redox, ce qui veut dire qu'on se rapproche d'un vrai bureau utilisable. Les pilotes graphiques ont aussi avancé : support du mapping mémoire GPU sur le pilote Intel, mise en place de shadow buffers pour améliorer les performances, et du travail sur l'API DRM.

Le noyau a aussi reçu un nouveau planificateur de tâches (Deficit Weighted Round Robin) et une meilleure détection des deadlocks. Côté paquets, CPython, PHP, Nano et Vim ont été mis à jour avec le support Unicode via ncursesw.

Un OS ecrit en Rust, pour quoi faire ?

Pour ceux qui ne connaissent pas, Redox OS est un système d'exploitation open source entièrement écrit en Rust, avec une architecture microkernel. Le projet existe depuis 2015 et cherche à proposer une alternative à Linux et BSD, avec la sécurité mémoire de Rust comme argument principal.

Il est porté par Jeremy Soller, qui travaille aussi chez System76 sur Pop!_OS. Redox n'est pas encore prêt pour un usage quotidien, mais chaque mois le rapproche un peu plus d'un système fonctionnel, et l'arrivée du bureau COSMIC est un gros morceau.

Interdire le code IA dans un projet open source en 2026, c'est quand même une prise de position forte. On peut comprendre la démarche : quand on construit un noyau de système d'exploitation, la qualité du code compte, et les contributions générées par IA ont tendance à créer plus de travail qu'elles n'en économisent pour les mainteneurs.

Mais bon, la politique reconnaît elle-même qu'il est impossible de détecter du code IA non étiqueté, ce qui pose la question de l'efficacité réelle de la mesure. Côté technique, voir COSMIC tourner sur Redox est une bonne nouvelle pour tous ceux qui suivent le projet de près. Après dix ans de développement, l'OS en Rust commence à ressembler à quelque chose.

Source : Phoronix

GNOME trop rigide, KDE Plasma trop usine à gaz, Xfce trop vintage... J'sais pas si vous êtes d'accord avec ça, mais c'est l'avis de ce développeur solo ultra acharné qui a décidé de tout refaire from scratch. Ça lui a pris 9 ans de boulot à coder du C++ sur le framework Qt, et à créer 48 composants modulaires pour fourer tout ça dans un environnement de bureau Linux, entièrement indépendant qui ne dérive d'aucun projet existant, qu'il a appelé Orbitiny Desktop !

Le truc chouette avec cet environnement de bureau, c'est sa modularité car chaque composant tourne dans son propre processus, ce qui veut dire que si le gestionnaire de fichiers plante, votre panneau et vos icônes de bureau restent en place. On est donc trèèèès loin du crash GNOME Shell qui vous renvoie sur l'écran de connexion en plein milieu d'un truc important !

Et le truc qui va plaire aux bidouilleurs, c'est que le bazar est 100% portable. Vous décompressez l'archive tar.gz de 185 Mo sur une clé USB, vous lancez le script start-orbitiny et hop, vous avez votre bureau perso sur n'importe quelle machine Linux. Tous les réglages sont sauvegardés dans le dossier d'extraction... du coup vous pouvez trimballer votre config partout avec vous. Et si vous préférez une installation classique, y'a aussi un script graphique install-orbitiny à lancer avec sudo.

Côté features, c'est plutôt fourni ! Orbitiny intègre son propre gestionnaire de fichiers (Qutiny), un presse-papier système, un gestionnaire de périphériques USB et un tableau de bord avec barre de recherche.

Le gestionnaire de fichiers gère la recherche par nom et contenu, la vue en double panneau et des trucs assez originaux genre le "File Join" qui permet de fusionner des fichiers texte par simple drag and drop, ou le "Image Join" qui colle des images entre elles verticalement. Y'a aussi un système de gestes de souris configurables sur le bureau (jusqu'à 12 tracés par bouton gauche ou droit), des bureaux indépendants par moniteur ET par bureau virtuel (chaque écran physique a son propre fond d'écran et ses propres raccourcis), et un panneau avec 18 applets qu'on repositionne par simple glisser-déposer, sans passer par un mode édition.

Le petit bonus sympa, c'est le support WINE et DOSBOX intégré. Vous balancez un .exe Windows sur le bureau ou dans le gestionnaire de fichiers et ça lance direct via WINE. Pareil pour les vieux programmes DOS via DOSBOX. Pas besoin de bidouiller des fichiers .desktop custom à la main (bon ok, faut quand même que WINE soit installé sur votre distro). Après ça ne marche pas forcément avec tous les programmes Windows non plus... va savoir pourquoi certains .exe passent et d'autres plantent. Les mystères de la vie !

Ah et j'allais oublier un truc : Orbitiny peut aussi tourner en mode overlay, c'est-à-dire par-dessus un autre environnement de bureau. Vous gardez votre GNOME ou votre KDE en dessous et vous superposez Orbitiny par-dessus pour profiter de ses fonctionnalités sans tout changer. C'est pratique pour tester sans engagement !

Le projet est sous licence GPLv2, disponible sur SourceForge et tourne sur toute distro Linux basée sur X11. Attention par contre, pas de support Wayland pour l'instant, c'est du X11 only, ce qui risque de poser souci à terme vu que Wayland remplace progressivement X11 sur Ubuntu, Fedora et compagnie. Oubliez pas non plus que c'est un projet d'un seul développeur, donc les mises à jour arrivent quand elles arrivent. Après si vous cherchez d'autres moyens de personnaliser votre bureau Linux , y'a de quoi faire.

Bref, 9 ans de boulot solo pour un environnement de bureau qui tient plutôt bien la route, faut quand même saluer l'effort !! Et un grand merci à François pour le partage !

Canonical vient de publier la bêta d'Ubuntu 26.04 LTS, nom de code Resolute Raccoon. Au menu de cette future version longue durée : le noyau Linux 7.0, GNOME 50, l'abandon pur et simple de X11 au profit de Wayland, et un bon lot de nouveautés côté sécurité avec chiffrement TPM, cryptographie post-quantique et même sudo réécrit en Rust. La version finale est attendue le 23 avril.

Ce qui change

Ubuntu 26.04 LTS embarque le noyau Linux 7.0, qui apporte la prise en charge des processeurs Intel Nova Lake, AMD Zen 6, et les premières bases pour les puces Qualcomm Snapdragon X2. Le pilote graphique Mesa passe en version 26.0.2, et les pilotes NVIDIA grimpent à la version 590.

Côté langages, on retrouve Python 3.14, GCC 15.2 et OpenJDK 25 par défaut. Et gros changement pour les développeurs : les dépôts AMD ROCm et NVIDIA CUDA sont désormais intégrés directement dans les sources officielles d'Ubuntu. Plus besoin d'aller les chercher à la main, ce qui devrait simplifier pas mal de configurations pour ceux qui bossent avec du GPU.

Wayland seul aux commandes

C'est la grosse rupture de cette version. Ubuntu 26.04 abandonne complètement la session X11 native. GNOME 50 ne la prend plus en charge, et Canonical a suivi le mouvement. Si vous avez des applications qui tournent encore sous X11, elles passeront par la couche de compatibilité XWayland, qui reste présente.

Mais le message est clair : X11, c'est terminé. GNOME 50 en profite pour ajouter le taux de rafraîchissement variable, la sauvegarde et restauration de session après un redémarrage, et un meilleur scaling des applications X11 héritées. Côté visuel, le thème Yaru a été retravaillé avec des icônes de dossiers colorées, un dock complètement opaque, une nouvelle animation de démarrage et un papier peint inédit.

Le lecteur vidéo Totem cède sa place à Showtime, le moniteur système est remplacé par Resources, et le visionneur PDF Evince laisse la main à Papers.

La sécurité passe un cap

Le chiffrement complet du disque via TPM sort enfin du statut expérimental. C'est désormais une fonctionnalité pleinement supportée, ce qui devrait rassurer ceux qui hésitaient à l'activer. La cryptographie post-quantique est activée par défaut sur SSH, avec l'algorithme hybride mlkem768x25519-sha256.

Et détail qui va plaire aux puristes : la commande sudo classique est remplacée par sudo-rs, une réécriture en Rust qui renforce la sécurité mémoire. Les paquets firmware, jusqu'à présent livrés en un seul gros bloc, sont maintenant découpés en 17 paquets spécifiques par constructeur, ce qui réduit la bande passante nécessaire pour les mises à jour.

Visiblement, Canonical a décidé de tout faire bouger d'un coup sur cette LTS. La fin de X11, le passage à GNOME 50, sudo en Rust, la crypto post-quantique par défaut, ça fait un gros paquet de changements pour une version censée rester stable pendant cinq ans.

On apprécie l'intégration directe de CUDA et ROCm dans les dépôts, parce que jusqu'à présent c'était une galère à configurer pour qui voulait faire tourner du machine learning sur Ubuntu. Le passage forcé à Wayland va probablement faire grincer des dents certains utilisateurs qui dépendent encore d'outils graphiques un peu anciens, mais bon, il fallait bien que ça arrive. La version finale est prévue le 23 avril, et le support court jusqu'en 2031, ou 2036 avec Ubuntu Pro. À voir si la bêta tient ses promesses d'ici là.

Source : Phoronix

Dirt 3 qui passe de 110 à 860 FPS sous nunux, non, j'ai pas fumé la moquette ! En fait c'est surtout grâce au fameux module de synchronisation kernel NTSYNC promis avec Wine 11 qui est enfin dispo dans certaines distros. Et la bonne nouvelle c'est que les premiers benchmarks développeurs viennent de tomber, donc on va regarder ça ensemble !

Concrètement, Fedora 42, Ubuntu 25.04 et SteamOS 3.7.20 beta embarquent maintenant le module par défaut avec le kernel 6.14. Du coup Resident Evil 2 bondit de 26 à 77 FPS, Call of Juarez grimpe de 99 à 224 FPS, et Tiny Tina's Wonderlands passe de 130 à 360. Et Call of Duty Black Ops est maintenant devenu... jouable ! Woohoo !

Alors attention, ces benchmarks comparent Wine vanilla (sans aucune optimisation) avec Wine + le module. Cela veut dire que si vous utilisiez déjà fsync via Proton ou Lutris, les gains seront moins spectaculaires. Après les jeux qui en profitent le plus sont ceux avec de grosses charges multi-thread où la synchronisation était vraiment le problèmo noméro uno.

Pour capter pourquoi cette news est un gros morceau, faut regarder un peu sous le capot. Au temps jadis, chaque fois qu'un jeu Windows devait coordonner ses threads (genre, attendre qu'une texture finisse de charger), Wine faisait des allers-retours avec wineserver... des milliers de fois par seconde. Du coup, on se tapait des micro-sacades et une cadence d'images pourrie.

Y'a eu des tentatives pour arranger ça. D'abord esync, puis fsync... ça améliorait les choses mais c'était du bricolage. Ça nécessitait des patchs kernel non-officiels que personne ne maintenait vraiment, et certains jeux gourmands faisaient carrément tout planter.

Mais tout cela c'est de l'histoire ancienne puisque NTSYNC, semble être enfin la bonne approche. Elizabeth Figura (CodeWeavers), la même dev qui avait pondu les solutions précédentes, a créé, cette fois, un vrai module intégré directement dans le noyau Linux. Comme ça, plus de bidouilles à la con et surtout plus d'approximations. Le noyau gère enfin la synchronisation lui-même, nativement, comme il aurait toujours dû le faire.

La stonksitude du barbu gamer est à son maaaax

Après des années de boulot et une présentation à la Linux Plumbers Conference 2023, le module a fini par être mergé dans le kernel mainline il y a peu. Ça marche donc "out of the box" et ça c'est plutôt chouette !

Et pour les possesseurs de Steam Deck, quand Valve rebasera Proton officiel sur Wine 11, tout le monde aura ça gratos !! En attendant, si vous êtes impatient, sachez que Proton-GE le supporte déjà ! Entre ça et le fait que 90% des jeux Windows tournent maintenant sous Linux , y'a clairement plus d'excuses pour rester sous Windows si c'est le gaming qui vous retenait, mes cocos !

Bref, c'est carrément la plus grosse avancée gaming Linux depuis Proton. Pas mal pour un module kernel bien velu quand même !

Source