Vous voulez vérifier un truc dans une vieille version de Python, du genre celle de 2017, histoire de voir si le bug que vous traquez vient de là. Normalement ça veut dire chercher une image Docker ou un vieux binaire de python, pour faire vos tests. Mais avec trynix, vous cliquez un lien et hop, vous avez un shell avec votre outil.

Ce site est signé Farid Zakaria, qui bricole autour de Nix depuis des années et appelle ça son "magnum opus". En gros, une machine Linux x86_64 démarre dans votre onglet, avec le paquet demandé déjà accessible dans le PATH. Rien à installer et pas de compte à se créer, ça marche direct dans le browser.

J'ai essayé ce matin avec python3 en version 3.6.2 . Le navigateur va chercher les chemins du store, vérifie leurs signatures, et au bout d'une trentaine de secondes le prompt s'affiche. Je tape alors python3 --version, il me répond Python 3.6.2, avec la glibc 2.25 et l'OpenSSL 1.0.2l de l'époque livré avec. Et voilà comment je me retrouve avec un Python de 2017 dans un Chrome de 2026, sans rien toucher à ma machine.

Le terminal de la machine virtuelle, dans l'onglet : Python 3.6.2 répond, et les seize chemins du store sont vérifiés juste au-dessus.

Et ce ne sont pas trois démos préparées à l'avance puisque l'index recense les 310 000 et quelques versions que nixpkgs a livrées en treize ans. Toutes ne démarrent pas, attention, il n'y en a que 274 729 avec un binaire x86_64 dans le cache, et le reste est non libre, cassé, ou hors du lot.

Ce qui rend la chose possible, c'est en fait une simple ligne d'en-tête HTTP. Le cache binaire de Nix sert un access-control-allow-origin: *, donc votre navigateur a le droit d'aller y piocher tout seul. Et le plus drôle, c'est que Zakaria avait lui-même réclamé cet en-tête en 2021, pour un tout autre projet. Et 5 ans plus tard, il s'en sert pour démarrer des machines virtuelles... Qui aurait pu prédire comme dirait l'autre !

Pour l'émulation, après il n'a rien réinventé. Il a tout simplement repris prend qemu-wasm , le QEMU compilé en WebAssembly de ktock, et la machine virtuelle ne boote même pas vraiment, mais reprend un instantané figé à l'avance. En tout cas, c'est bien pensé et très pratique.

Du Linux dans un navigateur, je vous avais d'ailleurs déjà montré ça ici avec cette machine virtuelle x86 . Sauf que ces trucs-là chargent une image figée à l'avance, alors qu'ici, on choisit vraiment son contenu en 1 clic.

Niveau vitesse, le projet annonce un lancement en 3 secondes, mais c'est le temps d'obtenir le shell quand tout est déjà dans le cache du navigateur. Chez moi, lors de mes tests, au premier passage, il a fallu 30 secondes, puis 7,5 secondes au suivant. Et une fois dedans ça reste poussif, parce que chaque binaire est traduit du x86 vers le WebAssembly à son premier lancement, ce qui peut faire monter le chargement à deux minutes sur les gros binaires.

Et il y a aussi un plafond puisque tout doit tenir dans la mémoire de l'onglet, soit environ 1,5 Go. Et c'est une console série, donc vous ne pourrez rien lancer de graphique, pas de fenêtre, pas de souris... Bref, que les outils en ligne de commande et rien d'autre ! Mais bon, vous êtes de vrais barbus qui n'ont peur de rien à part du déo, donc je ne suis pas inquiet ^^.

Ce qui est vraiment cool avec Trynix surtout, c'est l'action GitHub que son dev a sortie dans la foulée. Si votre intégration continue pousse déjà ses compilations dans un cache, un bot colle un lien sous la pull request et le relecteur lance le code au lieu de le lire. Comme ça, fini le clone, la compilation et le "*ça marche chez moi pourtant *" invérifiable. Même topo pour faire essayer un truc à quelqu'un qui n'a ni Nix ni Docker... Suffit de lui envoyer le lien.

Un petit point sécu quand même que je tiens à vous signaler : L'URL transporte à la fois les caches supplémentaires et les clés qui les valident, du coup la signature vous prouve bien que le binaire vient du cache annoncé... mais pas qu'il vient de quelqu'un de fiable. En effet, cliquer sur un lien trynix inconnu, ça revient à lancer le programme d'un inconnu, et même si ça se passe dans la sandbox de l'onglet du navigateur (ce qui limite les dégâts), c'est quand même mieux d'en avoir conscience !

Bref, voilà encore un chouette projet sous licence MIT et si ça vous chauffe, ça se passe sur trynix.dev .

Source : Simon Willison

Le projet Asahi Linux vient enfin de fusionner le support des Mac M3 dans son installateur. En clair, ça veut dire que si vous avez un MacBook Air, un MacBook Pro ou un iMac équipé d'un M3, d'un M3 Pro ou d'un M3 Max, vous pouvez y installer Linux dès maintenant.

Et la liste de ce qui fonctionne est plus longue que ce que je pouvais craindre. La webcam, les micros internes, le WiFi, le Bluetooth, l'USB 3 jusqu'aux 10 Gb/s permis par la machine, et le décodage vidéo accéléré, AV1 compris.

Le Thunderbolt aussi, est même arrivé cet été. Apple avait troqué, sur les M3 Pro et M3 Max, son vieux contrôleur de ports USB contre une puce ACE3 posée sur un bus SPMI au lieu de l'I2C. Il a donc fallu reverse tout ce petit monde afin que l'USB 3 et le Thunderbolt marchent sur l'ensemble de la gamme M3.

Si vous voulez vous lancer, l'installation doit encore passer par le mode Expert de l'installeur, parce que c'est encore tout frais. Mais quand la bêta de Fedora Linux 45, sera implémentée d'ici quelques semaines, ça devrait fonctionner en install normale.

Après le gros manque, c'est la 3D. N'attendez ni performances, ni accélération 3D économe en énergie puisque tout est géré par la partie CPU du M3. Et ce n'est pas de la mauvaise volonté de la part des dev puisque le GPU du M3 s'écarte nettement de celui des M1 et M2 : ray tracing matériel, mesh shaders, et le Dynamic Caching maison d'Apple. Il y a donc énormément à refaire et même si le chantier a commencé, pour le moment, on n'a pas de date.

Les autres limites ont l'air nettement moins définitives comme pour la mise en veille qui ne fonctionne pas et le port HDMI des MacBook qui est coupé. Cela s'explique par le fait que le composant DCP qui gère ces 2 aspects là c'est pas encore piloté par Asahi, mais ça ne devrait pas tarder.

Le Mac Studio, lui, reste à la rue. Le M3 Ultra n'est pas supporté, et les M4 et M5 en sont au tout début, avec le stockage, le PCIe et le démarrage multicœur qui tournent mais pas grand-chose d'autre. Donc plus votre machine est récente, plus il va falloir être patient...

Perso, j'avais un iMac M3 et franchement, j'ai été très déçu par cette machine. Pour de la bureautique ça allait très bien, mais dès qu'on bidouille un peu fort, ça pédale dans la semoule. Je suis donc passé au Mac Studio depuis et je ne le regrette pas une seconde.

En tout cas, je sais que si je veux recycler ce "vieil" iMac M3, je peux maintenant lui installer Linux... ça vaut peut-être le coup, à condition d'assumer un desktop sans la moindre accélération 3D ^^.

Source : le billet d'annonce d'Asahi Linux et Neowin .

Ce serait trop cool non, si avec un double-clic sur un .docx dans votre gestionnaire de fichiers Linux, Word s'ouvrait directement ? Et je ne vous parle pas d'un bureau Windows complet en plein écran ou d'une session de bureau à distance. Juste une fenêtre Word tout ce qu'il y a de plus classique, avec son icône dans votre barre des tâches, épinglable et "alt-tabbable" comme le reste.

Hé bien, c'est ce que fait WinPodX , qui fait tourner un conteneur Windows sous KVM en arrière-plan et découpe l'affichage application par application via FreeRDP RemoteApp. Comme ça, les liens mailto: partent vers Outlook ou les schémas slack: ou vnc: vers l'application qui les a déclarés.

Tout ce qui est presse-papiers, son, imprimantes et votre dossier personnel sont partagés d'office, et le conteneur se met en pause tout seul quand personne ne s'en sert.

Jusque-là, WinApps dont je vous ai déjà causé, qui fait tourner Office sous Linux , faisait déjà l'essentiel avec les fenêtres détachées, le dossier personnel partagé, le clic droit qui envoie un fichier vers une application Windows. Mais WinPodX se distingue aussi dans l'autre sens puisque vos applications Linux remontent également dans le menu "Ouvrir avec..." du Windows, et dans un dossier "Linux Apps" du menu Démarrer. Bref, l'accès aux apps et aux fichiers marche dans les 2 sens, pour plus de transparence dans vos usages.

Si ça vous intéresse, sachez qu'il vous faut une licence Windows valide, car WinPodX ne la fournit pas (logique), que la virtualisation doit être activée dans le BIOS, avoir un accès à /dev/kvm, 8 Go de RAM et une trentaine de gigas de libre. La première installation prend cinq à dix minutes le temps de télécharger l'ISO, et les suivantes sont quasi instantanées.

Pour l'installer :

curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash

Il y a également un paquet pour openSUSE, Fedora, Debian, Ubuntu, Arch et NixOS, un AppImage pour les autres. C'est sous licence MIT, et sans aucune télémétrie puisque celle de Windows a été elle-même coupée par défaut. Ah et l'interface du OuinOuin peut être configurée en français.

Par contre, pas d'accélération GPU, ce qui exclut les jeux et la 3D à moins de monter un passthrough à la main. Préférez Wine pour ça...

Vous jouez sous Linux et votre bibliothèque Steam, GOG ou Epic tourne à peu près entièrement grâce à Proton ? Cela signifie que, malheureusement, vos jeux Xbox PC et ceux du Game Pass, eux, restent à la porte... C'est con d'avoir un catalogue entier, payé tous les mois rubis sur l'ongle et de ne pas pouvoir y toucher ailleurs que sous Windows, via le streaming cloud.

Mais cette époque est révolue puisque Xodus est un projet open source qui rétro-ingénierie la chaîne Xbox PC pour faire tourner ces jeux directement sur Linux. Son dépôt coche déjà la connexion de l'appareil, celle du compte, l'autorisation Xbox, la récupération des licences, le téléchargement des paquets de jeu et le déchiffrement des exécutables à la demande. Bref, la douane est passée (non pas Hamza, celle de Microsoft).

Ce qui bloquait n'a jamais été Proton puisqu'en fait un jeu Xbox PC moderne repose sur le GDK de Microsoft et arrive emballé dans un conteneur MSIXVC chiffré, dont les clés dépendent de la licence attachée au compte.

Rien à voir donc avec un .exe posé dans un dossier.

L'équipe, emmenée par Paweł Lidwin qui contribue aussi à Heroic , a donc dû fabriquer ses propres briques, une bibliothèque d'authentification Xbox, un lecteur capable de parcourir ces conteneurs, et surtout une réimplémentation libre de xgameruntime.dll, le composant par lequel les jeux réclament les services Xbox (Celle-là est toujours en chantier). Le projet entretient même ses propres versions modifiées de Wine et de Proton.

Sauf qu'on ne joue toujours pas... Aucun binaire n'est distribué, il faut tout compiler soi-même, et les fameux services Xbox doivent encore être servis aux jeux à travers Wine. Le lancement, c'est donc le gros morceau restant même si un jeu auquel vous avez droit se récupère et se déchiffre.

Côté catalogue, il faut du GDK et du MSIXVC. Le MSIXVC2 n'est pas géré, Gears of War 4 reste sur le carreau, et les titres rétrocompatibles se récupèrent mais réclameront peut-être des correctifs dans wine ou dxvk. Quant au déchiffrement, il s'appuie sur les instructions AES du processeur. Cela signifie que sur une machine trop vieille pour les avoir, ça ne ramera même pas... ça s'arrête juste net sur une instruction "illegal".

Et puis, vous vous en doutez, il y a Microsoft... Le projet n'est ni affilié ni approuvé par Redmond, donc c'est à utiliser à vos risques et périls, car rien n'empêche l'éditeur de changer une clé ou de modifier un bout du protocole et de refermer la porte du jour au lendemain. Avec Xodus, personne n'a rien promis, et c'est un pari sur un avenir incertain... Toutefois le dépôt avance bien quand même, sans binaire à la clé pour le moment.

Source

Lucas, lecteur de Korben.info, m'a écrit pour me montrer Wayland-Wheeltani , son outil qui ramène l'autoscroll au clic molette sous Wayland, et qu'il met à jour depuis ce printemps. C'est un peu dans l'air du temps de ce genre d'outils puisque fin juillet, je vous parlais déjà de midscroll , qui règle le même manque sous Linux. Wayland-Wheeltani vise le même geste, mais avec une idée nouvelle que l'autre n'a pas.

Le geste, donc... Vous le connaissez, on maintient le bouton du milieu, on éloigne la souris du point d'appui, et la page défile dans cette direction. Plus on s'éloigne, plus ça accélère et si on relâche, ça s'arrête net. Et si on repasse de l'autre côté du point de départ, hé bien le défilement s'inverse sur cet axe.

Toutefois, un mouvement minuscule ne déclenche rien, ce qui fait que sous le seuil, le clic molette reste un clic molette, collage de la sélection compris. Et comme le programme déchiffre les mouvements de la souris au niveau du noyau pour réémettre un genre de molette virtuelle, les applications au-dessus n'en savent rien. Pour elles, c'est juste une molette de souris ordinaire.

L'écart sur la méthode de fonctionnement avec Midscroll, c'est que Wayland-Wheeltani ne se lie pas à votre souris par son fichier dans /dev/input, dont le numéro bouge à chaque branchement, mais bien par son identifiant USB constructeur et produit. Le réglage survit ainsi aux redémarrages et aux changements de port, et le service la retrouve seul quand vous la rebranchez. C'est super si par exemple vous utilisez à certains moments un dock externe.

Le filtre par application, lui, existe des deux côtés, mais ne fonctionne pas dans le même sens. Midscroll démarre avec FreeCAD, OrcaSlicer et Minecraft déjà blacklistés alors qu'avec Wayland-Wheeltani, rien n'est filtré au départ, et vous pouvez exclure des applications ou n'en autoriser que quelques-unes grâce à une commande donnant l'identifiant précis de la fenêtre active. Hyprland, Sway et i3 sont ainsi supportés en direct, GNOME avec une extension fournie, KDE avec kdotool. Et l'autoscroll, lui, marche sur toute session Wayland.

Pour le reste, il faut une session Wayland, systemd en mode utilisateur et l'accès à /dev/uinput. L'installation dépose une règle udev visant votre souris, ce qui évite de faire tourner le service en root au quotidien.

Après la limite, vous la connaissez puisqu'elle est dans le nom : Wayland-Wheeltani ne couvre que Wayland, là où midscroll gère aussi X11. Donc si votre session est encore en X11, vous n'aurez pas le choix. Par contre, si elle est en Wayland et que vous passez votre temps à débrancher / rebrancher votre souris et qu'elle change de port sans cesse, c'est celui-ci qu'il vous faut.

Bonne nouvelle les amis, je viens de vous mettre en ligne un sélecteur de distribution Linux !! 35 distributions dans la balance, vingt questions max et à l'arrivée, le nom du Linux qu'il vous faut !

Parce que oui, la "meilleure" distribution Linux n'existe pas dans l'absolu. En fait, le bon choix dépend de votre machine, de votre usage et du temps que vous acceptez d'y passer. Posez la question à deux personnes, l'une répondra Linux Mint, l'autre CachyOS, et les deux auront raison !

L'outil vous demande vos usages et ce que vous avez sous la main... L'âge de la machine, la RAM, la carte graphique, un Windows à garder à côté, et ce que vous comptez en faire, jouer compris.

Le questionnaire se raccourcit ensuite selon ce que vous avez déjà répondu et au final, vous repartez avec une distribution, sa fiche technique et 2 alternatives si celle-là ne vous branche pas.

J'ai remarqué que ce qui manquait à la plupart des classements de ce type, c'était le "pourquoi pas cette distrib ?". C'est pour cela que mon sélecteur affiche aussi les distributions écartées avec la raison de leur élimination, et celles qui ne démarreront même pas chez vous. Hé oui, un vieux PC en 32 bits n'a plus grand monde à se mettre sous la dent depuis que Debian 13 a supprimé son noyau i386.

Et quand Linux n'est pas la réponse à votre besoin, il vous prévient. Par exemple, si votre travail dépend de la suite Adobe ou d'un jeu avec un système anti-triche, l'outil ne fera pas semblant du contraire.

Et bien sûr, tout cela tourne exclusivement dans votre navigateur, et rien ne part ailleurs dans le cloud. En plus c'est gratuit ! 35 distributions ne font évidemment pas tout l'écosystème Linux, et j'ai dû faire des choix mais ça vous donne déjà un nom précis sur lequel vous lancer en toute sérénité.

Et si vous voulez découvrir les autres services Korben c'est par ici .

La dernière release candidate de Linux 7.2 est bien plus "grosse" qu'elle ne devrait l'être à ce stade du cycle, mais cela n'a pas empêché Linus Torvalds de la publier dimanche en attribuant ce trop-plein aux outils IA qui relisent le code du noyau.

"Je ne peux pas dire que la taille de tout ça m'enthousiasme, mais c'est comme ça : la nouvelle normalité, avec beaucoup de correctifs, dont beaucoup viennent de la revue par divers outils IA."

Rien ne lui paraît effrayant pour autant, et il ne voit aucune raison de retarder la 7.2. Une grosse taille pour ce noyau, ça veut dire plus de 400 correctifs, signés par plus de 230 personnes alors que dans une Release Candidate en général, c'est le moment où le noyau est censé se calmer avant la sortie. Alors que là, ça ressemble plutôt à un nouveau début de cycle.

Et ça tape de partout : Pilotes graphiques, son, réseau, systèmes de fichiers, code d'architecture. Les plus gros blocs viennent de s390 et zcrypt, de btrfs qui remet en place une infrastructure interne, et de correctifs netfilter ipset.

Mais attention au contresens, parce que je l'ai vu passer sur certains tweets d'anti-IA. Torvalds parle de revue de code par des outils IA, et pas d'une IA qui écrirait le noyau à sa place. Sa position de fond, Vincent nous la racontait en juillet quand il envoyait les anti-IA forker le noyau. Ici, ça ne concerne que des outils qui relisent du code existant et signalent des trucs douteux. Après derrière, ce sont des humains qui trient.

À titre d'exemple, l'un des correctifs de cette rc7 traite un use-after-free dans ptdump, l'interface qui affiche les tables de pages du noyau en clair pour repérer les problèmes de mémoire. C'est ce type de bug qui se transforme en faille et il était là depuis mars 2018 (depuis Linux 4.16).

C'est Syzbot , le robot qui bombarde le noyau d'entrées tordues en continu, qui a levé le lièvre en juin dernier. David Carlier a écrit un premier correctif en s'aidant de Claude Opus 4.8 pour remonter la piste, et Lorenzo Stoakes, mainteneur de la gestion mémoire, l'a retravaillé avant qu'il parte dans la rc7. Il devrait ensuite être rétroporté vers les noyaux stables, donc vers les machines qui tournent aujourd'hui.

Autre exemple, Greg Kroah-Hartman, qui traque déjà des bugs du noyau avec une IA locale , vient de faire retirer le pilote Moxa Intellio, soit près de 2200 lignes écrites en 1999 qui supporte certaines cartes série multiports. Alors pourquoi est-ce qu'il a fait ça ? Eh bien il écrit dans son patch que : "C'est un très vieux pilote, aucun matériel connu ne circule encore pour lui, et la société dit ne plus en avoir besoin, alors retirons-le puisque les LLM commencent à venir le titiller et à y trouver des choses "intéressantes" qui vont juste faire perdre du temps à tout le monde, vu qu'il ne sert plus...".

Voilà donc un autre effet de l'analyse de code par IA. Elle oblige les mainteneurs de projet à tailler dans le gras pour virer du code obsolète que des modèles de langage viendraient renifler d'un peu trop près. Ça ne peut pas faire de mal.

Pour moi, le vrai risque de ces outils sur un projet ouvert tient au volume. Un flot de signalements produits par des gens qui ne relisent pas ce qu'ils envoient, où plus personne ne distingue l'hallucination du vrai bug, et là ça partirait en eau de boudin. Mais comme le noyau, lui, garde des mainteneurs qui comprennent les tenants et les aboutissants de ce qu'ils lisent, ça se passe très bien. Même si la quantité de problèmes remontés surprend Linus.

Voilà, si cette nouvelle version du noyau vous intéresse, sachez qu'elle devrait normalement sortir la semaine prochaine en version finale.

Source

CHERRY a annoncé deux appareils à carte à puce, un clavier complet avec lecteur intégré baptisé Smart Board 1150, et un terminal séparé, le Smart Terminal ST-1150. Ils remplacent le KC 1000 SC et le ST-1144.

Une carte à puce sert ici à prouver qui vous êtes. Vous l'insérez, elle signe électroniquement un document, elle ouvre une session sur un réseau ou elle déchiffre un fichier, sans que la clé privée qu'elle contient ne sorte jamais de la puce.

Les deux appareils s'appuient sur le pilote CCID que Microsoft livre déjà dans Windows, et sur pcsc-lite sous Linux et macOS. La norme CCID permet à un lecteur de dialoguer avec le système d'exploitation sans code maison, et pcsc-lite en est l'implémentation libre côté Unix.

Aucun pilote propriétaire à installer, donc. Vous branchez et ça fonctionne, y compris sur une machine Linux, ce qui est encore assez rare pour ce type de matériel.

Screenshot

Les deux modèles embarquent aussi un contrôleur à mémoire flash, et le firmware peut être mis à jour après le déploiement. Ce genre de lecteur était jusqu'à présent figé pour toute sa durée de vie, avec les failles qu'il avait le jour de sa fabrication.

Le communiqué ne dit hélas rien sur la signature de ces mises à jour. Sur un périphérique de sécurité, la question n'a rien de cosmétique, parce qu'un firmware modifiable est aussi un firmware attaquable si personne ne vérifie d'où vient l'image installée.

Le terminal lit et écrit les cartes, pour ouvrir une porte, se connecter au réseau de l'entreprise ou valider une transaction en ligne. Il est fabriqué entièrement en Europe. CHERRY veut clairement faire les yeux doux aux administrations et aux organismes de défense, avec les certifications américaines TAA et FIPS-201 au passage, et une base lestée en métal qui permet d'y glisser la carte d'une seule main.

Le clavier ajoute pour sa part une touche Copilot, ce qui sur un poste à données sensibles est quand même quelque peu audacieux. Il existe aussi en version conforme au Trade Agreements Act américain, pour les agences fédérales et les installations militaires soumises à des règles d'approvisionnement particulières, mais bon a priori ça ne devrait pas trop vous concerner (même si on a de plus en plus de lecteurs américains depuis que le site est traduit !).

Le Smart Board 1150 est vendu 49,99 euros. Le Smart Terminal ST-1150 descend à 34,99 euros, et les deux sont disponibles dès maintenant.

J'avoue que je ne pensais plus voir sortir de nouveaux lecteurs de carte à puce en 2026.

Source : Cherry

L'humain est paresseux par nature, mais alors je ne vous raconte pas quand il s'agit de taper des lignes de commande... Mais bon, l'IA est arrivée dans nos vies et maintenant nous ne sommes plus que des gros sacs de viande et de graisse dont le cerveau se ramollit jour après jour. Donc, foutu pour foutu, autant y aller à fond et c'est pour cela qu'aujourd'hui, je vais vous parler de l'application Deja.

Deja est un outil de remplacement intelligent pour un autre outil dont je vous ai déjà parlé qui s'appelle ZSH Auto Suggestions qui va carrément deviner votre prochaine commande ZSH. C'est un truc qui fait donc de la prédiction de commande. Pour l'installer, vous pouvez passer par homebrew ou curl et hop, comme par magie, ce sera intégré directement à votre fichier .zshrc. Ensuite, vous rechargez votre terminal et c'est parti.

Deja remplace zsh-autosuggestions, le plugin de complétion dont dépend aussi zsh-copilot , donc il ne faut surtout pas garder les deux dans votre plugins=(). En effet, les deux réécrivent les mêmes widgets ZLE, et heureusement, quand deja détecte que l'autre est chargé, il affiche une ligne d'avertissement et se met en retrait plutôt que de coincer votre éditeur de ligne. Si vous gérez votre zsh avec Oh My Zsh ou zinit, il existe aussi une intégration dédiée pour chacun, et dans ce cas il faut enlever la ligne eval que l'installeur a ajoutée au .zshrc, sinon l'intégration est chargée deux fois.

Autre chose à savoir tout de suite, sinon vous allez chercher un moment : la suggestion s'accepte avec la flèche droite, pas avec Entrée (ça c'est pour envoyer la commande). Ensuite, Ctrl et flèche droite n'acceptent que le mot suivant, Tab ouvre la liste des alternatives classées sans quitter la ligne, et Ctrl+X coupe les suggestions pour toute la session.

Ça se base sur tout un tas de paramètres que je ne vais pas tous vous lister, mais en gros Deja est au courant du répertoire où vous êtes. Ensuite, si vous tapez des commandes mal fichues, il sera capable de vous en suggérer qui devraient correspondre à votre besoin. Et puis après, il y a l'historique et un score de fréquence ce qui fait que l'outil est vraiment hyper prédictif. Il n'y a pas d'IA derrière, c'est vraiment de l'algorithmie pure, mais ça rend bien des services. Surtout si vous tapez à peu près tout le temps les mêmes commandes au même moment, aux mêmes endroits.

Par exemple, l'outil retient que vous lancez make test après make build, et pondère la suggestion en conséquence. Les quatre signaux, correspondance floue, fréquence combinée à la récence avec une demi-vie d'une semaine, affinité avec le répertoire courant et probabilité d'enchaînement, sont fondus dans un score unique.

Le "flou", lui, se règle en trois crans selon l'écart toléré entre les lettres que vous tapez. Tight n'en laisse passer qu'un seul, smart jusqu'à quatre (c'est le réglage par défaut), et loose jusqu'à huit. En smart, taper par exemple gco proposera git checkout main ; alors qu'en loose, ça partira chercher beaucoup plus loin. Et Shift + flèche droite permet de passer au cran de "flou" suivant sans quitter la ligne.

Bref, je pense que ça va vous faire gagner un max de temps.

deja est publié sous licence MIT, se pose sur macOS et Linux, et ne connaît que zsh. Et si l'essai ne vous convainc pas, la désinstallation se fait en 4 étapes : enlever la ligne eval du .zshrc, tuer le démon avec pkill -f 'deja daemon', supprimer ~/.local/share/deja/, puis retirer le binaire avec brew uninstall deja ou, si vous êtes passé par le script curl, en supprimant le fichier posé dans ~/.local/bin/.

Si vous avez un Raspberry Pi et que Chromium commence à vous fatiguer, le VRAI Chrome, celui des chads que vous êtes, est enfin dispo en ARM64 !! Enfin, dispo... Si vous savez où chercher, parce que la page de téléchargement de Google vous propose toujours l'installeur amd64, qui ne tournera jamais sur votre machine. C'est Joey Sneddon, d'OMG! Ubuntu, qui a trouvé la combine en bidouillant l'URL depuis son Pi 5.

Avant toute chose, vérifiez que vous êtes bien en 64 bits, parce qu'un système 32 bits refusera le paquet :

dpkg --print-architecture

Si ça répond arm64, le fichier est là , 126 Mo. Il s'installe comme n'importe quel .deb local, en laissant apt gérer les dépendances :

wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb
sudo apt install ./google-chrome-stable_current_arm64.deb

Le RPM existe aussi pour les distributions qui préfèrent, en remplaçant la fin du nom par aarch64.rpm.

J'ai ouvert le paquet pour regarder ce qu'il y avait dedans. Son fichier de contrôle annonce google-chrome-stable en version 150.0.7871.186, architecture arm64, un peu plus de 400 Mo une fois installé. Soit exactement la même version que le paquet x86 poussé le même soir. Le même Chrome, à la même révision.

Et le canal stable n'est pas seul. Le dépôt de Google sert aussi la beta (151.0.7922.47), la dev (152.0.7967.2) et la canary (152.0.7974.0) pour les puces ARM, et son fichier Release déclare noir sur blanc les deux architectures. Les quatre canaux ont été publiés dans la même minute que leurs équivalents x86.

Est-ce qu'on se retrouve coincé sur cette version, à re-télécharger le .deb à la main tous les mois ? Non. Le script de post-installation contenu dans le paquet ajoute le dépôt Google en précisant l'architecture, et les cinq paquets y sont indexés en arm64 exactement comme en x86. Les mises à jour ont donc de quoi arriver par apt, comme d'habitude.

Alors pourquoi s'embêter, puisque Chromium tourne sur ARM depuis des années ? Pour deux trucs. D'abord ma synchro du compte Google, qui ramène favoris, mots de passe et extensions. Et ensuite, Widevine, le module DRM, qui est ici un vrai binaire aarch64 et pas une couche de compatibilité comme l'émulateur FEX financé par Valve . Netflix et les autres plateformes à DRM s'ouvriront enfin sur un SBC !!!

Mais avec une nuance à connaître avant de vous réjouir qui est que sous Linux, Widevine reste au niveau "Software Secure". Cela veut dire que sur Netflix, la qualité plafonnera entre 720p et 1080p. De la HD donc et pas de la 4K. Désoléééé !

Google avait promis tout ça en mars, pour le deuxième trimestre et son billet annonçait même une installation via chrome.com/download pour les autres distributions, ce qui est malheureusement le morceau qui manque aujourd'hui.

Cela veut dire aussi que rien ne garantit que ce paquet soit considéré comme étant prêt par ses auteurs donc si votre machine doit rester stable, laissez passer quelques semaines avant de vous y essayer.

Manque plus que quelqu'un chez Google ait le courage d'appuyer sur "publier".

Source

La carte graphique minimum dont on a besoin pour émuler une PS3 est sortie... après la PS3. C'est AniLeo et kd-11, de l'équipe RPCS3 , qui viennent de descendre le minimum officiel de l'émulateur à la Radeon HD 2900 XT, sortie en mai 2007. La PS3, elle, arrivait en France en mars de la même année.

Certes, c'est moins de deux mois d'écart mais pour émuler une console, en général, on a besoin de matériel largement postérieur.

RPCS3 accepte donc maintenant les Radeon HD 2000, 3000 et 4000, la première génération TeraScale d'ATi. Le plancher précédent, c'était la HD 5550. Deux conditions quand même : ça ne marche que sous Linux, avec le pilote libre Mesa r600. Windows reste dehors, le vieux pilote d'AMD étant trop bancal pour l'émulateur.

Maintenant, ce qui bloquait vraiment n'était pas la puissance. L'émulateur tenait pour acquis que toutes les cartes qu'il supporte savent faire un certain type d'écriture en mémoire. Ces vieilles Radeon ne savent pas, et personne n'avait prévu le cas, alors l'affichage plantait dès le démarrage, sur un pointeur nul... snif. Le correctif consiste donc à vérifier si la carte sait le faire, et à s'en passer quand ce n'est pas le cas. Et voilà, une pull request plus tard et c'était du tout bon pour la Radeon HD 2900 XT !

Reste que la plus musclée de ces vieilles puces, la HD 4890 de 2009 avec son gigaoctet de mémoire, donne des résultats à géométrie très variable. Sur les captures de l'équipe, OutRun Online Arcade tourne entre 52 et 59 fps, et Metal Gear Solid HD Collection oscille entre 45 et 60 selon la densité de la scène. Jusque-là, ça va.

Par contre, la démo de FIFA 08 tombe à 15 fps, et le jeu Rain à 15 aussi, et là c'est la cata. Cette HD 4890 est pourtant plusieurs fois plus puissante que le RSX, la puce graphique de la PS3, mais ça ne suffit pas, parce que l'émulateur lui refile du boulot que la console ne lui demandait pas, comme décoder les textures à la place du processeur. Et surtout, parce que la mémoire n'est pas rangée pareil.

Sur PS3, la mémoire vidéo et la mémoire système sont bien deux réservoirs séparés, sauf que les jeux ont le droit de piocher directement dans les deux. Tout est à portée de main. Sur PC, les deux sont vraiment cloisonnés, du coup l'émulateur passe son temps à recopier les données de l'un vers l'autre.

En descendant dans la gamme, la sanction est immédiate. La HD 3870 doit tomber à 273p, l'équivalent d'une PSP, pour afficher les jeux les plus simples. La HD 2600 XT, elle, plafonne à 12,9 fps sur Portal à cette même définition. Bref, ça ne sert plus à rien de descendre plus bas, celle-là est carrément plus faible que la puce de la console qu'elle est censée émuler.

Côté manipulation, il faut mentir au pilote. Ces cartes annoncent une version d'OpenGL trop ancienne, et l'émulateur refuse de démarrer tant qu'il la voit. Deux variables d'environnement au lancement suffisent à lui faire croire le contraire :

MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=440 ./rpcs3.AppImage

Et si ça plante encore, l'équipe conseille de basculer le réglage Shader Mode sur "Legacy Recompiler".

Je vous parlais de RPCS3 en 2021 quand il servait surtout à rendre les vieux jeux plus beaux avec le FSR d'AMD et voilà maintenant qu'il sait les faire tourner sur du matériel de leur époque.

Le billet de l'équipe , que je vous invite à lire, détaille les réglages et les résultats carte par carte. Si vous avez une TeraScale au fond d'un placard, vous savez quoi en faire.

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

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

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

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

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

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

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

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

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

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

Votre clé 4G ou Wifi que vous avez connectée en USB sur un vieux serveur situé au fond du garage, plante une fois ou deux fois par semaine et à chaque fois faut aller débrancher la clé et la rebrancher pour la réveiller / ressusciter ? Et bien c'est fini la galère les amis, puisque uhubctl règle ça en une commande. Cet outil coupe puis rallume le courant d'un port USB précis, sans que vous n'ayez à toucher au moindre câble.

C'est donc un petit utilitaire en ligne de commande, écrit en C par Vadim Mikhailov, qui pilote l'alimentation électrique de vos ports USB un par un. uhubctl -a off -p 2 éteint le port 2, -a on le rallume, et -a cycle enchaîne les deux avec une petite pause au milieu. C'est pile-poil ce qu'il faut pour rebooter par exemple un modem 4G figé ou une webcam qui ne répond plus.

Par contre, désolé mais ça ne fonctionne pas sur n'importe quel hub USB. Il vous faut un hub intelligent qui gère le per-port power switching, autrement dit capable de couper le jus d'un seul port sans toucher aux autres. Rassurez-vous, si vous ne savez pas quoi acheter, le projet maintient une liste de modèles compatibles que vous pouvez consulter ici .

Après y'a certains hubs qui coupent bien la connexion data mais laissent passer le courant (le fameux VBUS). Du coup vous croyez avoir éteint le port, et le téléphone branché dessus continue tranquillement de charger. Alors pour vérifier, branchez un ventilo ou une petite lampe USB et lancez la coupure. Si ça s'arrête vraiment, votre hub est bon. Sinon il sait uniquement couper la data, et pas l'alim.

Mais en tout cas, une fois le bon matériel entre les mains, les usages deviennent vraiment sympas ! Par exemple, avoir un disque dur USB alimenté seulement quand vous en avez besoin, histoire de tuer le phantom load qui bouffe du courant pour rien (pensez juste à bien le démonter avant de couper le jus, sinon bonjour la corruption ^^).

Y'a aussi le cluster de Raspberry Pi que vous allumez et éteignez nœud par nœud. Ou encore un plugin OctoPrint qui coupe l'alim USB de l'imprimante 3D une fois l'impression finie. Y'a même des bidouilleurs qui pilotent un ventilo ou une guirlande LED avec.

Côté installation, rien de méchant : apt install uhubctl sur Debian, Ubuntu et Raspbian, brew install uhubctl sur Mac. Sous Linux il faudra passer par sudo ou poser une règle udev pour les permissions, sinon l'outil râlera. Sur Windows par contre, laissez tomber pour la coupure d'alim. Le driver USB de Microsoft ne laisse pas passer la commande, donc uhubctl compile mais n'éteint rien du tout.

Et si vous visez le Raspberry Pi, gardez un œil sur ses bizarreries car sur pas mal de modèles, tous les ports sont liés. Si vous en coupez un, vous les coupez tous. La parade classique, c'est donc de brancher un vrai hub compatible sur le Pi et de piloter ses ports à lui.

Et si vous cherchez quoi en faire côté DIY de votre Pi, j'avais listé 130 idées pour votre Raspberry Pi qui se marient bien avec ce genre de contrôle à distance.

Bref, si vous bricolez de la domotique ou un rack de Raspberry Pi, vérifiez d'abord votre hub, puis foncez. C'est gratuit, open source et ça évite pas mal d'allers-retours vers la multiprise.

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

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

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

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

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

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

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

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

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

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

Source

NVIDIA a débranché GameStream, son système maison pour envoyer les jeux de votre PC vers une Shield ou un laptop. Sauf que le protocole, lui, n'est pas mort : Moonlight , le client open source qui le réimplémente, tourne toujours sur Windows, macOS, Linux, Steam Link, Raspberry Pi 4, Apple TV et Xbox, et même sur des Switch et des Vita en homebrew.

Et surtout, Hans Gaiser bricole depuis début 2024 une pièce qui manquait côté serveur, Moonshine , qui commence à être sérieusement utilisable.

Moonlight n'étant qu'un client, il affiche l'image et renvoie votre clavier, votre souris et votre manette. Derrière, il faut donc forcément une machine qui capture le jeu et qui encode la vidéo en temps réel.

Bref, comme je vous le disais, depuis que NVIDIA a rangé GameStream au placard début 2023, ce rôle revient à des serveurs communautaires. Le seul que la FAQ Moonlight recommande, c'est Sunshine , du collectif LizardByte. C'est codé en C++ sous licence GPL-3 et ça tourne sous Windows, Linux, macOS et FreeBSD. Sauf que Sunshine capture une session de bureau existante ce qui veut dire que sur une machine sans écran, il faut composer avec ça, et c'est de là que vient toute la littérature sur les dongles HDMI factices et autres écrans virtuels...

Alors que Moonshine, lui, est codé en Rust et prend un autre chemin. En fait, chaque session de streaming tourne dans son propre environnement isolé, qui est totalement séparé de votre bureau. Du coup, vous n'avez plus besoin de session active du tout... Une simple tour sans écran fera parfaitement le boulot.

Voilà, si vous avez une machine Linux qui dort dans votre placard avec un GPU dedans, ça peut vous permettre de lancer Moonlight depuis votre canapé à distance, et c'est le serveur qui gérera la session rien que pour vous.

Après, c'est du Linux uniquement, testé sur Arch même si ça remonte que ça tourne aussi sur d'autres distribs, avec systemd obligatoire pour lancer et gérer tout ce qui est processus. Et du côté du GPU, il vous faudra de l'encodage vidéo Vulkan, donc, vous l'aurez compris, une Nvidia RTX ou une AMD RDNA2 ou plus récente, voire une Intel Arc pour les plus motivés.

Voilà, toutes vos vieilles GTX resteront sur le banc de touches... Sans oublier que vous aurez besoin du client Moonlight en version 6.0.0 minimum et que la compatibilité avec les portages non officiels n'est pas garantie.

Les codecs supportés, c'est du H.264, H.265 et AV1, avec du HDR en 10 bits. L'AV1 est marqué expérimental et Hans Gaiser prévient lui-même qu'il fait gonfler la taille des images au fil du temps sur les cartes NVIDIA. Sauf que c'est réglé depuis : NVIDIA a sorti le correctif dans son pilote Vulkan beta 595.44.3.0 et Hans Gaiser a confirmé début avril, mesures à l'appui, que la qualité était revenue à la normale. Son README, lui, n'a pas suivi et vous conseille encore de rester en H.264 ou H.265. Donc si l'AV1 vous tente, prévoyez le pilote Vulkan beta, pas celui de votre distrib.

Notez aussi que Moonshine n'est pas conçu pour être utilisé sur des réseaux publics puisque le protocole GameStream sous-jacent a des limites qui font que le trafic n'est pas entièrement chiffré au niveau applicatif. Donc, si vous vous y mettez, n'exposez jamais les ports de Moonshine directement sur internet. Préférez passer par Tailscale ou un WireGuard par exemple.

Bref, Moonlight, Sunshine, Moonshine... si comme moi, vous vous emmêlez dans les noms, c'est parfaitement normal. N'empêche que c'est un super truc, encore en dev, certes, mais ça promet pour le futur...

Source

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

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

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

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

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

Une demi-seconde.

C'est le retard qu'ont pris les connexions SSH d'Andres Freund, ingénieur chez Microsoft, lors d'un benchmark de routine en mars 2024. Cette demi-seconde, Adrian Mastronardi, CTO de Habi et linuxien depuis 1996, vient d'en tirer un bouquin gratuit, Half a Second , qui raconte toute l'affaire XZ du début à la fin.

La plupart des gens auraient haussé les épaules mais lui, non. Il a tiré le fil, encore et encore, et a fini par déterrer une des backdoors les plus tordues jamais glissées dans un logiciel open source.

Half a Second, le livre gratuit d'Adrian Mastronardi sur le backdoor XZ

Pour ceux qui auraient loupé l'épisode, XZ Utils c'est un outil de compression qu'on retrouve sur à peu près tous les systèmes Linux, serveurs compris, donc autant dire une bonne partie d'Internet.

L'attaquant, lui, a joué le contributeur modèle pendant environ 2 ans. Gagner patiemment la confiance du mainteneur, puis glisser sa backdoor dans le code. Je vous en parlais à chaud à l'époque , le jour même de la découverte et quelqu'un avait même bricolé dans la foulée un agent SSH exploitant cette backdoor .

Mais la technique, dans ce livre, c'est presque secondaire. Le vrai sujet est dans le sous-titre : le travail invisible qu'il y a en dessous. Lasse Collin, le mainteneur de XZ, portait ce projet critique tout seul, bénévolement, et il était au bout du rouleau. Et c'est précisément cet épuisement que l'attaquant a retourné contre lui. Entre la pression des utilisateurs, les faux contributeurs qui râlent, la culpabilisation de ne pas pouvoir faire mieux tout de suite tout le temps.… Le mec a été intoxiqué / manipulé avant même que la moindre ligne de code.

Et des gars comme Lasse Collin, il y en a des milliers. Il y a des tas de gens qui maintiennent seuls gratuitement sur leur temps libre, des petites briques libres dont dépendent nos banques, nos hôpitaux, nos administrations et personne ne les paye, voire pire, personne ne les considère ni leur dit merci.

Et cela fait deux des proies faciles pour des attaquants bien organisés. Concernant le bouquin, rien à redire, la bibliographie s'appuie sur les rapports de l'OpenSSF, d'Akamai ou encore de Binarly. C'est une vraie enquête extrêmement bien sourcée qui ne tombe pas dans le charabaiat technique, ce qui fait que c'est parfaitement lisible pour tout le monde, même pour ceux dont la sécurité informatique n'est pas la spécialité.

Et le récit mélange les trois voix, celle du narrateur manipulé, celle de l'ingénieur curieux et celle de l'opérateur fantôme. Parce que oui je sais pas si vous savez, mais celui qui a fait cette backdoor n'a jamais été identifié et ne le sera peut-être jamais. Voilà, ça a l'air d'être un chouette bouquin distribué sous licence créative Commons non commercial. C'est donc gratuit et ça le restera pour toujours.Par contre, c'est en anglais, donc faudra faire un petit effort. Mais n'importe qui peut le traduire si ça l'amuse.

Bref, si l'affaire XZ vous avait marqués, c'est le récit qu'il vous fallait.

À lire ici en PDF ! Et merci à LWN d'avoir repéré le bouquin.

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

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

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

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

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

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

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

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

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

Source : ARS Technica