Hacker News
-
What happens if an entire class of workers loses faith in their careers
Aaron Horwath, directeur des opérations IA dans une entreprise de technologie créative, observe une désillusion croissante chez les travailleurs du savoir. Il illustre ce malaise par l'anecdote d'un jeune cadre en costume tricotant un bonnet dans le train, symbole d'un désir de faire quelque chose de concret. Les professionnels partagent des rêves d'évasion (ferme, hors réseau) et remettent en question le sens de leur travail.
Horwath relie cette angoisse existentielle à l'IA, qui menace de rendre une partie du travail intellectuel obsolète, et au « workism », tendance à faire du travail une source de sens comparable à la religion. Il critique les « bullshit jobs » sans utilité réelle et s'interroge sur les conséquences si toute une classe de travailleurs perdait foi en leurs carrières, l'IA pouvant briser le « sort » du workism.
Plusieurs commentateurs, souvent des vétérans de la tech, partagent le sentiment de désillusion décrit dans l'article, mais divergent sur les causes. Certains pointent le télétravail, devenu un piège après des années, ou la toxicité croissante du web et l'astroturfing, qui érodent la santé mentale. D'autres estiment que le problème vient de ceux qui ont rejoint le secteur pour l'argent, pas par passion : les vrais passionnés, eux, s'adaptent toujours aux évolutions. Un avis minoritaire conteste même l'idée d'une perte de foi généralisée, rappelant que l'excitation de créer et de bricoler avec l'IA locale existe encore.
La discussion corrige et nuance l'article sur plusieurs points. L'auteur, présenté comme « Director of AI Operations », est accusé de répandre lui-même le désespoir qu'il décrit, et d'éviter soigneusement le terme d'aliénation. L'affirmation selon laquelle « personne ne parle des traducteurs » est jugée fausse. L'exemple des métiers manuels comme échappatoire est critiqué : posséder une ferme ou travailler dans l'agriculture ne suffit souvent pas à vivre, et la réalité physique est dure. Plusieurs commentaires citent le sort des imprimeurs et le documentaire « Farewell, Etaoin Shrdlu » comme précédent historique, mais soulignent que le risque structurel existe pour toute carrière.
Ce qui divise le plus, c'est la responsabilité de l'IA et la nature du travail. Certains y voient une opportunité de créer des choses nouvelles, d'autres dénoncent le modèle d'abonnement et l'insuffisance des modèles locaux. Plusieurs commentateurs estiment que le problème n'est pas propre à la tech : le monde du travail dans son ensemble est cassé, et l'article, trop enthousiaste à l'idée de voir l'IA « briser l'illusion », ne propose pas d'alternative crédible. La nostalgie des lancements de l'iPhone est rappelée comme exception, pas comme norme.
-
US strikes $1.2B deal to pay German firm to halt offshore wind projects
L'administration Trump verse 1,2 milliard de dollars à l'énergéticien allemand RWE pour qu'il abandonne ses projets d'éolien offshore aux États-Unis. RWE réinvestira cette somme dans des projets gaziers, dont 900 millions de dollars dans un terminal de gaz naturel liquéfié en Louisiane, et renonce à ses concessions au large de la Californie, de la Louisiane et du New York Bight. Le secrétaire à l'Intérieur Doug Burgum salue cet accord. Des accords similaires ont été conclus avec TotalEnergies et Duke Energy.
La discussion exprime une indignation quasi unanime face à l'accord de 1,2 milliard de dollars pour stopper les projets éoliens offshore de RWE. Plusieurs commentateurs soulignent l'hypocrisie du secrétaire à l'Intérieur qui dénonce les « subventions coûteuses » alors que l'argent sert à financer du gaz, notamment via le réinvestissement de RWE dans un terminal de GNL en Louisiane. Un avis minoritaire rappelle que toutes les énergies sont subventionnées et que la stratégie « de bon sens » n'existe pas. L'article est corrigé sur un point : un commentaire signale que l'accord avec Duke Energy mentionné est de 129 millions de dollars, et non 129 milliards comme une faute de frappe pourrait le laisser croire.
Plusieurs commentateurs attribuent cette décision à la rancune personnelle de Trump contre les éoliennes, depuis son litige avec un golf en Écosse, ainsi qu'aux donations de l'industrie pétrolière et gazière. D'autres y voient une cohérence avec le programme des électeurs républicains, ou une forme de « suicide collectif » face au changement climatique. Des retours de terrain contrastent : un commentateur basé en Irlande du Nord affirme que l'éolien offshore y fournit plus de 35 % de l'électricité, tandis qu'un autre répond que les éoliennes ne sont pas « cool » au Texas. La discussion rappelle aussi que la Chine dépend encore massivement du charbon, contrairement à une idée reçue, même si elle investit à long terme.
Enfin, certains commentaires s'éloignent du sujet pour évoquer des comparaisons historiques (Empire romain), des théories sur l'empoisonnement au plomb ou des appels au vote, mais l'essentiel reste une condamnation morale et politique de l'accord, perçu comme un gaspillage d'argent public et un frein délibéré aux énergies renouvelables. Aucun commentaire ne défend l'accord sur le fond, seulement sa cohérence avec les intérêts de l'administration.
-
New Mexico court orders Meta to pay $567m over harms to children’s mental health
Un tribunal du Nouveau-Mexique a ordonné à Meta, société mère de Facebook, de verser 567 millions de dollars dans un fonds destiné à réparer les effets néfastes de ses plateformes sur la santé mentale des enfants. Cette décision s'ajoute à l'amende de 375 millions de dollars imposée en mars, portant le total à 942 millions de dollars.
Le juge Bryan Biedscheid a affecté 420 millions de dollars à des services de traitement pour les jeunes, le reste finançant prévention, dépistage et autres coûts sur cinq ans. Le tribunal a également ordonné des changements chez Meta, notamment des améliorations de l'assurance de l'âge, un modèle de prédiction pour les moins de 13 ans, et un portail de signalement pour les écoles. Meta devra supprimer les données des utilisateurs de moins de 13 ans et rendre compte de ses progrès deux fois par an.
Meta a annoncé son intention de faire appel, contestant la décision. Ce jugement s'inscrit dans une série de poursuites contre l'entreprise aux États-Unis, notamment au Tennessee et en Californie, sur les préjudices allégués aux jeunes utilisateurs.
La discussion autour de la condamnation de Meta au Nouveau-Mexique relativise largement la portée de la décision. Plusieurs commentateurs soulignent que si la somme de 567 millions de dollars paraît faible face aux revenus mondiaux de Meta, elle est considérable pour un État de 2 millions d'habitants : elle représenterait la moitié à deux tiers des revenus que Meta a tirés de cet État sur cinq ans. D'autres rétorquent que le géant fera traîner l'affaire en appel pendant des années, rendant la sanction inopérante, et que le montant n'est qu'un « coût de faire des affaires ». Certains estiment que seule une peine de prison pour les dirigeants aurait un effet.
Les commentaires divergent sur le fond. Des voix critiquent la loi de nuisance publique invoquée, la jugeant trop large et dangereuse si elle était généralisée, comparant Meta à FedEx ou aux studios de cinéma. D'autres rappellent qu'un jury a reconnu Meta coupable d'avoir sciemment nui à la santé mentale des enfants et dissimulé l'exploitation sexuelle sur ses plateformes, ce qui justifierait la sanction. Un commentateur apporte une correction importante : l'affaire ne porterait pas seulement sur les algorithmes addictifs, mais aussi sur l'échec de Meta à retirer des contenus liés au trafic d'enfants, ce que l'article ne précise pas toujours. Un autre précise que le juge a rejeté la défense fondée sur l'article 230 du CDA, un point juridique clé.
Plusieurs participants déplorent que la responsabilité parentale soit évacuée, tandis que d'autres estiment que les entreprises doivent assumer leurs algorithmes. L'accord général se limite au constat que la décision sera attaquée en appel et que son impact réel dépendra de la mise en œuvre, notamment des changements de modération annoncés. La discussion corrige ainsi le récit d'une victoire définitive : la bataille judiciaire ne fait que commencer.
-
DeepSeek V4 Flash 0731
Titre d'un post Hacker News : « DeepSeek V4 Flash 0731 » (par tosh). Aucun contenu disponible au-delà du titre.
Plusieurs commentateurs saluent DeepSeek V4 Flash 0731 comme un modèle extrêmement rentable, suffisant pour la plupart des usages, y compris en programmation. Ils rapportent des coûts dérisoires (moins de 5 dollars par jour avec plusieurs sessions), une vitesse élevée en local (8k tok/s en prefill sur 2x RTX Pro 6000, 250 tok/s en flux unique) et une qualité de réponse jugée proche de modèles bien plus chers. Un utilisateur le préfère même à Claude pour son « persona » et ses angles morts complémentaires. Plusieurs soulignent que le prix va probablement augmenter : DeepSeek a annoncé une hausse « significative » à venir, mais personne n'en connaît le montant (un commentateur évoque une possible suppression de la remise de 75 % plutôt qu'un facteur 10).
Les avis divergent sur la fiabilité agentique : un commentateur déplore des boucles infinies et des changements de sujet aberrants (parlant de Rust puis de chaise électrique), tandis que d'autres n'ont aucun problème avec OpenCode ou Pi. Les benchmarks présentés dans l'article suscitent le scepticisme : certains résultats (GLM-5.2 faible, V4 Flash supérieur à Kimi K3 max) semblent trop extrêmes par rapport à d'autres sources comme Artificial Analysis. Un commentaire note que le modèle est text-only et s'interroge sur ses bons résultats en ARC-AGI-2, un test visuel.
Enfin, plusieurs corrections et nuances : les endpoints officiels sont lents selon un utilisateur (25 tok/s en local vs 250 annoncés), et la comparaison des prix doit tenir compte du doublement en heures de pointe (définies selon l'heure chinoise). Un commentateur rappelle que DeepSeek est open weight et que d'autres providers le servent à des tarifs très bas, ce qui relativise l'impact de la hausse annoncée. La discussion confirme globalement l'article mais met en garde contre des benchmarks trop parfaits et des comportements agentiques parfois instables.
-
Oracle bans AI-generated code from OpenJDK
Oracle interdit le code généré par IA dans les contributions OpenJDK, invoquant des risques de sécurité, de sûreté et de propriété intellectuelle. Les développeurs peuvent utiliser des LLM en privé pour déboguer et revoir le code, mais ne peuvent pas soumettre de contenu généré par IA dans les dépôts ou pull requests.
Cette politique contraste avec les pratiques internes d'Oracle : Larry Ellison a récemment déclaré que les modèles d'IA écrivent désormais le code d'Oracle, et le co-CEO Mike Sicilia a attribué aux outils d'IA une livraison plus rapide avec des équipes réduites.
Oracle investit 70 milliards de dollars cette année dans l'expansion de ses datacentres. Cette dépense a conduit l'agence S&P à dégrader la note d'Oracle à BBB-, un cran au-dessus du statut spéculatif, en raison des retours sur investissement incertains.
Plusieurs commentateurs estiment que cette interdiction relève avant tout d'une gestion du risque juridique et de licence, plutôt que d'une remise en cause de la qualité du code généré par IA. Oracle, décrit comme « un cabinet d'avocats avec une branche tech », chercherait à préserver sa capacité à attaquer en justice pour violation de droits d'auteur, notamment après son célèbre procès contre Google. L'appel à des contributions externes générées par IA poserait un problème de provenance, alors que les grands groupes utilisant l'IA en interne bénéficient de garde-fous et d'indemnisations de la part de leurs fournisseurs. Plusieurs commentaires soulignent aussi l'ironie de la situation : Oracle investit massivement dans l'IA (data centers, licenciements) tout en l'interdisant sur son projet open source. Un lien vers l'article original de The Register est fourni, la publication liée étant jugée de mauvaise qualité.
Les avis divergent sur le bien-fondé de la décision. Certains la jugent rationnelle pour un projet mature comme Java, où tout code est une responsabilité potentielle, et rappellent que d'autres projets comme Rust adoptent des politiques similaires. D'autres y voient une hypocrisie (« règles pour toi, pas pour moi ») et un signal clair que le code généré par IA est considéré comme inadéquat par ses propres promoteurs. La question de l'applicabilité est au centre des débats : comment détecter du code généré par IA, surtout si l'auteur le modifie ensuite ? Un commentateur répond que la politique repose sur l'auto-déclaration et le principe social de l'open source : si un contributeur ne peut pas expliquer son code, il n'est pas accepté.
La discussion nuance l'article en précisant que la politique d'OpenJDK est intérimaire, en attendant une version définitive rédigée par les juristes. Plusieurs commentateurs relèvent que l'interdiction inclut explicitement tout code généré par IA, même partiellement, comme le montre l'exemple cité sur la page officielle. Un avis minoritaire estime que cette décision est un signal que les « développeurs AI-first » devraient prendre au sérieux, même si un autre commentateur les qualifie de « délires ».
-
2027 memory capacity is reportedly sold out
Un rapport (Digitimes, via TweakTown) affirme que Samsung, SK Hynix et Micron ont vendu l'intégralité de leur capacité de production de mémoire DRAM/HBM pour 2027, principalement à des entreprises d'IA via des accords d'achat à long terme. Aucune confirmation officielle des fabricants pour l'instant.
Cette situation devrait maintenir la pression sur les prix de la RAM. La demande de mémoire NAND augmente également, et les SSD deviennent plus chers (exemple : le WD SN7100 est passé d'environ 110 $ à 189 $ en quelques mois). Les hausses de prix touchent aussi les consoles, comme la Xbox Series X et la Steam Machine.
La discussion confirme le point central de l'article : la demande d'IA pour la mémoire HBM (High Bandwidth Memory) assèche l'offre de DRAM grand public. Plusieurs commentateurs expliquent qu'une unité de HBM consomme environ trois fois la capacité de wafer qu'une unité de DDR5 pour le même nombre de bits, et que ce ratio devrait encore s'aggraver avec HBM4. En conséquence, les fabricants privilégient les produits à forte marge, réduisant la production de puces standard. Un praticien rapporte avoir vu les prix des puces avec DDR intégrée quadrupler depuis décembre, et un autre mentionne que la nouvelle capacité de production ne sera pas disponible avant fin 2027, avec une stabilisation des prix seulement vers 2029.
Les commentateurs s'accordent sur les conséquences concrètes : hausse des prix de la RAM pour les consommateurs (un exemple : 16 Go de DDR4 à 120 $), augmentation du coût des téléphones, consoles et ordinateurs portables, et impact disproportionné sur les pays pauvres. Plusieurs suggestions alternatives émergent, comme utiliser des disques Optane bon marché en swap plutôt que d'acheter de la RAM neuve. Un commentaire note que de la RAM chinoise (CXMT) commence à arriver sur le marché américain, en quantité mais avec une qualité douteuse, ce qui pourrait refroidir les prix à terme. Un autre signale que CXMT produit désormais autant qu'un des trois grands fabricants.
La discussion nuance l'article sur plusieurs points. D'aucuns estiment que la pénurie n'est pas qu'une question de capacité mais aussi de choix stratégiques : les fabricants ne veulent pas investir dans de nouvelles usines tant que la rentabilité n'est pas garantie, et certains évoquent un risque de bulle financière si les commandes d'IA ne sont pas honorées. Un avis minoritaire rappelle que les prix de la mémoire sont cycliques et que cette tension est dans la norme, même si elle est plus marquée. Enfin, un commentaire mentionne que la livraison de RAM chez Amazon en Inde requiert désormais un mot de passe, preuve de la valeur élevée de ces produits.
-
99% of My Website Traffic Is Bots
L'article, dont seul le titre est disponible, évoque le constat que 99 % du trafic d'un site web provient de bots.
La discussion confirme massivement le constat de l'article : plusieurs commentateurs rapportent des proportions de bots similaires ou pires, avec des chiffres concrets. L'un cite près d'un million de visiteurs uniques pour seulement quelques dizaines d'humains par jour ; un autre détaille 205 000 pages récupérées par le seul `Claude-SearchBot` en 72 heures sur son site, pour un seul clic de référence. Beaucoup soulignent le coût réel, comme cette facture D1 multipliée par cinq en un mois, et un praticien recommande de passer sur un site statique plutôt que de subir ces coûts. Un commentateur, qui opère une instance GitLab pour 500 utilisateurs, explique avoir fait chuter la charge serveur de 99 % à 0,1 % en bloquant les crawlers chinois par plages IP.
Sur les solutions, les avis divergent nettement. Plusieurs présentent Anubis, un système de preuve de travail, comme une parade efficace ; mais un autre commentateur affirme que cette protection est trivialement contournée par une implémentation native, citant un solveur CUDA des milliers de fois plus rapide que le navigateur. L'usage de Cloudflare divise : certains le recommandent pour se protéger des bots, d'autres s'inquiètent de confier à une grande entreprise le pouvoir de décider qui voit un site, et un commentateur évoque le principe de ne pas vouloir mettre tout le web derrière Cloudflare. Des stratégies alternatives sont partagées : bloquer les ASN de clouds avec un CAPTCHA (en laissant passer Google et Bing), bloquer par pays avec prudence pour ne pas pénaliser les VPN, ou simplement ignorer les bots. Un commentateur conseille de ne pas sur-bloquer et de servir les pages tant qu'elles ne sont pas coûteuses.
La discussion nuance aussi l'article sur un point : la question des requêtes initiées par un humain via ChatGPT ou un assistant. Un commentateur estime que l'article n'aborde pas ce cas, mais un autre rappelle que la section « Claude ratio » le traite en distinguant les user-agents de scraping des requêtes utilisateur, et que ces dernières sont infimes.
-
Assembly Hall of Shame
Article présentant un concours informel pour trouver l'instruction x86 la plus lente possible, en cherchant à maximiser la latence d'une seule instruction. La stratégie gagnante utilise fxrstor64 avec un accès MMIO via le bus PCIe, saturé par d'autres cœurs, atteignant environ 198 milliards de cycles (62 s) sur un AMD Ryzen 7 5800H. Suivent des mesures pour d'autres instructions : nop (1 cycle), rdtsc (49), idiv avec grand dividende (77), enter (112), fsin (257), mfence (326), wrmsr (34 304), wbinvd (1,6 million), etc. L'article explore des microarchitectures et des méthodes de benchmark extrêmes.
La discussion autour de l'« Assembly Hall of Shame » est globalement enthousiaste, mais plusieurs commentateurs soulèvent des réserves méthodologiques. Le principal reproche concerne l'utilisation de MMIO (memory-mapped I/O) : un participant juge que cela « triche » et rend les résultats « ennuyeux », car lenteurs artificielles via des ports ACPI ou la saturation du bus PCIe ne reflètent pas le comportement en mémoire principale. Un autre remarque que la règle excluant les handlers de traps n'empêche pas certaines entrées de piéger en SMM. Plusieurs s'accordent à dire que la plupart des stratégies gagnantes reposent sur des manipulations de MMIO ou des subnormaux, ce qui limite l'intérêt pratique.
Des corrections factuelles émergent : un commentateur conteste la valeur de 49 cycles pour RDTSC, affirmant qu'elle est plutôt d'environ 25 cycles sur les microarchitectures Skylake, et explique que l'instruction agit comme une barrière d'exécution. Un autre relève que NOP devrait être premier car « infiniment lent pour ce qu'il fait », avec une réponse ironique sur son incrément de RIP. La discussion mentionne aussi les travaux parallèles de l'auteur (compilateurs à base de MOV, sandsifter, repsych) et un lien vers un projet similaire utilisant des instructions lentes pour casser SMI. Quelqu'un s'interroge sur l'utilité réelle de ces découvertes, sans obtenir de réponse claire.
Un avis minoritaire critique le style de rédaction, jugé « ennuyeux et typique des LLM ». Globalement, la discussion complète l'article en mettant en garde contre les artefacts de mesure et en proposant des pistes comme tester d'autres architectures (POWER) ou explorer la limite théorique de fxrstor64. Rien ne contredit frontalement l'article, mais plusieurs nuances méthodologiques sont apportées.
-
U.S. economy lost 23,000 jobs in July, a sudden reversal
L'économie américaine a perdu 23 000 emplois en juillet, un net retournement après quatre mois de créations positives. Le taux de chômage a légèrement baissé à 4,1 %, alors que les économistes attendaient 83 000 créations. Les chiffres des deux mois précédents ont été révisés en baisse de 103 000 postes au total.
La croissance des salaires horaires a été de 0,1 % sur un mois et de 3,2 % sur un an, sous l'inflation (3,5 %), un plus bas en cinq ans. Le taux de participation à la main-d'œuvre est au plus bas depuis février 2021. Les pertes d'emplois sont marquées dans l'éducation locale (-50 000), l'hôtellerie-restauration (-40 000), le commerce de détail (-19 000) et la finance (-14 000), tandis que la santé (+22 000), la construction (+22 000) et la fabrication (+5 000) progressent.
Les marchés actions ont monté après le rapport, les rendements obligataires ont baissé, et la probabilité d'une hausse des taux en septembre est tombée d'environ 50 % à 40 %.
Plusieurs commentateurs critiquent l'absence de barres d'erreur et soulignent le bruit statistique des chiffres mensuels de l'emploi. Ils rappellent que les premières estimations sont souvent révisées, citant par exemple la révision de mai 2026 de 172 000 à 63 000 emplois. D'autres contestent le qualificatif de « revirement soudain », y voyant plutôt une tendance baissière sur plusieurs mois. Un commentateur corrige l'article sur la baisse dans l'éducation : les enseignants restent généralement sur les listes de paie pendant l'été, il s'agit donc probablement de contrats précaires ou de postes saisonniers, qui devraient de toute façon être lissés.
La discussion relève aussi que la santé est le seul secteur créateur d'emplois, une tendance déjà observée les mois précédents, ce qui nourrit des interprétations politiques. Le fait que le marché monte malgré ce mauvais chiffre est expliqué par l'anticipation d'une baisse des taux de la Fed. La fiabilité des données est remise en cause : le taux de réponse aux enquêtes de la BLS est passé d'environ 85 % à 65 % en une décennie, et les deux mois précédents ont été révisés en baisse de 103 000 emplois cumulés. Certains y voient une manipulation statistique à des fins électorales, mais un commentateur oppose que la BLS suit aussi les travailleurs découragés et dénonce les théories du complot.
Quelques interventions apportent un contexte externe : le Canada a créé 75 000 emplois en juillet, bien qu'un commentateur note sa faible productivité. Un autre déplore que l'article ignore les licenciements dans la tech, mais on lui répond que ce secteur n'est pas majoritaire dans les pertes et n'existe pas en tant que catégorie NAICS. Dans l'ensemble, le fil exprime un profond scepticisme envers le chiffre brut, partagé entre ceux qui voient une détérioration réelle et ceux qui le réduisent à du bruit statistique, avec en toile de fond des accusations récurrentes de manipulation politique.
-
App Store Rejection of the Week: Dark Hours
John Gruber rapporte que l'application Dark Hours, méticuleusement conçue pour l'astronomie amateur, a été rejetée par l'App Store d'Apple au motif qu'elle relèverait de l'astrologie. Malgré les recours, l'App Review Board a maintenu le rejet en affirmant, à tort, que l'application propose des lectures de tarot. Gruber voit dans ce refus persistant un symptôme du dysfonctionnement du processus de revue d'Apple, préjudiciable aux développeurs comme à Apple elle-même.
La discussion converge sur l'arbitraire et l'incohérence du processus de revue de l'App Store. Plusieurs développeurs rapportent des expériences similaires : délais imprévisibles (un cas de 90 jours pour un compte développeur d'entreprise), rejets aléatoires à chaque mise à jour, absence de contexte entre les revues, et des réponses parfois absurdes (une app visionOS rejetée parce que le reviewer avait Safari ouvert hors écran, finalement acceptée en appel). Un commentateur résume : « c'est une CI non déterministe ». D'autres signalent que Google Play n'est pas mieux, avec un rejet lié à une image promo comportant du sang, alors que l'app officielle Google TV montre la même image sans avertissement.
La discussion corrige et nuance l'article sur un point important : la raison officielle du rejet de Dark Hours n'est pas l'astrologie mais une « fonction de tarot en direct » qui n'existe pas. Plusieurs rappellent qu'Apple a des directives précises interdisant les nouvelles apps de divination, considérées comme spammy, à moins d'une expérience « significativement différente ». Cela explique le rejet, même si l'incohérence reste flagrante : l'app d'astrologie Co-Star a été mise en avant par Apple. Certains commentateurs suggèrent une parade cynique — resoumettre avec le commentaire « fonction tarot retirée » — ce que d'autres condamnent comme un mensonge. Un avis minoritaire estime que l'app elle-même semble générée par IA et ne mérite pas tant d'éloges.
Plusieurs commentaires élargissent le débat à la distribution des logiciels en général : certains plaident pour des web apps pour contourner les magasins d'applications, d'autres évoquent les monopoles de distribution et la nécessité de pouvoir installer des apps depuis d'autres sources (avec référence au mouvement Keep Android Open). La discussion donne aussi des informations concrètes : les revues semblent parfois externalisées ou effectuées par des assistants IA, et la distinction astrologie/astronomie a une longue histoire de confusion.
-
Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
pgrust, une extension Postgres écrite en Rust, sort en version 0.2 avec des gains de performance spectaculaires : 10x plus rapide que la version précédente, 30% plus rapide que Postgres sur OLTP, et 300x plus rapide sur ClickBench, benchmark analytique de Clickhouse. L'article explique comment le moteur de requêtes a été optimisé via le batching, la fusion d'opérateurs et SIMD, et compare la lenteur du modèle Volcano de Postgres à une boucle simple en Rust. Un exemple de somme de 500 millions de nombres prend 20s sous Postgres contre 358ms en Rust. L'implémentation miniature d'un moteur de requêtes montre que le batching réduit le temps de 1.3s à 480ms.
Plusieurs commentateurs saluent l'ambition technique de pgrust, notamment l'adaptive planning, longtemps réclamé à PostgreSQL, et le planificateur d'E/S fondé sur des papiers académiques. L'auteur précise sa méthodologie de validation : preuves formelles pour plus de 1000 fonctions et fuzzing différentiel sur des millions d'entrées, qui a révélé ~100 bugs dans pgrust et ~20 dans PostgreSQL. Un commentateur corrige une critique virulente : bien que le dépôt n'ait que deux commits, l'historique Git réel contient près de 6000 commits, ce qui atténue l'accusation de 'AI slop'. Plusieurs demandes d'éclaircissements sur l'utilisation comme bibliothèque (type SQLite) reçoivent une réponse évoquant un 'test mode' pour cloner une base en moins de 10 ms.
Le principal point de division reste la confiance. Beaucoup estiment que pgrust ne remplacera pas PostgreSQL en production, car la longévité et la continuité d'un outil critique priment sur la performance. Un commentateur dénonce le manque d'humilité d'un projet porté par une seule personne et un bus factor de 1 ; un autre rétorque que les gains réels convaincront. La discussion corrige aussi l'article : le benchmark de 300x a été réalisé avec la parallélisation de PostgreSQL désactivée, ce qui fausse la comparaison. Enfin, plusieurs s'interrogent sur le changement de licence MIT vers AGPL via réécriture par LLM, éthiquement douteux malgré une légalité apparente.
Quelques commentateurs enthousiastes y voient une opportunité pour du matériel modeste, et une comparaison avec pgColumnar ou ClickBench montre des performances supérieures. D'autres regrettent que le projet glisse d'une tentative sérieuse vers une 'démo clinquante', rappelant la différence entre modèle d'exécution et simple optimisation. Globalement, la discussion nuance fortement l'article : la vitesse annoncée est réelle mais conditionnelle, et la défiance vis-à-vis de l'origine du code et de la transparence domine les échanges.
-
Managing AI Coding Costs at Scale
Chez Databricks, l'IA pour le codage améliore nettement la productivité, mais les coûts augmentent de façon exponentielle. Plusieurs grandes entreprises (Stripe, Coinbase, Uber, Ramp) adoptent des techniques pour concilier accès large et enveloppe de coûts maîtrisée. Le levier principal est d'adopter rapidement les nouveaux modèles les plus efficients, pas seulement les plus intelligents, via des évaluations internes (Databricks a ainsi déployé GLM). Pour éviter le verrouillage des modèles, certains utilisent un méta-harnais (comme Omnigent) qui standardise l'interface tout en dirigeant les requêtes vers différents harnais.
Plutôt que des budgets durs, ces entreprises privilégient la visibilité des dépenses en temps réel et une friction progressive selon l'usage. Enfin, l'article aborde la réduction du contexte (les coûts sont dominés par le contexte collecté par les agents, pas la requête initiale) et la mise en cache des prompts.
La discussion confirme l'importance du sujet mais l'enrichit de retours de terrain. Plusieurs commentateurs partagent leurs expériences : l'un décrit un workflow détaillé avec des modèles variés, un autre souligne que les agents produisent souvent des designs médiocres, surtout en base de données/caching, et échouent à évaluer leur propre performance. D'autres notent que le changement de facturation (par siège à consommation) explique pourquoi les coûts explosent. Un thème central : la difficulté d'évaluer les agents, certains ayant construit des benchmarks maison, ce que l'article ne détaille pas.
Les avis divergent sur l'utilité réelle des agents. Un commentateur estime que pour les codebases complexes, il vaut mieux coder traditionnellement, car les agents rendent le code ingérable ; un autre conteste cette affirmation faute de preuves. Plusieurs rapportent que des modèles moins chers peuvent suffire, mais que la qualité baisse. D'autres encore voient les modèles comme des commodités interchangeables, ce qui remet en cause la pérennité des laboratoires d'IA. Un commentaire ironique réduit les conseils de l'article à des évidences, alors que d'autres les jugent pragmatiques et détaillés.
La discussion corrige l'article sur un point : l'utilisation d'API d'entreprise plutôt que d'abonnements, évitant tout problème de TOS. L'auteur de l'article répond aux questions, précisant qu'ils utilisent des modèles du commerce et expérimentent des benchmarkings. Des retours concrets sur Omnigent sont fournis, avec des réserves sur sa maturité. Plusieurs commentateurs insistent sur la nécessité de contrôler le contexte et d'éviter le gaspillage de tokens, un aspect que l'article aborde mais que les praticiens considèrent comme le vrai levier de coût.
-
Lost my phone at the office. Claude suggested tracking Bluetooth signal strength
Titre seul : un utilisateur a perdu son téléphone au bureau ; Claude (IA) a suggéré de suivre l'intensité du signal Bluetooth pour le retrouver.
Plusieurs commentateurs relatent des expériences similaires où un LLM les a aidés à résoudre un problème concret en quelques minutes : retrouver un objet via le signal Bluetooth, créer un jeu pour enfant, débugger GIMP ou inverser un protocole. Ils y voient une vraie rupture : l'IA permet à des non-spécialistes de fabriquer des outils sur mesure, rapidement et sans compétences préalables. Un ingénieur de 20 ans affirme ainsi avoir pu développer une dizaine d'applications personnelles qu'il utilise en production, chose impossible sans IA. D'autres expriment un mélange d'émerveillement et d'inquiétude face à la qualité du code généré, déjà décrit comme un futur fardeau technique.
Mais la discussion contredit fortement l'idée de nouveauté : retrouver un téléphone par la force du signal Bluetooth est une technique ancienne, intégrée dans les montres Garmin, des applications Android, des scripts bash avec `bluetoothctl`, ou des systèmes de présence domotique. Un commentateur rappelle l'avoir fait il y a 15 ans. D'autres soulignent que le LLM ne fait que rejouer des solutions connues, et que s'émerveiller de cela révèle une méconnaissance des outils existants. Certains doutent même de la véracité de l'anecdote, et un avis minoritaire juge ces critiques de l'IA « épuisantes » face à l'enthousiasme des utilisateurs.
Au final, l'article est nuancé : la valeur n'est pas dans l'intelligence du modèle mais dans la démocratisation de l'accès à des briques techniques connues. Les commentaires apportent des retours de terrain concrets (utilisation du RSSI pour localiser des enfants, câblage Ethernet réutilisé comme tire-fil, etc.) et corrigent l'impression de prouesse. Le consensus se dégage sur un point : l'IA abaisse la barrière, mais les méthodes qu'elle propose sont souvent déjà documentées, et la qualité du code reste un enjeu pour l'avenir.
-
Ancient Library – 1,060 Greek/Latin texts, click any word to parse it
Présentation d'Ancient Library, un outil de lecture des textes classiques grecs et latins (1 060 œuvres, 293 latines et 767 grecques, 140 auteurs) permettant de cliquer sur n'importe quel mot pour obtenir sa lemmatisation, sa morphologie et sa définition complète (Lewis & Short pour le latin, Liddell-Scott-Jones pour le grec). Le site organise les œuvres par genres : épopée, lyrique, tragédie, comédie, histoire, biographie, oratoire, philosophie, lettres, etc., avec un index A-Z complet.
Les commentateurs saluent l'initiative mais la jugent inaboutie. Le principal reproche porte sur la fiabilité de l'analyse morphologique : un lecteur signale une erreur sur « nostra » dans César (glosé nominatif pluriel neutre alors qu'il s'agit d'un ablatif singulier féminin), et un autre estime qu'environ 40 % des formes difficiles du chant 13 de l'Odyssée sont fausses ou sans réponse, là où Perseus fait mieux. L'interface est jugée boguée (popups qui ne se ferment pas, défilement erratique) et la tokenisation pose problème : l'enclitique -que est détachée, des espaces apparaissent avant la ponctuation, et le rendu du grec (accents, esprits) est critiqué. Plusieurs notent aussi l'absence de macrons et le mélange u/v, même si certains apprécient au contraire le respect des graphies originales.
La comparaison avec Perseus revient souvent : l'outil est perçu comme une version plus jolie mais moins complète, et la question « pourquoi ne pas utiliser Perseus ? » est posée à plusieurs reprises. Plusieurs commentateurs partagent leurs propres projets : l'un a construit Kevilex (lecteur grec avec suivi du vocabulaire), un autre NoDictionaries, et un autre encore un outil similaire basé sur Diogenes et la base TLG, proposant des pistes comme l'intégration du Barrington Atlas ou la génération de cartes Anki. Des corrections factuelles sont apportées : « fulgere » renvoyant à « fulgo » est en réalité une pratique normale des dictionnaires latins (entrée à la première personne), et dans une citation de Caton, « edes » est probablement un futur plutôt qu'un subjonctif.
Malgré ces critiques, l'enthousiasme domine chez les passionnés de langues anciennes, et plusieurs disent que ce type d'outil leur donne envie de se remettre à la lecture. Les demandes d'amélioration sont précises : meilleure police (notamment New Athena Unicode), tri chronologique des œuvres, mise en évidence du sens contextuel dans l'entrée, affichage bilingue, ou encore fermeture des popups en cliquant n'importe où. Un commentaire replace le projet dans la tradition des textes interlinéaires du XIXe siècle, rappelant que cette approche pédagogique a une longue histoire.
-
Water system controllers don't belong on the internet, says ex-NSA chief
L'ancien directeur de la NSA estime que les contrôleurs de systèmes d'eau ne devraient pas être connectés à Internet.
La discussion reprend largement l'idée de l'article, qualifiée par certains de « l'eau est mouillée », mais l'enrichit de retours de terrain. Plusieurs commentateurs ayant travaillé sur des automates programmables (PLC) décrivent un monde industriel éloigné des pratiques du génie logiciel : absence de contrôle de version, intégration tardive, et une culture où la programmation est un après-coup après la construction de l'usine. Un praticien raconte avoir vu un intégrateur utiliser Windows pour piloter un système critique, illustrant la fragilité du secteur. On relève aussi que les liaisons radio locales (RF, Bluetooth) sont souvent peu sûres, même sans exposition directe à Internet, et que les infrastructures comme les stations de compression de gaz naturel sont vulnérables à des attaques par déni de service.
Plusieurs avis nuancent toutefois la position de l'ex-NSA. L'air gap n'est pas une protection absolue : il faut bien une supervision centralisée, donc un accès réseau, et les failles humaines (clics sur pièces jointes, Windows non patché) suffisent souvent. La solution préconisée par plusieurs est de ne jamais exposer directement les PLC à Internet, mais d'interposer un VPN et un pare-feu, tout en reconnaissant que « si c'est fait avec compétence » est une hypothèse optimiste. Un commentateur remarque que les systèmes connectés sont toujours compromis à terme, et qu'il faut les durcir sans connexion physique à Internet, sauf pour des dispositifs de lecture seule. Un autre propose de rendre par défaut tout service non destiné à des clients non authentifiés « non joignable » sur le réseau.
La discussion contredit ou nuance l'article sur la responsabilité. Une réponse souligne que la NSA et la DHS ne sont pas en charge des infrastructures locales et qu'accuser de négligence est exagéré, même s'ils publient des guides de cybersécurité. Un commentaire plus critique suggère que les agences de renseignement privilégient leur capacité d'exploitation des vulnérabilités plutôt que leur défense. Enfin, un avis cynique compare l'attitude des États-Unis à celle d'autres pays qui sécurisent leur eau, et un autre évoque un risque d'incident majeur si rien n'est fait.
-
Show HN: Wyzer Programming Language
Wyzer est un langage de programmation compilé, statiquement typé, orienté ressources, combinant programmation chorégraphique et modèle mémoire Perceus. Il permet d'écrire un programme unique pour des systèmes distribués, le compilateur projetant ce code en binaires indépendants sans interblocage. Le modèle Perceus utilise un comptage de références précis pour gérer la mémoire sans garbage collector ni borrow checker, avec mutation en place (FBIP). Le langage garantit l'absence d'interblocage, la sécurité des transferts réseau via des déplacements linéaires, et offre une compatibilité avec l'ABI C. L'article présente des exemples de code et des liens vers la documentation, la recherche et un serveur Discord.
Plusieurs commentateurs saluent l'ambition de Wyzer, notamment l'idée de programmation chorégraphique, mais regrettent que la documentation enterre les innovations sous une présentation syntaxique classique. Ils conseillent de mettre en avant un exemple de code distribué dès le début du README; l'auteur répond qu'il restructure en ce sens. Un commentateur explique que la chorégraphie évite les interblocages distribués en décrivant envoi et réception comme une seule opération, mais admet que l'expressivité est réduite. D'autres signalent que le README ne décrit pas réellement le fonctionnement de la chorégraphie et renvoient vers des ressources pédagogiques.
La discussion corrige ou nuance l'article sur deux points. D'une part, l'affirmation du README selon laquelle les garbage collectors rendent les langages 'plus lents et moins prévisibles' est contestée: un commentateur détaille la diversité des algorithmes de GC (refcounting Python, mark-and-sweep Go, moving collectors Java) et soutient que certains sont plus rapides et plus prévisibles que la gestion manuelle en C++ dans les grands logiciels concurrents. D'autre part, la revendication de sécurité mémoire est accueillie avec scepticisme: un praticien du domaine estime que Wyzer ressemble à 'Rust sans borrow checker' et demande comment sont gérés les structures partagées et les mutex. Un commentaire pointe aussi l'absence de discussion sur les compromis ou les timeouts pour les appels externes.
Enfin, plusieurs intervenants demandent des exemples concrets, non triviaux, montrant ce que Wyzer permet de faire difficilement ailleurs, et comparent la chorégraphie à d'autres approches (server functions de Next.js, Clojure Electric, session types, MPI/PGAS). Un avis minoritaire souligne que la lisibilité du README est bonne, mais que la partie sur le modèle de ressources mériterait plus de détails. Dans l'ensemble, la discussion est plus riche que l'article lui-même: elle apporte des éclairages techniques sur la chorégraphie, mais aussi des réserves argumentées sur les promesses du langage.
-
Kitesurf: Agent-first browser that runs in V8 isolates
Cloudflare annonce Kitesurf, un navigateur conçu spécifiquement pour les agents IA, qui tourne entièrement sur Workers. Il est disponible gratuitement en bêta dans Browser Run. L'objectif est de remplacer Chromium pour les tâches agentiques courantes comme les captures d'écran et l'extraction HTML, avec une bien meilleure efficacité CPU et mémoire.
Le projet est parti d'un portage de l'engin headless Rust “obscura” vers Workers, assisté par IA. Les choix de conception incluent une forte utilisation des Web Platform Tests pour guider le développement, du Rust compilé en Wasm pour la performance, une gestion rigoureuse des exceptions pour ne jamais tuer une session, et une isolation stricte entre composants. L'architecture privilégie des composants sans état pour faciliter la scalabilité et la reprise après erreur.
La discussion technique salue l'architecture de Kitesurf, construit sur le moteur Blitz (open source) et validé via les tests WPT. Plusieurs commentateurs s'intéressent au support de WebDriver BiDi, un standard W3C jugé préférable aux protocoles propriétaires comme CDP ; l'auteur de Blitz confirme y porter attention et prévoit d'ouvrir le code. Un commentaire relève le côté méta d'un moteur JS en Rust compilé en WASM tournant dans V8, et l'auteur répond que l'évaluation native arrivera dans Workers. Certains doutent que Kitesurf soit un « navigateur » au sens classique, le voyant plutôt comme un outil de données web.
Le point le plus discuté est le conflit d'intérêts potentiel de Cloudflare, à la fois protection anti-bot et fournisseur d'outils d'automatisation. Plusieurs commentateurs trouvent cela paradoxal, voire suspect, et demandent si les instances Kitesurf contournent les protections de Cloudflare. Une réponse officielle précise que non : les requêtes sont identifiées comme du trafic bot via un user-agent documenté et une signature Web Bot Auth. Cela nuance l'article, qui pouvait laisser penser à un accès privilégié. Un commentateur note d'ailleurs que ces instances sont simplement bloquées, ce qui rend l'outil « inutile » pour le scraping, mais d'autres y voient une avancée pour les agents légitimes.
La sécurité est un autre axe : un commentateur argue que l'isolat V8 protège le mauvais côté, car le risque principal d'un agent navigateur est l'injection de prompt depuis une page hostile, non l'évasion du code. Il demande comment Kitesurf limite ce que l'agent peut faire après lecture d'une page malveillante. Un praticien partage son expérience : pour automatiser le web, ce ne sont pas le rendu ni le JS qui bloquent, mais l'identité (captchas, vérifications e-mail/téléphone). Une réponse mentionne que Cloudflare travaille justement sur une identité portable et des paiements (x402). Enfin, plusieurs commentateurs souhaitent une version open source pouvant être auto-hébergée, et la réponse indique que cela arrivera bientôt, tout en rappelant que Kitesurf ne cherche pas à se cacher des sites qui veulent le bloquer.
-
Iceberg Collapses and Flips over in Ilulissat, Greenland (July 25, 2026) [video]
Vidéo montrant un iceberg s'effondrant et se retournant à Ilulissat, au Groenland, le 25 juillet 2026.
La discussion salue unanimement la beauté et la puissance de la vidéo, beaucoup comparant l'iceberg à une créature vivante ou à un monde qui s'effondre. Plusieurs commentateurs soulignent le côté organique du mouvement, certains évoquant Godzilla ou Solaris. Un point récurrent : la musique forte qui gêne l'écoute de l'audio réel, et le fait que le commentaire le plus populaire sous la vidéo concerne la génération par IA, ce qui agace certains qui rappellent qu'une vérification par les sources scientifiques est facile.
Sur le plan technique, plusieurs questions sont posées. Pourquoi pas de vague énorme ? La réponse convergente : l'iceberg flotte et sa densité est proche de l'eau, donc le déplacement de volume change peu. Autre point : la base de l'iceberg s'effrite comme du sable, ce qui surprend ; un commentateur explique que l'eau sous la mer reste autour de -1°C à 4°C, alors que l'air peut être bien plus froid, et que la glace interne est autour de -10°C. Un détail important : la vidéo semble s'arrêter brusquement, et une réponse indique que c'est parce que l'iceberg touche le fond marin (grounded près de Disko Bay) et que la vitesse de la vidéo passe de ~8x à 1x. Plusieurs commentateurs notent que le titre est un peu trompeur : l'iceberg se retourne d'abord, puis s'effondre, et la perte de masse est surtout sous l'eau.
La question de l'authenticité est abordée. Un commentateur demande comment vérifier, et une réponse fournit des liens vers des sources fiables (ESA, BBC). Un autre dit avoir fait une vérification rapide et que la vidéo semble légitime. Enfin, des liens sont partagés vers des ressources complémentaires : le plus grand vêlage glaciaire filmé, et un outil pour dessiner son propre iceberg (iceberger). La discussion ne contredit pas l'article, mais elle le nuance : il s'agit moins d'un effondrement simple que d'un retournement avec perte de masse, et le ralentissement final est dû à un contact avec le fond.