La DARPA vient de confier 5,2 millions de dollars à la startup Avalanche Energy pour développer une batterie à base de particules alpha. L'objectif : créer une source d'énergie compacte de quelques kilos, capable d'alimenter un ordinateur pendant des mois, destinée aux missions spatiales et militaires. Et la startup a une idée derrière la tête.
Avalanche Energy, une jeune entreprise basée dans l'État de Washington, vient de décrocher un contrat de 5,2 millions de dollars auprès de la DARPA, l'agence de recherche du Pentagone. Le programme s'appelle "Rads to Watts" et il va durer 30 mois.
L'idée, c'est de fabriquer des cellules solides miniaturisées capables de convertir les particules alpha émises par des radio-isotopes en électricité. On appelle ça une batterie "alphavoltaïque", un cousin éloigné des piles bêtavoltaïques qu'on trouve dans certains pacemakers.
La différence, c'est que les particules alpha transportent beaucoup plus d'énergie. Avalanche ne travaille pas seule : l'équipe comprend l'Université de l'Utah, Caltech, le laboratoire national de Los Alamos et McQuaide Microsystems.
Plus de 10 watts par kilo
Côté performances, la DARPA vise un objectif précis : dépasser les 10 watts par kilogramme. Pour donner un ordre de grandeur, les générateurs thermoélectriques à radio-isotopes utilisés sur les rovers martiens Perseverance et Curiosity produisent environ 2,5 watts par kilo pour une masse d'à peu près 45 kilos. Les batteries bêtavoltaïques actuelles, elles, plafonnent dans la gamme des microwatts.
Avec cette nouvelle technologie, quelques kilos de batterie suffiraient à alimenter un système de la taille d'un PC portable pendant des mois. Le principal défi technique est connu : les particules alpha endommagent les semi-conducteurs très rapidement, parfois en quelques heures. Avalanche travaille donc sur des puces résistantes à la dégradation, capables d'encaisser ce bombardement sur la durée.
La fusion n'est jamais très loin
Robin Langtry, le cofondateur d'Avalanche Energy, ne cache pas que ce contrat sert aussi un objectif plus ambitieux. L'entreprise développe en parallèle l'Orbitron, un réacteur à fusion compacte de la taille d'un bureau, prévu pour produire entre 1 et 100 kilowatts électriques.
Les puces conçues pour la batterie alphavoltaïque pourront servir dans ce réacteur, puisque la fusion génère aussi des particules alpha à haute énergie. Avalanche a déjà levé 29 millions de dollars en février 2026 et obtenu un contrat de 1,25 million auprès de l'AFWERX, la branche innovation de l'armée de l'air américaine. L'entreprise a construit et testé des démonstrateurs en interne ces deux dernières années, mais personne n'a encore produit de gain net d'énergie.
Le volet batterie radioactive est le plus crédible du projet. Produire 10 watts par kilo à partir de particules alpha, c'est ambitieux mais faisable avec les bons matériaux et un peu de patience. Par contre, le réacteur à fusion de bureau, on va dire que c'est un autre sujet.
Les spécialistes estiment qu'un prototype fonctionnel ne verra pas le jour avant une trentaine d'années. Avalanche a le mérite de financer sa recherche fusion avec des applications concrètes à court terme, et la DARPA ne donne pas 5 millions à n'importe qui. Maintenant, entre une pile qui tient des mois et un réacteur à fusion portatif, il y a quand même un petit gap.
Source : The Register
Si vous bossez avec le CI/CD de GitLab, y'a un angle mort que vous n'avez probablement jamais vérifié : La config de votre pipeline elle-même. Celle qui décide quelles images faire tourner et quels secrets exposer sans oublier les jobs à lancer. Et ça personne ne la scanne !
C'est d'ailleurs exactement cet angle d'attaque qu'ont choisi les pirates derrière l'attaque tj-actions en mars 2025, qui a touché plus de 23 000 organisations en modifiant simplement des tags de version. Ou encore l'attaque sur Trivy , où un scanner de sécurité s'est retrouvé lui-même vérolé. Le schéma est toujours le même : on s'infiltre comme Mario, par la tuyauterie et pas par la porte d'entrée.
Plumber
que je vous présente aujourd'hui, est un outil open source en Go qui scanne votre .gitlab-ci.yml et les réglages de votre repo pour détecter les failles de configuration. Vous l'installez via Homebrew (brew tap getplumber/plumber && brew install plumber), vous lancez plumber analyze à la racine de votre projet, et il vous sort un rapport de conformité. 2 minutes chrono, même pas besoin de toucher à votre CI.
Plumber embarque 14 contrôles de sécurité qui couvrent les erreurs de configuration les plus courantes. Ça détecte les images Docker taguées latest (le classique qui traîne dans 80% des projets), les branches pas protégées, les curl | bash sans vérification, et même les jobs de sécurité qu'on a désactivés en douce avec un petit allow_failure: true. Vous savez, le réglage foireux qui fait que votre pipeline affiche tout vert... alors qu'il ne scanne plus rien du tout !
Côté output, Plumber génère une sorte de liste d'ingrédients de votre pipeline, un peu comme l'étiquette sur un paquet de bouffe mais pour votre chaîne de déploiement. Ça vous dit exactement quelles images, quels scripts et quelles dépendances tournent dans vos jobs. Le tout dans un format standard que d'autres outils de sécu peuvent digérer.
Pour l'intégrer directement dans votre pipeline GitLab, c'est 2 lignes :
include:
- component: gitlab.com/getplumber/plumber/plumber@v0.1.30
Ça tourne à chaque push et chaque merge request. Y'a même un mode qui poste un commentaire de conformité directement dans la MR. Seul piège : il faut un token GitLab avec des droits Maintainer, sinon certains checks tournent dans le vide sans rien remonter. Une fois le token bien configuré, ça roule.
Après c'est GitLab only pour l'instant donc si vous êtes full GitHub, c'est pas pour vous (pour le moment). Et le projet est encore jeune donc faut pas s'attendre à une couverture totale non plus. Quoi qu'il en soit, ça va bien plus loin que Checkov sur la partie pipeline. Les 2 sont assez complémentaires d'ailleurs.
Pour en savoir plus c'est par ici : Plumber
Amazon va mettre fin au support de ses liseuses Kindle et tablettes Kindle Fire sorties en 2012 ou avant. A partir du 20 mai, ces appareils ne pourront plus acheter, emprunter ou télécharger de nouveaux livres. Seuls les ouvrages déjà présents sur l'appareil resteront lisibles.
La liste est assez longue et remonte à la toute première Kindle de 2007 avec son clavier et sa molette. Sont concernées la Kindle 1ere et 2e génération, la Kindle DX et DX Graphite, la Kindle Keyboard, la Kindle 4, la Kindle Touch, la Kindle 5 et la Kindle Paperwhite première génération.
Les tablettes Kindle Fire de première génération sont aussi touchées, même si elles garderont l'accès aux autres applications et services Amazon. Après le 20 mai, si vous réinitialisez un de ces appareils ou si vous le désassociez de votre compte Amazon, il ne pourra plus être réenregistré.
Les livres déjà téléchargés sur l'appareil restent accessibles, donc vous pouvez toujours lire ce que vous avez. Par contre, impossible d'acheter quoi que ce soit de nouveau depuis la boutique Kindle, et pas moyen non plus d'emprunter ou de télécharger des livres, même ceux que vous avez déjà achetés sur un autre appareil.
Pour ceux qui veulent quand même continuer à utiliser leur vieille liseuse, il reste la solution du transfert par USB. Avec un logiciel comme Calibre , on peut convertir des fichiers ePub en format compatible Kindle et les charger manuellement. D'ailleurs c'est aussi valable si vous avez une Kindle récente !
Amazon indique que cette mesure ne concerne qu'environ 3% de ses utilisateurs actuels. On va dire que c'est l'occasion de vous équiper avec une Kindle un peu plus récente ! À titre personne j'utilise désormais une Kindle Paperwhite Signature Edition , et je l'adore vraiment, je la préfère même à la Colorsoft qui est moins bien contrastée sur la lecture de romans. Et en liseuse secondaire, j'ai toujours ma Kobo que j'ai testée ici .
Quoi qu'il en soit, c'est le genre de décision qui rappelle que quand on achète du contenu numérique, on achète surtout un accès, pas une propriété. Ces liseuses ont entre 13 et 19 ans, donc on peut comprendre qu'Amazon arrête le support technique. Mais couper l'accès à la boutique alors que l'appareil fonctionne encore, c'est quand même un peu sec.
Source : Engadget
L'IA embarquée, c'est pas juste un buzzword de salon type CES. C'est vraiment ce qui fait que votre voiture freine toute seule, que votre drone évite les arbres et que votre prothèse auditive filtre le bruit en temps réel. Sauf que pour déployer un réseau de neurones sur un microcontrôleur de 256 Ko de RAM... bah on dépend quasi exclusivement de frameworks américains ou chinois.
Un peu gênant, non ?
Du coup, le CEA (oui, le Commissariat à l'énergie atomique, celui de Palaiseau) a décidé de s'y coller avec AIDGE , un framework open source dédié à l'IA embarquée qui est hébergé par la fondation Eclipse. En gros, vous prenez votre modèle de deep learning entraîné sous PyTorch ou importé en ONNX, et AIDGE se charge de l'optimiser puis de générer du code C/C++ standalone prêt à tourner sur votre cible matérielle. Pas du pseudo-code donc mais du vrai C++ compilable.
Et quand je vous dis "cible matérielle", y'a bien sûr pour les GPU et les CPU mais également pour des microcontrôleurs, des DSP, des FPGA (ces puces reprogrammables), des NPU (processeurs spécialisés IA) et même d'ASIC custom. Le framework du CEA supporte les architectures CNN, RNN, GAN et Transformers, avec tout l'arsenal d'optimisation qui va bien tels que quantification post-entraînement, pruning, compression, et même du Quantization Aware Training basé sur les méthodes SAT et LSQ. Bon ok, ça fait beaucoup d'acronymes, on ne comprend pas tout ^^, mais en résumé c'est ce qui permet de réduire la taille d'un modèle de plusieurs gigas à quelques centaines de Mo sans trop perdre en précision.
en fait, au lieu de réécrire tout pour chaque puce, AIDGE utilise un système de graphes pour manipuler et transformer vos modèles indépendamment du hardware cible. Comme ça si vous changez de puce, vous regénérez le code, et c'est reparti. Pas besoin de réécrire votre pipeline de déploiement à chaque fois (et ça, si vous avez déjà bossé dans l'embarqué, vous savez que c'est pas rien). Bon par contre, faut pas s'attendre à un pip install aidge qui marchera du premier coup... ce serait trop simple ;-). Faudra quand même compiler quelques dépendances C++ avant d'en profiter.
AIDGE est porté par deux gros programmes : DeepGreen côté français avec 18 partenaires (Airbus, Thales, Dassault Aviation, EDF, MBDA, Inria dans la boucle) et Neurokit2E financé par Horizon Europe qui réunit 25 partenaires dans 5 pays (STMicroelectronics, Infineon, Fraunhofer entre autres). Et le projet embarque même un design de chip dédié qui s'appelle NeuroCorgi (oui, comme le chien de la reine d'Angleterre ^^).
D'ailleurs, les cas d'usage vont du classique à des choses plus inattendues : détection d'objets pour l'ADAS automobile (genre, freiner avant le piéton), maintenance prédictive en usine, ou encore amélioration audio temps réel pour les prothèses auditives. Le tout sous licence Eclipse Public License 2.0, donc libre et gratuit.
Bon après, la doc a encore du mal à suivre (comme souvent avec les projets de recherche) et j'aurais aimé des benchmarks comparatifs clairs face à TensorFlow Lite ou ONNX Runtime, histoire de voir concrètement combien de millisecondes on gagne sur un STM32 par rapport aux alternatives. Mais le fait d'avoir une chaîne complète design-optimisation-déploiement qui soit européenne, open source et hardware-agnostique... ça mérite quand même qu'on s'y intéresse. Surtout quand on voit la dépendance actuelle à PyTorch qui est, faut bien le dire, piloté par Meta.
Bref, si vous bossez dans l'embarqué ou que vous kiffez bidouiller du deep learning sur des petites puces, allez jeter un oeil .
Merci à Fabrice pour le lien !
Google vient d'annoncer l'arrivée des onglets verticaux dans Chrome sur ordinateur. Une fonction que des navigateurs comme Edge ou Arc proposaient depuis des années, et qui arrive avec un mode lecture plein écran revu.
L'option est désactivée par défaut. Pour l'activer, il suffit de faire un clic droit sur la barre d'onglets et de choisir "Afficher les onglets verticalement". Les onglets passent alors dans une barre latérale sur le côté de la fenêtre, avec le nom complet de chaque page affiché en clair. La gestion des groupes d'onglets est aussi plus lisible dans ce mode, ce qui est quand même pratique quand on commence à dépasser la dizaine d'onglets ouverts.
Et une fois activée, l'option reste en place tant que vous ne revenez pas manuellement à l'affichage classique.
Google a aussi profité de cette mise à jour pour revoir le mode lecture. Jusqu'à présent, il s'affichait dans un panneau latéral, ce qui n'était pas toujours très confortable. La nouvelle version propose un affichage plein écran qui supprime les distractions. Un clic droit sur une page, puis "Ouvrir en mode lecture", et c'est parti.
Les deux fonctions sont en cours de déploiement sur la version bureau de Chrome. Google ne précise pas de numéro de version, mais indique que tous les utilisateurs devraient y avoir accès dans les prochaines semaines.
Pour le contexte, Microsoft Edge propose les onglets verticaux depuis 2021, Firefox les a ajoutés l'an dernier, et des navigateurs comme Arc ou Vivaldi en avaient fait un argument de vente depuis le début. Chrome arrive donc bon dernier sur ce coup-là.
C'est une bonne nouvelle pour les utilisateurs de Chrome qui jonglent avec des dizaines d'onglets au quotidien. Les onglets verticaux, c'est un vrai gain de lisibilité sur les écrans larges, et on se demandait depuis un moment pourquoi Google trainait autant pour le proposer.
Source : 9to5Google
ChipSoft, l'éditeur qui fournit le logiciel de dossiers médicaux à environ 80 % des hôpitaux aux Pays-Bas, vient d'être touché par un ransomware. Le site de l'entreprise est hors ligne depuis le 7 avril, et on ne sait pas encore si des données de patients ont été volées.
L'attaque a été confirmée le 7 avril par Z-CERT, l'agence néerlandaise qui surveille la sécurité informatique dans le secteur de la santé. ChipSoft développe le logiciel HiX, qui gère les dossiers médicaux de patients dans la grande majorité des hôpitaux du pays. Le site web de l'entreprise est tombé dans la journée et reste inaccessible.
Z-CERT a envoyé un mémo confidentiel aux clients de ChipSoft pour leur demander de couper leur connexion VPN vers les systèmes de l'éditeur. Onze hôpitaux ont déconnecté leurs systèmes par précaution. Les autres ont indiqué que leurs données patients étaient en sécurité et que leurs services continuaient de fonctionner.
ChipSoft a confirmé qu'il y avait eu un "incident de données" avec un "possible accès non autorisé". L'entreprise ne peut pas garantir que des données de patients n'ont pas été consultées ou copiées. Le groupe de hackers derrière l'attaque n'a pas été identifié, et aucun montant de rançon n'a été rendu public.
Plusieurs hôpitaux, dont le Rijnstate Hospital, l'Antoni van Leeuwenhoek (spécialisé en cancérologie) et le Franciscus Hospital ont déclaré ne pas être affectés. Mais la portée réelle de l'attaque reste floue.
Z-CERT classe les ransomwares et l'extorsion comme les menaces principales pour les organisations de santé néerlandaises dans son rapport annuel.
Le secteur reste une cible privilégiée parce que les données médicales ont une valeur élevée sur le marché noir, et que les hôpitaux ne peuvent pas se permettre de rester longtemps sans accès à leurs systèmes.
Quand un seul éditeur gère les dossiers médicaux de 80 % des hôpitaux d'un pays, une attaque sur cet éditeur prend une dimension un peu inquiétante.
Pour l'instant les dégâts semblent contenus, mais le fait que ChipSoft ne puisse pas exclure un vol de données, c'est quand même un gros point d'interrogation. Et ça rappelle qu'un système de santé aussi centralisé, ça peut vite devenir une faiblesse.
Source : NL Times
Après le test du Yoto Player Gen 3 , on a voulu voir ce que valait la version portable. La Yoto Mini coûte environ 70 euros, tient dans une poche et promet 20 heures d'autonomie. On l'a confiée au même testeur de 4 ans, le fils d'une amie. Et on a été plutôt convaincus.
La Yoto Mini fait 7 cm de côté. C'est un petit bloc dense, qui a l'air de pouvoir survivre à peu près à tout, surtout avec sa protection en silicone : chute sur le bitume, fond de sac à dos, mains d'un enfant de 4 ans. On retrouve les deux gros boutons rotatifs orange pour le volume et la navigation, pas d'écran tactile, pas de lumière bleue. Juste de la mécanique simple que notre cobaye a prise en main tout de suite.
Elle se recharge en USB-C et affiche une autonomie d'environ 20 heures, de quoi traverser la France sans trop de stress. Et point important : la Mini fonctionne toute seule. Pas besoin d'avoir le gros modèle pour l'utiliser, c'est un appareil indépendant. Pour les parents qui hésitent à mettre 100 euros dans le cube de salon, c'est une bonne entrée en matière à 70 euros.
La vraie différence avec le modèle de salon, c'est la prise jack. On branche un casque, et l'enfant écoute ses histoires sans imposer le générique de ses dessins animés à tout le wagon. La qualité audio est très bonne pour un si petit appareil, on n'est pas sur un jouet qui crachote. Et en Bluetooth, la Mini peut tout à fait servir de petite enceinte une fois arrivé à destination.
Côté contenu, on retrouve le système de cartes physiques Yoto. Les cartes vierges "Make Your Own" sont d'ailleurs le vrai bon plan : en quelques clics sur l'application, on peut y lier un flux RSS de podcast ou des MP3, et l'enfant se balade avec sa propre bibliothèque. Un peu comme nos baladeurs cassettes dans les années 90.
Les cartes ne contiennent pas les données audio, elles servent de clés. Pour écouter en avion, en train ou en rase campagne, il faut juste que le contenu ait été téléchargé dans la mémoire de la Mini avant de partir.
Rien de compliqué : on la laisse sur le Wi-Fi à la maison la veille du départ, et c'est réglé. L'application mobile gère tout le reste : bridage du volume (indispensable sous un casque pour un enfant), état des téléchargements, et le Yoto Daily, un petit podcast matinal gratuit qui est devenu un rituel chez notre testeur.
Pour 70 euros, la Yoto Mini fait le job et elle le fait bien. Solide, simple à utiliser, 20 heures d'autonomie et une vraie qualité audio pour sa taille. Le système de cartes personnalisables est malin, et la prise jack résout le problème numéro un des trajets en famille : le bruit.
Que ce soit en complément du gros cube ou comme premier appareil Yoto, c'est franchement difficile de trouver mieux dans cette catégorie. Un achat qu'on ne regrette pas, pour peu que vous ayez un enfant bien sûr. Disponible par ici sur Amazon !
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.
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.
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.
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 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
Et si vous pouviez renommer n'importe quel lieu sur la carte du monde ?
Genre, transformer "Paris" en "Pain au Chocolat City" ou "Bordeaux" en "Chocolatine Land" ? Hé bien c'est exactement ce que propose Rename World , et y'a déjà plus de 40 000 renommages au compteur.
Le principe est hyper simple : vous cliquez sur un nom de lieu, vous proposez un nouveau nom, et la communauté vote. Les meilleures propositions restent, les autres disparaissent dans l'oubli. Y'a pas besoin de créer un compte pour explorer la carte, c'est ouvert à tout le monde et c'est dispo en français !
J'ai d'abord cru que ça allait être un festival de noms vulgaires et de spam... mais en fait non. Le créateur (qui se fait appeler kafk) a mis en place un filtre de mots plus un dashboard d'administration qui lui permet de dégager les trolls en quelques clics. Sur les 40 000+ propositions, le spam reste donc marginal et la majorité des renommages sont soit créatifs, soit du jeu de mots inoffensif. Après évidemment, si quelqu'un challenge votre proposition, faudra convaincre la communauté de voter pour vous.
Je vous présente Clermont-Ferrand ^^ :
Mais le site ne s'arrête pas au simple renommage. Y'a aussi un mode Name Duel où deux propositions s'affrontent en face à face, un Quiz pour tester vos connaissances géo, et un Leaderboard pour les plus prolifiques. Du coup c'est devenu un vrai petit jeu communautaire.
Il y a également un bouton "Hide NZ" qui permet de supprimer carrément la Nouvelle-Zélande de la cartographie mondiale. Si vous traînez un peu sur r/MapsWithoutNZ, vous comprendrez la référence. Et un bouton "Show NZ" pour les gens bien, évidemment.
Côté technique, kafk a préféré utiliser des PMTiles (40 Go stockées chez Cloudflare) plutôt que des tuiles raster classiques, ce qui rend la navigation bien plus fluide. Le rendu vectoriel s'appuie comme d'hab sur OpenStreetMap et tourne sur le serveur d'un de ses potes équipé de 256 Go de RAM (oui, on a les amis qu'on mérite ^^). Attention par contre, si vous cherchez à renommer un endroit précis (genre votre village de consanguins) et que le libellé ne s'affiche pas, faudra jouer avec le niveau de zoom car c'est du vectoriel, les étiquettes géographiques apparaissent à des échelles différentes.
Si vous avez déjà perdu des heures sur des cartes interactives de Westeros , attendez de voir ce qui se passe quand Internet a le droit de renommer le monde réel. Perso, j'ai cherché ce que les gens avaient fait de ma ville... et j'ai pas été déçu. Y'a aussi un Discord pour la communauté si vous voulez proposer des idées ou signaler des soucis.
Bref, allez-y, renommez votre bled, la préfecture de votre département, et bon courage à kafk pour la modération !
Ah et merci à AV pour l'info !