Vue lecture

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

Hazmat - Vos agents IA en cage sous macOS

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

puis

cd /tmp
hazmat init --bootstrap-agent claude

Et hop, 10 minutes plus tard votre agent tourne dans sa cage. (le premier snapshot est ultra loooong mais après c'est de l'incrémental donc ça ira plus vite)

L'isolation repose sur 3 couches indépendantes, un peu comme les sas d'un sous-marin. Il y a d'abord un utilisateur agent dédié (vos fichiers perso deviennent alors hors de portée, point). Ensuite, une politique seatbelt générée dynamiquement à chaque session qui consiste à ce que le kernel de macOS vérifie chaque accès fichier et refuse tout ce qui n'est pas explicitement autorisé pour cette session précise.

Et par-dessus, des règles pf firewall qui empêchent l'agent d'envoyer du trafic SMTP, IRC, FTP, Tor ou VPN. Comme ça, un agent qui tentera d'exfiltrer vos données par mail se retrouvera bloqué net au niveau du noyau.

Côté supply chain, Hazmat force npm ignore-scripts=true par défaut. Comme ça, par exemple le fameux hack axios qui livrait un RAT via un hook postinstall en 2 secondes chrono n'est plus possible ici ! Y'a aussi une blocklist DNS qui redirige les services de tunnel connus (ngrok, pastebin, webhook.site) vers localhost. Contre un domaine perso fraîchement enregistré, ça passera mais les vecteurs d'exfiltration classiques, ça devrait résister.

Hazmat utilise TLA+, le même formalisme que les ingés d'Amazon utilisent pour vérifier les protocoles de DynamoDB. Genre, l'installation des règles sudoers AVANT le firewall (évidemment, ça crée une fenêtre de vulnérabilité), les restrictions qui bloquaient les lectures mais pas les écritures, ou encore une restauration cloud sans vérifier qu'un snapshot existait...etc, c'est le genre de truc qu'aucun test unitaire n'aurait chopé.

Ça supporte Claude Code (y compris le fameux --dangerously-skip-permissions), OpenCode et Codex. Attention par contre, si votre projet utilise Docker, y'a deux cas de figure : soit le daemon Docker est privé au projet et Hazmat le route automatiquement vers un mode Docker Sandbox, soit c'est un daemon partagé et là faudra passer --docker=none explicitement.

La commande hazmat explain montre aussi exactement ce que le sandbox autorise avant de lancer quoi que ce soit... et ça, c'est pas du luxe quand on sait pas trop ce qu'on va lâcher dans la nature. Le hazmat diff qui affiche les changements faits par l'agent depuis le dernier snapshot Kopia, c'est plutôt bien pensé. Et si l'agent casse un truc ? hazmat restore et c'est reparti, comme un Ctrl+Z géant pour tout votre projet.

Si vous avez déjà configuré votre Mac avec teaBASE pour sécuriser votre env de dev, c'est un complément logique.

Côté limites, faut être honnête, Seatbelt n'est pas documenté par Apple depuis macOS 10.5 et c'est du defense-in-depth, et pas une vraie frontière de VM. Quand à l'exfiltration HTTPS elle n'est pas bloquée car l'agent peut toujours curl n'importe quoi sur le port 443. C'est logique mais bon, c'est pas étanche à 100% quoi...

Et surtout c'est macOS only pour l'instant (le port Linux est en chantier), et bien sûr le /tmp partagé entre les comptes locaux reste un vecteur potentiel. J'aurais aimé aussi que le réseau soit coupé par défaut sauf whitelist, mais bon, faudra attendre. Après entre ça et laisser Claude Code en roue libre avec les pleins pouvoirs sur votre machine... y'a pas photo.

Bref, pour du vibe coding sur Mac, c'est le minimum vital.

Le VLIW, cette architecture de processeur "impossible" qui revient par la porte de l'IA

La chaîne YouTube Asianometry vient de publier une vidéo qui retrace l'histoire du VLIW, une architecture de processeur née dans les années 80 et longtemps considérée comme un échec. Sauf que cette technologie, enterrée avec l'Itanium d'Intel, refait surface dans les puces dédiées à l'intelligence artificielle. Et elle est peut-être déjà dans votre smartphone.

Le principe, et c'est un peu technique

Si vous ne connaissez pas Asianometry, c'est une chaîne qui décortique l'histoire des semi-conducteurs avec un vrai talent de vulgarisation, et cette vidéo sur le VLIW (pour Very Long Instruction Word) ne fait pas exception.

L'idée est assez simple sur le papier. Un processeur classique exécute ses instructions une par une, ou les réordonne à la volée avec du matériel dédié (c'est ce que font les puces modernes avec l'exécution "out-of-order").

Le VLIW fait l'inverse : c'est le compilateur, le logiciel qui transforme le code en instructions machine, qui regroupe à l'avance plusieurs opérations dans un seul "mot" très long. Du coup, le processeur n'a plus qu'à exécuter le paquet en une seule fois, sans se pose la moindre question. Le matos est de fait plus simple, moins gourmand en énergie, et plus rapide.

Le problème, c'est que tout repose sur le compilateur. S'il ne trouve pas assez d'opérations à paralléliser, le processeur tourne à vide. Et écrire un compilateur capable de faire ça correctement, c'est un casse-tête qui a occupé des chercheurs pendant des décennies.

L'Itanium, le plus gros pari raté d'Intel

Les premières tentatives commerciales datent des années 80 avec Multiflow et Cydrome, deux entreprises qui ont fait faillite. Intel a sorti le i860 en 1989, un processeur VLIW quasi impossible à programmer. Et puis il y a eu l'Itanium. Développé avec HP à partir de 1994 sous le nom IA-64, ce processeur devait remplacer le x86 et dominer les serveurs. Les analystes prédisaient la fin des architectures classiques.

Quand l'Itanium est sorti en 2001 après dix ans de développement, les performances étaient décevantes, la compatibilité avec les logiciels existants était catastrophique, et AMD avait entre-temps lancé le x86-64 qui faisait tout pareil en restant compatible avec l'ancien. L'Itanium est devenu un produit de niche avant de disparaître. La presse tech l'a rebaptisé "Itanic", en référence au Titanic.

Le retour par l'intelligence artificielle

Le VLIW n'a jamais complètement disparu. Texas Instruments l'utilise dans ses processeurs de traitement du signal depuis 1997 avec la famille TMS320C6000. Le DSP Hexagon de Qualcomm, celui qui gère l'inférence IA dans les puces Snapdragon, est lui aussi basé sur du VLIW.

Et Groq, la startup qui fait beaucoup parler d'elle pour la vitesse de ses puces d'inférence, utilise une architecture VLIW où le matériel ne prend aucune décision à l'exécution.

L'inférence de réseaux de neurones, c'est justement le type de calcul idéal pour le VLIW : des opérations régulières, prévisibles, massivement parallèles.

Pas besoin de réordonnancer quoi que ce soit, le compilateur peut tout planifier en amont. Des chercheurs travaillent d'ailleurs sur des extensions RISC-V qui intègrent des principes VLIW pour combiner le meilleur des deux mondes.

C'est quand même amusant de voir une technologie enterrée il y a vingt ans revenir grâce à l'IA. Le VLIW a échoué dans les années 2000 parce que le code des logiciels classiques est trop imprévisible pour être optimisé par un compilateur.

Mais l'inférence IA, c'est l'exact opposé : tout est prévisible et régulier. Du coup, l'architecture qui devait remplacer le x86 se retrouve à alimenter les accélérateurs IA de votre Snapdragon. Comme quoi, en informatique, rien ne meurt vraiment.

Source : Hackaday

ChatGPT’s refusal to admit mistakes is getting out of hand, and this exchange proves it

OpenAI CEO Sam Altman recently admitted that ChatGPT doesn't have the capability to keep track of time, but the chatbot insists it does.

In this photo illustration OpenAI ChatGPT icon is displayed on a mobile phone screen in Ankara, Turkiye on August 13, 2024.

In this photo illustration OpenAI ChatGPT icon is displayed on a mobile phone screen in Ankara, Turkiye on August 13, 2024.

"Raptor Lake will continue to be abundantly available": Intel exec makes a case for its older chips as RAM prices soar, but are they actually worth buying in 2026?

Intel's aging Raptor Lake desktop CPUs are "not going anywhere," according to an Intel exec, as RAM prices soar and PC gamers search for DDR4 alternatives. Are these chips worth buying in 2026? Let's explore.

Intel Core i7-13700K

Intel's "Raptor Lake" 13th and 14th Gen desktop processors remain a solid option for DDR4 gaming PCs.

❌