Si vous ne connaissez pas Linux, il faut savoir que sur ce système d'exploitation, le clic milieu colle la sélection. Moi, c'est un truc que j'aime bien, mais c'est surtout un héritage de X11 qui se marche complètement dessus avec l'autoscroll . Du coup Firefox désactive le sien par défaut sur Linux, et Chromium ne l'active nativement que sous Windows. Mais c'était sans compter sur Grant Hendricks qui a décidé de faire autrement avec midscroll .

Midscroll ne s'accroche à aucun toolkit, et se branche sur l'entrée du noyau. Ensuite, il capte chaque souris en evdev , la re-émet dans un clone uinput , et glisse ses événements de molette au passage. Rien au-dessus n'a donc besoin de coopérer, donc Wayland et X11 s'en fichent, et vos applis Qt, GTK ou Electron ne voient qu'une molette ordinaire.

Les gens sous Windows qui utilisent l'autoscroll savent que la vitesse dépend de l'écart. Un centimètre sous le point d'appui et la page descend au ralenti, la moitié de l'écran ou plus bas et elle défile à toute berzingue. Et tant que la molette reste enfoncée, ça scroll sans s'arrêter. C'est super pratique quand on est face à des pages web ultra longues.

Alors pour Midscroll, la courbe d'accélération qu'a mise au point Grant, n'a pas été bricolée au feeling. En fait, c'est la même courbe que celle de Chromium, reprise telle quelle : 0,000008 × distance^2,2 en pixels par milliseconde, avec une zone morte de 15 px histoire de ne pas déclencher sur un clic simple...

Et comme le middle-drag, ça sert déjà dans un logiciel de CAO ou dans Minecraft, il y a une liste d'exclusion pour FreeCAD, OrcaSlicer et Minecraft dedans. Comme ça, tant que ces fenêtres sont au premier plan, midscroll se retire en silence.

Et si tenir le bouton vous gonfle parce que vous êtes trop faible, le mode toggle inverse la logique : le pointeur circule librement une fois le défilement lancé d'un clic, et le premier clic venu remet tout à l'arrêt. C'est le fonctionnement de l'explorateur Windows ET de Firefox, et c'est une fonctionnalité qui a été beaucoup réclamée, même si on perd la faculté de coller du texte qui a été surligné.

Bien sûr, toutes les valeurs sont paramétrables. On peut régler la vitesse à laquelle ça part, la cadence des événements et dans quel sens ça défile.

Côté installation, des paquets pour Arch, Debian/Ubuntu et Fedora sont dispo, plus un install.sh pour le reste. Le flatpak, lui, est hors jeu car son bac à sable ferme totalement l'accès à uinput.

Le projet est hyper jeune, donc traitez-le comme tel et n'hésitez pas à contribuer pour soutenir le dev. Dans le registre confort Windows sous Linux, j'avais parlé de Wubuntu qui va beaucoup plus loin dans le mimétisme, et côté Wayland je vous avais montré niri et son défilement infini de fenêtres.

À tester et si ça vous gonfle, un sudo systemctl stop midscroll et on n'en parle plus.

Ubuntu 26.04 LTS est disponible depuis avril, et si vous l'avez installée, vous avez peut-être remarqué un truc : **Plus aucune notification de mise à jour !**L'icône qui vous prévenait dans la barre du haut a disparu, les pop-ups aussi. Rassurez-vous, ce n'est pas un bug mais un choix de design assumé par Canonical.

La clé show-updates-status-icon du paquet update-notifier est passée à false par défaut, du coup, votre système ne vous signale plus rien quand des paquets attendent d'être installés. Pour le savoir, il faut ouvrir un terminal ou lancer l'App Center à la main.

Je précise quand même un truc avant que tout le monde s'énerve, parce que beaucoup de Linuxiens n'aiment pas le changement ^^. Sachez que cette icône de notification est toute récente et n'existait pas sur Ubuntu 24.04, elle est arrivée avec la 25.10 pour remplacer le vieux pop-up intrusif du Software Updater. Donc cette 26.04 ne supprime pas une fonction historique, mais achève juste un machin qui avait à peine un an.

Donc avant de changer de distro en panique, non, votre sécurité n'est pas en jeu. Ubuntu garde unattended-upgrades, le service qui installe les correctifs de sécurité tout seul en arrière-plan, actif par défaut. Les failles critiques continuent donc d'être colmatées, c'est juste que vous n'êtes plus au courant quand ça se produit.

Sauf qu'il y a un petit bémol bien réel : LTS. Une version LTS, c'est celle qu'on garde 5 ans, souvent installée sur le PC de quelqu'un qui n'ouvrira jamais un terminal (coucou l'ordi de vos parents). Et unattended-upgrades ne gère par défaut que la sécurité, et pas les mises à jour applicatives. Vos applis en Snap comme Firefox continuent donc bien de se mettre à jour toutes seules dans leur coin, mais vos paquets .deb non critiques, eux, vont s'empiler sans que personne ne vous prévienne. C'est la seule vraie critique à faire à Canonical sur ce coup. Après c'est un éditeur coutumier des choix qui divisent , donc on commence à avoir l'habitude, mais bon voilà, il faudra penser à faire les mises à jour non critiques.

Le plus gênant, c'est qu'il n'y a pas non plus de bouton dans les réglages pour réactiver cette icône. La seule voie passe donc par gsettings, et la valeur par défaut, elle, reste sur off.

Donc voici comment faire si l'idée de piloter vos mises à jour à l'aveugle vous refroidit. Une ligne de commande et l'icône revient :

gsettings set com.ubuntu.update-notifier show-updates-status-icon true

Voilà, voilà, vous retrouvez vos notifications comme avant sans avoir besoin de réinstaller quoi que ce soit.

Bref, rien de dramatique, mais un défaut trèèèès discutable notamment sur les versions LTS qu'on garde des années.

Source

Balaji Bikshandi avait un rêve ! Il voulait booter sa machine directement sur un LLM sans avoir à passer par le moindre environnement de bureau ! Et il y est parvenu avec son outil BMASS , qui s'installe sur une clé USB de 8 Go, et qui embarque Alpine Linux, llama.cpp et un modèle Qwen3 0.6B évidemment quantisé.

Vous allumez l'ordi portable, Alpine démarre depuis la clé et vous tombez sur un prompt BMASS>. Et voilà à partir de là, vous pouvez causer à votre ordinateur en langage naturel. Ensuite, quand vous demandez à BMASS de faire des trucs, celui-ci injecte la commande qui va bien dans une balise et le runtime l'exécute pour de vrai sous un compte Linux non privilégié. Et ensuite, le LLM récupère la sortie brute, pour répondre, à partir de cette "preuve".

Operator: Which operating system is this?
Assistant: <shell>cat /etc/os-release</shell>

Tout le code de BMASS tient en 399 lignes de Python, et nécessite de faire tourner un llama-server en background sur le port 8080 avec 2048 tokens de contexte et 2 threads. Et ensuite lui fait le pont entre le modèle et le shell. Y'a rien de sorcier donc mais comme ça tourne sur du CPU, que c'est hors-ligne, et que ça peut se mettre sur des vieilles machines, c'est plutôt cool...

Voilà je vous laisse avec la vidéo que Balaji a filmée, ça montre le démarrage complet de son IA bootable :

Lire la vidéo YouTube ne se charge qu'après votre clic Voir cette vidéo sur YouTube

Ah et petite subtilité qui va vous plaire, le code de BMASS contient une regex baptisée FALSE_EXECUTION_CLAIM dont le boulot est de détecter quand le modèle prétend avoir exécuté une commande alors qu'il n'a rien lancé du tout. Le runtime lui renvoie alors une correction pour lui dire qu'aucune commande n'a été exécutée lors de ce tour. Faut dire que la 0.6B de Qwen hallucine tellement parfois, qu'il lui fallait obligatoirement un garde-fou.

Donc, voilà, côté sécu c'est super léger... y'a juste une regex qui bloque les sudo, doas, pkexec et autres su, mais c'est tout. Pas de conteneur, encore moins de namespace et surtout pas de liste blanche, donc si vous vous lancez, ce sera à déployer uniquement pour rigoler sur une vieille machine sans importance, parce que si demain, le modèle décide de lancer un rm -rf, faudra pas venir chialer ^^.

Petit service au passage si vous voulez tester, la doc d'installation vous fait copier le prompt système dans /opt/bmass/config/system-prompt.txt, sauf que le launcher le cherche dans /opt/bmass/system-prompt.txt.

Dans le genre modèle local qui tient dans presque rien, j'en ai parlé avec Llamafile qui fait tourner un LLM depuis un fichier unique. Et si les bidouilles minimalistes vous amusent, il y a aussi ce mini-PC Linux piloté entièrement en morse .

Perso, je doute que ça serve à grand-chose. Mais le concept est marrant !

On ne présente plus Linus Torvalds, le père du noyau Linux, aussi connu pour son génie technique que pour un franc-parler. Cette fois, c'est le débat sur l'usage de l'IA dans le développement du noyau qui l'a fait sortir du bois.

Sur la fameuse mailing list où se décide l'avenir de Linux, il a coupé court à la polémique en posant noir sur blanc que son projet n'était pas, et ne serait jamais, un truc anti-IA.

Sa sortie a de quoi rester dans les annales, puisqu'à ceux que ça agace, il conseille de faire ce que l'open source autorise justement, forker le noyau, autrement dit en copier tout le code pour bâtir leur propre version dans leur coin, ou alors juste s'en aller.

Ce qui est étonnant, c'est le revirement, parce qu'il y a deux ans à peine, ce même Torvalds envoyait balader l'IA en la réduisant à du 90 % de hype. Aujourd'hui, il la décrit comme un outil clairement utile dont plus grand monde ne discute vraiment l'intérêt.

Ça ne l'empêche pas de reconnaître les ratés, puisqu'il admet que ces outils peuvent charger un peu plus la barque des mainteneurs et faire remonter des bugs bien embarrassants, mais pour lui la parade tient en deux mots, de meilleurs outils, surtout pas la fuite.

Le passage le plus tranchant arrive quand il refuse de transformer le noyau en champ de bataille idéologique, en rappelant que ça n'a jamais été un projet de justiciers sociaux et que ça ne le sera jamais.

Dans sa communauté, martèle-t-il, on fait de l'open source parce que ça donne de meilleures technos, pas pour des motifs quasi religieux, et les choix se tranchent au mérite technique, jamais par peur d'une nouveauté.

Il n'est d'ailleurs pas seul sur cette ligne, puisque Greg Kroah-Hartman, l'un des mainteneurs les plus haut placés du noyau juste derrière lui, a confirmé de son côté que les rapports de bugs pondus par des IA étaient devenus franchement précieux.

Voir le créateur de Linux balancer un forkez ou barrez-vous à la figure des anti-IA, c'est du Torvalds pur jus, brutal mais au moins parfaitement limpide.

Source : ARS Technica

Amis linuxiens, je viens vous quérir d'une charmante nouvelle qui va faire frisoter votre barbe. Anthropic vient de sortir son application Claude Desktop pour Linux, et cette fois c'est une beta officielle, qui plus est, installable directement depuis un dépôt apt maison. Vous y retrouvez donc les mêmes onglets Chat, Cowork et Code que sur macOS et Windows : sessions parallèles , revue visuelle des diffs, terminal et éditeur intégrés, et preview de l'app en direct.

C'est le même Claude Code que d'habitude, mais dans une vraie fenêtre de bureau au lieu de votre terminal.

Pour l'installer, il vous faudra Ubuntu 22.04 ou plus récent, ou Debian 12 ou plus, en x86_64 ou arm64. Vous ajoutez la clé de signature et le dépôt d'Anthropic, et vous laissez apt bosser :

sudo curl -fsSLo /usr/share/keyrings/claude-desktop-archive-keyring.asc https://downloads.claude.ai/claude-desktop/key.asc
echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/claude-desktop-archive-keyring.asc] https://downloads.claude.ai/claude-desktop/apt/stable stable main" | sudo tee /etc/apt/sources.list.d/claude-desktop.list
sudo apt update && sudo apt install claude-desktop

Et voilà !

L'intérêt de passer par le dépôt plutôt que par un fichier, c'est que les mises à jour arrivent avec vos apt upgrade habituels, sans rien re-télécharger à la main.

Y'a bien un .deb à récupérer sur claude.com/download si vous ne pouvez pas utiliser le dépôt, mais celui-là ne se mettra jamais à jour tout seul.

Alors cette news pourrait vous étonner mais jusqu'ici, pour avoir Claude Desktop sur Linux, fallait passer par des projets communautaires pas toujours très bien maintenus. Le plus costaud et le plus connu, c'était aaddrick/claude-desktop-debian qui pourtant n'était pas magique puisqu'il téléchargeait l'installeur Windows, en extrayait l'app Electron (le fameux app.asar), virait les modules natifs Windows-only pour les remplacer par des stubs Linux, recompilait node-pty, patchait les verrous de plateforme et repackageait tout ça en .deb.

Vous faisiez donc tourner le JavaScript prévu pour Windows, avec une bonne dose de bricolage et bizarrement ça marchait bien. Mais bon ça restait un repack par-dessus un binaire qui n'était pas conçu pour le manchot...

Toutefois, une beta restant une beta, le Computer Use (le contrôle de votre écran et de vos applis) n'est pas dispo ni la dictée vocale. Faudra passer par le CLI pour ça.

Et surtout, Anthropic ne couvre pour le moment que les distributions basées sur Debian. Pas de Fedora, RHEL, Arch ou Nix, alors que le projet communautaire balançait des .rpm, des AppImage, un paquet AUR et un flake Nix. Snif...

Donc oui, l'app officielle débarque, mais elle boite un peu. Maintenant, j'sais pas vous mais je préfère quand même largement le CLI Claude Code à cette app et elle a le mérite de très bien fonctionner sur bien plus de distributions.

En attendant, si vous êtes sur Debian ou Ubuntu, l'install prend deux minutes et la doc complète est par ici .

PS : Et au moment où je finalise cet article, je vois qu' Anthropic a sorti Claude Science qui promet d'accompagner la recherche scientifique... Je vous laisse aller voir ça, moi je crois que j'ai assez parlé d'eux pour auj. ^^

Petite victoire pour le logiciel libre. Avec la prochaine version du noyau Linux, la 7.2, le pilote Nouveau va enfin prendre en charge le GA100 de NVIDIA.

Pour situer, Nouveau, c'est le pilote graphique libre développé par la communauté pour faire fonctionner les cartes NVIDIA sans dépendre du pilote propriétaire maison.

Le GA100, lui, n'est pas une carte de gamer. C'est la puce qui anime l'A100, l'accélérateur que NVIDIA vend par camions entiers aux data centers pour entraîner les IA et faire tourner du calcul scientifique. Une bête taillée uniquement pour le calcul, sans même de sortie vidéo.

Et c'est justement ce qui posait problème. Nouveau gérait déjà les autres cartes de la génération Ampere grâce au GSP, un petit processeur embarqué sur la carte qui sert d'intermédiaire pour la piloter.

Sauf que le GA100, étant une puce entièrement dédiée au calcul, faisait bande à part et réclamait un traitement particulier, en réutilisant au passage des bouts de code prévus pour la génération précédente. NVIDIA a fini par publier les correctifs nécessaires en février, et ils arrivent donc maintenant dans le noyau.

Attention quand même à ne pas crier victoire trop vite. Le pilote côté noyau est prêt, d'accord, mais la partie logicielle qui permet réellement d'exploiter la carte pour faire du calcul n'est pas encore au point côté libre.

Les outils comme Mesa ou les pilotes OpenCL ne savent toujours pas gérer une carte NVIDIA dépourvue de moteur 3D. Il reste du boulot avant d'avoir une chaîne entièrement open source du début à la fin.

Source : Phoronix

niri , c'est un compositor Wayland écrit en Rust par Ivan Molodetskikh, et il a un drôle de kink qui est de ne jamais redimensionner vos fenêtres dans votre dos. Jamais !!

Ainsi, quand vous ouvrez une nouvelle appli, elle vient se coller à droite de la précédente sur une bande horizontale qui s'étend à l'infini. Pas de grille rigide, pas d'empilement façon Tetris, vous scrollez simplement vers la droite pour balader votre regard sur vos fenêtres, comme on fait défiler une pellicule photo.

Derek Clark, développeur chez Valve, a fait remonter dans le noyau Linux un nouveau pilote baptisé hid-oxp. Sa fonction : permettre au système de configurer correctement les consoles portables de la marque OneXPlayer, un constructeur chinois qui fabrique des petites consoles PC un peu dans l'esprit du Steam Deck mais livrées sous Windows par défaut.

Le code est mis en file dans la branche de développement de Linux 7.2, dont la fenêtre de merge doit s'ouvrir en juin.

En pratique, le pilote prend en charge trois choses chez ces machines : l'éclairage RGB des boutons et joysticks (luminosité, effets, on/off, vitesse), la gestion de l'intensité des vibrations, et un mécanisme de mapping matériel des boutons.

Trois éléments qui, sans pilote dédié, sont inaccessibles ou demandent des bidouilles Windows-only. Pour celui qui veut faire tourner une distribution Linux ou un SteamOS-like sur sa OneXPlayer, c'est désormais beaucoup plus simple.

Le code est sous licence GPLv2+ et copyrighté Valve Corporation. C'est donc le studio derrière Steam qui finance ce travail, comme il l'a déjà fait pour le Steam Deck et plus récemment pour les ROG Ally d'Asus.

Valve a un intérêt évident à élargir le catalogue de machines capables de faire tourner SteamOS sans douleur, vu que la version 3 du système commence à devenir une vraie alternative à Windows pour les consoles portables.

Derek Clark a poussé le pilote dans la branche hid.git for-7.2/oxp, qui sera mergée dans le noyau principal au prochain cycle. Linux 7.2 devrait sortir vers la fin de l'été, ce qui veut dire que les distributions Linux ayant un noyau récent l'auront automatiquement quelques semaines plus tard.

Ce qui est rigolo dans tout ça, c'est de voir Valve travailler patiemment, pilote par pilote, à transformer toutes les consoles portables PC chinoises en machines compatibles SteamOS. Asus, OneXPlayer, demain probablement Ayaneo et GPD.

Du coup, à terme, on aura peut-être un écosystème où la question Windows ou SteamOS se pose vraiment, alors qu'aujourd'hui c'est surtout SteamOS qui doit prouver qu'il sait faire tourner les jeux.

Source : Phoronix

Greg Kroah-Hartman, le numéro 2 du développement du noyau Linux après Linus Torvalds en personne, s'est offert un nouveau jouet en avril dernier : un assistant IA tournant en local sur son ordinateur, qu'il a appelé gkh_clanker_t1000 en clin d'œil au Terminator.

Le but, c'est de faire du fuzzing, c'est-à-dire balancer plein d'entrées bizarres sur du code pour voir ce qui casse. Et clanker, c'est l'argot anglais légèrement méprisant pour désigner les IA. C'est plutôt rigolo.

Le matériel, c'est un Framework Desktop, un mini PC modulaire et réparable, équipé du Ryzen AI Max+ "Strix Halo" d'AMD, avec ses seize cœurs et jusqu'à 128 Go de mémoire unifiée. Le tout fait tourner un grand modèle de langage en local, sans cloud, sans dépendance externe. Greg KH lui balance des bouts du noyau Linux à analyser, l'IA repère les fragments suspects, et lui, avec ses décennies d'expérience, regarde si c'est un vrai bug ou du bruit. Quand c'est un vrai bug, il écrit le patch lui-même.

Depuis avril, près de 24 patches issus de ce process ont été mergés dans la branche principale du noyau Linux. Ils touchent des sous-systèmes très variés : USB, HID, audio ALSA, partage de fichiers SMB, IO_uring, le pilote graphique Nouveau, et plein d'autres.

Tous portent une étiquette spéciale dans Git, "Assisted-by: gregkh_clanker_t1000", pour signaler à la communauté que l'IA a participé à leur découverte. C'est une transparence que pas mal d'autres projets feraient bien de copier.

Et la suite est déjà là. Greg KH travaille sur une version successeur baptisée gkh_clanker_2000, qui poursuit la même logique avec quelques évolutions de méthodologie. L'idée n'est pas que l'IA écrive du code à la place du mainteneur, mais qu'elle agisse comme un assistant qui débroussaille et signale, pendant qu'un humain expérimenté garde la responsabilité finale.

Le détail qui change tout, c'est que tout ça tourne en local. Pas d'API cloud, pas de fuite de bouts de noyau chez un fournisseur tiers. Pour un projet aussi sensible que le noyau Linux, ce n'est pas un détail. Et ça démontre qu'on n'a pas besoin de GPT-5 ou Claude Opus dans le cloud pour faire du travail sérieux d'analyse de code, un bon modèle local sur un bon PC suffit.

Source : Phoronix

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

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

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

Vous avez déjà essayé de faire tourner un vieux logiciel Linux sur une distrib récente, du genre un truc compilé il y a 5 ans ? Bah bon courage, parce que y'a de grandes chances que ça plante lamentablement à cause d'une dépendance qui aura changé entre-temps.

Maintenant, prenez un .exe Windows de 1998, genre un vieux jeu ou une appli Win32 classique. Lancez-le sous Wine et là, ô surprise... y'a de bonnes chances que ça tourne ! Bon, ça dépend des applis évidemment, mais le taux de réussite est souvent meilleur qu'avec les vieux binaires Linux...

C'est précisément ce paradoxe que pointe le projet loss32 , une distro Linux expérimentale dont l'idée complètement dingue serait de faire tourner TOUT l'environnement de bureau en Win32 via Wine. Leur slogan c'est "Win32 is the stable Linux ABI!" ce qui veut dire en gros que l'interface binaire la plus fiable pour faire tourner des applications sur Linux à long terme, c'est celle de Windows. Ahaha, je suis mort de rire en écrivant ça car j'imagine votre tête énervée de barbu ! Pourtant, vous allez voir, c'est difficile de leur donner tort...

Alors c'est quoi le problème avec Linux exactement ?

Hé bien en août 2022, un changement dans la toolchain a fait des dégâts. Beaucoup de distributions ont basculé vers l'option --hash-style=gnu au lieu de --hash-style=both, ce qui génère des binaires sans la section DT_HASH classique. L'idée c'était de gagner quelques kilobytes par binaire avec DT_GNU_HASH, qui est plus moderne et plus performant.

Ça n'a l'air de rien comme ça... sauf que ça a cassé pas mal de trucs. Des jeux utilisant Easy Anti-Cheat d'Epic se sont retrouvés en vrac, par exemple Shovel Knight a eu des soucis, ou encore le limiteur de framerate libstrangle . Bref, des logiciels qui marchaient très bien la veille se sont retrouvés dans les choux du jour au lendemain.

Et c'est là qu'on touche au cœur du problème car sous Windows, Microsoft maintient une compatibilité binaire quasi-religieuse pour les applis Win32 classiques. Un programme compilé pour Windows 95, s'il n'utilise pas de drivers ou d'APIs obsolètes, a de bonnes chances de tourner sur Windows 11. C'est un contrat tacite entre Microsoft et les développeurs qui a tenu pendant trois décennies.

Et même si sous Linux, le kernel et glibc sont plutôt stables, c'est vrai, dès qu'on parle de binaires tiers liés à des bibliothèques user, c'est une autre histoire. Et comme c'est le bordel et que chaque distribution fait un peu ce qu'elle veut, et les dépendances évoluen forcement. Du coup, si votre binaire précompilé casse, c'est votre problème. La philosophie c'est donc plutôt "recompile ton truc et arrête de te chialer 'spèce de fragile".

Et c'est pour ça que Valve a misé gros sur Proton. Officiellement, ils n'ont pas de préférence entre ports natifs et Windows via Proton, mais dans les faits, Proton fonctionne tellement bien que pas mal de studios ne se cassent plus la tête à faire des ports Linux natifs. Et parfois, les jeux Windows via Proton tournent même mieux que les ports natifs ... c'est dire.

Et le projet loss32 pousse cette logique jusqu'au bout car pourquoi se battre contre les moulins à vent de la fragmentation Linux quand on peut simplement tout faire tourner en Win32 ?

Alors perso, j'ai hâte de voir ça et visiblement un PoC devrait sortir en janvier 2026 avec un paquet APT pour qu'on puisse tous tester ça chez nous. Et si ça fonctionne bien, ça veut dire que si vous créez une application desktop simple et que vous voulez qu'elle tourne sur Linux encore dans 10 ans, cibler Win32 et distribuer un .exe via Wine/Proton est une option à considérer sérieusement.

Ça semble contre-intuitif, mais pour certains cas d'usage, c'est une stratégie pragmatique...

Pour les utilisateurs, ça veut dire aussi que Wine et Proton ne sont pas des rustines en attendant mieux mais des des solutions de première classe pour faire tourner des logiciels de manière stable sur Linux. Le Steam Deck l'a prouvé avec des milliers de jeux Windows qui tournent nickel.

Bref, on en est là... Win32, l'API de Microsoft, est devenue paradoxalement une des couches de compatibilité les plus stables pour faire tourner des logiciels sur Linux. C'est fou non ? Ça va faire grincer des dents de barbus c'est sûr mais c'est aussi la preuve que parfois, les solutions terre à terre l'emportent sur l'idéologie.

Source

Vous avez une vieille GTX 1060 qui tourne nickel sous Arch Linux ? C'est con, NVIDIA vient de vous mettre un beau coup de pied aux fesses car la boîte au caméléon vert a décidé d'abandonner le support des GPU Pascal (les GTX 10xx) dans son dernier driver 590 et ça crée un joyeux bordel, notamment sur Arch.

Le problème, c'est que quand vous faites une mise à jour système sur Arch avec une vieille carte Pascal ou Maxwell, le nouveau driver refuse de charger. Résultat, vous vous retrouvez éjecté vers la ligne de commande sans interface graphique. Sympa pour débugger quand y'a plus d'écran qui fonctionne...

Faut dire que le modèle "rolling release" d'Arch fait que les utilisateurs ont reçu ce driver incompatible automatiquement avec leur mise à jour. Ils n'ont pas eu le temps de dire ouf que leur système était déjà cassé. Et les GTX 1060 et 1050 Ti, c'est pas exactement des cartes de musée... Y'en a encore pas mal qui tournent sur Steam, et même si parmi leurs propriétaires, seule une poignée utilise Linux, et encore moins Arch, ça fait quand même du monde impacté.

Pour s'en sortir, y'a deux solutions. La première, c'est d'installer le driver legacy nvidia-580xx-dkms depuis l'AUR, qui est maintenu par l'équipe CachyOS. Le hic, c'est que ça crée des problèmes de dépendances avec Steam, donc faut aussi installer lib32-nvidia-580xx-utils pour que les jeux 32 bits fonctionnent. La deuxième option, c'est de basculer sur Nouveau, le driver open source fait par reverse engineering. Ça marche, mais avec les limitations que ça implique niveau performances et fonctionnalités.

Ce qui me rend dingue dans cette histoire, c'est que pendant des années, NVIDIA a refusé de fournir de la documentation pour ses GPU, forçant la communauté Linux à utiliser le reverse engineering pour Nouveau. Et depuis 2022, ils ont ouvert les modules kernel pour les architectures Turing et plus récentes, mais les parties user-space et le firmware restent propriétaires. Et surtout, aucune aide pour les vieilles cartes comme Pascal !! Du coup, maintenant que NVIDIA abandonne ces générations de cartes, c'est aux bénévoles de la communauté de maintenir les drivers legacy... Pas cool.

D'ailleurs, l'annonce officielle d'Arch Linux précise que les cartes Turing et plus récentes (RTX 20xx et GTX 1650+) vont automatiquement basculer vers les modules kernel open source, donc pas d'intervention manuelle pour eux. C'est uniquement les propriétaires de vieilles Pascal/Maxwell qui doivent se taper le boulot.

Bref, si vous avez une carte Pascal sous Arch, basculez sur nvidia-580xx-dkms avant votre prochain pacman -Syu. Dans sa grande bonté, NVIDIA a aussi promis des patchs de sécu jusqu'en 2028, mais bon, on a vu ce que valent leurs promesses côté Linux...

Source