Hacker News
-
Tailscale Traces Database Corruption to 16y/o SQLite WAL-Reset Bug
Tailscale a subi de nombreuses pannes en 2023-2024 causées par une corruption de sa base de données SQLite. Après des mois d'investigation avec les développeurs de SQLite, l'équipe a identifié un bug vieux de 16 ans dans la réinitialisation du WAL de SQLite. L'article détaille les symptômes, les difficultés de diagnostic et les mesures de récupération automatisées mises en place (arrêt immédiat, monitoring des backups, journalisation des transactions).
Les commentateurs saluent unanimement la qualité du récit et l'attitude de Tailscale, qui a financé le développement d'un shim VFS open-source pour isoler le bug. Plusieurs soulignent que ce financement d'outils de débogage par une entreprise est un bel exemple de soutien à l'open source. Sur le plan technique, un commentaire contredit une implication de l'article : le bug ne peut survenir qu'avec plusieurs connexions ouvertes, or l'article présentait le design comme mono-écrivain. Un autre commentaire relève une incohérence dans les explications de Tailscale sur le nombre de pages copiées depuis le WAL, mais d'autres commentateurs proposent des interprétations conciliantes.
La discussion corrige aussi l'article sur la rareté du bug : plusieurs commentateurs notent qu'il est impossible à reproduire organiquement et que les développeurs de SQLite ont dû ajouter du code pour le déclencher délibérément. Un commentaire cite la phrase de l'article expliquant que Tailscale était plus exposé à cause de son checkpointing agressif et manuel. D'autres évoquent des cas de corruption sur du matériel défaillant (carte SD) et se demandent si Litestream, qui s'insère aussi dans le processus de checkpoint, pourrait être affecté. Un débat apparaît sur la pertinence d'utiliser SQLite pour un plan de contrôle, certains plaidant pour des KV stores plus simples.
Enfin, un commentaire mentionne que Richard Hipp a indiqué que des agents IA font du fuzzing sur SQLite et remontent déjà des bugs. Un autre signale un bug similaire dans Codex. Quelques commentaires mineurs portent sur les points uniques de défaillance et les tests, mais la discussion reste centrée sur la prouesse technique et les leçons à tirer.
-
DeepSeek V4 Pro 0813
Page OpenRouter présentant le modèle DeepSeek V4 Pro 0813. Elle détaille l'hébergement (un seul fournisseur), les prix réels, les performances (débit, latence, TTFT), la disponibilité, les benchmarks, les applications l'utilisant et l'activité du modèle. Un guide de démarrage rapide est inclus, avec un appel compatible API OpenAI.
Plusieurs commentateurs considèrent que DeepSeek V4 Flash 0731 reste le modèle le plus remarquable récent par rapport au nouveau V4 Pro, notamment pour son rapport capacité/prix. Certains restent donc sur Flash, déçus par Pro, tandis que d'autres y voient une progression significative. Un test sur une tâche complexe de génération de docker-compose a montré des échecs pour Pro là où GPT-5.6-terra-high réussissait, illustrant un décalage entre les benchmarks et l'usage réel. Un retour d'expérience sur un simulateur de physique rapporte des gains notables malgré un coût de 12,50 $ pour 2B de tokens, un autre intervenant soulignant qu'avec un cache bien géré (99 % de hits) ce coût pourrait chuter à quelques dollars.
Les tableaux de benchmarks comparants Pro 0813 à Flash, GLM-5.2, Kimi-K3, Opus-4.8 et Fable 5 montrent que Pro est globalement au niveau des modèles premium comme Fable ou Opus sur les agents, mais bien moins cher (environ 20 fois moins qu'Opus 4.8). La sortie le même jour que Qwen3.8-max est perçue comme une tentative de contre-attaquer, Pro étant plus performant sur plusieurs métriques (Terminal Bench, NL2Repo, Toolathlon) mais plus faible sur d'autres (HLE, DeepSWE). Un commentateur évoque la possibilité de faire tourner Flash localement pour 8000 $ (2x DGX Spark).
Plusieurs avis nuancent l'article : des utilisateurs trouvent Pro lent ou peu fiable en pass@1, bien qu'efficace en pass@3, un souci possiblement lié à l'entraînement GRPO. D'autres signalent de mauvais résultats aux tests d'hallucinations (AA-Omniscience), peut-être à cause d'une sur-spécialisation en codage. Enfin, l'hébergement sur OpenRouter exige actuellement d'accepter l'entraînement sur les données, ce qui freine certains testeurs, d'autres rappelant qu'il faut traiter toute requête à DeepSeek comme potentiellement publique.
-
AI is removing the middle class of software engineering
L'article décrit comment l'IA accélère la dégradation des projets logiciels dans les équipes sans culture d'ingénierie solide. Des agents peuvent générer des PR massives (ex. +24506/-3938 lignes) que personne ne comprend vraiment, tandis que les décisions d'architecture sont déléguées à des conversations Claude. Le coût de la dette technique devient incontrôlable et les correctifs sont difficiles à réverter.
L'auteur soutient que l'IA abaisse la barrière de production de code, mais que la compréhension et le jugement restent essentiels. Les ingénieurs compétents deviennent plus précieux, car ils peuvent aller plus vite grâce à l'IA, tandis que ceux qui ne font que relayer des prompts deviennent moins employables ou moins bien payés. La valeur se concentre sur une minorité capable de comprendre et de valider les systèmes.
La discussion reprend largement la thèse de l'article : l'IA supprime une partie du travail d'implémentation et creuse l'écart entre les ingénieurs capables de penser en termes de systèmes et ceux qui se contentent d'exécuter des tickets. Plusieurs commentateurs décrivent l'IA comme l'« automatisation de l'ingénieur Stack Overflow » : un senior peut désormais déléguer la rédaction du code à un agent, sans avoir besoin d'une équipe de développeurs juniors. Cette évolution est vue comme une sélection naturelle, mais certains préviennent qu'elle amplifie aussi l'impact des mauvais ingénieurs, qui peuvent propager du code médiocre à grande échelle. Un avis plus nuancé estime que l'IA atténue au contraire les défauts des mauvais développeurs en produisant un code plus propre et mieux testé, mais que le problème principal reste la conception et l'architecture, domaines où l'IA ne remplace pas la pensée systémique.
Plusieurs commentaires corrigent ou nuancent le modèle présenté dans l'article. Un praticien de vingt ans affirme que la répartition idéale « senior pense, junior exécute » n'a jamais existé dans la pratique : les tâches sont attribuées en fonction de la disponibilité, et les juniors se retrouvent souvent à concevoir des projets complexes sans encadrement. D'autres insistent sur le risque de délégation aveugle : ne pas comprendre le code généré, approuver sans vérifier, et laisser l'IA prendre des décisions d'architecture conduit à des dettes techniques ingérables. L'idée que l'IA ferait « échouer plus vite » les projets à faible culture d'ingénierie est contestée : au contraire, elle permettrait d'aller plus loin dans le désordre avant que le problème ne devienne critique. Un commentateur remarque que déléguer la réflexion à Claude revient à devenir le manager de l'IA, ce qui change la nature du travail.
Sur le marché de l'emploi, l'accord est large pour constater que les postes juniors et intermédiaires sont les plus menacés, et que le pipeline de formation des seniors est cassé : sans juniors pour apprendre, comment former la prochaine génération ?
-
Qwen3.8-2.4T
Qwen3.8-2.4T-A95B, dernière génération de modèles ouverts de Qwen, est publié. Il totalise 2,4 billions de paramètres avec 95 milliards activés, bâti sur l'architecture Qwen3.5, avec des gains en code, travail professionnel, recherche et tâches agentiques longues. Le modèle est purement textuel et exige le mode réflexion pour toutes les interactions, avec un contexte natif de 262 144 jetons extensible à 1 010 000. La version Qwen3.8-Max basée sur ce modèle ajoute vision, outils intégrés et 1M de contexte par défaut.
Le modèle est compatible avec vLLM, SGLang, TokenSpeed, etc. Des paramètres de génération recommandés sont fournis, ainsi qu'un contrôle de l'effort de raisonnement (xhigh, medium, low) et l'option preserve_thinking. La publication inclut une comparaison de benchmarks (SWE-bench Pro, Terminal Bench 2.1, etc.) avec des modèles comme Claude Opus 4.8, GPT-5.6 Sol, et souligne la performance sur des tâches d'ingénierie logicielle et d'agents.
La discussion tourne autour de la sortie de Qwen3.8-2.4T, un modèle open weight très volumineux (4,9 To en BF16, ~2,5 To en FP8). Plusieurs commentateurs notent qu'il s'agit d'un concurrent direct de Kimi k3, mais avec des différences importantes : Kimi k3 a été lancé en QAT 4 bits (~1,5 To), alors que Qwen ne publie que du BF16/FP8, ce qui le rend plus difficile à servir au lancement. Une quantification 4 bits non QAT est jugée possible mais nécessiterait des ressources importantes et des données de calibration. La licence est comparée à celle de Kimi k3, avec des restrictions au-delà de 50 M$ de revenus ou pour les services de coding/productivité. Les benchmarks annoncés placent le modèle entre Opus 4.8 et Fable 5, mais plusieurs commentateurs restent prudents sur la corrélation entre les benchmarks Qwen et l'usage réel.
Un point central de la discussion est la perte de fonctionnalités par rapport à la version officielle : pas de vision, contexte limité à 250k, modes de raisonnement restreints. Plusieurs intervenants regrettent ce choix, le jugeant « inutile » et « hors de propos » comparé à Qwen3.5 qui était plus ouvert et complet. Des pistes sont évoquées pour restaurer la vision en greffant un encodeur visuel d'un autre modèle, avec des précédents réussis sur DeepSeek ou GLM. Certains commentateurs attendent avec plus d'intérêt la sortie du Qwen3.8-27B prévu pour vendredi, qui serait plus accessible en local. Un avis minoritaire mentionne que la performance de niveau Opus 4.5 est déjà accessible avec DeepSeek-V4-Flash, bien plus petit, remettant en cause l'intérêt pratique de ce très gros modèle.
La discussion apporte aussi des informations factuelles : DeepSeek V4-Pro-0813 (1,6T-A49B) vient d'être annoncé sur WeChat et est déjà sur OpenRouter, avec des scores environ au niveau Fable 5. Un commentateur corrige l'idée que ce serait le plus gros modèle open weight jamais publié : Kimi k3 est plus gros (2,8T paramètres, mais ~1,5 To en QAT 4 bits). La taille du vocabulaire (~248k) est relevée comme inhabituellement élevée par rapport aux autres modèles chinois récents.
-
uBlock Origin Is Giving Up the Fight to Keep Ads Off Facebook
uBlock Origin abandonne la lutte pour bloquer les publicités sur Facebook.
La discussion tourne autour de l'abandon par uBlock Origin du blocage des publicités sur Facebook. Plusieurs commentateurs partagent un profond rejet de la publicité en ligne, la décrivant comme une « attaque contre le cerveau » ou un logiciel malveillant qui manipule et espionne l'utilisateur. Ils s'accordent sur le fait que les plateformes comme Facebook sont conçues pour être addictives et nuisibles, et beaucoup estiment que la seule solution efficace est de quitter complètement le réseau social. Ce point de vue est répété : supprimer son compte, malgré la difficulté de rester en contact avec certains proches ou de suivre des groupes locaux. D'autres, plus modérés, comprennent la décision d'uBlock Origin, jugeant qu'il est inutile de prolonger l'illusion qu'on peut échapper à la surveillance de Facebook.
Plusieurs commentaires apportent des détails techniques. On explique que Facebook complique le blocage en générant un balisage HTML volontairement illisible : des `div` imbriqués, des noms de classes aléatoires et des mots comme « ad » découpés en lettres. Certains praticiens partagent leurs anciennes règles de filtrage, soulignant la complexité des sélecteurs CSS. Un commentateur propose une approche alternative : whitelister le contenu non publicitaire au lieu de cibler les publicités, mais un autre répond que cela est devenu impossible tant le code est généré aléatoirement et change constamment. Une correction de l'article est implicite : la course à l'armement n'est pas près de s'arrêter, et un commentateur a même expérimenté avec succès un bloqueur basé sur un modèle de vision par ordinateur, qui identifie et masque les éléments visuels ressemblant à des publicités.
Un point de division net oppose ceux qui croient aux solutions techniques et ceux qui prônent l'abandon total. Certains s'inquiètent que YouTube, voyant que uBlock lâche prise, redouble d'efforts. D'autres répondent que YouTube propose une option payante raisonnable, contrairement à Facebook.
-
Delta
Delta est un nouvel environnement collaboratif de codage avec agents IA, présenté par l'équipe de Zed. Il connecte conversations et code dans un fil de discussion où développeurs et agents travaillent ensemble. DeltaDB, sa base de données répliquée, synchronise en temps réel la conversation et l'arbre de travail, tout en restant compatible avec les dépôts git existants : chaque édition et conversation est capturée entre les commits, et les coéquipiers qui n'utilisent pas Delta voient un dépôt git normal.
L'outil permet de commenter n'importe quelle ligne de code ou partie de la conversation, avec l'agent présent dans le fil pour expliquer ou corriger son travail. Il propose aussi un mode cloud, le partage par lien avec une version navigateur compilée en WebAssembly, et une intégration avec Claude Code pour synchroniser les sessions de terminal.
Delta est conçu pour afficher intégralement les diffs et transcriptions générés par les agents, et permet de répondre directement à n'importe quel point du fil. Les premières invitations en bêta privée ont été envoyées, avec des invitations supplémentaires à venir.
La discussion est très partagée sur Delta, l'outil de collaboration et d'annotation pour agents de Zed. Plusieurs commentateurs sont enthousiastes : ils ont testé l'alpha et la trouvent très bonne, notamment la possibilité d'annoter directement les messages de l'agent, ce qui facilite le mentorat et le handoff. Un participant souligne que l'application est déjà accessible via le web grâce à WebAssembly et WebGL. D'autres en revanche se disent sceptiques : coder est un jeu solo, l'utilité d'un éditeur multi-utilisateurs n'est pas évidente, et les résumés IA du code sont souvent verbeux et omettent des cas particuliers. Certains rappellent que des outils comme Codex proposent déjà des annotations similaires, et que préserver des transcripts entiers pourrait devenir pénible à relire, comme des historiques de chat.
Un autre fil critique la stratégie de Zed. Beaucoup estiment que la société néglige les fondamentaux de l'éditeur : bugs, finitions, et qu'il y a une véritable crise d'identité. Un commentaire affirme que Zed est en train de devenir une copie de VS Code. D'autres répondent que Delta est un produit distinct, nécessaire pour explorer de nouvelles interactions sans casser l'éditeur existant. Des questions se posent aussi sur l'absence d'open source pour DeltaDB, contrairement à Zed, et sur l'intérêt concret par rapport à des git worktrees. L'article est par ailleurs critiqué pour son faible contraste de couleurs, nuisant à la lecture.
Enfin, certains voient dans Delta un changement de paradigme : l'agent n'est plus dans la barre latérale, il est au centre de l'interface, et c'est exactement ce que les modèles actuels exigent. D'autres jugent cette orientation rétrograde, car la revue de code se concentre désormais sur les exigences fonctionnelles plus que sur la lecture ligne par ligne. La discussion nuance aussi l'article en précisant que DeltaDB n'est pas destinée à Zed mais à une nouvelle application, et qu'il ne s'agit pas d'un IDE complet mais d'une interface orientée agent. Un lien vers un précédent fil HN de 300 commentaires est également partagé, ce qui montre l'importance du sujet dans la communauté.
-
License plate reader searches should require a warrant
Un analyste de la criminalité plaide pour qu'un mandat soit exigé avant toute recherche historique dans les données de lecteurs automatiques de plaques d'immatriculation (ALPR). Il s'appuie sur l'affaire Schmidt v City of Norfolk et sur la jurisprudence Carpenter pour estimer que cette obligation deviendra inévitable, les caméras se généralisant. Il distingue le signalement actif de véhicules volés, qu'il juge légitime, des recherches rétroactives permettant de tracer les déplacements d'une personne, et propose des procédures de mandat encadrées par les États. Il critique aussi la conservation très courte des données, qui selon lui limite l'utilité policière sans empêcher les abus.
Plusieurs commentateurs s'accordent sur l'existence d'un problème d'abus potentiels avec les lecteurs de plaques, citant des cas de policiers ayant utilisé ces données à des fins personnelles. Un avis récurrent propose soit l'exigence d'un mandat, soit une transparence totale, jugeant intenable la situation actuelle où la police y accède sans contrôle judiciaire tout en échappant aux lois sur l'accès à l'information. D'autres contestent cette dichotomie : l'argument du « mandat » serait une protection insuffisante, le vrai problème étant la collecte et la conservation massives de données. Certaines voix, minoritaires, défendent ces systèmes en s'appuyant sur l'exemple de la Chine ou sur le fait que les plaques sont visibles dans l'espace public.
La discussion corrige ou nuance l'article sur plusieurs points. Le ton d'inéluctabilité de l'auteur est critiqué : des pays comme l'Allemagne interdisent ce type de surveillance, donc c'est un choix politique. Plusieurs intervenants notent que les lecteurs de plaques sont en réalité des caméras connectées programmables, ce qui élargit le débat au-delà des seules plaques. L'accent mis uniquement sur le mandat est jugé trompeur : sans limitation de conservation ni audits efficaces, le mandat n'empêche ni les fuites ni les abus internes. Un commentateur souligne que les « hotlists » déclenchent déjà une recherche automatique au passage, donc la violation a déjà lieu avant toute consultation humaine.
Concrètement, des propositions alternatives émergent : exiger un numéro de dossier ou d'appel de service (CAD ID) plutôt qu'un mandat, ce que des chefs de police jugeraient acceptable, mais avec nécessité d'audits tiers. D'autres préconisent une conservation courte (par exemple 7 jours) sauf warrant. Un commentateur relate le cas de l'Inde où la surveillance faciale a été utilisée contre des manifestants. Quelqu'un mentionne une étude de cas de l'EFF sur les risques de divulgation publique. Enfin, un débat oppose ceux qui veulent supprimer ces systèmes et ceux qui acceptent une surveillance avec des garanties procédurales, certains citant des exemples locaux comme Irvine pour contester l'utilité sécuritaire.
-
Grok 4.6
Grok 4.6 est disponible, succédant à Grok 4.5 avec un accent sur les agents longue durée et le travail interactif et visuel. Le modèle atteint un niveau d'intelligence frontière sur plusieurs benchmarks, égalant GPT-5.6 Sol sur l'Artificial Analysis Intelligence Index, un score composite de neuf tests.
Le modèle est accessible dès aujourd'hui dans Cursor et Grok Build, avec une offre de double usage inclus la première semaine. Il est également disponible via l'API et des partenaires comme OpenRouter, Vercel et Cloudflare. L'entraînement a inclus davantage de données générées, des données d'ingénierie haute qualité, un optimiseur amélioré, et l'utilisation de Grok 4.5 pour régénérer les trajectoires SFT. Les garde-fous ont été renforcés et calibrés, avec la plus large suite de tests pré-déploiement à ce jour.
Le tarif est de 2 $ par million de tokens en entrée et 6 $ par million en sortie, avec une variante rapide au double du prix.
Plusieurs commentateurs saluent l'arrivée de Grok 4.6 comme un concurrent crédible sur la frontière, avec des performances annoncées au niveau de Fable 5 et GPT-5.6 Sol, pour un coût inférieur. Certains y voient une saine concurrence, mais d'autres s'interrogent sur la synchronisation des sorties récentes : comment toutes les labos ont-ils pu rattraper Fable en deux mois ? Plusieurs hypothèses sont évoquées, du benchmark hacking à l'absence de fossé technologique réel, sans consensus.
Sur le terrain, les retours sont mitigés. Un utilisateur a utilisé Grok 4.5 pour une revue de sécurité et en est très satisfait, tandis qu'un autre le trouve plus direct et concis que Claude ou GPT, mais un avis minoritaire le juge inférieur à Opus. Un employé de xAI affirme que l'équipe travaille sur les principes de design visuel, mais un designer indépendant doute de ces affirmations subjectives. Plusieurs commentateurs signalent un problème concret : un system prompt par défaut empêche le modèle de discuter de ses propres instructions, ce qui est jugé agaçant. D'autres notent que la limite d'utilisation sur SuperGrok se consume plus vite et que le mode vocal est devenu plus laconique.
La discussion corrige ou nuance l'article sur plusieurs points. L'article de Cursor vante des améliorations en une passe pour les projets visuels, mais cette déclaration est jugée peu utile sans comparaisons indépendantes. Le classement des benchmarks est critiqué : Opus 5 est absent, et un commentateur rappelle que les benchmarks ne reflètent pas la hiérarchie réelle des modèles, comme l'a montré la récente publication d'Anthropic. Un point pratique : les pages de prix n'ont pas encore été mises à jour, et la publication est peut-être freinée par un filtre anti-controverse sur Hacker News. Enfin, la question politique divise : certains refusent d'utiliser un produit lié à Musk, tandis que d'autres estiment que cela n'empêche pas de reconnaître les progrès techniques.
-
2026 Eclipse Webcams
Titre seulement : annonce de webcams pour l'éclipse de 2026. Aucun détail fourni.
Le fil de discussion est dominé par l'auteur de la carte interactive des webcams pour l'éclipse, qui explique l'avoir construite rapidement pour l'éclipse de 2024 et l'avoir oubliée jusqu'à aujourd'hui. Plusieurs commentateurs corrigent ou nuancent la fiabilité de l'outil : certaines webcams ne fonctionnent pas, beaucoup pointent dans la mauvaise direction, et d'autres renvoient des erreurs « access blocked » en raison de restriction de référent. L'auteur reconnaît qu'il n'y a pas de vérification de l'orientation des caméras, ce qui limite l'utilité de la carte pour suivre la totalité.
Le fil apporte aussi des ressources complémentaires : des flux officiels (NASA, ESA, Virtual Telescope, Royal Observatory Greenwich, RÚV islandais), un outil de localisation avec prévisions nuageuses pour l'Espagne, des données de production solaire en temps réel, et des suggestions de spots. Plusieurs commentateurs signalent que la météo est mauvaise en Islande, avec une couverture nuageuse de 96 % sur Reykjavik, et recommandent de privilégier l'Espagne. Un commentateur note une coïncidence rare : l'éclipse tombe en même temps que les Perséides, ce qui pourrait permettre d'observer des étoiles filantes dans le ciel assombri.
Enfin, des retours d'expérience personnels émaillent la discussion : un voyageur raconte avoir parcouru des centaines de kilomètres en 2024 pour échapper aux nuages, un autre se trouve sur un bateau de croisière près d'Ibiza. Un commentateur insiste sur le fait que voir la totalité à l'œil nu est sûr et transcendant, contre une certaine prudence excessive, et encourage à vivre l'instant plutôt que de se contenter des écrans. La discussion ne contredit pas frontalement l'article, mais elle en souligne fortement les limites pratiques et met en avant des alternatives plus fiables.
-
Facebook is paying controversial creators to produce rage-bait content
Une enquête d'ABC News Verify révèle que Meta, maison mère de Facebook, rémunère directement des créateurs de contenu controversés via son programme de monétisation. Sont notamment concernés un nationaliste blanc lié aux néo-nazis, Hugo Lennon, auteur d'insultes racistes envers le Premier ministre indien, et la fondatrice du groupe anti-vaccin Reignite Democracy Australia, Monica Smit. D'autres pages d'extrême droite australienne, comme The Noticer et March for Australia, bénéficient également du programme depuis fin 2025.
Ces contenus semblent parfois enfreindre les politiques de monétisation de Facebook, qui interdisent l'information médicale trompeuse et restreignent la monétisation des sujets sociaux débattus. Meta n'a pas commenté les pages spécifiques, rappelant ses politiques et affirmant qu'il ne lui revient pas de "polir l'offensant". L'enquête souligne que Meta est l'un des rares géants du numérique à divulguer des informations sur ses bénéficiaires, mais que la transparence reste limitée et l'application des règles insuffisante.
La discussion converge sur un constat : Meta, via son programme de monétisation de contenu, crée un puissant incitatif à produire du « rage-bait », car l'indignation génère de l'engagement et donc des revenus. Plusieurs commentateurs estiment que le titre de l'article est trompeur : Meta ne commandite pas directement les créateurs, mais les paie à la performance via un programme sur invitation. D'autres rétorquent que cette distinction est « couper les cheveux en quatre » dès lors que Meta amplifie, protège et profite de contenus que ses propres règles interdisent. Un avis minoritaire rappelle que le problème n'est pas l'absence de fact-checking (dont la suppression est défendue par certains comme un moindre mal pour la liberté d'expression), mais le modèle économique de l'engagement lui-même.
Les retours de terrain abondent : un utilisateur rapporte que son fil alterne chaque jour entre posts pro-républicains et pro-démocrates, illustrant que l'algorithme pousse à la controverse des deux côtés. Un autre affirme qu'Instagram fait remonter les commentaires polémiques en tête de fil par volonté délibérée. Des commentateurs basés en Lituanie et en Roumanie décrivent une dégradation marquée depuis la suppression du fact-checking, avec des effets réels sur la vie politique. Plusieurs anciens utilisateurs expliquent avoir quitté Facebook, même si l'un avoue rester pour Marketplace, avec un profil dédié. Certains notent que ce phénomène n'a rien de nouveau et s'inscrit dans une culture plus large de la provocation (Kanye West, Mr. Beast, etc.), tandis qu'un commentateur juge que les algorithmes ont déjà modifié les comportements au point que le contenu extrême se maintiendrait même sans recommandation.
La discussion apporte plusieurs corrections et nuances. Un commentateur accuse l'ABC d'avoir repris le travail de l'enquêteur indépendant Tom Tanuki sans le créditer, ce qui relativise la nouveauté de l'article. Des désaccords surgissent sur la solution : certains plaident pour la suppression de la publicité ciblée ou une régulation européenne stricte, d'autres jugent toute censure dangereuse pour la démocratie et préfèrent un système type « community notes » de X.
-
LinkedIn CringeBot 3000
Titre seul, sans contenu disponible : « LinkedIn CringeBot 3000 ».
Plusieurs commentateurs ont testé le générateur et le jugent étonnamment efficace, « effrayamment bon », capable de transformer des sujets absurdes en anecdotes de conférence ou en posts « go girl » hilarants. Certains relèvent une reproduction fidèle du style LinkedIn, y compris les phrases courtes et les métaphores alimentaires répétées. L'outil a néanmoins connu des erreurs 500, ce que certains interprètent comme un clin d'œil involontaire à la plateforme qu'il parodie. Un commentateur note que le même prompt avec des styles différents produit des variations superficielles d'un même raisonnement, illustrant la faiblesse conceptuelle cachée derrière une prose cohérente. D'autres rappellent que des outils similaires existent déjà, comme le traducteur de Kagi, et que le succès du site tient surtout à la qualité du modèle sous-jacent.
La discussion élargit le débat à LinkedIn lui-même. Un avis fréquent : le réseau est à 85 % de « PR puffery » et de posts de charlatans, les experts réels y postant rarement. Plusieurs expliquent que les posts « cringe » existaient bien avant l'IA, hérités du marketing direct, et que l'IA ne fait qu'amplifier un phénomène déjà massif. Un commentateur signale le bouton « This looks like AI slop » récemment introduit par LinkedIn, qui a nettement amélioré son fil, même si l'effet reste incertain (individuel ou global). D'autres s'interrogent sur les motivations des auteurs de posts : auto-promotion, recherche de validation, ou revenus indirects.
Certains commentateurs vont plus loin : l'un avoue avoir automatisé ses posts et interactions via un bot, notant que peu de gens lisent vraiment le contenu, un autre déplore que les outils comme celui-ci découragent toute publication humaine. Un débat secondaire oppose ceux qui jugent le style « phrases courtes » comme une dégradation et ceux qui rappellent qu'il vient du marketing direct. L'absence de permaliens pour partager les résultats générés est aussi regrettée, tout comme les limites de coûts des jetons. La discussion n'apporte pas de correction majeure à l'article, mais elle en confirme la pertinence et l'exactitude par des retours d'expérience variés.
-
llama.cpp
llama.cpp permet d'exécuter des modèles d'IA entièrement en local, sans clés API ni télémétrie, sur n'importe quel matériel. Il peut être associé à un agent de codage local via le plugin pi-llama. Le projet met en avant la prise en charge de modèles récents comme Qwen 3.6, Gemma 4 et GPT-OSS, ainsi que l'optimisation pour différents CPUs et GPUs.
Le consensus est très favorable à llama.cpp, décrit comme le « ffmpeg de l'IA » et le vrai moteur derrière des outils comme Ollama et LM Studio. Plusieurs commentateurs soulignent que ces derniers ne sont que des enveloppes, et que llama.cpp mérite la reconnaissance directe. Le nouveau site llama.app est vu comme une tentative légitime du projet de posséder la relation avec l'utilisateur final, mais certains critiquent le manque d'attribution claire sur la page et l'absence de mention d'absence d'affiliation avec Meta, malgré le nom. La discussion confirme que le site est bien référencé depuis le dépôt officiel, ce que l'article ne précisait peut-être pas assez.
Les avis divergent sur l'installation et l'utilisation. La méthode curl|bash divise : certains la jugent acceptable en HTTPS et provenant d'une source fiable, d'autres préfèrent compiler depuis les sources, plus transparent. Le débat sur la facilité d'utilisation oppose ceux qui trouvent les étapes de compilation simples (clone, cmake, build) à ceux qui réclament une expérience plus accessible. Un commentateur remarque que llama.cpp est un serveur, et que des interfaces comme LM Studio remplissent le rôle de GUI. Plusieurs notent que llama-server propose un mode multi-modèles, mais avec des limitations : il faut sélectionner explicitement le modèle dans chaque requête API, ce qui complique l'utilisation avec plusieurs clients. Ces nuances corrigent l'image trop lisse que pourrait donner l'article.
Les retours de terrain sont concrets et parfois critiques. Une régression récente a cassé le support ROCm sur certains GPU AMD intégrés (Framework 13), sans correctif depuis près d'un mois, malgré un contournement via Vulkan. Un utilisateur d'Intel Arc n'a pas réussi à compiler avec OpenVINO après deux jours. Un autre, sur RTX 3070, a trouvé llama.cpp plus simple à installer que vLLM, qui impose une mise à jour des pilotes CUDA. Plusieurs recommandent d'activer l'option spec-default (ngram-mod) pour des gains de performance. Enfin, un commentateur s'interroge sur les performances de llama.cpp face à MLX sur Mac, tandis qu'un autre affirme que llama.cpp est plus rapide qu'Ollama.
-
Grok 4.6 scores 61 on the Artificial Analysis Intelligence Index
Grok 4.6, le modèle de SpaceXAI, obtient un score de 61 à l’Artificial Analysis Intelligence Index, rejoignant la frontière de l’intelligence artificielle, au niveau de GPT-5.6 Sol et derrière Claude Opus 5 (63) et Claude Fable 5 (62). Il gagne 5 points par rapport à Grok 4.5 et 23 par rapport à Grok 4.3. Ses performances sont particulièrement bonnes en agentique, avec un Elo de 1753 sur GDPval-AA v2, derrière Claude Opus 5, et des scores remarquables sur des tâches de service client et de terminal.
Le modèle conserve un prix inchangé de 2 $/6 $ par million de tokens (entrée/sortie), soit 60 % de moins que Claude Opus 5 et GPT-5.6 Sol. Son coût par tâche est de 0,84 $, le plaçant sur la frontière de Pareto du rapport intelligence/coût. Grok 4.6 est également efficace sur les travaux à long horizon : il réalise les tâches en ~53 tours et ~0,5 milliard de tokens en entrée, contre ~103 tours et ~2,0 milliards pour Claude Opus 5. Le contexte est de 500k tokens, et le cache passe à 0,5 $ par million de tokens.
La discussion porte moins sur le score brut de l'article que sur l'usage réel de Grok en programmation. Plusieurs développeurs affirment avoir quitté Claude pour Grok, citant une meilleure communication, une grande rapidité et un meilleur rapport qualité-prix, notamment via Cursor et son abonnement. Un praticien estime que Grok Build est 2 à 5 fois plus rapide que Claude Code, tandis qu'un autre confesse n'avoir jamais rencontré d'utilisateur de Grok pour coder, sauf contraint par son entreprise après des dépassements de budget. À l'inverse, un commentateur ironise sur un retour à l'ère Netscape vs IE, et plusieurs accusent la discussion d'être noyautée par du shilling.
Les aspects économiques et techniques sont débattus. Un commentateur relève que le prix de lecture du cache a presque doublé entre Grok 4.5 et 4.6 (de 0,30 $ à 0,50 $), ce qui pèse lourd dans les sessions de codage intensives. D'autres expliquent la cherté de Grok par la possession des datacenters par Musk, qui n'aurait pas besoin de lever des fonds avant une IPO. Quelques-uns doutent de la capacité de xAI à produire ses propres puces, et un lien est donné vers des inquiétudes sur les turbines à gaz pour l'entraînement. Une speculation récurrente suggère que Grok distillerait les modèles d'Anthropic hébergés dans ses datacenters, mais un avis contraire y voit plutôt la valeur des données de Cursor rachetées 10 milliards de dollars.
Le volet politique divise : certains refusent tout service lié à Musk à cause de son salut controversé et de son attitude, tandis que d'autres jugent cette réaction exagérée. Un commentateur s'interroge sur l'utilité d'un énième modèle fermé face aux alternatives ouvertes, mais reçoit comme réponse que la concurrence bénéficie à tous. Finalement, la discussion nuance l'article en montrant que le benchmark compte moins que l'expérience réelle, les prix, la vitesse et les considérations éthiques ou stratégiques.
-
Why tiny JPEGs look different in Chrome
L'article explique pourquoi de petites images JPEG peuvent être rendues différemment dans Chrome par rapport à Firefox. Chrome utilise une optimisation de décodage partiel (partial IDCT scaling) via libjpeg-turbo et Skia : pour les petites tailles, il ne décode que les basses fréquences des blocs 8×8, ce qui donne un rendu plus lisse ou plus épais. La dégradation vient du mélange de cette optimisation et de l'algorithme de redimensionnement. L'auteur recommande d'utiliser SVG pour les icônes plutôt que JPEG.
Les commentateurs confirment que le problème ne se limite pas aux JPEG : plusieurs relatent des dégradations similaires avec des PNG dans Chrome, au point de devoir différer une mise à jour d'Electron et migrer leurs icônes vers des SVG. Ils s'accordent sur le fond : utiliser un JPEG pour une icône est un mauvais choix, et afficher une image de 2000×2000 dans un espace de 20×20 est un gaspillage. Un avis minoritaire suggère que l'optimisation de Chrome n'est pas qu'une question de mémoire mais surtout de vitesse, le décodage partiel étant bien plus rapide que le décodage complet suivi d'un redimensionnement.
Plusieurs intervenants apportent des précisions techniques qui nuancent ou complètent l'article. L'un explique que Firefox ne décode pas non plus en pleine résolution mais fait un « downscale-during-decode » en streaming, sans décodage partiel des blocs 8×8. D'autres soulignent que les différences d'algorithmes de redimensionnement entre navigateurs (Chrome flou, Firefox plus net avec du ringing) contribuent probablement autant que le décodage partiel. Un praticien signale un effet secondaire concret : certains encodeurs laissent des zéros ou des déchets dans les blocs MCU externes, invisibles en plein décodage mais qui deviennent des artefacts visibles avec le scaling IDCT, avec des références vers des bugs Chromium et libjpeg-turbo.
La discussion corrige aussi une erreur : un commentaire affirme que le PNG est basé sur une palette de couleurs, ce qui est faux — le PNG est lossless et n'utilise pas de palette par défaut. Sur le fond, les avis divergent peu : le consensus est que les navigateurs privilégient la performance au détriment de la qualité, et que si l'on tient à un rendu précis, il faut soit fournir des images à la bonne résolution, soit utiliser SVG, soit passer par un rendu natif ou canvas avec un algorithme comme Lanczos. Quelqu'un mentionne que l'attribut CSS image-rendering peut donner un certain contrôle, mais de manière incohérente selon les navigateurs.
-
Show HN: Woxi - Open-source Mathematica / Wolfram Language reimplementation
Woxi est une réimplémentation open-source de Mathematica / Wolfram Language, présentée sur Hacker News.
La discussion est globalement très positive : plusieurs commentateurs voient en Woxi une alternative open-source bienvenue à Mathematica, notamment pour éviter le coût d'une licence après les études. Un utilisateur compare favorablement Woxi à Sage, qu'il juge être un « patchwork » de systèmes hétérogènes, et préfère payer Wolfram plutôt que subir cette incohérence. Un autre souligne que le projet a beaucoup évolué depuis une précédente soumission sur Hacker News, avec plus de 7 000 commits. L'idée d'un CAS intégré, rapide et écrit en Rust séduit, et plusieurs commentateurs espèrent se passer un jour de la licence propriétaire.
Les retours techniques sont concrets et nuancent l'article. Un utilisateur a testé des visualisations de calcul multivarié et constate qu'elles s'affichent, mais avec d'éventuels bugs. Un autre, qui a comparé plusieurs CAS, rapporte que seuls Sage, Maxima et Woxi ont donné les réponses attendues sur des problèmes d'algèbre. La compatibilité avec wljs a nécessité un script de contournement, et un type de variable version renvoie une chaîne au lieu d'un nombre réel : l'auteur a été invité à corriger cela. Rubi, le paquet d'intégration symbolique, fonctionne « principalement », mais la performance reste un point faible. Les fonctions parallèles ne sont pas encore implémentées, ce que l'auteur promet de prioriser. Enfin, un utilisateur demande une saisie interactive de la notation mathématique (typesetting 2D), mais l'auteur préfère l'ASCII et juge cette fonctionnalité secondaire.
Un débat de fond oppose certains commentateurs : l'un critique la tendance des projets open source à réimplémenter des logiciels propriétaires plutôt qu'à innover, tandis que l'auteur justifie le choix par le fait que le langage Wolfram est « 80-90 % bon » et que la réimplémentation permet de réutiliser le code existant, tout en envisageant à terme une meilleure interface. Un autre met en garde contre les risques juridiques (brevets, droits d'auteur) après l'affaire Oracle, jugeant risqué de réimplémenter un langage non ouvert.
-
Someone is running mass vulnerability scans, spoofing AI bots like ClaudeBot
The Agentic Web Index est un outil qui mesure l'activité des agents IA, crawlers et bots sur plus de 5 000 sites web. Il classe les bots en catégories (fournisseurs de données, assistants IA, agents de codage, recherche IA, agents autonomes) et fournit des métriques sur le respect de robots.txt, l'usurpation d'identité des agents, et les références de trafic depuis les plateformes d'IA comme ChatGPT ou Perplexity. Les statistiques d'usurpation détectent les visites qui prétendent être un agent connu mais échouent à l'authentification. Le texte explique également la méthodologie, les critères de qualification des sites, et précise que les résultats sont des estimations directionnelles, non un recensement précis.
Plusieurs commentateurs relativisent l'ampleur du phénomène : les scans de vulnérabilités sur les ports 80/443 sont monnaie courante depuis des décennies, avec des références historiques comme le ver Code Red en 2001. L'élément nouveau n'est pas l'existence de ces scans, mais leur volume inhabituel et leur technique : usurper les user-agents de bots d'IA comme ClaudeBot ou Googlebot, ce qui brouille les pistes et complique le filtrage. Un commentateur note une recrudescence précise entre le 30 juillet et le 6 août, avec un trafic multiplié par 5, principalement depuis des IP Google Cloud (AS396982), et un signalement à GCP resté sans réponse. D'autres confirment une hausse similaire sur de petits sites, passant de 2 000 à 15 000 requêtes par jour, avec des pics synchronisés venant de milliers d'IP différentes, ce qui suggère un contrôle centralisé. Certains s'interrogent sur la logique de se faire passer pour un bot d'IA, souvent bloqué, et y voient une tentative de nuire à l'image des entreprises d'IA ou un moyen de cibler des outils d'IA exposés.
La discussion apporte des corrections et des conseils pratiques importants. D'abord, il est rappelé que le user-agent n'est pas une identité : il faut vérifier par reverse DNS ou par les plages IP publiées par les fournisseurs légitimes. Plusieurs praticiens recommandent de bloquer les IP des hébergeurs VPS (ou des plages nationales entières pour un usage domestique), ce qui élimine la plupart des bots falsifiés. Un commentateur met en garde contre les outils de blocage automatisés de Cloudflare (Bot Fight Mode), qui ont bloqué par erreur de vrais crawlers de Bing, Google ou OpenAI, nuisant au référencement. D'autres conseillent d'utiliser uniquement la liste officielle des IP de crawlers Google pour distinguer le vrai du faux. Un avis minoritaire souligne que l'attribution géographique des attaques est fragile, car l'IP source peut être falsifiée en amont par des acteurs étatiques.
Certains commentaires s'écartent du sujet pour partager des retours de terrain : un admin OpenWRT décrit les 100 requêtes TCP par minute sur son routeur, et propose des commandes tcpdump pour observer les scans.
-
Tim King, AmigaDOS developer, has died
Tim King, développeur d'AmigaDOS, est décédé.
Les commentateurs rendent hommage à Tim King avec une gratitude teintée de nostalgie : plusieurs racontent comment AmigaDOS a été leur première vraie interface en ligne de commande, les menant plus tard à Unix et à une carrière dans l'administration système ou le développement. Un praticien souligne que c'est grâce à AmigaDOS qu'il a appris le C, d'autres mentionnent avoir configuré des piles TCP/PPP (Miami) pour connecter leur Amiga à Internet avant l'ère des FAI. Un contributeur qui travaillait chez un FAI se souvient avoir écrit des pages d'aide pour Miami. L'accord est général sur l'importance de l'Amiga et le rôle clé de Tim King dans son système d'exploitation.
La discussion apporte des précisions historiques sur l'origine de TripOS, développé à l'université de Cambridge, porté par Tim King sur Motorola 68k, puis intégré à l'AmigaOS. Un commentateur évoque le système Helios de Perihelion, qu'il a utilisé sur Transputers, et le rapproche de Plan9, estimant que ce système mérite plus de crédit. Une réponse à ce fil s'interroge sur l'alternative CAOS et sur ce que l'Amiga serait devenue si cette voie avait été suivie. Quelques intervenants ayant connu Tim King personnellement (via UK Online ou Perihelion) témoignent de sa gentillesse et de son côté aidant.
Aucun commentaire ne contredit l'article, mais plusieurs le complètent : l'un relève un lien vers une interview vidéo d'octobre 2021, un autre vers une archive détaillée sur TripOS, et un troisième signale un fil Reddit dédié. Un avis minoritaire exprime une certaine mélancolie sur l'évolution de l'industrie, comparant l'époque où l'on pouvait pitcher une création comme TripOS à l'ère actuelle où tout semble se résumer à une phrase générée par IA. Dans l'ensemble, la discussion est très unanime : Tim King est remercié pour avoir contribué à une machine qui a marqué des générations de passionnés, et sa disparition est pleurée avec respect.
-
What sort of maths are LLMs good at?
Quelques jours après l'annonce par OpenAI d'avoir résolu dix problèmes majeurs en mathématiques et informatique théorique (dont la construction d'un groupe non-sofic et une preuve sur les nombres de Ramsey multicolores), l'auteur s'interroge sur les capacités réelles des LLM en mathématiques. Il constate que malgré ces succès spectaculaires, les LLM ne surpassent pas encore les humains dans tous les aspects. Il examine l'idée que les LLM seraient particulièrement doués pour trouver des contre-exemples : les problèmes les plus célèbres résolus le sont en effet par des contre-exemples. Mais il montre que la notion de 'contre-exemple' est subtile, à travers l'exemple du théorème de Vinogradov (tout entier assez grand est somme de trois nombres premiers) et de la distance de Banach–Mazur, illustrant la complexité de la quantification logique. L'article explore des hypothèses et appelle à affiner la classification des problèmes où les LLM excellent.
La discussion porte sur les forces et faiblesses des LLM en mathématiques. Plusieurs commentateurs remarquent que les LLM sont surtout utiles pour trouver des exemples et conjecturer, mais pas pour construire des théories. Un point concret évoqué est l'amélioration de la borne sur les zéros de la fonction zêta par Claude, mais un intervenant précise que cela ne résout pas l'hypothèse de Riemann. Les avis divergent sur la capacité des LLM à produire des preuves élégantes, certains doutant de l'objectivité de ces critères. Globalement, les commentaires enrichissent l'article en apportant des exemples précis et des corrections importantes.
-
HTML over WebSockets: real-time SPAs with barely any JavaScript
L'article présente l'architecture HTML over WebSockets, une alternative aux SPA classiques fondées sur un framework JavaScript et une API JSON. Le serveur envoie directement du HTML assemblé via un canal WebSocket bidirectionnel, le client ne faisant que placer le contenu reçu. Cette approche, popularisée par Phoenix LiveView (Chris McCord, ElixirConf 2019), permet de construire des applications temps réel avec très peu de JavaScript et un seul langage côté back-end.
Le fonctionnement repose sur un canal persistant : l'état est conservé côté serveur, qui peut pousser des changements à tout moment (broadcast). Les avantages incluent un seul moteur de rendu, l'absence d'API intermédiaire, une latence réduite, une meilleure résistance aux injections XSS et la possibilité de créer facilement tchat, tableaux de bord ou jeux multijoueurs. En revanche, le serveur doit gérer plus de ressources (mémoire, WebSocket), la latence physique peut dégrader l'impression d'instantanéité, le hors-ligne n'est pas supporté et la courbe d'apprentissage est plus raide.
L'article passe également en revue les implémentations existantes dans différents langages, qui se déclinent selon le transport : HTTP (htmx), SSE (Datastar) ou WebSocket (LiveView, Django LiveView).
La discussion tourne autour du choix entre WebSockets et SSE (Server-Sent Events) plutôt que sur l'article lui-même. Plusieurs commentateurs affirment que SSE et fetch() suffisent pour la plupart des applications, car les navigateurs multiplexent les requêtes HTTP sur une connexion persistante, avec une latence comparable. Un avis minoritaire rétorque que cette latence n'est égale que sur HTTP/2 ou HTTP/3, et que le protocole WebSocket, plus simple, reste plus performant en HTTP/1.1. La discussion contredit aussi l'article sur un point de sécurité : l'affirmation selon laquelle le rendu serveur protège mieux contre le XSS est jugée fausse, car le client reste l'interprète autoritaire du HTML et la sanitisation serveur n'est pas fiable.
Un thème récurrent est le sentiment de déjà-vu : la technique décrite comme innovante par l'article est comparée à DHTML, ASP.NET Ajax, JSF Ajax ou encore WebForms. Un commentateur rappelle que Chris McCord a d'abord expérimenté l'idée dans Rails avant de créer Phoenix LiveView, et un autre affirme avoir fait la même chose chez Booking.com dès 2014-2015. Des bibliothèques actuelles comme htmx, datastar, Livewire ou Symfony Live Components sont citées comme des implémentations plus abouties. Certains critiquent htmx (limité à GET, pas de backoff, extensions nécessaires) et recommandent datastar, tandis que d'autres défendent htmx en expliquant que son usage normal n'exige pas de muter le DOM de façon impérative.
Plusieurs retours de terrain illustrent le compromis : un développeur de Blazor Server apprécie l'approche pour des applications internes à faible audience, car elle évite la conception d'API. Un autre détaille comment datastar avec compression Brotli atteint des ratios de 800:1 à 5000:1 sur les interactions, rendant l'approche plus efficace qu'un SPA React et réduisant la charge serveur. En revanche, des commentateurs soulignent les problèmes concrets de remplacement de fragments HTML : perte de focus, de scroll, d'état de formulaires, ce qui demande du travail supplémentaire.
-
Shade Map
Shade Map est un outil en ligne cartographiant ombres et soleil : calcul de trajectoire solaire, simulation d'ombres en 3D, analyse d'ensoleillement pour photos ou études solaires.
La discussion salue majoritairement l'outil Shade Map pour son interface soignée et ses calculs d'ombre rapides, notamment la simulation de hauteurs de bâtiments ou d'arbres via un outil de dessin de polygones, utilisée pour placer des panneaux solaires, organiser un camping ou choisir un lieu de terrasse. Le créateur participe aux échanges et précise que les données viennent d'OvertureMaps (un sur-ensemble d'OpenStreetMap), mises à jour mensuellement, et que l'outil peut simuler la coupe d'arbres en réglant une hauteur à zéro. Plusieurs commentateurs apprécient la couche « heures de soleil » par jour et la vue globale du terminateur en zoom lointain.
Plusieurs limites et corrections sont apportées. Un commentateur signale un problème d'attribution d'OpenStreetMap caché dans l'interface ; un autre note que les éléments hors du viewport ne projettent pas d'ombre, ce qui fausse les montagnes au lever/coucher. L'exactitude est contestée : un utilisateur voit un écart « facteur 3 » sur la hauteur des bâtiments, possiblement une erreur pieds/mètres, tandis qu'un autre trouve les ombres d'arbres irréalistes car le feuillage est modélisé comme un bloc plein jusqu'au sol (l'auteur répond que les données ne permettent pas de distinguer les essences). Un avis minoritaire mentionne que le site ne fonctionne pas (écran gris), ce qui est expliqué par une géolocalisation en pleine nuit ou sans bâtiments. L'auteur propose de diagnostiquer les erreurs signalées.
La discussion élargit le sujet avec des projets comparables : Streethenge pour les alignements soleil/lune en ville, jveuxdusoleil.fr pour Paris, Sunsit pour Berlin (avec modèle numérique de surface incluant arbres et collines), et ShadowMap qui existe depuis plusieurs années. Un commentateur évoque le cas de Manhattanhenge, et un autre demande si l'outil gère les éclipses — pas spécifiquement, mais il a servi à repérer des lieux visibles lors d'une éclipse. Globalement, les commentaires confirment l'intérêt pratique de l'outil tout en pointant des limitations de données et de précision que l'article initial ne mentionnait pas.