Quand on est habitué à Linux et qu'on se retrouve avec un Mac, même si c'est une base unix, c'est déroutant. Heureusement, Apple est de plus en plus ouvert au monde du libre et vient de publier la version 1.0 de Container , avec dedans des "container machines" qui ressemblent furieusement à WSL. Et ça nous permet comme ça d'avoir le meilleur des deux mondes : un macOS pour le quotidien, et un vrai Linux pour vos folles bidouilles.

Vous vous souvenez forcément de mon article où je vous présentais Apple Container , cet outil écrit en Swift qui fait tourner des conteneurs Linux dans des petites machines virtuelles. Et bien un an plus tard, le projet passe en 1.0, pile pour la WWDC, et la grosse nouveauté c'est donc ce mode "machine".

Le CLI container en action, sobre comme un terminal qui bosse ( Source )

Il s'agit d'un environnement qui vous permet de faire tourner de vraies distributions Linux comme Ubuntu, Debian ou Alpine, et pas juste un conteneur modelé sur une application. La machine lance le système d'init de l'image, donc un systemctl start postgresql fonctionnera comme sur un vrai serveur.

Et à la reconnexion, à partir du même terminal ou d'un autre, l'état de la machine n'est pas perdu. Surtout, elle mappe automatiquement votre utilisateur et votre répertoire home. Votre repo vit ainsi dans le $HOME de macOS, du coup vous éditez avec votre IDE côté Mac et vous compilez côté Linux, sans étape de copie entre les 2.

Pour la prise en main, entrez les commandes suivantes en prenant soin de remplacer alpine par la distrib de votre choix :

container machine create alpine:latest --name dev
container machine run -n dev whoami # votre user, pas root
container machine run -n dev # shell interactif

Oliver Sieber, un chercheur de chez Exodus Intelligence, vient de publier l'exploit complet d'une faille qui tient dans un seul caractère. C'est la CVE-2026-23111, planquée dans nf_tables, c'est à dire au bout du noyau Linux qui filtre les paquets réseau. Un bug discret donc, qui transforme un compte tout pourri, sans le moindre privilège, en compte root sur la machine... et qui vous fait sortir d'un conteneur au passage.

Le scénario, vous le connaissez si vous traînez ici depuis un moment. Un utilisateur qui dispose d'un compte sans droit particulier sur une machine Linux (y compris parce qu'il a exploité une autre faille avant, dans une appli web par exemple) lance l'exploit, et se retrouve avec les pleins pouvoirs. Pas de vecteur distant, rien à cliquer : c'est l'arme qu'on dégaine une fois le pied dans la porte. Que ce soit un shell avec des droits limités, un conteneur compromis, un compte de service... tout y passe et hop, root sur l'hôte !

Le bug lui-même, c'est ce qu'on appelle un use-after-free, c'est à dire que le noyau réutilise un bout de mémoire qu'il a déjà libéré, et forcément ça part en vrille. Exodus a titré son analyse complète "Off By !", un clin d'œil au classique off-by-one des développeurs, sauf qu'ici le coupable c'est un test inversé. Un caractère de trop, une condition qui dit l'inverse de ce qu'elle devrait, et voilà. Et le correctif, lui, tient en une seule ligne.

Le fameux caractère : le ! qui inversait le test dans nft_map_catchall_activate(). Le correctif le retire, et c'est tout (commit 8fdb05de).

La faille a d'ailleurs été reproduite deux fois, par deux équipes qui ne se sont pas concertées. Exodus l'a validé sur Debian Bookworm, Debian Trixie, Ubuntu 22.04 et 24.04. FuzzingLabs avait sorti sa propre version dès avril, par un chemin complètement différent, et l'avait fait tourner sur RHEL 10 juste avant le Pwn2Own de Berlin. Bref, ça marche, c'est bien documenté, et c'est public.

Mais le pire, c'est le calendrier de tout ce merdier puisque le patch a été mis à dispo le 5 février. Ensuite, y'a eu l'exploit de FuzzingLabs publié le 16 avril, suivi d'un write-up détaillé d'Exodus le 8 juin. Autrement dit, ça fait des mois que le correctif existe et des semaines que le code d'exploitation traîne dans la nature.

La seule chose qui vous sépare donc d'un compte root offert à n'importe qui, c'est d'avoir mis à jour ou pas.

Et cette faille s'ajoute à une sacrée série de failles root-local sur Linux ce printemps. Y'a eu Copy Fail , y'a eu Dirty Frag et sa variante Fragnesia ... à chaque fois le même refrain, un compte sans droit qui finit root sur une install standard. C'est devenu presque routinier, et Synacktiv pointe une raison plutôt pertinente en nous expliquant que c'est à cause (ou grâce ^^) aux outils d'IA qui décortiquent les patchs pour en sortir un exploit rapidos, qui marche direct avant même que la correction soit déployée partout.

Du coup, qu'est-ce que vous devez faire ?

Hé bien le plus simple d'abord, c'est de mettre à jour le noyau et vous rebootez. Ubuntu a corrigé 22.04, 24.04 et 25.10, Debian a patché Bookworm et Trixie (avec un backport en 6.1 pour Bullseye), et Red Hat, SUSE et Amazon Linux ont suivi. Comme la version corrigée exacte dépend de votre distrib, jetez donc un œil à l'advisory qui correspond à la vôtre.

Si vous gérez une machine où tournent des utilisateurs ou des workloads pas franchement de confiance, vous pouvez également couper le chemin d'attaque sans attendre le patch. La faille a besoin des user namespaces non privilégiés, un mécanisme qui laisse un process lambda se bricoler son propre bac à sable avec des droits root à l'intérieur.

Et nf_tables comme ces namespaces, sur la plupart des desktops et pas mal de serveurs, c'est actif par défaut, donc oui, sans le patch vous êtes probablement exposé.

Pour les désactiver, le plus universel c'est user.max_user_namespaces=0 : un sysctl -w user.max_user_namespaces=0 pour tout de suite, et la même ligne dans un fichier genre /etc/sysctl.d/99-userns.conf pour que ça tienne au reboot.

Ça marche sur toutes les distros mais c'est radical, ça coupe tous les user namespaces, même ceux de root. Sur Debian et les vieilles Ubuntu, t'as plus fin avec kernel.unprivileged_userns_clone=0 qui ne vise que les non-privilégiés. Et sur Ubuntu 24.04, bonne nouvelle, c'est déjà restreint par défaut via AppArmor. Attention quand même, ça peut casser des trucs qui s'appuient dessus, genre le bac à sable de Chrome ou Flatpak.

À faire en connaissance de cause, donc.

La parade en vrai : une fois les user namespaces non privilégiés coupés, un compte lambda qui tente d'en créer un (le prérequis de l'exploit) se fait jeter sur un "No space left on device".

Après la bonne nouvelle, c'est que d'après les chercheurs, aucune exploitation dans la nature pour cette faille précise n'a été constaté à ce jour. Après comme sa cousine Copy Fail, elle, a déjà atterri au catalogue des failles activement exploitées de la CISA, ne traînez pas trop. Bref, comme d'hab padpanik, vous mettez à jour, vous rebootez, et on n'en parle plus.

Source

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

• lien nᵒ 1 : April
• lien nᵒ 2 : Revue de presse de l'April
• lien nᵒ 3 : Revue de presse de la semaine précédente
• lien nᵒ 4 : 🕸 Fils du Net

Commentaires : voir le flux Atom ouvrir dans le navigateur

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.

Un développeur connu sous le pseudo EVVIE a sorti Waylandcraft, un projet qui n'aurait jamais dû exister et c'est tant mieux.

Le principe : faire tourner de vrais logiciels Linux directement dans le monde de Minecraft, leurs fenêtres posées comme des objets au milieu du jeu. Votre navigateur, votre éditeur de texte, un terminal, tout ça affiché sur des blocs, en 3D, et utilisable pour de vrai.

Flipper Devices, les gens derrière le fameux Flipper Zero , viennent de dévoiler leur prochain joujou, le Flipper One . Et leur annonce démarre par cette phrase de Pavel Zhovner, le co-fondateur : « on est franchement terrifiés, et on a besoin de vous ».

Apparemment, ce nouveau projet l'angoisse et faut être honnête, y'a de quoi. Car le Flipper One, ce n'est pas un Flipper Zero en plus gros. C'est carrément un mini-PC Linux ARM de poche, pensé comme un couteau suisse pour le réseau. Et là où le Zero causait uniquement aux protocoles de proximité (NFC, RFID, sub-GHz, infrarouge), le One joue dans la cour du dessus, en s'adressant également au monde IP, donc tout ce qui est Wi-Fi, Ethernet, 5G et même satellite. Ahaha, j'adore !

Et côté tripes, s'ils tiennent leurs promesses, ça va envoyer du lourd ! En effet, on va y retrouver un Rockchip RK3576 8 cœurs cadencé avec GPU Mali et un NPU pour faire tourner des modèles d'IA en local, 8 Go de RAM, deux ports Gigabit Ethernet indépendants, du Wi-Fi 6E qui gère le monitor mode, un modem 5G en module M.2, et une sortie HDMI 2.1 en 4K.

En gros, vous avez un routeur, un analyseur de signaux et un thin client réunis dans un truc qui tient dans la poche.

Puis y'a surtout ce truc de "double cerveau" avec à côté du gros CPU, un microcontrôleur RP2350 (celui du Raspberry Pi Pico 2) en plus qui pilote l'écran, les boutons et l'alimentation. Comme ça, même quand le Linux est éteint, l'appareil reste vivant et vous pouvez toujours gérer le boot et l'affichage sans réveiller le monstre.

Mais le vrai sujet de cette annonce, ce n'est pas la fiche technique. C'est l'ouverture du bestiau car le Flipper One vise un noyau Linux pur, celui de kernel.org, sans patch vendeur, ni blob binaire ou autres drivers proprio. C'est un truc de puriste qui va faire plaisir à tous les barbus !

Parce que oui, chez Flipper Devices, ils en ont marre des fabricants ARM qui balancent leurs « board support packages » crades que personne ne comprend, comme le fait Raspberry Pi au passage. Alors pour y arriver, ils bossent à fond avec Collabora afin de pousser le support du RK3576 directement dans le kernel officiel.

Et c'est là qu'arrive le « we need your help » car plutôt que de bidouiller dans leur coin, ils ouvrent d'un coup tout le processus de développement dès le premier jour. Leurs trackers de tâches, leurs débats d'architecture, leurs docs à moitié finies, bref tout le bazar que les boîtes planquent d'habitude, bah eux, ils le mettent à dispo ! Et c'est pour cela qu'ils cherchent des gens pour le support du kernel, pour tester le Wi-Fi en audit et injection, pour trancher le choix du bureau (KDE Plasma ou un gestionnaire en tiling plus léger ?), et même pour entraîner un petit modèle d'IA maison.

Et au-dessus de tout ça, ils préparent leur Flipper OS, une couche sur du Debian qui introduit une notion de « profils » qui n'est ni plus ni moins qu'un instantané complet du système avec ses paquets préconfigurés. Vous bootez dessus, vous le clonez, vous le cassez, et hop vous revenez à une copie propre sans tout reflasher.

Ils bossent aussi sur FlipCTL, un framework pour habiller les utilitaires Linux en menus sur petit écran, avec comme objectif de le rendre installable d'un simple apt install ailleurs que sur leur produit.

Après, j'espère que ça va bien se passer pour eux car malgré leur succès, Flipper Devices traîne un passif chargé. Le Flipper Zero s'est écoulé à plus d'un million d'exemplaires, mais il a été viré d'Amazon en 2023, étiqueté « appareil de skimming », puis carrément banni au Canada début 2024 sous prétexte qu'il servait à voler des voitures.

C'était d'ailleurs des accusations bidons vu que le bestiau dans sa forme de base est incapable de mener les attaques par relais qu'on utilise en général pour voler des voitures. Heureusement pour eux, la justice canadienne a fini par reculer, mais bon, leur réputation grand public est faite malheureusement.

L'autre point qui va vous calmer, c'est que vous ne pourrez pas encore l'acheter... Le moyen le plus rapide sera de lâcher 350 $ dans leur prochaine campagne Kickstarter prévue cette année. Et encore, le projet pourrait ne jamais sortir...

Voilà, du coup, si l'idée d'un Linux de poche sans compromis vous parle, le mieux pour aider, c'est peut-être d'aller mettre les mains dans le cambouis sur leur portail dev.

Perso, un cyberdeck ouvert jusqu'au noyau, moi ça me plait bien. Le Flipper Zero, ça m'a jamais convaincu mais ce Flipper One, déjà pour moi, il est beaucoup plus convaincant... On verra s'ils tiennent la distance maintenant. Et si vous voulez creuser le genre, jetez un œil à ce cyberdeck fait maison , au WiFi Pineapple côté audit sans fil, et à Intercept pour l'analyse radio.

À suivre de très près !

Une faille planquée pendant 9 ans dans le noyau Linux, voilà ce que les chercheurs de Qualys viennent de déterrer. Son petit nom, c'est ssh-keysign-pwn ou DirtyDecrypt (CVE-2026-46333 pour les intimes), et elle permet à n'importe quel utilisateur local sans privilèges de passer root, de lire votre /etc/shadow et de piquer les clés SSH privées de votre serveur.

Et ce bug dormait là depuis novembre 2016, c'est-à-dire depuis la version 4.10 du kernel. Personne ne l'avait jamais vu et autant vous dire que 9 ans, en cybersécu, c'est une éternité !!

Le truc se cache dans une fonction au nom barbare, __ptrace_may_access(). En gros, quand un processus privilégié abandonne ses droits, y'a une micro-fenêtre, le temps d'un battement de cils, où il reste "accrochable" via ptrace. Vous combinez ça avec l'appel système pidfd_getfd() et hop, vous récupérez les fichiers ouverts d'un process root.

Et l'exploit disponible vise des binaires SUID que tout le monde a sur sa machine, genre ssh-keysign, chage, pkexec ou accounts-daemon.

Du coup, première chose à faire : vous mettez à jour, genre rapidos ! Linus Torvalds a poussé le correctif et si vous ne pouvez pas patcher tout de suite, faut taper la commande sysctl -w kernel.yama.ptrace_scope=2 qui a pour effet de refermer la porte en attendant.

Niveau distros, ça touche à peu près tout le monde, d'Ubuntu 14.04 jusqu'à la 26.04, en passant par Debian, Fedora et toute la famille Red Hat.

Et le plus gênant, c'est que ssh-keysign-pwn, c'est la 4e faille kernel en moins de trois semaines. On a eu CopyFail , Dirty Frag début mai, puis Fragnesia juste après, et maintenant celle-ci. Aïe aïe aïe ! Je commence à me lasser, sérieux ^^.

Le noyau Linux prend cher en ce moment et comme les exploits fonctionnels sont déjà publics, le compte à rebours est lancé pour tous ceux qui traînent !

Alors après tout le monde va vous parler des cybercriminels et des serveurs compromis, et c'est vrai, faut patcher. Mais pour moi, ce genre de faille, c'est aussi une clé qui sert aux bidouilleurs pour reprendre la main sur leur propre matériel. Votre routeur verrouillé, votre objet connecté que le fabricant a laissé tomber depuis quelques années, ce bon vieux NAS dont plus personne ne livre de firmware... une faille comme ça, c'est parfois le seul moyen de le faire revivre !

Bref, faites vos mises à jour. Et gardez en tête que ces mêmes failles qui font flipper les sysadmins, ce sont aussi celles qui redonnent vie au matos verrouillé qui n'avait pas d'autre avenir que de finir à la déchetterie.

Source

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

Faire tourner les logiciels Adobe sous Linux, c'est la quête éternelle des photographes et graphistes qui voudraient bien quitter Windows ou macOS mais qui n'ont rien de comparable côté Linux.

Adobe n'a jamais voulu porter sa suite officiellement. Du coup, depuis des années, des développeurs tentent de la faire fonctionner via Wine, le logiciel libre qui sait exécuter des programmes Windows sur Linux. Avec un succès souvent partiel, et beaucoup de bidouille manuelle.

Un développeur connu sous le pseudo sander110419 vient de publier une recette reproductible pour faire fonctionner Adobe Lightroom CC sur Linux. Pas Lightroom Classic, attention, mais bien la version Creative Cloud avec la synchronisation, qui dépend de plus de composants Windows.

Tout est documenté sur GitHub, avec les scripts, les DLL patchées et le mode d'emploi. La particularité, c'est qui a fait le travail. Le développeur a simplement donné une consigne à Claude Code, l'assistant de programmation d'Anthropic en ligne de commande, et il a regardé l'IA bosser.

La consigne tenait en une phrase : faire tourner Lightroom CC sur Linux, puis publier une recette reproductible. Et Claude Opus 4.7, le modèle utilisé, a tout fait en autonomie. Il a identifié les composants Windows manquants, écrit des stubs, des fausses DLL qui simulent le comportement attendu, patché celles qui posaient problème, testé le tout sous Wine 11.8 staging, puis rédigé le README et la documentation. L'humain a juste validé derrière.

Côté résultat, ça marche raisonnablement bien sur la dernière version testée (Lightroom CC 9.3.1). La synchronisation cloud fonctionne, l'interface répond, les fonctions de base sont là. Quelques boîtes de dialogue plantent encore, et certaines fonctions accélérées par la carte graphique ne sont pas complètement opérationnelles. Mais on est sur un usage réel possible, ce qui n'avait jamais été le cas auparavant pour cette version.

Au passage, c'est un cas d'école intéressant pour ceux qui suivent l'évolution des assistants IA. La tâche est typiquement le genre de travail que personne n'a vraiment envie de faire : ingrat, plein de tâtonnements, qui demande de lire de la doc obscure et de tester en boucle. Et c'est précisément le terrain où une IA en mode agentique tient le mieux la route aujourd'hui.

Source : Phoronix

Sur Linux, certains utilisateurs passent des heures à customiser leur bureau pour le rendre joli. Cette pratique a même un nom dans la communauté : le "ricing", de l'anglais "to rice", qui veut dire bichonner sa machine comme on bichonnerait une voiture tunée.

Un utilisateur vient de publier un projet baptisé "Waylandcraft" qui pousse le concept assez loin : tout son bureau ressemble à l'intérieur du jeu Minecraft, le célèbre bac à sable où l'on construit avec des blocs cubiques.

Pour comprendre la blague du nom, il faut savoir que la majorité des Linux modernes utilisent un environnement graphique appelé GNOME, c'est-à-dire la couche qui dessine les fenêtres, les menus et le bureau (l'équivalent visuel de Windows ou macOS). Cet environnement tourne par-dessus un système d'affichage techniquement nommé Wayland, le successeur récent du très vieux Xorg. Le créateur a donc fusionné "Wayland" et "Minecraft" pour donner "Waylandcraft", et le nom n'aurait pas eu de sens il y a encore deux ans.

Visuellement, le thème reprend tous les codes du jeu : icônes en cubes texturés style terre et bois, fond d'écran avec un paysage de plaine herbeuse, police pixelisée façon Minecraft, et même les boutons et menus qui ressemblent à des inventaires de joueur. C'est du travail de précision, chaque détail a été retravaillé pour coller à l'esthétique du jeu de Mojang.

Le projet a immédiatement explosé les échanges autour de son intérêt dans la communauté. C'est typiquement le genre de truc qui finit publié en libre accès, avec une notice détaillant chaque thème, chaque police, chaque petit script utilisé pour arriver au résultat. Et si vous voulez vous lancer dans la customisation Linux, sachez que ça peut vite devenir un loisir chronophage. Très chronophage.

Source : Reddit

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

Vous ne le savez peut-être pas mais votre serveur Linux embarque plusieurs milliers de modules kernel et pourtant, il n'en utilise que quelques centaines à peine. Tout le reste ça prend la poussière et ça peut vous exposer à des problèmes de sécurité. Hé bien c'est exactement à ces modules inutiles que Jasper Nuyens, le fondateur de Linux Belgium, vient s'attaquer avec son outil ModuleJail .

Ce script lit /proc/modules pour savoir ce qui tourne vraiment sur votre machine, et considère ensuite cet ensemble comme étant intouchable. Par contre, pour tout le reste il ajoute une ligne install <module> /bin/true dans /etc/modprobe.d/modulejail-blacklist.conf.

Comme ça si un jour quelque chose essaie de charger un de ces modules endormis, c'est modprobe qui exécutera /bin/true à la place... et il ne se passe rien !!

C'est malin, hein ? Vous pouvez installer ModuleJail via le script dispo sur la page Github ou grâce aux paquets .deb et .rpm si vous préférez. Et ensuite, pour vérifier que c'est bien en place, un petit modprobe -n -v module_banni devrait vous répondre install /bin/true.

En tout cas, je trouve que ModuleJail tombe très bien parce que la chasse aux failles kernel est clairement en train de changer d'échelle. Je pense notamment à tous ces outils de scan assistés par IA qui débusquent à la chaine des bugs d'élévation de privilèges planqués dans le code depuis des années.

Le script propose 3 profils via le flag -p, minimal pour le strict nécessaire, conservative par défaut (serveur classique plus drivers VM courants) et desktop qui garde WiFi, Bluetooth, audio et vidéo. Vous pouvez aussi ajouter votre propre whitelist.

Et la règle d'or non négociable, c'est de le lancer quand la machine est dans un état stable, avec tous les services démarrés, et tous les disques montés. Car oui, ModuleJail ne devine rien, mais se contente de photographier ce qui tourne à l'instant T. Donc sur un système à moitié démarré, ce serait un peu couillon qu'il bannisse un module dont vous aurez besoin plus tard.

Après pour tout ce qui est compilé en dur dans le kernel (le fameux =y de la config) ça reste là, donc une faille dans le cœur du noyau façon Dirty Cow , ça n'y changera rien du tout. Et si vous branchez une webcam six mois après, son module sera déjà banni donc faudra pas oublier de retirer sa ligne du fichier ou relancer le script avec une whitelist, car un simple modprobe ne suffira pas !

Donc c'est pas forcement le pied pour un Linux Desktop mais pour un parc de serveurs en prod qui ne bougent pas, c'est une petite couche de sécurité en plus.

Source

Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment... Le chercheur William Bowling de l'équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d'obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.

Et la mauvaise nouvelle, en fait, c'est que Fragnesia tape dans la même surface d'attaque que Dirty Frag , mais via un bug logique différent qui n'est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !

La lignée "Dirty" continue donc tout simplement de s'allonger... Dirty COW en 2016, Dirty Pipe en 2022, Copy Fail le 1er mai 2026, Dirty Frag le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c'est un record je crois !

Alors comment ça marche ?

Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C'est le truc qu'on utilise pour faire du VPN d'entreprise et l'attaque détourne le moteur de chiffrement pour qu'il écrive là où il ne devrait surtout pas écrire.

Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel "tiens, chiffre-moi tout ça en IPsec". Le kernel obéit gentiment, sauf qu'au lieu d'envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l'attaquant. Suffit ensuite de taper su pour devenir root.

Et là c'est le drame !

Le pire, c'est qu'il n'y a aucun "tirage au sort" dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l'époque de Dirty COW. Là, c'est 100% reproductible à chaque exécution, ça marche du premier coup.

La cause profonde, c'est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d'un fichier qu'un autre process est en train de lire). Bowling appelle ça la "famille Dirty Frag" parce que c'est exactement le même genre d'amnésie qui avait permis Dirty Frag la semaine dernière.

Et le patch du 8 mai n'a pas suffi parce qu'il a juste rebouché un trou particulier, sans toucher à la fonction d'origine. D'où la sortie immédiate du PoC le 14 mai, parce qu'autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d'Internet.

Testez sur votre Linux

Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c'est simple :

git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/fragnesia/fragnesia-1.mp4">lien vers la vidéo</a>.

echo 3 > /proc/sys/vm/drop_caches

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.

ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.

La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.

C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.

Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.

Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.

Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.

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

• lien nᵒ 1 : Lien de l'épisode
• lien nᵒ 2 : Soutenir le podcast
• lien nᵒ 3 : La traduction en anglais de l'épisode
• lien nᵒ 4 : Le site de Mobian

Commentaires : voir le flux Atom ouvrir dans le navigateur

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

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 !

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

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.

Source : Phoronix

• lien nᵒ 1 : Site Officiel
• lien nᵒ 2 : Code Source (GitHub)
• lien nᵒ 3 : Documentation JemaOS

Commentaires : voir le flux Atom ouvrir dans le navigateur

2>&1, >, >>, 2>/dev/null... Si ces symboles dans votre terminal Linux ou macOS vous font autant flipper qu'un regex, respirez un grand coup ! Quand vous aurez lu cet article, vous verrez qu'en fait c'est super simple à comprendre, et en 5 minutes vous saurez enfin ce que vous copiez-collez depuis des années depuis StackOverflow.

En fait, dans les shells Unix (bash, zsh, etc.), y'a 3 canaux de base : stdin (entrée, numéro 0), stdout (sortie normale, numéro 1) et stderr (les erreurs, numéro 2). Tout le reste, de > à 2>/dev/null, découle de ces 3 numéros.

> - Écrire dans un fichier (et tout écraser)

echo "Salut" > fichier.txt

echo "Ligne 2" >> fichier.txt

commande_foireuse 2> erreurs.log

commande > output.log 2>&1

commande &> output.log

find / -name "*.conf" 2>/dev/null

Vous trouvez que votre Linux met 3 plombes à démarrer et vous regardez l'écran de boot défiler en vous demandant ce qui peut bien prendre autant de temps ?

Hé bien bonne nouvelle los amigos del manchos, si vous utilisez une distribution basée sur systemd (comme Debian, Ubuntu, Fedora, Arch, et compagnie), il existe un outil natif déjà installé qui permet de diagnostiquer tout ça : systemd-analyze

Ce truc c'est un peu le médecin légiste de votre démarrage système. Il dissèque chaque étape, identifie les unités qui traînent la patte, et vous permet de comprendre où part votre précieux temps. Pour ceux qui débarquent, systemd est le système d'initialisation adopté par la plupart des distributions modernes, et il permet justement de lancer plein de trucs en parallèle pour gagner du temps.

Pour commencer, la commande de base c'est tout simplement :

systemd-analyze time

systemd-analyze blame

systemd-analyze critical-chain

systemd-analyze plot > boot.svg

sudo systemctl disable nom-du-service

systemctl list-dependencies nom-du-service

systemd-analyze verify /chemin/vers/unite.service

Aujourd'hui, on va aller un peu plus loin que les simples bidouilles habituelles car je vais vous présenter Reinstall , un outil qui va peut-être vous changer la vie si vous gérez des serveurs distants.

Vous connaissez la chanson... vous avez un VPS sous Debian et vous voulez passer sous Arch pour faire votre malin. Sauf que pour opérer ce changement, c'est la galère assurée !! Faut passer par l'interface web de l'hébergeur, booter sur une ISO via une console VNC qui rame sa maman, et prier pour que le réseau revienne après le reboot.

Eh bien ça c'est terminé grâce à ce script Reinstall. Vous lui balancez une commande, le script s'occupe de tout, et hop, votre serveur redémarre sur le nouvel OS de votre choix. Pas besoin d'accès IPMI, pas besoin de supplier le support technique, ça marche tout seul.

Et ça supporte pas mal d'OS... Côté Linux, y'a 19 distributions majeures : Alpine, Debian (de 9 à 13), Ubuntu (de 16.04 à 25.10), toute la famille Red Hat (AlmaLinux, Rocky, Oracle), Fedora, Arch, Gentoo, NixOS... Bref, y'a tout ce qu'il faut.

Et le truc qui va plaire à ceux qui font du cloud, c'est également le support de Windows. En effet, le script permet d'installer Windows Vista, 7, 8.1, 10, 11 et même Windows Server 2025.

Et rassurez-vous, il n'utilise pas des images bricolées par on ne sait qui, mais les ISO officielles de chez Microsoft. Lui se content d'injecter automatiquement les drivers VirtIO pour que ça tourne comme un charme sur n'importe quel cloud (AWS, GCP, Oracle Cloud...).

Aussi, le point le plus chiant quand on réinstalle un serveur distant, c'est la config réseau. Si on se loupe, on perd l'accès SSH et c'est fini. Reinstall gère ça intelligemment puisqu'il détecte votre IP (statique ou dynamique), gère l'IPv6, les passerelles exotiques et même les serveurs ARM.

Ce qu'il vous faut avant de tout casser

• RAM : 256 Mo pour Alpine/Debian, 1 Go pour Windows.
• Disque : 1 Go pour Linux, 25 Go minimum pour Windows.
• Accès : Un accès root/admin sur la machine actuelle.
• Temps estimé : Environ 5 à 15 minutes selon la vitesse de connexion de votre serveur.

Un petit avertissement quand même... Ce script ne gère pas les conteneurs type OpenVZ ou LXC. Faut que ce soit une vraie VM (KVM, VMware, Hyper-V) ou un serveur bare-metal.

Le tuto ! Le tuto !

C'est là que ça devient drôle. Pour installer un nouveau Linux (disons Debian 13) depuis votre système actuel, il suffit de faire un petit :

# Télécharger le script
curl -O https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh

# Lancer la réinstallation
bash reinstall.sh debian 13 --password "VotreMotDePasse"

bash reinstall.sh windows --image-name "Windows 11 Enterprise LTSC 2024" --lang fr-fr

Vous utilisez WSL sous Windows mais vous en avez marre de devoir jongler avec les commandes PowerShell dès qu'il s'agit de gérer vos distributions ?

C'est vrai que taper du wsl --import ou du wsl --unregister à chaque fois qu'on veut tester une nouvelle instance, ça finit par être un peu lourd.

Heureusement, y’a un dev, Eric Trenkel (alias bostrot), qui a eu la bonne idée de sortir WSL Manager (qu'on connaissait aussi sous le nom de WSL2 Distro Manager), une interface graphique complète pour piloter tout ça sans se faire mal au terminal.

Cette application, développée avec Flutter offre une vue d'ensemble sur toutes vos instances WSL installées. Ainsi, en un clic, vous pouvez les démarrer, les arrêter, les renommer ou même changer leur version.

Mais là où l'outil excelle, c'est dans sa capacité à importer de nouveaux environnements. Pour ceux qui se demandent comment ça se passe pour récupérer des distributions exotiques, sachez que WSL Manager permet de télécharger et d'utiliser n'importe quelle image Docker comme base pour une instance WSL, et ce, sans même avoir besoin d'installer Docker Desktop sur votre machine.

Par exemple si vous voulez un Alpine minimaliste pour du test ou un Kali pour du pentest, vous l'importez direct depuis les registres Docker et hop, vous avez un nouveau système prêt à l'emploi.

C'est d'ailleurs un excellent complément à des outils comme DockStation si vous voulez garder une approche visuelle de vos conteneurs, ou même WinBoat pour faire tourner du Windows dans Docker. L'application propose aussi des "Quick Actions", qui sont en gros des petits scripts prédéfinis que vous pouvez exécuter directement sur vos instances pour automatiser les tâches répétitives. Vous pouvez également lancer directement Windows Terminal ou VS Code dans la distribution de votre choix en un seul clic.

Si ça vous branche, plusieurs options s'offrent à vous pour l'installer. Comme le projet est open source sous licence GPL-3.0, vous pouvez récupérer les exécutables gratuitement sur la page GitHub du projet.

Il existe aussi une version sur le Microsoft Store et notez aussi que bien que des paquets winget ou Chocolatey existent, ils sont souvent maintenus par la communauté et pas forcément à jour, donc privilégiez le téléchargement direct ou le Store pour être tranquille.

Voilà, si vous passez vos journées sous Linux tout en restant dans l'écosystème Microsoft, WSL Manager c'est le feu et ça permet de se concentrer sur son boulot plutôt que sur la syntaxe des commandes de gestion système.

Merci à Lorenper pour la découverte !

• lien nᵒ 1 : Documentation
• lien nᵒ 2 : Site officiel
• lien nᵒ 3 : Vidéos de présentation

sudo apt install podman

sudo useradd --base-dir /srv \
--create-home \
--shell /bin/bash \
--user-group \
meshcentral

sudo loginctl enable-linger meshcentral

sudo --login --user meshcentral

# On se base sur Debian Trixie en version slim
FROM docker.io/library/debian:trixie-slim

# On définit que la version « latest » de MeshCentral sera installée par défaut
ARG MESHCENTRAL_VERSION="latest"

# On fait les mises à jour, on installe les logiciels nécessaires, puis on
# supprime le cache des paquets
RUN apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get full-upgrade --assume-yes \
&& DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends --assume-yes nodejs npm tini \
&& rm -r /var/cache/apt/*
# On crée un utilisateur dédié pour lancer le service
RUN useradd --shell /usr/sbin/nologin --user-group --create-home meshcentral
# On utilise ce nouvel utilisateur
USER meshcentral
# On se place dans le bon répertoire
WORKDIR /home/meshcentral
# On installe les dépendances de MeshCentral dans ce répertoire
RUN npm install meshcentral@${MESHCENTRAL_VERSION}
# On définit la variable d’environnement conseillée pour faire tourner node
# en production
ENV NODE_ENV=production
# On lance tini pour qu’il prenne en charge et relaie SIGTERM
ENTRYPOINT ["tini","--"]
# Et finalement on lance meshcentral
CMD ["node","./node_modules/meshcentral"]

podman image build --build-arg MESHCENTRAL_VERSION=1.1.55 --tag meshcentral:1.1.55.

podman volume create meshcentral-files # pour les fichiers qu’on veut transmettre depuis ou vers les clients
podman volume create meshcentral-data # pour la configuration, les certificats, etc.

podman run --rm \
--volume=meshcentral-data:/home/meshcentral/meshcentral-data \
--volume=meshcentral-files:/home/meshcentral/meshcentral-files \
--publish 1025:1025/tcp \
--hostname meshcentral \
--name meshcentral \
localhost/meshcentral:1.1.55

sudo apt install certbot

sudo certbot certonly --standalone --domain aide.domain.example --dry-run --test-cert

sudo certbot certonly --test-cert \
--key-type rsa \
--standalone \
--domain aide.domain.example \
--deploy-hook 'install --verbose --owner=232071 --group=232071 --mode=644 /etc/letsencrypt/live/aide.domain.example/fullchain.pem /srv/meshcentral/.local/share/containers/storage/volumes/meshcentral-data/_data/webserver-cert-public.crt; install --verbose --owner=232071 --group=232071 --mode=600 /etc/letsencrypt/live/aide.domain.example/privkey.pem /srv/meshcentral/.local/share/containers/storage/volumes/meshcentral-data/_data/webserver-cert-private.key'

sudo systemctl disable certbot.timer

mkdir --parents ~/.config/containers/systemd/

[Unit]
Description=Meshcentral in a Podman container
# C’est déjà une dépendance implicite, mais je la mets pour que ce soit explicite
After=networking.target

[Container]
Image=localhost/meshcentral:1.1.55
ContainerName=meshcentral
HostName=meshcentral
PublishPort=1025:1025
Volume=meshcentral-files:/home/meshcentral/meshcentral-files
Volume=meshcentral-data:/home/meshcentral/meshcentral-data
# Je ne sais pas si c’est c’est vraiment utile mais ça ne coûte rien
DropCapability=all

systemctl --user daemon-reload

systemctl --user start meshcentral.service

cd /tmp/ && wget -O meshagent « https://aide.domain.example:1025/meshagents?id=pYWSORfgTMN%2IdKohzytKQePtv8DzNzbTZcqB2m%24h7MuA4bzXSWJRt6vLN9VBILW&installflags=1&meshinstall=6 » && chmod +x meshagent &&./meshagent

# on enregistre comment accéder à dbus (nécessaire pour dconf et systemctl
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/"$(id --user)"/bus
# on désactive l’accès RDP qui est activé par défaut
dconf write /org/gnome/desktop/remote-desktop/rdp/enable false
# on active l’accès VNC qui est désactivé par défaut
dconf write /org/gnome/desktop/remote-desktop/vnc/enable true
# on démarre le service utilisateur de partage du bureau
systemctl --user start gnome-remote-desktop.service

Commentaires : voir le flux Atom ouvrir dans le navigateur

Bon, les amis linuxiens (et ceux qui n'ont pas encore sauté le pas), asseyez-vous confortablement sur votre tabouret parce que Wine 11.0 vient de pointer le bout de son nez et c'est du lourd. Si vous pensiez que le projet s'essoufflait, détrompez-vous puisque après un un an de boulot, plus de 6 000 changements et 600 bugs corrigés, c'est pas juste une petite mise à jour de routine, c'est une sacrée étape !

Je commence direct, le gros morceau qui va faire plaisir aux gamers, c'est l'intégration de NTSYNC. Pour faire simple, c'est un module noyau Linux (qui devrait arriver avec le noyau 6.14) qui permet de gérer la synchronisation entre les processus de façon beaucoup plus efficace. Concrètement, ça veut dire que les jeux Windows qui tournent sur Linux vont arrêter de galérer sur les accès concurrents et gagner en fluidité. On est sur du gain de performance pur et dur.

L'autre révolution sous le capot, c'est la finalisation de l'architecture WoW64. Si vous vous souvenez, on en parlait déjà dans les versions précédentes comme d'une expérimentation, mais là c'est bon, c'est prêt. Ça permet de faire tourner des applications 32 bits (et même du 16 bits pour les nostalgiques) dans des préfixes 64 bits de manière totalement propre. Adieu le binaire wine64 séparé, maintenant on a un seul exécutable unifié qui gère tout. C'est plus propre, plus stable et ça simplifie vachement la vie.

Côté graphisme, Wine 11.0 passe à Vulkan 1.4.335 et apporte enfin le décodage matériel H.264 via les API Direct3D 11 sur Vulkan Video. En gros, vos vidéos et vos jeux vont moins pomper sur le CPU. Le pilote Wayland continue aussi de s'améliorer avec une meilleure gestion du presse-papier et des méthodes de saisie.

On sent que le futur sans X11 approche à grands pas...

Et pour ceux qui aiment brancher tout et n'importe quoi sur leur bécane, il y a du nouveau côté Bluetooth. On a maintenant un support initial pour le scan des appareils, la découverte et même l'appairage basique sur Linux via BlueZ. C'est encore le début, mais pouvoir connecter sa manette ou son casque sans bidouiller pendant trois heures, c'est ça l'objectif. Les joysticks et les volants à retour de force ont aussi eu droit à leur petit coup de polish pour une meilleure précision.

Ça me rappelle forcément la sortie de Wine 10.0 l'année dernière qui avait déjà posé de grosses bases, sans oublier que Win32 est devenu la couche de compatibilité la plus stable sur Linux !

On notera aussi que le support de TWAIN 2.0 pour le scan 64 bits est de la partie, tout comme des améliorations sur MSHTML pour le rendu web et même le support de Ping pour l'ICMPv6. Bref, c'est une version hyper complète qui prouve une fois de plus que le pont entre Windows et Linux est de plus en plus solide.

Voilà, si vous voulez tester tout ça, c'est dispo dès maintenant sur le site officiel. Comme d'hab, il faudra peut-être attendre quelques jours pour que ça arrive dans les dépôts de votre distrib préférée, mais ça vaut le coup d'œil.

Source

• lien nᵒ 1 : April
• lien nᵒ 2 : Revue de presse de l'April
• lien nᵒ 3 : Revue de presse n°50 de l'année précédente
• lien nᵒ 4 : 🕸 Fils du Net

Commentaires : voir le flux Atom ouvrir dans le navigateur

Bon, si vous êtes un vieux de la vieille sous Linux, j'ai une nouvelle qui va vous faire verser une petite larme ! GNOME et Firefox envisagent tous les deux de désactiver la possibilité de coller avec le clic milieu par défaut. Vous savez, ce truc où vous sélectionnez du texte, puis un coup de clic molette et hop, c'est collé ailleurs sans passer par Ctrl+C/Ctrl+V.

Jordan Petridis, développeur chez GNOME, vient de soumettre une merge request pour désactiver cette fonctionnalité dans les paramètres par défaut. D'après lui ce serait un véritable désastre... Des mots forts pour une fonctionnalité que beaucoup adorent mais faut dire que le mec n'a pas tort car avec les trackpads modernes et les souris à molette cliquable un peu sensibles, on finit souvent par coller des trucs sans faire exprès.

Du coup, c'est quoi exactement ce "primary paste" ? Hé bien c'est une spécificité historique de X11, le système de fenêtrage qui fait tourner les bureaux Linux depuis des lustres. Quand vous sélectionnez du texte, il est automatiquement copié dans un buffer séparé (le "PRIMARY selection"), différent du presse-papier classique . Et le clic du milieu colle ce buffer directement. C'est comme avoir deux presse-papiers en parallèle, c'est pratique mais ça peut foutre le bordel si vous cliquez au mauvais moment.

Et Firefox n'est pas en reste puisqu'une révision chez Mozilla propose exactement la même chose à savoir désactiver le collage au clic molette par défaut. Les arguments sont similaires... surtout que les utilisateurs qui découvrent cette fonctionnalité par accident (coucou les Windowsiens) ne comprennent pas d'où sort le texte qui vient de s'afficher dans leur barre de recherche. Perso, j'avoue que ça m'est arrivé de coller des trucs gênants dans un chat parce que j'avais cliqué sur la molette sans faire gaffe ^^.

La bonne nouvelle, c'est que ça reste réactivable pour ceux qui y tiennent. Sous GNOME, il suffira de taper :

gsettings set org.gnome.desktop.interface gtk-enable-primary-paste true

Ceux qui ont déjà essayé de faire de la musique sous Linux savent de quoi je parle. Configurer JACK, gérer les latences ALSA, prier pour que le plugin VST fonctionne... C'était un peu l'enfer, non ? Perso, j'ai abandonné plusieurs fois avant que PipeWire vienne tout simplifier.

Du coup, quand je suis tombé sur LinuxDAW.org , j'ai eu un petit moment d'émotion. C'est un catalogue visuel et bien foutu qui répertorie plein de plugins audio disponibles sous Linux : VST2, VST3, CLAP, LV2, standalone, et même des modules VCV Rack. Le site a été créé par fractalf (le code est sur Codeberg ) qui explique l'avoir créé simplement parce qu'aucun des sites existants ne répondait vraiment à ses besoins quand il a switché vers Linux.

Et ce qui me plaît ici, c'est que ce n'est pas un site puriste open source. Y'a du FOSS bien sûr (et un filtre dédié pour les trouver), mais aussi les plugins commerciaux de u-he, Toneboosters, Kazrog et compagnie. Parce que oui, de plus en plus d'éditeurs supportent Linux nativement maintenant.

Après c'est vrai qu'en cochant le filtre FOSS, on voit nettement la différence de qualité d'interface avec les plugins payants. Vous le savez car je m'en plains souvent, mais niveau design, les projets libres ont encore du chemin à faire... Mais bon, ça reste fonctionnel et gratuit, donc on va pas cracher dessus.

Bref, si vous êtes musicien et que vous envisagez de passer sous Linux (ou si vous y êtes déjà et que vous cherchez des outils), LinuxDAW.org c'est exactement ce qu'il vous faut. Y'a plus quà digger tout ça ! Et si ça vous amusez, vous pouvez même contribuer en ajoutant des plugins qui manqueraient au catalogue.

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 vous rappelez de votre PlayStation 2, cette bonne vieille console qui a bercé les années 2000 avec ses GTA, ses Final Fantasy et ses Pro Evolution Soccer ? Et bien figurez-vous que Sony avait sorti à l'époque un kit officiel pour transformer la machine en PC sous Linux. D'abord au Japon en 2001, puis aux États-Unis en 2002. Oui, officiellement, fait par Sony.

C'était complètement dingue quand on y pense !

Le kit PS2 Linux (compatible uniquement avec les modèles "fat" avec baie d'extension) comprenait tout un attirail de ouf : un disque dur IDE de 40 Go, un adaptateur réseau (qui faisait aussi office d'interface IDE), un adaptateur VGA pour brancher la console sur un moniteur compatible (sync-on-green requis), une carte mémoire de 8 Mo (requise mais non incluse), et même un clavier et une souris USB aux couleurs de la PlayStation. Sony avait vraiment mis le paquet sur la qualité de ces périphériques, avec un clavier qui avait un toucher plutôt agréable pour l'époque.

Côté électronique, la PS2 embarquait un processeur MIPS R5900 (le fameux Emotion Engine) et le système tournait sur un kernel Linux 2.2.1 basé sur Kondara MNU/Linux (une distro japonaise dérivée de Red Hat). Par contre, avec seulement 32 Mo de RAM, fallait pas s'attendre à des miracles. Le système incluait quand même l'environnement de bureau Window Maker, un gestionnaire de fenêtres old school mais terriblement classe avec son petit pingouin.

Vous avez un Steam Deck, un Lenovo Legion Go ou un ROG Ally qui traîne dans un coin parce que pas le temps de jouer, vous avez trop de boulot... Je connais bien vous inquiétez pas.

Mais si je vous disais que ce petit truc qui prend la poussière peut devenir votre meilleur allié pour les audits de sécurité discrets ?

Mais siii ! J'vous jure !

C'est en tout cas ce que propose Balor , un framework offensif fraîchement sorti et développé par Jean-Claude Charrier , qui grâce à ça peut d'un coup, transformer votre console gaming en une station de pentest portable.

Son concept est parti d'un constat simple... Quand vous débarquez en mission de pentest avec un cahier des charges qui exige de la discrétion, sortir un WiFi Pineapple c'est un peu comme débarquer en costard dans un festival de métal. Ça se voit !! Mais avec une console portable gaming par contre, vous avez juste l'air d'un type qui fait une pause entre deux réunions.

Ni vu ni connu, j't'embrouille !

Balor tourne sous CachyOS et Arch Linux, s'installe en une dizaine de minutes et embarque pas moins de 8 stacks pour environ 130 options au total. Côté WiFi, vous avez aircrack-ng, wifite, bettercap et même des versions de Wifiphisher réécrites spécialement pour Python 3.13. Pour l'OSINT, c'est Maltego, theHarvester, Shodan et compagnie. Et y'a aussi du Metasploit, Burpsuite, Nmap, Masscan, SQLMap, Hashcat, John the Ripper... Bref, la totale.

Le truc sympa c'est que tout passe par un wrapper unique appelé "balorsh". Vous tapez balorsh wifi et hop, le menu WiFi apparaît ! Pareil pour balorsh llm qui lance un assistant IA local via Ollama avec des personas adaptés comme Red Team pour l'offensif, Blue Team pour le défensif, Purple Team pour mixer les deux...etc.

L'installation se fait via un script qui dépose tout dans /opt/balorsh/data/ et la désinstallation est tout aussi propre. En plus chaque stack est modulaire, donc si vous n'avez besoin que du cracking de mots de passe, vous installez juste cette partie. Pour les sysadmins qui voudraient comprendre les workflows pentest sans se taper toute la doc, c'est aussi un bon point d'entrée. Genre enchaîner theHarvester, amass, massdns et httprobe pour du recon, ça devient accessible même sans être certifié OSCP ^^.

Côté limitations, Balor reste exclusif à l'écosystème Arch/CachyOS mais rassurez-vous, un portage Debian est envisagé si la demande suit.

Perso je trouve l'approche vraiment bien trouvée et le fait que ce soit un projet français plutôt qu'une énième distro sécu américaine corporate, ça fait plaisir. Voilà, par contre comme d'hab, c'est un outil pour les audits autorisés uniquement avec contrat signé, et pas pour aller embêter le WiFi du voisin, hein ^^.

Alors déconnez pas !

Encore merci à Jean-Claude d'avoir partager sa création avec moi.

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

Vous avez un parc de Raspberry Pi à déployer et vous en avez marre de refaire la config à chaque fois ? Ou pire, votre carte SD commence à faire des siennes et vous voulez la sauver avant qu'elle rende l'âme ? Hé bien j'ai le combo parfait pour vous les amis !

Je vais vous parler en réalité de deux outils complémentaires que vous connaissez déjà je pense : ddrescue pour le clonage/sauvetage de cartes SD, et Raspberry Pi Imager pour créer des images préconfigurées. Ensemble, ils forment une chaîne de production quasi "industrielle" pour vos projets Pi. Ça va vous faire gagner un temps précieux mais aussi vous sécuriser car on sait à quel point les cartes SD c'est capricieux parfois sur les Rpi (surtout quand y'a des coupures de jus ^^).

Commençons donc par ddrescue qui est l'outil libre parfait pour cloner des disques, mais avec un truc en plus que dd n'a pas : la gestion des erreurs et la reprise. Son secret, c'est le mapfile, un fichier journal qui garde trace de tout ce qui a été copié, du coup, si votre clone plante en plein milieu (câble qui se débranche, coupure de courant, carte SD qui fait la gueule), vous relancez la même commande et ça reprend exactement où ça s'était arrêté. Sans ce fichier, par contre, c'est retour à la case départ... snif.

⚠️ Attention : la destination va être écrasée. Donc vérifiez 3 fois vos /dev/... avant d'appuyer sur Entrée. Et oui, l'option --force porte bien son nom puisqu'elle autorise l'écriture sur un disque brut, donc si vous vous trompez de cible, c'est le drame.

La commande de base, c'est ça :

sudo ddrescue --force /dev/sdX /dev/sdY rescue.map

Vous remplacez /dev/sdX par votre carte source et /dev/sdY par la destination et le fichier rescue.map, c'est votre filet de sécurité, donc gardez-le précieusement à côté de vos images.

Après si vous préférez cloner vers un fichier image plutôt que directement vers une autre carte, c'est quasi pareil :

sudo ddrescue /dev/sdX raspios.img rescue.map

Et pour les cartes un peu fatiguées avec des secteurs défectueux, y'a une astuce en deux passes. D'abord une passe rapide qui saute les erreurs (le but c'est de récupérer le max sans s'acharner tout de suite) :

sudo ddrescue -n /dev/sdX raspios.img rescue.map

Puis une deuxième passe qui insiste sur les zones problématiques :

sudo ddrescue -r3 /dev/sdX raspios.img rescue.map

Le -r3 dit à ddrescue de réessayer 3 fois sur chaque secteur récalcitrant par contre, évitez de mettre --no-split par défaut. Ça peut sembler logique ("ne coupe pas"), mais sur un support vraiment abîmé, laisser ddrescue découper et isoler les zones foireuses est souvent plus efficace.

Maintenant faut vérifier que tout s'est bien passé… alors oui, on peut faire des contrôles, mais il faut être clair, si vous comparez juste un bout, vous validez juste un bout. Par exemple cette commande compare seulement 1 Go, et pas toute la carte :

sudo cmp -n 1G /dev/sdX /dev/sdY

Donc si vous voulez comparer TOUT (et que ça ne vous dérange pas d'attendre ^^), vous pouvez comparer l'image et la carte clonée en faisant un hash sur la totalité. Par exemple, pour vérifier que l'image écrite sur la carte correspond bien à l'image d'origine :

sha256sum raspios.img
sudo ddrescue /dev/sdY - | sha256sum

Si les deux hashes sont identiques, là, on parle (beaucoup plus) sérieusement. Et si vous ne voulez pas streamer le disque, vous pouvez aussi faire un hash du périphérique directement (mais ça lit tout le disque, donc c'est long).

Vous l'aurez compris, ddrescue nous sert à cloner ou à sauver une carte existante, mais pour déployer proprement une image, on va maintenant utiliser le fameux Raspberry Pi Imager. Car oui, l'outil officiel de la fondation a une fonction que beaucoup de gens ne connaissent pas qui est la personnalisation avancée. Comme ça, avant de flasher votre carte, vous pouvez préconfigurer plein de trucs.

Par exemple, le hostname du Pi, genre pi-cuisine ou pi-garage, l'utilisateur et son mot de passe, le Wi-Fi avec SSID et mot de passe, le SSH activé avec mot de passe ou clé publique, le fuseau horaire et la config clavier. Et précision importante, Imager prépare tout ça pour que ce soit appliqué au premier boot (c'est injecté pour l'initialisation), ce qui revient au même pour vous, mais ça explique pourquoi c'est si pratique en mode headless.

Du coup, vous flashez la carte, vous la mettez dans le Pi, vous branchez l'alimentation, et souvent c'est accessible en SSH très vite :

ssh pi@pi-cuisine.local

C'est le mode headless parfait puisque ça vous évite d'avoir à brancher un écran + clavier + souris sur votre Rpi. Notez que l'extension en .local de mon exemple ci-dessus dépendra du mDNS (Bonjour / Avahi)... Sur certains réseaux (ou certains PC), ça pourra ne pas résoudre donc dans ce cas-là, vous passez par l'IP ou votre DNS/DHCP habituel.

Et maintenant, roulements de tambours, voici le workflow magique pour déployer un parc de Pi. Cela consiste tout simplement à configurer un Pi de référence avec tout ce qu'il vous faut dedans (paquets, services, configs...). Ensuite vous l'éteignez proprement, vous clonez sa carte avec ddrescue, et vous dupliquez cette image à volonté.

MAIS (et là c'est le point qui évite des sueurs froides), cloner une carte Linux telle quelle, ça clone aussi des identifiants qui devraient être uniques, typiquement :

• le machine-id
• les clés SSH hôte (host keys)

Donc si vous déployez 10 Pi clonés à l'identique, vous vous retrouvez avec 10 machines qui se présentent pareil, et côté SSH vous pouvez avoir des alertes cheloues (et côté admin, c'est pas propre).

La solution la plus simple c'est donc de préparer votre image "master" pour que chaque nouveau Pi régénère ça au premier démarrage. Sur votre Pi de référence (avant de cloner), vous pouvez faire :

sudo rm -f /etc/machine-id
sudo truncate -s 0 /etc/machine-id
sudo rm -f /etc/ssh/ssh_host_*

Comme ça, au prochain boot, le système régénère un machine-id propre, et OpenSSH régénère ses clés hôte. (Si jamais ça ne se régénère pas automatiquement sur votre variante d'OS, un redémarrage + réinstallation/relance SSH règle généralement le truc.)

Après ça, à chaque nouveau Pi, vous flashez l'image.

Maintenant si vous n'avez pas de parc à déployer, mais que vous voulez simplement personnaliser le hostname, le Wi-Fi, le user, etc., le plus simple ça reste donc de passer par Raspberry Pi Imager au moment du flash avec ses options avancées car si vous écrivez l'image avec dd/ddrescue directement sur la carte, Imager ne pourra évidemment pas appliquer ses paramètres.

Et SURTOUT, avant de lancer quoi que ce soit, pensez à identifier vos disques pour pas faire de bêtises (c'est une commande Linux, btw) :

lsblk -o NAME,SIZE,MODEL,MOUNTPOINT

Ah et désactivez aussi l'automontage sur votre machine, sinon vous allez avoir des soucis avec la destination qui se retrouvera occupée par l'OS.

Bref, avec ddrescue et Raspberry Pi Imager, vous avez maintenant de quoi cloner vos cartes SD beaucoup plus sereinement (et pas juste "les yeux fermés").

Enjoy !

Vous connaissez les cyberdecks ?

Non ?? Pourtant, je vous en ai parlé déjà. Ce sont des petits ordis portables custom qu'on voit par exemple dans les films cyberpunk, où genre, le mec sort son bouzin de sa poche et hop, il peut hacker le monde entier. HACK THE PLANET !! Oué Oué !

Et bien tenez-vous bien car le Hackberry Pi CM5 9900 , c'est exactement ça, mais en vrai !

Le Hackberry Pi c'est donc un projet DIY qui transforme un Raspberry Pi Compute Module 5 en plateforme de hacking portable, ce qui est parfait pour les pentesters, les gens de l'infosec, ou simplement les geeks qui veulent un Linux puissant dans un format ultra-compact.

Le châssis mesure 143,5 x 91,8 x 17,6 mm pour 306 grammes et vous avez une coque en aluminium sur le devant et le dos, avec une partie centrale imprimée en 3D. À l'intérieur, un écran tactile 720x720, un vrai clavier physique style BlackBerry 9900, et un Raspberry Pi CM5 avec un quad-core Cortex-A76 qui tourne à 2,4 GHz.

L'écran est carré, ce qui est un format assez inhabituel mais plutôt pratique quand vous bossez en terminal. Le clavier, c'est celui du BlackBerry 9900, donc un vrai clavier physique avec des touches qui cliquent, et si vous avez déjà tapé sur un clavier tactile pendant 3 heures d'affilée, vous comprendrez pourquoi c'est cool.

Côté connectique, vous avez aussi 2 ports USB 3.0, un HDMI pleine taille, un slot M.2 2242 pour un SSD NVME, un lecteur microSD, une batterie de 5 000 mAh, et même des enceintes stéréo intégrées. La batterie vous donnera environ 5 heures en veille et 3 ou 4 heures en utilisation active. Et une recharge complète se fera en 3 heures via USB-C.

Donc plutôt que d'utiliser votre ordi principal pour vos tests de sécu, vous pouvez monter un environnement dédié sur ce petit deck. Vous flashez Kali Linux sur le SSD NVME, vous ajoutez quelques dongles WiFi style ALFA Network AWUS036ACM, peut-être un adapteur Bluetooth, un hub USB, et hop, vous avez une plateforme de pentesting portable.

Le truc cool, c'est surtout que le projet est modulaire donc vous pouvez par exemple modifier l'antenne WiFi.. Les fichiers STL sont également dispo en ligne, donc si vous avez une imprimante 3D, vous pouvez vous imprimer un support d'antenne custom. Certains ont même ajouté des radios logicielles (SDR) pour jouer avec les fréquences radio.

Ensuite, l'installation est assez simple. Vous commencez par insérer le module CM5 dans son slot dédié, vous ajoutez le SSD NVME, vous imprimez éventuellement votre support d'antenne custom, vous flashez Raspbian sur une carte microSD pour le boot initial, puis vous installez Kali Linux sur le NVME, et vous configurez les options de boot pour démarrer directement depuis le SSD.

Si vous avez capté tout ce qui est écrit ci-dessus, ce sera simple oui. Sinon, faudra lire un peu de doc ^^.

Le système supporte aussi plusieurs OS : Kali pour le pentesting, Pi OS par défaut, Ubuntu, LineageOS (Android), Manjaro, TwisterOS, ou même ParrotOS. Et vous pouvez basculer entre les environnements selon ce que vous voulez faire.

Maintenant niveau prix, comptez environ 300-350 dollars pour le setup complet. Le châssis Hackberry Pi CM5 9900 coûte 168 dollars, le module Raspberry Pi CM5 Lite avec 16 Go de RAM tourne à 132 dollars, vous ajoutez un SSD NVME de 256 Go, la batterie 5 000 mAh avec charge MagSafe, et quelques accessoires.

C'est dispo chez plusieurs revendeurs : Elecrow, Carbon Computers, Tindie, ou même Etsy mais le module CM5 par contre, faudra le sourcer séparément, genre chez Pishop.us.

Ce projet a été développé par ZitaoTech, c'est open source, donc toute la communauté peut contribuer, améliorer les designs, partager des configs, etc et y'a d'ailleurs déjà pas mal de mods qui circulent, notamment des antennes externes pour améliorer la portée WiFi pendant les tests de pénétration.

Comme ça, si vous êtes dans la sécu offensive, c'est quand même pratique d'avoir un device dédié qui ne risque pas de foutre en l'air votre config perso si un test part en vrille. Vous isolez vos outils, vos payloads, vos exploits sur un système séparé, et si ça plante, bah vous rebootez le deck, c'est tout.

Et puis franchement, c'est plutôt classe je trouve de sortir un truc comme ça de sa poche. Ça donne l'impression que vous êtes en mission, comme dans les films... vous dégainez votre petit cyberdeck avec son clavier BlackBerry, vous vous branchez sur un port Ethernet, et hop, vous lancez vos scans. Ça a plus de gueule je trouve qu'un laptop Dell sous Windows avec un autocollant Mr. Robot ^^.

A découvrir ici !

Je trouve que ce qui manque sous Linux, c'est un petit outil sympa pour garder un œil sur l'état de sa batterie de portable. Alors oui, y'a des trucs par-ci par-là, mais rien de vraiment moderne et surtout complet. Mais c'était sans compter sur Wattage vient combler ce vide aussi immense que votre amour pour mon site ^^.

C'est donc une petite appli GTK4/libadwaita toute fraîche qui vous affiche tout un tas d'infos sur votre batterie. Et quand je dis tout un tas, c'est vraiment tout un tas du genre le nombre de cycles de charge, la capacité actuelle, le voltage, l'état de santé, les métriques d'énergie, les infos constructeur, etc.

L'appli est codée en Vala, ce qui veut dire qu'elle compile en C et que c'est plutôt rapide. Elle va récupérer toutes ses données directement dans /sys/class/power_supply, le dossier système où Linux stocke les infos de vos périphériques d'alimentation.

Le truc cool avec Wattage, c'est qu'elle supporte plusieurs batteries ou sources d'alimentation en même temps, donc si vous avez un setup un peu particulier avec plusieurs batteries, hop, tout s'affiche proprement dans l'interface.

L'interface justement, elle est assez minimaliste et bien fichue puisque vous avez toutes vos stats batterie dans une seule fenêtre, sans menus compliqués, ni options inutiles.

Voilà, alors plutôt que de vous fier uniquement à l'indicateur système classique qui vous dit juste le pourcentage, vous pourrez maintenant voir l'état réel de votre batterie. Comme ça, si elle commence à décliner, ou si le nombre de cycles grimpe trop, vous le saurez. Même chose si la capacité maximale baisse par rapport à la capacité d'origine... Plus rien ne vous échappera.

C'est développé par v81d, dispo sur GitHub , et sous licence GPL v3 et comme tout bon logiciel Linux moderne, Wattage est dispo sur Flathub , donc vous pouvez l'installer sur à peu près n'importe quelle distribution en deux clics. Ubuntu, Fedora, Arch, Mint... tant que vous avez Flatpak installé, vous êtes bons.

Source

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

go install github.com/semonte/sisu@latest

Dites donc, en ce moment, c’est la folie autour de Valve. D’ailleurs, en lisant mon article sur le Steam Frame , vous vous êtes peut-être demandé comme celui-ci allait réussir à faire tourner des jeux PC alors qu’il tourne sur un Snapdragon ARM ?

Hé bien la réponse s’appelle FEX , un émulateur que Valve finance en secret depuis 2018 soit en gros depuis le tout début du projet.

Pour ceux qui connaissent pas, FEX permet de faire tourner des applications x86 (32 et 64 bits) sur des processeurs ARM64 sous Linux. C’est un peu comme qemu-user ou box64, sauf que FEX utilise un recompilateur binaire avancé avec un IR custom qui génère du code plus optimisé qu’un JIT classique.

Concrètement, au lieu de traduire directement le code x86 en ARM64 (ce qui serait un bordel monstre vu les différences entre les deux architectures), FEX fait donc ça en deux temps :

1. x86 → IR : le code x86 est d’abord converti dans un langage intermédiaire simplifié, indépendant de toute architecture
2. IR → ARM64 : ensuite cet IR est traduit en code ARM64 natif

L’avantage c’est qu’on peut appliquer des optimisations sur l’IR (par exemple, éliminer du code mort, simplifier des opérations, réorganiser les instructions…etc) avant de générer le code final.

FEX supporte même AVX et AVX2, ce qui est quand même pas mal pour de l’émulation.

La vraie force de FEX, c’est sa capacité à rediriger les appels API vers les bibliothèques natives du système. Au lieu d’émuler OpenGL ou Vulkan (ce qui serait une catastrophe pour les performances), FEX balance directement les appels vers les versions ARM des bibliothèques. Selon Valve, on parle d’une perte de performances de seulement 10 à 20% sur certains aspects du code… et visiblement, ils arrivent à faire tourner Hades 2 en 1440p à 90 Hz sur le Steam Frame donc c’est pas dégueu.

Du coup, on a maintenant la vue d’ensemble de la stratégie Valve pour le gaming ARM : FEX pour émuler le x86 natif , Lepton pour les APK Android, et Proton pour les jeux Windows. Trois couches de compatibilité qui devraient permettre au Steam Frame de jouer à peu près tout ce qui existe. C’est la même stratégie que pour le Steam Deck, au final.

Le cache de code expérimental de FEX permet aussi de réduire les saccades en jeu, et y’a même une interface graphique (FEXConfig) pour configurer les paramètres par application. Parce que oui, selon les jeux, vous pouvez ajuster les réglages pour optimiser les perfs… genre désactiver l’émulation coûteuse du modèle mémoire si le jeu n’en a pas besoin.

Et comme d’hab avec eux, c’est open source et ça profite à tout le monde alors c’est cool !

Source

Vous vous rappelez de Proton , cette couche de compatibilité magique qui permet de jouer à des jeux Windows sur Linux ?

Hé bien Valve récidive avec Lepton, qui fait exactement la même chose… mais pour Android. Et devinez quoi, c’est basé sur Waydroid , ce projet open source qui permet de faire tourner Android dans un conteneur Linux.

L’idée derrière tout ça, c’est le Steam Frame , le fameux casque VR que Valve va sortir début 2026 et contrairement au Steam Deck qui utilise un processeur AMD x86, ce bidule tourne avec un Snapdragon 8 Gen 3 et 16 Go de RAM. Oui vous l’aurez compris, c’est de l’ARM !

Du coup, plutôt que de demander aux développeurs de porter leurs jeux un par un (ce qu’ils ne font jamais, on les connait ces branleurs ^^), Valve a décidé de supporter directement les APK Android. Ainsi, les devs qui ont déjà sorti leur jeu VR sur Meta Quest pourront donc le balancer sur Steam sans effort supplémentaire. C’est pas con, hein ? (à prononcer avec l’accent ch’ti). Et d’ailleurs, Walkabout Mini Golf sera le premier jeu Android officiel sur Steam. Si vous l’avez déjà acheté sur Steam, vous aurez donc accès à la version Android le jour du lancement du Steam Frame… pas besoin de repasser à la caisse et ça c’est cool !

• lien nᵒ 1 : Vidéo YouTube "Building the PERFECT Linux PC with Linus Torvalds"

Commentaires : voir le flux Atom ouvrir dans le navigateur

Vous connaissez peut-être FUSE (Filesystem in Userspace), ce truc qui permet de créer des systèmes de fichiers custom sans toucher au noyau Linux. C’est grâce à lui notamment qu’on peut monter un Google Drive, un bucket S3 ou même un dossier distant via SSH comme un simple répertoire local.

Hé bien, Rohan Gupta a poussé ce concept jusqu’à l’absurde en créant LLMfuse, un système de fichiers où toutes les opérations sont gérées par un modèle de langage fine-tuné.

Ainsi, quand vous faites un ls, un chmod ou un cat sur ce filesystem, c’est un LLM qui répond et chaque opération FUSE devient une requête au modèle. Pour parvenir à ces fins, le développeur a entraîné un Qwen3-4B sur environ 15 000 paires prompt/completion générées à partir de simulations d’opérations filesystem. Le modèle a alors appris à lire le contenu des fichiers, modifier les métadonnées, et même à représenter l’arborescence complète en XML.

Bon, dit comme ça, ça ressemble à une expérience de savant fou un peu conne… Mais y’a un truc vraiment intéressant qui découle de tout ça. En effet, l’auteur a découvert que la combinaison du codage arithmétique avec son modèle fine-tuné permettait d’atteindre des taux de compression délirants. Sur un fichier texte classique, il obtient par exemple une compression 22 fois meilleure que gzip. Et pour une arborescence de fichiers représentée en XML, c’est environ 8 fois mieux que squashfs.

Alors comment c’est possible cette magie noire ? Bah ça remonte au théorème de Shannon de 1948 sur l’entropie où plus un modèle prédit bien les données, moins il faut de bits pour les encoder. Un LLM fine-tuné sur un type de données spécifique devient alors un compresseur hyper efficace pour ces données.

L’auteur est le premier à admettre que c’est une expérimentation, donc, pas de quoi vous emballer non plus… Après si vous souhaitez l’utiliser, vous avez besoin d’un GPU, que l’intégralité du système de fichiers tienne dans la fenêtre de contexte du modèle, et ça ne marche vraiment bien que sur des données textuelles. Pour vos vidéos 4K ou votre bibliothèque de jeux Steam, on repassera… snif…

D’ailleurs, le fait que lipsum.txt (le classique Lorem Ipsum) soit surreprésenté dans les données d’entraînement des LLM aide beaucoup à gonfler les chiffres de compression mais même sur d’autres types de textes “normaux” qui ressemblent à ce qu’on trouve sur Internet, les gains restent entre 5x et 20x par rapport à gzip.

Le code source est disponible sous licence MIT, avec notamment un utilitaire CLI appelé llmencode que vous pouvez tester en local si vous avez une bonne carte graphique sous la main.

Amusez-vous bien !

Source

Vous avez surement un vieux smartphone qui traîne au fond d’un tiroir, non ? Bah au lieu de le laisser pourrir ou de le balancer à la déchetterie, pourquoi ne pas en faire un vrai serveur web ?

Je sais ce que vous pensez… Ce mec est fou. Et pourtant, c’est exactement ce qu’a fait Louis Merlin avec son projet Far Computer . Son site tourne littéralement sur un Fairphone 2 posé dans un tiroir, avec PostmarketOS comme système d’exploitation. Le site affiche en temps réel les stats de la machine donc au moment où j’écris ces lignes, 5% de CPU, 280 Mo de RAM utilisés sur 1.8 Go disponibles… C’est presque de la puissance gâchée pour servir quelques pages statiques, mdr.

Ce projet s’inscrit dans cette mouvance du “sustainable computing” où l’idée c’est de donner une seconde vie aux appareils qu’on jette après 2-3 ans alors qu’ils ont encore plein de ressources à offrir. D’ailleurs, PostmarketOS est parfait pour ça puisque c’est une vraie distrib Linux basée sur Alpine, ultra légère, et qui supporte plus de 200 appareils différents, des vos vieux Nokia N900 aux tablettes en passant par les liseuses…

D’ailleurs le guide d’installation dispo sur far.computer/how-to est hyper bien fait si vous voulez vous lancer. En gros vous avez besoin d’un PC Linux (ou une VM), vous installez pmbootstrap, vous flashez le téléphone en mode bootloader, et hop, une fois PostmarketOS installé, vous vous connectez en SSH, vous configurez le WiFi avec nmcli, vous créez votre dossier /var/www/html/, vous lancez httpd et voilà. Votre vieux téléphone est devenu un serveur web.

Alors bien sûr, pour mon site avec son million de visiteurs uniques par mois, ça le ferait moyen et faudrait quand même coller un CDN devant pour encaisser la charge, mais pour un projet perso, un blog à faible trafic, une API interne ou juste pour le plaisir de dire aux inconnus dans la rue, “Hey bonjour, on ne se connait pas mais mon site tourne sur un téléphone”, c’est vraiment cool (et un peu creepy).

Certains vont même plus loin en montant des clusters Kubernetes avec plusieurs vieux smartphones . Quand on sait que ces machins ont souvent des specs supérieures à un Raspberry Pi et qu’ils consomment que dalle en électricité, je me dis qu’il y a vraiment un truc à explorer.

Point important à garder en tête quand même, évitez de laisser le téléphone branché en permanence sur le chargeur car les batteries n’aiment pas trop ça, et ça peut finir en feu de joie improvisé. Idéalement faut virer la batterie si c’est possible ou mettre en place une gestion de charge intelligente.

Le code source du projet Far Computer est dispo sous licence CC BY-NC-SA 4.0 donc vous pouvez vous en inspirer, le modifier, le partager… tant que c’est pas pour du commercial bien sûr et que vous gardez la même licence.

Voilà, vous savez ce qu’il vous reste à faire si vous avez des vieux smartphones qui prennent la poussière.

Vous vous souvenez de Remix OS, de Phoenix OS et de tous ces projets qui promettaient ENFIN de faire tourner Android sur votre PC comme un vrai OS desktop ? Ouais, moi aussi je m’en souviens… Et ce dont je me souviens surtout, c’est de comment ça s’est terminé… Des abandons, des problèmes de mise à jour, du licensing foireux avec Google. Bref, un vrai carnage…

Hé bien cette fois c’est Google lui-même qui se lance dans l’aventure avec un projet baptisé Aluminium OS. Et attention, ce n’est pas juste une rumeur de plus puisque Rick Osterloh, le grand patron de la division Devices de chez Google, a officiellement annoncé le projet en septembre dernier au Snapdragon Summit de Qualcomm. Comme les deux boîtes bossent ensemble sur cette nouvelle plateforme, on devrait logiquement voir débarquer des machines sous puces Snapdragon.

Côté naming, Google reste fidèle à sa convention maison avec un nom de métal en “-ium”, vous savez, comme Chromium pour Chrome… Sauf qu’ils ont choisi la version britannique “Aluminium” plutôt que “Aluminum” nord-américaine. Ça sera aussi plus simple à retenir pour nous les français.

Aluminium c’est donc la fusion tant attendue entre ChromeOS et Android afin d’avoir un seul OS unifié pour les laptops, les tablettes détachables et même les mini-PC style Chromebox. L’objectif affiché c’est de mieux concurrencer l’iPad sur le marché des tablettes, mais aussi taper sur la tête de Windows et macOS côté PC. Et contrairement à ce qu’on pourrait craindre, Google ne compte pas limiter ça aux machines d’entrée de gamme pourries puisqu’ils prévoient trois segments : AL Entry (le pas cher), AL Mass Premium (le milieu de gamme) et AL Premium pour jouer dans la cour des grands.

Le truc qui change vraiment par rapport aux Phoenix OS et autres projets communautaires, c’est surtout que Google veut intégrer son IA Gemini au cœur du système. Bon ok, tout le monde fait ça maintenant, mais au moins ça prouve que c’est un projet sérieux avec de vraies ressources derrière.

Maintenant, si vous êtes actuellement utilisateurs de Chromebook (force à vous ! ^^), pas de panique puisque les machines existantes continueront à recevoir leurs mises à jour jusqu’à leur fin de vie. Les plus récentes pourraient même avoir droit à une petite migration vers Aluminium OS si elles sont compatibles. D’ailleurs, si on en croit les rapports de bugs internes, Google teste actuellement ce système sur des cartes de dev équipées de puces MediaTek Kompanio 520 et Intel Alder Lake 12e gen, donc si votre Chromebook tourne avec l’un de ces chipsets, vous avez peut-être une chance…

En interne, les ingénieurs parlent même déjà de “ChromeOS Classic” pour désigner l’ancien système, ce qui laisse penser que Google pourrait simplement renommer Aluminium en ChromeOS une fois leur truc mature.

Bref, le lancement de ce nouvel OS Made in Google est prévu pour 2026 et sera probablement basé sur Android 17. À voir maintenant si ça décollera plus que ChromeOS…

Source

TwoFace est un outil développé par Synacktiv qui permet de créer des binaires Linux ayant 2 comportements bien distincts. Un comportement parfaitement inoffensif qui s’active dans 99% des cas et un comportement malveillant qui ne se déclenche que sur une machine ciblée spécifiquement pour l’occasion.

Comme ça, votre sandbox verra toujours la version “propre” parce qu’elle n’aura pas le bon UUID de partition.

D’après la doc de Synacktiv, voici comment ça fonctionne : Vous avez deux binaires en fait… Y’en a un qui est inoffensif et un autre malveillant. TwoFace les fusionne alors en un seul exécutable. Ainsi, au moment du build, le binaire malveillant est chiffré avec une clé dérivée depuis l’UUID des partitions disque de la machine cible. Cet UUID est unique, difficile à deviner, et stable dans le temps ce qui est parfait pour identifier une machine spécifique.

Ensuite au lancement, quand le binaire s’exécute, il extrait l’UUID du disque de la machine. Pour ce faire, il utilise HKDF (Hash-based Key Derivation Function) pour générer une clé de déchiffrement depuis cet UUID et tente de déchiffrer le binaire malveillant caché. Si le déchiffrement réussit (parce que l’UUID match), il exécute le binaire malveillant. Par contre, si ça échoue (parce que l’UUID ne correspond pas), il exécute le binaire inoffensif.

Le projet est écrit en Rust et c’est open source ! Et c’est une belle démo (PoC) d’un problème que tous ceux qui font de l’analyse de binaires ont. En effet, d’ordinaire, pour révéler le vrai comportement d’un malware on l’exécute dans une sandbox et on peut ainsi observer en toute sécurité ce qu’il fait, les fichiers qu’il crées, les connexions réseau qu’il établit etc…

Mais avec TwoFace ça casse cette façon de faire. Et c’est pareil pour les antivirus qui verront toujours la version inoffensive tant que l’UUID ne correspond pas.

Techniquement, TwoFace utilise memfd_create() pour exécuter le binaire déchiffré en mémoire, sans toucher au disque, ce qui veut dire zéro trace sur le système de fichiers. Le binaire malveillant apparaît directement en RAM, s’exécute, puis disparaît. Et si vous utilisez io_uring pour l’écriture mémoire, il n’y a même pas de trace syscall visible via strace.

Et ça, c’est la version basique car le document de Synacktiv mentionne également d’autres techniques avancées possibles comme du déchiffrement dynamique page par page du binaire ELF, des mécanismes anti-debugging, des chained loaders multi-niveaux…etc…

Le parallèle avec la backdoor XZ Utils backdoor est très instructif car celle-ci a failli compromettre des millions de serveurs Linux parce qu’un seul mainteneur a poussé du code malveillant dans une lib compressée. Elle a alors été découverte parce qu’un dev a remarqué un ralentissement SSH bizarre et a creusé… Et TwoFace montre qu’on peut faire encore pire sans toucher à la supply chain.

Pas besoin de corrompre un mainteneur de projet, de pousser un commit suspect chez Github. Là suffit d’écrire du code parfaitement propre, de le compilez avec TwoFace pour une machine spécifique, et de le déployez. Le code source sera alors auditable ainsi que le binaire mais l’audit ne révèlera rien parce qu’il se fera dans un environnement qui n’aura pas le bon UUID.

Après, techniquement, une défense existe. Vous pouvez par exemple détecter les appels à memfd_create(), monitorer les exécutions en mémoire, tracer les déchiffrements crypto à la volée…etc., mais ça demande du monitoring profond, avec un coût performance non-négligeable. Et ça suppose aussi que vous savez ce que vous cherchez…

Bref, si ça vous intéresse, c’est dispo sur GitHub !

ImunifyAV, le scanner AV qui protège 56 millions de sites Linux, vient de se faire pwn par le malware qu’il essayait de détecter. Et c’est pas la première fois…

En effet, Patchstack vient de révéler une faille RCE critique dans ImunifyAV, qui je le rappelle est un scanner antivirus gratuit ultra répandu dans l’hébergement mutualisé. Le problème en fait c’est que AI-bolit, le composant qui déobfusque le code PHP malveillant pour l’analyser, utilise la fonction call_user_func_array sans vérifier les noms de fonctions qu’elle exécute.

Boooh ! Du coup, vous uploadez un fichier PHP malveillant spécialement conçu pour l’occasion par un attaquant, ImunifyAV le scanne pour voir si c’est un malware, le déobfusque pour comprendre ce qu’il fait, et hop, le code malveillant s’exécute avec les privilèges du scanner.

Game over.

Hé pour qu’un antimalware détecte un virus, il doit analyser son code mais si les cybercriminels obfusquent leur malware pour cacher le code, l’antimalware doit alors le déobfusquer avant d’analyser. Mais déobfusquer du code PHP, ça veut dire aussi l’exécuter partiellement pour voir ce qu’il fait vraiment… d’où cette RCE.

La faille affecte donc toutes les versions avant la 32.7.4.0 et le correctif apporte juste une fonctionnalité de whitelist de fonctions autorisées pendant la déobfuscation. Il était temps, même si maintenir une whitelist de fonctions safe, à terme c’est un cauchemar car y’a des centaines de fonctions dans PHP. Certaines sont safe seules mais dangereuses combinées et je pense que les cybercriminels trouveront toujours un moyen de contourner cette whitelist.

En tout cas, comme je le laissais entendre en intro, c’est pas la première fois qu’AI-bolit se fait avoir sur la déobfuscation. En 2021, Talos avait déjà trouvé une faille sur unserialize dans le même composant. C’est la même blague car pour analyser du code malveillant sérialisé, il faut le désérialiser. Et désérialiser du contenu malveillant sans validation, ça fait “pwn” !

Voilà, 2 fois en 4 ans sur le même composant, c’est pas ce que j’appelle un accident. C’est un problème structurel car détecter du malware sans l’exécuter, c’est quasi impossible avec du code dynamique. Les signatures statiques ça marche bien pour les virus classiques mais face à du PHP obfusqué qui se reconstruit à l’exécution, vous êtes obligé de lancer le code pour voir ce qu’il fait vraiment. Et là, on est forcement en zone grise…

Même si on exécute du code potentiellement malveillant dans un environnement censé être isolé, si celui-ci “fuit” ou si le code malveillant trouve un moyen de sortir de la sandbox, vous avez une RCE. Et comme ImunifyAV tourne avec les privilèges nécessaires pour scanner tous les fichiers d’un serveur mutualisé, si vous compromettez cet antivirus, vous avez potentiellement accès à tous les sites hébergés sur la machine.

Si vous voulez tester, voici le proof of concept :

<?php
$data = "test";

$payload = "\x73\x79\x73\x74\x65\x6d"("\x74\x6f\x75\x63\x68\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74\x20\x26\x26\x20\x65\x63\x68\x6f\x20\x22\x44\x45\x46\x2d\x33\x36\x37\x38\x39\x22\x20\x3e\x20\x2f\x74\x6d\x70\x2f\x6c\x33\x33\x74\x2e\x74\x78\x74");
eval("\x70\x61\x63\x6b"($payload));
?>

php ai-bolit.php -y -j poc.php

Amazon vient d’annoncer qu’ils bloquaient désormais les applications de piratage sur leurs Fire TV Stick (lien affilié) et cela sur tous les appareils. Les nouveau, les anciens, peu importe… Ainsi, si une app est identifiée comme distribuant du contenu illégal, elle dégage ! Même si vous l’avez sideloadée.

Ce grand ménage a commencé en France et en Allemagne, et s’étendra au monde entier dans les prochains mois. Sniiff… Ça sent la fin d’une époque.

Ainsi, pendant des années, Amazon a vendu des millions de Fire Stick en sachant parfaitement ce que les gens en faisaient. Ils en ont bien profité les coquins ! Votre collègue qui vous proposait un Fire Stick modifié à 80 balles avec un abonnement IPTV 12 mois inclus et accès à Sky Sports, TNT Sports, et les films encore au cinéma, c’était la baaase et Amazon voyait bien tout ça passer.

Selon une analyse d’Enders , 59% des personnes qui regardent du contenu piraté au Royaume-Uni utilisent un Fire Stick. 59% !! Ça fait environ 4,7 millions d’adultes britanniques qui on streamé illégalement du sport ces six derniers mois. L’architecture même des Fire Stick facilitait le détournement puisque c’était un Android ouvert, avec du sideloading activable en trois clics dans les paramètres, et une excellente compatibilité avec toutes les apps tierces notamment pour l’IPTV.

Amazon avait conçu la streaming machine parfaite !!

Sauf Sky en a eu marre. La chaîne britannique a fait une grosse pression sur Amazon durant des mois et cela a été payant ! Amazon a enfin eu une révélation, une prise de conscience soudaine et miraculeuse sur l’importance de la sécurité et du respect de la propriété intellectuelle. Mais mdrrrr…

Et hop, un petit partenariat avec l’Alliance for Creativity and Entertainment, plus tard (c’est la coalition anti-piratage menée par la Motion Picture Association avec Disney, HBO, Netflix, tous les gros bonnets) et nous y voilà. Leur dernier né, le Fire TV Stick 4K Select (lien affilié) est même le premier appareil tournant sous Vega OS. C’est un système d’exploitation maison basé sur Linux, et pas Android, donc plus moyen d’exécuter les applications Android sideloadées avec ça.

Snif !

Après, les services pirates ne vont pas disparaître puisque certains services IPTV passent déjà aux web apps qui tournent dans le navigateur… mais bon l’âge d’or du Fire TV Stick en tant que box à piratage semble être terminée.

Bref, Amazon ferme le robinet… après avoir biiiien rempli la piscine !

Source