Hacker News
-
France to ban unsolicited telemarketing calls
La France interdit dès le 11 août les appels téléphoniques commerciaux non sollicités, sauf consentement préalable explicite du consommateur. Les amendes atteignent jusqu'à 375 000 € par appel pour les entreprises et 75 000 € pour les particuliers. Un signalement en ligne est prévu, et des exceptions existent (consentement, relation contractuelle existante).
Cette mesure fait suite à des années de plaintes : environ trois quarts des Français recevraient au moins un appel non sollicité par semaine. Le précédent système d'opposition (liste d'opposition) était jugé inefficace. La loi suscite des inquiétudes au Maroc, où 40 000 à 50 000 emplois de centres d'appels sont menacés, le marché français représentant plus de 80 % du chiffre d'affaires du secteur.
La discussion exprime un large consensus sur la nuisance des appels non sollicités, mais beaucoup doutent que l'interdiction française suffise. Plusieurs commentateurs racontent ne plus décrocher pour les numéros inconnus depuis des années, sacrifiant parfois des appels légitimes. Un praticien note que la loi vise le démarchage commercial, pas les arnaques, et rappelle que la France a déjà imposé le blocage des numéros usurpés en janvier, ce qui a réduit les appels frauduleux, même si les vrais numéros enregistrés pour arnaquer persistent. D'autres estiment au contraire que la mesure sera « essentiellement inutile » contre les fraudeurs, qui ignorent les listes d'opposition, et appellent à un filtrage au niveau des opérateurs, par exemple en bloquant les numéros qui émettent des volumes anormaux d'appels.
Les solutions techniques suscitent un vif intérêt : listes blanches gérées par l'État, authentification des appels (type STIR/SHAKEN) avec attestation complète obligatoire, ou affichage du nom de l'appelant vérifié. Des exemples étrangers sont cités : la Finlande bloque les appels internationaux avec un indicatif finlandais usurpé, tandis qu'aux Pays-Bas et en Norvège, des lois similaires existent mais sont mal appliquées — les commentateurs y reçoivent encore des appels, y compris avec des numéros locaux usurpés. Aux États-Unis, un participant note que les opérateurs ne font pas respecter les protocoles existants faute de pression financière, et qu'un numéro américain réservé à la double authentification reçoit plus d'arnaques en un jour qu'un numéro local en un an. À l'inverse, un autre Américain dit ne recevoir presque aucun appel frauduleux, ce qui montre une forte disparité.
La discussion nuance l'article sur plusieurs points. D'abord, l'efficacité réelle est mise en doute : le registre français Bloctel, censé protéger les consommateurs, a lui-même fui la semaine dernière, et des commentateurs recommandent des applications communautaires comme Sara Croche. Ensuite, un avis minoritaire craint que l'interdiction ne nuise aux petites entreprises qui dépendent du démarchage pour se faire connaître, au profit des grandes firmes.
-
As AI eats the web, the internet’s collective memory is disappearing
Les résumés IA de Google inventent des horaires de coucher de soleil et d'autres faits, illustrant la dégradation de la recherche en ligne. Le problème est plus profond : la mémoire collective du web se désagrège via le link rot, la suppression d'archives (ex. FiveThirtyEight) et la pollution par du contenu généré. L'Internet Archive et Wikipédia sont menacés : le trafic diminue car les IA scrapent directement leurs contenus, et l'Archive subit attaques et procès. Parallèlement, des gouvernements européens, dont la France avec Qwant, cherchent des alternatives souveraines ; un tribunal allemand a tenu Google responsable des fausses déclarations de son IA.
Plusieurs commentateurs confirment le constat de l'article : la qualité des recherches en ligne s'effondre et l'IA accélère la perte de mémoire collective du web. Des retours concrets évoquent des pages non indexées par Google depuis sa mise à jour « helpful content », des résumés IA qui hallucinent ou interprètent mal la requête, et des résultats tellement mauvais que certains utilisateurs utilisent par défaut les résumés IA (qu'ils disent détester). Un commentateur cite une décision de justice allemande tenant Google pour responsable d'une diffamation générée par son IA. D'autres notent que DuckDuckGo indexe parfois des pages que Google ignore, mais que la recherche reste globalement dégradée.
Les avis divergent sur la responsabilité de l'IA. Certains estiment que le web se dégradait déjà avant l'arrivée de l'IA, et y voient une chance de revenir à un web humain plus petit. D'autres trouvent une valeur pratique dans les assistants IA pour des tâches techniques (configuration réseau, écriture de code), tout en reconnaissant que leur fiabilité est inégale. Un commentateur raconte des conseils dangereux de Gemini pour une réparation automobile, illustrant le surconfiance du modèle. Un autre affirme que l'IA décourage la publication de contenu original, car il sera ingéré et remixé sans reconnaissance.
La discussion corrige et nuance l'article sur plusieurs points. Un commentateur précise que dans l'affaire contre l'Internet Archive, la cour a bien déterminé une « copie non autorisée », et non une simple allégation, et que l'Archive a ignoré des demandes répétées des syndicats d'écrivains. Un autre reproche à l'article de considérer les intermédiaires (gatekeepers) comme inévitables, et plaide pour une réflexion sur un internet sans gardiens. Enfin, plusieurs participants soulignent que la collecte de corpus « de confiance » pour l'entraînement des IA devient cruciale, face à un web contaminé par le SEO et la désinformation. Dans l'ensemble, la discussion valide les inquiétudes de l'article mais en complexifie les causes : algorithmes de Google, poursuites contre les archives, et défauts intrinsèques des résumés IA.
-
Stealing Reasoning Traces from Proprietary LLM APIs
Une étude académique démontre qu'il est possible de dérober les traces de raisonnement cachées des API de LLM propriétaires (OpenAI, Anthropic, Google). En collectant 6 708 trajectoires publiques d'agents sur GitHub et Hugging Face contenant des blocs de raisonnement chiffrés, les auteurs ont reconstruit 315 320 blocs via un pipeline de décodage. Ils ont notamment retrouvé 704 artefacts de confidentialité dans des sessions utilisateurs réelles, dont 62 clés API, 33 mots de passe, 24 jetons d'accès et 30 adresses e-mail, certains n'apparaissant que dans les traces cachées.
L'étude montre aussi que le raisonnement décodé peut être utilisé pour influencer les réponses d'autres modèles, et que des raisonnements sur des contenus dangereux peuvent être récupérés en clair. Les résultats sont détaillés dans un preprint arXiv.
La discussion salue la simplicité de l'attaque décrite dans l'article : les traces chiffrées sont portables d'un modèle à l'autre, et un modèle plus faible, plus facile à jailbreaker, peut les décoder. Plusieurs commentateurs s'étonnent que les fournisseurs réutilisent la même clé de chiffrement entre modèles et y voient une faille de sécurité évidente, vraisemblablement laissée pour permettre le changement de modèle en cours de conversation. Certains notent que la correction a déjà été appliquée, mais que les fournisseurs n'ont pas reconnu de risque de sécurité, ce qui est jugé décevant. Un commentaire souligne que le problème ne vient pas du chiffrement mais de la fonctionnalité de rétrogradation vers un modèle plus faible, et qu'il persisterait même si les traces étaient stockées côté serveur.
Le terme « vol » est contesté : plusieurs intervenants rappellent que les sorties d'un LLM ne sont pas protégées par le droit d'auteur (au moins dans l'UE) et que l'utilisateur paie pour les tokens. Pour certains, voir le raisonnement est même un droit et un outil de vérification nécessaire, comparable à l'accès au code source. D'autres relativisent en invoquant les conditions d'utilisation. Un débat émerge aussi sur la distillation : l'article suggère que Kimi K3 aurait été entraîné à partir de traces de Claude et GPT, mais un commentateur juge cette accusation teintée de sinophobie et estime que la distillation ne peut expliquer qu'un rattrapage de trois mois. À l'inverse, plusieurs praticiens rapportent avoir observé des similitudes frappantes entre les raisonnements de modèles propriétaires et les modèles open source, et un commentaire pointe que publier des traces inversées (sans les avoir volées) pourrait devenir une méthode alternative pour reconstituer les raisonnements.
Les commentaires apportent des précisions techniques : la validation de l'attaque repose sur la longueur des tokens de raisonnement ; les modèles jailbreakés révèlent des raisonnements en « grug speak » (style télégraphique) confirmé par ailleurs ; l'article mentionne que préremplir Kimi K3 avec des extraits de raisonnement d'Opus influence ses réponses, preuve indirecte de distillation.
-
The UK's War on Anonymity Has Come to America
Une enquête d'Effort a identifié une opération coordonnée de cinq ONG étrangères (et leurs filiales américaines) pour influencer les législateurs américains en faveur de lois sur l'identité numérique qui supprimeraient l'anonymat en ligne. Ces ONG britanniques s'appuient sur des arguments de protection de l'enfance, et ont déjà fait adopter ces lois au Royaume-Uni, où elles servent selon l'enquête à surveiller, arrêter et emprisonner des dissidents politiques. Elles répliquent maintenant ce modèle dans 21 États américains et au Congrès.
L'article cite notamment 5Rights, fondée par la baronne Beeban Kidron, qui a fait du lobbying pour la loi californienne AB 2273, et le Center for Countering Digital Hate (CCDH), fondé par des consultants travaillistes britanniques. L'Institute for Strategic Dialogue (ISD) et Reset Tech sont également impliqués, avec des financements gouvernementaux et des liens entre leurs dirigeants. L'enquête souligne que ces organisations n'ont pas toujours déclaré leurs activités de lobbying comme exigé par la loi sur l'enregistrement des agents étrangers (FARA), et que leurs propositions de lois pourraient être utilisées à des fins de censure politique aux États-Unis, comme au Royaume-Uni.
La discussion diverge fortement sur la nature de ces lois : pour beaucoup, la rhétorique de « protection de l’enfance » n’est qu’un prétexte à la surveillance de masse et à la censure, plusieurs commentateurs rappelant que les États-Unis ont déjà adopté des lois d’identification pour la pornographie, ce qui relativise l’influence britannique. Certains affirment au contraire que la majorité de la population soutient ces interdictions, rendant le combat des technophiles difficile. Un point d’accord émerge : les solutions techniques existent (comme le « child mode » proposé au niveau de l’OS avec listes blanches) mais sont soit inutilisables (le contrôle parental d’Apple nécessite 18 clics, selon un commentateur), soit contournées par les adultes. Plusieurs voix s’élèvent pour dénoncer le rôle de lobbys comme 5Rights, liés à des financements opaques de Meta, et pour souligner que des militants se sont déjà opposés en Californie aux projets de loi comme AB 1856, qui criminalisaient l’open source.
-
Compression is prediction
L'article explore la parenté entre compression de données et modèles de langage (LLM), qui visent selon l'auteur le même problème fondamental. Il expose les bases de la compression : minification vs compression "vraie", encodage par plages (RLE), transformées, modèles et codeurs entropiques. Il détaille le codage arithmétique, montrant comment de meilleures probabilités (le modèle) améliorent la compression, et que des distributions plus déséquilibrées réduisent le nombre moyen de bits par symbole (entropie). Le texte, tronqué, s'engageait sur un exemple concret avant de s'interrompre.
La discussion confirme que l'idée « compression = prédiction » est un lieu commun de la théorie de l'information : plusieurs commentateurs citent MacKay, Shannon, Schmidhuber, Ted Chiang ou encore Grant Sanderson, et certains reprochent à l'article de présenter comme nouvelle une notion déjà explorée sans citer ses sources. Un commentaire rappelle que cette thèse est au cœur de l'ouvrage de MacKay et des enseignements de Cambridge. D'autres apportent des références précises : PPM, complexité de Kolmogorov, distance de compression normalisée, ou encore l'article de Schmidhuber sur la compression comme moteur de la curiosité et de la créativité.
Le principal désaccord porte sur la portée de l'équivalence. Plusieurs intervenants soulignent que la compression ne vaut prédiction que si la distribution d'entraînement est exactement celle des problèmes futurs ; pour de la généralisation, la distribution de test peut être différente, et une compression avec pertes peut ignorer des cas rares qui comptent pourtant. Un avis minoritaire va plus loin : la compression serait de la mémorisation, pas de la prédiction, et les LLM manqueraient d'imagination. En réponse, d'autres rétorquent que tout compresseur peut être converti en modèle génératif (gzip peut produire du texte), et que l'abstraction apprise par les LLM dépasse la simple régurgitation. La discussion nuance donc l'article en distinguant compression, prédiction, extrapolation et indexation.
Des retours techniques concrets émaillent le fil : les fichiers GGUF Q8 se compressent à environ 90% de leur taille avec xz, les compresseurs courants combinent LZ et codage entropique (Deflate, LZMA, zstd, LZ4), et l'indexation est proposée comme troisième volet du triptyque. Un commentaire relie le sujet au Hutter Prize et à l'expérience de Shannon sur l'estimation de l'information de l'anglais. Dans l'ensemble, les commentaires reprochent à l'article son manque de nouveauté et de nuances, tout en lui reconnaissant une utilité pédagogique.
-
England set to be one of the first countries to eliminate hepatitis C
L'Angleterre est en passe de devenir l'un des premiers pays au monde à éliminer l'hépatite C. L'objectif de traiter 80% des cas connus est déjà atteint, et les décès ont baissé de 36% en dix ans. Des initiatives comme les tests sanguins aux urgences et les tests gratuits à domicile ont permis de trouver des personnes non diagnostiquées. Depuis 2015, plus de 100 000 personnes ont été traitées. Un objectif de réduction de 65% de la mortalité liée à l'hépatite C reste à atteindre, mais pourrait l'être avant 2030. Le NHS encourage les personnes issues de certains pays d'Europe de l'Est à se faire tester.
La discussion confirme l'importance de cette avancée pour l'Angleterre, mais apporte surtout des retours de terrain. Plusieurs commentateurs racontent avoir été diagnostiqués tardivement, parfois par hasard lors d'un dépistage plus complet, soulignant que le test de l'hépatite C n'est pas systématiquement inclus dans les panels STI standards. Un commentateur mentionne une contamination par transfusion dans les années 1980 et une attente de plusieurs décennies avant l'arrivée des antiviraux modernes. Ces témoignages expliquent pourquoi le dépistage est un enjeu clé, au-delà du seul traitement.
Certains commentaires corrigent ou nuancent l'article. Un lecteur reproche au texte de ne pas préciser la cible de 2030, mais d'autres répondent que les détails figurent plus loin (traitement par comprimés antiviraux pendant 8 à 12 semaines, guérison dans plus de 95% des cas), et qu'il s'agit d'un style BBC classique, pas d'une rédaction par IA. Un commentaire sceptique estime que diagnostiquer 90% des cas ne suffit pas à éliminer la maladie, car les usagers de drogues à risque ne seront pas tous atteints ; un autre rétorque que le traitement des cas connus a déjà fait chuter la mortalité de 36%, ce qui reste un progrès.
Les commentaires politiques sont nombreux mais périphériques : plusieurs opposent la situation des États-Unis à celle du Royaume-Uni, certains accusant RFK Jr. et le mouvement antivax, tandis qu'un avis minoritaire rappelle que l'hépatite C n'est pas évitable par vaccin et que le problème dépasse un seul homme. La discussion éclaire aussi le contexte institutionnel : le programme ne concerne que l'Angleterre car la santé est dévolue à chaque nation constitutive. Enfin, des clarifications sur le statut de l'Angleterre comme pays au sein du Royaume-Uni apparaissent, mais sans lien direct avec l'article.
-
OpenAI’s head of ethics leaves less than a year after joining
Le responsable de l'éthique d'OpenAI quitte l'entreprise moins d'un an après son arrivée.
Plusieurs commentateurs sont sceptiques quant au rôle réel des équipes d'éthique dans les grandes entreprises technologiques, y voyant avant tout un outil de communication ou une case à cocher pour rassurer investisseurs et employés. Selon eux, ces équipes n'ont généralement aucun pouvoir de décision et leurs recommandations sont ignorées dès qu'elles coûtent de l'argent. Certains soulignent que l'article ne fournit aucune explication sur le départ de Chloé Bakalar, et que son passage chez Meta (six ans) puis son départ d'OpenAI après moins d'un an interrogent : soit elle aurait fini par prendre conscience de l'inefficacité de son rôle, soit la situation chez OpenAI serait particulièrement mauvaise. Un commentaire ironise sur le fait d'avoir été « chief ethicist chez Meta sous Zuckerberg », tandis qu'un autre estime que ce parcours prouve justement qu'elle ne découvrait pas les problèmes éthiques des grandes entreprises.
La discussion s'attarde sur l'incident de piratage de HuggingFace, survenu juste avant son départ. Certains y voient une possible raison de son départ : elle aurait servi de bouc émissaire, ou l'incident aurait été orchestré comme une opération de communication pour montrer la puissance des modèles, et elle aurait refusé d'en être la figure. D'autres émettent l'hypothèse plus simple qu'elle a été licenciée pour cette raison. Un commentateur remarque que le COO a aussi démissionné récemment, mais que les départs sont fréquents dans les grandes entreprises et qu'il est difficile d'en tirer des conclusions. Plusieurs voix appellent à la prudence : les raisons de quitter un poste sont multiples, et une offre meilleure ailleurs est tout aussi plausible que des désaccords éthiques.
La discussion contraste avec l'article en soulignant son manque de détails. Plusieurs commentateurs notent qu'OpenAI a récemment réalisé une offre publique de rachat d'actions, ce qui aurait pu permettre à Bakalar d'empocher ses actions avant de partir. D'autres débattent de la nature du travail d'éthique : l'un estime qu'il devrait contribuer concrètement à l'alignement des modèles, mais un autre répond qu'il est techniquement impossible de prouver un tel alignement.
-
H3-metal – Native MiniMax-H3 inference for Apple Silicon
H3-metal est un projet d'inférence native du modèle MiniMax-H3 sur Apple Silicon, construit par étapes : métadonnées, parité Metal, encodage de prompt, génération vidéo/audio, conditionnement première/dernière image et références Ref2VA. L'article détaille l'utilisation pratique : commandes pour générer des vidéos, options de performance (étapes de débruitage, réutilisation de couches, réduction de jetons, rendu interne réduit), avec des exemples de profils et des mesures sur M3/M5 Max. Il mentionne des résultats de qualité (SSIM) et des recommandations de configuration pour équilibrer vitesse et qualité.
Plusieurs commentateurs partagent leurs retours d'usage de MiniMax H3 sur Apple Silicon via ComfyUI. L'un indique que sur un MacBook Pro M5 Pro 64 Go, le modèle fonctionne bien avec un quant GGUF Q5_K_M, mais qu'une courte vidéo de 9 secondes en 480x864 à 20 étapes demande plus d'une heure de calcul. Un autre, sur un Mac Studio M4 Max 128 Go, mesure une heure et demie pour une vidéo 15s 480p. Ces chiffres relativisent l'optimisation native : l'article promet des gains, mais en pratique la génération reste très lente comparée à une carte graphique dédiée — un commentateur cite une RTX Pro 6000 faisant la même chose en 2 à 3 minutes.
La question de la mémoire est éclaircie : selon le README cité, le pic d'occupation est d'environ 40 Go, ce qui rendrait le modèle utilisable sur des machines de 96 Go, contrairement à une première réaction qui pensait 128 Go obligatoires. Un commentateur recommande d'ailleurs Wan2GP pour les configurations à faible VRAM. Plusieurs intervenants s'interrogent sur les performances sur des configurations spécifiques (M4 Pro 48 Go, M5 Max), sans réponse définitive.
Un commentateur évoque une option 'sparse attention' mentionnée par MiniMax lors d'une AMA, qui pourrait accélérer significativement le modèle. Globalement, la discussion apporte surtout des retours de terrain chiffrés et nuance l'enthousiasme de l'article : si l'optimisation native est réelle, elle ne transforme pas la machine en station de travail temps réel.
-
Go is an ideal language for AI-assisted software engineering
L'article de 0xedb présente Go comme un langage idéal pour le développement logiciel assisté par IA. Il argue que l'IA génère désormais une grande partie du code, déplaçant l'effort humain vers la relecture, la vérification et la maintenance. Dans ce contexte, la lisibilité et la cohérence du code deviennent plus importantes que la rapidité d'écriture. Go, créé pour le génie logiciel d'équipe, offre une plateforme intégrée (formateur, tests, gestion de dépendances, sécurité) qui standardise le code, bénéficiant aussi bien aux humains qu'aux modèles d'IA. Sa simplicité, sa lisibilité et son typage statique aident à détecter les erreurs générées par l'IA, réduisant les hallucinations et les bugs. L'auteur conclut que la clarté pour les humains est aussi une clarté pour l'IA, permettant de maintenir des systèmes à grande échelle.
Plusieurs commentateurs valident l'idée que Go se prête bien à l'ingénierie logicielle assistée par IA, notamment grâce à sa simplicité, son formatage standardisé, ses outils (go fix, AST/SSA) et ses ressources officielles de qualité. Un responsable du langage Go chez Netflix rapporte que les agents IA produisent de meilleur code Go que dans d'autres langages, et que son équipe fournit ces ressources aux agents. D'autres soulignent l'importance de la rapidité de compilation pour le cycle itératif des LLM, un atout de Go face à des langages plus stricts mais plus lents.
Mais la discussion est très critique sur le fond et la forme. Beaucoup relèvent un conflit d'intérêts flagrant : l'article émane du créateur de Go chez Google, ce qui en affaiblit la crédibilité. Un avis minoritaire mais marqué préfère Rust, dont le compilateur strict et les vérifications à la compilation seraient idéaux pour guider un LLM et réduire les surprises à l'exécution. D'autres encore défendent des langages à typage riche ou orientés vérification formelle (Dafny, Agda). Plusieurs praticiens n'observent aucun avantage net de Go sur Java, TypeScript ou Zig pour le codage par IA, et signalent que les LLM produisent souvent du code concurrent Go bugué, surtout avec des modèles faibles. Enfin, un commentateur conteste la notion de « front de Pareto » : Go ne serait optimal sur aucun axe, même si un autre répond qu'un choix pratique peut très bien le sélectionner.
Des corrections factuelles et retours de terrain émergent : l'affirmation sur gofmt est jugée « un mensonge » car il ne coupe pas les lignes longues, même en option. Un utilisateur a réécrit tous ses scripts bash en Go et ne le regrette pas ; un autre a obtenu des résultats surprenants en générant du WASM minimaliste en Go après des échecs avec des langages pourtant plus adaptés. Certains notent que les LLM sont excellents pour relire et déboguer du code concurrent, ce qui nuance les craintes. Globalement, la discussion contredit l'article sur son caractère universel : le choix du langage dépend du contexte, et la supériorité de Go pour l'IA n'est étayée que par des anecdotes.
-
Mojo 1.0
Le langage Mojo atteint officiellement la version 1.0, marquant une étape clé depuis sa première sortie en 2023. Cette version vise à offrir une base stable pour les développeurs, avec notamment une simplification de la syntaxe (déclaration unifiée avec var, unification des closures, type Pointer unique), un serveur LSP plus fiable, un support amélioré des lambda de style Python, et une meilleure détection des problèmes de sécurité mémoire. La standard library a reçu près de 200 contributeurs et plus de 1 100 pull requests. Modulaire prévoit d'ouvrir le compilateur et la toolchain en 2026. La version 26.5 de MAX ajoute aussi la prise en charge de nouveaux modèles (GLM-5.2, Nemotron-H) et simplifie l'installation.
Plusieurs commentateurs expriment leur confusion sur le positionnement de Mojo 1.0 : le site officiel ne permet pas de comprendre le problème visé ni l'intérêt par rapport aux alternatives. Une réponse clarifie qu'il s'agit d'un langage natif proche de Python, destiné principalement aux GPU, avec l'ambition de devenir un sur-ensemble de Python. Mais d'autres remarquent que cette promesse de sur-ensemble est en train d'être discrètement abandonnée, comme le montre la roadmap (« Mojo may or may not evolve into a full superset of Python »). Ce revirement est perçu comme un pivot délibéré vers un langage « ère IA » pour la programmation GPU, au détriment de l'attrait initial pour les développeurs Python.
-
London Underground begins scanning passengers' faces
Le métro de Londres commence à scanner les visages des passagers.
Plusieurs commentateurs apportent des précisions factuelles sur le dispositif : il s'agit de stations portables temporaires, pas d'un branchement sur l'ensemble du réseau de CCTV. Un témoin à Victoria rapporte que les policiers ont mal réagi à ses photos et que les panneaux d'information étaient peu visibles. D'autres corrigent l'article sur des points connexes : l'affirmation selon laquelle le FAI partagerait « proactivement » l'historique web est jugée fausse, et le réseau de CCTV britannique est décrit comme beaucoup moins interconnecté que dans les fictions.
Le débat porte surtout sur la portée réelle de cette atteinte à la vie privée. Un avis répandu : le voyage anonyme dans le métro a déjà disparu avec les cartes bancaires sans contact, et la surveillance est une pente glissante déjà bien engagée. En face, certains jugent le concept de « surveillance state » britannique surestimé, rappelant que la police ne contrôle qu'une petite partie des caméras. D'autres encore opposent FaceID, qui traite localement, à la reconnaissance faciale centralisée.
Beaucoup s'inquiètent d'un usage futur contre les manifestants et la dissidence, certains affirmant que ce type de technologie a permis de cibler des opposants en Russie. Un commentateur sceptique se demande quel serait l'échec d'un tel essai. D'autres proposent des parades pratiques (LED infrarouges pour aveugler les caméras, masques, vêtements anti-surveillance), tout en notant les risques juridiques. Globalement, la discussion corrige le titre en montrant qu'il s'agit d'un essai limité, mais elle reste très critique sur les implications.
-
Nvidia's Risky Business
L'article établit un parallèle entre la fièvre ferroviaire du XIXe siècle et l'essor actuel de l'IA. Il rappelle le rôle de Jay Cooke dans le financement du Northern Pacific Railway, qui a conduit à la panique de 1873, et cite le livre 1873 pour souligner que les investissements actuels des grandes entreprises technologiques, comparables à 600 milliards de dollars en 2026, rappellent cette période. Il détaille l'endettement massif d'Oracle, Meta, Alphabet et Amazon (194 milliards de dollars levés en 2026), la hausse des rendements obligataires, et l'annonce par Google d'une levée de 85 milliards de dollars en capitaux propres, avec un investissement de 10 milliards de Berkshire Hathaway.
Ensuite, l'article aborde les difficultés de DeepMind : le départ de Demis Hassabis (devenu président), de Jeff Dean et d'autres chercheurs. SemiAnalysis déclare que DeepMind n'est plus un laboratoire de pointe et que "Gemini est cuit", anticipant une accélération de la croissance de Google Cloud. Le texte s'interrompt au milieu d'une phrase sur les chances de rattrapage de Google.
La discussion prolonge l'analyse de Ben Thompson sur les risques de Nvidia, mais la plupart des commentateurs en nuancent ou contestent certains points. Plusieurs estiment que l'avantage de Nvidia ne tient pas qu'au matériel mais à son écosystème logiciel (CUDA), même si celui-ci est jugé « l'un des pires environnements de développement » : les alternatives comme HIP ou Vulkan seraient encore pires. Ils soulignent que Google limite la diffusion de ses TPU en ne les proposant pas en carte PCIe pour le développement local, ce qui freine l'adoption hors de son cloud. Un commentateur note que l'interconnexion optique des TPU les destine avant tout aux pods distribués, pas aux particuliers.
Plusieurs intervenants s'accordent sur le fait que la demande de calcul existe mais que la croissance annuelle attendue est incertaine. L'un d'eux évoque une baisse de 90 % du coût de calcul pour une même qualité de modèle tous les 18 mois, ce qui rend les prévisions très difficiles : la demande d'inférence pourrait exploser sans que la demande de puces suive, ou l'inverse. Un autre rappelle que les cycles d'investissement finissent toujours par se corriger, et que le « pipe » de revenus de Nvidia pourrait s'effondrer si les dépenses en capital deviennent circulaires. D'autres, au contraire, estiment que l'adoption de l'IA n'en est qu'à ses débuts et que le marché des petites entreprises est encore sous-exploité, citant par exemple les 10 millions d'utilisateurs de Codex comparés au milliard d'utilisateurs de Microsoft Office.
La discussion contredit aussi l'article sur plusieurs points. Un commentateur juge « risible » l'idée que Google soit « cuit » pour l'IA, rappelant que l'entreprise gère une infrastructure massive et pourrait créer un modèle de pointe en quelques semaines sur ses TPU. D'autres soulignent que Nvidia ne dépend pas uniquement des hyperscalers et se tourne vers les consommateurs avec des produits comme le DGX Spark, ce que l'article ignorerait. Les références historiques à la panique de 1873 sont critiquées : un commentateur les juge exagérées, tandis qu'un autre défend l'article en disant qu'il s'agit d'une interprétation nuancée.
-
Grok Bot
Grok Bot est un agent IA de Cursor qui automatise des tâches dans les applications et sites web, y compris les outils difficiles à naviguer. Il exécute des tâches de bout en bout, apprend des routines, collabore avec d'autres bots et travaille 24/7. L'offre est à 200 $/mois, incluant Cursor Ultra.
La discussion salue l'expérience de Grok Bot comme une avancée naturelle après les chatbots et les agents de codage : plusieurs utilisateurs ayant eu accès en avant-première décrivent une interaction fluide avec des bots spécialisés qui possèdent chacun leur propre machine virtuelle, leurs routines et leur domaine, et peuvent communiquer entre eux. L'exécution asynchrone en arrière-plan est jugée concrète et utile, avec des exemples comme la recherche de billets ou la gestion de demandes fournisseurs. Un retour de terrain important nuance l'article : la démo montre le bot saisir des identifiants, mais en pratique il demande à l'utilisateur de se connecter lui-même sur une VM dédiée avant de reprendre la main. Plusieurs commentateurs notent aussi que le coût en tokens est le principal frein, certains ayant consommé plus de tokens en un mois que durant les cinq années précédentes.
Les inquiétudes dominent sur la sécurité et la confiance : vol de données, injection de prompts, accès permanent aux comptes. Un avis répandu est qu'il faut donner aux bots des comptes séparés, voire des cartes de paiement dédiées. La défiance envers Elon Musk et la centralisation des données chez xAI ressort fortement, certains comparant la situation au combat entre Microsoft et l'open source historique. Plusieurs commentateurs soulignent que des solutions open source locales (Hermes, projets personnels) offrent des fonctionnalités similaires sans les risques, mais avec des blocages anti-bot plus fréquents. Un débat oppose ceux qui voient l'intérêt d'un service clé en main avec VM gérées à ceux qui préfèrent des modèles ouverts et remplaçables, notamment pour les agents de codage où l'open source réduit les coûts.
La discussion corrige aussi l'article sur plusieurs points : les bots ont bien une VM toujours allumée, les sessions persistent et les agents peuvent communiquer entre eux via des messages, ce qui va plus loin que les simples "work mode" d'OpenAI ou Antigravity. Le modèle économique est jugé problématique : la tarification par siège profite aux bots qui travaillent 24/7, mais l'expiration du cache et la compaction contextuelle restent non résolues.
-
Apple Silicon and macOS VMs: Faster LLM Inference with llama.cpp
Une couche de compatibilité logicielle (shim) pour les VM macOS basées sur Virtualization.framework modifie les réponses aux requêtes de capacités Metal, permettant à llama.cpp de sélectionner des kernels GPU plus récents. Sur un M1 Ultra, le traitement de prompt de TinyLlama devient 11,08× plus rapide et la génération de tokens 16,36× plus rapide que dans la VM d'origine, avec un débit proche du bare-metal. D'autres tests avec Gemma 4 12B et Muse Glimmer 30B montrent des gains de 7× à 14× selon les métriques.
Le shim, nommé Lume, intervient dans un seul processus invité et ne modifie que deux réponses (Apple family 9, mémoire de threadgroup 64 Ko). Il est publié en licence permissive avec sources, scripts et logs de benchmark. L'article rappelle la différence avec le GPU passthrough VFIO de l'écosystème QEMU/KVM, et note que d'autres front-ends comme Tart sont concernés par cette limite des VM macOS.
La discussion corrige d'abord la portée de l'article : le gain de performance ne concerne pas llama.cpp sur Apple Silicon en général, mais uniquement son exécution dans une VM macOS utilisant Virtualization.framework. L'auteur précise que les chiffres (11,08× en prompt processing, 16,36× en génération de tokens) comparent le même workload dans la même VM Lume, avec et sans un correctif sous forme de bibliothèque dynamique. Le problème vient du fait que la VM expose à llama.cpp des capacités Metal limitées (famille de GPU plus ancienne, 32 Ko de mémoire threadgroup au lieu de 64 Ko), ce qui le pousse à choisir des kernels plus lents. Plusieurs commentateurs soulignent que le titre est trompeur, laissant croire à une accélération générale.
Un point de désaccord ou d'interrogation porte sur les raisons d'Apple : pourquoi Virtualization.framework ne rapporte-t-il pas toutes les capacités du GPU hôte ? Une réponse évoque une impossibilité de virtualisation sûre, tandis qu'un autre se demande si un simple override pourrait contourner le problème. La discussion apporte aussi une précision factuelle sur la signification des « Apple 1-9 » : il s'agit d'une énumération de familles Metal (MTLGPUFamily), et non de puces M1-M9.
En marge, un commentaire ironique sur l'achat de plus de RAM pour exécuter en CPU est ignoré, mais on note un échange sur d'autres startups YC travaillant sur des optimisations ML pour Mac, et un avis plus général sur le rôle d'Apple : la plateforme est jugée formidable malgré des efforts jugés insuffisants, ce qui pousse la communauté à combler les lacunes. Globalement, la discussion valide la technique mais insiste sur le périmètre restreint du correctif et nuance le titre de l'article.
-
Chicken Scheme 6.0
Bref article de Hacker News annonçant la sortie de Chicken Scheme 6.0, une implémentation du langage de programmation Scheme.
La discussion salue largement la sortie de Chicken Scheme 6.0, en particulier le passage complet à R7RS et aux chaînes UTF-8 natives, qui met fin au « jonglage » entre blobs et chaînes. Plusieurs commentateurs apprécient aussi le remplacement des blobs par des bytevectors, l'API process-object et l'optimisation de réutilisation de fermetures. Un utilisateur mentionne le support de Crunch (compilateur pour un sous-ensemble typé statiquement de Scheme R7RS), même si Crunch n'est pas encore en 1.0. Le consensus est que cette mise à jour était attendue et constitue une avancée majeure.
Plusieurs praticiens expliquent leur choix de Chicken face à d'autres Lisps : le compilateur vers C est considéré comme un joyau, produisant un C portable et permettant d'exécuter du Scheme sur des systèmes sans runtime Scheme. L'écosystème des eggs (paquets) est très apprécié, avec des exemples concrets : développement de jeux SDL2, serveurs web, ou encore un wrapper autour de makemkvcon. Le FFI est jugé ergonomique, les messages d'erreur utiles avec pile d'appels, et les définitions de types optionnelles réduisent le nombre de tests. Un utilisateur débutant rapporte qu'il s'attendait à rester sur v5 un moment, mais la sortie de v6 est arrivée plus vite que prévu, ce qui nuance l'idée d'une migration en douceur.
La discussion contient aussi des réserves. Un commentateur oppose la fragmentation de Scheme (multiplicité des SRFI, R7RS non finalisé après 14 ans, dépendances parfois plus complexes qu'en Common Lisp) à l'écosystème plus homogène de Common Lisp. Il critique le manque de documentation des SRFI et l'absence de R7RS-large. D'autres pointent des problèmes pratiques : documentation en ligne souvent indisponible, absence de format hors-ligne complet des eggs, et configuration difficile de chicken-doc sous NixOS. Enfin, un avis minoritaire relève un bug UTF-8 rencontré par le passé, mais l'accueil général reste positif, avec un enthousiasme marqué pour cette version « massive ».
-
Show HN: Scroll through all 43252003274489856000 Rubik's Cube states
Présentation sur Hacker News d'un projet permettant de parcourir les 43 252 003 274 489 856 000 états d'un Rubik's Cube. Aucun détail supplémentaire n'est fourni.
La discussion est globalement enthousiaste : plusieurs commentateurs saluent la visualisation, la trouvent satisfaisante et s'amusent à faire défiler les états. Quelques retours techniques concrets émergent : un bug sur iOS (exception client) signalé, et un problème de mise à jour de la vue lors du changement d'URL, que l'auteur a rapidement corrigé. Plusieurs suggestions sont faites : ajouter une navigation clavier fine, afficher le nombre minimal de mouvements pour résoudre l'état, ou encore trier par distance à la solution. Un commentateur propose d'utiliser un circuit hamiltonien pour que les états adjacents ne diffèrent que d'une rotation, à la manière d'un code de Gray, ce qui rendrait le défilement plus signifiant que l'ordre actuel, visiblement arbitraire.
Le nombre de 43 quintillions est relativisé : un commentateur le trouve « presque concevable » face aux 8×10⁶⁷ possibilités d'un jeu de cartes mélangé, dont le nombre exact se termine bien par des zéros. Certains pensent que c'est un petit nombre vu le peu de pièces du cube, d'autres le jugent immense. Une confusion est dissipée : plusieurs utilisateurs signalent que les centres ne bougent pas dans la vue « FX », mais c'est une propriété réelle du Rubik's Cube, les centres pivotent seulement sur place, ce qui n'est donc pas un bug. Un commentateur note aussi que l'ordre de tri est purement une question de système de coordonnées, sans signification intrinsèque.
En marge, une discussion s'engage sur le lien entre la résolution rapide du cube et les compétences en programmation : l'avis d'un commentateur est que les speedcubers mémorisent des algorithmes et s'entraînent à l'exécution, un ensemble de compétences différent de celui du développeur. Un autre raconte une anecdote sur un casino en ligne avec un Rubik's cube. Quelques comparaisons avec des projets similaires (everyuuid.com) et des blagues (NFT, doom scrolling) animent le fil, mais l'apport principal reste les retours techniques et la mise en perspective combinatoire, sans contredire frontalement l'article.
-
WorldClaw Agentic 3D open-world generation at scale
Le titre annonce WorldClaw, un système de génération agentique de mondes ouverts 3D à grande échelle.
Plusieurs commentateurs corrigent d'emblée l'article : WorldClaw n'est pas un modèle mais un ensemble de scripts Python qui appellent des modèles existants, et le code n'est pas disponible (le dépôt GitHub serait d'ailleurs vide). L'idée jugée la plus intéressante est l'utilisation d'un modèle d'image pour la composition, puis l'extraction des objets en 3D via des outils comme SAM3D avant placement dans le monde. Certains partagent des workflows similaires avec Tripo, Meshy ou Gemini, en conseillant d'utiliser des options low-poly pour éviter des maillages trop lourds.
La discussion diverge sur la qualité des mondes générés. Un avis répandu est que les mondes ouverts les plus réussis (Skyrim, Cyberpunk) reposent sur des détails placés à la main et une narration environnementale, là où la génération procédurale (Starfield) donne des résultats plus fades. Les exemples publiés sont probablement triés sur le volet, avec des artefacts visibles (bâtiments sur l'eau, placement incohérent). Un commentateur estime néanmoins que l'IA progressera vite et que l'avantage du travail manuel ne durera pas. D'autres notent que le style se limite à un rendu cartoony MMO, car les erreurs y sont moins visibles, alors que le réalisme exige un travail d'équipe artistique considérable.
Plusieurs remarques pratiques émergent : les mondes sont pré-générés et non reproductibles sur une machine personnelle ; un commentateur affirme qu'un simple prompt sur Claude permet d'obtenir des résultats similaires, y compris un fichier Blender avec assets, ce qui relativise la nouveauté. La discussion mentionne aussi la mode des noms en « Claw » dans l'écosystème IA. Au final, le fil nuance fortement l'article : l'intérêt technique existe, mais le projet n'est ni un modèle ni open-source, et sa valeur pour les jeux AAA est contestée.
-
More than 10 firms pay up to $100k a month for access to Truth Social posts
Truth Social a lancé début août un service d'accès payant aux publications de son réseau, destiné principalement à des firmes de trading haute fréquence. Les abonnements coûtent entre 60 000 et 100 000 dollars par mois, et plus de dix entreprises y ont recours pour obtenir en avant-première les posts des comptes influents, notamment ceux de Donald Trump.
Cette initiative intervient alors que Trump Media and Technology Group a annoncé une perte de 238 millions de dollars au deuxième trimestre, plus de dix fois supérieure à celle de l'année précédente, principalement à cause de la chute de ses actifs en cryptomonnaies. Le groupe, qui ne réalise pas encore de bénéfices, espère que ce service deviendra une source de revenus « significative » et « durable ». Le projet soulève des questions juridiques et éthiques, car la famille du président reste actionnaire majoritaire et pourrait profiter de ses déclarations publiques.
La discussion HN est quasi unanimement critique : l'article est perçu comme la preuve d'un 'insider trading as a service' et d'une corruption ouverte de la nouvelle administration. Plusieurs commentateurs soulignent que le prix de 100 000 $ par mois est dérisoire par rapport aux gains potentiels, en citant notamment l'exemple d'un post sur les 'bougies vertes' (terme boursier) comme une vantardise de manipulation du marché. Un commentaire note que les entreprises qui paient cherchent moins à accéder aux posts qu'à se rapprocher du président, et que cela revient à une forme de pot-de-vin légalisé.
Certains intervenants tentent de nuancer ou posent des questions de légalité : l'un demande un exemple concret de post enfreignant une loi, ce à quoi un autre répond que la légalité est secondaire face à la corruption morale. Un avis minoritaire compare cette pratique au trading d'informations classique et la juge comme un simple produit logique pour un réseau social détenu par une personnalité influente. D'autres rappellent que le précédent Pelosi a déjà normalisé l'insider trading des élus.
La discussion apporte aussi des corrections factuelles : un commentateur signale que Trump Media a perdu 239 millions de dollars l'an dernier, donc 100 000 $ par mois ne sauvera pas l'entreprise. Un autre remarque que ce système rend la corruption visible et pourrait faciliter d'éventuelles poursuites. Plusieurs commentateurs manifestent leur lassitude et leur pessimisme, tandis que d'autres estiment que cela marque un déclin irréversible des États-Unis.
-
Woman pulled over twice after Flock-linked software connected her to homicide
Amber Newell, conductrice dans le Wisconsin, a été arrêtée deux fois en une semaine après que des caméras Flock ont à tort associé sa voiture à une enquête pour homicide. L'alerte, qui aurait dû être retirée des jours plus tôt, n'a pas été supprimée par un employé de la police de Milwaukee. Les agents de Brookfield ont dégainé leurs armes lors des deux interventions. L'enfant de Newell demande désormais si la police va de nouveau les arrêter. Le chef de la police locale défend ses agents, mais l'incident soulève des questions sur la fiabilité et le suivi des alertes dans ces systèmes automatisés.
La discussion porte moins sur l'anecdote que sur l'attribution des responsabilités. Plusieurs commentateurs estiment que l'erreur vient du système de listes de surveillance alimenté par les forces de l'ordre, et non de Flock lui-même : la donnée de base (un avis de recherche non retiré) est défectueuse, et Flock ne ferait qu'amplifier un problème existant. D'autres, à l'inverse, jugent que Flock vend un outil mal conçu et doit répondre de ses défauts. Un ancien policier s'inquiète d'une dépendance excessive à ces technologies qui pousse les agents à délaisser le travail d'enquête classique. Un commentateur corrige d'ailleurs l'article : les caméras Flock ne se contentent pas de lire les plaques, elles identifient les véhicules par d'autres caractéristiques, même sans plaque.
Plusieurs retours de terrain illustrent les dérives : un homme raconte que son frère, après un vol de plaque, a été arrêté par une dizaine de voitures de police et menacé d'une arme, alors que le signalement ne correspondait pas. Un autre relate un cas similaire dans le Maine, où un véhicule acheté dans la journée a été signalé volé à tort. Plusieurs commentateurs soulignent que le problème n'est pas seulement la fausse alerte, mais la réponse disproportionnée des policiers américains, formés à un usage maximal de la force. Ils réclament des sanctions financières ou disciplinaires réelles pour ces erreurs répétées. Enfin, la qualité de l'article est vivement critiquée : son ton, qui présente ces incidents comme de simples « bugs », est jugé complaisant, et sa conclusion appelant à une simple surveillance humaine est perçue comme une normalisation d'un État policier.
Un courant minoritaire, mais présent, affirme que même un système parfait serait inacceptable : la surveillance de masse porte atteinte à la santé démocratique et au contrat social. Des commentateurs mentionnent la montée d'oppositions concrètes : caméras arrachées, débats dans les conseils municipaux, appels à candidater contre les élus favorables.
-
Nvidia Nemotron 3.5 Lightning and NeMo Switchyard
NVIDIA annonce Nemotron 3.5 Lightning, un modèle ouvert de 30 milliards de paramètres à architecture MoE, conçu pour les tâches spécialisées à fort volume dans les systèmes d'agents IA. Il promet jusqu'à 4x de rapidité en sortie et 30% de complétion de tâches plus rapide que les modèles de sa catégorie, avec une post-formation possible via NeMo. Le modèle est disponible sur Hugging Face, OpenRouter, build.nvidia.com et via des partenaires cloud.
NVIDIA lance aussi NeMo Switchyard, une bibliothèque open source de routage intelligent de requêtes entre modèles (ouverts, propriétaires ou NVIDIA), permettant de choisir automatiquement le modèle le plus efficace selon la tâche. Selon des benchmarks internes, elle maintiendrait une précision de niveau frontière tout en réduisant le coût à près d'un tiers de celui d'un modèle seul. Plusieurs partenaires (Boomi, Cadence, Cognition, LangChain, Ramp, etc.) rapportent des gains de coût ou de latence. Le tout s'inscrit dans une stratégie de systèmes multi-modèles pour des agents autonomes.
La discussion revient d'abord sur des retours de terrain contradictoires avec l'enthousiasme de l'article. Un commentateur travaillant sur Cloudflare OS a testé des modèles ~30B pour générer une appli collaborative : les modèles MoE (dont Nemotron 3.5 Lightning) ont échoué lamentablement, alors que les modèles denses comme Gemma 4-31B ou Qwen 3.6-27B ont réussi. Il note leur vitesse élevée, mais leur piètre qualité sur cette tâche. Un autre intervenant précise que Laguna XS, pourtant cité comme dense, est en fait un MoE. Plusieurs commentateurs s'accordent sur l'intérêt des petits modèles efficaces, certains y voyant une conséquence de la pénurie de RAM et un pari stratégique pour leur entreprise.
Un fil important critique Switchyard sur la gestion du cache de prompts : router chaque requête vers le meilleur modèle casserait la continuité des sessions et le caching. Un répondant renvoie au README du dépôt GitHub, qui le qualifie d'« expérimental, pas pour la production », en contradiction avec le discours commercial. Ils soulignent un compromis difficile entre coût (stickiness) et performance de routage. Un autre commentaire reproche à l'article d'omettre les modèles Qwen dans ses graphiques de comparaison, sauf le Max hors catégorie, ce qui fausse l'analyse. D'autres comparaisons citent Meta Muse Glimmer comme nettement supérieur, mais la discussion note un écart de coût possible.
Enfin, des préoccupations pratiques émergent : la VRAM nécessaire pour faire tourner Nemotron 3.5 Lightning (pas en 16 Go en q4 selon un participant), et un problème de compatibilité avec le NVFP4 sur DGX Spark, pourtant l'architecture cible de ce format. Un utilisateur d'Apple Silicon rapporte un fonctionnement correct mais lent via MLX. L'ensemble nuance fortement l'article : les benchmarks ne reflètent pas les usages réels de coding, la promesse de personnalisation de Switchyard est mise en doute par rapport à un simple LoRA sur un modèle existant, et la fiabilité des petits MoE reste contestée malgré leur attrait.