Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.
Un processeur de 1989
L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.
Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.
La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.
Du ménage dans le code
Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.
Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.
Et le 32 bits, alors ?
Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.
Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.
Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.
Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.
En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !
Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.
La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.
Quatre failles, dont une critique
Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.
La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.
Des fichiers supprimés et des téléchargements détournés
La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.
Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.
Qui doit mettre à jour
Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.
La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.
C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.
Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.
CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.
Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.
Quand l'IA fait le boulot des chercheurs en sécurité
C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des
agents IA
pour analyser le code de CUPS et débusquer les problèmes.
Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.
Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.
Deux failles qui se complètent
La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.
CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.
La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.
Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d'
écraser des fichiers système
en tant que root.
Pas de patch, mais des correctifs dans les tuyaux
Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.
Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.
Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.
C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.
Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.
Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.
Enfin !
Ce module s'appelle
hid-omg-detect
et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.
D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.
Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers
USBGuard
pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !
Mais alors pourquoi lancer ça maintenant ?
Hé bien parce que les outils d'attaque USB sont devenus légion ! Les
câbles O.MG
(créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois,
des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB
... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.
Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme
USBRip
(un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.
On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les
attaques par périphériques USB piégés
. Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !
Guide complet pour apprendre à installer et configurer AdGuard Home sur Linux pour bloquer les pubs sur tous les appareils du réseau (PC, TV, smartphone, etc).
Avec Ubuntu 26.04 LTS, les 6 Go de RAM deviennent la base recommandée pour Ubuntu Desktop. Cette évolution interroge face à la flambé des prix de la mémoire.
Et si je vous disais qu'on pouvait faire tourner Firefox dans un terminal ? Et pas un navigateur en mode texte, hein. Non, le véritable Firefox, avec ses onglets, les images, la totale... Hé oui c'est possible et que ça fonctionne via SSH, donc depuis un serveur distant. Bienvenue dans le futur (ou le passé, j'sais plus trop) !
Term.everything
c'est un compositeur Wayland construit from scratch en Go qui, au lieu de balancer l'image sur votre écran, la convertit en caractères ANSI et l'affiche dans le terminal. Du coup, n'importe quelle app GUI Linux peut tourner là-dedans. Firefox, un gestionnaire de fichiers, un lecteur vidéo... et même Doom (parce que si ça peut pas faire tourner Doom, ça compte pas). Le binaire fait une poignée de Mo, c'est sous licence AGPL-3.0, et y'a zéro dépendance externe.
L'outil propose 2 modes d'affichage. Le mode basique qui convertit les pixels en blocs Unicode, et dont la qualité dépend du nombre de lignes et colonnes de votre terminal. Plus vous zoomez out (Ctrl+- sur Alacritty), plus c'est net... mais plus ça rame. Donc si votre terminal supporte le protocole image, genre Kitty ou iTerm2, l'autre mode, c'est du rendu pleine résolution et là non seulement c'est pas dégeu mais en plus ça marche bien !
Le truc vraiment dingue, c'est surtout le SSH parce que si vous avez un serveur Linux distant, vous vous connectez dessus en SSH, vous lancez term-everything firefox et hop, Firefox s'affiche dans votre terminal local. Pas de X11 forwarding relou à mettre en place ni de VNC / RDP zarbi.
Pour les admins sys qui gèrent des serveurs headless, c'est quand même sympa ! D'ailleurs si vous aimez
les outils SSH bien pensés
, celui-ci aussi va vous plaire.
Par contre, on est encore en bêta et certaines apps vont planter ou refuser de se lancer. C'est normal, c'est un compositeur Wayland complet écrit par un seul gars (chapeau l'artiste !). Ce n'est donc pas le genre de truc qu'on met en prod, mais pour du dépannage sur un serveur Debian distant ou juste pour la beauté du geste, ça envoie du pâté.
Le créateur de term.everything est d'ailleurs le même qui avait codé
Fontemon
, un jeu vidéo caché dans une police de caractères. On est donc clairement dans la catégorie "parce qu'on peut le faire et que c'est marrant".
Bref, si vous voulez épater vos collègues en lançant KDE dans un terminal par-dessus SSH, ou juste jouer à Doom dans tmux,
c'est par là que ça se passe.
Amusez-vous bien et merci à Lorenper pour l'info !
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à.
GNOME 50 est disponible et cette version de l'environnement de bureau intègre un changement majeur : la suppression des sessions X11 au profit de Wayland.
Opera GX, le navigateur web pensé pour le gaming, débarque officiellement sur Linux. Il intègre un VPN, un bloqueur de pubs et d'autres fonctionnalités.
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 !
Le pilote Vulkan open source d'Intel pour Linux vient de recevoir une optimisation qui améliore les performances des jeux DirectX 12 tournant via Proton.
La modification a été intégrée à Mesa 26.1 et concerne les cartes graphiques Arc Alchemist et Battlemage. Le patch avait été proposé pour la première fois en 2020, il aura donc fallu plus de cinq ans pour le voir arriver.
Ce qui change pour les joueurs Linux
L'optimisation porte sur la façon dont le pilote ANV gère le cache d'état graphique. En utilisant une combinaison de deux identifiants internes (Binding Table Pointer et Binding Table Index) au lieu d'un seul pour référencer les textures, le pilote peut supprimer certaines étapes de synchronisation qui ralentissaient le rendu.
Les développeurs d'Intel indiquent que le gain est mesurable sur tous les jeux DirectX 12 qu'ils ont testés via VKD3D-Proton, la couche de traduction utilisée par Steam pour faire tourner les jeux Windows sur Linux.
Pas de chiffres précis dans la note technique, mais une autre modification récente du même pilote (un simple changement d'une ligne de code pour le prefetch des tables de textures) avait déjà montré des gains allant jusqu'à 3 à 4 % sur God of War et Destiny 2.
Un patch qui a mis cinq ans à arriver
L'anecdote vaut quand même le détour. Ce patch a été proposé pour la première fois en novembre 2020, et il vient d'être fusionné dans Mesa en mars 2026.
Plus de cinq ans entre la proposition et l'intégration, ce qui donne une idée du rythme de développement des pilotes graphiques open source. Le code nécessite aussi un correctif au niveau du noyau Linux (dans le pilote Xe), qui devrait arriver avec Linux 7.1.
Les GPU concernés sont les Intel Arc à partir de la génération Alchemist (Arc A770, A750, etc.) et les plus récents Battlemage (Arc B580, B570).
Quelques limites quand même
L'optimisation ne fonctionne bien qu'avec les jeux DirectX 12. Sur les titres DirectX 11, les développeurs ont constaté des baisses de performances, ce qui fait que le mécanisme est activé automatiquement pour DX12 et désactivé pour DX11. Il est aussi possible de forcer son activation ou sa désactivation via un réglage dans la configuration DRI.
C'est le genre de petite avancée qui, mise bout à bout avec les autres, finit par rendre les GPU Intel Arc de plus en plus viables sous Linux pour le jeu. Cinq ans pour un patch, c'est long, mais le résultat est là. Et puis ça montre aussi que l'approche open source d'Intel sur ses pilotes graphiques continue de porter ses fruits, même si le chemin est quand même un peu plus lent que chez NVIDIA ou AMD.
Kali Linux 2026.1, the first release of the year, is now available for download, featuring 8 new tools, a theme refresh, and a new BackTrack mode for Kali-Undercover. [...]
Un développeur américain a soumis en une semaine des modifications à trois projets Linux majeurs pour y ajouter un champ de date de naissance, au nom de lois californiennes et brésiliennes qui entreront en vigueur en janvier 2027.
Le plus gros morceau, systemd, a accepté la modification et refuse de revenir en arrière. La communauté open source est depuis en ébullition.
Un développeur solitaire, trois projets visés
Dylan M. Taylor, ingénieur DevOps basé en Caroline du Nord, a soumis des pull requests à systemd, Ubuntu et Arch Linux en mars 2026. Son objectif : ajouter un champ "date de naissance" dans la base de données utilisateur de chaque système, pour se conformer à trois lois qui entrent en vigueur le 1er janvier 2027.
La loi californienne AB-1043, la loi du Colorado SB26-051 et la loi brésilienne Lei 15.211 imposent aux systèmes d'exploitation de collecter l'âge des utilisateurs dès la création du compte, puis de transmettre cette donnée aux magasins d'applications via une API.
Le plus surprenant, c'est que personne ne lui a demandé de faire ça. Taylor a lu les textes de loi, estimé que Linux devait s'y conformer, et s'est mis au travail tout seul.
Il a lui-même reconnu dans sa pull request pour Arch Linux que le système serait "totalement inefficace pour empêcher quiconque de mentir sur son âge". Il a qualifié sa propre fonctionnalité de "hilarante d'inutilité", mais a quand même insisté pour l'intégrer.
systemd a accepté, et le revert a été refusé
Côté systemd, la modification a été acceptée par Luca Boccassi, un mainteneur qui travaille chez Microsoft. La pull request a généré 945 commentaires. Quand un autre développeur a tenté de faire annuler la fusion, Lennart Poettering, le créateur de systemd (ancien Red Hat, passé par Microsoft), a personnellement rejeté la demande le 19 mars.
Son argument : le champ est optionnel, systemd ne force rien, et les distributions sont libres de l'utiliser ou non. Le champ date de naissance reste donc dans le code.
Côté Ubuntu, les deux pull requests sont restées à l'état de brouillon. Un vice-président de Canonical a précisé qu'il n'y avait "aucun plan concret" pour intégrer cette fonctionnalité.
Côté Arch Linux, le mainteneur a verrouillé la discussion en attendant un avis juridique. Et Artix Linux a pris la position la plus claire : jamais de vérification d'identité ni d'âge dans leur distribution.
Des lois qui posent un vrai problème technique
Ces lois partent du principe que c'est au système d'exploitation de jouer le rôle de contrôleur d'identité. Sauf que Linux n'est pas Windows ou macOS : c'est un projet communautaire, maintenu par des bénévoles et des entreprises aux intérêts variés.
Collecter des données personnelles dans un système open source pour les transmettre à des magasins d'applications, c'est un changement de philosophie assez radical.
Un développeur d'Ubuntu a proposé une approche différente : une interface D-Bus optionnelle, sans stocker de date de naissance brute. Plus respectueux de la vie privée, mais ça ne fait pas non plus l'unanimité.
On a donc là un ingénieur qui admet que sa propre fonctionnalité ne sert à rien, et qui l'intègre quand même dans un des composants les plus utilisés de Linux. Le tout validé par un mainteneur employé chez Microsoft. Difficile de ne pas remarquer le problème.
Que des lois imposent la vérification d'âge aux systèmes d'exploitation, c'est une chose. Mais que ça passe par un bénévole qui pousse du code dans un projet open source sans que personne ne s'en rende compte avant la fusion, c'est un peu particulier quand même.
Lorsque qu’un disque dur est défectueux ou présente des secteurs endommagés, il devient risqué de travailler directement dessus.
Dans ce type de situation, la meilleure solution consiste à réaliser un dump disque (copie bit à bit) afin de sauvegarder toutes les données avant toute tentative de réparation.
Cette technique permet de cloner un disque en copiant chaque secteur, même en présence d’erreurs.
Dans ce guide, nous allons voir comment créer un dump de disque et dans quels cas cette méthode est indispensable.
Un dump disque est souvent la dernière chance de récupérer les données d’un disque défectueux. Ne travaillez pas directement sur le disque d’origine.
Quand faire un dump disque (copie bit à bit)
Créer une image disque (.dd) n’est pas toujours nécessaire, mais dans certaines situations, cela devient fortement recommandé. L’objectif est de travailler sur une copie du disque afin de limiter les risques de perte de données.
Situations où un dump disque est recommandé
Situation
Dump disque recommandé ?
Pourquoi
Disque avec secteurs défectueux
Oui
Évite la perte progressive des données
Disque en panne (lent / bruit)
Oui
Dernière chance de récupération
Récupération de données
Oui
Permet de travailler sur une copie
Disque RAW
Oui
Sauvegarde avant réparation
Disque qui se déconnecte
Non
Préférer une sauvegarde
Disque sain
Non
Inutile
Sauvegarde classique
Non
Préférer une sauvegarde normale
Cas où ce n’est pas indispensable
Dans certaines situations simples, vous pouvez travailler directement sur le disque :
Disque stable et sans erreur
Problème léger (partition visible, peu de corruption)
Vous travaillez sur ce fichier avec des outils (TestDisk, récupération…)
Le disque original reste intact
En cas d’erreur, vous pouvez recommencer sans risque.
Qu’est-ce qu’un dump disque (image disque .dd) ?
Une image disque (.dd) est une copie exacte d’un disque ou d’une partition, réalisée secteur par secteur. Contrairement à une simple copie de fichiers, elle reproduit l’intégralité du contenu du disque, y compris les zones invisibles ou endommagées.
Le résultat est un fichier unique (souvent avec l’extension .dd) qui contient une image complète du disque original.
Une copie “brute” du disque
Une image disque fonctionne comme un clone à l’identique :
Tous les fichiers sont copiés
La structure du système de fichiers est conservée
Les secteurs vides ou corrompus sont également inclus
Cela permet de capturer l’état exact du disque, même en cas de problème.
Différence avec une copie classique
Il est important de distinguer une image disque d’une copie de fichiers :
Copie classique → uniquement les fichiers accessibles
Image disque (.dd) → copie complète du disque, même illisible
Une image disque est donc beaucoup plus adaptée à la récupération de données.
À quoi sert une image disque ?
Créer une image disque permet de :
Travailler sur une copie plutôt que sur le disque original
Éviter d’aggraver les dommages
Tester plusieurs méthodes de récupération sans risque
Sauvegarder l’état du disque avant intervention
C’est une pratique fortement recommandée en récupération de données.
Dans quels cas utiliser un dump disque ?
Dump disque vs clonage vs image disque : quelles différences ?
Lorsqu’il s’agit de sauvegarder ou de récupérer un disque, plusieurs méthodes existent : le dump disque (copie bit à bit), le clonage de disque ou encore la création d’une image disque.
Ces techniques sont souvent confondues, mais elles répondent à des besoins différents.
Le dump disque consiste à copier un disque secteur par secteur, sans tenir compte du système de fichiers. Il est particulièrement adapté aux disques défectueux ou contenant des erreurs.
Le clonage de disque copie les données d’un disque vers un autre disque en vue d’une migration ou d’un remplacement, généralement sur un disque sain.
L’image disque crée un fichier contenant les données du disque, souvent compressé, utilisé pour la sauvegarde ou la restauration.
Comparatif des méthodes
Méthode
Fonctionnement
Cas d’usage
Avantages
Limites
Dump disque (dd / ddrescue)
Copie brute secteur par secteur
Disque défectueux, récupération de données
Sauvegarde complète, ignore erreurs logiques
Lent, nécessite espace équivalent
Clonage de disque
Copie disque vers disque
Migration vers SSD, remplacement disque
Simple, rapide, prêt à l’emploi
Pas adapté aux disques endommagés
Image disque
Copie dans un fichier (compressé)
Sauvegarde, restauration système
Gain de place, flexible
Ne gère pas bien les disques défectueux
Précautions avant de créer un dump disque
Créer une image disque est une opération sensible qui consiste à lire l’intégralité du support. Avant de lancer la copie, il est important de préparer correctement l’environnement afin d’éviter les erreurs et maximiser les chances de récupération.
Vérifier l’état du disque source
Avant toute chose, assurez-vous que le disque est lisible :
Le disque est détecté par Windows ou Linux
Il ne fait pas de bruits anormaux (clics, grattements)
Il ne se déconnecte pas en permanence
Si le disque est très instable, privilégiez un outil comme ddrescue.
Prévoir un support de destination adapté
Une image disque peut être très volumineuse.
Utilisez un disque sain
Prévoyez un espace libre au moins égal à la taille du disque source
Évitez d’utiliser le disque à sauvegarder comme destination
Un manque d’espace peut interrompre la copie.
Ne pas utiliser le disque pendant la copie
Pendant la création de l’image :
N’ouvrez pas de fichiers sur le disque
N’effectuez aucune écriture
Évitez d’utiliser le système si le disque est interne
Cela garantit une copie cohérente.
Utiliser les bons outils
Tous les outils ne sont pas adaptés à un disque endommagé.
Une interruption peut rendre l’image inutilisable.
Tableau des précautions
Précaution
Pourquoi
Risque évité
Vérifier le disque
Détecter instabilité
Échec de la copie
Prévoir l’espace
Éviter saturation
Copie incomplète
Ne pas utiliser le disque
Garantir cohérence
Données corrompues
Choisir le bon outil
Adapter à la situation
Mauvaise récupération
Laisser finir la copie
Éviter interruption
Image inutilisable
Créer un dump disque avec dd (Linux)
La création d’une image disque peut se faire en ligne de commande avec des outils comme dd. Cette méthode permet de réaliser une copie complète du disque, mais elle demande de la rigueur car une erreur peut entraîner une perte de données.
Cette méthode est recommandée pour les utilisateurs à l’aise avec les commandes système.
Principe de la commande dd
La commande dd permet de copier un disque secteur par secteur.
if (input file) → disque source
of (output file) → fichier image (.dd)
bs → taille des blocs
Elle fonctionne sous Linux, mais aussi via des environnements comme WSL ou un Live USB.
Le fichier image (.dd) sera créé sur le disque de destination.
Points importants
La copie est bit à bit, même les secteurs vides sont copiés
Le processus peut être long selon la taille du disque
Aucune gestion avancée des erreurs
En cas de secteurs défectueux, la commande peut s’arrêter.
Limites de la méthode dd
La commande dd présente certaines limites :
Ne gère pas bien les erreurs de lecture
Peut s’interrompre sur un disque endommagé
Ne reprend pas automatiquement en cas d’échec
Pour un disque défectueux, il est préférable d’utiliser ddrescue.
Créer un dump disque avec dd (Linux)
Lorsque le disque est endommagé ou instable, ddrescue est l’outil le plus adapté pour créer une image disque. Contrairement à dd, il est capable de gérer les erreurs de lecture et de reprendre la copie là où elle s’est arrêtée.
C’est la méthode recommandée pour la récupération de données sur un disque défectueux.
Pourquoi utiliser ddrescue ?
ddrescue est conçu pour travailler sur des disques problématiques :
Ignore les secteurs défectueux dans un premier temps
Réessaie de lire les zones endommagées
Enregistre la progression dans un fichier log
Permet de reprendre la copie en cas d’interruption
Il maximise les chances de récupérer un maximum de données.
Principe de fonctionnement
La copie se fait en plusieurs phases :
Lecture rapide des zones accessibles
Saut des secteurs défectueux
Tentatives de récupération des zones difficiles
Cela permet d’obtenir une image disque la plus complète possible.
Identifier le disque
Avant de lancer ddrescue :
Utilisez la commande lsblk
Repérez le disque source (ex : /dev/sdb)
Identifiez le disque de destination
Une erreur de disque peut entraîner une perte de données.
Cette phase tente de lire les secteurs défectueux.
Créer un dump disque avec TestDisk (Windows/Linux)
TestDisk n’est pas conçu à l’origine pour créer des images disque complètes comme dd ou ddrescue. Cependant, il peut être utilisé pour copier des fichiers depuis une partition ou un disque, ce qui peut servir de solution alternative dans certains cas.
Pour créer une véritable image disque (.dd), il est préférable d’utiliser des outils spécialisés comme dd ou ddrescue.
Ce que permet TestDisk
Avec TestDisk, vous pouvez :
Accéder aux fichiers d’une partition détectée
Copier des fichiers ou dossiers vers un autre disque
Sauvegarder les données avant réparation
Cela permet de sécuriser les fichiers sans passer par une image disque complète.
Choisissez un emplacement (bureau ou autre disque)
Lancez l’utilitaire en double-cliquant sur testdisk_win.exe
Choisissez No Log
Sélectionnez le disque à dumper
Puis laissez le type de partition détectée, probablement EFI GPT
Prenez l’option [Advanced] File System.
Sélectionnez la partition et en bas l’option Image Creation.
Choisissez l’emplacement en vous assurant que l’espace disque sera suffisant et appuyez sur C pour lancer la création. Le dump de la partition s’effectue. On obtient alors un fichier image.dd
La création du fichier image.dd s’effectue
Si tout va bien, une fois terminé, le message suivant s’affiche : Image created successfully.
Limites de cette méthode
TestDisk ne permet pas :
De créer une image disque complète (.dd)
De copier les secteurs bruts
De gérer les erreurs de lecture comme ddrescue
Il ne remplace pas un outil de clonage disque.
Créer un dump disque avec des outils graphiques (plus simple)
Si vous n’êtes pas à l’aise avec la ligne de commande, il existe des outils avec interface graphique qui permettent de créer une image disque facilement, sans avoir à saisir de commandes.
Ces solutions sont plus accessibles et réduisent les risques d’erreur.
Avantages des outils graphiques
Les logiciels avec interface offrent plusieurs bénéfices :
Interface visuelle plus intuitive
Sélection du disque en quelques clics
Paramétrage simplifié
Moins de risque de se tromper de disque
Ils sont particulièrement adaptés aux débutants.
Exemples d’outils disponibles
Plusieurs logiciels permettent de créer une image disque :
DiskGenius → création d’image + récupération de données. DiskGenius utilise son propre format d’image disque (.pmfx). Bien qu’efficace, ce format est propriétaire et ne peut pas être utilisé avec des outils comme TestDisk. Pour une compatibilité maximale, il est préférable d’utiliser un format standard comme .dd.
Certains outils sont gratuits, d’autres proposent des versions payantes.
Étapes générales
Le fonctionnement est globalement similaire :
Lancez le logiciel
Sélectionnez le disque source
Choisissez l’option Créer une image disque
Définissez l’emplacement de sauvegarde
Lancez la copie
Le logiciel se charge du reste.
Points de vigilance
Même avec une interface graphique :
Vérifiez toujours le disque source sélectionné
Assurez-vous d’avoir suffisamment d’espace
Ne travaillez pas sur le disque à sauvegarder
Évitez d’interrompre l’opération
Les erreurs restent possibles si les mauvaises options sont choisies.
Tableau comparatif
Outil
Type
Facilité d’utilisation
Fonctionnalités
DiskGenius
Récupération + image
Élevée
Analyse, récupération Format propriétaire .pmfx
HDClone
Clonage
Élevée
Copie disque
Macrium Reflect
Sauvegarde
Moyenne
Image système
R-Studio
Avancé
Moyenne
Forensic, récupération
Des outils graphiques comme Macrium Reflect permettent de créer une image disque facilement, sans ligne de commande. Cependant, ces logiciels ne réalisent pas toujours une copie bit à bit complète comme dd ou ddrescue. Ils sont plus adaptés à la sauvegarde ou au clonage de disques fonctionnels. En cas de disque défectueux ou de secteurs endommagés, il est préférable d’utiliser des outils spécialisés comme ddrescue.
Travailler sur une image disque (dump disque)
Une fois l’image disque (.dd) créée, il est fortement recommandé de travailler uniquement sur cette copie plutôt que sur le disque original. Cette approche permet de préserver l’état du support et de limiter les risques en cas d’erreur.
Pourquoi utiliser l’image disque ?
Travailler sur une image disque présente plusieurs avantages :
Le disque original reste intact
Vous pouvez tester plusieurs méthodes sans risque
Vous évitez d’aggraver les dommages
Vous pouvez revenir en arrière en cas d’erreur
Cela apporte une sécurité essentielle lors de la récupération de données.
Monter l’image disque
Pour exploiter une image disque (.dd), il est souvent nécessaire de la monter comme un disque virtuel. Cela permet d’accéder aux partitions et aux fichiers comme si le disque était connecté physiquement.
Monter une image disque sous Linux (loop device)
Sous Linux, vous pouvez utiliser un loop device pour attacher l’image disque.
Identifiez un périphérique libre :
losetup -f
Associez l’image disque :
losetup /dev/loop0 image.dd
Rafraîchissez les partitions :
partprobe /dev/loop0
Montez la partition :
mount /dev/loop0p1 /mnt
Vous pouvez alors accéder aux fichiers dans /mnt.
Monter une image disque sous Windows
Windows ne supporte pas nativement les fichiers .dd. Vous devez utiliser un logiciel spécialisé.
Exemples :
OSFMount (léger et efficace)
DiskGenius
R-Studio
Avec OSFMount :
Lancez le logiciel
Cliquez sur Mount new
Sélectionnez votre fichier .dd
Choisissez une partition à monter
Validez
L’image apparaît comme un disque dans l’explorateur.
estDisk ne permet pas de charger une image disque depuis son interface. Il faut passer par la ligne de commande.
Ouvrez un terminal ou invite de commandes
Lancez TestDisk avec le fichier image :
testdisk image.dd
TestDisk considère alors l’image comme un disque réel
Si vous préférez une interface graphique, vous pouvez monter l’image avec un outil comme OSFMount, puis lancer TestDisk sur le disque virtuel.
Tester sans risque
L’image disque permet de :
Essayer plusieurs méthodes de récupération
Recommencer en cas d’échec
Comparer les résultats
Cela évite les erreurs irréversibles.
Conserver une copie de sauvegarde
Même après récupération :
Conservez l’image disque
Stockez-la sur un support fiable
Évitez de la modifier
Elle peut servir de sauvegarde ou de référence.
Tableau des avantages
Avantage
Impact
Protection du disque original
Évite les dommages supplémentaires
Travail sécurisé
Permet de tester sans risque
Reproductibilité
Possibilité de recommencer
Sauvegarde
Conservation des données
Vérifier l’intégrité d’un dump disque
Une fois l’image disque (.dd) créée, il est important de vérifier qu’elle est complète et exploitable. Une image corrompue ou incomplète peut compromettre la récupération des données.
Vérifier la taille de l’image
La première vérification consiste à comparer la taille du fichier image avec celle du disque source.
La taille de l’image doit être proche de celle du disque
Une taille anormalement faible peut indiquer une copie incomplète
Cela permet de détecter rapidement un problème lors de la création.
Vérifier le fichier log (ddrescue)
Si vous avez utilisé ddrescue :
Consultez le fichier .log généré
Vérifiez les secteurs non lus ou en erreur
Analysez le taux de récupération
Le log donne une vision précise de l’état de la copie.
Monter l’image disque
Un bon test consiste à monter l’image :
Ouvrez l’image avec un outil compatible
Vérifiez si les partitions sont détectées
Essayez d’accéder aux fichiers
Si l’image est lisible, elle est exploitable.
Tester avec un outil de récupération
Vous pouvez également :
Ouvrir l’image dans TestDisk
Lancer un scan avec un logiciel de récupération
Vérifier la présence des fichiers
Cela confirme que les données sont récupérables.
Vérifier l’intégrité (hash)
Pour une vérification avancée, vous pouvez calculer une empreinte (hash) :
Connexion
