Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Ce kit de phishing ouvre les comptes Microsoft 365 sans voler le mot de passe

Voler un mot de passe ? C'est presque devenu accessoire. Le FBI a lancé une alerte sur Kali365, un kit de piratage qui s'introduit dans les comptes Microsoft 365 d'une entreprise sans jamais avoir besoin du mot de passe, ni du fameux code de la double authentification.

La protection que beaucoup imaginent solide ne sert plus à grand-chose ici. Hélas.

Kali365 n'est pas un virus classique. C'est ce qu'on appelle un kit de phishing en location : un service clé en main, vendu un peu comme un abonnement à un logiciel, sauf qu'il sert à pirater. Repéré depuis avril et distribué via la messagerie Telegram, il permet à n'importe quel apprenti pirate de lancer une campagne sans compétences techniques particulières. Le kit fournit les emails piégés rédigés par une IA, des modèles de campagne tout prêts, et même un tableau de bord pour suivre ses victimes en temps réel, la totale donc.

Cette méthode porte un nom, le device code phishing, et elle est redoutable de simplicité. La victime reçoit un email qui imite un service de partage de documents, avec un petit code et une consigne : aller sur une page Microsoft pour rentrer le code. Sauf que cette page-là est la vraie page de Microsoft, du coup zéro méfiance.

Rien à signaler du côté de l'antivirus, rien de suspect dans l'adresse du site. La personne entre le code en toute confiance. Et là, sans s'en rendre compte, elle vient d'autoriser l'appareil du pirate à se connecter à son compte.

À partir de là, l'attaquant récupère un jeton d'accès, ce que le jargon appelle un token OAuth. C'est un laissez-passer numérique : une fois qu'on l'a, plus besoin du mot de passe ni d'un nouveau code pour entrer.

Avec ce jeton, le pirate conserve un accès continu à la boîte mail Outlook, à la messagerie Teams et au stockage OneDrive de sa victime. Et comme il n'a jamais touché au mot de passe, le réinitialiser en urgence ne bloque même pas l'intrus.

Le procédé n'a rien de marginal. Sur des campagnes de ce genre, des chercheurs en sécurité ont compté des centaines de comptes piégés chaque jour, avec une nette préférence pour les profils liés à la paie et à la comptabilité, là où l'argent circule le plus.

Le FBI conseille aux entreprises de carrément désactiver ce mode de connexion par code dans les réglages d'administration de Microsoft. Encore faut-il que les services informatiques prennent le temps de s'en occuper.

Source : The Register

Fabriquer un circuit imprimé sans aucun logiciel, juste avec un marqueur

Un bricoleur connu sous le pseudo ALTco a fabriqué un circuit imprimé sans toucher au moindre logiciel. Pas de conception sur ordinateur, pas de commande envoyée à une usine. Juste un marqueur, une plaque de cuivre et un bain chimique. Rien d'autre.

La méthode date d'avant l'informatique, et elle fonctionne toujours aussi bien.

Le circuit imprimé, c'est cette plaque qu'on trouve dans absolument tous les appareils électroniques : sur sa surface courent de fines pistes de cuivre qui relient les composants entre eux.

Aujourd'hui, on les dessine sur un logiciel spécialisé, le logiciel EDA (conception électronique assistée par ordinateur), avant de transmettre le fichier à un fabricant qui se charge du reste. ALTco a tout simplement zappé cette étape.

Sa méthode tient en quelques gestes. Il part d'une plaque de cuivre brut, qu'il nettoie soigneusement pour que l'encre accroche bien. Puis il dessine directement les pistes du circuit à la main, au marqueur permanent.

La plaque part ensuite tremper plusieurs minutes dans un bain de perchlorure de fer, un produit chimique qui ronge le cuivre. Le marqueur, lui, protège le cuivre qu'il recouvre, et tout le reste finit dissous. Il ne reste plus qu'à rincer à l'eau puis à l'alcool pour effacer le marqueur, et le circuit apparaît.

Avant d'arriver à ce résultat propre, ALTco a pas mal tâtonné. Il a testé différents marqueurs et peintures censés résister à la gravure, et même des produits gravants faits maison, avant de revenir au perchlorure de fer, le grand classique du genre.

Le circuit qui sort de tout ça n'est pas un gadget de démonstration : c'est un petit contrôleur de ventilateur, qui pilotera un absorbeur de fumée pour ses séances de soudure.

On peut se demander pourquoi s'embêter avec ça, alors qu'une plaque propre coûte quelques euros chez un fabricant.

Pour une petite carte unique, faite chez soi en une après-midi, ça évite d'attendre une livraison et de passer par une commande minimum par exemple. Et puis il y a le plaisir de fabriquer soi-même, du début à la fin.

Le plus étonnant arrive à la fin. Un tracé fait main peut être électriquement meilleur qu'un tracé parfait. Les pistes dessinées au marqueur forment des courbes douces, là où un logiciel génère souvent des angles bien nets. Or ces angles renvoient une partie du signal électrique vers l'arrière, un peu comme un écho qui rebondit.

Les courbes, elles, laissent le signal filer sans accroc. Sur des circuits rapides, ça change vraiment quelque chose.

Bref, une méthode lente, salissante et imprécise. Mais voir un circuit naître d'un marqueur et d'un bac de liquide, c'est quand même autre chose qu'un produit expédié en usine.

Source : Huckster.io

Il a recréé la veste à écran de Cyberpunk 2077

Dans le jeu Cyberpunk 2077, un des vêtements qui marquent l'environnement visuel, c'est cette veste avec un petit écran intégré dans le col, qui diffuse des images en boucle.

Un objet purement décoratif du jeu, le genre de détail qui pose l'ambiance futuriste sans qu'on puisse vraiment l'avoir. Sauf qu'un bidouilleur connu sous le pseudo Zibartas a décidé qu'il en voulait une, pour de vrai. Il l'a fabriquée. Et le résultat colle de très près au modèle vu dans le jeu.

Il y a d'abord quatre écrans OLED flexibles, c'est-à-dire des dalles capables de se courber légèrement, contrairement à un écran de smartphone classique qui est rigide. Chacune a un format allongé, façon téléphone, et coûte autour de 300 dollars pièce.

Faites le calcul : rien que pour les écrans, la facture grimpe à 1200 dollars. Autant dire que ce n'est pas le genre de bricolage qu'on lance un dimanche après-midi sans réfléchir.

Pour faire tourner tout ça, Zibartas a glissé deux Raspberry Pi 4, ces mini-ordinateurs de la taille d'une carte bancaire qu'on retrouve dans une bonne partie des projets de bidouille électronique. Un Pi gère une paire d'écrans, le second s'occupe de l'autre paire.

Le problème, c'est de garder les quatre dalles synchronisées pour que la vidéo défile partout en même temps, sans décalage. La solution choisie est simple : les deux Raspberry Pi communiquent entre eux via leurs broches GPIO, ces petites pattes de connexion qui servent normalement à brancher des composants, histoire de se mettre d'accord sur le tempo. Le Pi 4, pourtant un modèle plus ancien, a été choisi volontairement car il permet une astuce technique précise pour diffuser une vidéo bien fluide sur deux écrans à la fois.

Pour les couture, la veste n'a pas été achetée puis modifiée : elle a été cousue entièrement de zéro pour ce projet. Le vrai défi, c'était de loger les écrans dans le grand col sans qu'ils se cassent au moindre mouvement. Zibartas a donc imprimé en 3D une structure rigide pour les caler et les protéger. Détail un peu rigolo : une fois installés, les écrans flexibles ne plient quasiment plus. Leur souplesse aura surtout servi pendant le montage, pour les manipuler sans les briser.

Le projet laisse quand même une question de côté : l'autonomie. Deux Raspberry Pi et quatre écrans OLED, ça consomme, et il faut donc trimballer une batterie quelque part sur soi. Tenir une soirée entière avec la veste allumée risque d'être un peu tendax. Pour une démo ou une convention cosplay, par contre, c'est carrément rigolo.

Source : Hackaday

Ce petit gadget DIY vous prédit l'avenir quand vous le secouez

Le maker connu sous le pseudo gokux a fabriqué un objet aussi inutile que mignon : un fortune cookie électronique. Vous le secouez, et il affiche une prédiction sur son petit écran. Voilà, c'est tout. Et c'est très bien comme ça.

Sous le capot, c'est un condensé de composants accessibles. Le cerveau, c'est un Seeed Xiao ESP32-S3 Plus, un microcontrôleur minuscule, autrement dit une puce programmable qui fait tourner le tout.

L'affichage passe par un écran e-paper, le même type d'écran que sur une liseuse, qui ne consomme du courant que pour changer d'image. Pour détecter quand vous secouez l'objet, gokux a ajouté un accéléromètre MPU-6050, le capteur de mouvement qu'on trouve dans les manettes et les téléphones.

Et une petite batterie Li-Po alimente l'ensemble. Rien d'introuvable, tout se commande en ligne pour une poignée d'euros.

Le bon point, c'est que tout est embarqué. Le gadget stocke plus de 3 000 prédictions et fonctionne entièrement hors ligne, donc pas besoin de connexion, pas de serveur, pas d'appli.

Votre oracle de poche marche même au fond d'une cave. L'écran e-paper apporte un vrai plus ici : une fois la prédiction affichée, elle reste lisible même batterie vide, comme une vraie page de papier. Et gokux n'a pas oublié de glisser deux modes bonus, accessibles via les boutons sur le côté : un lanceur de dés et un tirage à pile ou face. De quoi régler vos petits dilemmes du quotidien sans même sortir le téléphone.

Le projet est entièrement documenté sur Instructables , vous y trouvez la liste des pièces, le câblage, les fichiers à imprimer en 3D, le code et même les instructions pour ajouter vos propres prédictions. Comptez quelques dizaines d'euros de composants et une soirée de montage, pas plus. C'est le projet idéal à offrir, ou à bricoler avec un ado curieux d'électronique.

Et comme le code est ouvert, rien ne vous empêche de remplacer les 3 000 messages d'origine par vos propres blagues, citations ou vannes pour vos collègues. C'est exactement le genre de projet parfait pour débuter, assez simple pour ne pas décourager, assez complet pour apprendre à manipuler un ESP32 et un écran e-paper en même temps.

Bref, ça ne sert objectivement à rien, et c'est précisément pour ça qu'on a envie d'en monter un.

Source : Hackaday

Une console rétro "Lenovo" à 72 dollars, bourrée de ROMs Nintendo piratées

Une console de jeu portable estampillée Lenovo est apparue sur AliExpress à environ 72 dollars, et elle a un détail embarrassant : elle est livrée avec des milliers de jeux Nintendo piratés préinstallés. Le genre de produit qu'on prendrait pour une contrefaçon. Sauf que non.

Interrogé sur cette G02, Lenovo a confirmé que la console est bien officielle. C'est ce qu'on appelle un produit en marque blanche : Lenovo n'a pas conçu l'appareil, mais a accordé une licence d'utilisation de son nom à un fabricant tiers, via un accord régional réservé au marché chinois.

La G02 ne fait pas partie du catalogue mondial de Lenovo, mais elle porte bel et bien son logo, en toute légalité côté marque. C'est un modèle courant : une marque connue loue son nom, un fabricant local s'occupe du reste.

Le problème, c'est ce qu'il y a dedans. La console démarre avec le branding Lenovo, puis donne accès à des milliers de ROMs, ces copies de jeux rétro, en grande majorité des titres Nintendo.

Et là, plus de zone grise : il est hautement improbable que ces jeux soient sous licence. Nintendo est sans doute l'éditeur le plus féroce de l'industrie quand il s'agit de défendre sa propriété intellectuelle, et la firme a déjà fait fermer des dizaines de projets d'émulation à coups d'avocats.

Pour l'acheteur, l'affaire est presque trop belle : une machine de rétrogaming à 72 dollars, le logo d'un géant de l'informatique, et une ludothèque entière offerte. Sauf que cette ludothèque, personne ne l'a payée aux ayants droit.

Et la console continue de se vendre tranquillement sur AliExpress, accessible aux acheteurs chinois comme au reste du monde.

Du coup, Lenovo se retrouve dans une position franchement inconfortable. Son nom, validé par un contrat officiel, s'affiche sur un appareil qui distribue du jeu piraté à l'échelle industrielle. C'est précisément le risque du modèle de la marque blanche : vous touchez une redevance pour prêter votre logo, mais vous ne contrôlez pas toujours ce que le partenaire met dans la boîte.

Quelque part en Asie, un service juridique doit déjà transpirer.

Source : Tom's Hardware

Android 17 travaille sur sa version de "Continuité" d'Apple

Android 17 va donc lancer une fonction baptisée "Continue On", et l'idée est simple : reprendre une appli exactement là où vous l'avez laissée, mais sur un autre appareil.

Vous lisez un document sur votre téléphone, vous attrapez votre tablette, et hop, vous repartez au même endroit sans rien chercher. Les utilisateurs d'iPhone connaissent déjà ça sous le nom de Handoff (Continuité en français). Android s'y met enfin.

En pratique, c'est plutôt bien pensé. Quand vous vous approchez d'un autre appareil Android compatible, une petite suggestion apparaît dans la barre des tâches pour ouvrir la même appli, et un simple appui fait reprendre l'activité pile où vous en étiez. Le système marche dans les deux sens, sans appareil principal : n'importe quel appareil compatible peut aussi bien envoyer que recevoir. Pas de hiérarchie particulière, pas de réglage à bidouiller.

Google donne deux exemples. Un document Google Docs ouvert sur le téléphone se rouvre dans le même onglet sur la tablette. Un fil de discussion Gmail passe du téléphone vers la version web de Gmail sur la tablette.

Et il y a une bonne idée derrière : le repli vers le web. Si l'appareil qui reçoit n'a pas l'appli installée, c'est la version web qui s'ouvre à la place. Les développeurs doivent activer cette option, mais ça évite le mur du "appli non installée" qui casserait tout l'intérêt du truc.

Il y a quand même une grosse limite pour l'instant. "Continue On" ne marche qu'entre un mobile et une tablette. Pas de transfert vers un ordinateur, pas de passage vers une autre marque, pas même entre deux téléphones.

Google promet d'élargir les combinaisons d'appareils plus tard, sans donner de date. Et le tout arrive avec Android 17, encore en bêta, pour le moment réservé aux possesseurs de Pixel via la version de test QPR1 Beta 1.

La vraie inconnue, c'est l'adoption. La fonction sera là, la documentation pour les développeurs aussi, mais il faudra que les applis du quotidien jouent le jeu.

Une fonction de continuité, ça ne vaut rien si seulement trois applis la gèrent. Apple a mis des années à bien installer Handoff dans les habitudes, et Google part de plus loin avec un écosystème Android beaucoup plus éclaté.

Source : Ghacks

Le bac à sable de Claude Code avait deux failles, et c'est plus gênant qu'il n'y paraît

Anthropic, l'entreprise derrière l'IA Claude, a corrigé en douce deux failles dans le bac à sable réseau de Claude Code, son assistant de programmation. Un bac à sable, dans le jargon, c'est un enclos de sécurité : il est censé empêcher l'outil de se connecter à des serveurs non autorisés, pour éviter qu'il envoie vos données n'importe où. Sauf que pendant cinq mois et demi, cet enclos avait une porte dérobée.

La plus récente faille est en fait une jolie bidouille. Claude Code vous laisse définir une liste blanche, par exemple "autorise uniquement les connexions vers *.google.com". Un attaquant envoyait alors une adresse du genre "serveur-pirate.com<a target="_blank" rel="noreferrer noopener" href="http://0.google.com/">0.google.com", avec un caractère invisible (un octet nul) glissé au milieu.

Le filtre de sécurité, lui, lit la fin de la chaîne, voit ".google.com" et valide. Mais le système d'exploitation s'arrête au caractère invisible et se connecte en réalité à serveur-pirate.com. Le filtre et le système ne lisent pas la même adresse. La faille est là.

Combinée à une injection de prompt (le fait de cacher des instructions piégées dans un texte que l'IA va lire), la faille permettait d'exfiltrer des choses sensibles : identifiants cloud, jetons d'accès GitHub, accès aux services internes.

En clair, un dépôt de code piégé pouvait pousser Claude Code à expédier vos secrets vers le serveur de l'attaquant. Le trou a traversé plus de 130 versions de l'outil avant d'être bouché fin mars. Tout utilisateur de Claude Code qui faisait confiance à son bac à sable réseau était donc exposé sans le savoir, du développeur isolé à l'équipe en entreprise.

C'est le chercheur Aonan Guan, de Wyze Labs, qui a remonté le problème. Et sa phrase résume tout : un bac à sable troué, c'est pire que pas de bac à sable du tout. Celui qui n'a aucune protection le sait et reste prudent. Celui qui se croit protégé baisse la garde.

Anthropic affirme avoir trouvé et corrigé la faille de son côté avant le signalement, mais le souci, c'est qu'il n'y a eu ni CVE (le numéro de référence public qui catalogue une faille), ni note dans le journal des versions. Moche moche.

Source : The Register

Quelqu'un a réussi à faire tourner de vraies fenêtres Linux à l'intérieur de Minecraft

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.

Pour comprendre le délire, un mot sur Wayland. Sous Linux, c'est le système qui gère l'affichage des fenêtres à l'écran, le successeur moderne du vieux X11 qui datait des années 80. Au cœur de Wayland, il y a un compositeur : le programme qui assemble toutes les fenêtres ouvertes pour produire l'image finale que vous voyez sur votre moniteur. Waylandcraft, c'est exactement ça, un compositeur Wayland complet, sauf que la surface d'affichage n'est plus votre écran mais l'univers cubique de Minecraft.

En pratique, vous lancez n'importe quel programme et sa fenêtre apparaît dans la partie, posée où vous voulez, dans l'orientation que vous voulez. Et ce ne sont pas de simples images décoratives collées sur un mur : les fenêtres sont interactives, vous cliquez, vous tapez, vous utilisez le logiciel exactement comme sur un bureau classique. Un bureau Linux qui aurait juste pris la forme d'un monde plein de blocs.

Il faut quand même un peu de préparation : Linux, Minecraft et le chargeur de mods Fabric (l'outil qui permet d'ajouter des mods au jeu), plus quelques bricoles. Et le projet a ses limites. Tout ça ne marche que dans votre propre instance de jeu, impossible de diffuser ces fenêtres aux autres joueurs d'un serveur.

C'est donc une démo solo, à montrer en personne ou en vidéo. Le code est publié en open source sur GitHub, sous licence GPL, donc libre à qui veut d'aller fouiller ou contribuer.

Bref, est-ce que ça sert à quelque chose ? Absolument pas. Est-ce que c'est exactement le genre de bidouille gratuite et brillante qui rend l'informatique amusante ? Complètement.

Source : Hackaday

Ces badges LED de festival se synchronisent tout seuls

Tony Goacher a résolu un petit casse-tête avec élégance. Son projet CrowdClock, ce sont des badges lumineux pour festival qui clignotent tous en rythme, parfaitement synchronisés. Sauf qu'il n'y a aucun badge maître, aucune appli, aucun appairage. Les badges se mettent d'accord tout seuls.

Le truc tient en une technique toute bête. Chaque badge fait tourner sa propre horloge interne et diffuse en continu sa valeur tout autour de lui, via ESP-NOW (un protocole sans fil léger, qui permet à de petits modules de discuter directement entre eux sans passer par le Wi-Fi). Quand un badge capte une valeur d'horloge plus élevée que la sienne, il adopte cette valeur, tout simplement.

Avec cette seule règle, ça fonctionne. Mettez deux groupes de badges désynchronisés dans la même pièce, et en quelques instants tout le monde s'aligne sur l'horloge la plus avancée, puisetdéroule les mêmes animations lumineuses en même temps. D'habitude, synchroniser une flotte d'appareils, ça demande un serveur, une désignation de maître et une négociation en bonne et due forme entre tout ce petit monde. Là, rien de tout ça. Cette absence de mémoire partagée est même ce qui rend le système très solide : un badge qui arrive, qui repart, qui tombe en panne de batterie, rien de tout ça ne flingue la synchro.

Niveau matériel, c'est très accessible : un microcontrôleur ESP32, un anneau de 16 LED RGB adressables (le genre de LED qu'on pilote une par une), une batterie et un support imprimé en 3D. Rien d'exotique, rien de cher. Le code est publié en open source sur GitHub, donc n'importe qui peut reproduire le projet et s'en inspirer. Le tout revient à quelques euros de composants pour chaque badge, de quoi en fabriquer toute une fournée pour un atelier ou un festival.

CrowdClock a été monté avec des jeunes au sein d'une association qui s'appelle Inclusive Bytes, pour un festival. L'idée derrière tout dépasse donc le simple gadget : la foule ne regarde plus le spectacle lumineux, elle le compose. Pour beaucoup de ces jeunes, c'était probablement le premier contact avec les systèmes distribués, et c'est difficile de trouver meilleure démo.

Source : Hackaday

Voilà le MacBook Neo le plus rapide du monde

Sur les sites de benchmark, une petite course s'est lancée autour du MacBook Neo, le portable le moins cher d'Apple. Le but : trouver qui arrivera à le faire tourner le plus vite possible. Et un bricoleur, Salem Techsperts, a brièvement décroché le titre de MacBook Neo le plus rapide du monde, vidéo à l'appui pour montrer comment il s'y est pris.

Le MacBook Neo embarque une puce A18, la même famille que celle qui équipe les iPhone. Et comme tous les appareils mobiles, son ennemi numéro un, c'est le throttling thermique : pour ne pas cuire, la puce baisse volontairement sa vitesse dès qu'elle chauffe trop.

Du coup elle ne tourne jamais vraiment à son plein potentiel. La solution est évidente, il faut la refroidir. Et faire mieux que le refroidissement low-cost d'Apple n'a rien de sorcier, une bonne pâte thermique suffit déjà à gratter quelques points.

Sauf que Techsperts a vu beaucoup, beaucoup plus grand. Il a combiné une pâte thermique à changement de phase (le PTM7950, qui transmet la chaleur bien mieux qu'une pâte classique), un module Peltier (une plaque qui pompe activement la chaleur d'un côté vers l'autre quand on lui envoie du courant), des radiateurs qui pèsent sans doute plus lourd que le laptop lui-même, et une soufflante industrielle en guise de ventilateur. Oui, une vraie soufflante.

À ce stade, ce n'est plus vraiment un ordinateur portable. La carte mère a carrément été sortie du châssis pour être placée dans une sorte de sandwich réfrigérant : refroidie à l'eau par le module Peltier d'un côté, balayée par la soufflante de l'autre.

Pas franchement le genre de machine qu'on glisse dans un sac à dos. Mais ce n'était pas le but. Le portable fin et pratique, Apple l'a déjà fait. Là, l'objectif, c'était la vitesse pure.

Et ça marche. Le montage affiche un score 41% supérieur au MacBook Neo d'origine sur Cinebench, un test de performance classique, avec une puce qui grimpe à 11 watts contre 4 watts en version stock.

Détail amusant, malgré ce carton sur Cinebench, Techsperts n'a pas réussi à battre le meilleur score sur 3DMark, un autre test plutôt axé jeu vidéo. Possible qu'il ait juste tiré une puce un peu moins bonne que la moyenne, ce qu'on appelle la loterie du silicium. Et le record reste fragile, personne n'a encore tenté l'azote liquide sur ce malheureux MacBook.

Bref, transformer un laptop à 600 dollars en glacière de compétition pour gagner 41%, c'est parfaitement inutile. Et j'adore.

Source : Hackaday

Ce PC contient 13 écrans cachés qui diffusent 15 000 GIF en boucle

Un internaute connu sous le pseudo Several-Bar-6512 a transformé son PC de jeu en quelque chose qui n'a pas d'équivalent : à l'intérieur du boîtier, treize écrans diffusent en boucle plus de 15 000 GIF animés. Pas de RGB clignotant classique. Des écrans. Partout.

Le chiffre derrière le projet donne le vertige. Le bricoleur a d'abord téléchargé plus de 17 000 GIF, puis a passé environ 200 heures à les trier, les recadrer, ajuster leur format, leur vitesse d'animation et leur boucle, pour arriver à une sélection finale de plus de 15 000.

Regarder l'intégralité des tuiles, du premier au dernier GIF, prendrait 13 heures et demie. Treize heures et demie de mèmes en boucle dans un boîtier d'ordinateur.

Côté technique, c'est étonnamment débrouillard. Trois cartes Raspberry Pi 5 sont montées dans le boîtier. Les quatre plus grands écrans sont pilotés par ces Raspberry Pi, et les neuf autres lisent leurs vidéos directement depuis des cartes microSD, sans même avoir besoin d'un ordinateur derrière. Et tout ça cohabite avec une vraie config de jeu musclée, carte graphique haut de gamme comprise.

Le bricoleur explique sa démarche simplement : il voulait une machine unique, durable, et dont il pourrait être fier. Sa propre formule résume bien l'esprit du truc, il trouvait que le RGB classique faisait trop sage. Opinion qu'on ne partagera pas forcément mais bon...

Est-ce que c'est raisonnable ? Absolument pas. Plusieurs personnes qui ont vu le build le décrivent comme magnifique et insupportable en même temps, du genre à déclencher une migraine. Mais ce n'est pas le but.

Le but, c'est de posséder un objet que personne d'autre n'a, et là-dessus, mission accomplie. Et puis il y a le facteur découverte : impossible de tout voir d'un coup, vous tomberez toujours sur un GIF oublié que vous n'aviez jamais remarqué.

Bref, pendant que tout le monde se bat pour la config la plus puissante, lui a construit la plus distrayante. Et honnêtement, respect.

Source : PC Gamer

J'ai collé un autocollant de raccourcis macOS sur mon Mac, et c’est génial (existe pour Windows aussi !)

- Contient des liens affiliés Amazon -

Je suis tombé sur un accessoire à moins de 10 euros qui ne paie pas de mine, et que j'utilise pourtant tous les jours depuis que je l'ai reçu. C'est un simple autocollant. Un carré de vinyle transparent d'environ 8 cm de côté, qui liste les raccourcis clavier essentiels de macOS et se colle dans le coin de votre MacBook.

L'idée est bête comme chou. Au lieu d'aller chercher sur Google "comment faire une capture d'écran sur Mac" pour la centième fois, vous baissez les yeux vers le coin de votre clavier et c'est écrit. Cmd+Maj+4 pour capturer une zone de l'écran, Cmd+Espace pour ouvrir la recherche Spotlight, Cmd+Option+Échap pour forcer une application à quitter. Tout est regroupé sur un petit carré.

La pose se fait en deux minutes. Le vinyle est transparent, donc une fois collé sur la coque ou près du trackpad, ça reste discret et ça ne jure pas avec le design du Mac. Synerlogic conseille de dépoussiérer la surface et d'appliquer l'autocollant progressivement pour éviter les bulles d'air (évidemment moi je me suis précipité, donc ça a laissé quelques bulles, mais l'autocollant se repositionne sans mal pour les retirer). Bon point en plus : la colle n'est pas définitive. Vous pouvez retirer l'autocollant sans laisser la moindre trace, ce qui est cool si vous revendez la machine plus tard.

Le vrai intérêt, c'est pour les gens qui débutent sur Mac. Quand on arrive de Windows, les raccourcis changent tous, et c'est un des trucs les plus agaçants de la transition. Avec la liste sous les yeux, l'apprentissage se fait tout seul, sans effort. Au bout de quelques semaines, vous connaissez les raccourcis par cœur et l'autocollant devient un filet de sécurité pour les commandes que vous utilisez moins souvent.

Et si vous êtes sous Windows, Synerlogic décline exactement le même autocollant en version Windows, avec les raccourcis Windows qui vont bien pour gagner en productivité.

Alors oui, ça reste un autocollant. Il liste les raccourcis classiques, pas les combinaisons exotiques d'un développeur ou d'un monteur vidéo. Et si vous maîtrisez déjà votre Mac sur le bout des doigts, il ne vous apprendra rien. Mais à moins de 10 euros, franchement n'hésitez pas. Disponible ici sur Amazon pour macOS , et ici pour Windows !

Anthropic rachète Stainless, l'outil qui fabrique aussi les SDK de ses concurrents

Anthropic, la boîte derrière l'IA Claude, a racheté Stainless pour plus de 300 millions de dollars. Stainless, c'est un nom que le grand public ne connaît pas, mais l'outil est partout : il transforme automatiquement la spécification d'une API, l'interface par laquelle deux logiciels se parlent, en SDK.

Pour rappel, un SDK, c'est un ensemble de bibliothèques de code prêtes à l'emploi pour les développeurs, ici dans une dizaine de langages comme Python, TypeScript, Go ou Java.

En clair, quand un développeur veut brancher son application sur l'API de Claude, il utilise un SDK généré par Stainless. La boîte, fondée en 2022 par un ancien ingénieur de Stripe, a produit chaque SDK officiel d'Anthropic depuis les tout débuts de l'API Claude. Le rachat consolide donc une brique que l'entreprise utilisait déjà tous les jours.

Stainless ne s'arrête pas aux SDK. La société fournit aussi de l'outillage pour les serveurs MCP, le protocole poussé justement par Anthropic qui permet aux IA de se connecter à des outils et des données externes. Du coup le rachat fait sens à double titre : Anthropic met la main sur la génération de SDK et sur une partie de l'infrastructure MCP, deux briques où il veut clairement être central.

Sauf que voilà le détail un peu fou. Stainless ne servait pas qu'Anthropic, et sa liste de clients comprend OpenAI, Google DeepMind, Perplexity, Groq et Cloudflare, autrement dit la plupart des concurrents directs d'Anthropic sur le marché de l'IA.

La suite est sans pitié. Anthropic ferme tous les produits hébergés de Stainless, générateur de SDK compris. Les clients actuels gardent les SDK déjà générés et peuvent les modifier, mais le robinet, lui, est coupé. Tout le monde va devoir trouver une alternative ou rapatrier la génération de SDK en interne.

Pourquoi mettre 300 millions sur la table pour ça ? Parce que la vraie bataille n'est plus seulement sur les modèles d'IA, mais sur la couche d'outillage autour.

Celui qui contrôle la façon dont les développeurs branchent leurs applications et orchestrent leurs agents IA contrôle une partie de l'écosystème. OpenAI muscle son propre Agents SDK de son côté. Anthropic, lui, préfère racheter directement l'usine, et au passage priver ses concurrents d'un fournisseur bien pratique.

Source : TechCrunch

Une faille inconnue dans un routeur Huawei a mis tout le Luxembourg hors ligne pendant 3 heures

Le 23 juillet 2025, le Luxembourg entier s'est retrouvé sans réseau mobile, sans téléphone fixe et sans communications d'urgence pendant plus de trois heures.

Dix mois plus tard, on connaît enfin la cause grâce au média The Record : une faille jusque-là inconnue dans le logiciel d'un routeur Huawei.

Le mécanisme est presque bête. Du trafic réseau spécialement fabriqué a été envoyé vers des routeurs d'entreprise Huawei, et ce trafic les a fait redémarrer en boucle, sans jamais s'arrêter.

Pas besoin de pirater quoi que ce soit ni de voler un mot de passe, il suffisait d'envoyer les bons paquets au bon endroit. Ces routeurs équipaient l'infrastructure de POST Luxembourg, l'opérateur télécom historique du pays. Quand le cœur du réseau redémarre en continu, tout s'effondre derrière. Aucune charge criminelle n'a été retenue, faute de pouvoir désigner un responsable.

Le plus inquiétant, c'est ce qu'on ne sait toujours pas. La vulnérabilité n'a jamais été publiée. Aucun identifiant CVE, le numéro de référence standard qui permet de cataloguer une faille de sécurité, n'a été déposé dans les dix mois qui ont suivi.

On ignore si le trou a été bouché, combien d'autres opérateurs utilisent les mêmes routeurs, et si des équipements identiques sont encore vulnérables aujourd'hui quelque part. Les enquêteurs pensent même que POST n'était pas une cible : le trafic malveillant ne faisait peut-être que transiter par son réseau.

Et là, impossible de ne pas penser à FX Lindner. Ce chercheur en sécurité allemand avait alerté Huawei dès 2012 sur la fragilité de leurs équipements réseau, code bâclé et failles à la pelle.

Huawei avait minimisé. Treize ans plus tard, la même histoire se rejoue, sauf qu'elle ne touche plus un labo de test mais un pays entier, services d'urgence compris.

Ça repose la question de fond, celle de la souveraineté des infrastructures télécom européennes. L'Europe parle de souveraineté numérique depuis des années, surtout sur le cloud et l'IA. Mais les tuyaux eux-mêmes, les routeurs qui font transiter les appels et les données, restent souvent du matériel dont le code source échappe totalement aux opérateurs.

Faire tourner le réseau national d'un pays sur des routeurs dont on ne maîtrise ni le code ni le calendrier de correctifs, c'est un pari risqué. Et le Luxembourg vient de découvrir ce que ça coûte quand le pari échoue. Bref, treize ans d'avertissements ignorés, et il aura fallu un pays débranché trois heures pour que le sujet revienne sur la table.

Source : The Record

Google Cloud débranche Railway sans prévenir

Hier soir, le compte Google Cloud de Railway est passé en statut restreint. Du jour au lendemain, sans préavis et sans la moindre explication.

Railway, pour ceux qui ne connaissent pas, c'est un service américain qui permet aux développeurs et aux startups de mettre un site ou une application en ligne en quelques clics, sans avoir à louer ni configurer eux-mêmes des serveurs.

Dans le jargon, on appelle ça un PaaS, une plateforme d'hébergement clé en main. Des milliers d'entreprises s'en servent pour faire tourner leurs services au quotidien. Sauf que Railway, lui, fait tourner son propre tableau de bord, son API et son control plane (la partie qui orchestre toute la plateforme) sur Google Cloud. Donc quand Google a coupé, tout est tombé.

Résultat : environ six heures de panne. Les utilisateurs se sont retrouvés avec des erreurs "no healthy upstream" en cascade, impossible de se connecter, impossible de déployer quoi que ce soit. Le pire dans l'histoire, c'est que Railway n'est pas un petit client de passage. La boîte dépense plus de 10 millions de dollars par an chez Google Cloud. Même ça n'a pas suffi à éviter le débranchement automatique.

Le ton des équipes Railway est agacé. Angelo Saraceno, ingénieur chez eux, a lâché que leurs contacts chez Google étaient eux-mêmes confus et que les clients étaient furieux. Et cette phrase, qui résume tout : "nos clients se fichent que ce soit Google, c'est à nous d'assumer notre disponibilité". Difficile de leur donner tort.

Ce n'est pas la première fois. Railway avait déjà déménagé une partie de son infrastructure en colocation (des serveurs loués dans un datacenter, qu'on gère soi-même) en 2024, justement parce que les problèmes avec Google Cloud posaient un risque existentiel à leur activité.

Sauf qu'ils avaient gardé le control plane chez Google. Mauvaise idée, visiblement. Et en 2024, Google avait déjà fait exactement le même coup au fonds de pension australien UniSuper, suspendu une semaine entière sans raison claire.

Là où ça pique, c'est l'angle métier. Railway est un PaaS. Google Cloud propose aussi un PaaS. Autrement dit, Railway hébergeait son business chez un concurrent direct, qui peut le débrancher quand il veut, par un automatisme mal réglé ou autre chose. Vous voyez le piège. Confier sa plateforme d'hébergement à quelqu'un qui vend exactement le même service, c'est lui donner les clés et la corde.

Source : The Register

Il accuse Pizza Hut de lui avoir fait perdre 100 millions à cause d'une IA

Chaac Pizza Northeast, qui exploite plus de 100 restaurants Pizza Hut sur la côte est des États-Unis, attaque son propre franchiseur en justice. Le motif : un logiciel d'IA imposé par le siège pour gérer les livraisons, et qui aurait fait perdre près de 100 millions de dollars au franchisé.

Le logiciel s'appelle Dragontail. Il a été racheté en 2021 par Yum Brands, la maison mère de Pizza Hut, et il sert à orchestrer la production en cuisine et l'attribution des livraisons. Pizza Hut a fini par le rendre obligatoire pour ses franchisés.

Sur le papier, optimiser qui fait quoi et quand, c'est exactement le genre de tâche où une IA devrait briller. Sauf qu'en pratique, le résultat raconté dans la plainte est un désastre.

Le détail le plus parlant concerne les livreurs. Dragontail leur montrait si une autre commande allait bientôt être prête. Du coup, beaucoup de livreurs prenaient une commande, puis attendaient sur place quinze minutes pour en grouper une deuxième.

Résultat : la première pizza partait froide et en retard. Le genre de comportement algorithmique qui a du sens sur un tableur d'optimisation, et aucun sens dans la vraie vie d'un client qui attend son dîner. Et le client, lui, ne sait pas que c'est un algorithme qui a décidé de faire poireauter sa commande.

Les chiffres avancés par Chaac sont violents. Avant Dragontail, plus de 90 % de ses livraisons arrivaient en moins de 30 minutes, avec de bons scores de satisfaction. Après le déploiement, la croissance du chiffre d'affaires à New York est passée de plus de 10 % à environ moins 10 %. Le franchisé accuse donc Pizza Hut d'avoir violé le contrat de franchise en imposant un outil qui sabote la production, sans même fournir le support promis.

L'affaire est devant le tribunal des affaires du Texas, et elle dépasse largement le cas Pizza Hut. De plus en plus de franchisés se retrouvent à devoir installer des outils maison décidés par le siège, sans avoir leur mot à dire, et sans pouvoir revenir en arrière si ça plombe leur activité. Quand l'outil est une IA opaque qu'on ne peut ni ajuster ni désactiver, le franchisé paie les pots cassés tout seul.

Bref, une IA d'optimisation qui optimise si bien qu'elle livre les pizzas froides, c'est le genre de promesse 2026 qu'on n'avait pas vu venir.

Source : Gizmodo

Vim passe à GTK4, et Claude est crédité dans les commits

gVim, la version avec interface graphique du légendaire éditeur de texte Vim, récupère le support de GTK4. Pour situer, GTK c'est la boîte à outils qui dessine les fenêtres, les boutons et les menus des applications sous Linux.

Vim tournait jusqu'ici sur GTK2 et GTK3, deux versions vieillissantes. GTK4 modernise tout ça. Et le détail qui fait causer : le commit indique noir sur blanc que le portage a été co-écrit par Claude, l'IA d'Anthropic.

Le boulot a pris plusieurs semaines. Le support GTK4 est maintenant intégré au code de Vim, activable avec une option de compilation, --enable-gui=gtk4. GTK4 apporte un rendu plus moderne et un meilleur support des écrans haute densité, là où GTK2 commençait sérieusement à dater.

GTK2 n'est d'ailleurs plus vraiment maintenu côté GNOME depuis un bon moment, donc rester dessus n'était pas tenable éternellement. Pour l'instant, le script de configuration garde quand même GTK3 par défaut si vous ne précisez rien, le temps que la nouvelle version soit éprouvée. Aucune installation existante n'est donc affectée, et ça débarquera en option dans la prochaine version de Vim.

Le plus intéressant, ce n'est pas le code mais le tag "Co-authored-by: Claude" dans l'historique Git. Vim, c'est un projet open source vénérable, démarré en 1991, l'éditeur des barbus et des serveurs Linux du monde entier. L'éditeur n'a pas bougé sur ses fondamentaux depuis des décennies, et ce genre de modernisation graphique traîne souvent faute de bras pour s'en occuper.

Voir une IA créditée comme co-autrice sur une toolkit graphique de trente ans, c'est quand même un signal fort. Et personne n'a planqué la contribution : elle est assumée et tracée.

C'est exactement le bon réflexe. Le débat sur les contributions d'IA dans l'open source n'est pas nouveau, Greg Kroah-Hartman, un des mainteneurs du noyau Linux, avait déjà posé le sujet sur la table. Le vrai problème n'a jamais été "l'IA a écrit du code", mais "est-ce que c'est transparent et est-ce qu'un humain a relu et validé".

Ici, les deux cases sont cochées. Le code est passé par la revue habituelle du projet, et le crédit est explicite. Un curieux peut remonter le commit et voir précisément ce qui a été fait.

Bref, une IA qui aide à dépoussiérer une toolkit de trente ans en le disant clairement, c'est plutôt la version saine du truc.

Source : Phoronix

Cuivrer une pièce imprimée 3D sans cuve géante, c'est possible en la faisant tourner

Hendrik s'est attaqué à un problème classique des makers : électroplaquer une pièce imprimée en 3D un peu grosse, ça demande une cuve énorme remplie de produits chimiques pour la submerger entièrement.

Sa solution, fabriquée maison, prend le problème dans l'autre sens : si la pièce ne rentre pas dans la cuve, autant la faire tourner doucement dans une cuve plus petite.

Le principe est simple. Vous prenez votre pièce 3D, vous la poncez, vous la recouvrez de peinture conductrice (indispensable, sinon le métal ne s'accroche à rien).

Ensuite vous la fixez sur un axe motorisé piloté par un ESP32 (un petit microcontrôleur Wi-Fi du même style qu'un Raspberry Pi en plus modeste) qui fait tourner doucement la pièce via un moteur pas-à-pas. La pièce trempe à moitié dans la cuve d'électrolyte, et la rotation se charge du reste. Au bout d'une nuit complète, le cuivre s'est déposé uniformément sur toute la surface.

La cuve elle-même est fabriquée maison en acrylique, dimensionnée juste pour la zone immergée. Une carte électronique custom gère le moteur, un boîtier imprimé en 3D protège l'ensemble.

Une fois le cuivrage terminé, Hendrik polit la couche obtenue puis enchaîne avec d'autres bains pour ajouter d'autres métaux par-dessus si besoin, comme du nickel ou de l'or. Le résultat ressemble à une pièce métallique pleine, alors qu'en dessous c'est juste du plastique imprimé.

C'est exactement le genre de bricolage qui ne paie pas de mine mais qui débloque un truc bien utile. Une cuve d'électrolyse pour un casque ou une grosse pièce cosplay, c'est plusieurs centaines d'euros de produits chimiques, sans compter la place que ça prend dans un atelier.

Là, l'investissement matériel se réduit à un moteur pas-à-pas à 15 euros, un ESP32 à 5 euros, un bout d'acrylique et la peinture conductrice. Le tout est réutilisable indéfiniment, donc l'amortissement se fait rapidement.

Petit bémol quand même : si vous ne plaquez qu'une seule pièce dans votre vie, c'est sans doute plus simple de payer un pro pour vous le faire et il faut accepter de laisser tourner un montage chimique pendant douze heures dans son garage.

Mais pour quelqu'un qui produit des accessoires en série, des prototypes de bijoux ou des pièces cosplay régulièrement, c'est une vraie alternative.

Source : Hackaday

Apprendre Prolog avec des Pokémon, c’est possible

Alexander Petros, qui tient le blog Unplanned Obsolescence , a publié un tutoriel d'environ 3 500 mots qui explique les bases de Prolog, un langage de programmation logique des années 70 très différent des langages courants comme Python ou JavaScript, en utilisant les combats Pokémon comme support pédagogique. C'est étonnamment efficace.

Pour ceux qui n'ont jamais touché Prolog, la grosse différence avec un langage classique style Python ou JavaScript, c'est qu'au lieu de dire à l'ordinateur comment résoudre un problème étape par étape, vous lui décrivez les règles du jeu et vous le laissez chercher les réponses tout seul.

Vous écrivez des faits ("Bulbizarre est un Pokémon", "Bulbizarre est de type plante"), des règles ("un Pokémon vulnérable à X subit le double de dégâts d'une attaque de type X"), et vous posez ensuite des questions au système. Il fait le reste..

L'angle Pokémon est plutôt malin. Les combats Pokémon, c'est en fait un moteur de règles assez tordu : types, faiblesses, talents passifs, priorités d'attaques, statuts.

Bref, exactement le genre de domaine où Prolog brille et où un langage impératif transpire. Petros part de requêtes très simples ("est-ce que Carapuce est un Pokémon ?") et finit avec des filtres complexes qui sélectionnent les équipes en fonction de leur composition. À chaque étape, l'équivalent en SQL serait dix fois plus lourd.

Le passage le plus parlant, c'est quand il ajoute le support du talent Farceur, qui donne une priorité supérieure aux attaques de statut. Implémenter cette règle a pris trois minutes : il a ajouté une seule clause logique au programme.

Faites le même boulot dans un tableur ou une base SQL, et vous repartez pour des heures. C'est exactement le genre de cas où on comprend pourquoi Prolog a une niche stable, même si personne ne s'en sert au quotidien dans l'industrie.

Côté pédagogie, le choix est bon. La plupart des tutoriels Prolog vous balancent des relations familiales du style "Marie est la fille de Pierre, qui est le mari de...", ce qui marche mais reste relativement abstrait. Là, vous lisez le code et vous voyez immédiatement à quoi ça sert : à modéliser un combat Pokémon. Du coup les concepts d'unification, de prédicats et de négation passent presque tout seuls.

Si vous avez toujours voulu vous mettre à Prolog mais que les tutoriels classiques vous tombaient des mains, l'article de Petros est le point de départ qu'il vous faut.

Source : Hackaday

Voir à 650 mètres dans le noir avec un laser infrarouge et une webcam : c’est faisable

Project 326, une chaîne YouTube spécialisée dans les bricolages optiques, a montré un système de vision nocturne longue portée monté de A à Z dans un garage. Le résultat tient en quelques composants : un télescope réflecteur imprimé en 3D, une webcam modifiée et un laser infrarouge de deux watts. À l'arrivée, on voit jusqu'à 650 mètres dans l'obscurité totale.

Le principe est simple (si on peut dire). Un laser dans une longueur d'onde de 940 nanomètres, totalement invisible à l'œil nu mais détectable par n'importe quel capteur photo sans filtre infrarouge, éclaire la scène à distance. La webcam, dont on a retiré le filtre infrarouge d'origine, capte la lumière réfléchie. Le télescope réflecteur, un montage avec un miroir concave qui collecte la lumière comme dans les télescopes amateurs, concentre le tout sur le capteur. Du coup vous obtenez une image quasi-diurne en plein milieu de la nuit.

Le laser utilisé est un VCSEL, un type de diode laser qui émet la lumière par la surface plutôt que par le bord. Avec ses deux watts à 940 nm, il peut littéralement brûler un morceau de carton si vous mettez la main dessus à courte distance. Sauf qu'à 500 mètres, le faisceau s'est tellement élargi qu'il passe largement sous les seuils de sécurité oculaire. C'est ce qui rend le système utilisable en pratique : il faut viser loin, sinon ça devient dangereux.

Côté limites, l'atténuation atmosphérique mange jusqu'à 70 % de la puissance du faisceau à 940 nm quand l'air est humide. Project 326 a donc dû faire ses tests en altitude par temps sec pour atteindre les 650 mètres annoncés. À noter aussi que toute personne équipée elle-même de vision nocturne verra immédiatement le faisceau, donc oubliez le côté discret du truc.

Screenshot

Ce qui est franchement chouette dans ce projet, c'est l'écart entre le matériel utilisé et le résultat obtenu. Une vision nocturne militaire active coûte plusieurs milliers d'euros. Là, on est sur du télescope imprimé, un VCSEL acheté en ligne pour quelques dizaines d'euros, une webcam à dix euros. La précision de l'alignement optique reste l'étape compliquée, mais tout le reste tient dans un projet de week-end.

Bref, c'est une démonstration de plus que la limite entre matériel pro et bricolage amateur dépend surtout du temps qu'on veut y passer.

Source : Hackaday

Un essaim de Waymo s'est mis à tourner en boucle dans une rue résidentielle

Vous vous levez à 6h du matin, et là, surprise : une cinquantaine de SUV autonomes Waymo s'engouffrent l'un après l'autre dans votre impasse, font demi-tour au rond-point, et repartent dans le même sens. C'est ce qui s'est passé sur Battleview Drive, une rue calme du quartier de Buckhead à Atlanta.

Un riverain a filmé la scène et publié la vidéo, qui ressemble franchement à une séquence de Stephen King : des robotaxis vides qui glissent silencieusement dans le rond-point, sans personne au volant, et qui repassent toutes les 46 secondes en moyenne.

Pour la petite histoire, Waymo fait rouler des Jaguar I-PACE électriques modifiées en mode autonome dans plusieurs villes américaines. Le problème ici venait d'un bug de routage dans le logiciel qui pilote la flotte. Les voitures pensaient devoir passer par cette rue pour se rendre quelque part... sauf qu'elle ne mène nulle part. Du coup, elles entraient, faisaient demi-tour, ressortaient, et la voiture suivante recommençait l'exercice. Une vidéo a comptabilisé 13 Waymo en 10 minutes. Multipliez par les heures où ça a duré, vous voyez le tableau.

Les résidents ont signalé le problème pendant deux mois sans réponse. Mais bon. Excédés, ils ont fini par bricoler un panneau d'enfant pour bloquer la rue, ce qui a déclenché un embouteillage monumental de robotaxis confus.

C'est seulement quand la vidéo a tourné sur les réseaux que Waymo a réagi, présenté ses excuses, et corrigé le bug de routage avec son partenaire de flotte. La société rappelle au passage qu'elle effectue plus de 500 000 trajets par semaine aux États-Unis.

Waymo dit "prendre les retours communautaires au sérieux" et travaille avec ses partenaires pour que ça ne se reproduise pas. Bref, ce genre de bug rappelle que la conduite autonome à grande échelle est un vrai casse-tête, et qu'un mauvais point GPS peut transformer une rue tranquille en circuit Mario Kart.

Source : Independent.co.uk

Linux 7.2 saura enfin gérer les consoles OneXPlayer

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

Sortir les modèles 3D d'un jeu PS5 en passant par le mode Photo et un peu de photogrammétrie

Quand vous voulez récupérer un modèle 3D d'un jeu vidéo, en général il y a deux options. Soit vous fouillez les fichiers du jeu pour en extraire les assets, ce qui demande des outils spécialisés et qui ne marche pas simplement sur console.

Soit vous abandonnez. Un bidouilleur connu sous le pseudo Dung3onlord vient de proposer une troisième voie, beaucoup plus rigolote et qui ne touche pas du tout au jeu lui-même.

[Embed: https://www.reddit.com/r/OculusQuest/comments/1srgzgz/capture_and_view_ps5_characters_on_a_quest_link/]

La technique repose sur deux trucs intégrés à la PS5. D'abord, le mode Photo, présent dans la plupart des gros titres modernes, qui permet de geler la scène et de la regarder sous n'importe quel angle.

Ensuite, la photogrammétrie, une vieille méthode qui consiste à reconstruire un objet 3D à partir de plein de photos prises sous différents angles. Mettez les deux ensemble et vous obtenez votre modèle, sans toucher au moteur du jeu.

Le mode opératoire de Dung3onlord est assez simple. Il filme une vidéo en orbite autour d'une scène figée en mode Photo, désactive toute interface visible, extrait les images de la vidéo, et passe le lot dans un logiciel de photogrammétrie classique.

Le résultat, c'est un nuage de points 3D, qu'il nettoie, dont il enlève le fond, puis qu'il transforme en gaussian splat. C'est une technique récente d'affichage 3D qui demande très peu de puissance de calcul pour le rendu. Il visualise ensuite le tout dans un casque VR Quest, ce qui donne une vraie sensation d'immersion dans la scène du jeu.

Il y a des limites évidemment. Plein d'effets graphiques modernes, comme les normal maps qui font croire à du relief sur des surfaces plates, ne donnent pas une vraie géométrie par exemple. Du coup la version 3D paraît parfois plus lisse que ce que vous voyiez dans le jeu. Et la technique ne marche que sur des scènes statiques, pas sur des animations.

Mais pour des paysages, des décors, ou des modèles fixes, c'est efficace. Surtout si l'objectif n'est pas d'avoir la précision absolue d'un fichier 3D natif, mais juste de revisiter une scène en immersion.

Et puis surtout, ça contourne tout le problème de l'extraction directe : le DRM, les formats propriétaires, les hooks dans la mémoire. Ici, on photographie l'écran. Le jeu n'a rien à dire. C'est une méthode bien élégante en tous cas.

Source : Hackaday

Claude a fait tourner Adobe Lightroom CC sous Linux

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

Un fan de Linux a transformé son bureau en niveau de Minecraft

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 continue de trouver des bugs dans le noyau Linux avec son IA locale

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

Oubliez votre PC portable, et passez au Cyberdeck fait maison

Si vous avez déjà rêvé d'une machine portable qu'on peut démonter, réparer et améliorer pièce par pièce comme un Lego, l'objet construit par Jankbu va vous parler. Le YouTubeur, spécialisé dans la bidouille électronique, vient de publier la vidéo de son cyberdeck, c'est-à-dire un ordinateur portable maison taillé dans des composants choisis un par un, qui fait franchement penser à l'esthétique cyberpunk des années 80-90.

Au cœur de la bête, un Raspberry Pi 5 qui tourne sous Linux. Mais c'est tout autour que ça devient intéressant. Plutôt qu'une charnière classique d'ordi portable, Jankbu a opté pour un écran qui coulisse verticalement sur deux tiges en acier et roulements linéaires, avec une chaîne porte-câbles miniature pour éviter que les fils se coincent.

Le truc vraiment bien pensé, c'est le rail NATO qui équipe la machine. Ce rail standardisé permet de clipser et déclipser des modules à la volée. Et ça marche. Module d'alimentation avec des batteries NPF interchangeables (les mêmes que sur les caméras photo professionnelles), trackball récupéré d'une vieille souris Logitech Trackman Marble pour la navigation, poignée en aluminium massif usinée pour la robustesse... chaque pièce est pensée pour être démontable, remplaçable, modifiable.

La philosophie est claire : Jankbu déteste les laptops modernes scellés où vous ne pouvez rien réparer. Du coup, il a tout misé sur des connecteurs USB standard, du câblage modulaire, et des composants qu'on peut sourcer en magasin de bricolage. La machine est conçue pour faire du web et de la CAO, deux usages qu'on peut largement assurer avec un Pi 5 sans avoir à se ruiner sur un MacBook Pro.

Honnêtement, c'est franchement impressionnant ce qu'on peut sortir d'un Raspberry quand on a du temps, des compétences et l'envie de réparer plutôt que jeter.

Source : Hackster.io

L'histoire géniale du programmeur qui a tout effacé en 1981 à cause d'une astérisque

Sur The Register, un témoignage improbable d'un lecteur qui raconte la fois où il a effacé toutes les données et tout le code de son entreprise. Voilà qui date pas mal, puisque c,'était en 1981, il avait 21 ans, et il développait tout seul un script de nettoyage pour un mainframe IBM. Le genre de mission qu'on ne devrait pas trop confier à un dev junior sans relecture. C'est précisément ce qui a été fait, et la suite est exactement ce que vous pouvez imaginer.

Le système gérait des machines virtuelles pour les utilisateurs, chacune avec son disque attaché et une lettre attribuée de A à Z. À la fin de la journée, le script de Miller, notre héros, faisait trois choses simples : il rattachait tous les disques, les sauvegardait sur un disque temporaire, puis effaçait les originaux. Le problème, c'est que le disque temporaire recevait une lettre dynamique, pas prédictible à l'avance. Donc Miller avait écrit du code pour récupérer cette lettre au moment où elle était attribuée.

Sauf que voilà. Un jour, l'entreprise ajoute un nouveau compte utilisateur. Et là, les 26 lettres de l'alphabet sont toutes occupées. Le système ne peut plus attribuer de lettre au disque temporaire. 

La fonction censée renvoyer la lettre ne renvoie pas une erreur, mais une astérisque. Sauf que dans la plupart des langages de scripting shell, l'astérisque est un caractère joker qui veut dire "tout ce que tu trouves". Quand la commande de suppression s'exécute avec un astérisque à la place d'une lettre précise, elle ne supprime pas un disque. Elle supprime tout. Chaque fichier, toutes les données, tout le code de l'entreprise.

Une journée complète a été nécessaire pour restaurer ce qui pouvait l'être. Une vingtaine de collègues sont restés à se tourner les pouces pendant la restauration. Miller, lui, a appris ce jour-là pourquoi le contrôle de code par un pair existe. Plus de quarante ans plus tard, il dit que la leçon ne l'a jamais quitté.

L'histoire date de 1981, mais elle reste actuelle à un détail près. Aujourd'hui, on a les revues de code, les sauvegardes incrémentales, les snapshots, les outils de récupération, et on confie quand même des scripts shell critiques à des assistants IA qui n'ont pas toujours conscience de ces pièges . L'astérisque parasite n'a pas disparu, elle a juste changé de support. Méfiance donc !

Source : The Register

Des cartes perforées imprimées en 3D et lues par une webcam, parfait pour stocker vos mots de passe à vie

Les cartes perforées, c'est le truc qu'on associe à l'informatique de grand papa. Des bouts de carton avec des trous dedans qui servaient à programmer les ordinateurs des années 1960. Personne n'aurait l'idée d'en utiliser aujourd'hui.

Sauf Bitroller , un bidouilleur qui a eu une autre idée : et si on imprimait des cartes perforées en 3D, qu'on les laissait dans un coffre, et qu'on les relisait avec une simple webcam ?

L'objectif n'est pas de programmer un ordinateur, c'est de stocker des données ultra-sensibles sur un support qui ne risque pas de s'effacer. Genre la clé d'un portefeuille crypto ou un mot de passe maître.

Chaque carte mesure une dizaine de centimètres de côté et stocke 16 octets de données utiles, plus 4 octets de correction d'erreur « Reed-Solomon ». Ce système permet de retrouver l'info même si la lecture est partiellement abîmée. Reed-Solomon, ce n'est pas exotique d'ailleurs, c'est la même famille de correction d'erreurs que celle qui fait tenir vos CD ou vos QR codes face aux rayures. C'est microscopique, oui. Mais pour stocker une clé cryptographique, c'est largement suffisant.

Screenshot

Le génie du projet tient dans la méthode de lecture. Pas de machine industrielle, pas de scanner spécialisé. Juste une webcam, posée au-dessus de la carte, avec un fond noir derrière. OpenCV, la bibliothèque libre de vision par ordinateur que tout le monde utilise pour ce genre de tâche, lit la carte entière d'un seul coup à partir du contraste entre le fond et le plastique blanc. Le créateur fournit deux scripts Python, un pour générer la carte à imprimer, l'autre pour la relire.

Le matériau choisi est du PLA, le plastique standard des imprimantes 3D grand public. C'est honnête pour un prototype, mais pas idéal pour de la longue durée. Bitroller le reconnaît : en acier inoxydable, ses cartes survivraient à un incendie sévère et resteraient lisibles dans plusieurs siècles. Le but n'est pas vraiment de bidouiller, c'est de proposer un vrai support d'archive longue durée.

Face à un vieux papier ou à une clé USB, la différence est évidente. Le papier brûle, la clé USB meurt après quelques années sans alimentation. Une carte perforée en métal traversera les décennies sans broncher. Et le fait que la lecture se fasse avec n'importe quelle webcam évite la galère du lecteur propriétaire qui n'existe plus dans dix ans. Bref, bonne idée. Vous pouvez voir le projet ici .

Source : Hackaday

Il fait tourner Windows CE sur une Nintendo 64, et ça marche pour de vrai

Un développeur connu sous le pseudo ThroatyMumbo a réussi à porter Windows CE 2.11, un Windows allégé que Microsoft avait sorti à la fin des années 90 pour les petits assistants personnels et certains routeurs, sur une vraie console Nintendo 64

On ne parle pas d'un émulateur ici, mais bien d'une N64 qui démarre sur un vrai bureau Windows, avec sa barre des tâches, son explorateur de fichiers et la possibilité de lancer des programmes CE.

Pour bien comprendre le délire, il faut savoir que la N64 et Windows n'ont pas grand chose en commun. La console utilise un processeur MIPS et un système maison signé Nintendo. Windows CE, c'est l'inverse : un système Microsoft conçu pour tourner sur des appareils embarqués comme les assistants personnels.

Sauf que les deux mondes se croisent sur deux points clés. Windows CE tournait déjà sur des puces MIPS à l'époque, et il était conçu pour vivre avec à peine 1 Mo de RAM, ce qui correspond pile aux capacités de la N64. ThroatyMumbo s'est inspiré de l'IBM Workpad Z50, un ancien assistant qui tournait sous CE sur du MIPS, pour se dire que le portage était techniquement faisable.

Côté méthode, le kernel Windows CE d'origine n'est pas modifié. Tout le travail est dans la couche d'abstraction matérielle, la fameuse HAL, qui sert d'interface entre le système et le matériel. Le développeur a écrit la sienne de zéro pour la N64 : démarrage, gestion des interruptions, du timing, de l'affichage.

Le contrôleur N64 devient une souris (le bouton A pour clic gauche, le B pour clic droit, logique). L'EverDrive-64 X7, une cartouche qui fait office de lecteur SD, sert de disque dur. Et le son passe par la puce audio d'origine de la console.

Ce qui marche est franchement bluffant : déplacer les fenêtres, fermer une boîte de dialogue, naviguer dans les fichiers, lancer des exécutables CE tiers, et même afficher une démo 3D qui utilise la puce graphique de la console. Ce qui ne marche pas : pas de clavier physique, pas de réseau, et il faut le SDK Windows CE 2.11 de Microsoft, qui n'est plus commercialisé depuis longtemps.

Aucune utilité concrète, évidemment. Personne ne va remplacer Mario Kart 64 par Word pour Windows CE. Mais c'est rigolo, et permet de prouver qu'on peut faire un truc complètement absurde, juste parce que c'est techniquement intéressant.

Source : Hackaday

La folle histoire de la 3DO Blaster, ressuscitée dans un musée

En 1994, Creative Labs, le fabricant des fameuses cartes son Sound Blaster, a sorti un truc complètement fou : la 3DO Blaster, une carte ISA (le format d'extension standard des PC de l'époque) qui contenait littéralement une console 3DO entière, prête à être greffée dans un PC 386 ou 486.

Tous les composants graphiques et audio de la machine y étaient embarqués. Le PC servait juste d'écran et de boîtier. Le prix à l'époque : 399,95 dollars, soit exactement le tarif d'une vraie console 3DO chez Panasonic. L'idée commerciale était géniale.

The Retro Collective, un musée britannique dédié au matériel rétro, vient d'en recevoir une pour sa collection. Petit problème, la carte ne marchait que si on appuyait sur l'un de ses coins. C'est le genre de symptôme qui sent le faux contact, autrement dit des broches qui ne touchent plus le circuit imprimé. Un peu de fer à souder plus tard, plus quelques autres petites réparations, et la 3DO Blaster a retrouvé l'usage de la parole.

Pour rappel, la 3DO n'était pas exactement une console comme la PlayStation ou la Nintendo 64. C'était une spécification technique que les fabricants pouvaient utiliser pour construire leur propre machine.

Panasonic, Sanyo et Goldstar s'y sont collés. Sur le papier, le matériel tenait la route face à la première PlayStation. En pratique, le succès commercial n'a jamais suivi, faute de jeux marquants et avec un prix de lancement perché trop haut. La plateforme a végété puis disparu.

La Blaster avait en plus une bizarrerie qui n'a pas aidé à son adoption. Creative imposait un lecteur CD-ROM précis pour fonctionner, le CR-563, une variante maison d'un modèle Panasonic. Vous aviez la carte, le bon PC, mais le mauvais lecteur ? Tant pis. Mariage forcé pour qu'un produit déjà bancal trouve son public. Et comme il fallait aussi une Sound Blaster pour le son, la facture montait vite.

La carte est sortie aux États-Unis, au Royaume-Uni et en quelques marchés asiatiques, puis a quasiment disparu des radars. Aujourd'hui, en voir une en état de marche est rare.

Quand le musée fera tourner Shock Wave ou Gridders ce week-end devant les visiteurs, ce sera l'un des seuls endroits au monde où une 3DO Blaster sera de nouveau opérationnelle.

Bref, un produit absurde, un tarif absurde, un montage absurde. J'adore. D'ailleurs ça me donne envie de relancer des jeux 3DO sur ma Recalbox !

Source : Hackaday

Ne jetez pas votre vieux PC : le noyau Linux s'apprête à booster ses performances en jeu

Sur un PC, l'ordonnanceur du système (le scheduler en anglais), c'est ce petit bout du noyau qui décide quelle tâche tourne sur quel cœur du processeur, et pendant combien de temps. Plus il est malin, plus la machine est fluide.

Peter Zijlstra, l'un des développeurs historiques du noyau Linux, vient de proposer un patch baptisé "sched: Flatten the pick" qui réorganise la façon dont l'ordonnanceur attribue les priorités. Et les résultats sur le gaming, surtout sur du vieux matériel, sont étonnants.

Pour le test, le développeur a sorti un PC d'époque : un Intel Core i7-2600K, processeur de 2011, accompagné d'une carte graphique AMD Radeon RX 580. Le tout fait tourner Shadows: Awakening, un jeu disponible sur la boutique GOG, lancé via Lutris et Proton, l'écosystème qui permet de faire tourner les jeux Windows sous Linux. Et là, surprise.

Avant le patch, le jeu pédalait à environ 4 images par seconde au minimum et 48 en moyenne. Après application, on monte à 20 images par seconde au minimum et 57 en moyenne. Le temps maximum entre deux images, l'autre indicateur clé pour la fluidité, passe de 107 millisecondes à 37. On passe d'injouable à correct. Sur une machine de 2011, c'est presque un miracle.

Le patch touche à la gestion des cgroups, des conteneurs de processus qui regroupent et hiérarchisent les tâches, sur les systèmes multi-cœurs. Plusieurs niveaux de sélection étaient empilés, et le patch les "aplatit" pour gagner en réactivité.

Les vieux processeurs ont moins de cœurs et moins de marge, donc chaque mauvaise décision de l'ordonnanceur coûte cher. Sur un processeur récent avec dix ou douze cœurs, on ne le remarque presque pas. Sur un quadri-cœur d'il y a quinze ans, ça se voit immédiatement à l'écran.

Attention quand même, on n'est pas encore au point d'être intégré dans le noyau Linux officiel. Il reste des relectures et des validations avant que le code finisse en production. C'est la version 2 du patch, donc la discussion technique a déjà bien avancé.

Pour les distributions Linux orientées jeu, qui chassent la moindre milliseconde gagnée, ce genre de patch est exactement le type d'amélioration qu'on suit de près.

Bref, si vous traînez un vieux PC qui peine, un futur noyau Linux pourrait bien lui offrir une deuxième jeunesse pour le jeu.

Source : Itsfoss

Mythos, l'IA d'Anthropic, aide à percer le kernel d'un Mac M5 en cinq jours

Cinq jours. C'est le temps qu'il a fallu à l'équipe de Calif, une boîte de sécurité informatique, pour faire tourner un exploit fonctionnel sur un Mac équipé de la dernière puce M5 d'Apple. Et pas n'importe quel exploit : c'est la toute première démonstration publique de contournement de MIE, la grande nouveauté sécurité d'Apple sur cette puce.

MIE, c'est pour Memory Integrity Enforcement, c'est une protection câblée directement dans le silicium du M5. L'objectif est simple : empêcher qu'un programme malveillant puisse écrire dans des zones mémoire qui ne lui appartiennent pas, ce qui est la base de la quasi-totalité des grosses failles depuis vingt ans.

Apple a vendu au monde entier cette protection comme un mur quasi infranchissable. Et c'est ce mur que Calif vient de fissurer en toute décontraction.

L'histoire commence le 25 avril. Bruce Dang, l'un des chercheurs de Calif, repère deux bugs dans le kernel (le coeur du système d'exploitation) de macOS 26.4.1. Deux jours plus tard, Dion Blazakis rejoint l'équipe. Josh Maine construit l'outillage.

Le 1er mai, l'exploit fonctionne : depuis un simple compte utilisateur, on obtient un shell root sur la machine, c'est-à-dire les pleins pouvoirs sur le Mac. Dans la boucle pendant tout ce sprint, Mythos Preview, une IA d'Anthropic (la boîte derrière Claude, mais vous connaissez forcément). Bref, cinq jours du début à la fin.

L'équipe explique que Mythos a surtout été utile pour repérer rapidement les bugs, parce qu'ils appartenaient à des familles déjà connues, et que l'IA généralise très bien dès qu'elle a appris une classe de problème particulière.

Par contre, contourner MIE de manière autonome est resté hors de portée, parce que la techno est trop neuve. C'est là que les humains ont fait la différence, en combinant les bugs entre eux pour passer la barrière.

Calif a choisi une approche assez marrante pour montrer le problème : aller poser l'exploit en main propre à Apple Park, plutôt que de passer par le formulaire officiel. Apple n'a pas encore communiqué sur le calendrier pour un correctif.

Pour les utilisateurs lambda, pas de panique : l'exploit demande déjà un accès à la machine, donc ce n'est pas le scénario du phishing classique. Mais pour l'image de MIE comme rempart imprenable, c'est très bof.

Source : Calif.io

Une faille présente depuis 18 ans découverte dans nginx, le serveur qui fait tourner un tiers du web

Nginx, c'est ce logiciel discret qui sert les pages d'environ un site populaire sur trois sur la planète. Quand vous chargez une page web, il y a une bonne chance que ce soit lui qui vous l'envoie.

La société DepthFirst AI, spécialisée dans la recherche de failles assistée par intelligence artificielle, vient d'y trouver un trou de sécurité, et il est plutôt balèze : présent dans le code depuis 2008. Soit environ 18 ans de service sans que personne ne le remarque.

La faille (référencée CVE-2026-42945, le système de numérotation officiel des vulnérabilités) est notée 9,2/10 sur l'échelle de gravité, ce qui la classe en critique. Concrètement, elle vit dans un module précis de nginx qui gère la réécriture d'URL, et elle se déclenche quand deux instructions de configuration ("rewrite" et "set") sont utilisées en même temps.

C'est un débordement de mémoire tampon, c'est-à-dire que des données débordent dans une zone qu'elles ne devraient pas occuper. Quand on contrôle ce débordement, on peut faire planter le serveur, voire dans certains cas exécuter son propre code à distance sur la machine.

Pour le déni de service (DoS), c'est-à-dire faire tomber le serveur, l'exploitation est démontrée et fonctionne. Pour l'exécution de code à distance, c'est plus délicat : les chercheurs y arrivent uniquement quand une protection mémoire appelée ASLR est désactivée, ce qui n'est pas le cas par défaut sur les systèmes modernes. Bonne nouvelle relative, donc, mais ça reste à prendre très au sérieux.

Côté correctifs, les versions à installer sont nginx Open Source 1.31.0 ou 1.30.1, et NGINX Plus R36 P4 pour les clients commerciaux. Toutes les versions précédentes depuis 0.6.27 sont vulnérables, donc autant dire à peu près tout ce qui tourne en production aujourd'hui.

Si vous administrez un serveur, c'est le moment de regarder ce qui tourne dessus et de patcher rapidement. Les exploits publics ont une fâcheuse tendance à apparaître quelques jours après les divulgations de ce genre.

Le détail qui pique, c'est la méthode de découverte. DepthFirst AI utilise l'intelligence artificielle pour faire de l'analyse de code à grande échelle, en cherchant des motifs suspects que des outils classiques ne repèrent pas. Le fait qu'une faille planquée dans nginx depuis dix-huit ans soit sortie comme ça donne une idée de ce qui dort encore dans tout le code qu'on utilise au quotidien.

Source : Bleeping Computer

Une faille permet d'ouvrir un disque BitLocker avec quelques fichiers sur une clé USB

BitLocker, c'est le système de chiffrement intégré à Windows qui protège vos disques contre quelqu'un qui mettrait la main sur votre machine. Activé par défaut sur Windows 11 et installé sur des millions d'ordinateurs, il est censé garantir que sans votre mot de passe ou votre code de récupération, personne ne lit ce qu'il y a dessus.

Sauf qu'un chercheur en sécurité, Chaotic Eclipse, vient de publier une démonstration qui réduit cette promesse en miettes.

L'exploit s'appelle YellowKey et c'est une faille zero-day, c'est-à-dire une vulnérabilité connue avant que Microsoft ne sorte de correctif. La méthode est presque insultante de simplicité. Vous copiez un dossier nommé "FsTx", planqué dans le répertoire système "System Volume Information", sur une clé USB.

Vous redémarrez la machine en appuyant sur les bonnes touches. Et là, surprise. Windows vous propose un accès en ligne de commande avec les pleins pouvoirs, et le chiffrement BitLocker est contourné comme s'il n'avait jamais existé.

Pire encore, les fichiers utilisés pour l'attaque disparaissent après usage, ce qui ne laisse quasi aucune trace. Pour Chaotic Eclipse, ce comportement ressemble plus à une porte dérobée laissée par Microsoft qu'à une faille classique. C'est-à-dire un accès secret délibérément intégré au système, plutôt qu'un bug malheureux.

Le chercheur précise au passage que ses précédents rapports de sécurité ont été "apparemment rejetés" par les équipes de Microsoft. Bref, nous ne sommes pas dans de la collaboration sereine.

Côté machines concernées : Windows 11, Windows Server 2022 et 2025. Windows 10 passe entre les gouttes. Microsoft, pour l'instant, n'a fait aucune déclaration publique sur le sujet. Si BitLocker était le seul rempart entre vous et un voleur d'ordinateur, c'est le moment de revoir votre stratégie. 

Les entreprises qui s'appuient sur BitLocker pour leurs flottes de portables vont devoir se poser sérieusement la question d'un complément ou d'une alternative, en attendant un patch officiel qui n'arrive visiblement pas.

La théorie de la porte dérobée volontaire est évidemment difficile à prouver. Il faudrait soit un aveu de Microsoft, soit une analyse approfondie du code source qui n'est pas public.

Mais le profil de la faille (mécanisme trop propre, comportement trop spécifique, fichiers qui s'auto-nettoient) interpelle. D'autant que la fonction utilisée n'a pas de raison technique évidente d'exister dans un système destiné à empêcher l'accès au disque sans authentification.

Vous l'avez compris, une faille à laquelle on accède avec une clé USB et trois touches au démarrage, ça fait beaucoup pour un outil censé protéger des secrets industriels.

Source : Tom's Hardware

Il retrouve 400 000 $ de Bitcoin oubliés depuis 11 ans grâce à Claude

L'histoire est partie d'un changement de mot de passe fait pendant une cuite en 2014. Onze ans plus tard, le malheureux (" cprkrn " sur X) avait toujours ses 5 bitcoins coincés dans un portefeuille numérique dont la clé d'accès s'était totalement évaporée de sa mémoire.

À l'époque, ça valait quelques milliers de dollars. Aujourd'hui, c'est environ 400 000 $. De quoi avoir un peu mal au cœur.

Pour récupérer un portefeuille Bitcoin chiffré, il existe des outils comme btcrecover, un logiciel libre qui essaie des combinaisons de mots de passe en masse. Le problème, c'est qu'il faut une idée précise des variantes à tester, sinon on tape dans le vide pendant des années.

Notre trader avait justement passé des années à essayer sans succès. Et puis il a demandé un coup de main à Claude, l'assistant IA d'Anthropic, l'un des principaux concurrents d'OpenAI.

Claude a fait trois choses concrètes. D'abord, il a fouillé dans les archives d'un vieux disque de fac pour y dénicher une sauvegarde du portefeuille datant de décembre 2019, qui était passée inaperçue. Ensuite, il a repéré un bug de configuration dans btcrecover qui empêchait l'outil de combiner correctement les variantes de mot de passe. Et une fois le bug corrigé, la machine s'est lancée pour de bon.

Résultat : 3 500 milliards de mots de passe testés avant de tomber sur le bon. Le portefeuille s'est ouvert, les 5 bitcoins sont apparus, et notre type a récupéré un pactole oublié.

Cette histoire n'est pas anecdotique en fait. Un nombre énorme de bitcoins sont aujourd'hui considérés comme perdus à jamais, parce que les propriétaires ont oublié leur mot de passe, perdu leur disque dur, ou jeté la mauvaise clé USB.

On parle de plusieurs millions de Bitcoins immobilisés pour rien. Si l'IA peut aider à en récupérer une partie, c'est tout benef, même si la méthode ne marche pas dans tous les cas. Il fallait quand même la sauvegarde du wallet pour que ça fonctionne.

À noter que ce genre d'usage commence à devenir une tendance. Les services de récupération de portefeuilles crypto, comme Wallet Recovery Services, intègrent désormais des modèles d'IA dans leur process pour orienter les attaques par force brute.

Là où une machine essayait bêtement toutes les combinaisons possibles, l'IA peut deviner les habitudes du propriétaire et tester en priorité les variantes les plus probables. Ce qui change tout, parce que le nombre total de combinaisons possibles est en général astronomique.

Bref, ne changez jamais un mot de passe à 3h du matin après quelques verres. Et si c'est déjà fait, gardez l'espoir, Claude a peut-être une idée.

Source : Tom's Hardware

Pour activer ce nouveau pilote graphique libre, il faut littéralement réclamer un pilote cassé

Je ne vous apprends rien, un GPU, c'est la puce qui calcule l'image que vous voyez à l'écran. Pour qu'elle fonctionne, il lui faut un pilote, le logiciel qui fait le lien entre le matériel et le système d'exploitation.

Sur les puces Arm Mali, qu'on retrouve dans des tas de smartphones et de cartes type Raspberry Pi, Arm ne fournit pas de pilote libre. Du coup une bande de développeurs a monté Panfrost, un pilote libre reconstruit en grande partie par reverse-engineering, c'est-à-dire en observant le comportement du matériel pour deviner comment il marche.

Panfrost et son cousin PanVK, la version dédiée à Vulkan (l'interface graphique moderne pour les jeux et les applications 3D), viennent de prendre en charge le Mali G1 Pro. C'est le GPU le plus récent d'Arm, basé sur l'architecture maison baptisée "v14". Jusqu'ici, le haut du panier supporté s'arrêtait au Mali-G725 sorti en 2024. Le support arrivera officiellement avec Mesa 26.2, la prochaine grosse version de la bibliothèque graphique libre, attendue le trimestre prochain.

Pour comprendre pourquoi c'est un gros sujet, il faut savoir qui utilise Panfrost. Tous ceux qui font tourner Linux sur du matériel Arm, des cartes de bricolage aux ordinateurs portables ou aux téléphones reconvertis, en dépendent pour avoir une accélération graphique digne de ce nom.

Sans ces pilotes libres, ce matériel reste à moitié aveugle côté affichage. Que le projet suive d'aussi près les puces les plus récentes d'Arm, c'est donc tout sauf un détail.

Attention quand même, on est très loin d'un truc fini. Les tests sont encore limités, des morceaux peuvent manquer ou être carrément cassés. Et les développeurs ne s'en cachent pas : pour activer le pilote Vulkan sur ces nouvelles puces, il faut passer par une variable d'environnement nommée, je vous jure que c'est vrai, PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1. Soit "je veux un pilote Vulkan cassé" en français. Difficile d'être plus honnête.

Côté modèles, le G1 Pro est pris en charge mais ses grands frères, les G1-Premium et G1-Ultra, ne sont pas encore de la partie. Ça viendra sûrement, c'est souvent comme ça que le projet avance : une puce après l'autre, à mesure que le reverse-engineering progresse et que les développeurs comprennent les entrailles de chaque nouvelle architecture.

Source : Phoronix

Un capteur LiDAR matriciel pour donner la vue en relief à un petit robot

Le LiDAR, c'est cette techno qui mesure des distances en envoyant des impulsions laser et en chronométrant leur retour, un peu comme un sonar, mais avec de la lumière. On en entend parler surtout pour les voitures autonomes ou les robots aspirateurs.

Mellow Labs , une chaîne qui bidouille du hardware, s'est procuré un capteur LiDAR un peu particulier : un modèle matriciel. C'est-à-dire un capteur qui ne mesure pas une seule distance droit devant lui, mais toute une grille de points d'un coup.

Concrètement, ce capteur fonctionne comme une grille de 64 capteurs (8 sur 8) qui sort une carte des distances comprises entre 2 cm et 3,5 m. Au lieu de savoir juste "il y a un obstacle à un mètre", le robot récupère une vraie image en relief de ce qu'il a devant lui.

La différence est énorme : un capteur classique vous dit qu'il y a quelque chose, un capteur matriciel vous dit quoi, où, et à quelle hauteur. C'est tout de suite plus exploitable pour un engin qui doit se débrouiller seul, parce qu'il peut distinguer un mur d'une marche, ou un obstacle au sol d'un truc suspendu.

Mellow Labs a greffé ce capteur sur Zippy, son petit robot à chenilles imprimé en 3D et piloté par un ESP32, la puce bon marché qu'on retrouve dans la moitié des projets de bricolage électronique de la planète. L'objectif : faire passer Zippy du mode télécommandé à un vrai mode autonome. Avec sa grille de points, le robot peut enfin voir le sol devant lui et décider tout seul où aller. Enfin, en théorie.

Sauf que voilà, ça ne s'est pas fait en claquant des doigts. Premier souci, la moitié des données du capteur ne servait à rien, parce que la grille captait aussi le sol juste sous le robot. Du coup il a fallu trier, ne garder que la partie utile, et réduire encore le volume de données à traiter.

Mellow Labs a fait plusieurs allers-retours, avec, comme souvent désormais, un coup de main d'un modèle d'IA pour générer le code, avant que l'ensemble tourne enfin correctement !

Source : Hackaday

Ces fléchettes incendiaires géantes du XVIe siècle viennent enfin d'être testées

La Mary Rose, c'était le navire de guerre préféré d'Henri VIII. Il a coulé en 1545 au large de Portsmouth, son épave a été retrouvée en 1971 puis remontée en 1982, et depuis, tout ce qu'elle contenait fascine les historiens.

Parmi les objets sortis de la coque, il y avait des armes assez mystérieuses : d'énormes fléchettes qui semblaient conçues pour transporter une charge incendiaire. Personne ne savait vraiment comment elles fonctionnaient. Tod's Workshop, une chaîne YouTube spécialisée dans la reconstitution historique « testée pour de vrai », vient de s'attaquer à la question avec d'autres passionnés.

Le principe de ces fléchettes, une fois reconstituées à partir des fragments d'époque, est plutôt vicieux. À l'intérieur d'un revêtement en tissu enduit de poix, on trouvait un mélange incendiaire. Des mèches en bois mettaient le feu au contenu après un délai, et le résultat donnait des flammes quasiment impossibles à éteindre. Sur un navire en bois bourré de cordages et de voiles, vous imaginez les dégâts. Un cauchemar.

Restait à comprendre comment on envoyait ce truc sur le bateau ennemi. L'équipe a testé trois pistes. Le lancer à la main, d'abord, depuis le nid de pie (en haut du mat), ce qui semblait jouable pour atteindre un navire collé au vôtre. Ensuite un canon retrouvé juste à côté des fléchettes sur l'épave, un canon mal coulé et pointé vers le haut, ce qui n'est sûrement pas un hasard. Et faute de canon à poudre noire grandeur nature, ils ont reproduit un modèle réduit propulsé à l'air comprimé pour mesurer ce qui se passait vraiment.

Et c'est là que ça se complique. À pleine charge, la fléchette ne survit pas : l'accélération brutale la fait carrément se désintégrer avant même de partir. Par contre, avec une charge réduite, elle tient le coup et peut frapper une cible proche.

Une fois plantée dans la structure du navire adverse, les tests montrent qu'elle fait de gros dégâts. Donc l'arme n'était pas faite pour tirer loin, mais pour cramer le bateau d'en face dans un combat rapproché. Ce qui colle plutôt bien, d'ailleurs, avec la façon dont on se battait en mer à l'époque : on s'approchait, on s'accrochait, et on essayait de mettre le feu avant l'abordage.

Bref, une arme de 1545 qu'on ne comprenait pas, élucidée avec un peu d'air comprimé et beaucoup de patience, c'est improbable mais passionnant.

Source : Hackaday

Unitree lance son robot mecha à 500 000 dollars

500 000 dollars. C'est le prix d'entrée annoncé pour le GD01 d'Unitree, un robot mecha de 2,7 mètres de haut que vous pouvez littéralement piloter depuis son torse, façon Pacific Rim version chinoise. Unitree, le fabricant chinois déjà connu pour ses chiens-robots quadrupèdes, passe au stade de la production en série pour son engin transformable.

Le robot pèse 500 kilos avec son pilote à bord, soit clairement plus qu'un quad de loisir. Sa particularité, et c'est là qu'on bascule dans le délire science-fiction, c'est qu'il peut passer de la marche bipède à un mode quadrupède pour les terrains plus accidentés.

La vidéo de démonstration montre le patron Wang Xingxing en train de piloter l'engin, qui défonce un mur de briques d'un coup de poing métallique. Voilà voilà.

Côté chinois, ce n'est pas vraiment une surprise. Les fabricants locaux pèsent déjà environ 90% des ventes mondiales de robots humanoïdes en 2025, et Unitree fait partie des leaders du secteur. La boîte a même déposé son dossier d'introduction en bourse à Shanghai en mars dernier, avec 4,2 milliards de yuans à lever (environ 530 millions d'euros), dont 85% fléchés vers la recherche et développement. Le business des robots commence à devenir sérieux.

Au passage, ça marque une vraie différence d'approche avec les humanoïdes plus classiques, type Optimus chez Tesla ou Atlas chez Boston Dynamics (le fabricant américain de robots quadrupèdes et humanoïdes).

Eux visent un robot de taille humaine, autonome, destiné à assister ou remplacer des tâches du quotidien. Unitree, à l'inverse, propose un engin que vous habitez de l'intérieur, plus proche d'un exosquelette géant que d'un assistant compagnon. Pas le même produit, pas le même marché.

Unitree positionne le GD01 sur des usages assez spécifiques : parcs d'attractions, tournages de films, opérations de sauvetage en milieu hostile, expériences immersives. Pas franchement le genre de robot que vous garez dans le garage en rentrant du boulot. Le constructeur prévient d'ailleurs que le prix est "préliminaire" et qu'il bougera selon les optimisations à venir.

Bon, avant de rêver à votre propre mecha, quelques bémols quand même. Les experts pointent des soucis assez basiques : c'est galère d'entrer et de sortir du cockpit, l'autonomie batterie est limitée, le confort est minimal, et personne ne sait encore comment encadrer ce genre d'engin côté réglementation. Sans parler de la maintenance d'une bête mécanique de 500 kilos. Alors, vous sortez la carte bleue ?

Source : Gagadget

Valve a planqué un Wilhelm Scream dans le nouveau Steam Controller

Un utilisateur de Reddit a découvert cette semaine que le nouveau Steam Controller de Valve, vendu 100 euros en pré-commande sur le site de Steam, contient un easter egg complètement absurde : si vous lâchez la manette en mode Big Picture (l'interface plein écran de Steam, pensée pour être affichée sur une télé), elle pousse un Wilhelm Scream.

Pour ceux qui n'auraient jamais entendu ce nom, le Wilhelm Scream est un cri d'agonie enregistré en 1951 pour le film Distant Drums, et samplé depuis dans plus de 400 films d'Hollywood (Star Wars, Indiana Jones, Toy Story, et à peu près tout ce que Spielberg ou Lucas ont touché). C'est devenu une blague d'initiés de l'industrie du son.

Le truc, c'est que la manette ne contient pas de haut-parleur. C'est l'un de ses moteurs haptiques (les petits vibreurs qui font la vibration immersive sous les doigts) qui joue le son. Un moteur de vibration peut en effet être piloté avec un signal très fin pour reproduire à peu près n'importe quel son audible, comme un petit haut-parleur planqué dans le boîtier. C'est le même principe que sur la Switch ou la DualSense de la PS5, juste poussé à l'extrême pour cracher un cri reconnaissable.

Pour le déclencher, branchez la manette, lancez Steam en Big Picture, et lâchez le bidule sur quelque chose de mou. Coussin, canapé, oreiller. Ne jetez pas votre Steam Controller à 100 euros contre un mur pour tester, ce serait quand même un peu balot. Et ça n'arrive pas systématiquement : le Redditor qui a déterré l'easter egg a relevé une attented'environ une minute entre deux cris, histoire d'éviter que les gens en fassent une boucle audio en saccageant leur manette.

Au-delà de la blague, le nouveau Steam Controller affiche une bonne fiche technique. Deux trackpads pour un contrôle souris au pad, gyroscope complet pour la visée fine dans les FPS, et de nouveaux sticks magnétiques censés résister au stick drift (ce phénomène pénible où le stick croit qu'on le pousse alors que personne ne le touche). La manette est pensée pour fonctionner avec le PC, la Steam Deck, et la prochaine Steam Machine, la console salon de Valve qui doit débarquer plus tard cette année.

C'est typiquement le genre de détail qui montre qu'il y a encore des gens chez Valve qui font les choses pour le plaisir. Un easter egg sonore caché dans un accessoire à 100 euros, ça n'apporte rien commercialement, mais c'est franchement chouette.

Bref, ne lâchez pas votre Steam Controller pour le plaisir. Ou si.

Source : PC Gamer

OpenZFS 2.4.2 sort avec le support du noyau Linux 7.0

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

Au Royaume-Uni, les enfants contournent la vérification d'âge avec des fausses moustaches dessinées

Le Royaume-Uni a mis en place via l'Online Safety Act un système de vérification d'âge obligatoire sur les plateformes accessibles aux mineurs, avec contrôles biométriques à la clé pour estimer l'âge à partir d'un selfie.

Sur le papier, c'était la grande solution pour empêcher les ados d'accéder à TikTok, Instagram ou aux sites pour adultes. En pratique, c'est l'inverse : les enfants britanniques se passent les méthodes pour passer outre, et les méthodes en question sont parfois franchement drôls

En fait, selon une étude d'Internet Matters, près de la moitié des enfants britanniques (46 %) considèrent les systèmes de vérification d'âge comme faciles à contourner, et un tiers reconnaissent l'avoir déjà fait.

Les méthodes documentées vont de la classique fausse date de naissance au VPN, mais aussi à des techniques plus créatives : envoyer une vidéo du visage de quelqu'un d'autre, voire d'un personnage de jeu vidéo, et le meilleur : se dessiner une moustache au feutre pour tromper l'estimation d'âge faciale. J'adore.

Côté plateformes, c'est du coup difficile à gérer. L'Online Safety Act prévoit des amendes importantes contre les services qui laisseraient passer ces contournements, mais le régulateur Ofcom rame pour qualifier la responsabilité quand le gosse a triché lui-même avec une astuce que la plateforme n'a pas su détecter.

Internet Matters relève d'ailleurs que les adultes profitent aussi de ces failles, ce qui complique encore le tableau quand un majeur peut piquer la session d'un mineur, ou inversement.

L'autre limite, c'est la captation des données biométriques. Pour vérifier qu'un gosse est bien un gosse, il faut analyser son visage, ce qui veut dire stocker (ou au moins traiter) une image biométrique d'un mineur.

Plusieurs experts ont déjà soulevé le paradoxe : pour protéger les enfants, on les oblige à transmettre leur visage à une plateforme étrangère. Et si la plateforme se fait pirater (spoiler : ça arrive régulièrement), on a une fuite de données très sensibles dans la nature.

Vous l'avez compris, une régulation qui se fait contourner par un coup de feutre sous le nez, c'est probablement le signe qu'il faut revoir la copie.

Source : Independent

Les Pays-Bas migrent leur code vers Forgejo et claquent la porte de GitHub

Le gouvernement néerlandais a ouvert sa propre instance Forgejo à l'adresse code.overheid.nl, hébergée sur les serveurs de l'État via SSC-ICT (le service informatique mutualisé du gouvernement).

L'idée dans cette démarche, c'est de regrouper tout le code source produit par les administrations sur une plateforme libre et hébergée localement, plutôt que de continuer à dépendre de GitHub (Microsoft) ou de GitLab dont les versions entreprise sont fermées.

Forgejo, c'est un fork de Gitea, lui-même fork de Gogs, et il est complètement libre sous licence GPLv3+. Pas d'édition entreprise propriétaire, pas de fonctionnalités payantes planquées derrière des plans premium.

Du libre pur. C'est exactement ce que cherchent les administrations qui en ont marre de devoir confier leur code à une boîte américaine soumise au CLOUD Act. Les Pays-Bas ont vu la France galérer avec sa souveraineté numérique pendant des années et ont préféré agir vite plutôt que de discuter encore cinq ans.

Plusieurs ministères ont déjà migré : Finances, Affaires étrangères, Agriculture, Intérieur. Côté municipalités, La Haye, Utrecht, Leiden et Arnhem sont aussi de la partie.

Screenshot

Parmi les premiers dépôts publiés, vous avez le code du Conseil électoral néerlandais qui gère les élections, et plusieurs projets de digital workplace de l'Intérieur. Pour l'instant c'est encore en pilote pour récolter les retours développeurs, mais le déploiement s'élargit petit à petit.

Ce qui est intéressant dans la démarche, c'est la cohérence avec ce que les Pays-Bas ont déjà acté : sortie progressive de Microsoft Office au profit d'alternatives ouvertes, exigence de souveraineté sur les données de santé et refus du CLOUD Act sur certains marchés publics.

La migration Forgejo arrive dans cette logique de réduction systématique des dépendances aux géants américains, sans pour autant tomber dans le repli technologique total.

Bref, vous l'avez compris, pendant que d'autres pays publient encore des rapports sur la souveraineté numérique, les Pays-Bas ont juste appuyé sur le bouton.

Source : Itsfoss

Apple ajoute le chiffrement bout-en-bout entre iPhone et Android pour les RCS dans iOS 26.5

Avec iOS 26.5, Apple corrige enfin un manque que tout le monde signalait depuis l'arrivée du RCS sur iPhone : les messages échangés entre un iPhone et un Android n'étaient pas chiffrés.

Côté iPhone-vers-iPhone, les iMessage sont protégés de bout en bout depuis des années. Mais sitôt que la conversation passait par Android, la communication redevenait en clair, comme un bon vieux SMS. Plus pour longtemps.

Apple a travaillé avec la GSMA pour finaliser la version 3.0 de l'Universal Profile RCS, qui intègre le chiffrement de bout en bout en s'appuyant sur le protocole MLS (Messaging Layer Security). MLS, c'est ce qu'Apple, Google, Facebook et d'autres ont construit ensemble pour standardiser le chiffrement des messageries de groupe à l'échelle d'Internet.

Les RCS de l'iPhone vers Google Messages (et inversement) profitent maintenant directement de cette nouveauté, avec un petit cadenas dans la conversation pour vous le signaler.

Quelques contraintes quand même. Pour que le chiffrement marche, l'iPhone devra tourner sous iOS 26.5 ou plus récent, et l'Android doit être sur la dernière version de Google Messages. Surtout, l'opérateur télécom des deux côtés doit supporter cette mouture du RCS, ce qui n'est pas garanti partout dans le monde, et certains MVNO (les opérateurs sans réseau, type Sosh ou RED en France) traînent toujours sur les anciennes versions.

Le déploiement va donc se faire petit à petit. Sur le reste, plusieurs limitations de iMessage entre plateformes persistent : pas de message rappel, pas de réponse à un fil précis, pas de réactions emoji.

iOS 26.5 est en bêta depuis fin mars, en release candidate depuis cette semaine, et la sortie publique est attendue dans les jours qui viennent sans qu'Apple ait encore donné de date officielle. Le chiffrement RCS sera activé par défaut, avec un toggle dans les réglages de Messages pour le couper si vraiment vous voulez (ce qui n'a pas un grand sens, mais bon, vous faites ce que vous voulez de votre vie privée).

Bref, Apple boucle enfin la dernière brèche du RCS multiplateforme, presque deux ans après son intégration initiale.

Source : Ghacks

Chrome installe en douce un modèle IA de 4 Go sur votre disque sans rien demander

Alexander Hanff, consultant, a remonté un truc pas net sur Chrome. La dernière version du navigateur télécharge en arrière-plan un modèle de langage local appelé Gemini Nano, qui pèse environ 4 Go, sans jamais demander la moindre permission à l'utilisateur.

Le fichier s'appelle weights.bin, il atterrit dans un dossier OptGuideOnDeviceModel quelque part dans votre profil Chrome, et il sert ensuite à des fonctions du genre "Help me write" ou détection de fraude.

Hanff a documenté l'opération via les logs système de son macOS. Le 24 avril 2026 vers 16h38, Chrome crée le dossier. Quelques minutes plus tard, il télécharge et décompresse les 4 Go (l'opération prend une quinzaine de minutes), puis il les déplace à l'emplacement final. Tout ça pendant que vous ne touchez rien à votre machine. Si vous supprimez le fichier à la main, il sera réinstallé silencieusement au prochain lancement du navigateur.

Hanff estime entre 100 millions et 1 milliard de machines concernées dans le monde. Multipliez 4 Go par 1 milliard et vous obtenez de quoi remplir une bonne partie d'un datacenter.

L'auteur calcule également l'impact carbone du déploiement, entre 6 000 et 60 000 tonnes de CO2e rien que pour le réseau, sans compter l'empreinte SSD. Pour un fichier que personne ne vous a demandé d'installer.

Sur le plan légal, Hanff parle d'une "violation directe" de l'article 5(3) de la directive ePrivacy européenne, qui interdit de stocker quoi que ce soit sur l'appareil d'un utilisateur sans consentement explicite. Il évoque aussi un manquement RGPD. Si la qualification tient, ça serait une amende salée pour Google, sachant que les Cnil européennes ont déjà sanctionné Meta et Microsoft pour des choses bien moins foireuses.

Pour s'en débarrasser, trois options : aller dans chrome://flags pour désactiver les fonctions IA, passer par les politiques d'entreprise si vous gérez un parc de machines, ou virer Chrome, tout simplement.

Bref, Google qui pousse 4 Go d'IA en silence sur des centaines de millions de machines, c'est un sale moche.

Source : That Privacy Guy

Un passionné a recréé l'Apple Lisa de 1983 dans un FPGA

Voilà un projet qui sort un peu de l'ordinaire. Un développeur a passé huit mois à réimplémenter intégralement l'Apple Lisa, l'ordinateur lancé par Apple en 1983, à l'intérieur d'un FPGA. Le résultat tourne.

Il charge le système d'exploitation Lisa OS et fait fonctionner les logiciels de l'époque comme à la sortie de la machine, sans la moindre puce d'origine. Juste une description matérielle Verilog/VHDL synthétisée sur une carte FPGA moderne.

Pour ceux qui ne suivent pas le rétro-Apple, l'Apple Lisa, c'est l'ancêtre direct du Macintosh. Premier ordinateur grand public d'Apple à intégrer une interface graphique avec souris, prévu pour les pros, mais vendu à un prix faramineux à l'époque (autour de 10 000 dollars de 1983), ce qui l'a tué commercialement avant que le Mac plus accessible vienne reprendre le flambeau l'année suivante.

Aujourd'hui, les Lisa qui marchent encore sont des objets de collection rares, surtout que les disques Twiggy d'origine étaient une catastrophe en termes de fiabilité.

Recréer la machine en FPGA permet de la faire vivoter sans dépendre de pièces qui n'existent plus, et c'est aussi un bel exercice de reverse engineering. Il faut bien bien comprendre le bus, le contrôleur graphique, les puces custom, les timings exacts, et tout retranscrire dans un langage de description matérielle.

Le développeur a documenté chaque sous-système au fil de la construction... On parle là d'un travail de fond qui ferait passer une thèse pour un travail dominical.

Le projet est documenté en vidéo. Le créateur explique chaque étape du portage, les bugs rencontrés (le Lisa avait un système de gestion mémoire inhabituel pour l'époque), et démontre l'ordinateur en train de tourner sur sa carte FPGA finale. Les fichiers du projet (sources Verilog, schémas, images de ROM) sont a priori disponibles pour les amateurs qui veulent reproduire la chose à la maison.

C'est chouette comme projet ! Le rétro-computing à coup de FPGA, c'est probablement la seule façon de garder vivantes des machines comme la Lisa pour les décennies qui viennent.

Source : YouTube

Il démonte une caméra gimbal de drone Shahed-136 récupéré en Ukraine

Un chercheur du nom de Michel a mis la main sur une caméra de surveillance issue d'un drone Shahed-136 abattu en Ukraine, et il en a fait un démontage très complet.

Le Shahed-136, ce drone iranien que la Russie a adopté massivement et qu'elle modifie au fil des mois avec des charges utiles supplémentaires, embarque ici une caméra thermique pour les missions de nuit, montée sur un gimbal motorisé, le tout dans un boîtier qui tient dans la main.

Ce qui frappe quand on regarde l'intérieur, c'est l'origine des pièces. Vous avez deux cartes basées sur un FPGA Artix-7, plus un SoC Hi3519 qui s'occupe du flux vidéo. Le Hi3519, c'est un composant chinois qu'on trouve sans peine sur AliExpress et qui équipe une bonne partie des caméras IP grand public.

Ajoutez à ça une carte d'alimentation commerciale, une carte relais classique, un télémètre, et vous avez un assemblage qui ressemble plus à un projet maker qu'à du matériel militaire.

Côté gimbal, le constat est encore plus parlant : la majorité des composants sont occidentaux. Les marquages laser ont été soigneusement grattés ou poncés pour effacer la traçabilité, mais les pièces restent identifiables au format.

C'est cohérent avec ce qu'on voit depuis le début du conflit, avec ces drones russes bourrés de puces Texas Instruments, Analog Devices, STMicroelectronics ou Infineon censées ne jamais finir dans une arme.

Ce qui est fou dans cette histoire, c'est le contraste avec les missiles russes plus haut de gamme, où les ingénieurs partent de circuits sur mesure et de composants militarisés. Ici c'est plus simple. Du dev board reconverti et du off-the-shelf, sans doute parce que produire un Shahed à 50 000 dollars la pièce ça oblige à raboter partout, et que personne ne va concevoir une carte custom pour un drone qui se crashe par définition.

Source : Hackaday

Un slider caméra à trois axes bricolé avec des pièces d'imprimante 3D

Un slider caméra, c'est ce rail motorisé sur lequel on pose un appareil photo ou une caméra pour qu'elle glisse latéralement pendant la prise de vue, et obtenir ce travelling propre qu'on voit dans les pubs ou les vidéos YouTube un peu soignées.

CNCDan , lui, a voulu pousser le concept un cran plus loin avec un système à trois axes (haut/bas, gauche/droite, et une rotation), pour filmer ses propres projets. Et il l'a construit avec ce qu'il avait sous la main : un stock de pièces d'imprimante 3D.

Pourquoi ça marche bien comme base ? Les imprimantes 3D sont conçues autour de composants modulaires et standardisés (profilés aluminium extrudés, courroies, moteurs pas-à-pas, électronique), le genre de pièces taillées pour bouger une tête d'impression de quelques kilos avec précision. C'est exactement ce qu'on demande à un slider, sauf qu'à la place de l'extrudeur on met une caméra.

La logique tient debout. Mais CNCDan a vite découvert que ses moteurs n'étaient pas assez puissants pour bouger une caméra de 1,4 kg sans saccades, ce qui l'a obligé à revoir les rapports de réduction (le gearing) pour leur donner plus de couple.

Sauf que voilà, en touchant aux moteurs il a déréglé tout le reste. Cotes qui ne tombent plus juste, jeux qui apparaissent, plateforme qui ne tient plus en place. Du coup il a dû reprendre une grosse partie de la mécanique : nouvelle plaque de support découpée dans de l'acier (l'alu n'était pas assez rigide pour cette charge), nouveaux roulements montés à la presse, et un système de quick release pour fixer la caméra rapidement.

Et même comme ça, le mouvement n'était toujours pas fluide. Plusieurs semaines de réécriture du code de pilotage des moteurs ont été nécessaires pour obtenir une glisse vraiment propre.

Le résultat final tient la route. Le slider fonctionne sur une carte ESP32 et se pilote en Wi-Fi via une interface web ouverte depuis un autre ordi. 

CNCDan a aussi prévu que sa plateforme puisse accueillir d'autres caméras, y compris des smartphones, et il a publié les fichiers du projet sur GitHub si vous voulez reproduire la chose.

Lui-même reconnaît que ce n'était clairement pas la voie la plus simple pour avoir un slider, mais que ça lui a marché parce qu'il avait les pièces et les outils déjà chez lui.

Bref, du vrai DIY audacieux. Pas la solution la plus rapide, mais quand on a déjà l'atelier, c'est une chouette approche.

❌