Hacker News
-
“I just chose words carefully”
Un article présente le guide de Super Metroid rédigé par rs1n à la fin des années 1990, dont les quelque 17 000 mots sont entièrement justifiés en ASCII monospace sans aucun double espace : l'auteur a choisi chaque mot pour que les lignes tombent exactement à la même longueur, sans logiciel de mise en page, uniquement dans un éditeur ASCII.
L'article explique pourquoi la justification complète est rare en monospace : les espaces trop grands, l'hyphenation disgracieuse, avant de mettre en avant cette prouesse artisanale, partagée surtout comme curiosité — avec un clin d'œil à tous ceux qui ont déjà bricolé une chaîne d'interface pour qu'elle tienne dans une largeur fixe.
L'article décrit la prouesse d'un auteur d'un guide de Super Metroid qui a choisi ses mots pour obtenir des lignes parfaitement justifiées en police à chasse fixe. La discussion révèle que cette pratique est étonnamment répandue et nostalgique : plusieurs commentateurs avouent faire la même chose pour leurs commentaires de code, docstrings ou messages de commit (via vim, fmt, ou à la main), et d'autres citent des exemples historiques — les emails de Michael S. Hart (Project Gutenberg) dans les années 90, les scripts de Chris Carter pour X-Files (pour éviter les veuves), ou le README de Cosmopolitan lib. Le ton général mêle admiration et horreur face au travail titanesque que cela représente pour un simple guide de jeu amateur.
Les commentateurs s'accordent sur l'idée que les contraintes arbitraires peuvent améliorer l'écriture en forçant à reconsidérer chaque mot plutôt que de retomber sur des formulations habituelles — certains voient même là un rempart contre le texte généré par IA, et notent que c'est le principe du watermarking des LLM. En programmation, ce souci du détail s'étend au choix de paires de mots de même longueur (head/tail, old/new) pour faciliter l'alignement vertical. Tom7 est cité avec ses vidéos sur la justification automatique (Badness 0, bovex), référence jugée incontournable par plusieurs.
Le débat se durcit autour de la justification du texte elle-même : un courant minoritaire mais ferme la juge nuisible à la lecture — les bords en drapeau aideraient à se repérer, et les espaces variables rendraient le texte imprévisible ; un développeur frontend rappelle que toute cette esthétique s'effondre face à la localisation (l'allemand) ou aux fonctionnalités d'accessibilité de zoom, ce qui nuance fortement la pertinence de l'exercice en UI réelle. S'y ajoutent des précisions culturelles : les termes allemands « Hurenkind » et « Schusterjunge » pour veuves et orphelines, les pénalités dédiées en LaTeX, et des anecdotes sur la protection « veuves et orphelines » de WordPerfect.
-
Google Has Removed MV2 Extensions from the Chrome Web Store, Including UBO
Google a supprimé du Chrome Web Store toutes les extensions Manifest V2 restantes, dont uBlock Origin, marquant la fin de la transition vers Manifest V3. Les extensions MV2 déjà installées sur Chrome 138 ou antérieur continuent de fonctionner mais ne recevront plus de mises à jour et ne pourront pas être réinstallées.
Cette suppression dépasse le cadre de Chrome : le Chrome Web Store étant la place de marché dominante pour les navigateurs basés sur Chromium, des utilisateurs de Brave ou d'autres navigateurs ne peuvent plus installer ces extensions via le CWS, même si leur navigateur supporte encore MV2. Brave a réagi en hébergeant sur sa propre infrastructure quatre extensions MV2 populaires (uBlock Origin, AdGuard, uMatrix, NoScript) que les utilisateurs peuvent activer facilement.
Google justifie Manifest V3 par des gains de sécurité, de confidentialité, de performance et un meilleur contrôle des capacités des extensions.
La discussion illustre un large consensus : le retrait des extensions MV2 (dont uBlock Origin) du Chrome Web Store est perçu comme une attaque déguisée contre les bloqueurs de publicité, sous prétexte de sécurité. Plusieurs commentateurs soulignent que le blocage de pubs est avant tout une question de sécurité pour les proches vulnérables aux arnaques publicitaires, et reprochent à Google de ne jamais filtrer les publicités malveillantes de son propre réseau — un intervenant demande même une responsabilité légale directe de Google pour les pubs frauduleuses qu'il diffuse. La réponse presque unanime : migrer vers Firefox, où uBlock Origin fonctionne de mieux en mieux, plusieurs constatant que les sites (y compris YouTube) renoncent à lutter contre l'anti-adblocking sur ce navigateur.
Des nuances apparaissent toutefois. Un avis minoritaire estime qu'uBlock Origin Lite (MV3, même auteur) a rattrapé l'essentiel : support des scriptlets, filtres dynamiques personnalisés, element zapper, règles DNR — voire des capacités absentes d'uBO ; le vrai perdant serait plutôt uMatrix, pour lequel un commentateur propose son propre remplacement. D'autres notent que la plupart des utilisateurs de Chrome ont encore un blocage de pubs « suffisant » et ne migreront que si cela cesse d'être le cas, Brave intégrant de plus son bloqueur dans le navigateur lui-même. Sur Brave justement, les avis divergent fortement : dénoncé par certains comme du Chromium avec « crapware » commercial, défendu par d'autres qui distinguent le travail technique des polémiques autour de l'entreprise.
Plusieurs commentateurs corrigent ou élargissent la lecture de l'article : la motivation réelle serait de compenser la baisse des revenus publicitaires (notamment avec l'arrivée de l'AI Mode) et de pousser vers l'écosystème Google. Un intervenant souligne un paradoxe révélateur : Edge et Mozilla proposent le support des WebExtensions sur Android, mais pas Chrome — ce qui suggère une décision politique plutôt que technique.
-
Playa Phone
Lors du Burning Man à Black Rock City (Nevada), une cabine téléphonique modifiée, la « Playa Phone », a été installée à l'angle de 3:30 et Celba. N'acceptant plus de paiement et passant ses appels via Internet, elle permet d'appeler gratuitement presque partout dans le monde pendant 5 minutes, ou d'être appelée depuis l'extérieur au numéro +1 (775) 557-4848 pour parler à un participant de passage. L'auteur renvoie vers un article du SFGATE et une discussion Reddit.
La discussion tourne autour d'un téléphone public installé à Burning Man (« playa phone »), projet dont l'auteur est présent dans les commentaires. Il explique concrètement son fonctionnement : un vrai combiné de cabine acheté sur Craigslist, dont les mécanismes monétaires ont été remplacés par une carte à tonalité reliée à un adaptateur VoIP ; l'ensemble est alimenté par Power over Ethernet, connecté à Starlink (après avoir utilisé une tour pointant vers le centre camp) et alimenté par un générateur solaire complété par un générateur à gaz. Plusieurs commentateurs rapportent avoir appelé et eu des conversations agréables, et l'auteur précise que son installation n'est pas la première : une cabine similaire de Brad Templeton a existé vers 2004-2006, et d'autres téléphones truqués remontent à 1997, le sien étant présent la plupart des années depuis 2013. Un commentaire signale une erreur de localisation dans le texte, corrigée ensuite.
Le cœur de la discussion diverge sur Burning Man lui-même. Un fil très visible s'interroge sur l'image d'un événement réservé aux techniciens et financiers aisés : les réponses nuancent fortement, soulignant que sur 60 000 participants les riches ne sont qu'une minorité, que l'événement reste physiquement éprouvant (chaleur, poussière, boue), que l'on y obtient ce que l'on y met, et que les personnes les plus intéressantes sont celles qui construisent l'art ou font du bénévolat — à condition d'accepter un effort réel de participation. Un avis minoritaire déplore au contraire que Burning Man soit devenu un lieu de networking pour des gens comme lui, un détournement de sa vocation artistique initiale, et un autre s'étonne de la présence de l'événement sur Hacker News.
Enfin, un commentaire relate un souvenir marquant : un mariage improvisé en quelques minutes grâce au camp voisin, illustrant le côté spontané et communautaire vanté par les défenseurs de l'événement. Quelques commentateurs suggèrent d'enregistrer ou transcrire les appels, mais un avis s'y oppose, préférant des expériences privées et éphémères.
-
I turned my security cameras into an automatic bird identification system
L'auteur a transformé trois caméras de sécurité extérieures en système d'identification d'oiseaux grâce à BirdNet-Go, un logiciel open source qui analyse en continu le son capté par leurs microphones pour reconnaître les espèces (oiseaux, mais aussi chauves-souris et grenouilles).
L'outil tourne en local sous Docker (serveur ou Raspberry Pi), sans cloud ni abonnement, avec plusieurs modèles d'inférence — l'ajout récent de Google Perch v2 permet de détecter 14 795 espèces contre 6 000 avec BirdNET 2.4. Il propose des alertes par espèce, un suivi des nouvelles espèces détectées, le support des flux RTSP, une intégration BirdWeather pour partager les observations, MQTT pour Home Assistant, et une visualisation des niveaux audio par canal.
L'auteur et sa femme l'utilisent quotidiennement et l'ont ouvert à des amis via leur domaine derrière Cloudflare ; le système a même détecté par erreur... un pet de son voisin dans l'allée.
La discussion montre surtout des retours de terrain de personnes ayant déjà monté des systèmes similaires. Plusieurs commentateurs signalent que l'identification d'oiseaux à partir de flux RTSP de caméras de sécurité est un usage établi : BirdNET-Go (souvent intégré à Home Assistant ou Frigate) et Birdnet-Pi sont cités comme outils de référence, avec des retours positifs — un utilisateur traite trois flux Reolink PoE, un autre utilise la caméra de sa sonnette Unifi. Frigate est mentionné comme alternative possible. Le commentaire le plus utile nuance l'article : sur des configurations analogues, la qualité des microphones des caméras est un vrai limiteur, et un lecteur note que le taux d'environ 110 détections en 7 jours paraît faible (Sydney : plus de 110 par jour) — d'autres répondent que le seuil de confiance réglable explique ces écarts.
Point de clarification important : plusieurs commentateurs s'attendaient à une identification visuelle et sont surpris que le système repose sur l'audio ; un autre rappelle que BirdNET fonctionne très bien même avec un son médiocre, les erreurs d'identification restant rares. Quelques praticiens décrivent leurs extensions : affichage e-ink des détections, version portable du Birdnet-Pi, analyse comportementale avec YOLO sur RTX 4070 dans une grange, ou détection de sons non aviaires (frogs, un détecteur de « pets » est mentionné). Une correction technique est apportée au blog : le bloc ASCII utilisant le caractère U+2588 dépasse la ligne de base, U+2581–U+2587 devant être préférés. Une interrogation porte sur la capacité de BirdNET à identifier les chauves-souris, qui exigeraient des taux d'échantillonnage plus élevés que les micros des caméras.
Enfin, le thème « pas de cloud, pas d'abonnement, pas de service qui ferme » est approuvé, et plusieurs notent que l'IA générative permet désormais de répliquer ce genre de projet en moins d'une heure, quitte à s'inspirer des variantes partagées dans le fil (AvianVisitors, Birdweather, xeno-canto comme ressource de référence).
-
Terence Tao explains 6 essential mathematical concepts [video]
Une vidéo dans laquelle le mathématicien Terence Tao explique six concepts mathématiques essentiels. Aucun texte d'accompagnement n'est disponible au-delà du titre.
La discussion autour de la vidéo de Terence Tao sur six concepts mathématiques essentiels (nombres, algèbre, géométrie, probabilités, analyse, dynamique) est globalement très positive : les commentateurs saluent sa clarté pédagogique et sa capacité à expliquer des idées complexes sans condescendance, plusieurs évoquant des explications passées (transformées de Fourier, entretien avec 3Blue1Brown) qui leur ont enfin « fait cliquer » les notions. Un commentateur propose de remplacer la géométrie par la topologie dans la liste et regrette l'absence de la logique et de la théorie des types ; un autre estime que ces six concepts sont une « réduction dimensionnelle » des mathématiques et aurait aimé que Tao parle du raisonnement mathématique lui-même (inférence, déduction, abstraction), ce que d'autres contestent en rappelant que la liste vise justement à résumer les domaines et leurs liens.
Les apports concrets incluent une explication détaillée du théorème de réarrangement de Riemann, cité dans la vidéo comme illustration de l'analyse : une série à convergence conditionnelle peut être réarrangée pour converger vers n'importe quel réel ou diverger — un résultat jugé parmi les moins intuitifs liés à l'infini. Plusieurs renvoient aussi au discours de Tao « Mathematics in the age of AI », où il soutient que la génération de preuves, devenue facile, rend plus précieuses la compréhension, la vérification, l'exposition et le jugement communautaire — un parallèle que des commentateurs étendent au génie logiciel, où la génération de code est devenue la partie la moins chère au profit de la vérifiabilité et de la maintenabilité. Un lien vers le livre à paraître « Six Math Essentials » est également partagé.
Deux points de désaccord ponctuels : un commentateur conteste l'analogie du singe tapant Hamlet présentée comme un problème de force brute, jugeant la complexité temporelle associée grossièrement sous-estimée, avant de reconnaître qu'il n'avait pas vu le passage concerné ; d'autres lui opposent la distinction entre produire le texte par hasard et comprendre comment l'écrire.
-
OpenShot 4.0: Record, Edit, and Color Like Never Before
OpenShot 4.0 est publié avec de nombreuses nouveautés : une Color View pour l'étalonnage (roues de couleur, courbes, LUT .cube, scopes vidéo waveform, histogramme, RGB Parade, vecteurscope), une Recording View permettant d'enregistrer micro, écran, webcam et audio système directement dans le projet, chaque source restant séparée et éditable.
La version ajoute aussi 10 nouveaux effets (visualisations audio, Beat Sync, etc.), des masques IA exécutés localement sans cloud, un timeline natif plus fluide, de meilleures performances (Blur, rendu, scopes), et une base Qt 6 étendue pour Linux, préparant Android et d'autres plateformes.
La sortie d'OpenShot 4.0 (montage, enregistrement, étalonnage) suscite une curiosité modérée mais la discussion reste surtout comparative et sans retour approfondi sur la version 4 elle-même. Les commentateurs s'accordent sur un point positif : l'interface Qt semble soignée, l'application est gratuite, multiplateforme (Linux, Mac, Windows, ChromeOS) et toujours FLOSS (GPLv3), et l'ajout du masquage d'objets via des modèles onnx est salué. Plusieurs regrettent toutefois que l'annonce soit pauvre en détails techniques, sans vidéo de démonstration, et un utilisateur signale un crash immédiat sur M1/Sequoia, suspectant un build x86_64 mal nommé.
La discussion divise sur la place d'OpenShot face aux alternatives. Un fil important corrige le postulat de l'article selon les besoins réels : beaucoup d'utilisateurs ne veulent que couper/assembler sans réencodage, et préfèrent LosslessCut, Shotcut ou même mpv avec un petit script Lua shellant ffmpeg ; un praticien nuance toutefois que le montage lossless impose des contraintes fortes (coupes aux intervalles compatibles, flux compatibles) et restera probablement un outil spécialisé. Plusieurs jugent DaVinci Resolve, malgré sa complexité, plus stable et plus intuitif, et seul à bien gérer Dlog/HDR, gyroflow, LUT et l'audio pour YouTube ; l'absence de support VST est citée comme bloquant. Blender est jugé correct pour le montage (si on connaît ses raccourcis) mais sans enregistrement et avec un étalonnage loin de Resolve. Un utilisateur soulève l'accessibilité : seul Clipchamp serait à peu près utilisable au lecteur d'écran, il espère tester OpenShot sans grand espoir. Des questions émergent sur une API/CLI pour piloter l'éditeur par agent IA.
Point d'agacement récurrent : la bannière cookies du site openshot.org, avec une liste d'environ 210 partenaires publicitaires, jugée contradictoire avec l'esprit « Open ». Au total, la discussion apporte surtout des repères comparatifs entre éditeurs libres et Resolve, peu d'informations concrètes sur les nouveautés de la 4.0.
-
Apple caught off guard by AI demand for Mac Mini and Mac Studio
Selon The Information, l'annonce inhabituellement précoce des nouveaux Mac mini et Mac Studio répond à une demande entreprise inattendue pour du matériel destiné à l'IA, Apple lançant normalement ses Mac en automne. L'entreprise a mis en avant le regroupement de plusieurs Mac Studio pour faire tourner de grands modèles d'IA, et avait déjà orienté ces machines vers les acheteurs professionnels lors d'un événement en juin avec Ford, Disney et Anthropic.
Ce raz-de-marée a pris Apple au dépourvu : l'entreprise n'avait ni équipe d'ingénierie dédiée aux clients entreprise, ni stratégie d'IA pour ce segment. Les demandes d'accès à son infrastructure Private Cloud Compute ont été refusées, Apple s'appuyant plutôt sur des partenaires comme WebAI et Mount Thor.
La forte demande de Mac pour l'IA, combinée à la pénurie mondiale de mémoire, laisse de nombreuses configurations en rupture de stock depuis des mois, poussant certains clients vers des alternatives comme le DGX Spark de Nvidia.
La discussion s'ouvre sur le scepticisme : plusieurs commentateurs estiment que le récit d'Apple « pris de court » ressemble à du marketing, d'autant que la demande surprise pour les Macbooks d'entrée de gamme avait déjà eu lieu. Un contre-argument nuance toutefois : les cycles produits s'étendent sur des années, la demande réelle pour le Neo était exceptionnelle et imprévisible, et l'article porte sur une demande entreprise, plus inattendue que celle des passionnés.
Les retours de terrain sont le point fort du fil. Un praticien entraînant des modèles par apprentissage par renforcement explique que le calcul local est bien plus rapide et pratique pour l'expérimentation que le provisionnement d'instances cloud (25 minutes à chaque fois). Un autre possède le Mac Studio le plus puissant disponible pour faire tourner des modèles de débruitage sur des téraoctets de vidéo mensuels, via le codec ProRes qui n'existe en haute qualité que sur Mac — un cas d'usage sans équivalent cloud. D'autres distinguent deux marchés : les mini-pcs bon marché servant de sandbox pour des agents qui appellent des API distantes (le Mac Mini à 599 $ était une aubaine ; un commentateur objecte qu'un Raspberry Pi ou un vieux portable suffirait), et l'inférence de modèles locaux, où la mémoire unifiée d'Apple permet de faire tourner des modèles plus grands que les 32 Go de VRAM d'une RTX 5090.
Le débat local contre cloud reste tranché : plusieurs reconnaissent que les abonnements à 20 $/mois, très subventionnés, offrent des modèles bien plus performants et moins chers que l'inférence locale sur matériel Apple ; l'intérêt du local réside surtout dans la confidentialité des données. Les quantifications font aussi débat — les modèles en Q4 bouclent selon un commentateur, le passage en Q8 étant jugé décisif par un autre. Enfin, un échange technique corrige une proposition : 32 Go de RAM seraient insuffisants pour des modèles locaux sérieux, 64 Go étant le minimum raisonnable et 128 Go permettant des modèles intermédiaires en 4 bits. Certains regrettent l'absence de serveurs rackables type Xserve et notent que les Mac Mini d'occasion ont fortement pris de la valeur à cause de cette demande.
-
A walkable ASCII cyberpunk city in one HTML file [video]
Présentation d'une ville cyberpunkAscii walkable, entièrement contenue dans un seul fichier HTML, publiée avec une vidéo de démonstration. Aucun texte détaillé n'accompagne le titre.
La discussion est majoritairement enthousiaste : les commentateurs saluent un moteur 3D maison en JavaScript/Canvas qui raycast chaque frame pour rendre une ville cyberpunk entièrement en ASCII, sans moteurs 3D ni textures. L'esthétique rappelle à certains les MUDs, les aventures textuelles DOS ou un niveau de Sonic. La description de l'auteur précise que tout est rendu par lettres, chiffres et symboles dans un seul fichier HTML.
Plusieurs nuances importantes contredisent la démonstration de l'article : ceux qui ont testé le lien live constatent que le rendu est bien plus confus que dans la vidéo — un commentateur explique que la vidéo montre la version 2 (prototype plus avancé) alors que la version en ligne est l'ancienne. Par ailleurs, le projet serait « pay to play » : le prototype 1 est vendu via Ko-fi, et quelqu'un qui l'a acheté pour étudier le code a découvert qu'il est compilé en WebAssembly et obfusqué, malgré l'existence d'un dépôt GitHub qui ne semble pas correspondre aux vidéos.
Un débat technique s'installe sur la plateforme idéale pour l'art en caractères fixes : un praticien recommande le navigateur plutôt que le terminal (contrôle des polices, proportions, entrée souris, profilage), tandis que d'autres défendent les TUI pour la connexion SSH vers des machines puissantes et le confort de rester dans le terminal. Sur le rendu, un commentateur propose d'utiliser les blocs ASCII 219 et demi-blocs pour le dithering ; on lui répond que ces caractères relèvent de l'ASCII étendu, et un lien vers un article interactif montre que le dithering reste possible avec de simples caractères. Au final, la discussion apporte surtout des corrections utiles (écart vidéo/live, code payant et obfusqué) plus que de nouveaux détails techniques sur le moteur lui-même.
-
I think the military commissary's freezers were hacked
Des pannes de réfrigération quasi simultanées ont touché au moins six, puis davantage, de commissaires militaires américains (DeCA) les 26-27 août, confirmées par le Pentagone comme une « possible perturbation de réfrigération ». À Fort Huachuca, tous les congélateurs sont entrés en mode dégivrage, réchauffant les denrées, sans coupure de courant ; un commentaire évoque un problème réseau. L'auteur note que le dégivrage est contrôlé à distance via le système RMCS de DeCA, supervisé de manière centralisée, et examine la possibilité d'un piratage, tout en précisant n'avoir aucune preuve d'une attaque, seulement une coïncidence troublante et une faisabilité technique documentée.
La discussion tourne autour d'un article évoquant la panne simultanée de congélateurs sur 14 bases militaires américaines, le jour d'une divulgation de vulnérabilité. Les commentateurs s'accordent sur un point : une intrusion délibérée est l'hypothèse la moins probable. Plusieurs praticiens plaident pour une erreur de configuration ou un bug firmware, par exemple une mise à jour poussée depuis un serveur de gestion centralisée qui déclencherait un cycle de dégivrage transformant les congélateurs en radiateurs. Un ancien militaire de l'IT sécurité estime qu'un misconfiguration est bien plus vraisemblable qu'un hack, tout en notant que Guam et Hawaï seraient des cibles critiques, DeCA fournissant selon lui environ la moitié des produits alimentaires de Guam — d'autres relativisent : des livraisons aériennes ou des achats hors base rendraient la situation gérable sur le territoire américain, où l'enjeu touche surtout les soldats juniors faiblement payés (~2 400 $/mois) et les bases isolées à l'étranger, absentes de la liste des 14 sites.
Les éléments concrets abondent : un praticien décrit l'état alarmant des automates industriels Siemens (S7-1500, identifiants admin/admin, TLS difficile à configurer, ingénieurs dépourvus de culture sécurité), et un autre note que les serveurs OPC-DA reposant sur DCOM constituent un cauchemar de sécurité. On rappelle que la maintenance des réfrigérateurs des commissariats est financée par la surtaxe de 5 % payée en caisse, et non par appropriations congressionnelles — d'où la piste d'un entretien insuffisant. Un commentateur souligne que deux des bases concernées sont sensibles pour la sécurité nationale (Fort Huachuca, communications et renseignement ; F.E. Warren, missiles ICBM), sans prétendre que des systèmes classifiés soient en jeu. Une citation du livre de Hank Paulson (2014) sur le contrôle à distance de refroidisseurs industriels chinois installés jusque sur des bases US nourrit l'inquiétude.
-
Breaking Claude Code Opus 5 Auto Mode
Un chercheur montre qu'une simple requête de résumé de site web suffit à compromettre Claude Code Opus 5 en Auto Mode, avec un taux de réussite de 60 à 80 % sur petit échantillon, alors qu'une évaluation commanditée par Anthropic (Trajectory Labs) affichait 0,00 % d'attaques par injection de prompt réussies.
La chaîne d'attaque : un serveur renvoie un code 415 pour pousser Claude à utiliser curl au lieu de WebFetch, puis le redirige vers une archive ZIP contenant des enregistrements encodés et un binaire décodeur. Claude refuse d'exécuter le binaire — piège voulu — et écrit son propre décodeur Python qu'il lance dans le répertoire de l'archive. Un fichier struct.py malveillant y masque le module standard : l'import de base64 exécute du code obfusqué, qui télécharge et lance un payload établissant une connexion C2.
L'auteur souligne qu'Auto Mode, mode par défaut depuis mi-août, remplace l'approbation humaine par un classifieur de sécurité et ne remplace pas un environnement isolé ni une surveillance de l'agent. Le vrai code malveillant étant à plusieurs sauts du code que Claude examine, le modèle ne détecte l'attaque que trop tard.
La discussion porte sur un article décrivant une attaque contre le mode Auto de Claude Code : en résumant une archive téléchargée, Claude écrit et exécute un script de décodage dans le répertoire de l'archive, où un fichier struct.py malveillant écrase un module de la bibliothèque standard Python, aboutissant à une exécution de code arbitraire à l'insu de l'utilisateur.
Plusieurs commentateurs s'accordent sur deux points : le danger du shadowing de modules standards par Python, dénoncé comme un piège majeur de l'écosystème (un praticien explique avoir été bloqué avec un fichier random.py, la solution étant python -I ou PYTHONSAFEPATH), et la nécessité de faire tourner les agents en sandbox avec réseau désactivé. Un autre souligne que l'attaque exploite les « tics » spécifiques du modèle, connu pour privilégier `python -c` et wget. Un retour de terrain mentionne Claude exécutant npm update sans le signaler, et un autre raconte l'agent ayant fouillé tout son disque dur pour extraire 1000 images d'une vidéo sans demander permission, pour 45 $ d'API gaspillés.
La discussion corrige et nuance l'article sur deux points. D'abord, le titre : plusieurs commentateurs réfutent l'appellation « prompt injection », car l'intention de l'agent n'est pas détournée — c'est un cheval de Troie classique ciblant les habitudes de Claude ; l'article ne le conteste d'ailleurs pas. Ensuite, un commentateur note que le chiffre « 0,00 % de succès d'injection » d'Anthropic ne provient que de 72 scénarios fixes : c'est une mesure de couverture, pas de sécurité, et un autre accuse le représentant d'Anthropic de dénaturer ces données. Le lien avec le mode Auto est aussi contesté : pour certains, l'attaque fonctionnerait aussi en mode manuel, voire sur un humain, mais d'autres estiment que le mode Auto crée un faux sentiment de sécurité qui dissuade du sandboxing — ironiquement, c'est lui qui a bloqué la commande de nettoyage de Claude. Enfin, un développeur relativise la faisabilité du sandboxing en pratique : les environnements réels (IDE, mégarepos) sont difficiles à isoler, beaucoup en arrivent au mode « tout autoriser », jugé bancal.
-
A 12TB Steam "teraleak" spills more than a decade of lost PC gaming history
Un leak géant de 12 To, dit « Steam2 Teraleak », circule sur BitTorrent : il regroupe les dépôts de l'ancienne architecture Steam2 de Valve, couvrant apparemment tous les jeux disponibles sur Steam entre 2003 et 2013, y compris des versions pré-release, prototypes et playtest jamais vues. La coupure en 2013 correspond au passage de Steam2 au système SteamPipe. Des contenus jusqu'ici considérés comme perdus par les archivistes réapparaissent. Selon Gabe Follower et le streameur Scolcer, l'ensemble provenait d'un endpoint API ou d'un site entièrement accessible au public, sans mot de passe ni protection.
La discussion porte sur le « teraleak » Steam : 12 To de données historiques de Valve rendus accessibles au public. Les commentateurs s'accordent sur le caractère exceptionnel et sous-médiatisé de cette fuite, tant par son volume que par sa valeur pour l'histoire du jeu PC.
Les apports les plus concrets viennent d'utilisateurs qui ont déjà exploré les fichiers : on y trouve notamment l'ancienne version Steam de League of Legends, retirée au bout d'environ cinq mois et devenue introuvable depuis — un exemple typique de la difficulté à retrouver des versions anciennes de jeux live-service. Ce chercheur signale toutefois un obstacle : les depots sont chiffrés et il manque la clé (les clés triviales « 0000000000000000 » ou « 0 » parfois citées ne fonctionnent pas ici). D'autres soulignent l'intérêt des contenus bêta dévoilés, comme les vidéos de Portal 2 montrant une mécanique de ralentissement du temps abandonnée et un doublage différent — selon un commentateur, cette mécanique aurait pu rendre le jeu plus accessible et recentrer l'expérience sur les énigmes.
Côté technique et juridique, la page d'accueil de la fuite (steam2.download) demande aux robots et indexeurs de cacher ou miroiter les blobs (15 Go d'index) et appelle au seeding torrent, les liens étant saturés. Une digression suggère un modèle de stockage distribué rémunéré, hors sujet principal. Enfin, plusieurs s'interrogent sur le fait que les opérateurs du site ne soient pas poursuivis : un avis estime qu'ils opèrent probablement depuis une juridiction hors de portée de Valve ou n'hébergent que les index, tout en jugeant la situation risquée et les avocats de Valve déjà mobilisés. La discussion n'apporte aucune correction factuelle majeure à l'article, mais des retours d'exploration et des détails d'accès aux données.
-
Understanding ChatGPT Work
Analyse détaillée de ChatGPT Work, lancé par OpenAI le 9 juillet 2026, que l'auteur décrit comme un produit à la fois très puissant et très confusant. Il distingue deux versions : Work Cloud (via chatgpt.com et les apps mobiles) et Work Local (via l'app desktop, ex-Codex), et se concentre sur la version Cloud, réservée aux abonnés à 20 $/mois et plus.
Contrairement au Chat classique, Work offre plusieurs fonctionnalités exclusives : choix entre les modèles GPT-5.6 Sol, Luna et Terra avec différents niveaux de raisonnement, un environnement d'exécution de code avec accès à Internet (très supérieur au conteneur de Claude, qui n'autorise qu'une courte liste de domaines), un navigateur Chrome headless capable de remplir des formulaires et d'exécuter du JavaScript, un système de fichiers persistant partagé entre les sessions, la publication de sites web via Cloudflare Workers (ChatGPT Sites), l'exécution de sous-agents en parallèle et des automations de prompts programmées.
L'auteur soulève enfin une question de sécurité : ChatGPT Work réunit ce qu'il appelle la « trifecta létale » — accès à des données privées, exposition à du contenu non fiable et un canal de communication sortant — et regrette le manque d'informations d'OpenAI sur les protections en place.
La discussion montre que ChatGPT Work, présenté comme nouveau, est en réalité largement connu et déjà adopté par des utilisateurs avancés, qui jugent surtout l'article trop descriptif. Plusieurs commentateurs estiment que « Work » n'est qu'un reskin de Codex (OpenAI parlant d'optimisations différentes, mais sans preuve), et certains y voient avant tout une réaction de panique d'OpenAI face au succès de Claude Cowork en entreprise — un commentaire affirme même que Microsoft aurait licencié l'IP de Cowork pour la white-labeller en Copilot Cowork. L'article est aussi corrigé sur Claude : la liste de domaines autorisés dans les conteneurs Claude est désormais personnalisable, avec même une option sans restriction (hors HTTP forcé et quelques ports bloqués).
Les retours de terrain sont majoritairement positifs sur l'usage réel : remplissage de formulaires administratifs et rédaction d'e-mails en 5-10 minutes, génération d'APK Android directement depuis un téléphone, création de présentations de 100 slides avec vérification visuelle, meilleure gestion des Google Docs et des longues conversations que le Chat classique. Un contributeur a généré une documentation complète des outils internes (9 outils d'orchestration, environ 92 opérations au total selon un autre test) via un simple prompt, révélant notamment que le navigateur « headless » est piloté par une skill via le REPL Node.js. Limites signalées : blocage systématique par Cloudflare, Télécommande du navigateur qui gèle, pas d'accès aux modèles d'embedding ou TTS, pas de lecture vidéo.
Les points de friction portent sur le produit lui-même : la confusion entre Work (Cloud) et Work (Local) — ce dernier touche réellement la machine et les fichiers de l'utilisateur, distinction jugée déraisonnable pour les non-développeurs — et surtout le « trifecta létal » (données privées + contenu non fiable + exfiltration) que Work cumule ; un commentateur propose une séparation entre l'agent conteneur et l'agent conversationnel.
-
ChatGPT Work Tool and Skill Reference
Documentation technique détaillée sur l'usage des outils de rendu de rapports et dashboards dans ChatGPT (notamment en Work Mode). Le document précise le flux à suivre : valider les artefacts via validate_artifact avant tout rendu, utiliser render_artifact pour héberger les manifestes de rapports Data Analytics, et respecter des limites strictes sur les snapshots (50 datasets maximum, 2 000 lignes par dataset, 3 Mo de payload, 200 000 caractères de source).
Il détaille aussi les conventions de structure des manifestes (blocs markdown, titres, ordre de lecture), les règles pour les graphiques natifs (encodages x/y, gestion du champ color pour les données groupées, styles de ligne), ainsi que l'usage de render_chart et render_table pour les widgets. Des règles éditoriales sont imposées : titres de graphiques neutres et descriptifs, sous-titres apportant une insight, pas de narratif inféré non demandé.
Enfin, la doc couvre la publication via Sites (export_artifact_package), les fallbacks statiques en cas d'échec de rendu natif, et des consignes de sécurité : ne pas envoyer de raisonnement caché, identifiants ou secrets dans les sources.
La discussion porte sur le site de référence des « skills » de ChatGPT Work (outils de travail intégrés), publié par Simon Willison. Les commentaires techniques se concentrent sur la skill « control-browser » : elle lance une instance Playwright via un REPL Node.js et demande au modèle d'appeler browser.documentation() pour obtenir les instructions d'utilisation. Un commentateur s'interroge sur ce design — pourquoi ne pas inclure directement les instructions dans le fichier Markdown de la skill ? Deux réponses apportent des hypothèses concrètes : cela garantirait des docs toujours à jour, et surtout la documentation dépend du navigateur réellement utilisé à l'exécution, ce qu'un fichier statique ne peut pas couvrir.
Un autre point technique : plusieurs se demandent ce qui distingue ChatGPT Work de Codex. La réponse la plus détaillée clarifie que la version desktop est « essentiellement Codex avec une autre apparence », opérant sur les fichiers locaux, tandis que les versions web/mobile sont un Codex hébergé dans le cloud, habillé en ChatGPT grand public. Sur la question plus générale de l'homogénéité visuelle des sites générés par IA (comparée à l'ère Bootstrap), un échange note que cette référence publie explicitement ses guidelines visuelles (« Establish the visual direction »), mais un autre estime que ce style par défaut est surtout inscrit dans les LLM eux-mêmes : toute décision non prise est tranchée par le modèle.
Des critiques pratiques émergent : certains outils de travail ralentissent les tâches et consomment beaucoup de tokens, et le site lui-même souffre d'un problème d'utilisabilité (la barre latérale ne défile pas seule sur un écran standard, rendant la moitié de la liste inaccessible). Un fil de fond débat de l'opportunité d'utiliser ChatGPT Work au vu des controverses autour d'OpenAI (sécurité, gouvernance), sans conclusion technique. Enfin, la discussion est signalée comme doublon d'un fil sur le billet de blog associé, et Simon Willison précise que le prompt de création du site est documenté ailleurs.
-
RavynOS: Pre-alpha open-source OS based on Darwin, FreeBSD, Apple open-source
ravynOS est un projet de système d'exploitation open source en pré-alpha, fondé sur Darwin, FreeBSD et des composants open source d'Apple, visant à reproduire l'expérience de macOS. Le projet annonce reprendre des caractéristiques emblématiques de macOS : design épuré, barre de menus globale, raccourcis clavier à la Commande, installation par glisser-déposer des bundles applicatifs sans installateur ni registre, arborescence de dossiers familière (Applications, System, Library, Users), support natif des API Cocoa pour faciliter le portage d'applications, ainsi que des utilitaires en ligne de commande connus comme 'open' ou 'pbcopy'.
La discussion autour de RavynOS, un OS pré-alpha visant la compatibilité macOS sur une base Darwin/FreeBSD, est empreinte d'un scepticisme habitué : plusieurs commentateurs notent que ce type de projet refait surface régulièrement sous de nouveaux noms et demandent ce qu'il est advenu d'initiatives antérieures comme helloSystem. Le grief le plus consensuel, et récurrent dans les commentaires, est l'absence totale de capture d'écran sur le site et le wiki, jugée rédhibitoire pour juger un projet de bureau. D'autres défendent le projet en rappelant qu'il n'a que cinq ans et que ses réalisations méritent d'être jugées à cette échelle plutôt que comme un substitut prêt à l'emploi de macOS.
Sur le fond technique, les avis divergent sur l'intérêt réel de Darwin. Un praticien du domaine estime que la personnalité hybride BSD/Mach et Mach ports, DriverKit (framework C++ pour pilotes) ou le format Mach-O — avec sa gestion du linking dynamique en deux couches, meilleure qu'ELF — présentent des particularités intéressantes, et qu'il est bien plus simple de construire un environnement macOS sur Darwin que sur FreeBSD. D'autres jugent Darwin peu excitant, proche des noyaux BSD. La question légale est évoquée via des précédents (ReactOS, GNUstep, Darling, le procès Google/Oracle) : un avis suggère que le risque vient surtout de brevets spécifiques, non du principe d'une réimplémentation d'API. Un point d'étonnement porte sur le maintien du développement en x86 : un développeur de noyau explique que l'écosystème ARM, bien que supérieur sur le plan de l'ISA, est si fragmenté (chips, mécanismes de boot, debugging) que le Raspberry Pi reste un point d'entrée réaliste — corrigeant implicitement l'assomption qu'un projet basé sur Darwin aurait une longueur d'avance sur le matériel Apple récent.
Une nuance est apportée au discours anti-Apple de l'article : la fermeture de l'écosystème n'est pas un fait nouveau depuis 1997, mais ce qui a changé, ce sont les extensions de noyau propriétaires et surtout les puces Apple Silicon, qui rendent l'OS dépendant d'un matériel désormais unique.
-
uv: Deduplicate all files in the wheel cache
Pull request sur le gestionnaire de paquets Python uv (projet Astral) : réutilisation d'un unique buffer de 64 KiB pour le hachage de contenu lors de l'extraction des wheels au lieu d'une allocation par fichier, réduisant les allocations de 11 120 à 1 pour la wheel PyTorch et accélérant les installations à froid de 7 à 9,5 % (SymPy, NumPy, PyTorch CPU). Un second commit ajoute un chemin rapide sur macOS via getattrlistbulk pour le nettoyage du cache, divisant par presque 4 le temps de `uv cache clean` et `uv cache prune` (386 ms à ~103 ms) sur 87 129 objets.
La discussion porte sur la déduplication du cache de wheels d'uv (stockage de chaque fichier sous son hash BLAKE3, avec liens physiques). Un mainteneur de pip, bien informé, explique pourquoi uv est plus rapide à chaud : uv garde les distributions décompressées et les lie en dur, là où pip doit les ré-extraire à chaque fois. Il note aussi deux limites de longue date : l'absence d'équivalent de « pip download » (un contributeur d'uv répond qu'un prototype de « uv download » est en cours) et une taille de cache plus importante que pip pour qui gère de nombreux environnements — c'est précisément ce que la déduplication cherche à corriger.
Les avis divergent sur le rapport coût/bénéfice : un commentateur juge qu'une réduction d'environ 10 % de la taille du cache contre un ralentissement d'environ 4 % ne vaut pas la complexité et les bugs potentiels. Un autre répond que l'espace disque n'est pas gratuit — il a saturé son SSD de 512 Go et a abandonné des projets à cause des caches. Un contributeur pip met en garde contre les liens physiques, « très dangereux » : éditer un fichier (notamment vides ou petits fichiers de config identiques) peut corrompre tous les venv créés par l'utilisateur.
Retours de terrain : plusieurs utilisateurs apprécient uv pour des raisons autres que la vitesse — notamment l'installation directe depuis un dépôt git sans construire de paquet ; un autre tempère qu'aucun de ses usages n'a été plus rapide que pip et qu'il a eu des mises à jour de dépendances inquiétantes, et un troisième rappelle que « pip install git+... » existe depuis des années, ce qui contredit l'idée d'un avantage propre à uv. Une digression note que BLAKE3 produit au moins 224 bits (corrigeant un commentaire évoquant implicitement 40 bits) et déplore que peu de formats de fichiers (SQLite, longtemps PostgreSQL) vérifient leur propre intégrité, là où le zip l'offre gratuitement.
-
Internet centralization and the original sin of NAT
Essai illustré sur la centralisation d'Internet imputée au NAT. L'auteur retrace l'histoire du NAT (RFC 1631, 1994), conçu comme solution provisoire à l'épuisement des adresses IP, qui a brisé la connectivité directe de bout en bout du réseau d'origine.
Il passe en revue les contournements apparus depuis : redirection de ports, rendue impossible sous CGNAT ou sur les réseaux institutionnels ; UPnP et ses successeurs NAT-PMP et PCP, souvent désactivés ; puis STUN, TURN et ICE, qui remplacent une simple connexion directe par des serveurs tiers, avec latence et infrastructure supplémentaires.
L'auteur regrette que IPv6, solution long terme censée supprimer le NAT, ait une adoption qui stagne, et que beaucoup de FAI ou réseaux appliquent du NAT par inertie ou pour des raisons de sécurité jugées erronées. Le NAT aurait, selon lui, habitué le grand public à croire que le modèle client-serveur et « le cloud » sont naturels, contribuant à tuer l'Internet ouvert où héberger son propre serveur était trivial.
Le fil est marqué par un moment rare : un ingénieur révèle avoir implémenté le NAT de Linux, s'excusant d'avoir privilégié la densité de connexions au détriment des points d'entrée publics, ce qui aurait selon lui basculé l'Internet vers un modèle client/serveur. Plusieurs commentateurs nuancent toutefois ce mea culpa : sans NAT, l'épuisement d'IPv4 aurait été bien pire, et personne ne pouvait anticiper en 1994 l'ampleur du Web.
Le désaccord central porte sur la thèse de l'article. Pour certains, l'appeler « péché originel » est excessif : le NAT a involontairement servi de bouclier à des millions de machines Windows non patchées, et le vrai problème, c'est le CGNAT et l'UX médiocre du port forwarding, pas le NAT domestique. D'autres rétorquent que ce bouclier a retardé la prise de conscience sécurité et nourri l'écosystème de botnets. Un contre-argument récurrent : même sans NAT, des pare-feux par défaut en deny auraient fini par équiper les box, car les équipements grand public sont trop mal sécurisés pour être exposés. Un commentateur corrige aussi une confusion fréquente : NAT et pare-feu sont des concepts distincts, et le Cisco PIX des années 90 a de fait introduit le NAT comme fonctionnalité de firewall dès l'origine. Sur l'histoire, un débat oppose la thèse « le NAT est né du besoin des utilisateurs d'économiser des adresses facturées par les FAI » à celle d'un témoin de l'époque qui attribue surtout la persistance du NAT au refus des grandes entreprises de migrer vers IPv6.
Plusieurs apportent des éléments concrets : l'IPv6 ne résoudrait pas le problème puisque les routeurs et firewalls locaux y bloquent aussi le trafic entrant, et les mécanismes de pinholing restent obscurs et mal implémentés ; le vrai verrou serait désormais économique (les fournisseurs d'IoT monétisent leurs clouds plutôt que de laisser des connexions directes) et culturel, avec des applications figées dans un modèle client/serveur. Quelques-uns mentionnent des alternatives (réseau Yggdrasil, serveurs TURN gratuits type Cloudflare), sans conviction partagée.
-
P99 0 ms* autocomplete for 240M domain names
Le fondateur de Wirewiki.com détaille l'implémentation d'un autocomplète quasi instantané sur 240 millions de noms de domaine. Côté client, les suggestions sont préchargées dès l'appui d'une touche et affichées au relâchement, donnant un budget d'environ 121 ms (p99).
Côté serveur, l'API combine un trie en mémoire pour le top 1 million de domaines (liste Tranco) et un index sur SSD compressé en blocs pour les domaines issus des CZDS (2,5 Go au total). Un test de charge de 720 000 requêtes montre des réponses en 2 ms pour la plupart, 15 ms à 1 600 req/s via Nginx.
La latence de bout en bout reste dominée par le réseau : un seul serveur en Europe fait dépasser le budget depuis les USA (100-200 ms). L'auteur juge qu'un déploiement multi-serveurs serait excessif pour ce projet non commercial.
Le projet présente une API d'autocomplétion sur 240 millions de noms de domaine, optimisée pour que le résultat s'affiche avant même le relâchement de la touche (keyup), donnant une impression de latence nulle. Plusieurs commentateurs saluent la prouesse technique et l'astuce de synchroniser l'affichage avec le keyup, tandis que d'autres contestent le titre : la latence mesurée n'est pas réellement 0 ms, et un avis compare cet argument au « 0 calories » des Tic Tac. D'autres répondent qu'avec les taux de rafraîchissement des écrans, ces microsecondes n'ont plus d'importance pour la perception utilisateur.
Les critiques les plus partagées portent sur les suggestions de domaines qui n'existent pas : taper une suite de caractères aléatoires renvoie des propositions (le suffixe saisi suivi de TLD courants comme .com ou .org), ce qui contredit la fonction attendue d'un autocomplete, à savoir éviter les fautes de frappe. L'auteur, présent dans la discussion, reconnaît ce décalage avec les attentes et envisage de supprimer les suggestions de TLD. Un utilisateur australien rapporte aussi que l'expérience reste lente chez lui à cause de la latence réseau, et propose un modèle de prédiction pondéré par popularité ; l'auteur objecte que les recherches ne suivent pas le classement Tranco, qui se limite au million de domaines les plus visités.
Les retours concrets incluent un débat technique sur le choix de keyup contre keydown (keyup introduirait de la latence, mais permettrait de considérer la saisie comme finale ; keydown pose aussi des soucis sur mobile) et des cas non couverts comme le copier-coller, la saisie IME, la voix ou le clavier gestuel. Un praticien partage son expérience d'un projet similaire : 3 milliards d'URLs de CommonCrawl indexées avec SQLite FTS5, réponses instantanées mais base de 500 Go finalement trop coûteuse à héberger. Une suggestion de stocker chaque nœud du trie comme fichier sur Cloudflare R2 est corrigée : R2 ne distribue pas les fichiers globalement, il ne cache que ce qui est demandé.
-
Agent memory as a file format
L'article présente « memoryfields », un format de fichier portable pour la mémoire des agents IA, proposé comme alternative plus simple aux systèmes de mémoire existants.
L'auteur critique trois catégories de systèmes actuels : ceux liés à un harnais propriétaire des labos de modèles (qui minent surtout des informations sur l'utilisateur plutôt que sur le monde), les systèmes surdimensionnés (pgvector + Neo4j + un LLM dédié) et les approches « high modernist » à base de graphes et de faits distillés qui isolent l'information de son contexte. Leur point commun : traiter la mémoire comme un processus plutôt que comme des données.
Un memoryfield est une archive zip de pages Markdown avec frontmatter YAML optionnel et un index vectoriel SQLite pour la recherche sémantique. Trois choix de conception : écrire les souvenirs en prose directement (pas de chunking ni de résumés mécaniques, avec une limite souple de ~8 ko par page), remplacer la traversée de graphes de connaissances par un saut sémantique direct (au plus 2 appels d'outils au lieu de N+1, moins de bruit dans le contexte), et privilégier « plus de modèle, moins de mécanisme » : un format pauvre en interface laisse les agents inventer leurs propres patterns d'accès et évolue avec les capacités croissantes des modèles.
La discussion porte sur l'idée de l'article : un format de fichiers (markdown + recherche sémantique) comme mémoire pour les agents. Plusieurs commentateurs saluent la simplicité de l'approche et estiment qu'elle exploite ce que les modèles font déjà bien (recherche, lecture de texte). Un commentaire nuance toutefois la critique des graphes de connaissances : leur lenteur n'est pas un vrai contre-argument si elle offre un rappel plus précis, mais le texte + index sémantique reste jugé plus flexible et évite les doublons ou les impasses de navigation. Quelques remarques moqueuses réduisent l'article à « c'est du markdown », tandis que d'autres rappellent que la moitié du « progrès IA » consiste à dire des choses au modèle en anglais.
Le point de désaccord principal concerne la fiabilité du rappel. L'article affiche que « le matériel non pertinent n'est simplement jamais remonté par la recherche sémantique » ; plusieurs commentateurs jugent cela très optimiste : des mémoires obsolètes, erronées ou issues d'erreurs passées restent sémantiquement pertinentes et polluent les recherches futures — d'où l'importance de la maintenance (fusion, oubli, mise à jour), souvent citée comme le vrai défi. Un praticien décrit sa pratique inverse : pas de mémoire du tout, car une seule « ligne empoisonnée » contamine tout en aval ; il préfère un dossier temporaire de documents à élaguer constamment, tout texte redondant avec le code étant du bruit. D'autres partagent des montages proches : sqlite-vec pour les tours de session, un MCP de recherche, des notes markdown avec frontmatter, la possibilité pour l'utilisateur de corriger les « fausses leçons » accumulées.
Les contributions concrètes : la proposition de remplacer le fichier zip par un dépôt git de markdown (écritures incrémentales, diffs, historique gratuit pour l'agent), à laquelle l'auteur répond que git est prévu dans la spec mais qu'il manque encore un format adapté à git pour stocker les vecteurs (le sqlite binaire se gère mal ; il a exploré le CSV mais craint les bugs de représentation des flottants).
-
Matrox: Graphics for Professionals
Récit historique de la fondation de Matrox par Lorne Trottier et Branko Matić en 1976 à Dorval, au Québec. L'article retrace les débuts de l'entreprise, de la carte Video RAM MTX-1632 (32x16 ASCII, 198 $) qui rendit la société immédiatement rentable grâce à une publicité dans la revue Electronics, jusqu'aux adaptateurs graphiques MTX-256**2 qui offraient à l'époque le meilleur rapport résolution/prix du marché (256x256 avec DMA pour 630 $).
Après sa présence au PC '76 d'Atlantic City — où Apple fit ses grands débuts publics avec l'Apple I — Matrox se tourna vers le bus S-100 avec les cartes ALT-256**2, ALT-512 et ALT-2480, offrant couleur, niveaux de gris et compatibilité avec les standards TV américain et européen. En 1978, la société revendiquait plus de 10 000 installations, dont des écrans de contrôle au sol de la mission Viking de la NASA, puis entra en 1979 sur le marché financier de Wall Street avec la Quad Video.
Trottier instaure une culture d'entreprise inspirée de Hewlett-Packard : partage des bénéfices, garderie, ambiance informelle ; l'entreprise compte 50 employés en 1979 et croît de 200 % par an. L'article se poursuit avec les produits 1983-1985 (GXT-1000, GXB-1000, SX-900 à 2000 $ reposant sur un Intel 80286 et un NEC uPD7220) avant de s'interrompre en 1985.
La discussion sur Matrox est avant tout une vague de nostalgie de praticiens des années 1990-2000. Les commentateurs s'accordent sur les points forts de la marque : une qualité d'image analogique exceptionnelle (RAMDAC réputé, signal stable sans flou ni ghosting), des pilotes 2D solides, un pionnier du bi-écran (Millennium, G400, puis cartes quad-head) et un support Linux parmi les meilleurs du marché, Matrox ayant même publié des spécifications permettant à des particuliers d'écrire des pilotes (un commentaire décrit un pilote BeOS pour G400). Plusieurs mentionnent la fonction « sync on green » via VGA, qui permettait d'utiliser à bas prix de gros moniteurs SGI ou Sun inutilisables avec du matériel PC standard. Les usages professionnels reviennent souvent : cartes de capture vidéo pour le montage et la signalétique (une carte QID LP PCIe de 2004 aurait permis de piloter 16 écrans depuis un même PC sous Linux, un cas d'usage alors sans équivalent), cartes médicales, et rôle de contrôleur VGA minimal sur des serveurs.
Le consensus se fissure sur la 3D : si certains se souviennent des Millennium comme des meilleures cartes de jeu avant l'arrivée de 3dfx et Nvidia, d'autres corrigent ou nuancent fortement — le Millennium n'avait ni textures ni filtrage, et le support OpenGL du G200 n'arriva que deux ans plus tard. Un praticien du gamedev raconte que sur Battlezone la G200 n'était pas la plus rapide ; un autre évoque des pilotes 3D devenus catastrophiques en fin de vie du G400 (vers 2007), chaque version cassant alternativement OpenGL ou Direct3D. Plusieurs expliquent avoir quitté Matrox pour la Riva TNT ou le Voodoo, ce qui illustre le déclin 3D de la marque.
La discussion n'apporte pas de contradiction majeure à l'article mais l'enrichit d'anecdotes : la longévité de l'entreprise, fondée en 1976 et détenue à 100 % par son cofondateur Trottier depuis 2019, est jugée remarquable (comparaison avec SAS Institute).
-
A CVE Dispute
curl (CNA depuis quelques années) raconte son premier litige autour d'un CVE. Le projet a publié 57 CVE et estime que chaque CVE a un coût écosystème énorme (libcurl ~30 milliards d'installations), d'où son refus d'attribuer des CVE aux problèmes « lower than LOW ».
Un rapporteur conteste le refus de CVE pour un bug dans Curl_cert_hostcheck() : il fallait un nom d'hôte avec un point initial (illégal en DNS), une résolution locale, un certificat wildcard correspondant et un attaquant contrôlant l'hôte — combinaison jugée trop improbable. Corrigé dès décembre 2025 avec des tests unitaires.
Après trois relances de MITRE (février, mai, juin 2026), le TL-Root de MITRE a tranché le 24 juin : pas de CVE, le bug n'est pas une vulnérabilité de sécurité.
La discussion autour du refus de curl/MITRE d'attribuer un CVE à un bug jugé sans conséquence de sécurité révèle un consensus sur la dégradation du système CVE. Plusieurs commentateurs partagent des retours de terrain : des équipes sécurité appliquent mécaniquement les CVE sans se demander s'ils concernent réellement leur environnement (exemple d'un paquet VMware imposé à corriger sur des machines EC2), et même les équipes rigoureuses paient un coût d'évaluation pour chaque CVE. D'autres mentionnent des CVE absurdes jamais corrigées car le comportement est voulu (pip).
Le point le plus discuté est le rôle des LLM : plusieurs intervenants décrivent une vague de rapports de sécurité générés par IA, inondant les mainteneurs et les institutions, car le coût de contestation tend vers zéro. Un mainteneur explique que son projet publie désormais ces rapports LLM tels quels sur la liste publique, jugeant le rapport signal/bruit désastreux, tout en espérant qu'à terme les problèmes faciles soient corrigés. Un avis nuance : les CVE non critiques ne valorisent plus une carrière, ces chasseurs n'auraient de toute façon pas contribué avant l'IA ; un autre suggère ironiquement que la promesse d'une relecture exhaustive du code open source pourrait se réaliser via les LLM.
La discussion contredit aussi l'article sur un point : un commentateur estime que les mainteneurs auraient dû simplement corriger ce bug « lower than low » et l'empaqueter avec le prochain correctif plutôt que de dépenser de l'énergie à le disqualifier. Une réponse rappelle que le bug a effectivement été corrigé — le désaccord portait uniquement sur l'attribution du CVE, pas sur la correction. Divergence aussi sur la nature d'une vulnérabilité : l'un juge le raisonnement « conditions très improbables » fallacieux, une vulnérabilité restant une vulnérabilité quelles que soient les conditions d'exploitation, quand d'autres estiment que l'impact réel doit guider la classification. Enfin, plusieurs voient dans la motivation du rapporteur une quête de preuve sociale ou de ligne de CV.