Vue lecture

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

Plus de 1 000 environnements cloud infectés après une attaque sur le scanner Trivy

Un groupe de pirates a compromis Trivy, un scanner de vulnérabilités open source très utilisé dans les pipelines de développement. Résultat : plus de 1 000 environnements SaaS infectés par un malware qui vole des clés API, des identifiants cloud et des tokens GitHub.

Un scanner de sécurité devenu vecteur d'attaque

Trivy est un outil open source maintenu par Aqua Security. Il sert à détecter des failles, des mauvaises configurations et des secrets exposés dans du code, et il est intégré dans les chaînes de déploiement continu (CI/CD) d'un très grand nombre d'entreprises. Le groupe TeamPCP a réussi à compromettre la version 0.69.4 de Trivy en exploitant une mauvaise configuration dans le composant GitHub Action du projet.

En février, ils ont volé un token d'accès privilégié, et ce token n'a jamais été correctement révoqué. En mars, les attaquants l'ont utilisé pour injecter du code malveillant directement dans le projet, en poussant des images Docker et des versions GitHub vérolées vers les utilisateurs.

Le résultat : 75 des 76 tags de trivy-action ont été remplacés par des versions malveillantes.

La contamination s'étend

L'attaque ne s'est pas arrêtée à Trivy. Le même groupe a aussi compromis liteLLM, une bibliothèque Python qui sert d'interface pour les modèles de langage et qui est présente dans 36 % des environnements cloud.

Ils ont aussi touché KICK (un outil d'analyse statique de Checkmarx) et déployé CanisterWorm, un ver qui se propage via des paquets npm vérolés. Le malware installé est un infostealer qui extrait les clés API, les identifiants de bases de données, les tokens GitHub et toute information sensible accessible dans l'environnement de build.

Mandiant, la branche cybersécurité de Google, estime que plus de 1 000 environnements SaaS sont actuellement compromis, et que ce chiffre pourrait grimper à 10 000. TeamPCP travaillerait avec le groupe Lapsus$, connu pour ses attaques contre Microsoft, Nvidia et Uber.

Des révélations à la conférence RSA

Les détails de l'attaque ont été rendus publics lors de la conférence RSA. Le chercheur en sécurité Paul McCarty a été le premier à tirer la sonnette d'alarme, suivi par les équipes de Socket, Wiz et Aikido.dev. Aqua Security a vu ses 44 dépôts GitHub internes défacés, avec une exposition du code source et des configurations CI/CD.

L'affaire montre à quel point les outils de sécurité open source, quand ils sont mal protégés, peuvent devenir le point d'entrée idéal pour une attaque à grande échelle.

C'est quand même un comble : un scanner de vulnérabilités qui devient lui-même le vecteur d'une attaque. Le fait qu'un simple token non révoqué ait suffi pour compromettre toute la chaîne montre que la sécurité des projets open source reste un vrai sujet. Et quand on sait que liteLLM est présent dans plus d'un tiers des environnements cloud, on mesure l'ampleur du problème...

Source : The Register

Intel améliore les performances de ses GPU Arc dans les jeux sous Linux

Le pilote Vulkan open source d'Intel pour Linux vient de recevoir une optimisation qui améliore les performances des jeux DirectX 12 tournant via Proton.

La modification a été intégrée à Mesa 26.1 et concerne les cartes graphiques Arc Alchemist et Battlemage. Le patch avait été proposé pour la première fois en 2020, il aura donc fallu plus de cinq ans pour le voir arriver.

Ce qui change pour les joueurs Linux

L'optimisation porte sur la façon dont le pilote ANV gère le cache d'état graphique. En utilisant une combinaison de deux identifiants internes (Binding Table Pointer et Binding Table Index) au lieu d'un seul pour référencer les textures, le pilote peut supprimer certaines étapes de synchronisation qui ralentissaient le rendu.

Les développeurs d'Intel indiquent que le gain est mesurable sur tous les jeux DirectX 12 qu'ils ont testés via VKD3D-Proton, la couche de traduction utilisée par Steam pour faire tourner les jeux Windows sur Linux.

Pas de chiffres précis dans la note technique, mais une autre modification récente du même pilote (un simple changement d'une ligne de code pour le prefetch des tables de textures) avait déjà montré des gains allant jusqu'à 3 à 4 % sur God of War et Destiny 2.

Un patch qui a mis cinq ans à arriver

L'anecdote vaut quand même le détour. Ce patch a été proposé pour la première fois en novembre 2020, et il vient d'être fusionné dans Mesa en mars 2026.

Plus de cinq ans entre la proposition et l'intégration, ce qui donne une idée du rythme de développement des pilotes graphiques open source. Le code nécessite aussi un correctif au niveau du noyau Linux (dans le pilote Xe), qui devrait arriver avec Linux 7.1.

Les GPU concernés sont les Intel Arc à partir de la génération Alchemist (Arc A770, A750, etc.) et les plus récents Battlemage (Arc B580, B570).

Quelques limites quand même

L'optimisation ne fonctionne bien qu'avec les jeux DirectX 12. Sur les titres DirectX 11, les développeurs ont constaté des baisses de performances, ce qui fait que le mécanisme est activé automatiquement pour DX12 et désactivé pour DX11. Il est aussi possible de forcer son activation ou sa désactivation via un réglage dans la configuration DRI.

C'est le genre de petite avancée qui, mise bout à bout avec les autres, finit par rendre les GPU Intel Arc de plus en plus viables sous Linux pour le jeu. Cinq ans pour un patch, c'est long, mais le résultat est là. Et puis ça montre aussi que l'approche open source d'Intel sur ses pilotes graphiques continue de porter ses fruits, même si le chemin est quand même un peu plus lent que chez NVIDIA ou AMD.

Source : Phoronix

Opération Alice : 373 000 sites du dark web fermés, et les acheteurs piégés à leur tour

Europol vient de coordonner un coup de filet massif contre le dark web. En dix jours, 23 pays ont fermé plus de 373 000 sites frauduleux qui proposaient des contenus pédocriminels.

Le plus ironique : l'opérateur n'a jamais livré la moindre donnée, il arnaquait ses propres clients. Et ces clients sont désormais dans le viseur de la police.

Une opération dans 23 pays

L'opération Alice a été lancée le 9 mars et a duré dix jours. Sous la direction des autorités allemandes et avec le soutien d'Europol, des policiers de 23 pays ont participé à ce coup de filet, de la France aux États-Unis en passant par la Suisse, l'Australie et le Royaume-Uni.

L'enquête avait démarré en 2021 autour d'une plateforme baptisée "Alice with Violence CP", qui proposait des contenus pédocriminels à la vente sur le dark web. Au total, 105 serveurs ont été saisis, tous hébergés en Allemagne, et l'opérateur a été identifié : un homme de 35 ans basé en Chine, visé par un mandat d'arrêt international.

L'arnaqueur arnaqué

Le détail qui rend cette affaire si particulière : le suspect n'a jamais livré les contenus qu'il vendait. Il gérait environ 90 000 sites sur le réseau Tor qui proposaient des "packs" de 17 à 215 euros, payables en Bitcoin. Les acheteurs recevaient en échange... rien du tout.

En cinq ans d'activité, il a encaissé 345 000 euros auprès de 10 000 clients qui pensaient acheter des contenus pédocriminels. Un escroc qui arnaque des criminels, en somme.

440 suspects identifiés

Sauf que ces clients, même s'ils n'ont rien reçu, ont quand même tenté d'acheter des contenus illégaux. Europol a donc remonté les paiements en cryptomonnaies et identifié 440 personnes à travers le monde.

Plus de 100 d'entre elles font l'objet d'enquêtes actives. En Suisse, cinq personnes ont été placées en détention. En Allemagne, 14 suspects sont visés par des procédures. La France a mobilisé l'Office de protection des mineurs pour sa part de l'enquête.

On a quand même un type qui a monté 373 000 faux sites depuis la Chine et qui a encaissé 345 000 euros en arnaquant des gens qui voulaient acheter les pires contenus imaginables. Et grâce à lui, la police a maintenant une liste de 440 noms.

Source : Techspot

Un bras robotique imprimé en 3D pour apprendre la robotique chez soi

James Gullberg a mis en ligne un projet de bras robotique à 6 axes, principalement imprimé en 3D et conçu pour apprendre la robotique. Ce petit robot embarque un Raspberry Pi, des microcontrôleurs STM32 et tourne sous ROS 2.

Le tout pour un budget qui reste accessible, avec des mouvements décrits comme étonnamment fluides pour du fait maison.

Un bras robot signé James Gullberg

James Gullberg a publié sur son site un projet qui risque de plaire aux bricoleurs : un bras robotique compact à 6 degrés de liberté, dont la structure est quasi intégralement imprimée en 3D. Seuls les systèmes d'entraînement font appel à des pièces métalliques.

Le projet est pensé comme un outil pédagogique. On n'est pas sur un robot industriel, mais sur une plateforme d'expérimentation qui permet de toucher à la conception mécanique, à la planification de mouvement et au contrôle logiciel.

Six axes, un Raspberry Pi et ROS 2 sous le capot

Côté mécanique, chaque articulation a droit à son propre système de réduction. La base utilise un réducteur planétaire classique, tandis que l'épaule et le coude embarquent des réducteurs planétaires à anneau fendu, qui offrent une densité de couple élevée par rapport à leur encombrement.

Le poignet s'appuie sur un différentiel à courroie inversé. Pour le retour de position, des aimants alternés sont intégrés directement dans la couronne de sortie et suivis par un encodeur magnétique.

Un microcontrôleur STM32 gère le contrôle moteur avec des boucles PID et de la génération de pas. Un Raspberry Pi fait office d'ordinateur de bord et communique avec les moteurs via un bus CAN. Le tout tourne sous ROS 2.

Le résultat est visiblement assez bluffant : les vidéos montrent des mouvements fluides, bien loin de ce qu'on pourrait attendre d'un projet fait maison.

Apprendre la robotique sans se ruiner

Ce projet rejoint une vague de bras robotiques open source accessibles. On pense au Thor, au HELENE ou encore au BCN3D Moveo. Mais celui de Gullberg se distingue par la variété des mécanismes employés. Chaque articulation utilise un design différent, et c'est voulu : le but est d'expérimenter, pas de produire en série.

Côté budget, on ne connaît pas le coût exact, mais les composants restent a priori sur des montants franchement raisonnables, puisqu'on parle là d'un simple STM32, d'un modeste un Raspberry Pi, e quelques moteurs et bien évidemment du filament pour imprimante 3D. Bref, on est loin des prix d'un kit de robotique du commerce.

Ce mini bras robotique coche quand même beaucoup de cases. Il est ouvert, documenté, modulaire, et il permet de toucher à des concepts qui coûtent habituellement une fortune en formation.

Source : JCGullberg

MS-DOS tourne maintenant sur un Apple IIe, et c'est un projet open source

Un développeur a réussi à porter MS-DOS 2.0 sur l'Apple IIe, l'ordinateur personnel d'Apple sorti en 1983. Le projet, baptisé "reboot-camp-83", repose sur une carte d'extension qui embarque un processeur Intel 8088 à 8 MHz.

Le tout communique avec le processeur 6502 de l'Apple II, et le code est en accès libre. Quarante ans de retard, mais le geste est là, et il est plutôt classe.

Un processeur Intel dans un Apple II

Seth Kushniryk vient de publier "reboot-camp-83", un projet open source qui permet de faire tourner des applications MS-DOS 2.0 sur un Apple IIe. Pour que ça fonctionne, il faut une carte d'extension AD8088, fabriquée à l'époque par ALF Products.

Cette carte contient un processeur Intel 8088 qui tourne à 8 MHz et qui se branche sur le bus d'extension de l'Apple II. On se retrouve avec deux processeurs dans la même machine : le 6502 d'Apple et le 8088 d'Intel.

Kushniryk a développé un programme "pont" qui fait communiquer les deux processeurs. Il a aussi déplacé ce programme dans une zone différente de la RAM pour libérer de la place et permettre l'affichage en haute résolution.

Le tout a demandé pas mal de travail de débogage, avec entre autres un problème lié à une contrainte non documentée de ProDOS.

Ce que ça fait tourner, et ce que ça ne fait pas

Le port est compatible avec la quasi-totalité des logiciels MS-DOS 2.0, à une condition : que le programme n'écrive pas directement dans la mémoire vidéo. C'est une limitation qui exclut pas mal de jeux, mais les applications de productivité et les utilitaires fonctionnent.

Pour l'époque, avoir un processeur à 8 MHz dans un Apple IIe, c'était quand même une sacrée puissance de calcul, et pouvoir lancer des applications DOS en parallèle du système Apple aurait été un vrai avantage.

Le projet est entièrement open source et disponible sur le dépôt git de Kushniryk. Les mises à jour et la documentation sont publiées sur son site personnel.

Quarante ans de retard, mais c'est le geste qui compte

L'Apple IIe a été commercialisé en 1983, et MS-DOS 2.0 la même année. À l'époque, les cartes coprocesseur existaient déjà pour faire tourner CP/M-86 sur Apple II, mais le port complet de MS-DOS n'avait jamais été finalisé publiquement.

Kushniryk comble ce vide quarante ans plus tard, avec un projet qui relève plus de la prouesse technique et de la passion du rétro-computing que d'un usage pratique.

C'est le genre de projet qui ne sert à rien... et c'est pour ça qu'on l'aime bien. Faire tourner MS-DOS sur un Apple IIe, c'est un peu comme mettre un moteur de Porsche dans une 2CV : ça ne va pas révolutionner les transports, mais ça force le respect.

Le fait que le projet soit open source et bien documenté en fait aussi une ressource intéressante pour ceux qui s'intéressent au fonctionnement des processeurs de cette époque. Franchement, si en 1983 quelqu'un avait pu lancer Lotus 1-2-3 sur son Apple IIe, on en parlerait encore.

Source : Hackaday

Ils ont mis une plante carnivore dans un accélérateur de particules, et elle a réagi

La chaîne YouTube Electron Impressions a placé une dionée attrape-mouche dans un accélérateur de particules pour voir ce qui allait se passer.

Résultat : toutes les mâchoires de la plante se sont refermées en même temps sous l'effet de la radiation ionisante. La plante a confondu le faisceau de particules avec une proie.

Comment la dionée attrape ses proies

La dionée attrape-mouche fonctionne grâce à un mécanisme assez fascinant. Ses mâchoires sont tapissées de petits poils sensibles qui détectent le contact d'un insecte. Quand un poil est touché, il active des canaux à calcium dans les cellules de la plante.

Ce mouvement d'ions crée un potentiel d'action, un signal électrique qui se propage sur toute la surface de la mâchoire et qui déclenche la fermeture. Le tout en une fraction de seconde.

Ce qui se passe sous un faisceau de particules

Quand la plante a été exposée au faisceau ionisant de l'accélérateur, toutes ses mâchoires se sont fermées d'un coup. La radiation a provoqué exactement le même mouvement d'ions que celui déclenché par un insecte : les ions quittent les cellules, créent une pression osmotique, et paf, la mâchoire se referme.

Sauf que cette fois, pas besoin de mouche. Le faisceau de particules a activé le mécanisme sur l'ensemble de la plante en une seule fois.

La plante n'y a pas survécu

Le problème, c'est que la radiation ionisante ne s'est pas contentée de chatouiller les canaux ioniques. Elle a aussi détruit l'ADN des cellules de la dionée, ce qui a tué la plante. L'expérience ne peut donc pas être répétée sur le même spécimen.

Electron Impressions avait d'ailleurs déjà fait parler d'eux en créant des éclairs de Lichtenberg piégés dans du verre avec le même accélérateur.

C'est le genre d'expérience un peu absurde qui donne envie de regarder la vidéo en boucle. Voir une plante carnivore réagir à un faisceau de particules comme si c'était une mouche, c'est quand même assez inattendu.

Et puis il faut le dire, ça rappelle que la biologie et la physique ne sont pas si éloignées qu'on le croit. Dommage pour la plante en tous cas.

Source : NIH.gov

Ce détecteur de drones à 15 balles fonctionne avec un simple micro et un ESP32

Un développeur a mis au point un système de détection de drones qui tient dans la main et coûte moins de 15 dollars.

Le projet Batear utilise un microcontrôleur ESP32-S3 et un micro pour repérer les drones par le son de leurs hélices. Le tout est open source et fonctionne sans connexion internet.

Écouter les hélices plutôt que chercher un radar

Le principe de Batear est assez simple en fait. Plutôt que d'utiliser un radar ou une caméra, le système analyse le son ambiant pour y détecter les fréquences caractéristiques des moteurs de drones.

L'algorithme de Goertzel surveille six fréquences précises entre 200 et 4000 Hz, qui correspondent aux harmoniques habituelles des rotors.

Quand l'énergie sonore sur ces fréquences dépasse un certain seuil par rapport au bruit ambiant, le système déclenche une alerte, et le tour est joué.

Tout le traitement se fait en local sur l'ESP32-S3, dans ses 512 Ko de mémoire vive. Pas de cloud, pas de serveur, pas de données qui transitent quelque part. Simple, efficace.

Moins de 15 dollars de matériel

Côté composants, il faut un ESP32-S3 et un micro MEMS ICS-43434 avec interface I2S. Et puis c''est tout. Le micro enregistre le son à 16 kHz, l'ESP32 analyse 512 échantillons toutes les 100 millisecondes, et le système consomme si peu d'énergie qu'il peut tourner sur batterie ou panneau solaire.

Le créateur, qui se fait appeler TN666, a publié l'ensemble du code sur GitHub sous le nom Batear. Il s'est d'ailleurs inspiré des dispositifs acoustiques d'avant l'invention du radar, comme les fameux cornets géants japonais des années 1930 qui servaient à repérer les avions à l'oreille.

Quelques limites quand même

Le projet en est encore à ses débuts. Batear a été testé avec des enregistrements audio de drones, mais pas encore en conditions réelles en extérieur. Le vent, le bruit de fond, la distance et le type de drone sont autant de variables qui peuvent fausser la détection.

Le créateur recommande d'ailleurs d'utiliser une protection en mousse sur le micro pour limiter les interférences du vent. Il envisage aussi d'intégrer des modèles TensorFlow Lite pour améliorer la fiabilité, et invite la communauté à contribuer au projet.

Pour 15 dollars et un peu de soudure, c'est le genre de projet bricolage qu'on a bien envie de tester. Alors bien sûr, ça ne remplacera pas un système anti-drone militaire, mais pour surveiller un jardin ou un terrain privé, ça peut rendre service.

Et puis l'idée de revenir aux bonnes vieilles méthodes acoustiques pour détecter ce qui vole au-dessus de nos têtes, il y a quand même un côté un peu rétro qui ne manque pas de charme, non ?

Source : Hackaday

Le Z80 est mort, vive le PicoZ80 - un Raspberry Pi émule le processeur mythique

Le Z80 de Zilog, le processeur qui a fait tourner le ZX Spectrum, le Game Boy et des dizaines de micro-ordinateurs des années 80, a été arrêté en juin 2024 après 48 ans de bons et loyaux services.

Un bricoleur a créé le PicoZ80 , une petite carte qui se glisse directement dans le même support et qui émule le processeur original grâce à une puce Raspberry Pi.

48 ans de service, et puis s'en va

Le Zilog Z80 a été lancé en 1976 et il a alimenté une bonne partie de l'histoire de l'informatique personnelle. ZX Spectrum, MSX, Amstrad CPC, Game Boy, calculatrices Texas Instruments : la liste des machines qui ont tourné avec ce processeur 8 bits est longue.

Zilog a annoncé sa fin de vie en avril 2024 et a cessé de prendre des commandes en juin de la même année. Les stocks de Z80 neufs en boîtier DIP-40 commencent donc à se raréfier, et c'est là que le PicoZ80 entre en jeu.

Un Raspberry Pi dans un boîtier DIP-40

Le PicoZ80, développé par le maker eaw, utilise un microcontrôleur RP2350B (la puce du Raspberry Pi Pico 2) monté sur un circuit imprimé au format DIP-40, avec le même brochage que le Z80 original. Un des deux coeurs Cortex-M33 à 150 MHz se charge d'émuler le Z80, pendant que le second gère l'accélération et les périphériques.

Les moteurs PIO du RP2350 prennent en charge les transactions de bus en temps réel, ce qui garantit un timing identique à celui du processeur d'origine. La carte embarque aussi 8 Mo de PSRAM, 16 Mo de flash pour stocker des images ROM, et un coprocesseur ESP32 qui ajoute le WiFi, le Bluetooth et un lecteur de carte SD.

Des machines classiques qui renaissent

Le PicoZ80 peut fonctionner comme un simple Z80 de remplacement, mais il propose aussi des "personas" de machines classiques. Des pilotes existent déjà pour le RC2014, le Sharp MZ-80A et le Sharp MZ-700, et d'autres sont en développement pour l'Amstrad PCW8256.

La carte fait aussi office d'expandeur mémoire, d'hôte USB et d'émulateur de disquette. Vous remplacez un processeur de 48 ans et vous gagnez au passage le WiFi et le stockage sans fil.

Bref, on parle quand même d'un projet qui ressuscite un processeur plus vieux que moi (de 1976) avec une puce à quelques euros. Pour les passionnés de rétro-informatique qui ont un vieux micro au fond du placard, c'est peut-être la meilleure nouvelle de l'année.

Source : Hackaday

PowerToys - Quand Microsoft corrige les manques de Windows

Si vous êtes sous Windows 10 ou 11, vous avez forcément déjà ragé sur un truc tout bête. Genre redimensionner 50 photos d'un coup, renommer des fichiers en masse, ou juste organiser vos fenêtres proprement sur un écran ultra-large. Tout ça, Windows ne sait pas le faire nativement et c'est bien dommage ! Heureusement, c'est là que les PowerToys entrent en jeu... Si vous ne connaissez pas encore ça, sachez simplement qu'il s'agit d'un pack d'une trentaine d'utilitaires open source, maintenus par Microsoft eux-mêmes qui s'installent comme ceci dans un powershell lancé en admin :

winget install Microsoft.PowerToys -s winget

C'est gratuit, c'est dispo sur GitHub, et franchement, c'est à se demander pourquoi tout ça n'est pas intégré par défaut dans l'OS. C'est fou quand même !

Le premier truc qui change la vie, c'est FancyZones. Si vous avez un grand écran, le Snap Layout de Windows 11 c'est... limité. Avec FancyZones, vous créez vos propres zones de dépôt. Vous maintenez MAJ, vous glissez une fenêtre, hop, elle se cale exactement où vous voulez. Une fois qu'on y a goûté, impossible de revenir en arrière.

Autre indispensable c'est PowerToys Run. Tapez Alt + Espace et une barre de recherche épurée apparaît comme Spotlight sur Mac. Ça cherche vos applis, vos fichiers, ça fait calculatrice et conversion d'unités. Bref, vous pouvez oublier le menu Démarrer (et ses pubs).

Pour garder une fenêtre au premier plan quoi que vous fassiez, Win + Ctrl + T et c'est réglé. Always on Top, ça s'appelle et ça se matérialise sous la forme d'une bordure colorée qui apparaît pour vous montrer que la fenêtre est "clouée". Pratique quand vous suivez un tuto tout en tapant du code à côté.

Côté renommage de fichiers, PowerRename remplace avantageusement des outils comme Ant Renamer . Clic droit sur vos fichiers, search & replace avec support des regex pour les plus courageux. Du coup, fini le renommage un par un comme en 2003.

Y'a aussi Color Picker (Win + Maj + C) qui transforme votre curseur en pipette pour chopper n'importe quel code couleur à l'écran. Et Text Extractor (Win + Maj + T) qui fait de l'OCR instantané sur une zone de votre écran. Attention, ça marche pas toujours selon la police, mais ça évite de retaper du texte à la main.

Le plus dingue, c'est Crop and Lock. Vous faites Win + Ctrl + Maj + R et vous découpez une zone d'une appli pour en faire une fenêtre indépendante. Genre un graphique ou un flux d'infos. Sous le capot, ça crée une sorte de proxy visuel de la fenêtre originale, et vous pouvez même continuer à interagir dedans.

Et si vous avez deux PC côte à côte, Mouse Without Borders vous permet de les contrôler avec la même souris et le même clavier. Vous passez d'un écran à l'autre comme si c'était la même machine. Et d'ailleurs, si vous perdez votre curseur sur vos écrans géants, y'a aussi un utilitaire ici pour retrouver sa souris facilement.

Après j'ai pas tout listé. Y'a par exemple un éditeur de variables d'environnement hyper fastoche à utiliser, un aperçu du registre (pour éviter les bêtises), une fonction "Command Not Found" pour vous aider dans le terminal, un redimensionneur d'images intégré au clic droit...etc. Bref, à vous de fouiller mais ce que je retiens c'est que Microsoft a mis 30 ans à admettre que son OS avait des manques, et au lieu d'y répondre au cœur de Windows, ils ont fait ce side project devenu indispensable.

Et pour ceux qui veulent gérer leurs installs avec une interface graphique, allez voir WingetUI . C'est le complément parfait.

Voilà. Installez ça et remerciez-moi plus tard !

Et si l'IA consommait moins d'énergie que Google ?

"Une requête ChatGPT consomme 10 fois plus d'énergie qu'une recherche Google."

Cette phrase, vous l'avez lue 100 fois. Mais est-ce vraiment vrai ?

Charles Duprat, chercheur en inclusion numérique, vient de publier un papier qui retourne complètement ce chiffre. Et même si je suis incapable de vérifier la validité scientifique de tout ce qu'il avance, ça vaut le coup d'en parler.

Son argument de base est simple et pas con. En fait quand on compare l'énergie d'une requête IA vs une recherche Google, on ne regarde en fait que ce qui se passe côté serveur, plutôt que l'ensemble de la chaîne. Le GPU Nvidia qui mouline d'un côté, l'index Google qui répond de l'autre.

Sauf que dans la vraie vie, une recherche web sur votre iPhone ou votre Android, c'est clairement pas juste un serveur qui tourne ! C'est le téléchargement de plusieurs mégaoctets via la 4G, c'est du JavaScript et du CSS qui font chauffer le CPU de votre téléphone, c'est du temps d'écran, et surtout c'est des dizaines de scripts publicitaires et de trackers qui tournent en arrière-plan. Et rien de tout ça n'apparaît dans le bilan "officiel".

Du coup, le chercheur a modélisé la comparaison au niveau de la session utilisateur complète. Donc pas juste la requête serveur, mais tout le trajet : réseau mobile, rendu de page, pubs, temps passé à lire. Et là, les résultats sont contre-intuitifs car pour une tâche complexe sur mobile (genre comparer des pompes à chaleur et des chaudières gaz), une session LLM consommerait environ 5,4 fois moins d'énergie qu'une session de recherche web classique. Dans le pire des cas modélisé, l'avantage reste quand même de 1,6 fois.

Alors d'où ça vient ?

D'abord, la page web médiane sur mobile pèse 2,56 Mo. Oui, 2,56 Mo pour une seule page web sur Chrome ou Safari qui est ensuite transmise en 4G à 0,17 kWh/Go, et ça, ça coûte déjà plus en énergie réseau qu'une inférence LLM complète. Une réponse ChatGPT ou Claude, c'est environ 5 Ko de texte brut. Le ratio de transmission est de 500 pour 1 avant même de parler du reste. Quand on sait déjà que la consommation réelle des datacenters est un sujet à tiroirs, ça relativise pas mal.

Et puis y'a le boulet de la pub programmatique ! Des études (Khan et al., 2024) montrent que les bloqueurs de pub intégrés comme Brave réduisent la consommation électrique du terminal de 15 à 44%. En gros, quand vous naviguez sur un site d'actu classique, jusqu'à 41% de l'énergie de la session sert à charger et exécuter du JavaScript publicitaire. Hé bien le LLM court-circuite tout ça en vous filant une réponse texte directe.

Comme je vous le disais en intro, je suis totalement incapable de valider la méthodologie de cette étude... Allez savoir si les paramètres sont bien calibrés. Et c'est un working paper, donc pas encore relu par des pairs, avec des simulations plus nombreuses. L'auteur se base sur des chiffres publiés par Google pour Gemini (0,24 Wh par prompt, issu d'un papier arXiv), par Epoch AI pour ChatGPT (0,30 Wh), et par Sam Altman lui-même (0,34 Wh). Et comme ces chiffres viennent des constructeurs eux-mêmes, ça mérite qu'on garde un oeil critique.

Par contre, l'étude a aussi l'honnêteté de poser ses propres limites car l'avantage s'effondre pour les requêtes simples en Wi-Fi depuis votre PC ou Mac (quasi parité LLM <> Google). Et surtout, ça s'inverse violemment dès qu'on passe aux modèles de raisonnement type o3 ou Deep Think, qui consomment 30 à 700 fois plus qu'une inférence standard parce qu'ils génèrent des chaînes de pensée à rallonge.

Le paradoxe de Jevons est aussi mentionné : si l'IA est plus efficace par requête, les gens en feront forcément plus, donc la consommation globale augmentera quand même. Et la question des modèles éco-responsables reste elle aussi entière.

Mais bon, cette étude remet quand même en question un truc qu'on répète tous sans trop réfléchir. Comparer un serveur IA à un serveur Google, c'est oublier que la recherche web moderne, c'est devenu "recherche + publicité + réseau mobile + rendering JavaScript + temps d'attention". Et comme Google lui-même commence à coller de l'IA (les AI Overviews) en plus par-dessus ses résultats classiques, ça devient un joyeux bordel à mesurer...

Bref, lisez l'étude vous-mêmes , c'est en accès libre. Et faites-vous votre propre avis !

Un développeur fait tourner du code Arduino sur une puce de 1980

Un développeur vietnamien a trouvé le moyen de faire fonctionner du code Arduino sur un microcontrôleur 8051, une architecture conçue par Intel en 1980.

L'astuce repose sur un émulateur RISC-V intégré directement dans la puce, et le tout est disponible en open source sur GitHub.

Une puce de 45 ans qui refuse de mourir

Le 8051, c'est un microcontrôleur 8 bits qu'Intel a conçu en 1980. L'anecdote veut que son architecture ait été dessinée en un week-end par l'ingénieur John Wharton.

Depuis, Intel a vendu plus de 100 millions d'unités rien que sur la première décennie, et des variantes compatibles sont encore produites et utilisées un peu partout, des souris d'ordinateur aux puces Bluetooth.

La version ciblée ici, c'est le STC8H8K64U, un dérivé moderne fabriqué par le chinois STC Micro. Il coûte moins d'un dollar et reste populaire en Asie, mais les outils de développement modernes ne le prennent pas en charge. D'où l'idée du projet.

Un émulateur RISC-V dans un 8051

Bùi Trịnh Thế Viên n'a pas cherché à porter le compilateur Arduino directement sur l'architecture 8051, ce qui aurait été un chantier monstre.

Il a opté pour une approche détournée : intégrer un émulateur RISC-V (appelé rv51, écrit en assembleur 8051 par un autre développeur, cyrozap) dans la puce STC8. Le code Arduino est compilé pour RISC-V, puis exécuté via cet émulateur.

Le projet est disponible sur GitHub sous le nom STC_Arduino_Core.

Des limites assumées

L'émulation a un coût. L'émulateur consomme 8 Ko de mémoire flash sur la puce, et la vitesse d'exécution est divisée par 100 à 1 000 par rapport au code natif. Pour le code qui demande du temps réel, comme la gestion des interruptions, il faut repasser sur de l'assembleur 8051 classique.

Et puis il faut le dire, des microcontrôleurs RISC-V natifs existent et coûtent à peine plus cher. Le projet reste donc un exercice technique et pédagogique, pas une solution de production.

C'est le genre de bidouille qui fait sourire. Faire tourner du code Arduino sur une architecture de 1980 via un émulateur RISC-V coincé dans 8 Ko, il fallait quand même y penser.

Bon par contre, on ne va pas se raconter d'histoires, en pratique ça n'a pas beaucoup d'intérêt face à un vrai microcontrôleur RISC-V à 2 euros. Mais l'exercice a le mérite de prouver que le 8051 a encore de la ressource, 45 ans après sa création.

Source : Hackaday

DOOM over DNS - 2000 records TXT pour buter des démons

« Can it run DOOM ? » Vous connaissez tous la question je pense. En effet, depuis 1993, le FPS d'id Software a tourné sur à peu près tout ce qui contient un processeur, des calculatrices aux écouteurs en passant par des tests de grossesse. Et là, Adam Rice vient de pousser le délire encore plus loin en stockant et en lançant le jeu entier... via des enregistrements DNS.

Oui, ce bon vieux protocole de plus de 40 ans, conçu à la base pour traduire des noms de domaine en adresses IP (RFC 1035, tout ça). En fait, la magie tient dans le fait que les enregistrements TXT n'ont aucune validation de contenu. Du coup, rien n'empêche d'y coller du texte arbitraire... genre un FPS complet converti en texte via base64. En gros, le DNS devient un stockage clé-valeur distribué mondialement et mis en cache un peu partout. Pas mal comme CDN du pauvre !

Le fichier WAD (les niveaux et assets du jeu, 4 Mo) passe à 1,7 Mo après compression, les DLLs du moteur de 4,4 Mo à 1,2 Mo, et le tout est découpé en 1 966 enregistrements TXT sur une seule zone CloudFlare Pro. Un record spécial contient également les métadonnées de réassemblage (nombre de chunks, hash de vérification).

Ensuite, côté joueur, un script PowerShell de 250 lignes résout les 2 000 requêtes, reconstruit le binaire en mémoire et hop, ça tourne. Les données du jeu ne touchent ainsi jamais le disque, puisque tout reste en mémoire. Le tout chargé en 10 à 20 secondes (PowerShell 7 requis) !

Le truc rigolo, c'est que l'auteur ne connaît pas le C#. C'est Claude (oui, encore cette fichue IA, ahaha) qui s'est tapé le portage en modifiant managed-doom, un port C# du moteur original, pour remplacer les lectures fichier par des flux mémoire et virer toutes les dépendances natives au profit d'appels Win32 directs. L'audio a été sacrifié pour réduire le nombre de records mais bon, on va pas chipoter. Après si vous voulez tester, sachez que ça ne fonctionne que sous Windows car ça repose sur PowerShell, donc pas de version Linux pour l'instant.

D'ailleurs, si le concept vous rappelle quelque chose, c'est normal. Planquer des données dans les enregistrements TXT, c'est en fait une technique bien connue en sécu. J'en parlais déjà avec DNSteal pour exfiltrer des fichiers via DNS , ou avec ces malwares carrément stockés dans les records DNS . Adam Rice le dit lui-même, son projet est parti de l'exploration de techniques d'implants (staging de shellcode via TXT records) sauf qu'au lieu de planquer un trojan, il y a planqué ce FPS de +33 ans. C'est quand même plus sympa !

À vrai dire, avant d'en arriver là, il a d'abord fait un proof of concept avec une image de canard (va savoir pourquoi). Encoder la photo en base64, découper en chunks, uploader via l'API CloudFlare, reconstruire de l'autre côté avec un hash identique et ça a marché du premier coup. Par contre pour la vidéo, oubliez, un MP4 de 1 Go ferait 670 000 enregistrements.

Voilà et tout ça pour 20 dollars par mois (le prix de la zone CloudFlare Pro). Donc si DOOM sur des écouteurs vous avait déjà fait sourire, attendez qu'un taré le fasse tourner avec que des paquets ICMP. Bah quoi ??

Bref, le code est dispo sur GitHub et le DNS a clairement pas fini de nous surprendre.

Source

Oups, le triple envoi

Si vous avez reçu ma newsletter 3 fois ce lundi, non, vous n'êtes pas dans la Matrice, et non, je ne suis pas non plus devenu un affreux spammeur de viagra.

En fait, mon plugin WordPress a juste décidé de partir en freestyle. Pour ceux qui ne le savent pas, mes newsletters sont générées automatiquement puisque c'est un récap de tout ce qui a été publié dans la semaine. Je suis tout seul aux manettes, j'ai pas une armée de stagiaires pour rédiger ça à la main, et croyez-moi, c'est pas dans mon intérêt non plus de vous spammer, car chaque envoi me coûte des sous-sous.

Bref, j'ai (normalement) corrigé le tir en intégrant un système de verrou dans le plugin pour que ça ne se reproduise plus. Tout est artisanal ici, c'est du fait maison, et jusqu'à présent ça tournait nickel. Pas de bol. Ouin.

Un grand merci donc à tous ceux qui m'ont gentiment signalé le problème. Vous êtes au top ! J'ai quand même eu droit à un "Allez ciao KorbenGPT" d'une personne qui visiblement ne s'est pas remis de ce trauma que je lui ai infligé avec mon spam involontaire de ce matin. Bon vent l'ami et beaucoup de courage pour la suite ^^.

Pour les autres, les vrais, ceux qui sont encore là sachez que si vous n'êtes pas encore abonné à la newsletter, c'est par ici . Et promis, je ferais tout ce qui en mon pouvoir pour qu'à l'avenir, vous ne la receviez qu'une seule fois. ;)

Merci

Il fabrique une enceinte avec uniquement un laser et une feuille d'or

Et bien pourquoi pas ? Ce garçon a en effet réussi à produire de la musique, simplement en pointant un laser de 5 watts sur une feuille d'or. Pas de membrane, pas de bobine, pas d'aimant : le son est généré directement par l'air, chauffé et refroidi à grande vitesse par le faisceau lumineux.

Cet concept a un nom, c'est l'effet photoaoustique, et il a été découvert en 1880 par Alexander Graham Bell, l'inventeur de la cloche (non ça c'est une vanne, pardon).

Un effet vieux de 145 ans

L'effet photoacoustique a été découvert par Alexander Graham Bell en 1880 en observant que des objets éclairés par la lumière du soleil pouvaient émettre des sons. Quand une lumière intense frappe un matériau, elle le chauffe.

Ce matériau transfère sa chaleur à l'air environnant, qui se dilate. Si la source lumineuse est modulée rapidement, les cycles d'expansion et de contraction de l'air produisent des ondes sonores. Pas besoin de membrane ni de bobine. Juste de la lumière et de l'air.

De la feuille d'or au casque imprimé en 3D

Le maker SomethingAboutScience a testé plusieurs approches. Un laser de 5 watts dirigé sur une feuille d'or a produit de la musique reconnaissable, la feuille d'or absorbant bien la lumière bleue et étant assez fine pour transférer rapidement la chaleur à l'air.

Le même laser dirigé dans du dioxyde d'azote a donné un son plus propre. Il a même fabriqué un prototype d'écouteur imprimé en 3D, avec la feuille d'or tapissant l'intérieur de la cavité et la lumière acheminée par fibre optique.

Bon par contre, c'est peut-être un peu moyen de coller un laser de 5 watts à son tympan, je dis ça je dis rien.

Des pistes concrètes

L'application la plus directe concerne les casques audio pour IRM. Les écouteurs classiques à fils et aimants fonctionnent mal dans l'environnement magnétique d'un scanner, et la qualité sonore est souvent catastrophique.

Un système photoacoustique réglerait ce problème en supprimant tout composant métallique. Des chercheurs du MIT ont aussi montré qu'on pouvait envoyer un message audio à une personne située à 2,5 mètres en utilisant un laser et la vapeur d'eau présente dans l'air, à un volume de 60 décibels.

On parle d'une technologie découverte il y a 145 ans et qui reste au stade de la bidouille. Mais produire du son sans aucune pièce mécanique, juste avec de la lumière, ça a quand même de la gueule.

Source : Hackaday

Il transforme sa Xbox Series X en vrai PC gaming avec une RTX 5060

Le YouTubeur PhasedTech a intégré un PC gaming complet dans le boîtier d'une Xbox Series X : un Intel Core i7-12700, 32 Go de RAM, une RTX 5060 et une alimentation 600W. Le tout démarre sous Windows, lance Steam en mode Big Picture, et le lecteur de disques fonctionne encore. Le résultat arrive pile avant le Project Helix de Microsoft, qui promet la même chose en version officielle.

Un PC complet dans un boîtier de console

Le mod repose sur un Intel NUC 12 Extreme Compute Element, une carte PCIe qui intègre un PC complet : processeur Core i7-12700 (12 coeurs), 32 Go de DDR4 en SODIMM et un SSD NVMe Crucial P3 Plus de 1 To en PCIe 4.0.

Pour la partie graphique, PhasedTech a opté pour une Gigabyte GeForce RTX 5060 en format compact, avec une alimentation Flex-ATX de 600W installée au-dessus du GPU. Des fixations sur mesure maintiennent le tout en place.

Le résultat est assez bluffant : de l'extérieur, rien ne distingue cette machine d'une Xbox Series X classique. Les boutons en façade fonctionnent, et le lecteur optique aussi, ce qui était loin d'être garanti vu l'espace disponible à l'intérieur.

Des performances de vrai PC

La machine tourne sous Windows et démarre directement en mode Steam Big Picture, ce qui donne une interface très proche d'une console. Côté performances, PhasedTech annonce entre 100 et 140 images par seconde sur Arc Raiders en 1080p avec des réglages moyens à élevés, et environ 250 images par seconde sur Counter-Strike 2 en réglages élevés.

On est donc sur du PC gaming tout à fait correct pour du 1080p, avec un accès à toute la bibliothèque Steam, Epic Games Store et tout le reste.

Les températures sont annoncées comme correctes malgré l'espace très restreint, même si PhasedTech n'a pas communiqué de chiffres précis sur la chauffe en charge.

Un mod qui arrive au bon moment

Ce projet tombe pile au moment où Microsoft prépare son "Xbox Mode" pour Windows 11, prévu en avril 2026. L'idée de Redmond, c'est de proposer une interface console sur PC, avec à terme le projet Helix qui promet de faire tourner les jeux PC sur la prochaine Xbox.

PhasedTech a pris les devants en montrant que ça marche déjà, avec du matériel qui tient dans un boîtier de Xbox.

Bien sûr, ce type de mod reste réservé aux bricoleurs qui savent manier un fer à souder et qui sont prêts à sacrifier une Xbox Series X.

Le coût total du matériel n'a pas été communiqué, mais entre le NUC 12, la RTX 5060 et l'alimentation, on imagine que la facture dépasse largement le prix d'une console neuve.

Le projet de PhasedTech est la meilleure démonstration qu'on ait vue de ce que Microsoft essaie de faire avec Project Helix : fusionner l'expérience console et PC dans un même boîtier. Sauf qu'ici, c'est un bricoleur qui y arrive avant le constructeur. C'est quand même assez amusant.

Par contre, on ne peut pas vraiment conclure que ce genre de mod va se démocratiser : c'est un projet sur mesure, avec des composants choisis pour leur format compact, et il faut des compétences solides pour arriver à ce résultat.

Source : Techspot

Un agent IA a mené 700 expériences en deux jours pour améliorer un modèle de langage

Andrej Karpathy, ancien chercheur chez OpenAI et ex-responsable de l'IA chez Tesla, a laissé tourner un agent IA pendant 48 heures sur un petit modèle de langage. Résultat : 700 expériences, 20 optimisations retenues et un gain de 11 % sur le temps d'entraînement.

Le principe d'autoresearch

Mais c'est quoi ce concept d'autoresearch ? Et bien le fonctionnement est assez direct : un agent IA reçoit un script d'entraînement de 630 lignes en Python et un budget de calcul fixe de 5 minutes par expérience sur un seul GPU. Et c'est là que l'agent se met en mouvement pour lire le code, formuler une hypothèse, modifier le script, lancer l'entraînement, évaluer le résultat, et surtout décider, ou non, de conserver une modification.

Si le modèle s'améliore, le changement devient la nouvelle base. Sinon, il revient en arrière et essaie autre chose. En deux jours de boucle continue, l'agent a conduit environ 700 itérations et identifié 20 améliorations cumulables qui ont réduit le temps nécessaire pour atteindre le niveau GPT-2 de 2,02 heures à 1,80 heure.

Tobias Lütke, le patron de Shopify, a d'ailleurs testé le système sur des données internes : après une nuit, 37 expériences et un gain de 19 % sur les performances de son modèle.

La question de l'auto-amélioration

Là où le projet fait pas mal parler, c'est l'idée que cette IA s'améliore elle-même en boucle, dans un scénario que certains chercheurs en sécurité aiment appeler "exploser d'intelligence" (c'est aussi comme ça que j'appelle chaque moment que je passe à regarder l'ami Korben me parler de ses projets en cours).

Karpathy tempère : son agent n'optimise pas son propre code, il ajuste l'entraînement d'un modèle bien plus petit et bien moins complexe.

Par contre, il assume que tous les grands labos d'IA vont adopter cette méthode et que ça va accélérer la recherche. Il imagine à terme des essaims d'agents qui collaborent en parallèle, testent des pistes différentes et remontent les meilleures idées à des échelles de plus en plus grandes. Son objectif : ne pas reproduire le travail d'un doctorant, mais celui d'une communauté entière de chercheurs.

Bon maintenant il faut quand même relever que certains critiquent quand même l'idée, car elle ressemble en partie à AutoML, une technique qui est déjà utilisée chez Microsoft et Google.

Karpathy a répondu que la comparaison ne tient pas : AutoML fonctionne avec des variations aléatoires ou des algorithmes évolutifs, alors qu'autoresearch utilise un vrai modèle de langage qui écrit du code, apprend de ses expériences précédentes et a accès à internet. Bref, tout ceci est fascinant.

Source : The News Hack

QMD - Un moteur de recherche local pour vos notes Markdown

Si vous êtes comme votre blogueur préféré (hi hi) et que vous avez des tonnes de fichiers markdown qui traînent dans des dossiers obscurs depuis des années, voici l'outil parfait pour rendre tout ceci à nouveau utilisable dans la vraie vie.

En tout cas, c'est plus pratique qu'un grep !

Ça s'appelle QMD (Quick Markdown Search) et c'est un outil en ligne de commande dispo sur GitHub qui va indexer tout votre bazar de notes pour les rendre consultables rapidement. QMD combine la recherche plein texte classique (BM25) avec de la recherche vectorielle sémantique et du re-ranking via LLM, ce qui veut dire que c'est ultra puissant. On est un peu sur le même principe qu'un RAG en fait puisque l'IA locale est utilisée pour comprendre le sens de votre requête et pas juste chercher des chaînes de caractères bêtes et méchantes. J'utilise depuis un petit moment maintenant un système similaire avec LEANN pour indexer tous les articles de korben.info et retrouver des connexions entre mes contenus, et je peux vous dire que quand on goûte à la recherche sémantique, le bon vieux grep a un goût de carton.

L'outil est même capable de faire de l'expansion de requête (Query Expansion) pour deviner ce que vous cherchez vraiment.

Techniquement, ça tourne avec bun ou npm et ça s'appuie sur node-llama-cpp pour faire tourner des modèles GGUF directement sur votre machine. Tout reste chez vous donc niveau vie privée c'est nickel. C'est un peu la même philosophie que des outils comme Khoj ou Blinko dont je vous ai déjà parlé, mais en version CLI pour le terminal.

L'installation est hyper facile si vous avez déjà Bun, mais prévoyez quand même un peu de place (environ 3 Go) pour les modèles qui iront s'installer au chaud dans ~/.cache/qmd/models/ et installez sqlite si vous êtes sur macOS :

brew install sqlite # Pour macOS
npm install -g @tobilu/qmd

Ensuite, y'a plus qu'à vous créer vos collections en pointant vers vos dossiers, et en lançant l'indexation comme ceci :

qmd collection add ~/mes-notes --name notes
qmd embed # L'étape indispensable pour générer les vecteurs

Et hop, vous pouvez lancer des recherches !!

C'est magique ! Perso, j'utilise presque tout le temps la commande "qmd query" plutôt que "search" parce que le mode hybride est bien plus puissant je trouve. Vous avez aussi "qmd vsearch" si vous voulez une recherche purement sémantique, genre quand vous cherchez un concept sans connaître les mots exacts utilisés dans vos notes. En fait, quand vous tapez une requête, QMD va chercher via les mots-clés, via les vecteurs (le sens), puis fusionner tout ça avec un algo RRF, et refaire passer un petit coup de LLM par dessus pour trier les résultats par pertinence.

Après vous l'aurez capté en me lisant, si vous avez une machine un peu ancienne sans GPU costaud, l'étape de re-ranking risque de prendre un peu de temps... mais c'est le prix de la qualité et de la sécurité ^^.

D'ailleurs, si vous utilisez Claude Desktop ou Claude Code, sachez que QMD intègre également un serveur MCP (Model Context Protocol). Du coup, vous pouvez connecter QMD à Claude et lui permettre d'aller fouiller dans vos notes pour répondre à vos questions. Et bonne nouvelle, QMD propose maintenant un mode HTTP daemon (qmd mcp --http --daemon) qui garde les modèles chargés en mémoire, ce qui évite de les recharger à chaque requête. Attention par contre, dans ce cas précis, les extraits de vos notes seront envoyés à Claude (donc dans le cloud).

QMD est aussi dispo en tant que librairie Node.js (npm install @tobilu/qmd) pour ceux qui voudraient l'intégrer dans leurs propres scripts ou workflows d'automatisation. Avec les options --json et --files en sortie, ça se branche facilement dans un pipeline.

Perso je trouve ça génial parce que ça comble le fossé entre le simple fichier texte et les usines à gaz de gestion de connaissances. Par exemple, si vous êtes un grand adepte de Silverbullet ou d' Obsidian , c'est le top pour l'indexation globale de vos écrits.

Voilà, si vous voulez un moteur de recherche personnel qui en a sous le capot et qui respecte votre vie privée, foncez tester ça.

Source

Un ingénieur a intégré la vérification d'âge dans Linux, et c'est la panique

Un développeur américain a soumis en une semaine des modifications à trois projets Linux majeurs pour y ajouter un champ de date de naissance, au nom de lois californiennes et brésiliennes qui entreront en vigueur en janvier 2027.

Le plus gros morceau, systemd, a accepté la modification et refuse de revenir en arrière. La communauté open source est depuis en ébullition.

Un développeur solitaire, trois projets visés

Dylan M. Taylor, ingénieur DevOps basé en Caroline du Nord, a soumis des pull requests à systemd, Ubuntu et Arch Linux en mars 2026. Son objectif : ajouter un champ "date de naissance" dans la base de données utilisateur de chaque système, pour se conformer à trois lois qui entrent en vigueur le 1er janvier 2027.

La loi californienne AB-1043, la loi du Colorado SB26-051 et la loi brésilienne Lei 15.211 imposent aux systèmes d'exploitation de collecter l'âge des utilisateurs dès la création du compte, puis de transmettre cette donnée aux magasins d'applications via une API.

Le plus surprenant, c'est que personne ne lui a demandé de faire ça. Taylor a lu les textes de loi, estimé que Linux devait s'y conformer, et s'est mis au travail tout seul.

Il a lui-même reconnu dans sa pull request pour Arch Linux que le système serait "totalement inefficace pour empêcher quiconque de mentir sur son âge". Il a qualifié sa propre fonctionnalité de "hilarante d'inutilité", mais a quand même insisté pour l'intégrer.

systemd a accepté, et le revert a été refusé

Côté systemd, la modification a été acceptée par Luca Boccassi, un mainteneur qui travaille chez Microsoft. La pull request a généré 945 commentaires. Quand un autre développeur a tenté de faire annuler la fusion, Lennart Poettering, le créateur de systemd (ancien Red Hat, passé par Microsoft), a personnellement rejeté la demande le 19 mars.

Son argument : le champ est optionnel, systemd ne force rien, et les distributions sont libres de l'utiliser ou non. Le champ date de naissance reste donc dans le code.

Côté Ubuntu, les deux pull requests sont restées à l'état de brouillon. Un vice-président de Canonical a précisé qu'il n'y avait "aucun plan concret" pour intégrer cette fonctionnalité.

Côté Arch Linux, le mainteneur a verrouillé la discussion en attendant un avis juridique. Et Artix Linux a pris la position la plus claire : jamais de vérification d'identité ni d'âge dans leur distribution.

Des lois qui posent un vrai problème technique

Ces lois partent du principe que c'est au système d'exploitation de jouer le rôle de contrôleur d'identité. Sauf que Linux n'est pas Windows ou macOS : c'est un projet communautaire, maintenu par des bénévoles et des entreprises aux intérêts variés.

Collecter des données personnelles dans un système open source pour les transmettre à des magasins d'applications, c'est un changement de philosophie assez radical.

Un développeur d'Ubuntu a proposé une approche différente : une interface D-Bus optionnelle, sans stocker de date de naissance brute. Plus respectueux de la vie privée, mais ça ne fait pas non plus l'unanimité.

On a donc là un ingénieur qui admet que sa propre fonctionnalité ne sert à rien, et qui l'intègre quand même dans un des composants les plus utilisés de Linux. Le tout validé par un mainteneur employé chez Microsoft. Difficile de ne pas remarquer le problème.

Que des lois imposent la vérification d'âge aux systèmes d'exploitation, c'est une chose. Mais que ça passe par un bénévole qui pousse du code dans un projet open source sans que personne ne s'en rende compte avant la fusion, c'est un peu particulier quand même.

Source : Sambent

SpinalVoodoo - La 3dfx Voodoo recréée de zéro en FPGA

Quand Nvidia a racheté 3dfx, la Voodoo est morte façon Marion Cotillard dans Batman, et tout le monde était "mui tristé"... Mais vous allez pouvoir sécher vos larmes de "crocrodiles" car un dev vient de la ressusciter... dans un FPGA (c'est une puce reprogrammable).

SpinalVoodoo, c'est 430 registres de configuration, un pipeline graphique complet et des jeux à l'ancienne qui tournent OKLM du genre Quake ou Screamer 2.

Hé oui, sur un FPGA !

Le projet de Francisco Ayala Le Brun, c'est en fait une réimplémentation complète du GPU Voodoo 1 en SpinalHDL (un langage pour décrire des circuits). Pas de l'émulation logicielle genre 86Box mais une reconstruction totale du pipeline hardware registre par registre dans une puce reprogrammable. Du coup chaque pixel sort comme sur la carte d'origine comme quand elle faisait tourner Quake en 640x480 sous Windows 95. Enfin presque...

Screamer 2 par SpinalVoodoo

Je dis "enfin presque" parce que la Voodoo original, c'est pas juste un chip qui balance des triangles. Il y a en fait quatre types de registres qui réagissent chacun différemment selon le timing. Du coup si vous changez un paramètre au mauvais moment pendant qu'un triangle traverse le pipeline, les derniers pixels du triangle A se retrouvent avec la config du triangle B. Bref, bonjour la corruption !

SpinalHDL permet donc d'encoder tout ça proprement. Chaque registre déclare son adresse, sa catégorie et son mode d'accès en une seule déclaration. Pour un projet fait en solo, c'est quand même du costaud.

D'ailleurs, le récit de débogage vaut le détour. L'auteur avait des pixels d'overlay translucides qui devenaient mystérieusement transparents. Il a d'abord soupçonné un problème de framebuffer, changé les priorités d'écriture, ajouté des chemins sans cache... et l'artefact bougeait à peine. Snif...

Et là, avec Conetrace (un outil qui trace le chemin des pixels à travers le design), il a fini par trouver le coupable : 3 micro-erreurs de précision qui, séparément, étaient quasi invisibles, mais qui ensemble foutaient le bordel sur certains pixels. Le "bug mémoire" n'en était finalement pas un. Va savoir combien de développeurs hardware se seraient arrachés les cheveux là-dessus !

Quake sur SpinalVoodoo, rendu FPGA fidèle à l'original

Côté compatibilité, la majorité du pipeline graphique est implémenté (textures, transparence, brouillard, depth buffer, dithering...) par contre, y'a pas encore de contrôleur d'affichage (pas de sortie VGA native pour le moment), pas de trilinéaire, et pas de multi-texture. Attention aussi, pas de licence spécifiée sur le repo pour le moment, ce qui est un peu dommage si vous comptez réutiliser le code.

Si vous avez suivi le mec qui a conçu sa carte mère 486 from scratch avec un FPGA Spartan II, ou la Game Bub et son FPGA pour le rétrogaming, SpinalVoodoo pousse le curseur encore plus loin. Reproduire un GPU dédié avec son pipeline fixe et ses subtilités de timing, c'est quand même pas le même délire qu'émuler un CPU.

Bref, qu'une seule personne puisse recréer un GPU complet avec les outils RTL modernes, moi je trouve ça assez foufou !

Source

❌