Hacker News
-
AI-generated posters don’t have to be horrible
Face à l'omniprésence d'affiches générées par IA au style identique, l'auteur teste la capacité de ChatGPT à produire des affiches d'événement plus variées. En demandant explicitement des styles de design précis (Bauhaus, Swiss Style, risograph, brutalisme, minimalisme japonais, Memphis Design, fanzine punk photocopié…), il obtient des résultats nettement plus distinctifs qu'avec un simple prompt générique.
L'auteur en déduit une leçon pratique : plutôt que de laisser l'IA choisir son esthétique par défaut, il suffit de nommer un style de design ou un mouvement artistique pour échapper au look « affiche IA » que tout le monde commence à trouver agaçant. Il note aussi un effet de contexte : le texte inventé par le modèle s'accumule dans la conversation et réapparaît dans les affiches suivantes.
La discussion révèle un clivage net entre les défenseurs pragmatiques de l'IA et les critiques du rendu esthétique. Plusieurs commentateurs soulignent que les alternatives locales à l'IA ne sont pas de vrais designers mais des affiches WordArt, ClipArt ou des prestataires Fiverr médiocres : pour une fête de village ou un petit commerce sans budget, l'IA produit un résultat « suffisant » là où la solution précédente était pire, voire inexistante. Les critiques répondent que le problème dépasse la qualité technique : les affiches IA sont devenues reconnaissables par simple répétition d'un style uniforme, ce qui lasse indépendamment de leur qualité, et qu'elles signalent un « minimum d'effort » déguisé — un signe de paresse là où Comic Sans aurait au moins été « honnêtement charmant ». Un témoignage d'un voyage au Japon illustre l'effet repoussoir commercial : des clients évitent les restaurants affichant des images IA.
Sur le fond technique, les praticiens apportent des observations concrètes : les modèles restent prisonniers d'associations superficielles et clichées (sakura + drapeau pour « affiche japonaise »), échouent à comprendre les cultures spécifiques (le style drum'n'bass des années 90 est mélangé au smiley de la house, avec des rendus 3D incorrects), produisent des compositions « plates » sans hiérarchie visuelle où tout attire l'attention au même niveau — un défaut que certains rapprochent de la prose stéréotypée des LLM. Un commentaire nuance l'article : ses exemples « réussis » ne sont pas convaincants car le minimalisme offre peu d'occasions de montrer une personnalité, et la comparaison IA vs humain sur des styles différents n'est pas équitable. Un autre relève l'« ironie Toupee Fallacy » : on ne repère que les usages ratés de l'IA, pas ceux d'un bon designer.
Retours de terrain concrets : un employé d'imprimerie signale que les clients arrivent avec des fichiers IA mal dimensionnés (ratios 16:9 ou 2:3 incompatibles avec le papier), persuadés par l'IA elle-même que c'est correct.
-
Laya the open source version of Jev
L'auteur présente Laya, une famille de modèles open source (Apache 2.0) de « décisions System 1 » : une architecture non autoregressive qui n'a pas vocation à générer du texte, mais à produire des probabilités calibrées sur des schémas structurés. Il revendique l'antériorité du concept avec deux articles arXiv (mars et septembre 2025), face à Jev lancé en septembre 2026 par TypeSafe AI (laboratoire fondé par Diogo Almeida, co-inventeur de ChatGPT chez OpenAI), un produit fermé aux capacités similaires facturé 0,042 $ par million de tokens d'entrée avec des réponses autour de 150 ms.
Laya repose sur trois primitives (choice, score, noul) évaluant des questions typées sur n'importe quel état en une seule passe : sélection d'une option, notation sur une échelle ordinale, ou question booléenne, toujours avec une probabilité calibrée. Comme le modèle ne génère que des probabilités, il ne peut halluciner ni produire de JSON malformé. Construit sur des encodeurs bidirectionnels, il tourne en 32,8 ms sur un seul GPU (7,2 ms par question en batch), soit 6 à 8 fois plus vite que Jev, avec plus de 100 langues supportées et sans abonnement API.
Trois checkpoints spécialisés sont publiés sous un dépôt Hugging Face unique avec téléchargements sélectifs par sous-dossier (~808 Mo pour l'anglais).
La discussion autour de Laya, présenté comme alternative open source de Jev, tourne autour de deux thèmes : l'importance décisive du marketing face à la technique, et la réalité technique du produit. Beaucoup de commentateurs soulignent que l'auteur de Laya a publié ses travaux de façon académique (un preprint arXiv au titre peu accrocheur) sans les « productiser », tandis que Jev/Typesafe a su briller par son branding — coiner le terme « System One », une interface simple, un positionnement clair. Plusieurs rappellent que « Jev n'est que du BERT » est un argument faible : comme Dropbox n'était « qu'un compte FTP », ce qui compte c'est de faire connaître son produit, et personne ne se soucie d'être « premier ». Certains notent aussi que le travail de Jev pourrait d'ailleurs être un repackaging de GLiNER, dont le papier date de plusieurs années.
Sur le fond technique, les avis divergent. Un praticien ayant testé Jev le décrit comme un BERT entraîné sur plus de données, plus rapide et moins cher qu'un LLM, pas comme une percée, y voyant surtout un rappel que les tâches simples ne nécessitent pas de LLM générique. D'autres défendent Jev : sa vraie valeur serait l'apprentissage en contexte sans fine-tuning ni infrastructure, permettant de résoudre n'importe quel problème de classification en minutes — un avantage réel face à des années de fine-tuning manuel. Or un commentaire clé corrige l'article : la page de Laya admet en bas que les modèles de base obtiennent ~0,35 (quasi aléatoire) et que le score de 0,766 nécessite un fine-tuning, ce qui place Laya dans une catégorie différente de Jev, présenté comme zéro-shot. Les limitations sont aussi concrètes : contextes de 512-1024 tokens contre 32k-64k pour Jev, alors que ModernBERT supporte pourtant 8192.
Plusieurs commentateurs remettent en cause l'équation « Laya = Jev open source » : le papier décrit une solution taillée pour un problème business précis (prédiction de conversion en ventes), pas un classifieur généraliste, et des tests rapportés suggèrent que Jev lui-même se comporte comme un petit modèle (erreurs sur « strawberry », probabilités incohérentes, sensibilité à l'ordre des réponses jusqu'à 20 %).
-
Human brain is two separate organs, Stanford Medicine-led research finds
Des chercheurs de Stanford Medicine ont montré que le cerveau humain est constitué de deux organes distincts d'origine embryonnaire différente : le cerveau antérieur (forebrain) et le tronc cérébral (hindbrain) proviennent de deux progéniteurs mutuellement exclusifs, exprimant les gènes Otx2 et Gbx2. Cette découverte explique les échecs passés à cultiver des neurones du tronc cérébral en laboratoire, désormais obtenus avec succès à partir de cellules souches pluripotentes, ouvrant la voie à l'étude de maladies comme la SMA et la SLA. Le schéma à double origine, confirmé chez plusieurs espèces jusqu'aux vers enteropneustes, suggère que l'évolution a fusionné deux systèmes nerveux anciens. Publié dans Nature Neuroscience le 18 septembre.
La discussion porte surtout sur le décalage entre le titre sensationnaliste (« le cerveau est deux organes séparés ») et le contenu réel de l'étude. Plusieurs commentateurs, s'appuyant sur le titre exact de la publication dans Nature Neuroscience (« Two parallel neural ectoderm progenitors contribute to the developing brain »), soulignent que le papier parle d'un « organe composite » issu de deux progéniteurs de lignées distinctes — l'un exprimant Otx2 (prosencéphale/mésencéphale), l'autre Gbx2 (rhombencéphale), sans jamais se chevaucher dès les premiers stades embryonnaires. Le titre de l'article est jugé factuellement incorrect et surventé, même si un avis minoritaire estime qu'un titre vulgarisateur accessible au grand public n'est pas illégitime.
Le point consensuel le plus enthousiasmant n'est pas la dichotomie « deux organes » mais la retombée pratique : cette compréhension des lignées a permis de mettre au point une nouvelle technique de culture de cellules souches du cerveau postérieur in vitro, jusque-là très difficile, ce qui pourrait accélérer la recherche sur des maladies comme la SLA. Un commentateur explique que cette découverte éclaire aussi l'échec historique des tentatives de culture : les chercheurs partaient probablement de neurones du prosencéphale en croyant obtenir des neurones du rhombencéphale, car un neurone antérieur ne peut pas se comporter comme un neurone postérieur.
Des nuances factuelles complètent le tableau : le papier postule que ces deux progéniteurs seraient conservés depuis 550 millions d'années (des hémichordés aux mammifères), et un commentaire relie cette dualité à une autre actualité sur les cténophores, chez qui l'évolution aurait « inventé » un système nerveux deux fois indépendamment. Certains contestent l'idée que la communauté médicale aurait cru à un cerveau unique depuis un siècle, d'autres rapprochent (à tort ou à raison) le résultat du modèle du « cerveau reptilien », débat qui reste tranché entre le rappel que ce modèle est un cliché dépassé et l'avis que la critique en fait trop.
-
If math is more than proof, we need to better celebrate the rest of it
Grant Sanderson (3Blue1Brown) propose, en billet invité, de mieux valoriser dans la communauté mathématique ce qu'il nomme les « motivated explanations » : des explications qui visent à faire comprendre comment on aurait pu trouver une idée, et pas seulement à prouver un théorème. Selon lui, la preuve n'a toujours été qu'un proxy pour l'objectif réel des mathématiciens — faire progresser la compréhension humaine — et la génération automatique de preuves par les IA rend nécessaire de récompenser académiquement d'autres formes de contributions.
Il contraste les deux genres : dans une preuve, les définitions sont posées au départ et chaque énoncé doit être correct ; dans une explication motivée, les définitions arrivent au milieu, les idées imparfaites sont acceptées si leur origine est relatable, et l'objectif est aussi d'expliquer pourquoi un théorème mérite d'être posé. Il reconnaît l'absence de validation binaire (pas de « Lean » pour les explications), mais juge la notion de « motivated » assez vérifiable pour servir de mesure pratique.
Il cite l'essay de Bill Thurston « On Proof and Progress in Mathematics » et l'épisode du Princeton Companion to Mathematics édité par Timothy Gowers — qui n'a pu y consacrer cinq ans de travail qu'après sa médaille Fields — pour montrer que ces pratiques existent déjà et méritent un statut accru.
L'article de Grant Sanderson (3Blue1Brown, et non Terence Tao comme le croit initialement un commentateur, erreur corrigée en fil) propose de célébrer en mathématiques autre chose que la preuve : la compréhension, l'intuition et l'explication. La discussion est dominée par la question de l'impact de l'IA sur le métier de mathématicien.
Plusieurs commentateurs s'accordent sur le fond : les mathématiques sont d'abord un langage de communication précis, et l'enseignement rate souvent cette dimension, ce qui expliquerait le dégoût de nombreux élèves ; un enseignant déplore que de bons mathématiciens soient souvent de mauvais pédagogues. Un rapprochement est fait avec la programmation, elle aussi un langage de communication où l'IA déplace la valeur. Le parallèle avec le « coder's moment » revient plusieurs fois : comme « écrire du code n'a jamais été le but », la preuve comme tâche manuelle pourrait perdre sa centralité — mais plusieurs notent que cela retire une texture et un plaisir du métier. Un doctorant regrette quant à lui que « refactorer » des preuves (les simplifier, les clarifier) ne soit presque pas récompensé institutionnellement.
Le désaccord porte sur l'optimisme : un commentateur estime que c'est le meilleur moment pour être mathématicien, mais un ex-mathématicien le contredit fermement, affirmant que ses confrères sont misérables et fuient le domaine, la comparaison faite au chairon de la révolution industrielle. Des retours de terrain nuancent toutefois le tableau : un mathématicien professionnel raconte avoir prouvé en quelques semaines avec l'IA un théorème mûri depuis des années, jugeant le changement de workflow énorme. D'autres apportent des éléments concrets : le financement des mathématiques théoriques est déjà très faible (données NSF citées), donc l'enjeu économique serait secondaire ; le risque majeur serait la perte des « side quests » — ces détours nés de problèmes longs comme Fermat qui ont nourri d'autres champs (cryptographie elliptique).
-
San Francisco Onion Futures Company
Un projet bizarre propose des contrats privés et transférables d'achat d'oignons à livraison future, allant jusqu'à 6 mois, à des prix de 3 à 12 dollars par oignon. Le site argumente que la loi américaine interdisant les contrats à terme sur les oignons ne s'applique pas, car l'entreprise n'est pas une bourse organisée et vend ses contrats de manière privée, sans marché secondaire. La livraison est organisée dans quelques villes nord-américaines et les contrats peuvent être cédés via des clés uniques.
L'article présente le San Francisco Onion Futures Company, un projet qui vend des « contrats de livraison future d'oignons jaunes » afin de contourner — et de dénoncer — l'Onion Futures Act de 1959, qui interdit la négociation de contrats à terme sur oignons aux États-Unis. La discussion précise d'emblée le contexte : l'existence d'un groupe étudiant réel (UChicago for Onion Futures, avec site onionfutures.org) qui milite pour la légalisation et distribue des oignons sur les campus, tandis que le fondateur du site explique avoir eu l'idée indépendamment avant de collaborer avec eux.
Les commentateurs s'accordent sur le fait qu'il s'agit d'un projet de performance/nouveauté plutôt qu'un vrai marché, et le vendeur lui-même le confirme : les prix sont bien par oignon (jaune, parfois bio), les livraisons sont réelles, mais l'activité reste essentiellement artistique. Plusieurs s'amusaient de la position légale : le site argumente que l'interdit ne vise que les contrats passés sur une bourse organisée, et la vente privée de contrats transférables constituerait la faille ; des interventions techniques notent qu'il s'agit de forwards ou de simples précommandes, pas de futures. Un commentateur conteste que ces prix (jusqu'à 9 dollars) soient élevés : ils restent 2 à 4 fois supérieurs à ceux des oignons bio à New York, ce que d'autres expliquent par l'effet de nouveauté.
Le fond historique est rappelé : la loi de 1959 fait suite au corner de Vincent Kosuga sur les oignons dans les années 1950, un épisode couvert par un épisode de Planet Money ; un lien vers l'acte (qui interdit aussi les futures sur recettes de box-office) et le rapport quotidien USDA pomme de terre et oignon sont partagés. La nuance factuelle la plus intéressante vient d'un commentateur qui, après vérification sur FRED, constate que la volatilité des prix de l'oignon, de la laitue et de la tomate est en réalité très similaire, ce qui contredit l'idée souvent avancée que l'oignon serait sans futures particulièrement volatil.
-
GPT-6 Astra Solves a WWI German Radio Cipher
GPT-6 Astra a résolu un message radio allemand de la Première Guerre mondiale chiffré selon la méthode ADFGVX, figurant parmi la liste de 50 chiffres non résolus du portail Scienceblogs.de. Plus d'une dizaine de ces messages résistaient jusqu'ici aux décrypteurs, dont l'expert George Lasry.
Le modèle a retrouvé le mot de clé « TRUPPENVERSCHIEBUNG » et décodé le message du 27 novembre 1918 : « Un croiseur anglais est arrivé à Sébastopol le 24, un escadron allié suit le 26 ». Astra explique que le message restait insoluble car cette clé n'était documentée qu'à partir du 9 décembre 1918, postérieurement à la transmission.
Le modèle a ensuite vérifié son déchiffrage grâce aux archives : les journaux de bord confirment que le HMS Canterbury a bien accosté à Sébastopol le 24 novembre 1918, suivi d'un escadron allié le 26. L'auteur présente ce résultat comme une illustration des capacités du modèle, le message n'ayant, à sa connaissance, jamais été décodé auparavant.
La discussion porte sur la résolution par le modèle GPT-6 Astra d'un chiffre allemand de la Première Guerre mondiale (ADFGVX). Un commentateur apporte un éclairage clé qui nuance fortement le titre : la liste des clés avait été saisie après la guerre, donc toutes les clés étaient connues ; l'obstacle tenait au fait que l'opérateur allemand avait mal tapé la clé et utilisé une clé d'un autre jour que prévu. Le modèle n'a donc pas eu à casser le chiffre en force brute, mais à sélectionner la bonne clé dans une liste existante et identifier la faute de frappe. Un analyste humain dévoué aurait pu le faire, mais ne l'avait jamais fait — d'où le caractère « fruit bas » que plusieurs relèvent avec ironie face aux « percées » annoncées.
Un autre point de discorde porte sur l'autonomie réelle du modèle : certains exigent que les titres disent « un LLM a aidé à résoudre X », en déplorant l'effacement du travail humain de direction et de vérification ; d'autres objectent que si le prompt était simplement « choisissez un chiffre non résolu et résolvez-le », le crédit au modèle est mérité. Certains commentateurs soupçonnent une tricherie — récupération d'une solution présente dans les données d'entraînement ou fabrication d'une clé plausible à partir des journaux de bord — mais d'autres répondent que le chiffre (substitution via carré de Polybe suivie d'une transposition colonnaire clé, et non une simple substitution) offre trop peu de degrés de liberté, et que l'article vérifie la solution contre les journaux originaux du HMS Canterbury.
Enfin, plusieurs notent que les sceptiques des LLM reculent constamment leurs critères : ils refusaient d'abord toute cryptanalyse, puis ont minimisé des résultats concrets (nouvelles attaques sur des schémas de compétition, attaque divisant par deux la sécurité effective de HAWK, amélioration de 200 à 800 fois la meilleure attaque connue sur AES 7 tours, récupération de clé sur 13 rounds de LEA en moins d'une heure). La leçon partagée : les agents réussissent surtout sur des problèmes négligés faute de volontaires, « le travail fastidieux que les gens ne font pas », plutôt que sur du travail fondamentalement hors de portée humaine.
-
English: A vs. An
L'auteur explore la règle du choix entre les articles anglais « a » et « an » : elle dépend non de la première lettre écrite, mais du premier son prononcé (ex. « a unicorn », « an hour »). En analysant les données phonétiques du dictionnaire cmudict, il constate que seuls 129 mots sur 32 455 nécessitent une exception à la règle simple de la voyelle écrite. Il publie des visualisations d3.js et note, avec recul, qu'il aurait gagné du temps en utilisant un LLM pour ce code d'analyse ponctuel.
La discussion autour de « a vs. an » dérive rapidement vers l'apprentissage des articles en général, avec une forte participation de locuteurs non natifs. Le consensus est clair : la règle « an » devant un son de voyelle est simple, mais le vrai cauchemar des apprenants est le choix « a vs. the vs. rien », jugé presque indéterminable même après quarante ans de pratique. Plusieurs commentateurs soulignent que l'anglais reste relativement simple comparé à l'allemand, au grec, au russe ou au français, dont les genres grammaticaux et les déclinaisons doivent être mémorisés ; d'autres notent au contraire que l'orthographe anglaise reste redoutable.
Sur le fond technique, la discussion nuance l'article : un commentateur corrige l'idée que l'anglais aurait « ajouté » un n pour éviter deux voyelles — historiquement, le n était toujours présent (comme dans les autres langues germaniques) et a été perdu devant consonne. D'autres apportent des éclairages comparatifs : l'absence d'articles en latin et dans une grande partie de l'Europe de l'Est, les articles romans issus de « ille » et « unus », l'espagnol « él es médico » (sans article pour les professions) jugé plus cohérent que l'anglais, ou encore des parallèles en français (l'hôpital), irlandais et turc. Le phénomène ressemble au « linking R » des accents britanniques. On cite l'outil « anorack » (basé sur espeak) et le fait que « an adder » vient de « a nadder », tout comme « an apron » de « a napron ».
Détails concrets : pour les sigles, la règle du son prime toujours (« an LLM », « an FBI agent », « a NASA engineer »), bien que certains notent un usage divergent (« a RV ») qui suggère des règles distinctes entre oral et écrit selon les dialectes. Le cas « ub » dans le dictionnaire de l'auteur semble dû à « ubiquitous » et « uber ». Enfin, plusieurs évoquent l'usage du « the » in medias res dans les vidéos générées par IA, et un avis souligne que les LLM constituent désormais un outil utile de vérification grammaticale pour non-natifs.
-
I think you should almost never use AI to write
L'auteur argue qu'il ne faut presque jamais utiliser l'IA pour écrire — au sens de rédiger un texte destiné à transmettre des idées ou analyses — même avec des notes détaillées en amont et une relecture ensuite. Il s'appuie sur trois arguments : le processus d'écriture fait partie intégrante du processus de pensée (écrire révèle les failles d'un raisonnement, ce qu'un LLM alimenté par un plan ne fera jamais) ; l'écriture par IA est vague et subtilement fausse de manière difficile à détecter ; et déléguer son écriture à une IA sans le signaler est impoli et trompeur pour le lecteur.
L'auteur précise qu'il n'est pas anti-IA : il juge légitime de l'utiliser pour la transcription, l'analyse de données, la recherche d'informations, le brainstorming, le feedback sur des brouillons ou l'édition de style, tant qu'un humain accepte ou rejette chaque modification. Son propos vise uniquement la génération du texte lui-même.
La discussion autour de l'article « il ne faut presque jamais utiliser l'IA pour écrire » oppose deux camps. Le camp majoritaire défend la thèse centrale : écrire, c'est penser, et déléguer la production de texte à un LLM dégrade la qualité de la pensée elle-même. Plusieurs commentateurs partagent des retours de terrain négatifs concrets : une synthèse de livre blanc générée par IA a fait disparaître des subtilités argumentatives « de manière sournoise », coûtant un temps de correction important ; d'autres notent les faiblesses systématiques des LLM sur les quantificateurs vagues (« certains », « la plupart »), la négation logique (l'IA inverse « non X » en « X est faux ») et la tendance à remplacer des mots choisis par des formalismes académiques inadaptés. Un commentateur mentionne même avoir froissé un collègue en lui demandant de ne plus lui envoyer de textes rédigés par IA.
L'autre camp nuance sans nier le problème : plusieurs praticiens décrivent des usages qu'ils jugent compatibles avec la thèse — faire de l'IA un « sounding board » pour débloquer le début d'un texte, demander des critiques plutôt que des réécritures, ou faire générer plusieurs formulations pour clarifier sa propre préférence. La règle proposée et largement approuvée : « n'utiliser l'IA que pour se faire penser plus et mieux ». Un désaccord persiste sur le parallèle avec le code : certains estiment que les arguments de l'article s'appliquent aussi au code, tandis qu'un développeur répond que le code se vérifie objectivement (on peut l'exécuter) et n'engage pas l'identité, contrairement à la prose. La question de savoir si éditer du texte généré équivaut à écrire soi-même divise aussi : pour un commentateur, éditer suffisamment produit le même résultat ; pour d'autres, le texte d'autrui n'a jamais été « la voix dans sa tête » et l'édition devient un travail de menuisier plutôt qu'un artisanat.
-
Brood War Bench
L'auteur a créé un benchmark faisant s'affronter des modèles d'IA sur StarCraft Brood War, via une version du jeu jouable uniquement par des agents, après avoir constaté que des amis débutants gagnaient facilement en déléguant à leur agent.
Aucun modèle ne dépasse le niveau débutant. Codex Astra domine systématiquement les autres, privilégiant des stratégies de disruption (envoyer un Probe attaquer les ouvriers adverses) avant le macro, et créant parfois des sous-agents économie/armée qui communiquent mal. Les modèles Grok passent l'essentiel du temps à raisonner sans agir : dans une partie, 11 138 tokens de raisonnement pour seulement six lots de commandes en 43 minutes. Claude Fable tente sincèrement de construire une économie et de monter l'arbre technologique, remportant certaines parties. Les anciens modèles jouaient en tour par tour et se faisaient détruire pendant qu'ils réfléchissaient.
Le benchmark a été exécuté en round-robin entre configurations de modèles et niveaux d'effort, sur des VM Freestyle, avec des statistiques de victoires, coûts et matrices tête-à-tête publiées.
Le benchmark « Brood War Bench », où des LLM s'affrontent en temps réel sur StarCraft: Brood War, séduit plusieurs commentateurs : ils saluent l'idée d'évaluer enfin la stratégie, la planification à long terme et l'orchestration, dimensions absentes des benchmarks habituels, et le format temps réel pourrait permettre de quantifier le compromis vitesse/intelligence des modèles (effort élevé vs modèle plus rapide). L'auteur précise que les agents (Claude Code, Codex, Grok Build, pour des raisons de coût) passaient par l'API BWAPI minimale, avec commandes et observations comme outils — un point important : contrairement à DeepMind AlphaStar, les modèles ne sont pas entraînés spécifiquement sur le jeu, ce qui explique en partie des résultats jugés décevants. Plusieurs constatent que les agents échouent notamment parce qu'ils jouent « en tour par tour », trop lents face à la contrainte de temps réel.
La discussion apporte aussi des corrections et nuances. Sur le bot qui écrase actuellement l'échelle coréenne, des commentateurs tempèrent l'exploit : il n'est pas limité en APM et il soupçonne des map hacks. D'autres rappellent qu'un agent via API voit des choses impossibles pour un humain (sélection d'unités cachées, unités invisibles rapportées), ce qui rend la comparaison avec les joueurs humains discutable — la question de la médiation (captures d'écran vs flux de données API) est jugée essentielle. Un commentateur note l'absence de modèles chinois, pourtant compétitifs, et d'autres s'interrogent sur les résultats contre-intuitifs, comme la surperformance de certains modèles de milieu de gamme, potentiellement liée à la vitesse d'exécution plutôt qu'à la qualité du raisonnement.
La nostalgie domine par ailleurs : les cybercafés de la fin des années 90, les premiers tournois d'IA sur Brood War dès 2010 à UC Santa Cruz (BWAPI, proxybot, programmation génétique pour les build orders), l'importance culturelle de Brood War en Corée du Sud. Quelques prolongements sont proposés : des benchmarks similaires sur Go (GoBench), l'idée de laisser les agents apprendre entre les matchs d'une série, ou de faire coopérer un modèle lent et un modèle rapide.
-
The Effect of CRTs on Pixel Art (2024)
Essai (été 2024) sur l'influence des écrans CRT sur le pixel art, et sur le débat selon lequel le pixel art moderne paraît « faux » parce qu'il ignore les propriétés physiques des tubes cathodiques. L'auteur nuance l'idée répandue que le flou du CRT « lissait » tout : sur les systèmes 8 bits comme le C64 ou la NES, les pixels restaient bien visibles, comme le montre une photo de Maniac Mansion (1987) sur un moniteur Commodore 1084S.
Il montre au contraire que la progression du pixel art venait des techniques des artistes : anti-aliasing, dithering, superpositions de sprites et palettes travaillées, qui exploitaient à la fois les qualités du CRT (flou léger, scanlines, léger « color bleeding ») et compensaient les limites matérielles (résolution, RAM, palette fixe). L'exemple de Mayhem in Monsterland (C64, 1993) illustre ce saut qualitatif à matériel constant, malgré des outils de création rudimentaires (souvent clavier ou joystick, faute de souris).
L'auteur considère l'ère 16 bits (Amiga 500, SNES, Mega Drive, Atari ST) comme l'âge d'or du pixel art, avec Silkworm (1989) et Ruff'n'Tumble (1994) en exemples d'anti-aliasing et de dithering subtils. Il regrette enfin que les filtres CRT logiciels des émulateurs ne restituent jamais fidèlement le rendu d'un vrai tube, lui qui préfère désactiver ces filtres et utiliser des CRT réels.
La discussion nuance fortement l'article : plusieurs commentateurs contestent l'idée que les CRT « floutaient » les pixels du pixel art. Un premier commentaire remarque que les captures présentées semblent trop floues pour provenir d'un vrai CRT, et rappelle que sur NES ou SNES les pixels étaient si grands (deux lignes de balayage par pixel) que le dithering restait visible même en RF. Un autre insiste : un CRT ne mélange pas magiquement les pixels ; les gens confondent le flou du signal composite (qualité TV basse, adaptateur antenne) avec les propriétés de l'écran lui-même. Un connaisseur ajoute un détail technique : la grille du jeu ne correspondait pas 1:1 à celle du CRT, d'où un blending géométrique, et les jeux console étaient parfois conçus pour les effets du composite NTSC.
Les commentateurs s'accordent sur le fait que l'expérience variait énormément : les CRT d'arcade neufs étaient « rasoirs », les moniteurs VGA/SVGA affichaient des pixels nets et distincts, tandis que les mauvaises TV par RF adoucissaient l'image. Plusieurs regrettent que les musées exposent les jeux rétro sur écrans plats LCD, ce qui leur semble une trahison du médium — un commentaire va jusqu'à suggérer de les « shamer » comme pour des reproductions de tableaux. D'autres défendent une position opposée : le pixel art moderne est un médium à part entière, conçu pour les écrans haute densité, et l'attachement aux CRT relève d'une nostalgie sélective ; plusieurs rappellent que la Game Boy, écran LCD, a forgé l'affection de toute une génération pour le pixel art, ce qui contredit la thèse de l'article.
Côté concret : un commentaire partage un simulateur CRT open source convaincant (crt-xdr), tout en notant que la clarté du mouvement reste impossible à reproduire. Sur la question de pourquoi plus personne ne fabrique des CRT, les réponses pointent le coût face aux shaders gratuits de RetroArch (paramétrables à l'infini) et la contrainte réglementaire du verre au plomb anti-rayons gamma, non recyclable. Quelques commentateurs critiquent aussi le pixel art moderne « trop blocky », qui néglige le dithering et l'anti-aliasing des vraies productions C64/Amiga, par nostalgie orientée NES/SNES.
-
What Zig felt like, coming from Rust
Un développeur Rust expérimenté raconte sa découverte de Zig en réimplémentant une bibliothèque JSONPath (RFC 9535) qu'il avait écrite en Rust. Il détaille ses impressions : faible support IDE qui l'a poussé vers un workflow en ligne de commande, structure de fichiers plate encouragée par le langage, tests plus verbeux qu'en Rust, et l'absence de paradigme fonctionnel qui l'a contraint à la mutation en place et à un style impératif. Aucun rapport avec les thématiques suivies.
L'article, un retour d'expérience de Rust vers Zig, suscite une discussion polarisée entre les partisans de la sûreté mémoire « par construction » et ceux qui valorisent le contrôle explicite des allocations.
Le point d'accord le plus net : Rust occupe une niche que rien ne remplace — langage performant, sans runtime ni GC, mais sûr. Plusieurs commentateurs estiment qu'on ne peut pas confier un projet C++ ou Zig à des développeurs novices sans risque de fuites et de corruption mémoire, ce qui disqualifie ces langages pour la plupart des applications commerciales. Quelques nuances sont apportées : Ada/SPARK est cité comme alternative sûre, prouvable et performante ; d'autres regrettent l'absence de destructeurs automatiques en Zig et Odin, estimant que c'est une impasse, même si on réplique que les analyses statiques de fuites et surtout les arena allocators (libération en bloc à coût nul, bonne localité) répondent partiellement au problème. Le débat sur « l'obsession des allocateurs » (Zig, Odin, C3, Jai) divise : certains y voient un outil de niche adapté aux jeux AAA, kernels et bases de données, d'autres un gimmick surdimensionné pour le logiciel réel, et rappellent que mimalloc ou jemalloc suffisent souvent.
La discussion corrige aussi l'article sur plusieurs points. L'affirmation d'un support IDE « quasi inexistant » est contestée : ZLS couvre la majorité des fonctionnalités LSP et l'extension VS Code est jugée bonne, même si des retours antérieurs mentionnent des crashes. La section « mutation vs monade immuable » est également réfutée : le style fonctionnel est possible en Zig (en passant un allocateur à chaque appel), l'auteur décrit un choix idiomatique, pas une contrainte du langage. Enfin, sur comptime, un praticien nuance les éloges : Rust vise des garanties plus fortes (résultats identiques où que le code s'exécute), ce qui rend les deux approches difficilement comparables, même si comptime reste perçu comme plus agréable en pratique.
-
Tin: full-text search for Postgres
Annonce de TIN, une extension de recherche plein-texte pour Postgres développée par l'éditeur, disponible en version GA. Elle prend en charge requêtes booléennes, de phrase, fuzzy, wildcards, expressions régulières, comptage et classement BM25, avec support des mises à jour continues, réplication et visibilité transactionnelle.
Les benchmarks, menés sur un corpus Stack Exchange de 85 Go (150 millions de documents), comparent TIN à ParadeDB, pg_textsearch et l'index GIN natif : TIN affiche 25× à 57× plus de requêtes par seconde selon les scénarios, avec des latences p99 bien inférieures, tout en lisant moins de données par requête.
La discussion tourne autour de deux débats : d'abord, une tension sur le modèle de diffusion — Tin est proposé uniquement dans le cloud de PlanetScale, la version open source (le dépôt « lead ») ne servant qu'à tester la syntaxe, sans les performances. Plusieurs commentateurs critiquent ce choix, y trouvent un goût amer malgré la licence Postgres qui le permet, et un commentateur ironise sur un possible « embrace, extend, extinguish » ; d'autres regrettent l'absence de support bare metal. Ensuite, le fond technique : plusieurs intervenants rappellent que Postgres dispose depuis vingt ans d'une recherche plein texte intégrée (tsvector/tsquery, index GIN/GiST) et demandent ce que Tin apporte réellement ; un développeur de Tin et des défenseurs répondent que les benchmarks internes annoncent des performances nettement supérieures à GIN (lui-même plus rapide que GiST pour le texte), et que Tin combine recherche et filtres sur d'autres colonnes dans le même index.
-
Measure internet censorship
OONI présente son outil OONI Probe, qui permet à chacun de mesurer la censure sur internet : vérification des sites bloqués dans son pays, test de vitesse du réseau via NDT (développé avec M-Lab), contrôle du blocage de WhatsApp, Facebook Messenger et Telegram, et test des outils de contournement. Les résultats sont publiés automatiquement en quasi temps réel et alimentent le plus grand jeu de données ouvert sur la censure sur internet, avec des mesures consultables pour le monde entier.
Les commentateurs s'accordent sur l'utilité d'un outil de mesure de la censure réseau, mais critiquent fortement son périmètre. Plusieurs soulignent un biais méthodologique : l'application ne teste que des domaines typiquement bloqués dans les dictatures (et non des sites bloqués dans les démocraties, comme Anna's Archive), ce qui donne l'impression que seule la censure des pays autoritaires existe. Un autre reproche récurrent porte sur l'omission de la censure de plateforme (modération Reddit, X, etc.) : pour plusieurs commentateurs, c'est la forme de censure la plus répandue, citant l'exemple du blocage de l'article du NYPost par l'ancien Twitter. D'autres objectent que la modération existe partout, même sur 4chan, et qu'aucun espace vraiment non modéré n'est souhaité.
Un point de clarification technique émerge : l'outil ne mesure que la couche 3 (accessibilité IP), pas les couches 4-7, ce qui expliquerait l'absence de signaux de type plateforme — mais cela laisse aussi une question sans réponse : distinguer un blocage en transit d'un blocage à l'origine, alors que de plus en plus de sites se déconnectent eux-mêmes de Chine ou de Russie. Un praticien rapporte qu'en Chine installer l'outil est risqué et le résultat prévisible : réseau rapide, tout est bloqué. On signale aussi des projets comparatifs (Quack, mesure globale des manipulations DNS, OONI, Psiphon) et RIPE Atlas comme alternative avec des milliers de sondes.
Quelques threads polémiques sont signalés sans être arbitrés : un commentateur affirme qu'il serait mieux d'inclure latence et débit pour détecter les déviations de neutralité du net (avec l'astuce du traceroute par port pour repérer les manipulations) ; un autre note que la Russie a interdit les outils de type speedtest sous prétexte qu'ils aident à cartographier le réseau, et qu'un désaccord s'ensuit sur le principe « security by obscurity » versus données ouvertes. Enfin, un avis minoritaire nuance l'ensemble : quiconque n'a pas vécu une censure comme celle de l'Iran ne mesure pas ce qu'est une censure réelle, la comparaison plateformes/dictatures étant peu pertinente à ses yeux.
-
How Hacker News ranking works: scoring, controversy, and penalties (2013)
Analyse technique du fonctionnement du classement des articles sur Hacker News : formule de scoring combinant les upvotes et l'âge de l'article (gravité 1,8), et diverses pénalités. L'auteur a crawle les pages /news et /news2 chaque minute le 11 novembre 2013 pour comparer les scores bruts aux positions réelles, montrant que l'article au meilleur score brut n'est souvent pas en tête du fait des pénalités (controverse, NSA dans le titre, domaines populaires comme github.com ou medium.com automatiquement dégradés).
La pénalité de controverse s'applique aux articles ayant plus de commentaires que de votes et au moins 40 commentaires, avec un effet soudain pouvant faire disparaître un article du front page. En moyenne, 20 % des articles de la première page et 38 % de la seconde ont été pénalisés. L'article inclut le code Arc de la formule de classement et décrit la méthodologie (Beautiful Soup, Python, matplotlib).
L'auteur de l'article de 2013 se manifeste dans la discussion, surpris de voir son analyse ressortie treize ans plus tard. Les commentateurs s'accordent sur un point : l'algorithme décrit a forcément évolué, même si plusieurs mécanismes évoqués restent d'actualité. Un commentaire technique très détaillé nuance d'ailleurs l'article : le classement est appliqué de façon « paresseuse » — un post n'est recalculé que s'il reçoit un vote, plus un post du top 50 recalculé au hasard toutes les trente secondes, et les pages sont mises en cache 90 secondes. La première page n'est donc jamais un rendu exact de la formule, ce qui explique que les pénalités chiffrées dans l'article soient des plages déduites indirectement plutôt que des valeurs exactes.
La discussion apporte aussi des informations historiques et pratiques : le « second chance pool » (remise en avant par les modérateurs de posts passés inaperçus) daterait de fin 2014, d'où son absence de l'article. Sur la controverse, un commentateur précise que la pénalité ne vise pas le volume de commentaires mais leur ratio par rapport aux upvotes — davantage de commentaires que de votes étant, selon lui, un bon indicateur de « flamewar » dans 90 % des cas. Un utilisateur constate par ailleurs que son gain de karma pour les posts diminue au-delà d'un certain seuil, suggérant un ratio décroissant, sans qu'une explication définitive n'émerge.
Le débat se polarise sur les manipulations : plusieurs commentateurs estiment que des « voting rings » et fermes de votes payés sont actives sur le site, et un utilisateur raconte qu'une pétition jugée sensible a disparu de la première page après une heure, y voyant une influence sectorielle — hypothèse contestée par d'autres qui rappellent qu'une pétition est un appel à l'action peu « intellectuellement intéressant » et souvent flaggée par les utilisateurs eux-mêmes. Un avis majoritaire juge au contraire saine l'opacité des règles actuelles : à l'ère des agents automatisés, publier l'algorithme exact (comme X l'a partiellement fait) ne ferait qu'aider les fermes de votes à l'optimiser.
-
How OpenAI Used Its Own LLMs to Design Its Jalapeño Chip
OpenAI a dévoilé Jalapeño, son premier accélérateur IA : jusqu'à 13,4 pétaflops en 4 bits, 232 Go de mémoire à 15,4 To/s, et une réduction de latence de bout en bout allant jusqu'à 3,6x par rapport au GB300 de Nvidia, avec une consommation moindre. Le projet est passé du concept d'architecture au premier silicium en moins de 20 mois, avec seulement neuf mois entre le premier RTL et le tape-out.
La conception a reposé sur une équipe d'environ 100 personnes chez OpenAI (design système, hiérarchie mémoire, réseau), en partenariat avec Broadcom qui a géré le design physique à partir des portes logiques. Des experts jugent le calendrier crédible et « probablement le meilleur de sa catégorie », tout en soulignant l'apport décisif de Broadcom.
Les LLM d'OpenAI ont accéléré le front-end : le workflow s'appuie sur XLS, une chaîne de synthèse de haut niveau open source issue de Google, dont les langages proches du logiciel (DSLX, C++) sont plus accessibles aux modèles. Sur les premiers chips revenus en mai, les modèles internes ont porté un kernel DeepSeek de 0,31 % à 88,94 % du plafond théorique en environ 40 heures. Le projet a commencé avec o3 et s'est achevé avec des prédécesseurs internes de GPT-6 Astra, capables de travailler directement en Verilog. L'IA a été moins utile pour le backend, mais OpenAI espère capitaliser sur ces enseignements pour ses modèles commerciaux.
La discussion porte sur l'article d'IEEE Spectrum décrivant comment OpenAI a utilisé ses LLM internes pour concevoir sa puce « Jalapeño ». Le point le plus marquant et le plus consensuel est le chiffre de bringup : après réception des premières puces en mai, les modèles internes ont fait passer un kernel DeepSeek de 0,31 % à 88,94 % du plafond théorique en environ 40 heures, un résultat présenté comme répétable, ce qui change les hypothèses de planification. Plusieurs commentateurs, dont des personnes ayant travaillé sur le bringup de puces spécialisées, expriment leur étonnement devant cette accélération, tout en notant une nuance : autrefois on écrivait le logiciel avant la retour de fonderie, et aujourd'hui il devient plus rapide d'attendre.
-
US troop deaths during Iran war exceed Pentagon count by at least four
D'après le titre, le nombre de soldats américains morts pendant la guerre contre l'Iran dépasserait d'au moins quatre le bilan officiel annoncé par le Pentagone. Aucun texte d'article n'est disponible pour détailler les sources ou les circonstances de cet écart.
La discussion porte moins sur le chiffre lui-même (au moins quatre morts américaines non comptabilisées par le Pentagone pendant la guerre contre l'Iran) que sur la crédibilité des statistiques officielles. Un désaccord méthodologique apparaît d'emblée : faut-il compter comme « morts de guerre » des personnels décédés au Moyen-Orient sans lien direct avec le conflit ? Plusieurs commentateurs rappellent qu'historiquement on comptabilise les décès par maladie comme morts de guerre, tandis qu'un autre souligne qu'on ne sait pas assez pour trancher (par exemple un drone houthi vs une crise cardiaque sur une base tranquille).
Le fond du fil est très politique et critique : les commentateurs voient dans cette sous-déclaration un mensonge supplémentaire d'une administration déjà accusée d'avoir interdit à CNN de couvrir le sujet. Un commentaire y voit l'explication de l'agacement du président après le reportage de CNN ; un autre mentionne un incident lié à un outil d'IA militaire ayant failli provoquer une confrontation avec la Chine. Les parallèles avec la guerre d'Irak de 2006 abondent, avec une nuance notable : la géopolitique s'est inversée, les alliés actuels des États-Unis étant présentés comme les descendants politiques d'Al-Qaeda/Nusra, ennemis d'alors. Plusieurs expriment leur défiance envers des électorats qui, selon eux, croyaient que les statistiques gouvernementales étaient fausses — la réalité leur donnerait tort.
Quelques digressions concrètes apparaissent : l'« annexion de facto » du Groenland aurait selon un commentateur ne rien changé, puisqu'un simple réengagement du traité de 1951 sur l'accès militaire américain — déjà permanent — aurait été présenté comme une victoire. Sur le fond de la guerre, un avis l'estime encore plus infondée que celle d'Irak (Saddam avait possédé des armes de destruction massive dans les années 1990), un autre y voyant une opération pour affaiblir l'adversaire régional d'Israël. Un commentateur s'interroge enfin sur l'intérêt de cacher un si petit nombre, d'autres y voyant une habitude de nier systématiquement, même sur des enjeux mineurs.
-
Microsoft director: AI scraping 'the largest theft of labor in human history'
L'équipe juridique du New York Times demande un jugement sommaire dans son procès en contrefaçon contre OpenAI et Microsoft, en s'appuyant sur des documents internes des défendeurs largement scellés ou caviardés. Un mémo de janvier 2023 du directeur Applied Science de Microsoft, Brent Hecht, qualifiait le scraping par l'IA de « plus grand vol de travail de l'histoire de l'humanité », et un autre document interne évoquait un « doom loop » menaçant les modèles et le web entier. Les données de Microsoft montraient que Copilot faisait chuter le taux de clic vers le NYT jusqu'à 93 % par rapport à Bing. Chez OpenAI, le responsable de ChatGPT Nick Turley parlait d'une « menace existentielle » pour les éditeurs, et un chercheur évoquait devant Greg Brockman un « hack pour contourner le paywall du NYT », ce à quoi Brockman répondit « ah nice ». Ces révélations pourraient compliquer la défense d'« usage loyal » (fair use) des entreprises d'IA, en montrant que leurs directions connaissaient les répercussions de marché. Satya Nadella a déclaré en déposition que tout contenu payant devrait être sous licence pour l'entraînement, et qu'OpenAI aurait dû être contrainte de re-entraîner ses modèles si cela avait été porté à sa connaissance.
La discussion porte surtout sur la crédibilité du propos rapporté : un responsable de Microsoft (Brent Hecht, direction Applied Science) aurait qualifié le scraping par l'IA de « plus grand vol de travail de l'histoire de l'humanité » dans un mémo interne de janvier 2023, soit un mois à peine après la sortie publique de ChatGPT. Plusieurs commentateurs soulignent qu'il s'agit d'un document sorti de son contexte et jugent la formule prophétique plutôt qu'hypocrite, tandis que d'autres y voient de l'ironie venant d'une entreprise elle-même impliquée, Microsoft étant actionnaire et partenaire d'OpenAI.
Le principal point de division est la qualification même de « vol » : une partie des commentateurs estime que tout le savoir humain se construit en réutilisant les œuvres antérieures, et que parler de « vol de travail » est absurde ; d'autres objectent que cela confond inspiration et appropriation commerciale massive. Un commentateur relativise aussi la notion de vol de travail au sens strict : le contenu scrapé a déjà été rémunéré lors de sa création, c'est la valeur future qui est captée ; d'autres répondent qu'une grande partie du contenu web a été fournie bénévolement et que cela ne correspond pas au droit d'auteur. Un fil sceptique note l'invraisemblance de la promesse rapportée selon laquelle Microsoft aurait exigé d'OpenAI de « réentraîner » ses modèles si des contenus payants avaient été utilisés.
Apports concrets : un témoignage personnel rapporte qu'un terme et une explication inventés par son auteur sur un forum de linguistique ont été absorbés par un LLM, lequel a refusé d'en citer la source tout en paraphrasant le contenu — symptomatique, selon lui, d'une corruption générale de la provenance. Une réponse technique nuance toutefois cet exemple : les LLM n'ont par conception aucune mémoire des sources de leur corpus d'entraînement, la provenance n'étant simplement pas un objectif d'entraînement actuel. La discussion corrige donc l'article sur deux points : le propos date de début 2023 et ne peut être lu comme une admission récente, et les LLM ne « cachent » pas les sources par malhonnêteté mais par architecture.
-
Btrfs/ZFS/bcachefs under workloads classic benchmarks skip
Un fil Hacker News (auteur : farlight) compara Btrfs, ZFS et bcachefs face à des charges de travail que les benchmarks classiques ne couvrent généralement pas. Le texte de l'article n'est pas disponible au-delà du titre, la comparaison détaillée ne peut donc pas être résumée.
Le benchmark de Bartosz Fenski compare btrfs, ZFS et bcachefs sur des charges rarement testées (trivial-op p99, corruption, troncature, etc.). L'auteur intervient lui-même dans la discussion : il reconnaît les limites des runners GitHub (VM partagées, voisins bruyants), explique sa procédure de calibration et publie 593 runs ; il a aussi obtenu du vrai matériel (une machine Hetzner fournie par Kent Overstreet, qui a mouru après 3 runs, puis une machine à disques multiples en cours de test), avec des résultats bare metal publiés séparément. Il précise aussi que le label « Integrity » est trompeur et sera renommé « Corruption probe » : un SURVIVED ne prouve qu'un fichier est resté lisible et identique, pas la santé complète du système de fichiers. Un commentaire signale enfin un bug probable dans le test ftruncate concernant xfs, corrigé via une issue GitHub.
Le principal point de division porte sur la fiabilité et la gouvernance plutôt que sur les performances. Plusieurs commentateurs décrivent des défaillances historiques de btrfs (impossibilité de mesurer l'espace libre, échecs catastrophiques quand un volume se remplit, outils de réparation rendant parfois le volume illisible) et jugent que rien n'a été corrigé en neuf ans ; un autre rapporte une corruption totale sans raison apparente et une migration vers ZFS sans problème depuis. À l'inverse, les bons résultats de bcachefs plaisent, mais son éviction du noyau mainline (drame entre Kent Overstreet et les mainteneurs kernel, renvoi vers un article LWN) inquiète : certains refusent d'adopter un système « second-class » et préfèrent ZFS sur un autre OS, ou restent sur ext4/xfs + LVM. D'autres relativisent : pour un utilisateur, ce qui compte est que ça fonctionne, pas le drame des mainteneurs ; certains signalent qu'il existe des solutions de déploiement (NixOS, NASty) rendant bcachefs racine praticable.
Les critiques méthodologiques portent surtout sur l'absence de bare metal systématique et de comparaison directe loop devices / matériel réel, jugée indispensable pour tirer des conclusions ; l'auteur y répond en cours de travaux.
-
You can defeat the Dream Devourer from Chrono Trigger using an int overflow
Il est possible de vaincre le Dévoreur de rêves, boss secret de Chrono Trigger, en provoquant un dépassement d'entier (int overflow).
La discussion part du glitch permettant de vaincre le Dream Devourer de Chrono Trigger (boss exclusif à la version DS, absent de la version SNES, précisent plusieurs commentateurs) via un dépassement d'entier sur ses points de vie. Un participant note que le lien miroir proposé pour contourner le site Fandom ne mentionne pas ce glitch, ce qui relativise le contenu de l'article.
Les commentateurs s'amusent surtout de la récurrence des bugs d'overflow dans les jeux rétro et échangent des exemples concrets : le tunnel qui fait déborder le compteur d'argent dans Transport Tycoon, le superboss Egg Dragon de Lufia 2 avec ses 65 535 HP, le boss final de Fire Emblem Three Houses dont les 199 PV plus une case de soin de 60 débordent à 256, l'arme mal codée de Realmz qui permet de dépasser -127, le glitch d'élixir qui marche sur plusieurs boss, ou encore la corruption de sauvegarde dans Secret of Mana. Un commentateur cite aussi Noita, jeu qui assume volontairement ce type de comportements comme mécanique de late game. Quelques digressions sur le mythe du « Nuclear Gandhi » de Civilization (urban legend, corrigé par un lien Wikipédia) et une polemique Chrono Cross vs Trigger complètent le fil.
Deux points d'accord dominent : Fandom est qualifié de site surchargé de publicités et quasi illisible, plusieurs recommandant d'exclure Fandom et Fextralife de leurs recherches ou d'utiliser des miroirs ; et Chrono Trigger reste jugé intemporel, avec un soundtrack régulièrement cité parmi les meilleurs. Une remarque minoritaire défend les langages « sûrs » contre les overflows, nuancée aussitôt : Rust ou C# peuvent aussi déborder silencieusement selon la configuration.
-
Science Is Open Software
Aucun contenu n'est disponible au-delà du titre « Science Is Open Software », publié sur Hacker News par jegp. Impossible de déterminer le sujet traité à partir du texte fourni.
L'article défend l'idée que la science moderne devrait fonctionner comme un logiciel open source : résultats reproductibles, code et données ouverts, exécutables à la demande. Les commentateurs partagent globalement l'objectif mais plusieurs jugent l'article trop optimiste : l'idée d'un résultat « reproductible en un clic » relève de l'utopie. Un chercheur qui publie effectivement ses pipelines complète le tableau : le code associé à une publication est du « code exécuté une fois », souvent brouillon, et la reproductibilité à long terme pose des questions non résolues (une image de conteneur sera-t-elle encore disponible dans 30 ans ?). Un autre point récurrent : la reproductibilité est moins cruciale que la réplication indépendante, et un standard réaliste serait la reproductibilité par « une personne raisonnablement compétente », comme avant l'informatique.
Les échanges portent aussi sur les outils. Un débat technique oppose les partisans de Nix, qui revendiquent une égalité bit à bit des builds et un écosystème de ~140 000 paquets, aux défenseurs de Docker et Conda jugés plus accessibles ; un autre suggère plutôt une machine virtuelle standardisée (JVM, WebAssembly) pour éviter la centralisation. Sur le fond, plusieurs dénoncent les incitations académiques : la recherche médiocre est publiée, la vérification rigoureuse est découragée, et les données sont souvent retenues sous prétexte de confidentialité alors qu'un anonymisation est souvent triviale. En médecine, un commentateur propose que les essais cliniques publient leurs données brutes dans des dépôts, ce qui remplacerait des milliers d'heures de revues systématiques « doubly flattened ».
Le désaccord le plus vif porte sur les intérêts commerciaux : l'un regrette que la découverte de la nature soit appropriée par des entreprises, tandis qu'un autre nuance que les essais cliniques coûtent des millions et nécessitent une forme de protection pour attirer les financements.