Hacker News
-
Karpathy’s Pelican
Titre seul, aucun contenu disponible.
La discussion tourne principalement autour de la pertinence du benchmark « pelican on a bicycle ». Plusieurs commentateurs estiment qu'il est désormais saturé : les modèles produisent tous un pélican acceptable, et les débats portent sur des détails esthétiques, signe que le test ne discrimine plus. D'autres rétorquent que ce type de démonstration reste utile pour mesurer la compréhension du monde physique et le raisonnement spatial, surtout si l'on passe de l'image statique à l'animation 3D d'une scène complexe. Un avis minoritaire juge le test gadget et sans valeur prédictive pour les tâches réelles, préférant des évaluations sur des traces d'utilisation concrètes et des critères de coût/qualité/vitesse.
Plusieurs commentaires corrigent ou nuancent l'article. L'exemple de Bilbo est critiqué : le modèle s'appuie massivement sur les adaptations visuelles existantes (films, dessins animés) plutôt que sur une compréhension du texte, d'autant que la description n'est pas dans le passage fourni. Un autre point soulevé est la spécificité de Three.js : certains affirment que les modèles Anthropic ont été spécifiquement entraînés pour ce type de code, ce qui rend la démonstration peu représentative de capacités générales — bien qu'un commentateur réplique que la transformation d'un texte littéraire abstrait en scène 3D exige un immense savoir implicite. Enfin, l'accès privilégié de Karpathy à Opus 5 et la non-reproductibilité pour un utilisateur lambda sont mentionnés.
Des pistes alternatives sont proposées : utiliser Blender comme outil d'animation plus exigeant, tester sur des livres récents non présents dans les données d'entraînement, ou auditer des tâches de programmation réelles. Certains s'interrogent sur l'intérêt des démos « jeu généré en X tokens », qu'ils jugent inutiles et sans gameplay. Une réflexion plus large émerge sur le « logiciel jetable » produit à la demande, tandis qu'un commentaire philosophique regrette que ces efforts ne s'attaquent pas aux vrais problèmes du monde. La discussion ne remet pas en cause la prouesse technique, mais conteste fortement l'idée que ce benchmark soit un indicateur fiable de progression générale des modèles.
-
Go 1.27 Interactive Tour
L'article présente les nouveautés de Go 1.27 via un tour interactif. Parmi les faits marquants : les méthodes peuvent désormais avoir leurs propres paramètres de type (méthodes génériques), les clés de littéraux de structure peuvent référencer des champs promus, et l'inférence de type des fonctions génériques est généralisée aux conversions et littéraux composites. Le compilateur génère aussi des allocations spécialisées par taille (jusqu'à 30% de gain sur les petites allocations), les tracebacks incluent les labels pprof, un détecteur de fuites de goroutines devient un profil standard, et les packages crypto/mldsa (signature post-quantique ML-DSA) et uuid (RFC 9562) font leur entrée dans la bibliothèque standard.
Aucune de ces thématiques ne correspond aux centres d'intérêt de Julian.
La discussion dépasse largement l'article sur le tour interactif de Go 1.27 pour se concentrer sur l'évolution des generics, sujet qui divise. Plusieurs commentateurs trouvent l'exemple de méthode générique `(b Box[T]) Map[U any](...)` difficile à lire, notamment à cause des noms de paramètres de type à une lettre. Certains proposent des exemples concrets pour l'expliquer, comme `rand.N` de la stdlib ou une pile générique. Un avis minoritaire défend cet ajout, tandis que d'autres y voient une dérive vers la complexité à la C++. Plusieurs retours de terrain notent que l'inférence de type atténue la verbosité, mais que le débogage des erreurs de compilation reste pénible. La comparaison avec Java (`List`) montre aussi des limites : Go ne permet pas de manipuler un type générique sans spécifier ses paramètres, car les generics sont spécialisés à la compilation.
D'autres changements de la version 1.27 sont évoqués. Le drainage automatique des corps de réponse HTTP est jugé risqué car il change silencieusement le comportement, notamment pour les connexions idle ; les notes de version recommandent de désactiver les keep-alives dans ce cas. Le passage d'`encoding/json` v1 à v2 en arrière-plan est salué comme un changement majeur, mais le style du texte officiel, jugé trop influencé par les LLM, est critiqué. Un commentateur signale un correctif MTE pour Android, utile pour gomobile, et s'étonne que Go ne soit pas le langage principalement supporté sur Android.
La question de l'erreur handling revient : les generics ne résolvent pas le motif `if err != nil`, et un lien vers le blog officiel montre que l'équipe Go a décidé de ne plus poursuivre de changements syntaxiques en la matière. Enfin, sur le plan historique, un ancien membre de l'équipe Go explique que l'adoption des generics n'est pas un revirement mais le résultat d'un long processus de conception et d'un consensus, les mainteneurs d'origine ayant été remplacés.
-
Wikimedia Foundation refuses union recognition, hires union-busting law firm
La Wikimedia Foundation a refusé la reconnaissance volontaire du syndicat Wiki Workers United U.S., malgré une demande restée sans réponse pendant la conférence Wikimania. Elle a publié une déclaration privilégiant une élection à bulletin secret sous l'égide du NLRB, tout en ayant recours au cabinet Littler Mendelson, réputé pour ses pratiques antisyndicales. Le syndicat a annoncé le dépôt d'une demande d'élection et accusé la fondation de manœuvres dilatoires.
Jimmy Wales a défendu le processus de vote secret, estimant que le système de cartes d'adhésion avait pu exercer des pressions sur les employés. La communauté a réagi avec déception, lançant des pétitions de soutien au syndicat réunissant plus de 1 200 signatures chacune.
L'article mentionne également deux autres sujets : la proposition de critères d'éligibilité plus stricts pour le conseil d'administration de la fondation, et des allégations de harcèlement sexuel lors de Wikimania, rapportées par Wikimedia Korea et Wikimedia Malaysia.
De nombreux commentateurs annoncent l'arrêt de leurs dons à la Wikimedia Foundation, indignés par le refus de reconnaître le syndicat et par le recours à un cabinet spécialisé dans l'anti-syndicalisme. Plusieurs citent en contre-exemple l'EFF, qui a volontairement reconnu son syndicat, et certains partagent des liens vers Wiki Workers United. La discussion est dominée par une forte déception, certains voyant là une trahison de la mission de l'encyclopédie.
Cependant, la discussion apporte des nuances importantes. Un commentateur souligne que le titre est trompeur : le cabinet Jones Day, cité par l'article, travaille avec la WMF depuis plus de dix ans pour le droit des marques, et un autre précise que le cabinet réellement impliqué est Littler Mendelson. Plusieurs expliquent que la demande d'élection à bulletin secret par la WMF est une procédure légale standard, activée notamment si l'employeur estime que les cartes d'adhésion ont été signées sous pression ; certains commentateurs trouvent cette défense peu convaincante, mais d'autres la jugent raisonnable. Ainsi, l'accusation d'anti-syndicalisme est jugée faible par certains.
Les avis divergent sur l'intérêt des syndicats dans la tech : certains les jugent inutiles ou nuisibles, d'autres rappellent leur rôle de contrepoids face au déséquilibre de pouvoir, notamment avec l'IA. Par ailleurs, plusieurs commentaires critiquent la gestion des donations par la WMF, évoquant des projets jugés superflus, mais un commentateur répond que c'est le lot de toute organisation prospère. La discussion ne tranche pas, mais elle éclaire les motivations des donateurs.
-
AI financial advice is surprisingly good, especially if you ask right questions
MIT Sloan研究人员的一项新研究测量了大型语言模型提供的财务建议质量。研究发现，遵循AI建议通常能带来可观的储蓄缓冲，尤其对30岁以上人群，建议包括工作期间储蓄、退休时提取、投资多元化股票基金，并在45岁后减少股票敞口。但AI在应对失业等冲击时调整不足，且缺乏主动再平衡投资组合。
研究构建了模拟人生收入、投资和税收的模型，并要求1000名成年人向语言模型写入提示，随后模拟22至89岁人群遵循建议的结果。结果显示，AI建议总体良好，但在使用更结构化、学术化的提示时更好。AI在细节上有缺陷，例如建议失业者过度削减支出。此外，AI建议因用户的性别、金融素养和经验不同而显著变化，导致退休财富差距：女性、金融素养较低者比男性、高素养者少约4%财富，无AI经验者少约6%。
研究指出，更好的提示可改善建议，但最终挑战是让AI建议惠及不擅长写提示的人。AI可作为传统财务顾问的补充，帮助实施建议。
Des préoccupations concrètes émergent : la publicité et la manipulation des modèles (paris sportifs, injection de prompts hostiles) pourraient dégrader la neutralité des réponses, même si un commentateur parie que cela n'arrivera pas. Le manque de connaissances financières de la population générale est souligné : beaucoup de gens se laissent tenter par des arnaques (shitcoins, objets de collection), et une simple fiche « épargnez 10 % dans un ETF » ferait mieux que la plupart des conseils reçus. Plusieurs praticiens partagent des outils pratiques (un skill pour la planification financière, un prompt pour créer un agent conseiller) et des retours d'expérience mitigés selon les modèles. Un avis minoritaire insiste sur la nécessité de donner à l'IA une « peau dans le jeu » et tout le contexte de vie, mais cela soulève des problèmes de confidentialité et de volume de données. En résumé, la discussion valide l'intérêt pratique de l'IA pour la finance personnelle, tout en appelant à la prudence sur les détails techniques et en rappelant que l'humain reste indispensable pour l'aspect émotionnel et la vérification.
-
Show HN: I'm a 15 Year Old Wannabe Engineer, This Is a Cycloidal Gearbox I Built
Un jeune ingénieur de 15 ans présente un réducteur cycloïdal fabriqué par impression 3D, accompagné d'un script Python génératif. Plusieurs versions sont décrites, avec des améliorations comme l'usage de roulements MR128 et de vis M2. Le script s'appuie sur des équations paramétriques et permet de générer le modèle dans Fusion 360.
La discussion salue unanimement le projet d'un adolescent de 15 ans : la conception, la documentation et la fabrication d'un réducteur cycloidal impressionnent. Plusieurs commentateurs insistent sur le fait qu'il mérite le titre d'ingénieur, « par l'acte de faire ». Un avis minoritaire nuance : dans certains pays, le terme est réglementé et exige un diplôme ou une expérience professionnelle. D'autres plaisantent sur le fait que « wannabe » est finalement le lot de tout ingénieur, ou évoquent le syndrome de l'imposteur. La discussion apporte des précisions techniques : un réducteur cycloidal se distingue par son faible jeu, ses multiples points de contact et son rendement élevé ; il est prisé en robotique. Un praticien suggère de mesurer le backlash après quelques centaines de cycles et l'efficacité sous charge pour donner une vraie spécification. Plusieurs commentaires recommandent des ressources (chaîne YouTube, livres d'occasion, Hack Club) et certains proposent leur aide. Quelques mises en garde : ne pas publier son âge, ou être conscient que cela biaise les retours ; un commentaire évoque l'usage probable d'IA et conseille de faire aussi des projets sans. Enfin, un échange donne raison au jeune inventeur sur le plan de l'ingénierie, tout en rappelant que les réglementations locales peuvent encadrer le titre. La discussion corrige implicitement l'article sur un point : le qualificatif « wannabe » est jugé trop modeste par la majorité, et le travail présenté est considéré comme une preuve de compétence réelle.
-
'Crush this lady': how eBay harassment campaign led to $56M payout
Le titre relate une campagne de harcèlement orchestrée par eBay qui a abouti à un dédommagement de 56 millions de dollars.
La discussion prolonge l'article en se focalisant sur la responsabilité des dirigeants. Plusieurs commentateurs relèvent qu'aucun dirigeant n'a été poursuivi pénalement et citent la reconversion de Wenig (conseil d'administration de General Motors, start-up IA) ou de Jones (conseil d'administration de Prudential) comme une injustice. Un commentaire apporte une information factuelle issue du procès : l'organisateur de l'opération, Jim Baugh, aurait également tenté de monter une campagne de chantage contre un procureur de l'Arkansas pendant le voyage cross-country, ce qui suggère un comportement récurrent plutôt qu'un acte isolé.
Plusieurs commentateurs doutent que ce harcèlement ciblé sur un couple de blogueurs soit un cas unique, surtout avec d'anciens capitaines de police impliqués. Un ancien directeur de l'ingénierie chez eBay témoigne d'une culture d'intimidation interne : il raconte qu'un e-mail au CEO sur le processus d'évaluation a provoqué l'intervention d'une directrice RH qui l'a menacé implicitement de perte d'emploi. Ce témoignage renforce l'idée que l'entreprise tolérait des pratiques toxiques. Un commentaire minoritaire relativise en invoquant le caractère idiosyncratique des comportements humains.
La discussion corrige aussi un point tangentiel : un commentaire dénonce des frais eBay atteignant 13 % du prix total, mais un autre rappelle que cette politique est une réponse aux annonces abusives à 1 $ + 60 $ de frais de port, et qu'elle a réduit ces abus. Un autre lien signale qu'il s'agit d'une soumission redondante sans discussion approfondie. Dans l'ensemble, les commentaires apportent des détails issus du procès et des anecdotes personnelles, mais ne contredisent pas le fond de l'article.
-
SwiftUI After 7 Years
SwiftUI, annoncé en 2019 comme l'avenir du développement d'interfaces sur les plateformes Apple, est toujours perçu par l'auteur comme un framework en bêta perpétuelle sept ans plus tard. Il souligne des problèmes systémiques de performance, de prédictibilité du layout, un flux de données chaotique et un manque de rétrocompatibilité qui obligent les développeurs à multiplier les contournements.
Il s'appuie sur des exemples concrets, comme le tutoriel officiel Landmarks d'Apple dont le projet ne fonctionne pas correctement sur macOS, et une comparaison avec UIKit qui montre la supériorité de l'ancien framework. Il replace l'existence de SwiftUI dans le contexte de la concurrence (React Native, Flutter) et du Mac App Store, et y voit le signe d'une culture d'entreprise Apple qui privilégierait le « good enough » à la qualité.
La discussion partage les lecteurs entre ceux qui jugent SwiftUI toujours imparfait et ceux qui estiment que l'article critique des versions obsolètes. Plusieurs commentateurs relèvent que l'auteur ignore les évolutions récentes : NavigationStack depuis iOS 16, @Observable depuis iOS 17, et le modificateur onGeometryChange depuis iOS 18 qui rend GeometryReader inutile. Avec près de 100 % des utilisateurs sur iOS 16+, l'article viserait un état de SwiftUI dépassé. Un développeur en production depuis 2021 nuance les accusations sur le data flow : des outils de profilage existent, et les cascades d'@environment ont été nettement améliorées depuis iOS 17. Il note toutefois des performances macOS décevantes sur M2 Max et des timeouts du compilateur.
Un clivage apparaît entre les développeurs venus d'UIKit, qui peinent à adopter le paradigme déclaratif, et ceux qui estiment que SwiftUI demande simplement une montée en compétence. Plusieurs avis reprochent à SwiftUI de sacrifier la performance et la maîtrise sur des apps complexes, préférant UIKit ou Auto Layout pour le travail sérieux. Un commentaire qualifie SwiftUI de « Early Access » jamais terminé ; un autre, plus nuancé, estime que les centaines de milliers d'apps 100 % SwiftUI ne prouvent pas leur qualité, citant les lenteurs de l'app Réglages macOS. D'autres au contraire vantent la facilité pour des effets avancés (Metal, flous, animations) et considèrent que SwiftUI couvre 80 % des besoins, avec possibilité de descendre en UIKit quand nécessaire.
La comparaison avec d'autres frameworks revient souvent : Compose partage les mêmes défauts, Flutter bénéficie de l'open source, WPF a été abandonné. Un commentaire isolé trouve SwiftUI bien supérieur à SwiftData, jugé inutilisable au-delà de deux modèles. Enfin, pour la génération d'apps par IA, SwiftUI serait plus adapté que UIKit grâce à sa concision et son autonomie, même si certaines capacités restent réservées à SwiftUI.
-
Show HN: Kakehashi – Experimental userspace to run macOS binaries on Linux ARM
Kakehashi est un projet expérimental open source (licence Apache 2.0) qui permet d'exécuter des binaires macOS ARM64 sur Linux aarch64 via une couche de traduction en espace utilisateur, sans JIT. Il charge les Mach-O Darwin, fournit un libSystem autonome et traduit les appels système BSD. L'auteur montre des exemples avec 7-Zip, curl et des tests sur Docker/Colima et UTM. L'objectif est de faire tourner des outils CLI Darwin sur des runners Linux ARM moins chers que les runners macOS de GitHub Actions, malgré une exécution potentiellement plus lente. Le projet inclut des scripts Docker, des tests de correction et une feuille de route. Il n'est pas dérivé de Darling et ne vend pas de blobs Apple.
La discussion situe d'emblée le projet par rapport à Darling, l'antériorité principale. Plusieurs commentateurs citent ce projet et son PR ARM64 ouvert, suggérant une possible collaboration. L'auteur répond qu'il connaît Darling, que son projet n'en est pas dérivé (comme indiqué dans la licence) et que l'architecture diffère fondamentalement : Darling repose sur une émulation au niveau noyau et est écrit en C/objC, tandis que Kakehashi est un userspace léger en Rust. Un commentaire note que Wine a réussi grâce aux jeux, et que les applications de productivité restent moins bien prises en charge.
L'auteur détaille l'état d'avancement dans son message initial et en réponse aux questions : 7-Zip passe des tests multithread mais reste 5,2 fois plus lent que l'exécution native, curl valide plus de 200 commandes, git (Xcode Tools) exécute les commandes de base. Plusieurs commentateurs expriment des cas d'usage concrets : exécuter des Audio Units sur Linux via un pont à la yabridge, ou compiler des applications iOS sur des runners Linux ARM. Un commentateur interroge sur la prise en charge de versions macOS avec des restrictions différentes (par exemple /usr/ non inscriptible) et sur le comportement de `uname -o` pour les scripts bash attendus. Une suggestion sur l'utilisation d'une rootfs macOS complète, à la manière des projets de décompilation de jeux, est jugée peu intéressante par un autre commentateur car cela reviendrait à une machine virtuelle avec plus de surcoût.
Le point le plus discuté est la propreté du projet vis-à-vis de Darling alors que l'auteur reconnaît avoir utilisé des LLM. Un commentateur demande comment garantir l'absence de code dérivé, soulignant que l'IA a pu absorber les leçons de Darling. L'auteur se qualifie de « light-gray room » : pas de plagiat direct, langage différent (Rust vs C/objC), architecture différente (userspace vs noyau), et consignes explicites pour exclure les composants propriétaires. Il invite à auditer le dépôt. La discussion ne contredit pas l'article de présentation, mais elle ajoute des interrogations sur l'originalité et la viabilité à long terme, avec un intérêt marqué malgré le stade expérimental.
-
How the words we teach English language learners changed
L'article compare deux listes de vocabulaire essentiel pour apprendre l'anglais : la General Service List (1953, environ 2 300 mots) et la New General Service List (2013, révisée en 2023, environ 2 800 mots). Entre les deux, environ 600 mots ont été retirés et plus de 1 100 ajoutés. Les changements reflètent l'évolution de la vie quotidienne : 'telegraph' disparaît, 'computer' et 'website' apparaissent, 'tobacco' remplace 'cigarette', 'motherhood' devient 'mom'.
L'analyse sémantique et de tangibilité montre un glissement net : les catégories liées au monde physique immédiat (alimentation, objets, nature) rétrécissent, tandis que les concepts abstraits et institutionnels (hypothèque, évaluation, perspective) augmentent. Les mots concrets, traités par le cerveau via deux canaux (verbal et sensoriel), deviennent moins centraux au profit de mots purement verbaux. Cette évolution accompagne la transition vers une société de cols blancs et une vie plus dématérialisée.
Plusieurs commentateurs relèvent qu'il n'existe pas de liste de vocabulaire idéale : tout dépend de l'objectif (voyage, télévision, presse, vie sur place). Un retour de terrain précise que connaître les mots de supermarché n'est pas indispensable quand on vit à l'étranger, contrairement à ce que suggère un commentaire cité dans l'article. D'autres signalent les biais des corpus existants, comme la surreprésentation de termes techniques (Datenschutz, Impressum en allemand) issus de Wikipédia, et l'absence de statistiques fiables sur la conversation courante. L'article est ainsi nuancé : la difficulté d'un mot ne dépend pas seulement de sa fréquence.
Sur le fond, les changements lexicaux (abandon de humble, loyalty, generous au profit de community, identity, gender) suscitent des interprétations divergentes : inégalités et tribalisation pour certains, mondialisation pour d'autres, influence de l'informatique et d'une langue plus « objective » pour un autre. Un commentateur conteste l'assimilation précision/objectivité. Une critique méthodologique porte sur l'usage de pourcentages alors que la liste est passée de 2300 à 2800 mots : les variations relatives peuvent induire en erreur, même si, en absolu, les catégories en baisse diminuent effectivement.
Une grande partie des commentaires ne porte pas sur le contenu mais sur la présentation : le scroll-jacking et les animations sont jugés pénibles, voire illisibles, ce qui détourne de l'article. Quelques remarques anecdotiques (sur l'évolution des langues, un verset biblique, le mot « keen ») émaillent la discussion, mais sans lien direct avec la thèse. Globalement, les échanges apportent surtout des retours pratiques et une correction méthodologique, plutôt qu'une remise en cause profonde des données.
-
EU Age Verification Project Mandates Hardware-Bound Attestation
Le projet européen open-source de vérification d'âge impose l'attestation liée au matériel (hardware-bound attestation) comme exigence architecturale, d'après un mainteneur. Cette décision suscite des critiques concernant la compatibilité avec Linux, les ROM Android personnalisées et les applications compilées indépendamment.
Le système permet de prouver un âge minimal sans divulguer son identité complète, en s'appuyant sur des clés stockées dans des environnements sécurisés comme Android TEE, StrongBox ou Secure Enclave. La spécification exige l'utilisation du matériel cryptographique natif quand il est disponible, mais les contrôles plus stricts comme la détection de root ou Play Integrity ne sont pas universellement imposés.
Par ailleurs, les fournisseurs de preuve d'âge ne devraient délivrer des identifiants qu'aux applications figurant sur une liste de la Commission européenne, ce qui limite l'usage réel d'une version communautaire. Linux n'est pas explicitement interdit, mais aucune solution native n'est prévue. La controverse reste ouverte en attendant la revue de sécurité et le modèle de menace promis.
La discussion HN partage un large scepticisme : plusieurs commentateurs voient dans ce projet d'attestation matérielle pour la vérification d'âge un moyen détourné de lier l'identité réelle à l'activité en ligne, ou de renforcer le contrôle des géants mobiles (Apple/Google). L'argument « protéger les enfants » est jugé fallacieux, d'autant que des contrôles parentaux existent. Un avis minoritaire défend pourtant la nécessité de restreindre certains contenus aux mineurs, estimant que laisser l'Internet sans garde-fou a des effets sociétaux réels (addictions, cyberharcèlement). Mais la majorité insiste sur le problème de fond : exiger un smartphone certifié exclut de fait tout ordinateur de bureau, pas seulement Linux, et oblige à un second appareil pour les utilisateurs de PC.
Plusieurs précisions techniques corrigent ou nuancent l'article. Un commentateur souligne que l'attestation matérielle n'utilise ni preuve à divulgation nulle ni signature aveugle : l'identifiant matériel (certificat gravé dans le silicium) est donc techniquement exposé. Une collusion entre le fabricant, l'intermédiaire (Apple/Google) et le site vérifié permettrait de relier plusieurs comptes entre eux et à l'achat de l'appareil. D'autres rappellent que le problème n'est pas l'attestation en soi, mais la restriction aux seuls systèmes de Google et Apple : du matériel ouvert pourrait le faire. Un commentaire très éclairé signale que cette application est temporaire : l'UE vise un portefeuille d'identité numérique avec « non-liabilité » (unlinkability) d'ici ~2028, mais que la version actuelle ne l'offre pas. Un contradicteur réplique qu'un programme temporaire a tendance à durer, et qu'il existe des implémentations cryptographiques permettant déjà la liaison sans changer le matériel.
Un clivage net apparaît sur la stratégie. Beaucoup dénoncent une mesure technocratique pure, favorisant le contrôle de la population et renforçant les monopoles américains, voire préfigurant un « pare-feu européen » comme la Chine dès que des sites étrangers refuseront de s'y plier — un antécédent de 2020 est cité.
-
Running Kimi K3 on MI355X at Better Performance per Dollar Than B300
Un retour d'expérience de Wafer sur le déploiement de Kimi K3, un modèle ouvert de 2,8T de paramètres, sur des GPU AMD MI355X (288 Go de VRAM). Les benchmarks montrent que le MI355X atteint 952 tok/s/noeud et 118 tok/s en single stream, soit une meilleure performance par dollar que le B300 et le B200, malgré une avance du B300 en débit brut (~1,65×). Le coût horaire est de 2,50 $/GPU pour le MI355X contre 6 $ pour le B300.
Les optimisations ont porté sur deux points : le speculative decoding, avec un correctif Python nécessaire pour la branche ROCm de sglang (fonction top_k_renorm_prob manquante), qui a apporté ~2,2× en single stream ; et les préfill, où le fallback Triton était lent. Un padding du nombre de têtes d'attention (12→16) a permis d'utiliser le kernel MLA d'AITER, accélérant la préfill de 2-3× sur un préfill froid de 172k tokens.
Les auteurs concluent que l'écart logiciel AMD se réduit, avec un support day-0 pour Kimi K3, et que le SOTA sur AMD est proche.
La discussion HN est très critique envers l'article de Wafer, perçu comme une publicité déguisée. Plusieurs commentateurs relèvent que le B300 surpasse le MI355X sur tous les indicateurs de performance présentés (décodage par flux, agrégat, par GPU) et que l'avantage du MI355X ne repose que sur un prix de location horaire issu d'un seul site d'agrégation, sans calcul de coût total de possession (TCO) ni coûts électriques. Un commentaire détaille que la comparaison avec le B200 est faussée par un all-reduce inter-nœuds sur la voie critique. L'article est qualifié de « slop » et son titre jugé trompeur, car le gain en performance par dollar ne vaut que pour une configuration et des tarifs de location spot.
Plusieurs remarques portent aussi sur la méthodologie : un commentateur s'interroge sur le recours supposé à l'IA pour la mise en place et le benchmark, craignant une perte de cohérence du modèle ; un autre, ayant expérimenté des assistants IA pour ce genre de tâche, note qu'ils trouvent des choses utiles mais qu'il faut vérifier leurs résultats. Un employé de Wafer affirme avoir exécuté des contrôles de précision sur OpenRouter, sans fournir de détails. La discussion corrige aussi le terme « open source » : plusieurs intervenants rappellent qu'on parle de « open weights », les données et outils d'entraînement n'étant pas publiés.
Enfin, un fil aborde la disponibilité réelle et le prix d'achat des MI355X, jugés inaccessibles au marché, et remet en cause la rentabilité d'une infrastructure à moins de 10 $/h pour 8 GPU. Dans l'ensemble, la discussion n'apporte guère de données nouvelles, mais elle conteste fermement la validité de la comparaison proposée par l'article et appelle à plus de rigueur dans les benchmarks d'inférence.
-
US Treasury undertakes historic intervention in yen market
Intervention historique du Trésor américain sur le marché du yen.
Les commentateurs s'accordent sur le caractère historique mais non inédit de l'intervention : des précédents existent en 1998 et 2011. Le contexte est dominé par la crainte que le Japon ne vende ses énormes réserves de bons du Trésor américain pour défendre le yen, ce qui ferait grimper les taux et provoquerait des ventes paniques. Plusieurs analyses y voient donc un intérêt mutuel : Washington aide Tokyo à éviter une hausse des taux japonaise, qui déclencherait une onde de choc mondiale (le « choc BOJ » de décembre 2022 est cité comme précédent). La méthode exacte prête à débat : certains mentionnent que l'intervention passerait par une vente d'euros plutôt qu'un achat direct de yens, afin de soulager le Japon sans que ce dernier ne se défasse de ses titres américains.
Les commentaires apportent des informations concrètes qui complètent l'article : le Japon est le plus gros détenteur étranger de bons du Trésor (environ 1 100 milliards de dollars), et la fuite d'une note manuscrite de Bessent mentionnant « Buy Yen 5Y-10Y » est interprétée par certains comme un signal volontaire pour faire agir le marché sans dépenser d'argent réel. Toutefois, des voix divergentes doutent de l'efficacité : un montant de 5 à 10 milliards de dollars ne serait qu'un « ralentisseur », pas un stop. Un commentateur rappelle que l'intervention américaine en 1998 visait à renforcer le yen après une chute, tandis qu'en 2011 il s'agissait de l'affaiblir après le tsunami.
La discussion corrige et nuance l'article : le mot « sans précédent » est jugé exagéré, et plusieurs participants estiment que ce n'est pas un signal d'alarme majeur. Un avis minoritaire compare cela à une coopération normale entre alliés, tandis que d'autres soulignent les risques liés au yen carry trade, aux bulles d'investissement IA et au contexte de sanctions chinoises sur les terres rares qui fragilisent l'industrie japonaise. Un commentaire relève enfin que le graphique utilise une échelle inversée, ce qui peut tromper la lecture. Globalement, les échanges enrichissent l'article par des précédents historiques, des mécanismes de marché et des doutes sur la portée réelle de l'opération.
-
Anime User Interfaces
Article intitulé « Anime User Interfaces » publié sur Hacker News par akyuu. Aucun contenu n'est disponible au-delà du titre.
Plusieurs commentateurs saluent la collection d'interfaces anime, mais regrettent l'absence de sources ou de légendes pour chaque image. Certains citent des classiques manquants comme Serial Experiments Lain, Gundam Wing ou Golden Boy, et partagent des exemples précis. Une correction importante : une image provient du film WarGames (1983), pas d'un anime, même si un débat s'engage sur une éventuelle reconstitution. La discussion contredit donc l'article sur ce point.
Sur le fond, un commentateur explique les effets de lumière dans les anime anciens via un article détaillé sur les passes de mattes et gels. Un autre analyse la différence entre écran et interface d'entrée, rapprochant ces designs des salles de contrôle nucléaires et du passé militaire de leurs créateurs. Pour certains, ces interfaces foisonnantes contrastent avec la simplification imposée aux consommateurs, et l'IA pourrait permettre un retour à des tableaux de bord riches. Une référence aux panneaux LEGO est aussi évoquée.
Des avis divergent sur la pertinence : un commentateur juge que beaucoup d'images n'ont pas de UI, ce que d'autres réfutent en élargissant la définition. Un autre estime qu'il n'y a presque aucun vrai classique. Enfin, un exemple concret : la tablette Evangelion de Wacom, dont un acquéreur donne un retour mitigé (écran correct, mais fonctions manquantes pour le prix).
-
Meshdiff – visually compare two STL versions in the browser, client-side
Meshdiff est un outil de comparaison visuelle de deux versions de fichiers STL, exécuté côté client dans le navigateur.
Plusieurs commentateurs ont d'abord été déroutés par le terme « STL », pensant au C++ Standard Template Library avant de comprendre qu'il s'agissait du format de fichier pour l'impression 3D. Au-delà de cette confusion, les retours sont majoritairement positifs : l'outil est jugé pratique pour comparer des versions de fichiers 3D, notamment les fameux `part_v3_FINAL.stl`. La principale demande, exprimée à plusieurs reprises et appuyée par des +1, est la synchronisation des trois fenêtres de visualisation : faire pivoter l'une devrait entraîner les autres. D'autres suggestions incluent la mise en évidence des seules différences dimensionnelles (agrandissement, rotation, déplacement), des démos supplémentaires plus complexes, un avertissement quand on compare le même fichier, et une interface en ligne de commande pour intégrer les diff dans des pipelines CI ou des déclencheurs de revue GitHub.
L'auteur intervient pour expliquer son approche : il a choisi un moteur de voxellisation maison plutôt que Manifold/CGAL, car ces bibliothèques supposent une topologie CSG propre alors que les STL réels sont des « triangle soup ». Tout est traité côté client dans un Web Worker, avec métriques de volume et tolérance réglable. Il sollicite explicitement les utilisateurs pour tester ses fichiers bizarres afin de stresser l'outil. Un commentateur lui répond avec les règles de HN concernant les pseudonymes (ne pas utiliser le nom de son projet) et signale un problème de responsive sur son site. Cette réponse reste une digression, mais elle illustre un point de vigilance pour la présentation du projet.
Globalement, la discussion ne contredit pas l'article mais le complète : elle révèle un besoin clair de synchronisation des vues et une confusion sémantique autour de l'acronyme STL. Les retours de terrain sont surtout des demandes de fonctionnalités, plus que des corrections factuelles. Un commentateur mentionne d'autres outils du même domaine (BIM, ArchVision) mais sans les détailler.
-
Show HN: Bor – Open-source policy management for Linux desktops
Bor v0.8.0, gestionnaire de politiques open-source pour postes Linux, est publié. Cette version ajoute trois nouveaux types de politiques (Thunderbird, Microsoft Edge for Business et zones Firewalld), ainsi qu'une refonte complète de l'interface web, un contrôle d'accès par actions plus fin et un durcissement de la sécurité.
Les politiques Thunderbird et Edge utilisent le même mécanisme que Firefox ESR, avec détection des installations Flatpak, protection contre les altérations et éditeurs dans l'interface. Le type Firewalld gère zones, services, ports et règles riches, avec validation via firewall-cmd. La gestion des administrateurs est désormais découpée en permissions par action.
L'interface web adopte PatternFly 6 avec routage par URL, pagination côté serveur, protection contre les actions destructrices et accessibilité WCAG 2.2 AA. Le durcissement inclut liaison stricte de l'identité de l'agent au certificat mTLS, migration des secrets TOTP, protection contre les SSRF dans les helpers de dépôt, et correction de failles. La mise à niveau des agents est requise pour exploiter les nouveaux types de politiques.
Le projet Bor reçoit un accueil positif sur Hacker News. Plusieurs commentateurs y voient une solution adaptée à la gestion centralisée de parcs Linux (associations, écoles, entreprises), notamment ceux qui ne veulent pas recourir à Ansible ou à des outils du type Intune. L'auteur précise que Bor se distingue par son agent avec politique de sécurité renforcée : pas d'exécution de scripts arbitraires pour éviter un risque de RCE, et une livraison push via un flux gRPC persistant chiffré en mTLS. Ce choix technique est salué par plusieurs intervenants, car il évite d'ouvrir des ports entrants sur les postes et supprime la gestion de clés SSH. L'anti-dérive est aussi apprécié : verrouillage via dconf locks, marqueurs KDE Kiosk, et détection par inotify en cas de modification externe.
Les commentaires apportent des précisions et nuances sur l'article. L'auteur reconnaît que l'authentification est limitée à LDAP (pas de SAML/OAuth pour l'instant), que les scripts personnalisés sont délibérément exclus, et que la documentation reste à améliorer. Un intervenant signale que des outils comme Ansible ou Pyinfra couvrent un besoin similaire, tandis qu'un autre souligne l'intérêt de ne pas faire tourner SSH sur des laptops utilisateurs. Plusieurs questions portent sur la gestion des conflits de politiques (l'auteur évoque des priorités et un rollback immédiat si un paquet écrase un fichier), et sur des cas d'usage comme le contrôle parental (non prévu directement, mais possible via PAM ou DNS over HTTPS). Un commentateur demande le support de SCAP pour les STIGs, ce qui n'est pas encore envisagé.
La discussion confirme globalement la pertinence du projet, tout en nuançant son degré de maturité. Les limitations (auth LDAP-only, absence de scripts, pas encore de SCAP) sont assumées par le créateur, qui planifie certaines évolutions mais privilégie la sécurité et la simplicité du périmètre. Les échanges montrent un intérêt marqué pour les mécanismes techniques, notamment le modèle push/mTLS et l'anti-dérive, mais aussi une attente de compatibilité avec des environnements réels (Cinnamon, non-domain users) et des fonctionnalités plus avancées.
-
F*: A general-purpose proof-oriented programming language
F* est un langage de programmation orienté preuve, combinant types dépendants, automation par solveurs SMT et preuve interactive par tactiques. Il compile par défaut vers OCaml, avec des fragments vers F#, C, Wasm ou assembleur, et est développé par Microsoft Research, Inria et la communauté.
Open source sous licence Apache 2.0, F* est utilisé pour des projets de haute assurance comme Project Everest, HACL*, ValeCrypt et EverCrypt (cryptographie vérifiée), ainsi qu'EverParse, un générateur de parseurs utilisé notamment dans Windows Hyper-V pour l'analyse des paquets réseau d'Azure. Le langage fait également l'objet de recherches actives en logique de séparation et vérification formelle.
La discussion porte principalement sur l'accessibilité de F* et son utilité pratique. Plusieurs commentateurs regrettent l'absence d'exemples de code sur la page d'accueil, qui rend difficile la compréhension de la syntaxe et des cas d'usage ; l'un d'eux suggère de mettre un bac à sable en évidence, comme pour un jeu vidéo. En réponse, d'autres signalent qu'une capture d'écran existe et que des liens vers la section « Learn F* » sont présents, ce qui nuance la critique sur le manque d'illustrations.
Un commentateur ayant apparemment utilisé F* se dit satisfait de pouvoir exprimer l'appel de bibliothèques externes lors d'une migration incrémentale de code C existant, ce qu'il juge « très solide ». Cette précision répond indirectement à la question de savoir si le langage est utile pour les compilateurs et la preuve formelle : un autre intervenant confirme que c'est l'objectif principal, en le rapprochant d'Agda et de Coq.
Un avis plus critique émerge toutefois : F* est perçu comme un assemblage de plusieurs langages et systèmes de preuve, difficile à maîtriser, et un commentateur doute même qu'il gère correctement des opérations de base comme la soustraction ou les entiers non signés (u8), contrairement à Lean. Cette remarque, bien que minoritaire, tempère l'enthousiasme général et souligne un possible défaut d'ergonomie pour les débutants.
-
Linux desktop market share has hit over 10% in North America
D'après le titre, la part de marché du système d'exploitation Linux sur les desktop a dépassé 10 % en Amérique du Nord.
La discussion tourne presque entièrement autour de la fiabilité des chiffres de StatCounter, source de l'article. Plusieurs commentateurs jugent ces statistiques « invraisemblables » ou « une blague », pointant des incohérences internes comme la séparation entre « OS X » et « macOS » (avec une part de 21% pour OS X, abandonné depuis 11 ans, contre 8,6% pour macOS), ce qui jette le doute sur le reste. Un commentaire note que les chiffres correspondent à StatCounter si l'on filtre par Amérique du Nord, mais l'absence de méthodologie et la possibilité de bots de scraping identifiés comme Linux sous IP américaines rendent les données peu fiables. D'autres sources sont citées, avec des valeurs divergentes : Cloudflare montre 6% en trafic « humain probable » (9,3% avec bots), Steam environ 7%, et un commentaire évoque « 0% » pour BSD. Un commentateur suggère que l'augmentation récente pourrait venir d'une erreur de configuration de ChromeOS, dont la part chute au même moment selon Cloudflare.
Sur le fond, plusieurs avis s'accordent pour dire que Linux gagne du terrain, mais pas à ce point. Le développement du gaming est cité comme un déclencheur, ainsi que la « enshittification » de Windows et le désengagement de Microsoft du marché du desktop grand public. Certains praticiens témoignent d'une productivité supérieure sous Linux, et un commentaire évoque l'impact des bots et scrapers qui utilisent des navigateurs Linux pour contourner les blocages. Un commentaire minoritaire estime que « la digue est rompue » et que Linux est prêt pour l'adoption grand public, mais il est contrebalancé par le scepticisme général. La discussion insiste aussi sur la difficulté de mesurer le marché réel, beaucoup d'utilisateurs se contentant d'un téléphone et d'une tablette, et sur le fait que les données de StatCounter sont jugées tellement peu fiables que « discuter de ces chiffres, c'est comme discuter des numéros du loto de la semaine dernière ».
-
Atom is better than RSS, in ways that matter
L'auteur plaide pour l'utilisation d'Atom plutôt que RSS, arguant qu'Atom est techniquement supérieur et mieux défini. Il détaille des différences concrètes qui posent problème en RSS, notamment l'absence de sémantique d'encodage pour les titres, ce qui empêche d'y inclure fiablement du HTML. Il évoque aussi la distinction résumé/contenu complet, et mentionne les podcasts comme exception où RSS reste dominant, en partie à cause d'Apple.
Plusieurs commentateurs partagent l'avis de l'article : Atom est techniquement plus solide que RSS (horodatages non ambigus, encodage clair, possibilité de distinguer résumé et contenu complet). Mais ils s'accordent à dire que pour l'utilisateur final, la différence est minime : la plupart des lecteurs de flux acceptent les deux, et le format choisi n'affecte ni la lecture ni l'abonnement. Certains vont plus loin en proposant JSON Feed comme alternative plus pratique, notamment parce qu'il évite XML et permet de générer un flux sans bibliothèque dédiée.
Le principal point de discorde est la défense du HTML dans les titres par l'auteur. Plusieurs commentateurs jugent cette possibilité inutile et source d'erreurs de parsing, tandis que l'auteur rétorque qu'elle préserve l'emphase ou le code dans les titres de blogs techniques. La discussion corrige aussi l'article sur un point pratique : le podcasting reste très majoritairement sous RSS, avec des extensions iTunes, et Apple Podcasts a abandonné Atom. Un commentateur raconte l'incident historique du tag
Enfin, l'article est nuancé sur la facilité de production d'Atom : un commentateur souligne que son exigence de XML valide impose une conversion XHTML5 et des URLs absolues, ce qui complique la vie des sites statiques. Un autre mentionne les trois façons d'encoder un titre dans Atom, jugées confuses. Certains comparent le débat au concept de « worse is better » ou à la guerre du Betamax contre le VHS, rappelant qu'un format techniquement supérieur ne s'impose pas forcément. Pour un développeur, le conseil pratique qui ressort : utiliser Atom pour les nouveaux flux, mais RSS pour les podcasts. Un commentateur pose aussi une question concrète sur le stockage des flux en base de données, avec des conseils sur l'utilisation des GUID et du polling.
-
Unraveling the mysteries of habit formation
Des chercheurs de l'Université de Kyoto ont développé une méthode d'entraînement accéléré pour étudier la formation des habitudes chez la souris. Ils ont identifié deux circuits neuronaux distincts : l'un détermine si un comportement devient une habitude, l'autre contrôle l'intensité de son exécution, expliquant les différences individuelles. Cette découverte pourrait aider à mieux comprendre les troubles liés aux habitudes comme le trouble obsessionnel-compulsif.
La discussion prolonge l'article sur la formation des habitudes chez la souris par des retours d'expérience personnels et des débats de fond. Plusieurs commentateurs s'accordent sur l'idée que les habitudes, une fois installées, deviennent faciles à maintenir, mais divergent sur la facilité à les briser. Un praticien corrige d'ailleurs une affirmation de l'article : certaines habitudes comme la consommation d'héroïne sont beaucoup plus difficiles à rompre que d'autres, et la difficulté varie selon les individus et les habitudes elles-mêmes.
La discussion apporte un éclairage critique sur la méthode de l'article. Un commentaire souligne qu'il serait prudent d'ajouter la mention « chez la souris » aussi systématiquement que « année » ou « vidéo », car les résultats ne se généralisent pas toujours à l'humain. Un autre répond que les souris sont un organisme modèle pertinent, ce qui limite la portée de cette critique. Par ailleurs, un échange oppose le maintien d'une attitude positive à la « positivité toxique » : ignorer ses émotions négatives peut mener à de la rancœur, alors qu'il vaut mieux les reconnaître et communiquer sur leurs causes.
Enfin, plusieurs commentateurs partagent des retours de terrain : il est très difficile de reprendre une habitude perdue, même si on l'avait automatisée auparavant. Un avis compare cela à un « aller simple » vers une nouvelle vie une fois la routine établie, mais une seule rupture suffit à réaliser que ce n'est qu'une option parmi d'autres, rendant la reprise moins engageante. Un autre émet l'hypothèse que le circuit neuronal identifié pourrait permettre de créer des habitudes quasi instantanément, ce qui n'est pas directement testé dans l'article.
-
ASRock BC-250: Building the Budget Steam Machine
Guide complet de configuration de l'ASRock BC-250, une carte de minage recyclée en console Steam pas chère. L'auteur partage quatre conseils essentiels : allouer 6 Go de VRAM au lieu de 512 Mo, désactiver le pré-téléchargement des shaders Steam, undervolter et overclocker le CPU, et désactiver le démon HHD sur Bazzite pour éviter des stutters.
Le guide détaille ensuite le BIOS, le refroidissement, l'installation du governor GPU cyan-skillfish-smu pour un scaling dynamique des fréquences, et le déblocage des 40 CUs du GPU masqués par défaut. Il couvre aussi l'overclocking et l'undervolting du CPU via l'outil bc250-smu-oc, avec des instructions spécifiques pour CachyOS et Bazzite. L'ensemble vise à maximiser les performances et l'efficacité énergétique de cette plateforme.
La discussion confirme l'intérêt pratique du BC-250 comme base de console Steam à petit budget, mais nuance fortement l'article sur plusieurs points. Les commentateurs s'accordent sur le fait que les prix ont grimpé depuis l'époque du déversement par les mineurs : un intervenant rapporte avoir vu des racks entiers à 66 $ par carte, alors que les prix eBay actuels tournent autour de 200 $ et plus, ce qui en fait une option « trop chère pour ce que c'est » pour certains. Un utilisateur ayant monté sa machine témoigne d'une expérience positive : il a fini des jeux récents (Spider-Man 2, Hogwarts Legacy) avec une consommation réduite et un silence amélioré, malgré quelques crashs. Plusieurs précisions techniques sont apportées : un développement récent permet de débloquer 2 cœurs CPU supplémentaires (8 au lieu de 6), et la liste des jeux compatibles s'allonge (Cyberpunk 2077 inclus).
La discussion corrige un bug dans le script de l'article : le chemin vers le binaire stress est mal codé, avec un chemin absolu vers le home de l'utilisateur qui ne fonctionne pas tel quel. Les tests de ventilateurs sont également approfondis : le CFM est le facteur limitant, et des modèles comme le Phanteks T30-120 (30 mm d'épaisseur) offrent un meilleur débit que le Noctua, à condition de modifier l'impression 3D. Un intervenant qui a géré 20 000 de ces cartes en mining rappelle que les concepteurs ignoraient eux-mêmes les CU verrouillés, et voit dans cette seconde vie un contre-argument à la critique de l'e-waste minier.
Les avis divergent sur la facilité du projet : certains le trouvent trop impliqué comparé à une vraie Steam Machine, tandis que d'autres soulignent la flexibilité de SteamOS/Proton sur du matériel récupéré. En réponse à une question, la consommation au repos est mesurée entre 10 et 20 W, et l'installation d'un gouverneur la réduit de 85-105 W à 65-85 W selon la doc. Le HDMI CEC ne fonctionne pas nativement, mais des adaptateurs et une solution ESP32 pour allumer la console via Bluetooth existent.