Hacker News
-
Aaron Swartz was prosecuted for scraping, while Meta does it without consequence
L'article exprime l'indignation face au contraste entre la poursuite judiciaire d'Aaron Swartz, co-créateur de RSS, pour avoir téléchargé environ 70 Go d'articles académiques (avec des peines pouvant atteindre 35 ans de prison et 1 million de dollars d'amende), et l'absence de conséquences notables pour Meta qui a utilisé 80 téraoctets de livres pour entraîner ses modèles d'IA. L'auteur souligne que l'usage de Swartz visait la diffusion des connaissances, tandis que Meta en tire profit commercialement. Il conclut sur une réflexion personnelle et une photo de chat.
La discussion conteste d'abord le cadrage de l'article. Plusieurs commentateurs rappellent que Swartz n'a pas été poursuivi pour simple scraping : il s'était physiquement introduit dans un local du MIT, y avait branché son ordinateur et avait changé son adresse MAC pour contourner les bans. Un autre corrige le chiffre de 35 ans de prison souvent cité : ce n'était que le maximum théorique, la peine réaliste étant d'environ 7 ans, et son propre avocat pensait qu'une peine ferme était peu probable. Un commentateur affirmant avoir connu Swartz ajoute un contexte personnel : il était fragile, entouré de personnes influentes et manipulatrices, et la pression des poursuites l'a brisé. Le récit d'un simple martyr du scraping est donc jugé trop simpliste.
Le parallèle avec Meta est nuancé. Des commentateurs expliquent que le droit d'auteur distingue la distribution de copies, lourdement sanctionnée, de la consommation privée. Or l'entraînement d'IA ne distribue pas les œuvres, et a jusqu'ici été considéré comme un usage équitable. Meta ayant utilisé BitTorrent, il pourrait y avoir un risque juridique, mais pas pour le scraping en soi. Un commentaire mentionne une poursuite d'un éditeur allemand contre OpenAI pour distribution de copies, pour nuancer l'idée que les géants de la tech sont totalement intouchables. D'autres commentaires mettent en avant la dimension politique : ce serait moins une question de copyright que de contrôle des entreprises et de punition de ceux qui défient un modèle économique. Le gouvernement aurait choisi de poursuivre Swartz parce qu'il menaçait le modèle des éditeurs universitaires, et de laisser Meta tranquille pour préserver les investissements dans l'IA.
Plusieurs intervenants tirent des conclusions divergentes. Certains estiment que la bonne issue n'est pas de poursuivre Meta par souci de cohérence, mais de légaliser le scraping pour tous. D'autres dénoncent l'opportunisme sélectif et rappellent que des gens bien moins privilégiés subissent des injustices similaires sans mobilisation. Un avis évoque l'outil de la poursuite privée dans les pays du Commonwealth, avec l'exemple du scandale de la Post Office britannique comme mise en garde.
-
Don't Paste the AI, please
L'article plaide contre le réflexe de copier-coller la réponse d'un chatbot pour répondre à une question réelle. Il rappelle que l'interlocuteur attend un avis personnalisé, pas un texte générique. Il suggère de s'appuyer sur l'IA comme brouillon, puis de rédiger sa propre réponse, de ne garder que le passage utile, de citer l'IA si nécessaire et d'assumer l'absence d'opinion.
Plusieurs commentateurs adhèrent au principe central de l'article : ne pas coller une réponse d'IA telle quelle dans une communication professionnelle. L'idée de « écrire comme soi-même » est reprise, avec l'argument que copier-coller un texte généré par IA transfère la charge de compréhension au destinataire et prive l'émetteur d'un apprentissage personnel. Un intervenant ajoute une étape cruciale manquante à la démarche proposée : valider l'exactitude et la pertinence du contenu, sinon on devient un simple « embellisseur humain » d'IA. D'autres témoignent d'un usage jugé sain : l'IA sert de brouillon, mais le message final est retravaillé à la main, ce qui permet de rester dans sa voix tout en gagnant du temps.
Mais le consensus s'arrête là. Plusieurs avis contredisent frontalement l'article. Un commentateur argue que depuis que ses collègues utilisent Claude, il reçoit enfin du contexte complet au lieu de messages laconiques du type « c'est cassé » ; l'over-communication, même générée par IA, est préférable au sous-communication. Il souligne aussi que l'IA du récepteur n'a pas le même contexte que l'IA de l'émetteur : coller une analyse d'IA peut être légitime quand on n'est pas expert du domaine concerné, en guise d'avertissement pour les mainteneurs qui, eux, ont le contexte. Un autre commentateur relativise en rappelant l'ère Google : les gens demandaient déjà des réponses qu'ils auraient pu trouver eux-mêmes, et l'IA ne changera pas cette paresse. L'argument « l'autre a les mêmes outils que vous » est jugé irréaliste par plusieurs, basés sur des années d'expérience en tant que « gars de l'informatique ». Enfin, un commentateur évoque une stratégie de réponse symétrique : si son chef délègue les revues de code à l'IA, on peut lui répondre avec l'IA, tout en vérifiant et en contestant individuellement les points de revue.
La discussion s'attaque aussi à l'article lui-même. Plusieurs intervenants trouvent ses métaphores peu convaincantes (les puces sont faites pour être lues, le transfert d'email peut être utile) et ironisent sur le fait que la page, qui se conclut par « écrit par un humain, volontairement », semble elle-même générée par une IA.
-
AliExpress runs silent WebAudio fingerprinting that breaks Bluetooth multipoint
Un utilisateur a découvert que la page d'accueil d'AliExpress exécute discrètement un fingerprinting WebAudio qui provoque l'arrêt de l'audio sur ses écouteurs Bluetooth multipoint. En analysant le site, il a identifié deux scripts d'Alibaba (collina.js et fireyejs.js) créant des AudioContext cachés qui génèrent un signal audio inaudible (oscillateur, analyseur, gain à zéro) mais connecté à la sortie audio, ce qui empêche le basculement multipoint vers le téléphone. Ces scripts collectent de nombreuses données (canvas, WebGL, matériel, interactions) pour du fingerprinting anti-fraude. L'auteur propose des règles uBlock Origin pour bloquer ces scripts sans casser le site.
La discussion confirme massivement le phénomène décrit dans l'article : plusieurs commentateurs rapportent avoir constaté des comportements identiques ou similaires, avec des détails concrets. Un utilisateur ayant des aides auditives Phonak a remarqué que certains sites modifiaient l'amplification du bruit ambiant, probablement via Bluetooth. Un autre a vu l'application iOS AliExpress déclencher une commande audio dans sa voiture dès qu'elle était en arrière-plan. Plusieurs témoignages mentionnent des problèmes de multipoint Bluetooth : une page AliExpress ouverte maintient la connexion active entre un PC et un casque, bloquant l'audio du téléphone. Un utilisateur a même identifié ce comportement sur Wolt, une application de livraison, via des crachotements de Voice Over. La conclusion générale est que ces shenanigans sont répandus et difficiles à diagnostiquer pour un utilisateur normal.
Sur les causes et solutions, plusieurs commentaires soulignent que ce n'est pas limité à Bluetooth : Firefox émet de l'audio même sans lecture, et un filtre uBlock corrige le problème. Certains proposent que la lecture audio soit soumise à une permission explicite, comme pour la caméra ou le micro, mais d'autres notent que les utilisateurs accepteraient sans doute pour voir des vidéos. Un avis suggère que les navigateurs devraient bloquer ce genre de comportement au niveau du moteur. Côté réglementation, plusieurs participants évoquent le RGPD et la directive « cookie », estimant que le fingerprinting non consenti est illégal en Europe. Un commentaire nuance que cela dépend de la qualification de « strictement nécessaire ». D'autres débattent de la responsabilité d'Apple et du App Store, mais des réponses rappellent que l'article concerne un site web, pas une application native.
Enfin, des commentateurs élargissent le débat : ce n'est pas qu'AliExpress, mais aussi Twitter, certains captchas, et des exemples passés comme le scan de ports par eBay ou l'abus de DRM par Reddit. L'API WebAudio est un canal de fingerprinting parmi d'autres, exploitant les caractéristiques matérielles (bande passante, latence).
-
The August 17 outage
GitHub a subi une panne majeure le 17 août, d'une durée de 7 h 47, affectant github.com, l'authentification, Actions, les API, les pull requests, les issues et Copilot. La cause est un pic de trafic ayant saturé un composant critique du centre de données Central US, entraînant une pression de capacité généralisée. Ni code ni configuration n'étaient en cause.
Pour y remédier, GitHub a ajouté plus de 3 millions de cœurs CPU, 120 pétaoctets de stockage et accéléré sa migration vers Azure, qui supporte désormais 58 % de la charge de la plateforme. L'article détaille aussi des mesures correctives : isolation des systèmes critiques, limites de retries, et amélioration des alertes et observabilité.
Plusieurs commentateurs contestent le diagnostic principal de l'article : qualifier ces pannes de « défaillances de capacité » revient à manquer le vrai problème. Pour eux, un grand système distribué doit savoir dégrader ses performances quand la demande dépasse la capacité — par du rejet de trafic, de la limitation client et de l'isolation. Un point de convergence est le rôle amplificateur des boucles de retry : le bug latent dans VS Code a multiplié le trafic par 10 pendant la récupération. Certains praticiens estiment que les retries automatiques sont souvent contre-productifs et préfèrent laisser l'humain décider de réessayer.
La croissance des commits (1,4 à 2,9 milliards par mois) est largement commentée, souvent attribuée à l'IA générative (« AI slop »). Plusieurs voix jugent ce rythme insoutenable et suggèrent de faire payer les utilisateurs ou de limiter les pushes pour endiguer la surcharge. D'autres objectent que Microsoft, propriétaire de GitHub, a tout intérêt à encourager l'adoption de l'IA même à perte. Quelques commentateurs défendent néanmoins GitHub, rappelant que le service reste gratuit et sans publicité à cette échelle, ce qui mérite une certaine indulgence.
Le post-mortem lui-même est critiqué pour sa vagueur, même si un lien vers une analyse de cause racine plus technique est signalé. L'accent mis sur l'ajout de capacités et l'accélération de la migration vers Azure est jugé insuffisant : ce qui manque, c'est une stratégie de résilience active, pas seulement plus de machines. Un commentateur relate aussi des changements silencieux et cassants dans la plateforme Copilot. En somme, la discussion corrige l'article : le problème n'est pas uniquement de capacité, mais de conception — le système s'effondre au lieu de se dégrader proprement.
-
Show HN: I trained a 125M model to autocomplete piano on-device
Un développeur a entraîné un transformer de 125M de paramètres pour compléter automatiquement des performances de piano en temps réel (~108 notes/s sur iPhone 15), accessible via l'application RollTab. Il détaille ses choix de représentation MIDI : après avoir testé des tokens d'événements note-on/note-off (sujets à des dérives), il a opté pour une représentation factorisée où chaque note regroupe hauteur, délai d'onset, durée et vélocité, avec des champs vocabulaires séparés et des embeddings sommés. Le sustain est intégré aux durées lors du prétraitement.
Le dataset final contient quelques centaines de milliers de fichiers MIDI (~300M événements), nettoyés et dédupliqués, avec des augmentations (transposition, tempo, jitter, notes supprimées). L'entraînement combine les pertes cross-entropy des cinq têtes de sortie. L'auteur note que nettoyer et sélectionner les données importe plus que d'augmenter leur volume (×5 a dégradé les résultats), et que la cross-entropie ne mesure pas bien la qualité musicale d'une continuation.
La discussion salue largement le projet comme typique de l'esprit HN, mais plusieurs commentateurs le replacent dans une histoire longue : l'autocomplete musical s'apparente aux formules d'improvisation des compositeurs classiques (avec des références à Gjerdingen et à Beethoven). D'autres rappellent des travaux antérieurs comme le Continuator, l'Anticipatory Music Transformer, ou Magenta Realtime 2. Un débat philosophique émerge : la génération automatique de notes n'enlève-t-elle pas le plaisir de l'improvisation ? L'auteur répond que sa motivation est surtout le plaisir de résoudre le problème lui-même, et un commentateur rétorque qu'on peut toujours pratiquer la musique pour l'accomplissement personnel.
Sur le plan technique, l'auteur fournit des précisions demandées : pré-entraînement sur 4 RTX 4090 (environ une demi-journée), seulement 700 exemples de préférences pour le DPO (12 minutes sur un GPU). Le gain de performance vient surtout d'un changement de représentation (notes composées) qui réduit d'environ 5 fois le nombre de passages autorégressifs, plus que de l'optimisation du modèle. Un commentateur suggère d'encoder les relations de hauteur plutôt que les hauteurs absolues, et un autre propose d'ajouter des jetons de mesure ou une étape de planification (type CoT) pour améliorer rythme et forme. L'auteur reconnaît être à un niveau GPT-2 et envisage ces pistes.
Plusieurs avis nuancent ou contredisent l'article : le résultat musical est jugé déroutant (l'exemple de Für Elise) et certains questionnent sa valeur intrinsèque en tant qu'œuvre. Un musicien demande si l'auteur trouve une satisfaction esthétique dans la pièce générée, au-delà du plaisir de l'outil. L'auteur reste modeste sur la qualité et mentionne des améliorations possibles. Enfin, un fil secondaire évoque la nostalgie des fichiers MIDI et leur usage professionnel actuel, et un utilisateur demande une extension avec entrée micro ou sortie MIDI vers un synthétiseur, sans réponse.
-
Malicious Rust crate Arrayref runs a build-time payload
Le 20 août 2026, une version compromise de la crate Rust arrayref (0.3.10) a été publiée sur crates.io. Elle ajoute une dépendance vers une crate typosquattée, proc-macro1, publiée par un compte imitant David Tolnay. Son script de build assemble une adresse serveur à partir de fragments base64, télécharge un binaire adapté à l'OS et à l'architecture via TLS sans validation de certificat, puis l'exécute de manière détachée du processus de compilation. La simple compilation d'un projet utilisant arrayref 0.3.10 déclenche donc l'attaque.
L'attaquant, ayant compromis le compte du mainteneur légitime droundy, a yanké les versions antérieures d'arrayref pour pousser les développeurs vers la version malveillante. Le code source de proc-macro1 est une copie renommée de proc-macro2, ce qui rend la crate fonctionnelle et moins suspecte. crates.io a retiré les versions malveillantes, mais les dépôts GitHub du mainteneur légitime sont supprimés. L'article liste des indicateurs de compromission, notamment les hash SHA256 des artefacts retirés.
La discussion reproche d'abord à GitHub et crates.io leur gestion de l'incident : suppression du dépôt et des versions sans avertissement ni advisory de sécurité, ce qui empêche d'analyser le code malveillant. Plusieurs commentateurs signalent que les versions incriminées ont été entièrement supprimées, pas simplement yankées, rendant l'étude impossible. Un avis minoritaire conteste cette critique : crates.io a déjà géré des incidents et a publié un processus en février 2026, l'absence d'advisory instantané n'est pas un signe d'incompétence.
Le débat principal porte sur les causes et les remèdes. Beaucoup imputent la vulnérabilité à la culture des dépendances et à la stdlib jugée trop maigre, comparant Rust à JavaScript/npm, tandis que Go, .NET ou Odin sont cités comme des modèles « batteries included ». D'autres répondent que Rust a en réalité une stdlib très fournie et que la plupart des dépendances sont des crates first-party maintenues par l'équipe Rust. La question du sandboxing des build scripts (build.rs et proc macros) divise : certains réclament une sandbox Cargo, d'autres doutent de son efficacité pratique, mais plusieurs mentionnent des solutions existantes (cargo-deny, SBE, min-release-age pour npm) et des RFC en cours pour Cargo. Un consensus se dégage sur la nécessité de limiter les privilèges et le nombre de dépendances, ainsi que sur l'utilisation de conteneurs ou de sandboxes OS.
La discussion apporte des informations concrètes : liens vers le blog Rust, l'analyse de StepSecurity, JFrog et Aikido, ainsi que le thread HN dédié au billet officiel. Elle corrige l'article sur un point : crates.io n'était pas totalement démuni face à l'incident, et le manque d'advisory immédiat est nuancé. Enfin, plusieurs commentateurs notent que les actions malveillantes exactes du code restent inconnues, car tout a été supprimé.
-
CIA funding helped keep NeXT afloat in the 80s
Le titre indique que le financement de la CIA aurait aidé NeXT à rester à flot dans les années 80. Aucun autre détail n'est disponible dans cette source.
Plusieurs commentateurs recadrent d'emblée le titre de l'article : « financement de la CIA » signifie ici que l'agence a acheté des machines NeXT, pas qu'elle a injecté des fonds ou installé des portes dérobées. Un commentaire ironise sur le parallèle avec Coca-Cola, et un autre rappelle que ce genre de relation client n'a rien de clandestin. La discussion s'accorde donc pour dire que l'article relève plus du clic que de la révélation.
Des retours de terrain confirment néanmoins l'usage gouvernemental de NeXT : un ancien employé d'un sous-traitant fédéral signale que son client (unique) a acheté « une tonne » de machines NeXT au milieu des années 1990 ; un autre évoque un projet de tri postal en temps réel basé sur NeXT ; un commentateur mentionne l'utilisation d'une machine NeXT en front-end d'un système Kendall Square Research, dans une salle nécessitant des habilitations de sécurité. Plusieurs intervenants notent que la NSA, la DIA et le reste des « trois lettres » achetaient aussi bien du Sun que du NeXT. Un point technique est soulevé : NeXT n'était pas POSIX-compliant, ce qui obligeait à des dérogations, là où Sun passait les tests d'interopérabilité. Un commentateur spécialiste conteste par ailleurs l'anecdote de la « mise à niveau du CPU » : les processeurs étaient soudés et non overclockables, et il s'agissait probablement d'une carte d'accélération.
La discussion élargit le débat : plusieurs commentateurs rappellent que l'argent public (défense, NIH, NSF) a massivement financé la Silicon Valley et la recherche, et que des entreprises comme Oracle ou SpaceX vivent en grande partie de contrats gouvernementaux. Un échange cite aussi SELinux (issu de la NSA) et le rôle historique des agences dans l'informatique. Un commentaire plus spéculatif sur la collecte d'ADN est jugé hors sujet et rapidement écarté. Dans l'ensemble, les commentaires corrigent le framing de l'article : il ne s'agit pas d'un financement opaque de la CIA mais d'un simple rapport client-fournisseur, dans un contexte où les agences soutenaient déjà largement l'écosystème tech américain.
-
Show HN: Huzzah – a novel approach to coding with AI
L'auteur présente Huzzah, un éditeur expérimental qui propose un paradigme alternatif pour travailler avec les LLM. Il critique les agents de codage actuels : les prompts en langage naturel sont longs, impératifs, éphémères et ne conservent pas l'intention humaine. Huzzah utilise des fichiers pseudocode déclaratifs et persistants, dont les diffs servent de prompts à l'IA pour régénérer le code. Exemples à l'appui (fizz buzz, panier, todo), il montre comment cela rend la collaboration plus concise et lisible, tout en servant de documentation.
L'auteur évoque des bénéfices comme l'engagement cognitif, la flexibilité de verbosité, et la possibilité de cibler plusieurs langages. Il reconnaît des limites : difficultés à l'échelle, adaptation idéale aux nouveaux codebases, besoin d'expertise, dépendances inter-fichiers compliquées, et absence de fonctionnalités LSP. Le projet est en développement actif et disponible sur GitHub.
La discussion valide l'intérêt de l'approche de Huzzah pour préserver l'intention humaine face au code généré par IA, mais la relativise fortement. Plusieurs commentateurs soulignent que le concept de pseudocode persistant n'est pas nouveau, le rapprochant du développement piloté par les spécifications (spec-driven development) ou d'outils existants comme Codespeak ou Spekk. Un avis récurrent : l'abstraction ajoutée par un fichier de pseudocode risque de coûter cher en appels LLM et de devenir un niveau intermédiaire superflu, alors qu'un simple prompt système ou un journal des messages utilisateur pourrait suffire. La question du niveau d'abstraction adapté est jugée centrale, certains estimant que le pseudocode est trop proche du code pour être vraiment utile, et qu'il ne règle pas le problème de l'imprécision du langage naturel face à un générateur stochastique.
Le débat le plus vif porte sur l'épuisement ressenti avec l'IA. Un commentateur affirme que la fatigue ne vient pas de l'écriture de texte mais de la perte du processus méditatif de programmation : on délègue la pensée au lieu de coder. D'autres rétorquent que l'IA exige toujours une réflexion approfondie, qu'elle permet à des non-développeurs de prototyper et qu'elle agit comme un « rubber ducky » interactif. Certains expriment une inquiétude générationnelle sur la dégradation des compétences cognitives et de la maîtrise du code, prédisant un retour forcé aux fondamentaux.
Sur le terrain, un praticien confirme que l'IA est utile pour le code de liaison et le boilerplate, mais inutile face à des problèmes complexes de compatibilité navigateur (comme le parsing CSS mso-*), où il faut comprendre le domaine et écrire le code manuellement. Plusieurs commentateurs partagent des solutions alternatives : journaliser les prompts dans un chat_log.md pour détecter la dérive d'intention, ou utiliser des assertions déclaratives plutôt que du pseudocode. Des questions concrètes restent sans réponse : comment gérer les changements multi-fichiers, les connexions entre modules, ou exprimer des concepts applicatifs abstraits.
-
Windows brings out the Rorschach test in everyone (2003)
Ancienne anecdote sur Windows 95 et XP : un hologramme anti-piratage représentant un bébé nu (sans chemise) a offensé un gouvernement anonyme, forçant Microsoft à produire une version habillée sans l'animation du bras. Windows XP a aussi suscité des plaintes pour son wallpaper Red Moon Desert jugé évocateur, et pour des personnages génériques comparés à Hitler ou à un organe obscène.
Le fil confirme l'anecdote centrale de l'article : plusieurs commentateurs rapportent des cas où une image anodine a été perçue comme obscène, entraînant des modifications (logo d'entreprise, splash screen, jaquette de jeu). L'exemple le plus étayé est celui de SimCity : un commentateur a retrouvé par email le cofondateur de Maxis, qui confirme un procès de Toho pour la couverture de 1989, le monstre ayant été remplacé par une tornade pour 50 000 $.
Mais la discussion corrige surtout l'article sur le point du fond d'écran de Windows XP. Un commentateur cite la page Miraheze dédiée : l'histoire de « Red Moon Desert » remplacé à cause d'une ressemblance avec des fesses serait fausse ; Bliss avait déjà été choisi après des recherches, et ce fond d'écran n'aurait été qu'un leurre dans une build intermédiaire. D'autres commentateurs contestent aussi la réaction de Microsoft : certains jugent excessive la suppression des images, y voyant une capitulation face à des plaintes absurdes, quand d'autres estiment que le problème vient plutôt du regard du plaignant.
Quelques commentaires s'écartent du sujet pour critiquer Windows moderne ou évoquer des expériences Linux, mais l'essentiel du fil porte sur la relativité des perceptions et la tendance à surcorriger. Un avis minoritaire défend le droit de ne pas céder à toutes les demandes, tandis qu'un autre pointe l'hypocrisie de censurer un nourrisson nu alors que la nudité est normale dans d'autres cultures. Globalement, la discussion apporte des précisions factuelles et des exemples supplémentaires, mais ne remet pas en cause le fond du propos de l'article.
-
Watching TikTok and Instagram deactivates the cognitive control network: Study
Une étude de l'Université du Zhejiang (publiée dans NeuroImage, janvier 2026) a scanné 56 jeunes adultes par IRM fonctionnelle et spectroscopie pendant qu'ils visionnaient des clips courts type TikTok/Instagram. Les régions cérébrales du contrôle cognitif (cortex cingulaire antérieur dorsal et cortex préfrontal dorsolatéral) se désactivaient significativement lorsque les participants regardaient jusqu'au bout une vidéo qu'ils aimaient, comparé aux vidéos délaissées. Le glutamate mesuré au repos dans la première région prédisait cette suppression, mais les auteurs insistent : la désactivation ne reflète pas un échec du contrôle cognitif, plutôt un basculement adaptatif vers un traitement automatique à faible effort. Ils notent aussi des limites (pas de mesure dans le dlPFC, pas d'échelle d'addiction validée, etc.).
La discussion conteste fortement l'interprétation de l'article. Plusieurs commentateurs soulignent que la déactivation du cortex préfrontal dorsolatéral (dlPFC) est observée dans de nombreuses tâches immersives (jeux vidéo, etc.) et que cela ne signifie pas que l'activité est bonne ou mauvaise. Un commentaire précise que le cerveau passe en « mode basse consommation » avec le réseau du mode par défaut, et que l'article omet de mentionner que les auteurs de l'étude eux-mêmes avertissent que cette déactivation « ne doit pas être interprétée comme un échec de la capacité de contrôle cognitif ». D'autres jugent que le titre est du « blogspam » et que le lien devrait pointer vers l'étude originale. Le manque de fiabilité des études fMRI à petit échantillon est aussi évoqué, avec un appel à la prudence avant de tirer des conclusions.
La discussion élargit le débat au-delà de TikTok : plusieurs commentateurs notent que le véritable problème est le format des vidéos courtes, présent sur YouTube Shorts, Instagram, etc., et pas seulement la plateforme. Un commentaire compare cela à une « télévision moderne » mais en plus optimisé, avec un flux infini et un système de rétroaction qui capte l'attention. D'autres rappellent les paniques morales passées (livres, télévision) et se demandent si les études montrent réellement une différence. Quelques retours d'expérience personnels sont partagés : un utilisateur évoque des nausées après usage, un autre a supprimé son compte plusieurs fois. Un commentaire ironise sur la publicité vidéo courte qui apparaît pendant la lecture de l'article.
Certains commentaires vont plus loin en proposant une régulation ou une interdiction des réseaux sociaux, tandis qu'un autre signale que le compte à l'origine de l'article semble promouvoir un site généré par IA, ce qui jette un doute sur la fiabilité de la source. Un commentaire mentionne que les études antérieures associent l'usage fréquent des vidéos courtes à des troubles de l'attention et de la régulation émotionnelle, mais cela ne fait pas consensus.
-
Turns are Better than Radians (2022)
Article de programmation plaidant pour remplacer les radians par des tours (cercle complet = 1) dans les fonctions trigonométriques. L'auteur montre que le code multiplie souvent par pi ou tau pour convertir une valeur en radians avant d'appeler sin/cos, alors que l'implémentation interne reconvertit immédiatement en divisant par pi. Utiliser des tours simplifie le code, évite les conversions inutiles et permet de représenter exactement des angles courants comme 0,25 (90°) ou 0,5 (180°). Des alternatives comme les demi-tours (déjà présentes dans certaines bibliothèques avec sincospi) sont également évoquées.
La discussion reconnaît l'intérêt pratique des tours en programmation : ils simplifient l'arithmétique modulaire, évitent les erreurs d'arrondi pour les quarts de tour et peuvent être représentés par des entiers en virgule fixe (plusieurs évoquent l'ancienne unité BRAD, et un commentaire cite la représentation u16 de Doom). Un participant a vérifié sur Godbolt que les compilateurs n'éliminent pas les conversions radians-tours, ce qui donne du crédit à l'article sur le plan de la performance. Cependant, l'article est critiqué pour ne fournir aucun exemple d'implémentation, et plusieurs estiment qu'il exagère en affirmant que les tours sont « meilleurs ».
Le principal désaccord porte sur le calcul différentiel : la dérivée de sin(2πx) introduit un facteur 2π, et les développements de Taylor deviennent moins élégants. De nombreux commentateurs soutiennent que les radians sont naturellement adaptés aux fonctions trigonométriques, via la formule d'Euler et la propriété d'auto-dérivation de l'exponentielle. Un avis récurrent : les tours sont utiles comme représentation d'API, mais pas pour les mathématiques fondamentales. La discussion nuance aussi l'article en rappelant que les fonctions trigonométriques servent à d'autres usages que la géométrie, comme le traitement du signal, où la notion de cycle est courante mais où le facteur 2π reste incontournable.
Des alternatives sont proposées : représenter un angle par un couple (cos θ, sin θ) ou par une projection stéréographique, ou encore utiliser un type d'angle dédié à l'instar des types de temps. Plusieurs remarquent que, de toute façon, on peut définir librement une fonction sinT sans bouleverser la mathématique existante. En définitive, le consensus est que le choix dépend du contexte : tours pour la programmation numérique et les graphiques, radians pour le calcul et l'analyse. L'article, par son titre provocateur, est donc fortement nuancé par la discussion.
-
I should have loved biology (2020)
L'auteur raconte comment il n'a pas aimé la biologie à l'école, réduite à une récitation de noms et de formules, alors qu'elle recèle des merveilles comme la différenciation cellulaire ou l'expérience d'Oswald Avery sur le principe transformant de l'hérédité. Il compare la biologie à la programmation informatique, où l'on apprend par projets et questions, et décrit la complexité fractale de l'immunologie rencontrée en travaillant sur le SARS-CoV-2. Le texte, qui s'interrompt sur une phrase à propos de l'hémoglobine, plaide pour une approche plus émerveillée et interrogative de la biologie.
La discussion autour de cet article de 2020 (signalé à plusieurs reprises comme un « perennial HN favorite ») porte moins sur la biologie elle-même que sur la pédagogie. Un large consensus se dégage : l'enseignement traditionnel, dominé par la mémorisation et la mesure, tue le sens de la découverte. Plusieurs commentateurs, dont un responsable de micro-école, défendent l'ordre « sens > motivation > mécanique > mesure ». Un commentaire illustre ce point avec l'exemple d'un cours de chimie « honors » axé sur l'exploration, qui a laissé les étudiants en chimie en difficulté l'année suivante, faute de bases techniques. Un autre, physicien, regrette que les travaux pratiques soient de simples recettes sans apprentissage de la conception d'expériences, et note que les notes pénalisent l'erreur. L'article est souvent comparé à la philosophie de Seymour Papert et de Piaget : apprendre en interagissant avec l'environnement plutôt qu'en recevant des vérités toutes faites.
Mais la vision romantique de la biologie est nettement nuancée. Un chercheur ayant fait le pivot du développement logiciel vers la biologie computationnelle décrit une réalité moins séduisante : médecins « sous-payés » dans un « complexe industriel des sciences de la vie », recherches longues aux résultats incertains, et scientifique « traité comme une ressource » par les biologistes de paillasse. D'autres commentateurs soulignent que ce problème n'est pas propre à la biologie : physique et chimie souffrent du même travers, avec des cours centrés sur des formules et des problèmes stéréotypés, alors que l'histoire des sciences serait bien plus inspirante. Un avis minoritaire rappelle qu'il faut « connaître les bases avant de comprendre les trucs cool », mais il est contredit par l'expérience de ceux qui ont eu des cours véritablement ouverts et formateurs.
Plusieurs commentaires apportent des références concrètes : un lien vers l'article classique « Can a biologist fix a radio? » de Yuri Lazebnik, qui critique le manque de rigueur conceptuelle en biologie, et les discussions précédentes sur HN (2020, 2022, 2024).
-
Vomit: Clean up Claude 5's token output with a separate LLM
Vomit est un outil local qui convertit le flux de tokens de Claude en anglais lisible en le faisant passer par un LLM local, sans télémétrie ni dépendances externes. Il s'installe via `go install`, se configure avec `vomit init`, et peut remplacer la sortie de Claude via des hooks ou fonctionner en mode non invasif avec les commandes `vomit list` et `vomit tail`.
Limitations : le LLM local ne voit que ce que Claude essaie de communiquer (pas d'accès aux actions ou fichiers), ce qui peut provoquer des hallucinations ; le processus est lent, testé uniquement sur Mac, et le message original peut être manqué (des outils comme AgentsView permettent alors de le récupérer). L'auteur recommande Llama.app avec GPT-OSS 20B si aucun LLM local n'est configuré. Le projet est sous licence GNU GPLv3.
La discussion confirme un ras-le-bol généralisé face au style de rédaction d'Opus 5, jugé verbeux, artificiel et truffé de métaphores bizarres. Plusieurs praticiens déclarent que cela nuit à leur travail, certains évoquent même un impact psychologique et envisagent de migrer vers d'autres modèles, notamment Codex ou des modèles open weight. Un commentaire note que le problème s'étend à d'autres agents comme Codex, mais qu'Opus 5 est particulièrement touché, avec des tournures comme des sujets objets verbés ou des auto-justifications. La plupart s'accordent sur le fait que les instructions système (AGENTS.md, claude.md) ne suffisent pas, car le style dérive au fil de la session.
Les causes avancées divergent. Une théorie, reprise par plusieurs, attribue ce style à un entraînement par renforcement optimisé pour la communication agent-agent, notamment via des sous-agents internes, ce qui expliquerait l'emphase et les justifications. D'autres y voient une conséquence de la tarification à la consommation de tokens, les modèles étant poussés à générer plus. Côté solutions, l'article propose de faire nettoyer la sortie par un autre LLM ; des alternatives sont citées comme « Claudish to English », « Caveman », ou des skills maison type « deslop ». Un commentateur suggère d'utiliser la norme ASD-STE100, mais un retour terrain indique que cela n'aide guère. Plusieurs mentionnent un récent paramètre officiel « outputStyle: concise », tout en ironisant sur le fait que cela revient à répéter « tais-toi » à chaque tour.
La discussion nuance et contredit partiellement l'article. Certains font valoir que Fable (le modèle moins cher) est moins affecté, et qu'Opus 4.6 reste préférable pour certains. Un commentaire dénonce le nom « Vomit », qui peut déclencher des réactions physiologiques chez les émétophobes. Plusieurs sceptiques se moquent de l'empilement d'outils agentiques nécessaires pour corriger un modèle censé simplifier la vie. Enfin, la majorité espère un post-mortem d'Anthropic sur ce comportement, mais un avis minoritaire estime que le problème est transitoire et que le modèle sera corrigé.
-
Consumer Rights Wiki
Le Consumer Rights Wiki, dédié aux pratiques anti-consommateurs, publie un ensemble de mises à jour techniques : bouton de retour sur les articles, fonctions anti-spam, comptes temporaires pour les modifications anonymes, mode de verrouillage du site, et lancement de projets sur les lois et la maintenance. Une liste de ressources est également fournie, comprenant des bloqueurs de publicité, des outils d'archivage, des bases de données de rappels de produits et des services de protection des consommateurs.
La discussion tourne autour du Consumer Rights Wiki, une initiative lancée par Louis Rossmann et tenue par quelques bénévoles. Plusieurs commentateurs relèvent le caractère volontairement hyper-spécifique des articles (ex. écouteurs Bose, garantie de pneus, un chat nommé Mr. Clinton), qui prête à sourire isolément. Un participant défend cette approche : l'accumulation de milliers de griefs précis rend l'impact cumulatif difficile à ignorer pour les entreprises, et le wiki sert aussi de vérification avant de faire affaire avec une société. Un autre illustre le cas Bose avec une analogie frappante : un ordinateur portable qui ne se chargerait qu'avec son câble d'origine serait jugé absurde et devrait être illégal, or les écouteurs fonctionnent ainsi.
Un commentateur raconte avoir découvert le site de Rossmann en cherchant des informations sur une corruption BTRFS, et souligne que ce dernier prône la transparence et la réparation. Cela amène une critique notable : plusieurs personnes signalent que le site Rossmann contient beaucoup de contenu SEO généré par IA, avec un scroll détourné, ce qui est jugé inacceptable. Cette remarque tempère l'éloge général et montre que la communauté ne soutient pas aveuglément l'initiateur du wiki.
Enfin, un participant déplore que le wiki soit uniquement en anglais, limitant son utilité hors du monde anglophone, mais un autre répond que des alternatives locales existent (comme verbraucher-rechte.de). Un avis souligne que le manque de ressources bénévoles rend difficile l'ajout d'autres langues sans risque de modération défaillante. Globalement, la discussion valide l'initiative tout en pointant ses limites pratiques et la qualité variable des sites associés.
-
Linux 7.2
Linux 7.2 a été publié, avec un cycle chargé, comparable à 6.7. Parmi les nouveautés : ordonnancement sensible au cache, améliorations de MGLRU, sous-ordonnanceurs pour sched_ext et création automatique de transparents hugepages multi-tailles.
Les contributions d'Igalia incluent la politique d'ordonnancement équitable du DRM scheduler, qui reste optionnelle à cause d'une régression de dernière minute, des améliorations d'observabilité pour sched_ext, et la gestion dynamique de l'alimentation (runtime PM) pour les GPU des Raspberry Pi 4 et 5, réduisant la consommation quand le GPU est inactif. Des correctifs corrigent aussi des bugs anciens du driver GPU Raspberry Pi 3 affectant RetroPie, ainsi que divers autres bogues, dont un bug de 14 ans dans futex. Enfin, un support initial HDMI 2.1 (FRL) pour amdgpu a été intégré.
Plusieurs commentateurs soulignent le contraste entre la stabilité perçue du noyau Linux et l'importance des changements internes. Un avis contredit l'idée que « rien ne change » en rappelant les progrès majeurs : support matériel, isolation par namespaces/cgroups, eBPF, io_uring, Btrfs stable, et les itérations sur l'ordonnancement. D'autres insistent sur l'amélioration spectaculaire de l'expérience desktop récente (audio, GPU, gaming, WiFi), rendant obsolètes les installations de pilotes artisanales.
La discussion apporte des précisions factuelles sur HDMI 2.1 : un commentateur s'interrogeait sur le blocage par le HDMI Forum, et une réponse explique que Valve a travaillé avec AMD pour faire aboutir le support, notamment pour ses machines. Un autre ajoute que des fuites de documentation interne et des négociations ont conduit le forum à lâcher prise. L'acronyme DRM prête à confusion : il s'agit ici de Direct Rendering Manager (gestion du GPU), non de gestion des droits numériques. À propos des écrans, plusieurs notent que l'HDMI 2.1 est utile pour les téléviseurs, qui manquent de DisplayPort, et qu'il offre une bande passante supérieure au DP 1.4. Sur la gestion mémoire, un utilisateur déplore que l'OOM provoque encore des reboots ; des solutions sont proposées comme zram/swap ou earlyoom.
Enfin, certains s'interrogent sur le public visé par ce type d'article. Une réponse suggère qu'il s'agit surtout d'une vitrine pour les services d'Igalia. Un autre commentaire estime que ce format est plus lisible que la liste brute des commits de Linus, tandis qu'un avis minoritaire préfère la couverture de LWN. Globalement, la discussion valide l'article tout en apportant des nuances sur la visibilité des changements et des conseils pratiques issus du terrain.
-
Why aren't smart people happier? (2022)
L'article interroge le lien entre intelligence et bonheur. Une définition standard de l'intelligence, basée sur le raisonnement et la résolution de problèmes, laisserait penser que les plus intelligents sont plus heureux. Pourtant, plusieurs méta-analyses et une étude britannique représentative montrent une corrélation faible ou nulle avec le bonheur. L'auteur analyse 50 ans de données du General Social Survey (30 346 personnes) : les scores de vocabulaire, corrélés aux tests de QI, sont très légèrement associés à un moindre bonheur (r = -.06).
Il attribue ce paradoxe à Charles Spearman et sa théorie de l'intelligence générale (facteur g). Les tests d'intelligence mesurent surtout la capacité à résoudre des problèmes bien définis, avec des règles stables, des frontières claires et des réponses vérifiables. Or la vie est remplie de problèmes mal définis (choix de carrière, relations, éducation des enfants), qui ne se prêtent pas à une solution unique. Selon lui, le QI prédit la réussite scolaire et professionnelle, mais pas la capacité à naviguer ces situations floues. Il manque un terme pour désigner cette compétence, associée à l'insight, la créativité ou la sagesse. Le texte s'interrompt sur cette réflexion.
La discussion nuance fortement la prémisse de l'article. Plusieurs commentateurs partagent leur expérience : s'identifier comme « intelligent » et faire de l'intelligence une source de valeur personnelle mène au malheur, tandis que lâcher prise sur cette identité, ou cultiver d'autres dimensions (relations, santé mentale), procure le bonheur. L'étiquette « intelligent mais paresseux » est citée comme particulièrement néfaste. Beaucoup élargissent la définition de l'intelligence pour y inclure l'intelligence émotionnelle, pratique ou relationnelle ; un avis minoritaire proteste contre l'idée que la vie de célibataire sans enfants soit forcément moins épanouie. D'autres encore voient dans l'ambition, non l'intelligence, l'antithèse du contentement.
Un point de divergence majeur oppose ceux qui estiment que l'intelligence expose à une conscience aiguë des problèmes insolubles (l'ignorance est une bénédiction) et ceux qui rétorquent que l'intelligence sert surtout à justifier rationnellement son malheur, par exemple en se focalisant sur ce qui échappe à notre contrôle. Plusieurs commentaires s'appuient sur des cas concrets : un article de blog mentionné raconte la chute temporaire de QI d'un homme, qui s'est senti plus heureux en cessant de percevoir les systèmes défaillants ; d'autres évoquent des physiciens ou mathématiciens qui se considèrent persévérants plutôt que brillants. L'article est critiqué pour sa superficialité : un commentateur liste des pistes ignorées (pensée de type 1/type 2, autonomie, sens, etc.), tandis qu'un autre défend l'article en rappelant qu'il s'agit d'un simple billet de blog.
Sur le plan factuel, un commentateur corrige l'interprétation de l'article : le QI est une mesure de rang (écarts-types), non une échelle proportionnelle, ce qui relativise les différences de bonheur observées. Un autre souligne que la capacité à passer des tests est une compétence en soi, indépendante de l'intelligence réelle. En définitive, la discussion déplace le débat : plus que l'intelligence en soi, ce sont les croyances, les habitudes mentales et le choix de ce à quoi l'on prête attention qui feraient le bonheur.
-
Bun 1.4
Bun 1.4, le toolkit JavaScript/TypeScript, est disponible. Cette version ajoute 1 517 tests de la suite Node.js, corrige plus de 2 900 problèmes, réduit l'utilisation CPU au repos par 5, la mémoire jusqu'à 35 % et démarre 50 % plus vite sous Linux. Elle introduit aussi Bun.Image, Bun.WebView, Bun.markdown, Bun.cron, Bun.Terminal, l'exécution parallèle des commandes run/test, bun audit fix, bun dedupe et bun prune. Le projet a par ailleurs été réécrit de Zig vers Rust.
En matière de compatibilité Node.js, node:http, node:fs, node:cluster, node:timers, node:zlib, node:vm et node:stream passent 97 % des tests de Node, node:quic 99 %, et node:events, node:trace_events et node:sqlite 100 %. Playwright, Next.js 16.3 avec Turbopack, vitest, OpenTelemetry et dd-trace fonctionnent désormais avec Bun. De nombreux autres packages (Nuxt, testcontainers, @grpc/grpc-js, etc.) sont également pris en charge.
Les performances en production sont améliorées : pour Claude Code, l'utilisation CPU chute de 2×, et les serveurs HTTP consomment 13 à 48 % de mémoire en moins. Bun 1.4 offre aussi de nouveaux outils d'observabilité : --cpu-prof-md, --heap-prof-md, --metafile-md, et un événement process.on('memoryPressure') pour réagir aux pressions mémoire du système.
La discussion salue largement la démonstration technique de Bun 1.4 et de sa réécriture en Rust assistée par Claude, avec des retours de terrain concrets : un commentateur rapporte -50% CPU et -60% mémoire sur ses services, et plusieurs praticiens soulignent la stabilité retrouvée, la disparition d'une fuite mémoire SSR et une compatibilité Node améliorée. Certains voient dans cette release une preuve que les critiques de l'IA étaient infondées, citant les commentaires sceptiques datant de trois mois. D'autres restent mesurés : le projet est jugé « très en retard et sérieusement hors budget », et l'affirmation d'une réécriture en 11 jours est contestée — un commentaire estime qu'il a fallu environ 50 jours, et un autre avance un coût total de 300 à 400 000 dollars en tokens, malgré les chiffres officiels d'environ 165 000 dollars pour l'API seule.
Le principal débat oppose les partisans d'un runtime tout-en-un à ceux qui y voient une mauvaise direction. Plusieurs commentateurs critiquent l'énorme binaire qui réimplémente tout (drivers SQL, clients Redis/S3, parseurs YAML/TOML, tests headless) au lieu de laisser des projets spécialisés faire leur travail. En réponse, d'autres rappellent que l'écosystème Node a longtemps souffert de l'absence de bibliothèque standard et que la fragmentation expose aux attaques de supply chain ; avoir plus de fonctionnalités intégrées réduit les dépendances et améliore la performance. Un avis minoritaire ironise sur un « systemd pour développeurs web » non auditable, mais on lui oppose que le code est open source et que l'audit reste possible. Certains préfèrent attendre que Node reprenne les bonnes idées de Bun pour éviter une migration coûteuse, tandis qu'un commentateur déclare que Node est « mort » pour lui.
La discussion apporte des informations que l'article ne donne pas : le coût réel en tokens de la réécriture, les doutes sur le calendrier annoncé, et des retours d'expérience concrets en production.
-
Stwipe Acquires OpenWouter
Annonce parodique d'une acquisition fictive de "OpenWouter" par "Stwipe", deux entités inventées. Le texte précise que les entreprises réelles Stripe et OpenRouter n'ont aucun lien avec cette satire et que rien de ce qui est écrit ne constitue un conseil financier ou juridique. Il mentionne que certains endpoints sont réels et renvoie vers le service réel duckbillhq.com.
La discussion, largement humoristique, tourne autour du canular que constitue l'article. Les commentateurs saluent l'absurdité de l'acquisition et enchaînent les jeux de mots sur le prénom Wouter, avec des références à d'autres mèmes et à la culture pop. Un commentaire compare la situation à un célèbre article de The Onion, un autre évoque le « koan du Non ». L'ensemble relève davantage du divertissement que d'un débat de fond.
Quelques contributions apportent des éléments concrets, sans lien direct avec le fond : un commentateur suggère de ralentir le défilement du bandeau en haut de page, un autre s'interroge sur la propriété du domaine stwipe.com, et un participant rappelle que Wouter est un prénom courant aux Pays-Bas. Un avis mentionne que le modèle est disponible sur Docker, tandis qu'un autre note, non sans ironie, que les chiffres inventés annoncent zéro hallucination.
Aucun commentaire ne contredit ni ne corrige l'article, qui est manifestement une fiction. La discussion n'apporte pas d'information technique ou factuelle supplémentaire, mais prolonge le plaisir du canular.
-
Stop eating Lady Gaga's Oreos
Cet article oppose l’éthique anti-commerciale du rock des années 1990 à l’acceptation actuelle des partenariats artistes-marques. Il commence par l’exemple de Pearl Jam, qui refusait vidéos et interviews par crainte du « sell-out », puis évoque des cas récents comme Lady Gaga commercialisant des Oreos Chromatica ou Ice Spice avec Dunkin’. Il attribue ce changement à la poptimisme (l’idée que la culture populaire vaut autant que l’art), ainsi qu’au déclin de la critique artistique professionnelle face à Internet et au consumérisme. L’auteur conclut que la distinction entre art et divertissement, et entre single et publicité, a disparu.
La discussion conteste largement la thèse de l'article selon laquelle les partenariats artistes/marques seraient un phénomène nouveau. Plusieurs commentateurs citent des exemples historiques : Michael Jackson filmé avec les cheveux en feu pour Pepsi, Britney Spears vendant du Pepsi, les Rolling Stones payés pour Windows 95, les boys bands des années 90 ou encore les athlètes comme Michael Jordan. Un commentateur estime que les années 90 étaient au contraire l'apogée de la superstardom commerciale, et que l'auteur, adolescent à cette époque, tire de mauvaises conclusions de sa nostalgie. Un avis nuance toutefois : la différence ne tient pas au phénomène lui-même mais à la perte de pouvoir des gardiens culturels qui stigmatisaient autrefois le "sell-out" ; désormais, plus rien ne freine la course aux tie-ins.
Plusieurs intervenants apportent un éclairage économique : la musique ne rapporte presque plus rien, et les artistes dépendent désormais des contrats publicitaires et des produits dérivés pour vivre. Un commentateur souligne que le problème ne vient pas des artistes qui se vendent, mais du culte de la célébrité lui-même ; il propose de simplement ignorer tout ce qui ne relève pas de leur art. Un autre, en écho à l'article, déplore que l'aspiration à la célébrité pousse chacun à se transformer en marque, même pour 500 dollars. Quelques voix discordantes rappellent que l'anti-consumérisme des années 90 n'a jamais été universel, et que les sportifs ou les popstars se vendaient déjà massivement.
Une minorité prend la défense des Oreos eux-mêmes : plusieurs commentateurs affirment avoir adoré les éditions Selena Gomez ou Lady Gaga, et qu'ils les achètent pour la saveur, pas pour la célébrité. L'un d'eux moque l'article en disant que lui dire d'arrêter d'en manger revient à lui demander d'oublier un amour passé. Un commentateur mentionne au passage que l'Oreo a changé de recette, ce qui l'attriste plus que le partenariat. La discussion corrige donc l'article sur son manque de perspective historique, tout en reconnaissant parfois le malaise contemporain autour de la marchandisation généralisée.