Connexion
Si vous ne connaissez pas Linux, il faut savoir que sur ce système d'exploitation, le clic milieu colle la sélection. Moi, c'est un truc que j'aime bien, mais c'est surtout un héritage de X11 qui se marche complètement dessus avec l'autoscroll . Du coup Firefox désactive le sien par défaut sur Linux, et Chromium ne l'active nativement que sous Windows. Mais c'était sans compter sur Grant Hendricks qui a décidé de faire autrement avec midscroll .
Midscroll ne s'accroche à aucun toolkit, et se branche sur l'entrée du noyau. Ensuite, il capte chaque souris en evdev , la re-émet dans un clone uinput , et glisse ses événements de molette au passage. Rien au-dessus n'a donc besoin de coopérer, donc Wayland et X11 s'en fichent, et vos applis Qt, GTK ou Electron ne voient qu'une molette ordinaire.
Les gens sous Windows qui utilisent l'autoscroll savent que la vitesse dépend de l'écart. Un centimètre sous le point d'appui et la page descend au ralenti, la moitié de l'écran ou plus bas et elle défile à toute berzingue. Et tant que la molette reste enfoncée, ça scroll sans s'arrêter. C'est super pratique quand on est face à des pages web ultra longues.
Alors pour Midscroll, la courbe d'accélération qu'a mise au point Grant, n'a pas été bricolée au feeling. En fait, c'est la même courbe que celle de Chromium, reprise telle quelle : 0,000008 × distance^2,2 en pixels par milliseconde, avec une zone morte de 15 px histoire de ne pas déclencher sur un clic simple...
Et comme le middle-drag, ça sert déjà dans un logiciel de CAO ou dans Minecraft, il y a une liste d'exclusion pour FreeCAD, OrcaSlicer et Minecraft dedans. Comme ça, tant que ces fenêtres sont au premier plan, midscroll se retire en silence.
Et si tenir le bouton vous gonfle parce que vous êtes trop faible, le mode toggle inverse la logique : le pointeur circule librement une fois le défilement lancé d'un clic, et le premier clic venu remet tout à l'arrêt. C'est le fonctionnement de l'explorateur Windows ET de Firefox, et c'est une fonctionnalité qui a été beaucoup réclamée, même si on perd la faculté de coller du texte qui a été surligné.
Bien sûr, toutes les valeurs sont paramétrables. On peut régler la vitesse à laquelle ça part, la cadence des événements et dans quel sens ça défile.
Côté installation, des paquets pour Arch, Debian/Ubuntu et Fedora sont dispo, plus un install.sh pour le reste. Le flatpak, lui, est hors jeu car son bac à sable ferme totalement l'accès à uinput.
Le projet est hyper jeune, donc traitez-le comme tel et n'hésitez pas à contribuer pour soutenir le dev. Dans le registre confort Windows sous Linux, j'avais parlé de Wubuntu qui va beaucoup plus loin dans le mimétisme, et côté Wayland je vous avais montré niri et son défilement infini de fenêtres.
À tester et si ça vous gonfle, un sudo systemctl stop midscroll et on n'en parle plus.
Bonne nouvelle pour tous ceux qui balancent du code sur PyPI. L'index officiel des paquets Python refuse désormais tout nouveau fichier ajouté à une release qui a plus de 14 jours. Le correctif vient de Seth Larson, développeur sécurité en résidence à la Python Software Foundation, et il colmate un trou que personne n'avait encore exploité sur PyPI... mais qui traînait là, grand ouvert.
Jusqu'ici, un mainteneur pouvait ajouter un fichier à n'importe quelle release, même sortie il y a 3 ans. Pratique pour livrer une nouvelle wheel, dangereux si un token de publication se fait voler. Un attaquant avec vos clés pouvait glisser un binaire vérolé dans une version stable que tout le monde télécharge depuis des lustres, sans déclencher la moindre alerte. Larson le dit sans détour : si ça n'a pas encore été abusé, c'est juste que les pirates n'avaient pas réalisé que c'était possible.
Le déclencheur, c'est l'affaire LiteLLM et Telnyx, deux paquets populaires compromis en mars dernier via une "référence mutable" dans leur usage de la GitHub Action Trivy. Encore une compromission de la chaîne d'appro, dans la lignée de Shai-Hulud sur npm dont je vous ai déjà parlé avec son scanner dédié , même si le mécanisme n'est pas le même. Le sujet mijotait depuis janvier 2024 dans les discussions autour de PEP 740, sauf qu'il coinçait sur un cas d'usage bien réel. En effet, certains projets ajoutent le support d'une nouvelle version de Python, genre les wheels cp314 pour Python 3.14, à d'anciennes releases longtemps après leur sortie.
Sauf que les chiffres ont tranché. En interrogeant la base PyPI sur les 15 000 paquets les plus populaires, seuls 56 avaient publié une wheel compatible 3.14 plus de 14 jours après une release. 56 sur 15 000, autant dire une poignée. Mike Fiedler, l'ingénieur sécurité de PyPI, a donc porté le débat au Packaging Summit de la PyCon US 2026, et le consensus est tombé. Il est maintenant demandé à ces projets de bumper vers une nouvelle version.
Après ne prenez pas cette nouvelle mesure de sécurité comme une garantie. Il n'existe aucune API pour vérifier qu'une release est "fermée", et les vraies règles du jeu ne seront gravées dans le marbre qu'avec l'API Upload 2.0 et les Staged Previews prévus par PEP 694. Donc pour l'instant, c'est un verrou qui protège, mais pas un vrai contrat de confiance sur lequel bâtir (De quoi Darty ??).
N'empêche que le bénéfice est immédiat car ça fait moins de ménage pour les admins PyPI quand un projet se fait trouer, et s'en est fini de l'état schizophrène où une release est à moitié compromise, à moitié saine, avec quelques fichiers vérolés planqués au milieu. Une vieille release devient un bloc figé, et voilà !
GitHub avait déjà dégainé la même idée avec ses releases immuables , qui rendent vos versions intouchables même par le mainteneur du projet.
Bref, une porte de moins pour les attaquants supply chain. Sympa non ?
Source (repéré chez Simon Willison)
Balaji Bikshandi avait un rêve ! Il voulait booter sa machine directement sur un LLM sans avoir à passer par le moindre environnement de bureau ! Et il y est parvenu avec son outil BMASS , qui s'installe sur une clé USB de 8 Go, et qui embarque Alpine Linux, llama.cpp et un modèle Qwen3 0.6B évidemment quantisé.
Vous allumez l'ordi portable, Alpine démarre depuis la clé et vous tombez sur un prompt BMASS>. Et voilà à partir de là, vous pouvez causer à votre ordinateur en langage naturel. Ensuite, quand vous demandez à BMASS de faire des trucs, celui-ci injecte la commande qui va bien dans une balise
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) 
Operator: Which operating system is this?
Assistant: <shell>cat /etc/os-release</shell>
Tout le code de BMASS tient en 399 lignes de Python, et nécessite de faire tourner un llama-server en background sur le port 8080 avec 2048 tokens de contexte et 2 threads. Et ensuite lui fait le pont entre le modèle et le shell. Y'a rien de sorcier donc mais comme ça tourne sur du CPU, que c'est hors-ligne, et que ça peut se mettre sur des vieilles machines, c'est plutôt cool...
Voilà je vous laisse avec la vidéo que Balaji a filmée, ça montre le démarrage complet de son IA bootable :
Ah et petite subtilité qui va vous plaire, le code de BMASS contient une regex baptisée FALSE_EXECUTION_CLAIM dont le boulot est de détecter quand le modèle prétend avoir exécuté une commande alors qu'il n'a rien lancé du tout. Le runtime lui renvoie alors une correction pour lui dire qu'aucune commande n'a été exécutée lors de ce tour. Faut dire que la 0.6B de Qwen hallucine tellement parfois, qu'il lui fallait obligatoirement un garde-fou.
Donc, voilà, côté sécu c'est super léger... y'a juste une regex qui bloque les sudo, doas, pkexec et autres su, mais c'est tout. Pas de conteneur, encore moins de namespace et surtout pas de liste blanche, donc si vous vous lancez, ce sera à déployer uniquement pour rigoler sur une vieille machine sans importance, parce que si demain, le modèle décide de lancer un rm -rf, faudra pas venir chialer ^^.
Petit service au passage si vous voulez tester, la doc d'installation vous fait copier le prompt système dans /opt/bmass/config/system-prompt.txt, sauf que le launcher le cherche dans /opt/bmass/system-prompt.txt.
Dans le genre modèle local qui tient dans presque rien, j'en ai parlé avec Llamafile qui fait tourner un LLM depuis un fichier unique. Et si les bidouilles minimalistes vous amusent, il y a aussi ce mini-PC Linux piloté entièrement en morse .
Perso, je doute que ça serve à grand-chose. Mais le concept est marrant !
Vous avez peut-être remarqué un petit point rouge tout en bas de mon site, avec un nombre à côté. Il s'agit du nombre de personnes passées sur le site durant la dernière heure.
Je voulais remettre ce truc depuis un bail, bien à l'ancienne comme dans les années 2000 mais sur un site statique, qui plus est sans tracker de stats JS type Google Analytics ou Matomo, et sans cookies de tracking, c'était pas franchement une option... jusqu'à maintenant !
Le compteur, en vrai, tout en bas de korben.info.
La solution évidente sur des sites statiques, c'est souvent un petit Worker Cloudflare qui compte les visiteurs et servirait le chiffre, mais ça se facture à chaque requête. À 390 000 pages vues par jour, ça grimpe vite à des dizaines de millions d'invocations par mois, soit dans les 6 à 7 dollars. C'est pas super cher mais pour un compteur qui n'est utile qu'à satisfaire mon égo tout en sachant s'il y a du monde aujourd'hui, ça ne sert strictement à rien ! Donc le Worker, je l'ai écarté direct.
Du coup j'ai fait ça à l'ancienne. Un petit script Python tourne sur la machine qui héberge le site, une fois par minute. Il pose une seule question à Cloudflare, à savoir combien d'adresses IP distinctes ont chargé une page durant la dernière heure (ou demi-heure, ou quart d'heure ou 5 min, c'est vous qui paramétrez), il écrit la réponse dans un minuscule fichier live.json de quelques centaines d'octets, et c'est tout. Ce fichier, Cloudflare le sert ensuite depuis son cache comme il servirait une image, gratuitement. Zéro Worker, zéro base de données, zéro abonnement, j'ai exactement le même résultat sans dépenser une thune.
Maintenant, faut que je sois clair sur ce que ce chiffre raconte. C'est le nombre de navigateurs distincts ayant chargé une page durant la dernière heure, hors trafic interne de Cloudflare. C'est un "*combien de monde est passé récemment *", pas un "combien lisent là tout de suite".
Et les bots là-dedans ?
En fait, les bots pourris , ceux qui scrapent en boucle, se font bloquer en amont par le Super Bot Fight Mode de Cloudflare, donc ils n'arrivent même pas jusqu'à mon site. Restent les gentils bots, du genre de Googlebot et compagnie, que je laisse passer exprès, parce que les bloquer reviendrait à me flinguer mon référencement. Sur les 7 derniers jours, Cloudflare classe à peine 4% comme bots vérifiés. Donc c'est une goutte d'eau, surtout qu'ils tournent sur une poignée d'IP. Donc oui, mon compteur avale deux ou trois crawlers au passage, mais je ne voulais pas vous mentir en écrivant "zéro bot". Mais l'essentiel c'est que les nuisibles, eux, ne soient pas comptabilisés.
J'ai aussi dû gérer un petit piège car l'API de Cloudflare plafonne sa réponse à 10 000 lignes. Et comme sur une heure entière de trafic ça peut se remplir vite, si je crève ce plafond, la requête sous-compterait sans rien dire. Donc le script lève un flag et le compteur affiche "10 000 personnes ou plus" plutôt qu'un faux nombre. Quand j'y serai aux 10 000 et plus, je pense que je réduirai alors le delta temps en passant de 1h à 30 min...etc.
Côté vie privée, c'est carré également. Cloudflare renvoie à mon serveur une liste JSON des IP passées dans l'heure, mon script en compte le nombre de distinctes, et efface cette liste de sa mémoire dans la milliseconde qui suit. Aucune IP n'est stockée, aucune n'atterrit dans un log, aucun fichier avec les IPs n'est créé sur le disque... Il ne reste qu'un entier. Comme je vous le disais, pas de cookie , pas de traceur, et rien qui touche votre navigateur . Et comme le compteur ne s'affiche jamais en dessous de 10 personnes, impossible d'isoler qui que ce soit.
Maintenant, si vous voulez le même chez vous, sachez que j'ai tout balancé en open source sur GitHub , sous licence MIT, donc servez-vous. Voici les pré-requis :
live_count.py sur votre serveur et vous le lancez une fois par minute (ou toutes les 5 ou 10 min) via un cron.span dans vos pages, tout se règle par des attributs, aucun script inline, donc ça passe même avec une politique de sécurité stricte.Le seul truc sur lequel ne pas vous louper, c'est de mettre un temps de cache court à live.json. Si c'est trop long, tous vos visiteurs verraient un chiffre périmé.
Voilà. Un petit compteur maison simili-live sans tracking et qui ne me coûte rien, c'est le bonheur !
Hubert, fidèle lecteur de Korben.info m'a envoyé un mail pour me dire qu'il avait reçu sa nouvelle carte d'identité. Vous savez celle en petit format avec la puce dedans qu'on peut scanner avec l'app France Identité. Et il en est bien content !
Voilà, l'histoire s'arrête là !
Mais non, je plaisante ! En fait, Hubert s'est posé LA question que personne ne se pose à l'heure de l' identité numérique européenne : Y'a quoi là dedans ?
Et plutôt que d'attendre qu'un employé de mairie expert en technologie ne lui explique (j'rigole, ça n'existe pas), il a passé son week-end à coder cnie-python-tools , un projet codé en python (vous aviez deviné je pense) capable de lire la puce de la CNI et de vous ressortir les infos y compris la photo d'identité.
Le tout sous Linux, évidemment, sans smartphone ni app officielle.
Pour l'utiliser, vous devez brancher un lecteur de carte à contact (un
ACR38U
, un
Omnikey
(liens affiliés), ce genre de bestiole compatible PC/SC), vous lancez uv run cnie-dump, et vous tapez le CAN, c'est-à-dire les 6 chiffres imprimés au recto de votre carte.
Photo envoyée par Hubert, je me suis permis d'enlever ses données personnelles #RGPD-way-of-life ^^
Y'a besoin de cette clé car c'est elle qui permet de déverrouiller la puce via un protocole qui s'appelle PACE. C'est ce mécanisme précis qu'utilise la carte France Identité quand elle lit votre carte en NFC sauf que là c'est direct sur votre PC. Son script permet alors de récupérer toutes les data dans des fichiers bruts + un summary.json qui liste tout ce que la carte a bien voulu cracher.
Et c'est qu'elle est bavarde cette coquine, puisqu'avec ce simple script, elle vous sort votre état civil complet (nom, prénoms, date et lieu de naissance, nationalité), votre adresse, votre taille, la MRZ (la fameuse bande de caractères qu'on retrouve aussi sur les passeports), mais aussi la photo qui est dessus au format JPEG 2000, un format parfois un peu pénible à ouvrir.
Bref, de quoi remplir un formulaire administratif sans avoir à tout retaper.
Maintenant rassurez-vous, il y a quand même des données qu'on ne peut pas extraire. Sur la CNIe française, la donnée biométrique sensible, ce sont vos deux empreintes digitales (DG3), et celles-là restent bouclées à double tour derrière l'EAC, une couche de sécurité réservée aux terminaux officiels de l'État. Quand le script tape à cette porte, la carte répond aussi sèchement qu'un agent assermenté sans clim, avec le code 6982, ce qui veut dire "security status not satisfied", cause toujours.
Si ça vous dit d'essayer bien sûr, c'est à utiliser uniquement avec votre propre carte. Et si le lecteur sur la photo ci-dessus vous parle, c'est normal. Plutôt que d'acheter un lecteur de carte tout neuf, Hubert a simplement réalisé ses tests avec le lecteur fourni par les TCL (le réseau de transport Lyonnais) qui visiblement est dans le tur-fu en ce qui concerne la recharge des abonnements de métro ^^.
Merci Hubert pour le partage !!
Le conseil de pilotage de Python, l'instance qui tranche les grandes décisions du langage, a demandé le 5 juin la suspension de tout nouveau développement sur son compilateur JIT.
Un JIT (just-in-time), c'est un compilateur à la volée : au lieu d'interpréter votre code ligne par ligne, il traduit les portions les plus sollicitées en instructions machine pendant l'exécution, histoire de gagner en vitesse. Python en a un, expérimental, depuis la version 3.13 sortie début 2024.
Le problème n'est pas le code. Il est dans la procédure.
Ce JIT est arrivé dans la branche principale de CPython, l'implémentation de référence du langage, sans passer par le circuit de décision habituel. Chez Python, toute évolution majeure doit faire l'objet d'un PEP, un document formel que la communauté discute puis valide. Celui qui couvre le JIT, le PEP 744 signé Brandt Bucher et Savannah Ostrowski, n'est qu'informatif et laisse plusieurs questions en suspens : la maintenance future, la compatibilité avec l'outillage existant, les critères de réussite mesurables.
Le conseil l'a reconnu noir sur blanc : il n'a pas été "aussi strict sur le respect du processus qu'un changement de cette ampleur le méritait". Responsabilité partagée, donc.
En pratique, plus aucune nouvelle fonctionnalité JIT ne peut atterrir sur la branche principale tant qu'un PEP en bonne et due forme n'est pas accepté. Les corrections de bugs et de sécurité, elles, continuent. Le conseil laisse une fenêtre de six mois pour soumettre et faire valider ce document. Passé ce délai, faute d'accord, le code du JIT sera purement et simplement retiré.
Le timing est mauvais. Le JIT amélioré était l'une des nouveautés mises en avant de Python 3.15, dont les fonctionnalités sont déjà gelées et dont la sortie est attendue en octobre. Sur du x86-64 sous Linux, il promet un gain de 8 à 9% en moyenne, même s'il reste désactivé par défaut et consomme 10 à 20% de mémoire en plus.
Mark Shannon, un des principaux contributeurs, n'a pas caché son agacement. Pour lui, tout arrêter d'un coup fait perdre l'élan et risque de faire fuir les nouveaux venus, alors il réclame une période de grâce pour avancer pendant que le PEP se construit. Barry Warsaw, lui, a demandé pourquoi le travail ne pourrait pas se poursuivre dans un dépôt séparé le temps des discussions.
La réponse du conseil tient en une idée : mettre le développement en pause évite que le JIT devienne une cible mouvante pendant qu'on débat de son sort.
Du coup, on se retrouve avec une techno qui fonctionne, déjà embarquée dans le langage, suspendue à un document qui n'existe pas encore.
Geler une techno qui marche pour une procédure oubliée, c'est agaçant sur le moment. Mais sur un langage utilisé par des millions de gens, c'est probablement plus prudent.
Source : The Register
Les chercheurs de X41 D-Sec viennent de divulguer une faille critique baptisée BadHost (CVE-2026-48710) dans Starlette, le framework Python qui sert de fondation à FastAPI, vLLM , LiteLLM et une grande partie des serveurs MCP basés sur FastAPI.
325 millions de téléchargements par semaine, et il suffit d'injecter un seul caractère dans le header HTTP "Host" pour contourner les contrôles d'accès path-based qui lisent "request.url.path" dont autant dire que beaucoup de déploiements d'agents IA en production tournent en ce moment avec une porte d'entrée très mal verrouillée.
Le proof of concept publié par OSTIF donne ceci :
curl -i -H 'Host: foo' http://target/admin # 403, bloqué
curl -i -H 'Host: foo?' http://target/admin # 200, ça passe !!
Et c'est tout ! Un simple point d'interrogation collé au Host header, et l'endpoint "/admin" qui jusqu'alors filtrait les non-authentifiés s'ouvre alors aussi facilement que le claque-merde de mes haters ^^.
Donc si votre infra utilise FastAPI, vLLM ou LiteLLM exposés directement en ASGI (uvicorn, hypercorn, granian) sans reverse proxy strict devant, vous pouvez tester votre exposition immédiatement grâce au scanner de BadHost développé par Nemesis et X41 D-Sec.
Niveau mécanique, Starlette reconstruit l'objet "request.url" en concaténant la valeur du header "Host" avec le path de la requête, puis re-parse le tout. Sauf que la valeur de "Host" n'est jamais validée donc si vous y injectez un "/", un "?" ou un "#", vous décalez la frontière entre path, query et fragment au moment du re-parse.
Du coup, le routeur Starlette dispatche sur le vrai path de la requête HTTP (donc votre endpoint sensible s'exécute bien), mais les middlewares qui lisent "request.url.path" voient simplement un path empoisonné qui ne correspond plus à rien d'interdit.
Donc le contrôle d'accès saute et le code derrière tourne quand même. On est sur un score CVSS de 7/10 et la boite de sécu Secwest estime même que cette note est largement sous-estimée... En gros c'est super grave !
Car la portée réelle ce sont surtout les serveurs MCP qui peuvent stocker ou manipuler des tokens et identifiants pour accéder aux ressources externes auxquelles les agents IA se connectent : bases de données, comptes mail, calendriers, S3, webhooks...etc
Bref, le genre de "coffre-fort" que vous ne voulez pas voir ouvert via un header HTTP à la con malformé. Markus Vervier de X41 D-Sec a même publié un petit échantillon de ce que leurs scanners ont déjà trouvé en production : Des bases de données d'essais cliniques chez des biopharmas, des données de vérification d'identité avec PII en temps réel, des accès SSH à des équipements industriels via bastion, des boites mails complètes en lecture/écriture, des listes de souscripteurs CMS, des topologies AWS complètes avec metric queries.
Bref, l'écosystème agents IA vient de passer en mode naturiste !
Pour régler ce problème, vous devez donc mettre à jour vers Starlette 1.0.1 ou supérieur, dans tous vos déploiements LLM qui l'intègrent... Et là c'est le bordel parce qu'il y en a partout : Dans les images Docker, les virtualenvs et les artefacts "vendorisés" un peu partout... Donc faut tout rebuilder.
Et si vous avez du code custom, l'OSTIF recommande aussi de remplacer request.url.path par request.scope["path"] partout où une décision de sécurité est prise.
En gros, lire la valeur non reconstruite est le "fix" qui survivra aux prochaines versions du bug, parce que croyez-moi, ça reviendra à coup sûr !
Maintenant, côté infra, X41 D-Sec et OSTIF indiquent que nginx, Apache httpd et Cloudflare rejettent le PoC par défaut, mais ça ne doit pas vous empêcher de vérifier votre config. Donc ne traitez votre reverse proxy comme une mitigation qu'après l'avoir testé explicitement avec le scanner Nemesis.
Au-delà du correctif technique, BadHost rappelle une mécanique qu'on a déjà vue avec la faille RCE de llama-cpp-python à savoir que la chaîne d'approvisionnement de l'IA ne tient que sur quelques mainteneurs bénévoles qui prennent des risques personnels énormes pour patcher proprement.
Kludex, le mainteneur de Starlette, est actuellement sous une avalanche de reports depuis des mois. L'audit qui a permis de trouver le bug a par ailleurs été financé par OSTIF et AWS et sans ça, BadHost serait encore probablement dans la nature pour un an voire plus avant d'être découvert plus naturellement.
Donc si votre boîte fait tourner du LLM en prod via FastAPI, vLLM ou LiteLLM, vous avez aujourd'hui 2 choses urgentes à faire : 1/ passer votre infra dans le scanner Nemesis, et 2/ envoyer un petit don à Kludex pour le soutenir !
Sources : Ars Technica , OSTIF
J'sais pas si vous avez vu le film ou lu le livre mais Rocky, c'est l'araignée de roche extraterrestre de Projet Dernière Chance (Project Hail Mary) qui communique en chantant. Et Lahiru Maramba, un dev Firebase en poste chez Google, vient de le recréer en vrai avec un Raspberry Pi Zero 2W et un LLM local. Et voilà comme avoir un vrai pote Eridien posé sur votre bureau, qui vous répond en accords polyphoniques au lieu de parler.
L'architecture c'est ce que son concepteur appelle du "Voice Box & Brain". Le Pi Zero 2W tout seul est bien trop faiblard pour faire tourner un modèle de langage, du coup le Pi gère juste le hardware (micro, écran LCD, LED RGB, synthèse des accords) et balance l'audio brut à un Mac qui fait le gros du calcul. Le Mac transcrit ce que vous racontez avec mlx-whisper (un modèle Whisper-Tiny optimisé Apple Silicon), passe le texte à LM Studio qui fait tourner un Gemma 4 quantifié en local, et renvoie la réponse au Pi qui la joue en musique. Latence totale annoncée sur le repo, environ 2 secondes, soit, selon son propre benchmark, le même temps que via l'API Gemini dans le cloud, sauf que là, tout en local !
Le langage Eridien, lui, est fidèle au bouquin d'Andy Weir puisque chaque réponse est synthétisée en accords. Certains mots sont mappés sur des accords émotionnels précis, par exemple "amaze" sort en Mi majeur bien lumineux. Et pour les mots inconnus, ils sont hashés mathématiquement vers une signature de 3 fréquences, déterministe et permanente. Autrement dit, le même mot bizarre produira toujours exactement le même accord, comme un vrai vocabulaire qui se construit. C'est ce genre de petit détail qui fait la diff...
Côté matériel, il faut un Raspberry Pi Zero 2W et un PiSugar Whisplay HAT, un module tout-en-un qui apporte l'écran LCD, le bouton, la LED RGB et l'audio. De son côté, le repo propose 2 chemins d'install : la méthode "It Just Works" avec les drivers système précompilés (apt-get et c'est parti), ou la méthode isolée avec uv pour ceux qui veulent un environnement propre. Côté Mac, vous lancez LM Studio avec le modèle 4-bit quantifié sur le port 1234 et Y'a même un mode cloud avec une clé API Gemini si vous n'avez pas de Mac sous la main, ainsi qu'une fonctionnalité expérimentale planquée avec un générateur de sons façon R2-D2.
Pour la petite histoire, le film Projet Dernière Chance réalisé par Phil Lord et Christopher Miller est sorti en mars, avec Ryan Gosling en Ryland Grace et pour donner une voix à Rocky, les sound designers d'Hollywood ont tout simplement bossé avec un ocarina pour les aigus, une jarre pour les graves, et des chants de baleine, après avoir consulté Andy Weir sur l'anatomie du bestiau.
Je l'ai vu, et franchement, j'ai bien aimé. Je suis bien rentré dedans, même si j'aurais préféré que ce soit un peu plus "hard science" et un peu plus bidouille DIY comme l'était "Seul Sur Mars"... mais bon, il en faut pour tous les goûts.
Après si l'idée d'un compagnon IA DIY vous branche mais que vous voulez un truc plus généraliste et pas un Eridien qui chante, jetez un œil à Adeus , l'assistant IA personnel open source que j'avais couvert.
Quoiqu'il en soit, voici la vidéo complète où Lahiru montre tout le process, du câblage à Rocky qui prend vie :
Bref, c'est gratuit, c'est sous licence MIT, et le repo est juste ici .
Amusez-vous bien à construire votre petit pote Eridien !
Entre le 6 et le 7 mai 2026, le site officiel jdownloader.org a été compromis et a servi pendant un peu plus d'une journée des installeurs piégés à la place des versions légitimes du célèbre gestionnaire de téléchargements.
Concrètement, les liens alternatifs pour Windows et l'installateur shell pour Linux ont été remplacés par un loader qui déploie un RAT (Remote Access Trojan) écrit en Python sur la machine de la victime. Pour ceux qui ne connaissent pas, un RAT donne à l'attaquant un contrôle total à distance de votre PC : exécution de commandes, vol de données, installation d'autres malwares, et tout ce qui peut se faire avec un compte utilisateur compromis.
Bonne nouvelle dans le malheur. Tous les canaux de distribution n'ont pas été touchés. La version macOS est passée à travers, pareil pour les installations via Flatpak, Winget et Snap, ainsi que pour le package JAR principal de JDownloader. Seuls les liens "alternative download" Windows et le script shell Linux du site officiel sont contaminés. Si vous utilisez ces canaux pour vous mettre à jour, c'est sur eux qu'il faut vérifier.
Le problème a d'abord été relevé par un utilisateur Reddit, "PrinceOfNightSky", qui a constaté que les exécutables téléchargés étaient signalés par Microsoft Defender et signés par des éditeurs douteux (Zipline LLC, The Water Team) au lieu de la signature légitime AppWork GmbH.
Une fois alerté, le développeur de JDownloader a confirmé la fuite, mis le site hors ligne, et publié un rapport d'incident détaillé pour permettre l'analyse externe. La porte d'entrée des attaquants ? Une vulnérabilité du CMS du site qui permettait de modifier les listes de contrôle d'accès et le contenu sans authentification. Pas génial.
Le malware Windows fonctionne en deux étages. Un petit programme téléchargé sert de loader, qui récupère et exécute ensuite le vrai payload en se connectant à deux serveurs de commande nommés parkspringshotel[.]com et auraguest[.]lk. Architecture modulaire, ce qui veut dire que l'attaquant peut envoyer le code Python qu'il veut depuis ses serveurs et adapter sa charge en temps réel. Vol de mots de passe, persistance, mouvement latéral sur le réseau local, tout y est possible.
Si vous avez téléchargé JDownloader depuis le site officiel entre le 6 et le 7 mai, faites donc très attention. Réinstallez complètement l'OS et changez tous vos mots de passe. Un RAT donne suffisamment d'accès pour qu'un nettoyage par antivirus seul ne soit pas une garantie suffisante. Pénible mais c'est le seul moyen propre.
Source : Bleeping Computer
Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'eteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.
La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.
Concrètement ça donne ça :
from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé
Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !
La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...
Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.
Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !
Sur le terrain anti-bot, ça se compare bien à
Botasaurus
dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.
Détail sympa pour les bidouilleurs : y'a également un serveur MCP est intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.
Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.
Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.
Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .
Et merci à Letsar pour le lien !
Vous synchronisez 4 ou 5 dossiers vers plusieurs serveurs avec rsync ? Alors vous connaissez ce sketch quand un job mouline pendant que les autres font la queue, parce que rsync de base c'est mono-thread et ça avance en file indienne.
Hé bien y'a un petit utilitaire Python qui dégoupille tout ça, pondu par overflowy. Ça s'appelle parallel-rsync et le nom annonce la couleur !
L'idée c'est de pouvoir empiler plusieurs jobs rsync en parallèle, avec une config YAML pour piloter le tout. Vous décrivez vos sources et destinations dans sync.yml, vous lancez parallel-rsync -c sync.yml --workers 4 --max-per-host 2, et hop, ça parallélise.
Le bougre tourne sur un ThreadPoolExecutor Python 3 qui spawn N processus rsync système avec un cap global et un cap par hôte. Et pendant ce temps, des barres de progression vous affichent l'avancement de chaque transfert sans que la console parte en sucette.
La dernière fois, je vous parlais de rsyncy qui collait juste une barre de progression à un rsync solo mais là, on monte clairement d'un cran avec une orchestration multi-cibles.
--workers cap c'est donc le nombre total de processus rsync simultanés (4 par défaut). --max-per-host limite la concurrence par destination (2 par défaut, histoire de ne pas saturer un seul serveur, parce que oui, balancer 8 rsync sur la même machine c'est juste se tirer une balle dans le pied côté I/O).
--timeout met une laisse à chaque rsync, --dry-run ajoute le flag à toutes les commandes pour tester avant de tirer, et --no-progress débraye les barres si vous voulez juste les logs. Côté logging, --log-file et --log-level font également le job.
Par contre y'a pas de retry automatique donc si une session SSH coupe en plein transfert, faudra relancer à la main. C'est logique mais un peu dommage.
Sur un homelab, ce genre de config YAML permet de résoudre le problème des synchros récurrentes avec un seul fichier centralisé au lieu de 8 scripts shell.
Notez aussi que le repo build un binaire universel via cosmofy , qui empaquette le tout en un exécutable cross-platform Windows, macOS et Linux d'un coup. Du coup, pas besoin d'installer Python sur la machine cible. Carrément pratique pour distribuer sur des serveurs où vous n'avez pas envie de gérer un environnement Python complet avec pip et un venv.
Petit point d'attention quand même : rsync lui-même doit être installé sur la machine qui lance le binaire, ce qui est natif sous macOS et Linux mais nécessite WSL ou Cygwin sous Windows.
Y'avait déjà
msrsync
qui découpe les transferts en buckets,
parsyncfp
qui s'appuie sur fpart pour grouper par taille, et la classique combine find . -type f | parallel -j10 rsync que tout sysadmin a bricolée un jour pour gratter de la bande passante. De son côté, overflowy se place plutôt sur le créneau "config déclarative" pour orchestrer plusieurs rsync entre sources et cibles.
Le code est sous licence MIT et tout se passe sur le repo GitHub . À tester si vous orchestrez régulièrement plusieurs rsync à la main.
Vous voulez comprendre ce qui se passe dans le cerveau de votre bagnole ? Hé bien pour cela avant, il fallait du matos pro et des suites logicielles à licence annuelle. Mais maintenant, y'a CANviz .
Un pip install canviz, un module USB à quelques balles branché sur le bus CAN de la voiture, et hop, vous accédez à tous les secrets de votre voiture simplement en ouvrant votre navigateur sur localhost:8080. Toutes les trames qui circulent sur le réseau interne du véhicule s'affichent en direct dans un tableau qui défile sans ramer à 2000 fps si j'en crois le README, donc ça envoie !
Ce projet signé Chanchal Dhiman tourne sur n'importe quelle config équipée de Python 3.10 ou supérieur, et côté matériel, CANviz se branche sur plein de bazars tels que les modules à firmware Candlelight (genre FYSETC UCAN autour de 8 balles ou CANable 1.0 autour de 15), les périphériques slcan via port COM, et du matériel sérieux type PEAK PCAN-USB, Kvaser, Vector ou même socketcan sur Raspberry Pi. En gros, si votre clé USB CAN est compatible avec python-can, CANviz la gère !
L'interface décode alors les fichiers DBC (le format de base de données du CAN), donc au lieu de lire des paquets hexadécimaux chelous, vous voyez directement "vitesse moteur = 1450 rpm" ou "position accélérateur = 34%". Vous pouvez aussi filtrer par ID ou par nom de signal, et le filtre se garde dans l'URL. Comme ça, vous pouvez partager une vue à un pote en copiant simplement le lien.
Le truc vraiment pratique, c'est surtout la partie enregistrement. Vous capturez une session en .asc ou .csv, et vous la rejouez plus tard à vitesse variable (de 0.5x pour décortiquer lentement, jusqu'à 10x pour survoler), ou vous forgez vos propres trames depuis l'interface pour tester la réaction d'un module donné. Une API REST et du WebSocket ouvrent aussi la porte aux bricolages en Python, avec une doc interactive accessible sur /docs.
Autre truc malin, vu que c'est un serveur web derrière : vous pouvez déployer CANviz sur un Raspberry Pi planqué dans la bagnole et le consulter à distance en SSH. Par contre, pas de WebUSB ici. L'auteur a explicitement fait le choix de passer par python-can côté serveur pour des raisons de sécurité. L'accès USB reste donc dans le sandbox Python, et le browser ne touche rien. J'avoue, je préfère.
Le projet est sous licence MIT, et est encore jeune, mais l'approche est éprouvée. Pour ceux qui cherchent des alternatives desktop, y'a bien sûr CANgaroo côté Qt, ou SavvyCAN qui tourne aussi en natif. Et si vous voulez bidouiller votre voiture comme Charlie Miller l'a fait avec la Jeep , y'a toujours le Panda de Comma sorti en 2017 avec son soft Cabana.
Bref, pour quelques euros de module USB et un pip install des familles, vous pouvez transformer votre laptop en analyseur CAN niveau pro et ça c'est plutôt classe !
