Hacker News
-
Anthropic's best AI model struggles to attract users as cheaper tools thrive
Selon le titre, l'article aborde les difficultés du meilleur modèle d'Anthropic à attirer des utilisateurs, alors que des outils moins chers prospèrent sur le marché.
Les commentateurs convergent sur un point : les changements incessants de tarification et de quotas d'utilisation d'Anthropic (promotions, A/B tests, bugs de facturation) créent une anxiété qui décourage de s'appuyer sur le service au quotidien. Plusieurs comparent l'IA à l'électricité, qu'on veut stable et prévisible, et déplorent un « jeu de marchandage » permanent. Le style d'écriture de Claude est aussi vivement critiqué : jugé « punchy », « LinkedIn », voire « psychologiquement nuisible », certains le font réécrire par un autre modèle. En revanche, la discussion nuance fortement l'article : un utilisateur du plan à 200 $ décrit une session autonome de 24 heures avec Fable (2 milliards de jetons, un projet migré de Spark vers Pandas) sans bug, qu'il estime valoir bien plus que son coût API de 2 000 $. Un autre rétorque que la lenteur explique ces longues durées.
La qualité des modèles divise. Plusieurs estiment qu'Opus 5 est en réalité moins bon qu'Opus 4.8, plus lent et bridé, et suspectent Anthropic de l'avoir volontairement affaibli pour pousser les utilisateurs vers Fable, plus cher. Beaucoup restent donc sur Opus 4.8, ce qui expliquerait les statistiques de faible adoption du nouveau modèle. Une minorité affirme que Fable est imbattable pour les tâches longues, tandis que d'autres sont partis vers GPT 5.5/5.6, jugé meilleur et moins cher. Les garde-fous de sécurité sont un autre point de friction : un programmeur dit se faire traiter en criminel pour des projets de rétro-ingénierie légaux, alors que le même prompt passe sans problème chez Codex. Un commentateur estime que ces plaintes sont « hors sol » vu l'IPO annoncée d'Anthropic.
Enfin, des considérations d'entreprise et de confidentialité apparaissent : l'absence de ZDR (zero data retention) pour Fable bloque son déploiement chez certains clients, et un non-utilisateur s'inquiète de la fuite d'IP via les prompts. Un autre répond que les grands comptes signent des contrats protégeant leurs données.
-
I spent $266 and four AI models to own my tablet. GLM-5.3 finished it in a day
Un utilisateur raconte comment il a dépensé 266 $ en services d'IA pour rooter sa tablette Amazon Fire HD 10 (2021) qui s'éteignait toute seule. Après des mois avec Claude sans succès, Kimi K3 a trouvé une faille (CVE-2022-38181) dans le pilote Mali, exploitée après 30 heures et 164 $ de session. GLM-5.2 a corrigé l'approche pour 21,90 $, et GLM-5.3 a terminé en un jour. L'auteur note que les modèles américains (Claude, OpenAI) ont refusé des tâches de cybersécurité légitimes, tandis que les modèles chinois ont aidé, illustrant un contraste géopolitique.
La discussion est mince mais apporte un retour de terrain et une critique. Un commentateur raconte une session où un agent IA a mené à bien un débogage complexe (extraction du dyld cache iOS, montage APFS) pour résoudre un problème HomeKit, illustrant l'autonomie croissante des modèles. L'autre commentaire juge l'article ennuyeux à cause de son ton rédigé par IA, et en donne l'essentiel : les modèles ont trouvé des vulnérabilités non patchées et créé un exploit pour rooter la tablette, les modèles chinois y parvenant tandis que les américains se sont arrêtés par sécurité. Ce résumé est cohérent avec le titre, mais précise un point que l'article semble traiter de manière moins nette : l'écart de comportement entre modèles chinois et américains face aux garde-fous. Aucun désaccord majeur, mais une divergence d'appréciation sur l'intérêt du récit : l'un le trouve révélateur d'une époque étrange, l'autre le juge superflu une fois le fait central connu.
-
I were 17, I'd learn how to build LLMs from scratch
Le titre suggère qu'à 17 ans, l'auteur apprendrait à construire des LLM à partir de zéro. Aucun contenu n'est disponible au-delà du titre.
La discussion conteste largement le conseil de l'article. Plusieurs commentateurs estiment que construire des LLMs from scratch n'est pas un chemin réaliste pour un adolescent : le domaine est saturé, les postes d'entraînement sont rares, et l'accès au matériel coûteux (clusters B200, etc.) est un obstacle massif. Un commentateur compare la situation à celle de l'étude du noyau Linux en 2000, où l'avantage était énorme, alors qu'aujourd'hui des milliers de personnes bidouillent les LLMs. D'autres soulignent un biais de survie chez l'auteur, ou citent la réponse cinglante de Yann LeCun pour rappeler que les modèles autorégressifs pourraient devenir obsolètes, comme les écrans CRT, et que les fondamentaux mathématiques comptent davantage.
Certains commentaires nuancés défendent néanmoins l'intérêt pédagogique : comprendre les LLMs de bout en bout aide à développer une intuition utile pour résoudre des problèmes, même sans en faire une carrière. Un praticien raconte avoir appris via les vidéos de Karpathy et les livres de Raschka, par simple curiosité, et en retire une meilleure compréhension des concepts de pointe. Des ressources pratiques sont partagées, comme les notes de cours CS336 de Stanford, nanoGPT, ou un site gratuit qui enseigne la construction d'un LLM. D'autres rappellent que le fine-tuning de petits modèles existe bel et bien dans l'industrie (assurances, banques), corrigeant l'idée que seul l'entraînement massif compte.
Enfin, plusieurs voix s'écartent complètement du sujet tech : elles conseillent aux jeunes de privilégier les compétences sociales, l'équilibre de vie, la santé mentale, ou des filières stables comme la santé. Un commentateur note que le rythme des changements rend toute prédiction impossible et que les choix individuels pèsent moins qu'avant. Dans l'ensemble, la discussion corrige fortement l'optimisme de l'article en pointant la rareté des débouchés, l'importance des infrastructures, et la valeur incertaine de cette compétence à long terme.
-
How I find problems to solve as a staff engineer
L'article explique comment un staff engineer trouve des problèmes à résoudre : plutôt que de bloquer du temps pour réfléchir, il écoute le bruit quotidien, absorbe les difficultés des équipes, les laisse mûrir, puis cherche les schémas communs. Il illustre avec son travail sur Perfetto, où des demandes d'équipes différentes ont révélé un besoin commun de personnalisation de l'UI. Il insiste sur l'importance de tester ses hypothèses avant de construire, et de ne pas se fier à l'élégance apparente d'une solution.
Plusieurs commentateurs confirment la mise en garde de l'article sur la perte d'autonomie des ingénieurs. Un commentaire relate une expérience personnelle : malgré l'ancienneté, l'autonomie diminue, avec davantage de contrôles et d'approbations qu'il y a dix ans. Un autre précise que pour progresser au niveau staff, il faut refuser les tâches purement assignées et travailler sur des problèmes difficiles nécessitant collaboration, ce qui s'apparente souvent à du management technique.
Un avis minoritaire conteste l'utilité même du titre de staff engineer, le jugeant vide de sens et variable selon les organisations, et critique ce type de publications. À l'inverse, un commentateur du monde des startups souligne que les problèmes ne manquent jamais : le vrai défi est la priorisation, notamment en choisissant des solutions qui résolvent plusieurs problèmes à la fois, même si cela peut dérouter les collègues qui ne voient pas un travail direct sur le problème.
La discussion nuance l'article en montrant que la perte d'autonomie est un phénomène réel et vécu, pas seulement une hypothèse. Elle apporte aussi un éclairage différencié entre grands groupes et startups, et relativise l'importance du titre lui-même.
-
What Is a Harness?
L'article explique ce qu'est un « agent harness » (harnais d'agent), un logiciel qui fournit un environnement d'exécution à un modèle d'IA pour en faire un agent. Il compare ce concept à un harnais d'escalade : l'agent harness sécurise, guide et équipe le modèle. Il remplit quatre fonctions : fournir un « system prompt » (instructions), proposer des outils (recherche web, écriture de code, envoi d'e-mails), établir une boucle agentique (le modèle itère sur ses actions selon ses propres évaluations) et inclure une couche de traduction pour fonctionner avec différents modèles (Anthropic, OpenAI, open weight).
L'article souligne que, contrairement aux modèles, l'utilisateur peut posséder et adapter son harnais, ce qui lui donne du contrôle et de l'autonomie face aux laboratoires d'IA. Des exemples concrets comme Pi et OpenClaw sont cités, ainsi qu'un scénario où l'agent compare des écoles et envoie un e-mail de résultats avec un tableur en pièce jointe.
La discussion prolonge l'article en apportant surtout des retours de terrain. Un praticien raconte avoir construit un harness pour des agents comptables : il recommande vivement de doter les LLM d'un CLI interne, mais a abandonné l'approche par « skills » trop prescriptive. Selon lui, un agent suit mieux une liste de tâches s'il peut raisonner sur le travail à faire, à condition de disposer d'outils et de garde-fous. Ce retour nuance l'article en insistant sur la nécessité de laisser l'agent raisonner plutôt que de le sur-cadrer.
Un autre commentateur cherche un harness capable de gérer des « handoffs » : d'un terminal à une interface web, d'un membre d'équipe à un autre, d'un modèle à un autre, etc. Il regrette de perdre le contexte selon l'endroit où tourne le harness (VM isolée, machine locale avec GPU). Aucun outil existant n'est cité en réponse, ce qui suggère un manque. À l'inverse, un commentateur vante un harness précis (Pi) pour son système d'extensions, permettant de le transformer en trader, usine logicielle, etc. Ce point de vue est toutefois isolé et semble promotionnel.
Enfin, un commentateur prédit que « harness » deviendra le mot à la mode de 2026, tout en notant que certains produits présentés comme des agents restent en réalité du logiciel déterministe. Globalement, les commentaires enrichissent l'article par des cas concrets et des questionnements pratiques, mais sans le contredire frontalement ; l'ensemble reste centré sur l'écart entre la théorie du harness et son usage réel.
-
To become a better writer, read as much as you can
L'auteur, écrivain, défend l'idée que lire massivement est la règle d'or pour tout écrivain. Il constate avec inquiétude que de nombreux aspirants écrivains ne lisent plus, prétextant le manque de temps, alors qu'ils passent des heures sur leur téléphone. Il cite trois raisons principales : la lecture enseigne le métier (structure, style, genre), inspire en dehors de son propre genre, et modifie positivement le cerveau, contrairement à l'addiction numérique qui détruit l'attention et la capacité d'immersion.
Il compare les grands écrivains aux grands cinéastes, passionnés et cultivés, et critique l'IA générative qui permet à des gens qui n'aiment pas la littérature de produire des livres sans intérêt. L'article s'adresse aux écrivains sérieux et recommande un minimum d'une vingtaine de livres par an.
Plusieurs commentateurs valident l'idée que lire est indispensable pour écrire : cela forge le style, le vocabulaire, l'oreille et l'appartenance à une tradition, comme l'illustre l'analogie du musicien qui n'écoute pas de musique ou du programmeur qui ne lit pas de code. Certains témoignent d'un effet dit « memetic » : on imite inconsciemment les tournures de ses lectures, jusqu'aux tics des e-mails et des sorties de Claude. Un commentaire cite Hugh Howey pour qui les meilleurs écrivains sont les meilleurs lecteurs. Mais tous s'accordent à dire que lire ne suffit pas : la pratique de l'écriture quotidienne reste nécessaire, et plusieurs reprochent à l'article de confondre ambition littéraire et fiction de genre, où la lecture peut être remplacée par d'autres médias.
Les désaccords portent surtout sur la nature de la lecture. Un commentateur opposé affirme que « écrire autant que possible » est plus efficace que lire, car l'écriture révèle ses propres limites ; un autre insiste sur la lecture critique et sélective, citant Schopenhauer sur l'art de ne pas lire et le danger de laisser autrui diriger sa pensée. La qualité des lectures compte plus que la quantité : plusieurs dénoncent le bruit de l'édition actuelle, des livres calqués sur des séries TV, et recommandent de lire le type de texte que l'on veut produire. D'autres remarquent que lire améliore la reconnaissance mais pas l'usage actif du vocabulaire, et que le fait de lire beaucoup n'empêche pas de « rambler ».
La discussion corrige ainsi l'article : lire est une condition nécessaire mais non suffisante, et son universalité est nuancée. Le conseil devient « lire beaucoup, mais de manière critique et délibérée, et surtout écrire ». Des commentaires pointent aussi l'influence néfaste de l'IA et des textes médiocres sur le style, et l'importance de l'étude des œuvres des autres dans tout artisanat, y compris le code. Enfin, un avis minoritaire juge l'article daté, « pré-IA », et un autre le trouve confus et moralisateur.
-
My agent.md to improve LLM-assisted code quality
Retour d'expérience sur l'utilisation d'agents LLM pour la programmation. L'auteur relate ses essais entre mi-2025 et début 2026 : d'abord décevants, puis plus convaincants, mais avec un code de mauvaise qualité. Il a ensuite adopté un fichier `agent.md`, injecté dans le prompt au démarrage d'une session de codage, pour y consigner des préférences de style et des règles de production.
Il partage sa version d'`agent.md` : commentaires et messages concis, évitement des nombres magiques, réduction de l'indentation, noms de fonctions courts, enums plutôt que booléens, visibilité par défaut privée, respect des couches d'abstraction, règles pour les messages de commit, et écriture d'un test avant un correctif. Il note que cette approche améliore nettement la qualité du code, mais ne dispense pas d'une relecture.
Il évoque enfin le phénomène de « dilution de l'attention » des LLM (moins d'attention aux instructions du milieu du contexte) et suggère de faire mettre à jour `agent.md` directement par l'agent pour limiter son impact.
Plusieurs commentateurs estiment qu'une partie des règles proposées dans l'article relève davantage du linting que du fichier d'instructions. Par exemple, l'usage obligatoire des accolades ou la limite de 30 caractères pour les noms de fonctions sont des contraintes que l'on peut imposer automatiquement, afin que les développeurs qui écrivent encore le code à la main reçoivent le même type de retour. Un commentateur partage sa propre règle dite de « convergence » : chaque tâche substantielle doit aboutir à l'un de trois états — succès, progression significative, ou arrêt honnête avec preuves — pour empêcher l'agent d'enchaîner des patchs sans fin. Cette approche est jugée plus efficace que de longues listes de consignes stylistiques.
Un point de divergence net concerne les commentaires. Un intervenant interdit formellement à ses agents d'en ajouter : il relit lui-même le code et insère les explications manuellement. Si un bloc lui paraît incompréhensible malgré le contexte, il jette le code plutôt que de demander à l'LLM de commenter ce qu'il a fait, afin de préserver la lisibilité par les humains. À l'inverse, un autre participant recommande d'inscrire dans AGENTS.md une phrase unique : « Utilisez toujours l'anglais technique simplifié ASD-STE100 », ce qui, selon lui, réduit fortement le verbosité et le style grandiloquent des réponses de l'agent.
Un commentaire exprime un scepticisme de fond : ces consignes aident-elles réellement l'LLM à itérer sur le code, ou relèvent-elles d'un nitpicking humain que l'auteur de l'article ne regardera jamais ? Pour ce dernier, difficile de mesurer l'impact ; sa pratique consiste à faire trois passes — écriture, auto-revue, puis relecture — ce qui suffit pour obtenir du code fonctionnel sans avoir à tout lire. Dans l'ensemble, la discussion complète l'article en suggérant d'automatiser certaines règles via des linters et en insistant sur la nécessité d'éviter les instructions trop subjectives, tout en relativisant l'effet réel de ces fichiers sur la qualité du code généré.
-
A website for debloated open source alternatives
Un site web recense des alternatives open source allégées (debloated).
La discussion est globalement positive à l'égard du site présenté, perçu comme une alternative légère à Alternativeto.net. Plusieurs commentateurs louent sa rapidité et son absence de JavaScript, de cookies et de fioritures, le qualifiant de bien plus agréable que son concurrent, jugé « bloaty » et hostile. Un commentaire apporte des détails techniques concrets : le site fonctionne avec un navigateur texte, toutes les pages sont accessibles via un seul flux HTTP, et l'ensemble du contenu tient dans un fichier HTML de 1,9 Mo, ce qui illustre parfaitement la philosophie « débloatée ».
Cependant, un utilisateur signale un problème d'accès sous Firefox avec une erreur SSL (SSL_ERROR_INTERNAL_ERROR_ALERT), ce qui nuancent l'impression de perfection technique. Un autre commentaire suggère une amélioration d'interface : remplacer le champ texte pour la sélection des catégories par des cases à cocher, plus ergonomiques. Enfin, un participant profite de la discussion pour présenter son propre projet comparable, canireplaceit.com, qui vise à fournir des informations plus riches (licences, coût SSO, alternatives gratuites, raisons de non-remplacement), mais cet apport est considéré comme une digression promotionnelle plutôt qu'un retour sur l'article.
Dans l'ensemble, les commentaires confirment l'intérêt de l'approche minimaliste mais signalent un bug concret et une limite d'ergonomie, sans toutefois contredire le fond de l'article.
-
Google Workspace thinks my domain is an email provider (2025)
Un utilisateur rapporte un bug dans le formulaire d'inscription à Google Workspace : son domaine "web.*" est refusé avec le message « Enter a valid domain name instead of an email provider ». Le problème vient d'une validation JavaScript côté client qui utilise une liste de motifs d'adresses e-mail, incluant `web\.\..*` et `me\.\..*`. Cela a également affecté le domaine du ministère ukrainien de l'Économie (me.gov.ua). L'utilisateur a contourné le blocage en désactivant la fonction de validation dans le code source de la page, prouvant qu'il ne s'agit que d'une vérification frontale. Google n'a pas fourni de solution officielle, suggérant d'utiliser un autre domaine.
Plusieurs commentateurs confirment le problème décrit dans l'article : des domaines légitimes mais atypiques (comme 3e.org, détenu depuis 30 ans) sont refusés par la validation de Google Workspace, soit parce qu'ils sont trop courts, soit parce qu'ils commencent par un chiffre. Ils racontent contourner le blocage en désactivant la validation côté client, ce qui fonctionne la plupart du temps. L'un d'eux rappelle d'ailleurs que l'autorisation des chiffres en tête de domaine a fait débat à l'époque de l'ICANN. La discussion converge donc sur le caractère arbitraire et purement frontal de cette vérification.
Un commentaire met en garde contre la solution inventive proposée par l'auteur : il existe un risque non nul qu'une validation côté serveur existe aussi, et qu'un jour une opération devienne irrécupérable. Il recommande de ne pas s'engager dans des contournements fragiles. Par ailleurs, un commentateur relève que la réponse du support Google citée dans l'article est typique d'une réponse générée par un LLM : elle aborde un sujet hors de propos (domaines fictifs en .web) puis tente de se rattraper, ce qui souligne l'absurdité de la situation.
Globalement, les commentaires valident le constat de l'article mais en nuancent la portée : le contournement frontal n'est pas une solution robuste, et le support automatisé ne fait qu'ajouter à la frustration. La discussion n'apporte pas de données chiffrées, mais des retours d'expérience concrets qui corroborent et complètent le récit initial.
-
Slovakia finds Russian backdoor in traffic speed cameras
Les services de sécurité slovaques (NBU) ont détecté une backdoor dans les caméras de vitesse NERO R-ONE, acquises dans le cadre d'un projet de 30 millions d'euros financé par l'UE. Une alerte signale un accès shell et réseau via un SMS envoyé depuis des numéros russes codés en dur. Il s'agirait en réalité de caméras russes CORDON PRO.M de la société Semicon. Le rapport technique note aussi un SecureBoot désactivé, des vulnérabilités du portail web et des flux vidéo accessibles sans mot de passe. Sur les 279 caméras prévues, le déploiement est suspendu en attendant un audit indépendant. Des appareils similaires seraient en service en Croatie et ailleurs en Europe de l'Est.
La newsletter rapporte également une cyberattaque contre l'agence ukrainienne ARMA, chargée des avoirs russes saisis, et des attaques DDoS iraniennes (groupe 313 Team) ayant perturbé BlueSky et GitHub. Parmi les autres incidents : un ransomware à l'hôpital de Winnipeg, des fuites chez SafePal (40 000 clients) et Bits of Gold (250 000 clients), et la mise en vente de données d'employés de grandes entreprises.
Enfin, côté tech, Windows 11 abandonne l'outil WMIC, Firefox 154 intègre le support de GeForce Now et Firefox iOS gagne un ad blocker. En Russie, un tribunal a ordonné à des chaînes Telegram de retirer des posts liés à un incident de blocage des VPN.
La discussion enrichit l'article en apportant un contexte sur l'origine du matériel. Un commentaire principal relate que des caméras achetées ressemblaient exactement à des modèles russes, que le gouvernement a nié cette similitude, puis que les numéros de série ont finalement confirmé une correspondance, conduisant à une enquête. Le commentateur salue le fait que les autorités aient enquêté avant toute mise en service.
Un autre intervenant nuance fortement cette attribution : ces caméras sont très probablement fabriquées en Chine, car la Russie ne produit pas ses propres puces pour ce type d'équipement. Cette remarque jette un doute sur l'interprétation « backdoor russe » de l'article, suggérant une origine chinoise ou une simple coïncidence matérielle.
Enfin, un échange tangentiel évoque les onduleurs solaires chinois comme prochaine cible, mais une réponse sceptique en minimise la menace concrète. Dans l'ensemble, les commentateurs apportent une correction factuelle et une prudence sur l'attribution, sans pour autant trancher le débat.
-
How Complex Systems Fail
L'article explore la nature des systèmes complexes (transport, santé, production d'énergie) qui sont intrinsèquement dangereux. Des défenses multiples (techniques, humaines, organisationnelles) protègent contre les pannes, mais ces systèmes fonctionnent malgré des défauts permanents. Les accidents catastrophiques surviennent quand de petites défaillances apparemment innocentes se combinent, et il n'existe pas de « cause racine » unique.
L'auteur souligne le biais rétrospectif : après un accident, les observateurs surestiment la visibilité des signes précurseurs. Les opérateurs doivent constamment équilibrer production et prévention des accidents, leurs actions étant des paris face à l'incertitude. L'expertise humaine reste essentielle, et les organisations entretiennent une ambiguïté sur les risques acceptables. Le texte est une réflexion théorique, sans application directe à un domaine technologique précis.
La discussion valide largement l'article, vu comme un texte fondateur difficile à apprécier sans avoir vécu des défaillances réelles de systèmes complexes. Plusieurs commentateurs insistent sur l'idée que la recherche d'une « cause racine » unique est trompeuse : un incident déclencheur peut disparaître alors que l'état de panne persiste (défaillance métastable), et l'on découvre alors plusieurs causes imbriquées. Un exemple concret est donné avec un système de verrouillage distribué qui entraîne un effondrement en cascade du déploiement. L'accent est mis sur la banalité des défaillances dans ces systèmes, qui continuent de fonctionner grâce à la redondance et à l'intervention humaine, ce qui rejoint la notion de « proto-accidents » évoquée dans l'article.
La discussion apporte un cadre conceptuel : ce courant est identifié sous le nom de « Safety II » par plusieurs intervenants, qui recommandent les travaux d'Erik Hollnagel et Sydney Dekker. Une comparaison est établie avec les enquêtes sur les accidents aériens, où l'on retrouve la même complexité et la même impossibilité d'attribuer une cause unique. Un commentateur mentionne également des ouvrages de référence comme Normal Accidents et Meltdown. Un avis minoritaire relève une coquille ou une tournure étrange dans la première phrase (« by THE own nature »), sans remettre en cause le fond.
Aucun contradicteur sérieux ne se manifeste : les commentaires convergent pour réaffirmer la justesse de l'article, notamment l'affirmation que l'attribution d'une « cause racine » est fondamentalement erronée. Les informations concrètes apportées sont essentiellement bibliographiques et conceptuelles, plutôt que des corrections factuelles. La discussion enrichit donc la lecture de l'article en le reliant à des domaines variés (informatique distribuée, sécurité aérienne, ingénierie de la résilience).
-
I gave Qwen 3.8 27B a reverse-engineering job and it finished in 30 minutes
Un utilisateur a testé Qwen 3.8 27B, un modèle open-weights, sur une tâche de rétro-ingénierie : déconstruire le système de vérification de licence d'une application commerciale. Exécuté entièrement en local sur une station Lenovo ThinkStation PGX (puce Nvidia GB10 Grace Blackwell, 128 Go de mémoire unifiée), le modèle a d'abord refusé de contourner la protection, détectant la tentative de jailbreak et identifiant le vrai développeur. Il a ensuite produit un audit complet, puis a finalement construit un bypass fonctionnel.
Via analyse statique uniquement, sans jamais lancer l'application, Qwen a désassemblé des milliers de lignes d'arm64, retrouvé une clé de vérification publique volontairement cachée dans le binaire, et a reconstitué le schéma d'activation : vérification de signature, liaison au matériel, liste de révocation et chemin de mise à jour signé. Le modèle a même corrigé sa première erreur (une clé presque juste mais un hash non conforme) et achevé la tâche en environ 30 minutes, produisant un proof-of-concept opérationnel.
L'auteur souligne que c'est un seuil significatif pour un modèle local de 27B tournant sans cloud, tout en notant les limites : un seul test, un seul logiciel, et des performances inégales possibles sur d'autres cibles. Il conclut que la capacité de rétro-ingénierie n'est plus réservée aux modèles frontier ou aux serveurs distants.
Plusieurs commentateurs estiment que la tâche de rétro-ingénierie décrite, avec un test clair de type vrai/faux, n'est pas la plus difficile et correspond précisément au domaine où l'IA excelle. Ils notent qu'une analyse statique seule n'est pas le plus dur de la rétro-ingénierie et que, pour les petits modèles, la limite vient surtout de la taille de contexte utilisable. Certains louent la persistance de Qwen à vérifier son travail (il a corrigé un hash d'intégrité), mais ce point est nuancé par une citation de Linus Torvalds où l'IA déclare une tâche impossible, et par un commentateur qui met en garde contre les généralisations sans paramètres contrôlés.
La discussion aborde aussi la sécurité et les modèles locaux. Plusieurs intervenants estiment que les garde-fous des modèles locaux sont une perte de temps, puisque des versions non censurées existent déjà et que la criminalité organisée y a accès. L'un mentionne qu'un ancien employé d'Anthropic aurait révélé un accès au modèle « Mythos » conditionné par le niveau de dépenses. Un autre rapporte qu'une campagne de piratage attribuée au gouvernement chinois aurait utilisé Claude Code en compartimentant les tâches. Un utilisateur pratique décrit avoir utilisé Qwen localement pour organiser factures et contrats, mais d'autres le mettent en garde contre les risques de connecter le modèle à sa messagerie sans sauvegardes hors ligne.
L'article est également corrigé : un commentateur a remarqué que la capture d'écran montrait Claude Opus au lieu de Qwen, et l'auteur a reconnu l'erreur en disant qu'il la corrigeait. Un benchmarkeur indique que Deepseek-v4-flash a surpassé Qwen 3.8 27B en rétro-ingénierie, ce qui nuance la portée de l'anecdote. Enfin, l'auteur précise que l'outillage utilisé était Pi avec des outils Bash uniquement, répondant à une demande de détails sur le harnais.
-
Wi-Fi 8 is the first wireless upgrade in years that isn't chasing speed
Le Wi-Fi 8, standard IEEE encore en développement et attendu pour 2028, abandonne la course aux débits pour se concentrer sur la fiabilité. Baptisé « Ultra High Reliability », il conserve les mêmes caractéristiques que le Wi-Fi 7 (débit maximal, modulation 4096-QAM, canaux de 320 MHz) mais vise une amélioration de 25 % du débit effectif, une réduction de 25 % de la latence et des pertes MPDU, notamment dans les environnements chargés. De nouvelles technologies comme les unités de ressources distribuées (DRU), les pilotes d'atténuation des interférences ou les modulations inégales sont introduites pour mieux gérer les conditions réelles, avec l'objectif de rivaliser avec la 6G. L'article suggère que, pour ceux qui envisagent de passer au Wi-Fi 7, il pourrait être préférable d'attendre le Wi-Fi 8, dont les premiers appareils devraient apparaître en 2028.
La discussion converge sur un constat : le Wi-Fi 8 a raison de délaisser la course au débit théorique pour se concentrer sur la fiabilité, la latence et l'itinérance. Plusieurs commentateurs expriment des besoins concrets en environnement professionnel (entrepôts, VoIP) où la stabilité et le roaming piloté par l'infrastructure priment sur des débits faramineux. Un retour de terrain souligne que des scanners en entrepôt souffrent d'une connexion Wi-Fi capricieuse alors que le DECT fonctionne parfaitement, illustrant le fossé entre les promesses marketing et la réalité. D'autres partagent des expériences domestiques : un utilisateur a vu son débit réel doubler en passant d'un AP Wi-Fi 6E à un Wi-Fi 7 dans une maison en brique, mais beaucoup constatent que leur connexion Ethernet gigabit est déjà suffisante et que les vitesses Wi-Fi actuelles dépassent les besoins courants, sauf pour des transferts locaux ou des jeux exigeants en latence.
Les commentateurs s'accordent pour critiquer la métrique du débit théorique maximal par bande, jugée « totalement inutile » et trompeuse, avec des conditions irréalistes (à quelques cm du point d'accès, sur un site dégagé). Un avis minoritaire relativise en expliquant que les gains absolus diminuent en pourcentage à mesure que les vitesses augmentent, mais que le Wi-Fi est déjà « assez rapide » pour la plupart des usages. La principale divergence porte sur l'utilité réelle des nouvelles fonctionnalités : certains estiment que le Wi-Fi 7 est déjà un bond significatif en pratique, tandis que d'autres soulignent que des fonctionnalités comme la MLO (multi-link operation) sont « surtout une arnaque » dans l'implémentation actuelle, même sur du matériel enterprise récent, et qu'il faudra attendre le Wi-Fi 9 pour une version stable et déboguée, reprenant le cycle habituel des générations précédentes.
Plusieurs commentaires nuancent ou contredisent l'optimisme de l'article sur la faisabilité réelle.
-
Over 170k Nonprofits Lost All Their Data. Is Microsoft to Blame?
Près de 171 000 petites organisations à but non lucratif auraient perdu l'intégralité de leurs données stockées sur OneDrive après la suppression par Microsoft de ses licences gratuites pour les ONG, selon des témoignages rapportés par Slate. Des responsables d'associations expliquent n'avoir reçu aucun avertissement clair ou n'avoir pas vu les notifications envoyées sur des comptes administrateurs rarement consultés. Microsoft affirme avoir prévenu les clients dès le printemps 2025 et proposé un accompagnement, mais plusieurs usagers estiment que l'information était trop discrète. La fin du programme, qui bénéficiait à environ 400 000 organisations, a laissé de nombreuses petites structures sans solution de remplacement, faute de budget.
La discussion reproche d'abord à Microsoft sa communication : plusieurs commentateurs soulignent que les e-mails d'avertissement sont envoyés en masse, ce qui provoque une « fatigue d'alerte » chez les administrateurs, et que l'entreprise aurait dû instaurer une période de transition graduelle (accès admin seul, OneDrive en lecture seule) plutôt qu'une coupure brutale. L'absence d'excuses et la communication « orwellienne » de Microsoft sont également critiquées, certains y voyant une incapacité américaine à reconnaître ses torts.
Un point factuel important contredit l'article : un commentateur cite la documentation officielle Microsoft qui prévoit une conservation des données pendant 90 jours après l'expiration de la licence. Or, dans le cas rapporté, la licence avait été renouvelée et confirmée jusqu'en octobre 2026, et les données ont pourtant été supprimées. Ce décalage entre la politique annoncée et la réalité des systèmes est relevé, certains notant que même les employés de Microsoft ignorent comment fonctionnent réellement leurs propres services.
Plus largement, la discussion met en cause la direction de Microsoft, jugée obsédée par la croissance des abonnements au détriment de la fiabilité. Un avis minoritaire élargit le propos à la fragilité du cloud et des supports numériques, rappelant que les archives contemporaines risquent de disparaître. Un commentaire hors-sujet sur Windows est ignoré.
-
My favorite nonfiction books about cults, scams, and schemes
Article de Hacker News listant les livres de non-fiction préférés de l'auteur sur les sectes, les arnaques et les escroqueries. Aucun contenu disponible au-delà du titre.
La discussion enrichit la liste de l'article par de nombreuses recommandations. Plusieurs titres reviennent : « Little Bosses Everywhere » pour les arnaques MLM, « Underground » de Murakami sur la secte Aum, « Seductive Poison » sur Jonestown, « Bad Blood » pour Theranos, « The Electric Kool-Aid Acid Test » ou encore « Mindfuckers » sur les sectes des années 60-70. Un commentateur propose aussi le modèle BITE (comportement, information, pensée, émotion) comme grille de lecture transversale des groupes autoritaires, des sectes religieuses aux systèmes de vente pyramidale. D'autres évoquent des ouvrages plus généraux comme « Fads and Fallacies » de Martin Gardner ou « The Cult of Trump » pour l'actualité.
Plusieurs commentaires corrigent ou nuancent l'article. Un débat porte sur la fiabilité des mémoires et récits de témoignage : un avis les rapproche de la fiction, difficiles à vérifier, et recommande de se tourner vers des sources académiques, mais un autre commentateur, se présentant comme universitaire, doute que les articles scientifiques soient plus fiables. Surtout, le livre de Michael Lewis sur SBF est vivement critiqué : il aurait brisé la crédibilité de l'auteur aux yeux de plusieurs lecteurs, qui lui reprochent de se laisser éblouir par des personnalités charismatiques et de s'appuyer sur le recul historique quand il écrit sur des événements en cours.
Un témoignage personnel apporte un éclairage concret sur la double nature des sectes : l'aide initiale ressentie, puis l'endettement et l'isolement progressif, jusqu'à la peur de lire des livres non suggérés. Ce récit illustre le mécanisme d'emprise décrit plus haut. Enfin, un commentaire marginal, confus, évoque des théories sur la manipulation mentale à distance et les programmes de la CIA, sans lien direct avec les livres recommandés. Globalement, la discussion confirme l'intérêt du sujet mais insiste sur la prudence méthodologique face aux récits personnels.
-
Malware infects Android-based automotive head unit firmware
Des chercheurs de Kaspersky ont découvert un nouveau malware Android infectant les autoradios (head units) sous Android via le mécanisme de mise à jour intégré. Le malware, un téléchargeur multi-étapes, vise la fraude publicitaire et la création d'un botnet proxy. C'est le premier cas documenté de malware avec une chaîne d'infection spécifique à ce type d'appareil. L'activité est attribuée au groupe MoYu, lié au botnet BADBOX.
La chaîne d'infection commence par l'application système TWCore, légitime, qui reçoit des commandes via un broker MQTT pour installer des APK. Un flag 'installNotExists' permet d'installer des applications non présentes à l'origine. Le malware (JarService) est un dropper sans UI qui décrypte des blocs XOR, puis charge un loader qui communique avec un serveur C2 pour télécharger le stade 3. Ce dernier exécute neuf commandes pour afficher des publicités, commettre des fraudes publicitaires ou servir de proxy.
La discussion corrige d'abord une ambiguïté de l'article : le malware ne touche pas Android Auto (protocole de mirroring exécuté sur le téléphone), mais des autoradios après-vente chinois bon marché fonctionnant sous Android. Il est diffusé via des mises à jour OTA officielles du constructeur, sans auto-propagation, et s'apparente aux box TV Android pré-infectées en usine. Plusieurs commentateurs soulignent l'absence de CVE et d'informations précises sur la version d'Android ou le modèle concerné.
Sur le fond, beaucoup s'accordent sur le risque limité mais réel : l'autoradio peut exfiltrer des données sensibles (localisation, contacts, journaux d'appels) et être recruté dans un botnet ou servir de proxy résidentiel, surtout s'il est relié à un modem ou une carte SIM. Un débat oppose ceux qui estiment que les autoradios après-vente ne sont pas connectés au bus CAN et ceux qui rappellent que certains OEM le sont, ce qui pourrait permettre des actions dangereuses. D'autres évoquent une propagation latérale vers le téléphone appairé.
Un avis minoritaire juge que le malware de fraude publicitaire ne cible pas l'utilisateur, donc ce n'est pas vraiment un malware. Certains commentateurs en profitent pour critiquer la sécurité de l'industrie automobile, souhaiter des kits de « désmartification » ou ironiser sur l'avenir des antivirus pour voitures. Enfin, plusieurs notent que l'attaque nécessite de compromettre les serveurs de mises à jour du fabricant, souvent peu sécurisés, et que l'article exagère peut-être la menace.
-
GLM-5.3 (open-weight) beat Anthropic/OpenAI models – for 1/5 the cost
Le benchmark Featherbench (28 tâches réelles) place GLM-5.3 comme premier modèle à réussir 100% sur les cinq catégories (code, données, réel, sécurité, outils), avec un coût de 0,28 $ par parcours, mais un délai de première réponse de 16,3 s. GPT-5.5 est plus rapide (13,2 s) pour un coût de 1,43 $ et 89% en réel. Le modèle open-weight devance nettement les modèles Anthropic/OpenAI en coût par tâche.
Le classement note des refus côté Anthropic : fable-5 et opus-5 ont vu des tâches bloquées par un filtre fournisseur, et opus-5 affiche 43% en code à cause de ces blocages. Les modèles gpt-5.6 (luna, terra, sol) ont un taux d'échec sécurité de 33-50% (jailbreak). kimi-k3 garde le meilleur score de qualité (9,5) mais est lent. Le benchmark est open source (Featherbench, MIT).
La discussion remet fortement en cause la crédibilité de l'article, jugé par plusieurs commentateurs comme « clairement généré par Claude » et donc difficile à prendre au sérieux. Ils pointent une contradiction avec des références comme Artificial Analysis ou le leaderboard d'agents d'Arena, et s'interrogent sur la saturation du benchmark : « presque 10 modèles dépassent 95 % », ce qui indiquerait un test trop facile ou biaisé. Un avis concret conteste la présence de Haiku, un modèle jugé « sans intérêt » en pratique, parmi les meilleurs, et note que la qualité des rubriques est évaluée par un autre LLM (Fable 5), ce qui affaiblit la mesure. L'ensemble est perçu comme très assisté par IA, ce qui n'arrange pas la confiance.
En réponse à la première accusation d'IA-génération, un commentateur dénonce une « tendance inquiétante » sur HN : des accusations non fondées et sans preuve en tête de fil, assimilées à une « chasse aux sorcières » ou à du « virtue trolling ». Il plaide pour que les modérateurs interviennent, car cela dilue la discussion et décourage les commentaires de fond. Cette opposition illustre un désaccord sur la méthode : certains rejettent l'article a priori à cause de son style, d'autres y voient une réaction émotionnelle qui nuit au débat.
Enfin, une prédiction pragmatique est formulée : même si les modèles chinois open-weight égalent ou dépassent légèrement les modèles occidentaux, les entreprises continueront de payer pour Claude ou ChatGPT, pour l'écosystème, les intégrations et la tranquillité d'esprit, plutôt que de s'appuyer sur des clouds chinois. Ce commentaire modère l'impact commercial du résultat présenté, sans pour autant valider les scores. Dans l'ensemble, la discussion n'apporte pas de données de terrain, mais signale que les benchmarks sont probablement saturés et que l'article manque de robustesse méthodologique.
-
MartyPC is a cross-platform emulator of early PCs written in Rust
MartyPC est un émulateur multiplateforme des premiers PC, écrit en Rust. L'article, partagé sur Hacker News, ne fournit pas de détails supplémentaires.
Plusieurs commentateurs saluent le choix de Rust pour l'écriture d'un émulateur : la gestion de la mémoire et du threading simplifiée permet de se concentrer sur la précision, et MartyPC est jugé très fidèle. Un praticien apprécie notamment le support de la carte Adlib, en rappelant qu'elle coexistait avec la Soundblaster, tandis qu'un autre évoque sa carte Covox maison.
La discussion est en partie méta : beaucoup de commentaires portent sur le titre « written in Rust » plutôt que sur l'émulateur. Certains s'agacent de cet étiquetage, d'autres le défendent, allant jusqu'à se demander pourquoi on ne voit jamais « written in C ». Un commentaire ironise que « written in Rust » signifierait désormais « écrit par Claude » (un LLM). Sur le fond, plusieurs limitations sont signalées : absence de support des claviers non-QWERTY, mappage inhabituel de la barre oblique inversée en retour arrière (avec un précédent historique), et le nom MartyPC prête à confusion avec l'ordinateur FM Towns Marty, alors qu'il s'agit d'une référence à Marty McFly. Un commentateur note que « cross-platform » ne va pas jusqu'à son vieux Mac ni son Amiga.
Des souvenirs personnels remontent : certains veulent les bruits de disque dur, renvoyés vers IBMulator; d'autres évoquent le jeu EGATREK avec nostalgie. La discussion contredit l'article sur certains points pratiques, mais confirme l'intérêt de l'émulateur pour sa précision.
-
The End of an Athlon
Un passionné de matériel relate un incident survenu en manipulant un Athlon XP : le processeur a vu un gros éclat de silicium se détacher lors du retrait du dissipateur. Le CPU fonctionnait pourtant parfaitement avant cet incident, et le démontage n'a pas requis de force excessive. L'auteur suppose qu'une microfissure préexistante a cédé sous la contrainte.
Cet épisode illustre la fragilité des processeurs à packaging flip-chip PGA, utilisés autour de l'an 2000 par Intel et AMD pour améliorer le refroidissement. Le silicium exposé était vulnérable aux chocs mécaniques, et l'installation du dissipateur devait être très délicate. Intel est rapidement passé à des processeurs avec capot (lidded), plus robustes, tandis qu'AMD a conservé ce type de packaging pour les Athlon PGA. Les processeurs LGA modernes sont bien plus résistants, même si la fragilité s'est déplacée vers le socket de la carte mère.
Plusieurs commentateurs confirment par leur expérience personnelle la fragilité des Athlon à die nu, notamment les Athlon XP et Thunderbird. La pose du dissipateur était une opération angoissante : une pression mal dosée, un tournevis qui glisse sur le levier de fixation, et le processeur était mort. Certains se souviennent avoir cassé leur CPU malgré toutes les précautions, d'autres racontent avoir réussi du premier coup en lisant les instructions dix fois. Pour parer au risque, le marché proposait des cales en cuivre qui entouraient les petits composants autour du die et offraient une surface plane au radiateur, tout en conservant un contact direct avec le silicium.
Sur le plan technique, la discussion apporte des précisions. Un commentateur s'interroge sur la nature de ce qui est visible : plusieurs réponses expliquent que c'est bien le die découpé dans le wafer, mais que l'épaisseur n'est pas aussi faible qu'on le croit : le silicium massif constitue l'essentiel du substrat, la couche active et les couches de métal étant très minces au bas. Sur les CPU modernes, le wafer est parfois aminci pour améliorer les échanges thermiques. Un autre commentateur avance que la fissure pourrait être due à la chaleur plutôt qu'à la pression mécanique, même si le refroidissement était assuré par des ventilateurs délirants (des 9000 tr/min sont évoqués).
La discussion nuance également l'article sur deux points. D'abord, le delidding mentionné dans l'article ne s'applique pas à ces CPU sans capot : ici, le die était directement exposé et la moindre contrainte était fatale. Ensuite, les dégâts ne concernaient pas que le processeur : le socket lui-même pouvait casser sous l'effort du clip métallique, et un tournevis pouvait rayer les pistes du circuit imprimé. Un conseil pratique revient : faire tourner légèrement le dissipateur avant de le déclipser pour décoller la pâte thermique.
-
The Art and Beauty of Blade Runner (2015)
Article célébrant la beauté visuelle de Blade Runner, 35 ans après sa sortie. Il évoque les illustrations de fans, le travail du designer Syd Mead (qui a également œuvré sur Star Trek, Alien et TRON) et l'attention obsessionnelle de Ridley Scott aux détails, comme le pistolet de Deckard fabriqué à partir d'un fusil à verrou modifié. L'auteur s'attarde sur l'influence durable du film dans l'art et la science-fiction, sans aborder de sujet technologique ou d'actualité.
La discussion porte essentiellement sur le débat autour du statut de Deckard et de la fidélité au roman de Philip K. Dick. Plusieurs commentateurs critiquent la décision de Ridley Scott de faire de Deckard un replicant, la jugeant incohérente narrativement et thématiquement : un chasseur de replicants plus faible que ses proies n'a pas de sens, et le propos du livre — la déshumanisation progressive de Deckard face à des replicants de plus en plus humains — est plus riche. Un avis minoritaire assume détester le film pour cette infidélité, tout en reconnaissant l'avoir apprécié après l'avoir étudié séparément du livre. Un commentaire relève néanmoins que le geste de Roy Batty sauvant Deckard va dans le sens de l'ambiguïté, ce que l'article ne mentionne pas.
Les commentateurs s'accordent largement sur la qualité immersive du film, saluant à la fois les visuels, le son et le rythme. Plusieurs insistent sur la dimension auditive (musique de Vangelis, bruitages, atmosphère) souvent négligée au profit des images. Le contraste avec les films de science-fiction actuels, jugés trop rapides et agressifs, est souligné. Quelques critiques factuelles émergent : l'interprétation d'Harrison Ford est jugée faible par un commentateur, qui cite une scène particulièrement pénible, et le jeu de Brion James est également critiqué. Un commentateur oppose à l'enthousiasme général une préférence pour Terminator, plus réaliste, et un autre, plus tranché, qualifie le film de « POS » avant de saluer Solaris et Alien.
La discussion corrige ou nuance l'article sur deux points. D'une part, elle rappelle que le film de 1982 a été mal accueilli à sa sortie par certains spectateurs, qui ne l'ont apprécié qu'après des revisionnages. D'autre part, un commentateur souligne que la question des « enhancements » photographiques dans le film (la scène « Computer, enhance ») est techniquement absurde, car ils révèlent des détails physiquement masqués — une remarque d'ingénieur que l'article ne traite pas.