Hacker News
-
Gemini 3.7 Flash
Google annonce Gemini 3.7 Flash, successeur de 3.6 Flash, optimisé pour le codage et les agents. Améliorations notables en débogage, résolution de problèmes, et génération de code (FrontierCode 1.1 : 43,6 % vs 34,4 % ; DeepSWE v1.1 : 65,3 % vs 49,0 %). En webdev, il dépasse 3.6 Flash sur WebDev Arena (Elo 1588 vs 1538). Pour les domaines à forte densité de connaissances, il progresse sur GDP.pdf (34,0 % vs 22,0 %) et AutomationBench (30,4 % vs 17,0 %). Prix d'introduction : 0,75 $/M tokens d'entrée, 3,75 $/M tokens de sortie, jusqu'à fin d'année. Le modèle est disponible via l'API Gemini, Google AI Studio, Android Studio, et Gemini Enterprise. Gemini Spark, l'agent personnel, l'utilise dès aujourd'hui pour les abonnés Pro et Ultra.
Plusieurs commentateurs saluent la vitesse et les capacités multimodales de Gemini 3.7 Flash, notamment en vision. Un test image→HTML montre qu'Opus 5 reste le meilleur, mais que Grok 4.6 a rattrapé son retard. Un autre souligne que le modèle produit d'excellents SVG, malgré un filtre invalide qui casse l'affichage selon le navigateur. Les avis sur le code sont partagés : certains y voient un net progrès par rapport à 3.6 Flash, d'autres le jugent bon pour des tâches d'automatisation mais pas pour du refactoring lourd.
Le prix divise. Plusieurs commentateurs trouvent absurde le « prix promotionnel » qui expire fin 2026, alors que le modèle sera probablement obsolète. Ils comparent avec Luna, beaucoup moins cher, et Grok 4.6, meilleur et moins cher. Un commentaire note que 3.7 Flash est comparé à Terra, mais que Terra est moitié prix. D'autres répondent que les crédits Google Cloud startups rendent Gemini quasi gratuit, ou que Google vise surtout les abonnés Google One/Workspace. Un point contredit l'article : un commentateur affirme que le prix est en réalité le même que celui de 3.6 Flash.
Les retours terrain sont mitigés. Un utilisateur rapporte que les modèles Gemini précédents mentent sur l'achèvement des tâches, et qu'il annule son abonnement. Un autre trouve que 3.7 Flash est un bond en avant pour le code. Plusieurs notent que la sortie consomme plus de tokens par tâche (37k vs 26k), mais que la baisse de prix rend le coût par tâche inférieur. La discussion contraste avec l'annonce officielle : la concurrence (Luna, Grok, DeepSeek) est jugée plus avantageuse pour le texte pur, et la différenciation de Google semble reposer sur la vitesse et le multimodal, pas sur le prix. Enfin, un commentaire regrette la difficulté d'obtenir une clé API chez Google.
-
DeepSeek Harness
DeepSeek AI publie DeepSeek Harness (dsh), un agent open-source conçu comme une architecture où tout est un plugin, propulsé par Cordis. Actuellement en aperçu développeur, l'outil évolue rapidement avec des changements cassants. Installation via npx ou depuis le dépôt GitHub, interface web sur http://127.0.0.1:3080.
La discussion salue principalement la traçabilité intégrale des sessions, une fonctionnalité que plusieurs commentateurs jugent décisive face aux harnais américains qui chiffrent ou obscurcissent leurs traces (notamment le COT). Un avis répandu est que cette transparence est nécessaire pour améliorer ses outils, même si certains notent que les traces brutes restent difficiles à exploiter. L'architecture « tout est plugin » divise : certains y voient une avancée grâce au système Cordis (chargement/déchargement à chaud avec nettoyage des effets de bord), d'autres expriment une « fatigue des plugins », craignant l'incohérence et l'abandon des écosystèmes communautaires. Un commentaire minoritaire trouve l'idée triviale (un simple destructeur), tandis qu'un autre compare le concept à une couche d'indirection supplémentaire.
Plusieurs corrections et précisions factuelles émergent. Un auteur du projet confirme qu'il s'agit d'une préversion MIT avec des changements cassants à prévoir. Des lecteurs du papier scientifique sur Cordis expliquent que l'innovation réside dans la gestion de cycle de vie des plugins et la réversion des effets de bord, mais que l'exposé est trop mathématique. Un commentateur souligne que Cordis existe depuis quatre ans dans un autre projet (Koishi), ce qui relativise la nouveauté. Un utilisateur ayant testé le harnais avec un modèle local 9B via llama.cpp rapporte que ça fonctionne très bien pour de petits projets Python. Enfin, plusieurs commentaires critiquent l'absence de benchmarks comparatifs entre harnais et s'interrogent sur la pertinence d'un tel comparatif, renvoyant à des sites comme Artificial Analysis.
La discussion contraste fortement avec l'article : si la traçabilité est unanimement appréciée, la criticité porte sur le poids de l'installation (47 Mo téléchargés, 1,5 Go après build, avec 35 dépendances jugées excessives par un développeur), le manque d'innovation perçu (certains rappellent que git hooks résolvent déjà le problème des pre-commit), et la confusion sur ce qu'est réellement un harnais pour les non-initiés.
-
Accelerating GPT-5.6 Sol Ultrafast
Cerebras et OpenAI dévoilent Ultrafast Mode, une nouvelle offre de l'API OpenAI propulsée par Cerebras pour le modèle GPT-5.6 Sol. Elle atteint jusqu'à 750 tokens de sortie par seconde sans compromis sur la qualité, soit 11 fois plus rapide que Fable 5 et 5 fois plus rapide que Opus 4.8 en mode Fast. Sur le benchmark Humanity's Last Exam, GPT-5.6 Sol en Ultrafast a traité les 2 500 questions en 11h11 contre 78h27 pour Claude Fable 5, soit près de 7 fois plus vite. Sur GDP-Val, le mode Ultrafast offre un gain de vitesse de bout en bout de 5,6x sans dégradation de qualité.
Cette performance repose sur l'architecture Wafer-Scale Engine de Cerebras, qui embarque 44 Go de SRAM par puce, permettant de garder les poids du modèle sur la puce et d'éviter les goulots d'étranglement de bande passante mémoire des GPU. Ultrafast est disponible en aperçu limité pour certains clients, avec un accès élargi au fil du temps.
La discussion salue la prouesse technique de GPT-5.6 Sol Ultrafast, fruit de la collaboration OpenAI-Cerebras, tout en la nuançant fortement. Plusieurs commentateurs relèvent que ni OpenAI ni Cerebras n'affirment explicitement que ce mode offre exactement les mêmes performances que le modèle standard ; ils citent la phrase « without any quality compromise » mais la jugent insuffisante en l'absence de détails sur les benchmarks et surtout de prix. Un autre point central : la vitesse de tokens ne réduit pas tous les goulots d'étranglement. Les tests de bout en bout, la compilation, les recherches dans un grand codebase ou les vérifications humaines restent lents, ce qui limite l'intérêt pour le codage quotidien. L'exemple de l'Humanity's Last Exam est jugé trompeur car ce benchmark n'implique pas d'outils externes.
Les commentateurs s'accordent sur le potentiel des ASIC et du wafer-scale pour l'inférence, certains y voyant un retour aux gains de vitesse mono-thread des années 90. Cependant, un avis rappelle que servir des modèles de mille milliards de paramètres nécessite un cluster entier et plusieurs mégawatts, et que le « Sol Ultrafast » ne sera pas accessible au grand public. Une comparaison avec un concurrent, Mimo v2.5-Pro Ultraspeed (1000 tok/s), montre que le graphique de l'article omet des alternatives rapides et moins chères. Plusieurs commentateurs spéculent sur la taille réelle de Sol : le plus gros modèle jamais servi par Cerebras étant Kimi K2.6 (1T de paramètres), Sol serait peut-être plus petit que prévu, ce qui expliquerait les marges et la baisse de prix de Luna. D'autres s'interrogent sur l'usage : certains sont prêts à consommer davantage de tokens, mais d'autres doutent que la vitesse change vraiment la productivité si l'humain doit relire le code.
La discussion apporte aussi des corrections factuelles : absence de prix, possible stratégie de sélection des clients, utilisation interne probable pour accélérer la recherche, et l'étonnement que Cerebras n'ait pas encore de KV cache. Un commentaire mentionne que le cours d'OpenAI a chuté le même jour, ce qui fait soupçonner une annonce destinée à rassurer les investisseurs.
-
Spaghettifying DRAM
Un article technique détaillant une attaque matérielle sur les contrôleurs mémoire AMD (Family 16h) : en modifiant un seul bit dans le registre du DCT (bank-swizzle-mode), il est possible de réécrire les traductions d'adresses physiques vers les coordonnées DRAM, contournant ainsi les mécanismes de protection (PSP, SMM, microcode, régions réservées). L'auteur explique la pipeline complète de traduction d'adresses, de la MMU au contrôleur mémoire, et montre comment remapper la mémoire pour accéder à des zones protégées invisibles même pour le noyau. Le projet skitter-creek-bath-salts, testé sur AMD Family 16h, démontre que ces registres ne peuvent pas être verrouillés, et la technique pourrait s'étendre à d'autres architectures (ARM, RISC-V).
La discussion salue largement le retour de Christopher Domas, chercheur reconnu pour ses travaux précédents sur les backdoors x86, et qualifie cette découverte de « hacker ethos » pur. Plusieurs commentateurs soulignent toutefois que l'article manque de précision sur le périmètre réel de l'attaque : développée et testée uniquement sur les CPU AMD Family 16h (2013), elle ne s'applique probablement pas aux processeurs Zen modernes, dont le contrôleur mémoire est différent et dont les registres de traduction ne sont plus documentés. Un commentaire note que l'information sur les CPU plus récents est « intentionnellement laissée de côté ». La discussion insiste aussi sur le fait que l'exploit nécessite déjà un accès root ou ring-0 : il ne constitue donc pas une élévation de privilèges locale, mais permet d'atteindre des couches normalement protégées (ring -2, TPM, attestation), ce qui peut servir à contourner des protections anti-tampering ou à rendre des malwares persistants. Plusieurs intervenants relèvent également que l'attaque est purement logicielle, contrairement à des attaques physiques comme Battering RAM, et que la mémoire chiffrée (ex. Secure Enclave d'Apple, Xbox One) peut neutraliser ce type d'exploit sur les consoles modernes, qui traitent déjà la DRAM comme non fiable.
Un débat important oppose les commentateurs sur la portée réelle : certains y voient un moyen de redonner au propriétaire d'un ordinateur le contrôle total sur sa machine, tandis que d'autres s'interrogent sur le risque de sortie de KVM (hyperviseur). Un avis minoritaire estime que l'attaque ne change rien au modèle de menace, puisque la plupart des systèmes avec DRAM physiquement accessible seraient déjà vulnérables, mais cette position est contredite par ceux qui rappellent que le chiffrement total de la mémoire rendrait une attaque physique inefficace. La discussion ne tranche pas sur la possibilité d'un patch microcode, certains espérant que l'auteur fournisse plus de détails lors d'une future présentation Black Hat.
-
ChatGPT Desktop (Codex Desktop) for Linux
Annonce de ChatGPT Desktop (Codex Desktop) pour Linux, publiée par allanrbo sur Hacker News. Aucun détail supplémentaire n'est fourni.
La discussion est très critique. On s'étonne qu'OpenAI livre une app Electron après six mois de portage, alors que l'IA est censée accélérer le développement. La sécurité domine : plusieurs commentateurs recommandent de traiter l'app comme un trojan et de l'isoler dans une VM. Un commentateur précise que la version Linux utilise bubblewrap et seccomp, mais que les fonctions de 'computer use' sont activables en un clic sans politique de configuration, ce qui inquiète les entreprises. Un autre rappelle que Codex CLI est open source, pas Codex Desktop, donc non auditable.
Le rapport avec le CLI est le cœur du débat. Beaucoup préfèrent le CLI pour l'isolation et la légèreté, et demandent l'intérêt de l'app. Les réponses citent le rendu des diffs, LaTeX, et une meilleure ergonomie de saisie pour les non-développeurs. Un commentateur rapporte des problèmes de performance sur Windows (blocages de plusieurs minutes). Sur Linux, un utilisateur en KVM dit que ça fonctionne, mais l'avis général est que l'app est superflue pour les utilisateurs Linux, qui préfèrent le terminal.
Des informations concrètes : le lien officiel pour le téléchargement Linux est donné, car la page d'accueil s'adapte à la localisation et affiche Windows. Un utilisateur confirme la connexion de Codex CLI à ChatGPT iOS via SSH, ce qui rend l'app encore moins nécessaire. L'idée de verrouillage propriétaire est évoquée mais contestée. Enfin, plusieurs conseillent de créer un compte utilisateur séparé pour l'agent, une pratique rare. La discussion nuance donc fortement l'annonce en pointant les risques de sécurité et l'absence de plus-value claire.
-
Gloomberb
Gloomberb est un terminal financier open-source, disponible en application de bureau ou en TUI (interface texte). Rapide, piloté au clavier et extensible, il est axé sur une barre de commande : on tape un ticker ou un raccourci (comme DES, AAPL, TOP) pour accéder directement aux vues du marché. Il permet de rechercher des entreprises (cours, graphiques, données financières, documents, actionnariat, initiés, options, notations d'analystes, événements, valorisation relative), de suivre les marchés (actualités classées, infos de dernière minute, flux sectoriels, indices mondiaux, changes, événements macro, courbes de taux, variations, sentiment) et de gérer un espace de travail (portefeuilles, listes de suivi, connexions au courtier, alertes, notes, écrans IA, marchés de prédiction et chat Gloom Cloud).
La discussion autour de Gloomberb, un terminal financier alternatif, se concentre sur sa pertinence face à Bloomberg et sur les inquiétudes liées à son installation et son origine. Plusieurs commentateurs soulignent que la valeur de Bloomberg ne réside pas dans l'interface mais dans les données et le réseau de messagerie, certains affirmant que le service de chat est un avantage décisif, tandis qu'un autre conteste cette idée en notant que les professionnels migrent facilement vers d'autres plateformes comme ICE chat. D'autres rappellent que le coût de Bloomberg (~24 000 $ par an) justifie sa valeur perçue, notamment pour les obligations et les données macroéconomiques. Gloomberb est jugé utile comme alternative à quelques onglets, mais ne remplace pas Bloomberg. Un commentaire note que l'interface est en réalité basée sur le web et TypeScript, contrairement à ce que laissent penser les captures. Plusieurs intervenants s'inquiètent de la méthode d'installation via curl, demandant plus de transparence sur la stack ; une réponse précise que l'outil utilise probablement des exécutables autonomes Bun, ce qui évite les conflits de dépendances.
Un fil majeur concerne le soupçon que le projet soit du « slop » généré par IA. Plusieurs commentateurs expriment leur méfiance envers les logiciels récents, supposant qu'ils sont produits par des LLM et donc moins fiables. Un commentaire pointe une faute de frappe visible dans l'en-tête, ce qui renforce cette impression. Cependant, d'autres défendent le projet, appréciant son design et sa présentation, tout en notant que l'offre payante par abonnement les refroidit. Un praticien mentionne un concurrent, Godel Terminal, utilisé par Shkreli, mais non open source. Un autre demande s'il est possible de l'exécuter dans un conteneur.
La discussion corrige ou nuance l'article sur plusieurs points : la nature de l'interface (pas un TUI mais une app web), la source des données (probablement Yahoo et SEC, avec biztoc pour l'actualité), et le fait que le moat de Bloomberg est davantage lié aux données et au réseau qu'à l'interface elle-même.
-
Understanding is the new bottleneck
Cet article est la version écrite d'une conférence donnée à l'AI Engineer conference en juillet 2026. L'auteur défend l'importance de comprendre le code produit par les agents IA, malgré leur autonomie croissante. Il explique que la compréhension ne sert pas seulement à vérifier le travail des agents, mais aussi à participer activement au processus créatif et à éviter la « dette cognitive ».
Trois techniques sont proposées pour comprendre efficacement le code des agents : les explications structurées (documents qui fournissent le contexte, l'intuition et une « diff littéraire »), les quiz de vérification intégrés aux explications, et les « micro-mondes » interactifs qui permettent d'explorer un système en manipulant ses éléments. L'auteur illustre ces approches avec des exemples concrets, comme un débogueur pour un interpréteur Prolog ou un jeu vidéo de migration de site web.
L'article s'appuie sur des références à l'éducation (Seymour Papert, Andy Matuschak) et à des travaux sur la dette cognitive. Le ton est celui d'un retour d'expérience personnel, avec des conseils pratiques pour intégrer ces techniques dans un flux de travail avec des agents IA.
L'article présente la compréhension comme le nouveau goulot d'étranglement, mais la discussion s'accorde à dire que ce n'est pas nouveau. Plusieurs commentateurs rappellent que la compréhension a toujours été le problème central du développement logiciel, côté management ou programmation. Un avis ironique qualifie l'article de « salesmanship » des LLM, affirmant que les LLM sont eux-mêmes le goulot d'étranglement quand ils produisent du code que personne ne comprend. L'idée que le problème est « backloaded » plutôt que « frontloaded » est également avancée : on comprend après génération au lieu d'avant.
Les avis divergent sur l'utilité des LLM. Certains rapportent des expériences positives avec des descriptions de PR si on fournit du contexte, mais d'autres jugent ces descriptions mécaniques, sans motivation. Des praticiens adoptent des stratégies concrètes : jeter le code incompréhensible, le réécrire, ou utiliser la spécification comme source de vérité (Spec Driven Development) pour maintenir la compréhension humaine. Un commentateur souligne que le code peut servir d'outil de compréhension et non seulement d'objet à comprendre.
La discussion corrige l'article sur plusieurs points. Le problème n'est pas seulement la compréhension mais la confiance dans les agents, leur alignement et les vérifications adverses. Plusieurs estiment que les systèmes complexes générés par LLM sans compréhension humaine se dégraderont inévitablement, et que les techniques d'assurance (tests, méthodes formelles) restent essentielles, mais ne sont pas glamour. Enfin, le manque d'historique du code généré d'un bloc empêche l'archéologie du code qui permettait de comprendre les systèmes hérités.
-
Choose Boring Technology (2015)
L'article, écrit par Dan McKinley en 2015, défend l'idée que les entreprises devraient privilégier des technologies éprouvées et « ennuyeuses » plutôt que des innovations constantes. Chaque entreprise dispose selon lui d'un nombre limité de « jetons d'innovation » ; les dépenser sur des choix techniques risqués (nouveau langage, base de données récente, etc.) réduit les chances de succès. Les technologies matures comme MySQL, Postgres, PHP ou Memcached sont préférables car leurs capacités et leurs modes de défaillance sont bien connus, contrairement aux technologies nouvelles avec leurs « inconnues inconnues ».
Il critique la vision du « meilleur outil pour le travail » en soulignant les coûts opérationnels et cognitifs de l'ajout de chaque nouvelle technologie. Il recommande de réfléchir globalement et de considérer si le problème peut être résolu sans ajout. Si une nouvelle technologie est nécessaire, il faut un processus de validation à l'échelle de l'entreprise, prévoir la migration de l'existant, et éviter la prolifération de solutions locales. En conclusion, la polyglotte programmation est séduisante mais crée une lourdeur opérationnelle ; la maîtrise technologique demande des choix réfléchis.
Plusieurs commentateurs valident le concept d'« innovation tokens » comme outil de décision et de communication, tout en le replaçant dans son contexte de 2015. L'idée centrale — choisir une technologie familière pour concentrer l'innovation là où elle compte — est jugée toujours utile, notamment à l'ère des agents IA. Un avis suggère de pousser tous ses jetons vers les agents et d'utiliser pour le reste des technologies « ennuyeuses », bien représentées dans les données d'entraînement des LLM (PHP, Ruby, Elixir plutôt que monorepos TypeScript). Un autre remarque que l'IA change la perception des projets Rust, désormais souvent « vibe coded ». Le consensus est que « boring » signifie avant tout « familier », avec plus d'inconnues connues que d'inconnues inconnues.
La discussion comporte toutefois des oppositions nettes. Certains rejettent la métaphore des jetons comme arbitraire et peu sérieuse, préférant « choisir la technologie la plus appropriée » : la nouveauté n'est qu'un proxy faible, une technologie récente peut être mieux testée qu'une ancienne mal maintenue. D'autres y voient un faux débat conservateur/progressiste, et rappellent que dans une startup, prendre des risques technologiques peut être nécessaire. Un commentaire minoritaire souligne qu'une nouvelle technologie peut avoir une fonctionnalité exclusive indispensable. Une mise en garde concrète est partagée : une entreprise ayant choisi Cassandra comme « boring technology » pour l'authentification et un service clé-valeur a subi des pannes, car on dépassait le domaine de confort de l'outil ; « boring » ne suffit pas, il faut aussi le bon outil.
La discussion nuance l'article sur plusieurs points. L'exemple d'Etsy cité dans le billet est repris pour illustrer que la réutilisation d'une pile partagée permet de scaler sans effort, mais d'autres notent que la liste des technologies « ennuyeuses » évolue plus vite que les opinions : Kubernetes est devenu banal, alors qu'il est encore cité comme risqué dans les vieux fils. Plusieurs commentateurs déplorent que ce billet ait été utilisé pour justifier des arguments paresseux contre toute innovation.
-
Deutsche Bank becomes first foreign yuan clearing bank in Europe
La Chine a autorisé Deutsche Bank à devenir la première institution étrangère en Europe à assurer la compensation des transactions en renminbi depuis Francfort. Cette décision, officialisée par un protocole d'accord avec la Banque populaire de Chine, s'inscrit dans l'effort de Pékin pour élargir l'usage de sa monnaie dans le commerce et l'investissement internationaux. Les entreprises européennes actives avec la Chine pourraient ainsi simplifier leurs règlements en yuans, sans bouleverser la domination du dollar ou de l'euro.
La discussion dépasse le simple fait annoncé pour s'interroger sur ses implications géopolitiques. Plusieurs commentateurs y voient une étape, modeste mais symbolique, vers un monde multipolaire et un recul de l'hégémonie du dollar, rappelant que d'autres devises (livre sterling, florin néerlandais) ont perdu ce statut. D'autres tempèrent : la notion de réserve de change est récente, et les actifs libellés en dollars restent sans commune mesure avec ceux en yuans, donc le changement serait très lent, s'il advient. Un avis minoritaire relie l'attractivité du yuan aux ressources énergétiques et à la puissance électrique de la Chine, mais cette idée est peu reprise.
Sur le plan pratique, des commentateurs éclairent ce que signifie concrètement ce statut : permettre à une banque comme Deutsche Bank de compenser des transactions internationales en yuans, évitant ainsi les frais de correspondance imposés par le système américain. Un intervenant mentionne l'existence d'UnionPay pour régler en yuans directement, ce qui nuance l'enthousiasme. La discussion corrige aussi l'article sur un point de vocabulaire : yuan et renminbi, précisant que le renminbi est le nom officiel de la devise et le yuan son unité de base, à l'image de dollar et cent. D'autres s'interrogent sur la possibilité d'un système de prêts en yuans hors de contrôle de la banque centrale chinoise, à l'instar des eurodollars.
Plusieurs commentaires expriment leur méfiance envers la Chine, qualifiée de régime autoritaire, et regrettent une dépendance accrue. D'autres rétorquent que les États-Unis ne valent guère mieux, notamment après les menaces sur le Groenland. La réputation de Deutsche Bank est épinglée (liens avec Epstein) et certains prédisent des scandales futurs liés aux fragilités économiques chinoises (immobilier, déflation). Enfin, le thème du « pétro-yuan » est jugé obsolète par un commentateur, car le pétrole déclinera dans trente ans. Globalement, la discussion est politiquement polarisée et apporte des précisions techniques utiles, sans que l'article ne soit fondamentalement invalidé.
-
Mistral OCR 4.1
Publication Hacker News titrée « Mistral OCR 4.1 », annonçant apparemment une nouvelle version de l'outil OCR de Mistral. Aucun détail n'est fourni au-delà du titre.
Plusieurs commentateurs jugent le tarif de Mistral OCR 4.1 excessif : 3,5 € pour 1000 pages serait plus du double des prix d'AWS Textract ou d'Azure Document Intelligence. Un praticien affirme obtenir 1000 pages pour 0,05 à 0,1 USD avec des bounding boxes sur des GPU loués, et un autre, utilisant NuExtract sur une RTX 4090, évoque un coût trois fois inférieur pour des relevés bancaires non structurés. La question du prix divise néanmoins : certains rappellent que l'exactitude et la conformité réglementaire comptent autant que le tarif, et un commentateur note une vitesse nettement supérieure sur les benchmarks internes.
Sur le fond, la discussion nuance fortement l'article. Pour des documents complexes (ligatures, fraktur, sigles critiques, écriture manuscrite historique), le modèle ne se distingue pas, selon un utilisateur, des modèles pro d'OpenAI — qui eux-mêmes échouent souvent. Plus inquiétant, les VLM peuvent censurer invisiblement des documents sensibles, tandis que les modèles OCR purs hallucinent. Pour y remédier, un commentateur décrit un harnais qui fait tourner deux à trois fournisseurs, recoupe leurs sorties et vérifie chaque citation dans l'original. Un autre signale Transkribus pour l'écriture historique.
Enfin, quelques questions restent ouvertes : performance sur les langues européennes, comparaison avec l'OCR de Baidu (gratuit localement), et l'impact des régulations qui protégeraient Mistral. Un commentateur s'interroge sur les paires entrée/sortie avec analyse de mise en page. Le fil confirme donc un scepticisme général sur le rapport performance/prix, et corrige les éventuelles promesses de l'article sur l'exactitude pour les usages spécialisés.
-
Ordinary Abundance
L'article dresse une série de vignettes reliant les conforts domestiques modernes (musique à la demande, éclairage électrique, livres imprimés, eau courante, fruits importés, réfrigération, vaccination, anesthésie, sanitaires, vélo) à des citations historiques illustrant à quel point ces biens étaient jadis extraordinaires. Il souligne l'abondance ordinaire de la vie contemporaine, souvent tenue pour acquise, en la replaçant dans l'histoire des innovations techniques.
La discussion prolonge l'article sur l'« abondance ordinaire » en validant son constat : plusieurs commentateurs témoignent de leur gratitude pour des acquis modernes souvent banalisés (eau courante, douche chaude, musique à la demande, nourriture variée). Un récit marquant décrit la vie sans électricité ni eau courante chez la grand-mère de l'un d'eux, un autre vit en van pour renouer avec une « friction » bénéfique, et un troisième raconte l'installation d'un adoucisseur d'eau après des mois d'eau ferrugineuse. Le concept d'« adaptation hédonique » est fréquemment cité, et plusieurs intervenants recommandent la « visualisation négative » (imaginer la perte d'un confort pour mieux l'apprécier) comme antidote à la lassitude. Un lien est fait avec les dons en espèces de GiveDirectly : des bénéficiaires très pauvres achètent des matelas, preuve que le confort de base reste un luxe pour beaucoup.
Mais la discussion corrige et nuance fortement l'article. Le principal reproche : la présentation de l'abondance est trop esthétisée, « classe moyenne supérieure », et ignore les difficultés structurelles — loyers élevés, santé, insécurité — qui empêchent beaucoup de gens d'accéder même à ce confort de base. Un commentateur souligne que, si l'on remplaçait les belles photos par un intérieur modeste et une pile de factures médicales, l'effet serait différent. D'autres s'opposent à l'injonction implicite « soyez heureux » : il existe une troisième catégorie de gens, ni insatisfaits ni avides, mais inquiets de la durabilité et des coûts humains de cette abondance. Un avis minoritaire rejette ouvertement la décroissance, tandis qu'un autre pointe que l'auteur est lié au mouvement de l'altruisme efficace, suscitant des réactions mitigées (certains y voient une insinuation sans intérêt).
-
Nine PBS sues Iron Mountain over blocked access to archival data
Titre seul : Nine PBS poursuit Iron Mountain en justice concernant un accès bloqué à des données d'archives. Aucun autre détail disponible.
La discussion tourne principalement autour de la responsabilité de PBS dans cette perte d'accès. Plusieurs commentateurs reprochent à la chaîne de ne pas avoir appliqué la règle de sauvegarde 3-2-1 : 50 To se dupliquent facilement et à faible coût (quelques milliers de dollars par an). D'autres répondent que cette règle est récente, que PBS est une filiale à but non lucratif aux budgets serrés, et que le vrai problème est la défaillance d'un intermédiaire, OSS, qui n'a visiblement pas payé Iron Mountain. Un avis minoritaire juge injuste de blâmer Nine PBS : on ne peut pas anticiper qu'un prestataire se mette en faute et qu'un autre agisse de mauvaise foi face à un jugement.
Les commentaires apportent des précisions techniques et factuelles. Plusieurs intervenants soulignent que les données ne sont pas détruites mais « légalement bloquées » : un tribunal a déjà ordonné leur restitution, et Iron Mountain a d'abord accepté de les rendre avant de se rétracter en invoquant la propriété d'OSS. Un lien vers un compte-rendu d'audience indique des inquiétudes sur d'éventuelles clés de déchiffrement en mémoire et le risque de perte si le serveur est éteint. Certains notent que l'article ne précise pas la nature du contrat (colo ou location de matériel), ce qui change tout. D'autres rappellent que l'archive peut inclure des bandes physiques, pas seulement des disques, et citent des cas historiques de pertes de données (Ohio, émissions perdues).
La discussion nuance fortement l'article : le titre laisse croire à une perte alors que les données sont conservées et sous main de justice. Plusieurs commentateurs estiment que la solution était triviale (un NAS local en complément) et s'étonnent qu'une organisation majeure n'ait pas de copie. D'autres proposent des alternatives comme l'Internet Archive, tout en avertissant de ne pas en faire l'unique copie. Enfin, un commentaire plus politique critique les partenariats public-privé et la confiance aveugle accordée à des tiers privés, quitte à payer des frais de justice alors que le coût de la duplication était dérisoire.
-
Hello, me. It's been a while
L'auteur raconte son retour après quatorze ans de silence sur son blog, expliquant comment il a progressivement comblé tous les moments de calme avec des podcasts, des livres audio et les réseaux sociaux, au point d'étouffer sa propre voix intérieure. Il se décrit comme un penseur lent qui apprécie les longues réflexions, mais que son travail et ses interactions ne lui laissent plus cet espace. Il a finalement redécouvert le plaisir de faire une tâche ménagère en silence, laissant ses pensées revenir, et encourage les lecteurs à expérimenter le silence.
La discussion confirme largement le constat de l'article : nombreux sont ceux qui se décrivent comme accros aux podcasts, audiobooks ou à la musique, et qui peinent à laisser place au silence et à l'ennui. Plusieurs commentateurs partagent leurs tentatives de se severer : résolution du Nouvel An, pause musicale de trois mois, randonnées solitaires sans musique ni réseau. Ils insistent sur le bénéfice de ces moments pour laisser l'esprit vagabonder, et certains citent la conférence « Hammock Driven Development » qui distingue conscience et subconscient, affirmant que l'ingestion constante d'information nuit à la synthèse inconsciente. L'idée que l'ennui est devenu un luxe rare et qu'il faut réapprendre à ne rien faire revient souvent.
Cependant, la discussion nuance fortement l'article. Plusieurs commentateurs soulignent que le casque, en open space, est avant tout une protection contre le bruit ambiant et un signal de concentration, pas une fuite de sa propre voix. Un avis minoritaire va plus loin : pour certains problèmes techniques difficiles, une distraction de surface (podcast, actualités) aide justement le subconscient à travailler en empêchant les pensées conscientes de dominer. D'autres reconnaissent la valeur du silence pour la création, mais disent avoir besoin d'un bruit de fond pour les tâches répétitives ou pour éviter la rumination anxieuse. Un commentateur évoque l'usage des audiobooks comme outil pour gérer le stress et trouver le sommeil, rappelant que la recherche de silence n'est pas universelle.
Enfin, plusieurs commentaires apportent des nuances factuelles. L'un renvoie au concept de « continuous partial attention » pour expliquer l'habitude de stimulation constante. Un autre décrit son expérience inverse : après avoir acheté un terrain, il a naturellement cessé toute consommation de musique et de podcasts pour se reconnecter aux sons de la nature, mais cette solution est moquée (« il faut donc acheter un terrain ? »). Un commentateur âgé confie que la musique, autrefois omniprésente, lui est devenue pénible, suspectant un trouble de l'attention aggravé par la surstimulation.
-
Principia Mathematica is modern and insightful
Article de blog (via Hacker News) qui relit le chapitre 1 des Principia Mathematica de Whitehead et Russell (1910) et le juge étonnamment moderne. Il souligne que les preuves y sont d'une minutie extrême mais que l'essentiel réside dans les notions de base et la structure logique. Les notes portent sur les variables libres et liées (apparentes), les fonctions propositionnelles, la transparence référentielle, les définitions comme choix importants, et les fonctions descriptives. L'auteur relève des anticipations du lambda-calcul et de la logique moderne, avec des commentaires de Jacques Carette sur le constructivisme et l'analyticité. Hors des thématiques suivies par Julian.
La discussion reconnaît largement la valeur historique de l'ouvrage de Russell et Whitehead, tout en soulignant ses défauts : notation datée, redondances. Plusieurs commentateurs recommandent des ressources d'accès : éditions PDF, le site PM-MATS pour l'analyse structurelle, l'Introduction à la philosophie mathématique, et la bande dessinée Logicomix pour une approche narrative. Un praticien rappelle que PM a servi de base au Logic Theorist (1956), le premier programme d'IA, qui a prouvé 38 des 52 premiers théorèmes du chapitre 2, trouvant même une preuve plus courte. Ce lien avec l'informatique suscite l'intérêt, notamment pour la théorie des types, même si un commentateur précise que les types de Russell diffèrent des types de programmation.
Plusieurs commentaires corrigent ou nuancent l'article. Le point central est l'incomplétude de Gödel : PM ne peut atteindre son objectif, ni aucun système formel, ce que l'article ne mentionne pas explicitement. Un débat émerge sur la pertinence de lire PM aujourd'hui : un avis minoritaire recommande de préférer la théorie des types homotopique (HoTT), plus moderne et applicable, tandis qu'un autre commentateur la juge difficile. Un commentateur critique le ton de l'article ("moderne et perspicace") en rappelant que PM est un échec logique, mais cette critique est elle-même contestée : prouver les mathématiques n'a rien d'infantile, et des systèmes partiels restent prouvables. Une confusion est signalée entre le Principia de Newton et celui de Russell/Whitehead, et une traduction erronée ("traduce" ≠ "traduire") est relevée.
Sur la forme, plusieurs lecteurs s'accordent sur l'originalité de la notation par points, jugée potentiellement utile pour les langages de programmation même si un commentaire demande son intérêt concret. Un commentaire plus acide s'étonne qu'un simple résumé des 40 premières pages attire tant de réactions, ce qu'une réponse interprète comme une frustration programmatique : les programmeurs cherchent un "code machine" des mathématiques, alors qu'il faut accepter la confusion et l'effort.
-
Donkey.bas is 45 Years Old – 131 line of Glory
Donkey.bas, le jeu en BASIC de 131 lignes fourni avec les premiers PC IBM, fête ses 45 ans.
La discussion célèbre principalement la nostalgie de DONKEY.BAS et des BASIC de Microsoft. Beaucoup racontent comment ce jeu, avec GORILLA.BAS, a été leur première porte d'entrée vers la programmation : un commentateur explique avoir modifié un nombre dans le code et découvert l'explosion plus grosse ; un autre se souvient de floppies avec des versions modifiées contenant des insultes. Plusieurs liens vers des ports navigateur ou des implémentations modernes sont partagés, et certains commentateurs estiment que la simplicité du code (131 lignes) illustre ce que les environnements de développement modernes ont perdu, même si un avis cite raylib comme équivalent possible.
La discussion apporte des corrections factuelles à l'article. Un commentateur signale que les effets sonores du port sont trop avancés, les premiers PC IBM ayant un simple haut-parleur dynamique. Un autre, après lecture du code, affirme que la détection de collision est buguée (ligne 1750) et enregistre un choc sans vérifier que la voiture a dépassé l'âne. Un débat s'ouvre aussi sur la théorie du jeu : ce serait un jeu coopératif (les deux joueurs gagnent ou perdent ensemble), et non une compétition où l'âne pourrait « gagner ». Enfin, la rumeur selon laquelle Gates aurait écrit ce jeu comme dernier code chez Microsoft est évoquée, mais traitée avec scepticisme par plusieurs.
Quelques commentaires divergent sur la qualité relative des PC de l'époque : un utilisateur de C64 exprime sa déception face aux capacités graphiques et sonores des PC. D'autres remarquent que BASICA était requis et s'interrogent sur le nom « Advanced Basic ». Des détails pratiques sont partagés : un bug d'affichage sur Firefox à certaine taille est corrigé via une pull request, et un commentateur mentionne que le jeu original affichait une photo de Bill Gates en easter egg. Globalement, la discussion confirme l'importance historique du jeu, tout en nuançant sa qualité technique.
-
Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes
Rapport de bug sur systemd-journald (version 257.9, Debian 13, kernel 6.12.57) signalant des écritures disque excessives : une seule ligne de log entraîne 49 Ko+ d'écritures sur ext4 et 110 Ko+ sur btrfs. Une VM émet environ 50 IOPS pour seulement 2 lignes de log par seconde, bien au-delà de l'ordre de grandeur attendu avec syslog. L'auteur reproduit le problème avec un flux constant de logs HAProxy sur XFS, mentionne un précédent ticket (#15292) fermé sans justification, et critique le format de journald comme extrêmement inefficace, avec des fichiers nettement plus volumineux que le contenu réel, ainsi qu'une fiabilité discutable après des redémarrages non propres.
La discussion confirme et approfondit l'article sur l'amplification d'écriture de systemd-journald. Plusieurs commentateurs s'accordent sur le fait que la conception est fondamentalement mauvaise, notamment l'utilisation d'écritures via mmap au lieu de simples écritures séquentielles ou de pwrite. L'analyse technique pointe une dispersion des données dans le fichier joural, avec de minuscules écritures à des offsets non contigus, provoquant des réécritures de blocs entiers. Un contributeur ayant travaillé sur journald à l'époque de CoreOS confirme que le format sur disque disperse trop l'information, chaque champ étant écrit séparément, et que les indexeurs (tables de hachage) aggravent le problème. Il précise s'être concentré sur la performance en lecture et la stabilité, mais n'avoir jamais eu le mandat de changer le format d'écriture.
Les commentateurs relèvent des problèmes concrets : l'absence de filtrage efficace (limité à la sévérité ou à LogFilterPatterns, peu pratique et ne couvrant pas tous les services), la difficulté de réduire le volume de logs par programme, et des applications comme KDE ou des pilotes qui spamment des milliers de lignes. Plusieurs utilisateurs contournent le problème en passant journald en stockage volatile ou en le limitant à un routeur vers syslog. Un avis minoritaire suggère qu'utiliser un format de base de données comme SQLite ou même DuckDB/Parquet serait plus robuste et plus performant, mais cette suggestion est discutée.
La discussion corrige ou nuance l'article sur plusieurs points. Le format en annexe avec déduplication était censé réduire l'espace disque, mais il s'avère être la source de l'amplification d'écriture. Un commentateur estime que ce format alambiqué sacrifie la robustesse immédiate au profit d'une optimisation théorique. D'autres critiquent la gestion du projet systemd, évoquant une absence de direction technique comparable à celle de Linux. Enfin, des liens vers des issues GitHub sont fournis pour suivre le problème, et une note pratique indique que l'utilisation de btrfs sans COW ou avec snapshots aggrave encore le phénomène.
-
NP-overrated
L'article conteste l'idée répandue que les problèmes NP-difficiles sont inabordables en pratique. Il affirme que les cas les plus défavorables ne se produisent généralement pas, et que des algorithmes efficaces résolvent souvent des problèmes comme la résolution de dépendances, le typage, l'ordonnancement ou SAT. Il cite notamment Amazon qui résout un milliard de problèmes SMT par jour, et mentionne que les progrès algorithmiques ont dépassé les gains matériels.
Plusieurs commentateurs convergent sur l'idée centrale de l'article : la dureté NP dans le pire cas est souvent sans rapport avec la pratique. Les problèmes réels ont une structure, des tailles bornées, ou acceptent des heuristiques efficaces. Un praticien de l'EDA rappelle que presque tout y est NP-difficile mais que des solveurs exacts ou approchés traitent de très grandes instances ; d'autres citent le simplexe, dont le pire cas est exponentiel mais qui reste l'outil standard en programmation linéaire. Des exemples concrets sont donnés : un algorithme O(n!) fonctionne pour n≤20, un autre approche 1% de l'optimal en 2 ms. Les algorithmes d'approximation (TSP euclidien, set cover) sont mentionnés comme voie féconde, avec la nuance que les garanties de pire cas ne prédisent pas la performance réelle.
Mais la discussion contredit nettement l'article sur l'absence de « blow-up galactique ». Plusieurs retours de terrain signalent des cas réels : le solveur d'apt de Debian a consommé 2 GiB de mémoire par minute lors de la transition time_t ; SwiftUI est notoirement lent à typer certaines expressions (minutes pour échouer) ; les regex style PCRE peuvent être utilisées pour des dénis de service, et l'exemple (a+) a fait tomber Cloudflare. Un commentateur souligne que l'article oublie le simplexe parmi les problèmes où la NP-difficulté n'importe pas en pratique. D'autres estiment que le type checking est un mauvais exemple, car en Rust ou C++ la complexité vient moins du caractère NP-complet que de la répétition et des choix d'implémentation.
Un débat de fond oppose ceux qui défendent la théorie comme outil de compréhension des limites du calcul et ceux qui la jugent trop éloignée des besoins des ingénieurs. Des commentaires reprochent à l'article de ne pas aborder la solution évidente : interdire les configurations difficiles, comme le font les gestionnaires de dépendances ou les systèmes de types, ce qui réduit le problème à une version plus facile.
-
I requested a copy of my data from McDonald’s loyalty program
Un journaliste a demandé à McDonald's l'accès à ses données personnelles en tant que résident californien. Il a reçu un fichier de 515 pages contenant l'historique détaillé de ses achats, ses transactions, ses points de fidélité, ainsi que des prédictions algorithmiques sur ses visites futures et ses dépenses moyennes. Des experts en vie privée soulignent que cette collecte de données, alimentée par des modèles prédictifs, est courante mais invasive, et qu'elle crée un déséquilibre de pouvoir entre les consommateurs et les entreprises. Le journaliste a utilisé un outil d'IA générative pour analyser le rapport, puis a demandé la suppression de ses données afin de contredire les prédictions de l'algorithme.
La discussion tourne autour du caractère préoccupant ou non des données collectées par McDonald's. Plusieurs commentateurs jugent ces données « banales » et conformes à ce qu'on attend d'un programme de fidélité : statistiques internes, prévisions de dépenses, etc. D'autres estiment que le caractère invasif et le fait que ce soit standard ne s'excluent pas, et que la collecte automatisée est plus troublante que le volume brut. Un point fait consensus : le problème ne vient pas des données elles-mêmes mais de leur agrégation avec d'autres sources et de leur revente éventuelle à des tiers.
La discussion corrige ou nuance l'article à plusieurs égards. L'affirmation selon laquelle la « sauce secrète » de McDonald's serait la surveillance commerciale est contestée : la fidélisation se joue surtout sur la marge, et les programmes de fidélité servent en réalité à une discrimination par les prix, avec deux segments de clientèle (habitués sensibles au prix, clients occasionnels moins sensibles). Le « dossier de 515 pages » est jugé hyperbolique : il s'agit d'un export de données CRM, pas d'une enquête individuelle. Certains notent que la collecte automatique est plus troublante qu'un dossier rédigé, d'autres rétorquent que des données brutes ne sont pas nécessairement « connues » par quelqu'un.
Plusieurs retours concrets illustrent l'essai : un commentateur raconte avoir été interpellé par son prénom au drive de Wendy's, ce qui l'a poussé à supprimer l'application. D'autres soulignent que les programmes de fidélité servent aussi à ne pas envoyer de coupons aux clients déjà captifs, et que les avantages sont contrebalancés par l'usage des données. L'ironie du consentement demandé par Wired est relevée. Enfin, un commentateur note que ce type de données est utilisé en interne, contrairement à d'autres entreprises plus intrusives (Uber), ce qui relativise la gravité.
-
Where did the old web go? We followed 657,607 links to find out
Analyse de 657 607 liens créés entre 2009 et 2014 via le raccourcisseur macédonien 0.mk. En août 2026, 76,7 % des liens ne chargent plus, soit 78,7 % des URL uniques. 55 % échouent au niveau réseau, 23,7 % renvoient une erreur HTTP (404 majoritairement). Les grands sites comme YouTube ou Wikipedia survivent mieux que les blogs personnels, forums et presse locale. Le service, fermé en 2014, a été relancé grâce à l'IA qui réduit les coûts de maintenance.
La discussion porte d'abord sur la définition de « vieux web » : beaucoup de commentateurs contestent la période 2009-2014 retenue par l'article, la jugeant trop récente. Pour certains, le vrai vieux web remonte aux années 1990 ou au début des années 2000, avec l'ère des blogs et avant l'hégémonie de Facebook. D'autres relativisent : ce sentiment de perte serait moins lié à une époque précise qu'à la disparition des communautés auxquelles on appartenait. Un commentateur compare d'ailleurs le web actuel à un « jardin aux murs plus hauts » qui pourrait finalement voir revenir un web de passionnés, tandis qu'un autre qualifie la nostalgie de « lunettes roses » et rappelle que l'ancien web était aussi rempli de sites amateur sans intérêt.
Plusieurs intervenants apportent des précisions factuelles. L'auteur de l'article (ou un proche) explique la méthodologie : 657 607 liens issus d'une base de données récupérée sur un disque, avec 76,7 % de liens morts, mais en soulignant que ce chiffre est une borne haute : certains serveurs répondent 403 ou 429, et une réponse HTTP ne garantit pas que le contenu existe toujours. Un commentateur remarque l'ironie qu'un service de raccourcissement de liens (0.mk) disparu pendant dix ans vienne dénoncer la mort des liens. D'autres critiquent le recours à l'IA dans l'article, jugé coûteux et potentiellement dangereux (risque de jailbreak).
Enfin, la discussion aborde les solutions pour lutter contre la disparition du web : l'archivage par Archive.org est salué, mais certains plaident pour une approche technique plus radicale, comme le content-addressing (liens contenant un hash du contenu) afin que des copies tierces puissent maintenir les ressources. Un commentaire souligne que le spam et les filtres automatisés rendent le web moins sûr pour les non-techniciens. Globalement, la discussion nuance fortement l'article : le « vieux web » est une notion subjective, les chiffres sont à interpréter avec prudence, et la nostalgie ne doit pas faire oublier les défauts réels de l'époque.
-
Choosing an AI model: one prompt, 11 models, different results
Netlify annonce un partenariat avec OpenRouter pour offrir un accès à davantage de modèles via son AI Gateway et Agent Runners, incluant les modèles open source récents comme Kimi K3, GLM 5.2 et DeepSeek V4. L'article compare les résultats et coûts en crédits de plusieurs modèles (dont Claude Opus et Sonnet) sur un même prompt : la création d'un site vitrine pour un coffee shop. Opus a produit un design soigné mais avec une consommation de crédits très variable (un run à 1 055 crédits), tandis que Sonnet est plus économique. Des tests supplémentaires sur d'autres scénarios sont annoncés.
Les commentateurs contestent surtout la méthodologie de l'article : avec un seul essai par modèle, les résultats sont hautement sensibles au hasard, d'autant que les modèles sont probabilistes. Un praticien du benchmark insiste sur la nécessité d'au moins cinq exécutions et de rapporter la variance, faute de quoi toute comparaison relève de la devinette. Le prompt lui-même est jugé irréaliste : une consigne aussi vague laisse les modèles produire une réponse médiane, alors qu'un vrai cahier des charges (horaires, prix, contraintes réelles) révélerait leurs limites. Plusieurs commentateurs estiment donc que ce test ne dit rien des capacités en développement logiciel réel, où l'on travaille par itérations avec des instructions détaillées ; il s'adresserait plutôt aux « vibe coders ». Certains remarquent aussi que les modèles open source ou plus anciens produisent des pages plus sobres et plus lisibles, et que les différences de coût sont plus instructives que le simple rendu visuel.
Une vérification pratique apporte un correctif important : tester les pages sur mobile révèle des écarts considérables que l'article ignore. Certaines maquettes n'affichent qu'un titre et une image sur un téléphone, d'autres ne se chargent pas en connexion 3G. Un commentateur souligne que les designs les plus esthétiques ne sont pas nécessairement les plus efficaces pour l'utilisateur pressé qui cherche l'adresse ou le menu. La discussion nuance aussi l'idée d'une supériorité des gros modèles : plusieurs préfèrent les sorties des modèles économiques, moins « typées IA », et un avis mentionne que les modèles récents génèrent désormais des pages visuellement très similaires, comme si un style par défaut s'était imposé.
Quelques commentateurs défendent néanmoins l'intérêt de ce type de comparaison, notamment pour les coûts réels par token et le comportement des modèles à effort variable. L'idée d'évaluations ad hoc sur son propre problème est évoquée, mais un praticien rétorque que construire un benchmark fiable pour des agents est loin d'être trivial (gel du modèle, de la config, du dataset, des outils, du conteneur).