Hacker News
-
Creepy Crawlies
Konstantin Ryabitsev, responsable de git.kernel.org, détaille l'impact des crawlers IA sur l'infrastructure du noyau Linux. Plus de cycles CPU sont consommés pour rendre les commits en HTML pour les scrapers que pour tout autre usage légitime, dont les clones git : sur 90 cœurs répartis sur 5 nœuds, 14 à 16 cœurs (environ 20 % de la capacité) sont en permanence occupés à rendre des commits pour les scrapers.
Les robots ont d'abord été identifiés par leur user-agent, puis ont usurpé des navigateurs, poussé vers des sous-réseaux et ASN entiers, avant de passer à des millions d'IP résidentielles ou mobiles via la « monétisation par SDK proxy » — des machines comme les télévisions participent à ces essaims. La mise en place d'Anubis (preuve de travail en calculant un hash sha256 avec zéros initiaux) a fonctionné quelques mois, mais les bots résolvent désormais la difficulté 5.
Sur environ 6 millions de requêtes quotidiennes, 66 % sont bloquées par le défi Anubis mais 33 % le franchissent ; les requêtes légitimes représenteraient environ 2 % du trafic. Le site reste réactif, mais des fonctionnalités seront restreintes pour réduire le nombre d'URLs crawlables, sans solution simple en vue.
La discussion autour d'Anubis (preuve de travail anti-scrapers) est très critique. Le commentaire le plus voté démontre qu'un iPhone 17 ne fait qu'environ 100 KH/s en JS (180 s pour une difficulté 6 sur lists.ffmpeg.org, site devenu inutilisable), alors qu'un simple noyau C optimisé ARM SHA256 atteint 200+ MH/s sur le même appareil, et un ASIC à 5 000 $ fait 200 TH/s : l'écart dépasse six ordres de grandeur. Plusieurs répondent nuancent toutefois : sur un portable de trois ans, le défi ne prend que 8 s, et l'objectif n'est pas de battre les bots en puissance brute mais de leur imposer un coût multiplié par des millions de requêtes. Un autre argument en faveur d'Anubis : le kernel.org rapporte que 66 % des scrapers abandonnent directement, et les flottes de proxys résidentiels (smart TVs, SDK monétisés) ont des CPU faibles qui souffriraient du PoW. Un avis opposé rappelle que Tavis Ormandy avait prédit ce problème : contrairement à un hash de mot de passe, chaque requête du scraper est productive, donc le PoW favorise structurellement les attaquants.
Les retours de terrain convergent sur l'ampleur du fléau : plusieurs administrateurs de cgit (dont un hors projet noyau) subissent plus d'un million de requêtes/jour et ont dû bloquer diffs, blame et snapshots (certains répondent désormais 402 « payment required ») — ils constatent que les bots crawle des milliards de liens insensés sans même chercher s'il existe un moyen plus simple (git clone) d'obtenir les données. Un webmaster d'un site de jeu voit son compteur d'utilisateurs passer de 100-200 à des milliers, entièrement artificiel ; un exploitant d'app mobile observe +100 % de « sessions » fantômes, Meta identifiant ses crawlers mais continuant 50 000 requêtes/jour.
Sont évoqués des contre-mesures alternatives : pièges applicatifs type « iocaine » en Elixir (trous noirs, réponses octet par octet, images absurdes), ou défense par obscurité en forkant Anubis avec un hash modifié — plusieurs notent que les scrapers ne vérifient même pas les résultats et brûlent du CPU pour rien, et qu'aujourd'hui une simple variation suffit à les bloquer.
-
Our decision on Cursor following its acquisition by SpaceX
L'article concerne une décision prise au sujet de Cursor, un éditeur de code basé sur l'IA, après son acquisition par SpaceX. Aucun détail n'est disponible au-delà du titre.
La discussion porte essentiellement sur la décision d'OpenAI de rompre son contrat avec Cursor après son acquisition par SpaceX. Plusieurs commentateurs jugent cette décision logique, voire inévitable, dans un contexte où Musk a admis avoir distillé les modèles d'OpenAI pour entraîner xAI. Certains rappellent qu'Anthropic avait déjà banni xAI pour des raisons similaires, mais notent que le récent accord de datacenter entre Anthropic et xAI pourrait freiner une décision analogue. D'autres contestent le motif invoqué : ils y voient une manœuvre commerciale pour préparer la sortie du modèle Astra et capter la valeur plutôt que de la revendre via un concurrent. Un commentateur souligne que le fondateur de Cursor a indiqué que les modèles OpenAI ne représentaient qu'environ 5 % de l'usage, ce qui relativise l'impact.
Sur le plan pratique, les utilisateurs s'interrogent sur les alternatives. Plusieurs recommandent des outils comme Zed, JetBrains Air, Crush ou OpenRouter pour combiner plusieurs modèles depuis le terminal. Un avis récurrent : le modèle économique de Cursor, qui revend des API tierces, était voué à s'effondrer face aux offres subventionnées ou aux modèles open source. Certains défendent néanmoins l'éditeur pour son UX, notamment la revue de code intégrée et la rapidité des petites modifications, qui manquerait aux agents en ligne de commande comme Claude Code. D'autres, au contraire, estiment que Cursor n'est pas indispensable et qu'il est déjà trop coûteux dès qu'on utilise des modèles externes, avec des surcharges importantes par rapport aux tarifs des fournisseurs.
La discussion corrige ou nuance l'article sur plusieurs points. Le « préavis maximal » mentionné dans l'article est jugé étrange par des commentateurs : ils notent qu'une clause de résiliation après changement de propriétaire peut avoir une date d'expiration, et qu'OpenAI attendrait le dernier moment pour déclencher cette clause.
-
Debian votes to allow "responsible use of generative AI"
Le projet Debian a voté une résolution autorisant l'« usage responsable » de l'IA générative dans le développement, la maintenance et la documentation. Le projet ne l'endosse ni ne l'interdit, mais exige que toutes les contributions respectent les mêmes normes de qualité, de légalité et de maintenabilité. L'usage d'outils d'IA ne diminue pas la responsabilité des contributeurs, qui doivent comprendre, vérifier et modifier les résultats produits avant de les intégrer.
Plusieurs commentateurs saluent la décision de Debian comme un simple rappel du principe de responsabilité : quel que soit l'outil utilisé, le développeur reste responsable du code soumis. Un commentaire propose une heuristique pragmatique : « comprendre le code généré comme si on l'avait tapé caractère par caractère ». L'analyse statistique du scrutin est également citée : l'option E est vainqueur de Condorcet, avec une probabilité a posteriori de 99,9993 % de se classer première. Certains notent que l'absence de proposition ouvertement pro-IA parmi les options indique un décalage entre les rédacteurs des propositions et les votants, ces derniers étant surtout des membres actifs de la liste de diffusion.
Les avis divergent fortement sur la portée réelle de cette politique. D'un côté, des défenseurs de l'IA y voient une adaptation nécessaire, tandis que d'autres dénoncent une décision trop laxiste. Un commentaire cite le blog de Joey Hess, qui craint que les LLM n'éliminent toute incitation à supprimer le code boilerplate ou à réformer des processus complexes, favorisant la complexité et la fragilité. Un autre relate un exemple concret : un développeur aurait inondé la liste de diffusion de ffmpeg d'une proposition générée par IA, faute de temps pour rédiger un vrai texte. Plusieurs commentateurs soulèvent aussi des questions juridiques : la protection par le droit d'auteur des contenus générés par IA est incertaine, et l'exigence de « conception mentale » pourrait poser problème pour l'open source.
La discussion corrige au passage une idée reçue : Debian n'est pas qu'un assembleur de paquets, elle produit du code (APT, dpkg, correctifs). Un commentateur note que l'auto-évaluation du niveau d'assistance IA, proposée par un projet tiers, est utile mais repose sur la confiance envers l'auteur, ce qui est discutable. Enfin, des références concrètes sont apportées : Gentoo et Guix auraient explicitement banni l'IA générative, tandis que LWN suit le sujet. L'ensemble montre que la décision de Debian est perçue comme un compromis pragmatique, mais ses implications pratiques et éthiques restent débattues.
- Good Culture Is the Biggest Productivity Hack, Not AI
- The Internet Is Kind of a Predatory Cesspit Now
- DHS is using obscure law to snoop on journalists, non-profits, unions
-
Boot a Virtual iPhone via Apple's Virtualization.framework
Publication d'un outil open-source, vphone-cli, permettant de démarrer un iPhone virtuel via l'infrastructure de virtualisation (Virtualization.framework) d'Apple sur un Mac Apple Silicon sous macOS 15+. Il automatise le téléchargement des IPSW, le patch de la chaîne de boot, la restauration DFU et le premier démarrage, avec des variantes de jailbreak (SSH) et l'accès VNC. L'article détaille les prérequis (désactivation partielle de SIP/AMFI, Xcode, dépendances Homebrew), les commandes de gestion des VM (création, clonage, export/import, configuration) et des problèmes connus : blocage sur « Press home to continue » (contournable via VNC), refus d'installation des apps système selon la région choisie, crash avec EXC_GUARD, et un bug de ldid-procursus provoquant des boucles infinies lors de la re-signature. Un socket de contrôle permet des tests E2E pilotés par IA (captures d'écran, touches, gestes) via un serveur MCP.
Plusieurs commentateurs corrigent d'emblée une ambiguïté de l'article : il ne s'agit pas d'émulation comme Corellium, mais de virtualisation. Apple fournit un noyau iOS pour Virtualization.framework dans les images PCC/cloudOS, et le projet l'associe à l'espace utilisateur iOS avec des patchs. Les applications peuvent facilement détecter l'environnement. La différence avec le simulateur iOS est aussi soulignée : le simulateur compile des composants iOS pour macOS, tandis que ce projet exécute une image iPhone complète telle quelle, via virtualisation, avec un noyau séparé. Un commentateur précise que le simulateur n'est pas virtualisé et tourne sur l'instruction set de l'hôte.
Côté usages, des praticiens disent utiliser le projet régulièrement pour tester des applications, notamment via un MCP permettant à des agents de contrôler l'interface. D'autres y voient un intérêt pour le reverse engineering et les tests de performance, en regrettant que Corellium soit devenu recherche uniquement. Plusieurs limitations concrètes sont signalées : il faut désactiver partiellement SIP, ce qui est rédhibitoire sur une machine d'entreprise ; des binaires inclus dans les scripts/resources s'exécutent en root sans transparence, d'où une inquiétude sur la sécurité. La consigne de ne pas choisir la région UE ou Japon durant l'installation est expliquée par des vérifications réglementaires liées aux puces Felica et aux magasins d'applications alternatifs.
La discussion replace le projet dans un contexte plus large : Apple avait tenté de fermer Corellium, et certains trouvent ironique qu'Apple fournisse désormais les briques nécessaires. Un commentateur demande si Apple finira par casser le projet, avec un avis majoritairement pessimiste. Sur une éventuelle compatibilité PC, la réponse est négative, mais le projet fonctionne sur Mac. L'acronyme PCC est éclairci comme « Private Cloud Compute ». Enfin, des questions restent ouvertes sur la prise en charge de CallKit ou l'utilisation pour la récupération de compte, sans réponse claire dans les commentaires.
- Hy4 preview
-
Iceland votes on whether to restart talks on joining EU
Les Islandais votent lors d'un référendum sur la reprise des négociations d'adhésion à l'UE, treize ans après leur interruption. Les sondages donnent un résultat serré, avec une légère avance du camp du Non (51,6%). Le débat porte principalement sur la souveraineté, la pêche et les craintes de perdre le contrôle des zones de pêche, plutôt que sur les questions de sécurité. Un vote oui ne serait pas une décision finale, mais ouvrirait la voie à un accord d'adhésion qui devrait ensuite être approuvé par un second référendum et les États membres de l'UE.
La discussion sur le référendum islandais concernant l'ouverture de négociations d'adhésion à l'UE est dominée par la question des pêches, qui représentent environ 40 % des exportations selon plusieurs commentateurs, et par la crainte de perdre le contrôle des eaux islandaises au profit de la politique commune de la pêche. Certains voient là un enjeu de survie pour le pays, d'autant que l'Islande n'a pas de militaire. Un commentateur impliqué dans le processus électoral décrit en détail le système de vote, volontairement low-tech, avec comptage manuel et double vérification, y voyant une garantie de transparence.
Le débat plus large sur l'UE oppose des critiques (toute-puissance de la Commission, inflation réglementaire comme les bouchons de bouteille, ChatControl) et des défenseurs des avantages concrets (euro, libre circulation, fin des frais d'itinérance, régulation des grandes entreprises technologiques). Un avis minoritaire estime que l'UE est en déclin ; d'autres jugent ces critiques peu informées, comparables aux discours sur le fiat money. Plusieurs commentateurs soulignent que l'Islande est déjà membre de l'espace Schengen et du marché unique, si bien que l'adhésion complète porterait principalement sur la monnaie, la politique étrangère et la sécurité. Selon certains, les nouveaux membres doivent obligatoirement adopter l'euro, avec une période de transition négociable, ce que l'article ne mentionne pas explicitement.
La discussion corrige aussi le cadre du scrutin : ce référendum ne porte que sur l'ouverture des négociations, un second vote devant valider l'accord final, une nuance que plusieurs commentateurs jugent importante au vu de l'expérience britannique. Certains proposent des alternatives comme un statut d'associé ou une union nordique. Enfin, quelques commentaires notent que la conformité réglementaire est déjà imposée aux exportateurs islandais, même hors UE. Dans l'ensemble, les échanges n'infirment pas l'article sur les pêches, mais ils le nuancent en rappelant qu'il ne s'agit pas d'un choix binaire et que d'autres enjeux, notamment monétaires, sont déterminants.
- GrapheneOS project: pixel 11 no longer supports hardware memory tagging (MTE)
-
I accidentally turned LLM memory into program analysis
L'auteur, qui utilise des agents LLM pour la recherche de vulnérabilités, s'est heurté au problème de la perte de contexte lors de longues sessions. Il propose plutôt de confier la maintenance des connaissances à une base Datalog. L'LLM convertit les observations en faits structurés, et des règles dérivent des conclusions ; si un fait est rétracté, les conclusions dépendantes sont invalidées automatiquement. L'outil, nommé Lemmalog, gère aussi la provenance des faits dérivés, ce qui permet de demander pourquoi une conclusion est vraie et d'éviter les hallucinations sur l'état de l'investigation.
La discussion valide l'approche centrale de l'article : confier à un LLM l'extraction de faits dans une représentation formelle (Datalog, graphe de connaissances) plutôt que de le laisser gérer la mémoire en langage naturel. Plusieurs commentateurs partagent des expériences convergentes : l'LLM excelle pour transformer des requêtes en une représentation rigoureuse et pour interpréter les résultats, mais le stockage et le raisonnement doivent reposer sur un moteur mécanique. Certains rappellent que cette idée est ancienne, citant Cyc ou la tradition neuro-symbolique, et qu'elle ressemble à une redécouverte de l'IA symbolique. Un praticien note qu'il utilise une base de faits au format "sujet verbe objet" avec métadonnées, qu'il peut différer et réviser dans git ; un autre a construit un graphe de connaissances dans Postgres pour suivre des faits évolutifs (candidats, endorsements).
Plusieurs commentaires nuancent ou corrigent l'article. Un avis minoritaire estime que cette approche ne produit pas d'amélioration majeure du raisonnement, seulement un meilleur ancrage factuel. D'autres soulignent que le formalisme fonctionne pour des faits concrets et sans ambiguïté, mais se dégrade face à des notions floues comme "rougeâtre" ou "intermittent". Le problème le plus discuté est l'invalidation : un LLM a tendance à continuer de traiter comme vrais des faits déjà réfutés, et l'approche Datalog ne propage pas automatiquement l'invalidation. Un commentateur propose un journal de décisions horodaté, un autre insiste sur la nécessité de métadonnées de provenance (et corrige au passage la faute "providence" de l'article). Un praticien du domaine signale que les classifications générées par LLM dérivent en pratique, ce qui peut nuire au raisonnement logique.
Plusieurs outils concrets sont recommandés en complément : DeepClause (implémentation Prolog pour agents), Scallop (programmation neurosymbolique), Cave lang, ou encore l'utilisation de z3 pour résoudre des contraintes. Un commentateur utilise TLA+ pour vérifier du code généré par IA, mais reste sceptique sur le rapport confiance/effort.
-
Nancy Grace Roman Space Telescope
Le télescope spatial Nancy Grace Roman, nommé d'après la première astronome en chef de la NASA, a décollé le 30 août 2026 à bord d'une Falcon Heavy de SpaceX. Avec un champ de vision au moins 100 fois supérieur à celui de Hubble, il pourrait mesurer la lumière d'un milliard de galaxies, observer directement des exoplanètes et étudier l'énergie sombre et l'astrophysique infrarouge.
La discussion porte sur le lancement du télescope spatial Nancy Grace Roman (Falcon Heavy, prévu puis effectué avec succès et séparation du lanceur confirmée). Les commentateurs s'accordent sur son point fort : le champ de vision très large, bien supérieur à Hubble et Webb — une image de Roman couvre plus que la Lune pleine, là où Hubble est plus petit et Webb encore plus restreint, ce qui le rend idéal pour les relevés du ciel ; plusieurs rappellent que Hubble garde son intérêt pour l'imagerie profonde ciblée. Un point salué : toutes les données (jusqu'à ~1,4 To/jour brut compressé) seront publiques dès traitement, sans période d'embargo, ce qui est vu comme une avancée majeure mais qui inquiète un commentateur pour les doctorants pressés de publier. La complémentarité avec JWST est décrite : Roman repère par différences d'images répétées les anomalies (supernovae, etc.) que JWST observe ensuite en détail, le tout combiné avec Rubin et Hubble.
La discussion corrige et nuance l'article sur un point clé : le télescope s'appuie sur un miroir issu d'un satellite espion abandonné dans un entrepôt, ce qui expliquerait qu'il soit sous budget et en avance sur le calendrier ; un autre précise que seul le miroir provient du satellite espion, la structure et l'électronique étant de la NASA. Certains y voient un gaspillage militaire, d'autres une preuve que des projets publics peuvent tenir les délais. Sur les débits, une correction factuelle notable : la liaison est de 500 Mbps (mégabits) et non 500 mbps, soit environ 5,4 To/jour et non 1,5 To, le chiffre initialement avancé étant erroné.
Débat annexe : pourquoi ne pas construire deux exemplaires de télescopes coûteux pour se prémunir d'un échec de lancement ? Des réponses objectent que les échecs de lancement sont devenus rares et que des missions en double existent déjà (Voyager, rovers martiens). Une question technique précise que Roman a un seul ensemble de miroirs alimentant deux instruments : l'imager grand champ et un coronographe. Le nom du télescope a surtout nourri des digressions sans intérêt, et la discussion n'apporte guère au-delà de ces précisions techniques et du contexte du satellite espion.
-
Samsung's Processing-in-Memory (PIM)
Samsung présente sa technologie LPDDR5X-PIM, ajoutant des blocs de calcul dans les puces mémoire. Chaque banque contient un bloc PIM avec un arbre MAC, accédant à la banque sans passer par le bus externe, exploitant la bande passante interne de 614 Go/s (contre 76,8 Go/s en accès DRAM classique). Le bloc supporte des formats INT8, FP8, etc., avec un débit de 2,4 TOPS par puce.
L'interface reste compatible LPDDR5X grâce à des adresses de ligne spéciales permettant de passer en mode multi-banques et d'accéder aux registres PIM. Les lectures/écritures standard sont redirigées vers les registres PIM pour charger les opérations, les facteurs d'échelle et les activations. Un mode d'alignement d'adresse (AAM) gère le réordonnancement du contrôleur mémoire.
Le principal défi est logiciel : les modes PIM changent la signification des commandes, empêchant les accès mémoire classiques simultanés. Il faut isoler une zone mémoire PIM, ce qui pose des problèmes de bande passante et de multitâche, notamment pour le multithreading et la coordination entre processus.
La discussion s'accorde sur l'intérêt théorique du PIM pour l'IA et les LLM, mais diverge sur sa faisabilité pratique. Plusieurs commentateurs soulignent que déplacer le calcul dans la mémoire impose de connaître à l'avance la localisation des données, ce qui ne convient qu'à des charges très spécifiques. Un avis minoritaire défend le goulot d'étranglement de von Neumann comme une fonctionnalité : la communication coûteuse oblige à une certaine discipline. D'autres rétorquent que la difficulté de programmation deviendra secondaire si l'IA écrit le code, mais rappellent que cela bouleverse le concept de mémoire virtuelle et exigerait de nouveaux systèmes d'exploitation. Plusieurs rappellent que l'idée n'est pas nouvelle : des travaux similaires existaient dès les années 1980 et au début des années 2000, mais n'ont jamais abouti.
Sur le plan technique, les commentaires corrigent ou nuancent l'article. Un praticien explique que la multiplication matricielle exige de faire passer chaque élément d'une matrice devant chaque élément de l'autre, ce qui nécessite un registre à décalage, et que le mouvement des données reste le problème principal. Un autre précise que pour les multiplications vecteur-matrice (GEMV), le PIM peut fonctionner en découpant les matrices en tuiles, mais qu'il est inutile pour les multiplications générales (GEMM) où un GPU reste meilleur. La question de la taille des banques mémoire est soulevée : si les poids d'une couche ne tiennent pas dans une banque, les gains chutent, même si la découpe des vecteurs peut compenser. Plusieurs notent que le process DRAM n'est pas adapté à la logique de calcul, et que le manque de support pour les formats numériques quantifiés limite la flexibilité face aux GPU. Un commentateur compare le PIM à d'anciennes cartes CPU sur bus ISA, soulignant le caractère cyclique de la technologie.
La majorité reste sceptique sur l'adoption : des douzaines d'accélérateurs exotiques sont présentés chaque année sans suite, même si certains citent Mythic AI ou Encharge AI comme exemples de PIM ayant atteint l'industrie.
- StemDeck, a free, open-source and local AI stem separator
-
Calibrate Before You Accelerate: Bias Toward Action in a New Role
Conseils de carrière pour démarrer un nouveau poste : l'auteur, passé de Monzo à Engine by Starling, propose de calibrer son « biais pour l'action » en trois phases — collecte d'information (écoute active, Chesterton's Fence, cartographie des parties prenantes), synthèse (identifier les points de douleur récurrents, trier les gains rapides des enjeux systémiques), puis accélération stratégique (commencer par des victoires visibles, partager ses hypothèses, augmenter progressivement la part d'action).
Les commentateurs approuvent globalement la thèse de l'article (se calibrer avant d'agir dans un nouveau rôle), mais plusieurs la jugent presque triviale : « comprendre avant de changer » relèverait du simple bon sens. Un contraste fréquent est dressé avec « move fast and break things », et la typologie de von Hammerstein est citée pour reformuler l'idée : mieux vaut être travailleur et intelligent que travailleur et stupide. La clôture de Chesterton est invoquée à plusieurs reprises comme principe fondateur, avec une réponse nuancée : une « clôture » non documentée peut aussi être un signal d'alerte qu'il faut questionner activement plutôt que respecter aveuglément.
Un fil notable contredit le ton de l'article : plusieurs estiment que le texte est très probablement généré par IA (style « LLM », détections par des outils), sans que cela remette en cause le fond, jugé pertinent et tranché. D'autres partagèrent un scepticisme similaire sur certaines tournures de l'article.
Les apports concrets sont nombreux : un praticien décrit sa « listening tour » (questions préparées, synthèse anonymisée en doc) ; d'autres recommandent de commencer par la documentation, les runbooks et la CI — un livrable sans risque pour la production, que les nouveaux sont les mieux placés pour améliorer — ou de construire d'abord des outils d'analyse/visibilité. Plusieurs insistent sur la communication : publier ses petites contributions pour bâtir sa réputation. Des nuances tempèrent toutefois l'article : il faut montrer un impact concret avant de perdre la confiance des pairs ; accepter les tâches ingrates des autres est un bon moyen de cartographier l'organisation ; et en entreprise, un biais pour l'action paie davantage en carrière que pour les résultats. Récits de terrain contrastés : un CTO « qui devait mettre sa patte partout » et a semé le chaos, face à une autre CTO méthodique qui a attendu des mois avant de changer quoi que ce soit, avec très peu de dommages. Un commentaire déplore enfin le manque d'onboarding structuré dans les startups, et un développeur CORPORATE exprime son usure face à des rôles où l'on exige de livrer des features plutôt que du changement organisationnel.
-
TurboKV: Insanely fast Rust key-value store
TurboKV est une base de données clé-valeur embarquée écrite en Rust, orientée performance, avec lots atomiques, scans de plage ordonnés, durabilité configurable, compression LZ4 et compaction en arrière-plan. Son format de filtres de Bloom persistant exploite l'AES matériel (via RUSTFLAGS pour x86 et ARM).
Le projet détaille ses modes de durabilité (Fast sans WAL, Durable avec WAL non synchronisé à chaque écriture, Paranoid avec synchronisation avant chaque acquittement), sa gestion exclusive du répertoire de données, et ses API de batches et d'itérateurs avec vues cohérentes à un instant donné.
Des benchmarks sur Apple M4 comparant TurboKV 0.6, fjall 2.11.2 et redb 2.6.3 montrent des débits en clés acquittées par seconde, avec des précisions méthodologiques pour éviter les comparaisons de durabilité non équivalentes entre moteurs.
La discussion est largement critique envers les promesses de l'article. Le point le plus consensuel porte sur la sémantique de durabilité : le mode « durable » de TurboKV écrit dans un WAL « sans sync par écriture », donc ne survit pas à une perte d'alimentation. Plusieurs commentateurs soulignent que « durable » signifie normalement qu'une écritue acquittée ne peut pas être perdue, et comparent cela aux débats autour de MongoDB sans fsync. Un avis demande d'ailleurs de re-benchmarker les concurrents avec flush() désactivé pour une comparaison loyale.
Autre critique technique récurrente : le benchmark utilise un jeu de données de 80 MiB sur une machine de 32 GiB de RAM, ce qui ne représente pas une charge de base de données typique. Or mmap est rapide seulement quand les données tiennent en mémoire ; avec des lectures aléatoires sur un dataset plus grand que la RAM, les performances peuvent s'effondrer. La comparaison avec RocksDB est demandée mais absente de la discussion.
Plusieurs commentateurs rejettent aussi le titre « Insanely fast » comme du hype éditorialisé non présent dans le dépôt lui-même. Sur le fond, un commentaire apporte une correction nuancée : le gain en écriture vient surtout d'un WAL utilisant des segments mmap préalloués évitant un write(2) par mutation, tandis que le hachage AES matériel et LZ4 n'aident que les Bloom filters et les SSTables ; pas de boucle SIMD pour les scans. Un praticien note qu'un get+delete atomique est difficile sans API transactionnelle, que ce store n'a pas. Discussion donc peu convaincante : corrections de fond (durabilité, conditions de benchmark) plutôt que validations des performances annoncées.
-
9th Circuit sides with states in Kalshi gambling fight
La cour d'appel américaine du 9e Circuit a donné raison aux États dans le conflit qui les oppose à Kalshi au sujet des paris sportifs. Aucun contenu supplémentaire n'est disponible dans l'article fourni.
La décision unanime de la 9e Circuit en faveur des États contre Kalshi sur les paris sportifs suscite peu de sympathie pour l'entreprise dans la discussion. Un commentateur juriste explique le cadre juridique : la transmission d'informations de paris sportifs entre États est une infraction fédérale sauf si le pari est légal dans les deux États (18 U.S.C. § 1084(a)), et la CEA interdit les contrats illégaux en droit étatique (17 CFR 40.11). Selon lui, le droit est établi depuis longtemps et Kalshi relitige simplement une question déjà tranchée, en espérant être traitée comme Uber.
Un contrepoint relève que la CFTC avait elle-même ordonné à Kalshi de continuer à opérer dans l'État de New York lorsque celui-ci voulait la réprimer, et mentionne que Donald Trump Jr. est conseiller rémunéré de Kalshi — ce qui nuance le tableau d'une entreprise qui défierait simplement la loi. Plusieurs commentateurs notent que la stratégie « Uber » (enfreindre la loi jusqu'à obtenir un juge ou un Congrès favorable) est peu risquée : pas de prison, au pire une amende, ce qui en fait un pari asymétrique rentable. Un autre conteste l'idée que la Cour légifère en jugeant : jusqu'il y a quelques années, le consensus était que les paris sportifs étaient impossibles sur une bourse régulée par la CFTC, et l'opinion s'appuie longuement sur les définitions statutaires, pas sur du caprice.
D'autres apports : un commentateur souligne que le concept n'a rien d'innovant — les « betting exchanges » existent depuis plus de 25 ans en Europe, la seule innovation de Kalshi étant d'être régulée comme marché de matières premières plutôt que comme paris en ligne. Sur le fond, plusieurs jugent les paris sportifs une externalité négative qui devrait être taxée fortement (40-50 % du chiffre d'affaires, comme le tabac) avec restrictions publicitaires. L'argument d'un marché utile pour couvrir des risques (paris sur la victoire en World Series pour couvrir les invendus de merchandising) est récusé : l'assurance sur mesure existe déjà chez Lloyds.
-
You Know GDPR Is Good Based on Who Hates It
Essai défendant le RGPD : l'auteur soutient que la haine que lui porte l'industrie tech américaine est la preuve que la régulation fonctionne. Il rejette l'idée que les bannières cookies sont une fatalité du RGPD, les qualifiant de « vandalisme délibéré » — des dark patterns destinés à épuiser l'utilisateur et masquer la surveillance, mais qui paradoxalement ont sensibilisé le public (partage des données avec 996 partenaires, etc.).
L'article retrace l'histoire : entrée en vigueur le 25 mai 2018, précédent de la loi de Hesse (1970), et consensus mondial autour des principes OCDE de 1980, avec 126 pays dotés de lois sur la protection des données. Il s'appuie sur « l'effet Bruxelles » d'Anu Bradford (l'UE comme marché incontournable qui impose ses standards), les autorités de protection des données de chaque État membre, et le cas Max Schrems dont la plainte contre Facebook a fait annuler Safe Harbor.
Il oppose l'approche européenne (la vie privée comme droit humain, reprise publiquement par Brad Smith et Tim Cook) à l'approche américaine qui traite la donnée comme un problème de marché, et mentionne l'AI Act comme exemple de régulation préventive européenne.
La discussion autour de l'article « You Know GDPR Is Good Based on Who Hates It » oppose deux camps. Plusieurs commentateurs approuvent la thèse de l'auteur, la comparant au « scream test » des militants anti-tabac : plus une mesure est combattue par l'industrie, plus elle est probablement efficace. Un praticien rapporte qu'en entreprise, le RGPD a forcé une prise en compte réelle du stockage des données clients, même si c'était pénible ; un autre estime que la conformité n'est pas si compliquée et qu'un développeur ayant travaillé dessus rejette l'idée que Meta ou Google « adorent » le règlement, vu les armées de lobbyistes envoyées à Bruxelles. Un point fait large consensus : les bandeaux cookies ne sont pas imposés par le RGPD lui-même mais relèvent d'une « conformité malveillante » (ils viennent de la directive ePrivacy) conçue pour être agaçante afin de discréditer la régulation ; certains notent toutefois que même les sites officiels de l'UE les affichent, ce qui nuance cette explication.
Les voix critiques sont nombreuses : plusieurs estiment que le règlement est rédigé par des gens qui ne comprennent pas la technologie, qu'il dégrade l'expérience web sans bénéfice prouvé (fuites de données répétées en Pologne sans aucune conséquence), et qu'il écrase les petites entreprises — une startup berlinoise devait employer une personne dédiée à la conformité (corrigé : cela relèverait plutôt de la bureaucratie allemande que du RGPD lui-même). Un avis récurrent voit le RGPD comme une légitimation du commerce de données plutôt qu'une protection, avec des régulateurs (type ICO) impuissants face aux grandes entreprises. D'autres soulignent l'asymétrie : les géants américains absorbent les coûts pendant que les acteurs européens ne peuvent plus se lancer, expliquant l'absence de champions tech européens. Un utilisateur allemand regrette que le droit à l'effacement ne fonctionne pas contre les agences de crédit (SCHUFA), où il en aurait le plus besoin.