Les pièges des clés primaires UUID dans SQLite L'utilisation de clés primaires UUID aléatoires (UUID4) dans les bases de données dotées d'index clusterisés, comme SQLite, entraîne une dégradation significative des performances d'insertion. Leur nature désordonnée force une re-balance constante de l'arbre B-tree, provoquant un surcoût en pagination, lectures et écritures. Des tests sur SQLite montrent des insertions 10 à 12 fois plus lentes avec UUID4 qu'avec des clés entières. SQLite utilise implicitement un `rowid` entier de 64 bits comme index clusterisé dans les tables standard. Les tables `WITHOUT ROWID` désignent la clé primaire déclarée comme index clusterisé. Pour contourner ce problème, les UUID7, qui sont ordonnés temporellement, réduisent considérablement cet impact. Bien que légèrement moins performants que les entiers (dû à une taille de 16 octets contre 8), ils offrent un compromis viable. Les UUID sont appréciés pour leur opacité comme identifiants publics, évitant des erreurs de jointure silencieuses par aliasing d'entiers. Une stratégie courante consiste à utiliser des entiers en interne pour les performances et des UUID pour les interfaces externes. Attention, JavaScript peut mal interpréter les grands entiers (64 bits) en les arrondissant ; une conversion en chaîne est souvent préférable pour l'échange de données. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48419571) - **Article source** : [The perils of UUID primary keys in SQLite](https://andersmurphy.com/2026/06/05/the-perils-of-uuid-primary-keys-in-sqlite.html)
Archives
Tag : #materiel • 119 articles • Page 1 sur 10Sortie de Pluto 1.0 : Annonces de paquetages pour le langage Julia L'article source n'ayant pas pu être chargé, cette analyse explore l'importance des notebooks interactifs. Ces outils sont jugés vitaux pour les langages de script, suscitant un appel à des plateformes neutres à noyaux enfichables. Jupyter, reconnu pour son efficacité, permet l'intégration de noyaux comme celui de Raku. Avec `Inline::Python` et les modules pip, Raku offre des cas d'usage novateurs, notamment pour les "chatbooks" basés sur les grands modèles de langage (LLM). Le rôle du langage Julia est aussi souligné, notamment via un cours du MIT sur la pensée computationnelle et ses applications, tel que la modélisation de la pandémie de COVID-19. La gestion des calculs présente une distinction clé : contrairement à Excel, où les utilisateurs avancés contrôlent le recalcul, les notebooks comme Pluto s'appuient sur la rapidité et un ordre topologique. Pluto, en particulier, dépend fortement de la vélocité d'exécution pour la cohérence des résultats. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48377496) - **Article source** : [Pluto 1.0 release! - Package Announcements - Julia Programming Language](https://discourse.julialang.org/t/pluto-1-0-release/137296)
Launch HN: Expanse (YC P26) – Libérer la Capacité GPU Gaspiée Les centres de données, en particulier les clusters HPC et GPU, affichent une utilisation effective des ressources très faible, souvent entre 30% et 40%. Ce gaspillage significatif, pouvant atteindre 8,5 millions de dollars par mois pour un seul cluster, résulte de la tendance des utilisateurs à sur-demander des ressources. Cette pratique est une réponse rationnelle au risque asymétrique : une sous-estimation peut entraîner l'échec d'un travail de plusieurs jours, un coût bien plus élevé que le gaspillage diffus de capacité. Expanse propose une solution logicielle pour optimiser cette utilisation. En s'intégrant aux ordonnanceurs (SLURM/K8s) et en collectant la télémétrie matérielle en direct (GPU VRAM, CPU, mémoire, temps d'exécution), le code source et les scripts de soumission, des modèles de deep learning spécifiques aux clusters prédisent avec une grande précision les besoins réels. Le système surpasse les approches traditionnelles et les LLM de pointe par un facteur de 8, car il intègre le contexte matériel et la topologie, là où les LLM manquent de cette compréhension intrinsèque. Expanse offre trois fonctionnalités clés : la prédiction des ressources avec détection de défaillances et suggestions d'optimisation au moment de la soumission, une observabilité en direct des charges de travail, et un diagnostic détaillé des échecs avec des suggestions de correction au niveau du code. Déployée en local et de manière non critique pour le fonctionnement du cluster, cette solution garantit la sécurité des données et vise à réconcilier les objectifs des utilisateurs (rapidité d'exécution) et des administrateurs (efficacité des infrastructures). - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48356312) - **Article source** : [Launch HN: Expanse (YC P26) – Unlock Wasted GPU Capacity](item?id=48356312)
86Box | Blog: 86Box v6.0 La version 6.0 de 86Box marque une avancée significative pour l'émulation de systèmes IBM PC rétro, privilégiant une précision matérière accrue. Cette mise à jour introduit des sons de disques durs configurables et un "switch local" innovant pour interconnecter plusieurs machines 86Box, même entre hôtes et plateformes différentes, facilitant les réseaux multi-machines. Les connectivités série et parallèle sont enrichies, supportant désormais des imprimantes configurables et des liaisons directes via Named Pipe, tandis que l'émulation de lecteurs de bandes SCSI ouvre des perspectives pour les sauvegardes d'époque. L'interface utilisateur est modernisée avec des onglets, une fonction de recherche et de nouveaux boutons pour l'avance rapide et les captures d'écran, améliorant l'ergonomie. Des modifications structurelles incluent la fusion des sélections de cartes vidéo et l'intégration d'un composant externe pour les images MDS v2/MDX, soulevant des questions de licence. Des builds sont disponibles pour Windows ARM, bien que le support de macOS 10.13 soit abandonné. Cette approche d'émulation très détaillée garantit une fidélité essentielle pour les systèmes d'exploitation anciens, souvent incompatibles avec des émulateurs plus génériques qui peinent avec leurs pilotes ou comportements matériels spécifiques. Si cette précision implique une exécution plus lente, la rendant moins propice aux systèmes d'exploitation modernes gourmands en ressources, elle est fondamentale pour une authentique expérience rétro. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48342935) - **Article source** : [86Box | Blog: 86Box v6.0](https://86box.net/2026/05/31/86box-v6-0.html)
Spécification AV2 AV2 est la nouvelle spécification de codec vidéo de l'Alliance for Open Media, conçue pour surpasser AV1 avec une efficacité de compression améliorée de 20 à 30%. Cela permet une diffusion vidéo de haute qualité avec des débits binaires nettement inférieurs. Optimisé pour le streaming, la diffusion et la vidéoconférence en temps réel, AV2 intègre un support renforcé pour les applications de réalité augmentée et virtuelle, la diffusion multi-flux — un atout majeur pour les sports en direct et la VR — ainsi que la gestion des contenus d'écran et la prise en charge de la vidéo transparente via un canal alpha. Bien que ses gains d'efficacité soient substantiels, l'adoption généralisée d'AV2, notamment par les utilisateurs finaux, pourrait être progressive, reflétant les défis rencontrés par AV1. Les encodeurs matériels existants ne sont généralement pas adaptés, nécessitant de nouvelles puces dont l'intégration dans les appareils grand public pourrait prendre du temps. Cependant, AV2 présente des avantages significatifs pour les appareils mobiles grâce à son efficacité énergétique. Le statut « sans redevance » des codecs AOMedia continue de susciter des discussions juridiques. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48340910) - **Article source** : [AV2 Specification](https://av2.aomedia.org)
Politique d'IA de ripgrep : équilibre entre innovation et responsabilité humaine Le projet `ripgrep` a établi une politique d'utilisation de l'IA (LLM) qui autorise son emploi comme outil de codage, tout en maintenant un standard de qualité élevé et la pleine responsabilité des contributeurs et mainteneurs pour le code publié. En revanche, l'IA est strictement interdite pour la rédaction de commentaires aux mainteneurs ou la description de problèmes, ces communications devant rester l'œuvre d'humains pour en garantir l'authenticité et la clarté. La politique exige une présence humaine active tout au long du processus, interdisant formellement les agents autonomes et imposant que les contributeurs comprennent le travail généré par l'IA. Toute utilisation d'IA pour des informations contextuelles doit être citée, divulguée et expliquée par un commentaire humain. Cette ligne directrice reflète une préoccupation croissante pour la diligence humaine et la qualité des contributions dans l'ère de l'IA, tout en soulevant des questions plus larges sur l'évolution des relations entre les projets open source et les entités commerciales, notamment en matière d'acquisitions. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48292718) - **Article source** : [ripgrep/AI_POLICY.md at master · BurntSushi/ripgrep · GitHub](https://github.com/BurntSushi/ripgrep/blob/master/AI_POLICY.md)
De Rust à Ruby : Quand l'IA Réécrit le Code Un développeur a récemment entrepris de convertir une partie significative de son projet Rust (environ 15 000 lignes de code pour une application web) vers Ruby on Rails. Cette initiative est motivée par la verbosité de Rust, ses temps de compilation conséquents et la complexité de ses tests de bout en bout. Après avoir évalué les compromis, notamment à l'aide de grands modèles linguistiques (LLMs), il a utilisé un LLM local pour effectuer la conversion en seulement 30 minutes. Le résultat initial est une réduction spectaculaire de 77 % du nombre de lignes de code. Si l'application n'a pas encore été testée, le développeur anticipe une nette simplification des tests et une gestion allégée des dépendances. Cependant, cette démarche soulève des questions sur la validité des évaluations de l'IA et le statut actuel de Ruby dans l'industrie. La prétendue perte de stabilité sans typage statique en Ruby est contestée par de nombreux experts, qui jugent cette affirmation excessive pour un langage ayant prouvé sa robustesse. Le rôle croissant de l'IA dans les décisions d'architecture et la génération de code, parfois sans expérience directe des langages, est un sujet de débat. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48286561) - **Article source** : [From Rust to Ruby](https://xlii.space/eng/from-rust-to-ruby/)
Microsoft publie en open source le "plus ancien code source de DOS découvert à ce jour" - Ars Technica Microsoft a mis à disposition le code source du 86-DOS 1.00, le prédécesseur direct de MS-DOS, datant d'avant l'acquisition par l'entreprise. Cette initiative révèle les origines de l'un des systèmes d'exploitation les plus influents, incluant le noyau et des utilitaires comme CHKDSK. Le code, créé par Tim Paterson pour Seattle Computer Products, a été racheté et adapté par Microsoft pour l'IBM PC, devenant PC-DOS pour IBM et MS-DOS pour les autres fabricants. La numérisation de ce code s'est avérée un défi majeur, nécessitant une transcription manuelle à partir d'imprimés papier originaux, les technologies OCR modernes peinant avec la qualité des documents anciens. Cette récupération souligne l'importance de la préservation numérique. Cet événement met en lumière une distinction cruciale dans l'histoire de Microsoft : l'acquisition de DOS fut un coup de maître commercial, né en partie des négociations manquées d'IBM avec d'autres acteurs. La véritable prouesse technique initiale de Microsoft réside davantage dans le développement de l'interprète Altair BASIC par Bill Gates et Paul Allen, conçu sans accès direct à l'ordinateur cible, démontrant une ingéniosité remarquable. La publication de ce code ancien enrichit la compréhension des fondations de l'informatique personnelle. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48253386) - **Article source** : [Microsoft open-sources "the earliest DOS source code discovered to date" - Ars Technica](https://arstechnica.com/gadgets/2026/04/microsoft-open-sources-the-earliest-dos-source-code-discovered-to-date/)
Google's Antigravity : Une mise à jour qui déstabilise les développeurs Google a récemment mis à jour de force son environnement de développement "Antigravity", remplaçant l'IDE existant par une nouvelle interface conversationnelle de type chatbot. Cette transition, effectuée sans avertissement clair, a gravement perturbé les flux de travail des développeurs, effaçant l'historique des conversations et les paramètres. De plus, elle a rendu impossible l'exécution simultanée des deux versions sans une réinstallation complète, perçue comme un "bait and switch". Cette manœuvre soulève des interrogations sur la stratégie produit de Google, souvent critiquée pour son manque de cohérence et sa propension à lancer et abandonner des outils, au détriment de la stabilité et de la confiance des utilisateurs. Des changements concomitants aux limites d'utilisation et aux crédits d'IA pour les abonnés payants sont également considérés comme une dégradation de service. Ces pratiques poussent les développeurs à rechercher des solutions plus fiables et agnostiques aux fournisseurs pour leurs besoins de production. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48222529) - **Article source** : [Google's Antigravity Bait and Switch | Sid's Blog](https://www.0xsid.com/blog/antigravity-bait-n-switch)
wake up! 16b : Une prouesse de densité algorithmique Le programme "wake up! 16b", une démo de 16 octets en assembleur x86, repousse les limites de la densité algorithmique en générant simultanément un fractal de Sierpinski visuel et sonore. Créé pour la demoscene, il exploite la mémoire vidéo du mode texte DOS comme espace de calcul. L'algorithme utilise l'opération XOR sur les données de la mémoire, qui, bien que "pré-remplie" par le BIOS, permet de dégager le motif mathématique de la Règle 60 de Wolfram. L'astuce réside dans l'utilisation du Bit 1 de chaque octet : il est directement envoyé au haut-parleur PC via le port 61h, transformant la géométrie du fractal en ondes sonores distinctes. Le déplacement de -56 octets par itération module l'expérience, étirant le fractal en dix colonnes diagonales à l'écran et abaissant la fréquence audio d'une octave. La sortie visuelle et sonore est étonnamment sensible aux états initiaux de la RAM, rendant chaque exécution unique et soulignant la beauté imprévisible des contraintes extrêmes. Cette œuvre est saluée pour son ingéniosité technique et sa beauté troublante. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48173962) - **Article source** : [wake up! 16b](https://hellmood.111mb.de//wake_up_16b_writeup.html)
‘No Way To Prevent This,’ Says Only Package Manager Where This Regularly Happens | Kevin Patel Les attaques sur la chaîne d'approvisionnement logicielle posent une menace persistante et dévastatrice pour l'écosystème JavaScript, entraînant la compromission de millions d'applications via le registre npm. Tandis que cette situation est souvent perçue comme inévitable par certains, d'autres écosystèmes comme Go ou Rust, dotés de bibliothèques standard robustes et de vérifications cryptographiques intégrées, affichent une bien meilleure résilience. La problématique est exacerbée par la dépendance de l'écosystème JavaScript à des arbres de dépendances excessivement profonds, à des packages non vérifiés et à l'exécution arbitraire de scripts d'installation par défaut. Pour contrer ces vulnérabilités, des mesures concrètes sont proposées. Parmi elles, l'instauration de "délais de grâce" (cooldowns) de quelques jours pour les nouvelles versions de packages est jugée essentielle, offrant aux outils de sécurité et aux mainteneurs le temps nécessaire pour détecter et retirer le code malveillant. Des réformes plus larges incluent l'application de vérifications d'identité pour les éditeurs, la restriction des plages de versions dynamiques et la réévaluation fondamentale des scripts d'installation. La sous-capitalisation des projets open-source critiques est souvent identifiée comme une cause profonde, contrastant avec des systèmes plus matures comme Maven Central qui appliquent des garde-fous et des politiques d'immutabilité plus stricts. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48155690) - **Article source** : [‘No Way To Prevent This,’ Says Only Package Manager Where This Regularly Happens | Kevin Patel](https://kevinpatel.xyz/posts/no-way-to-prevent-this/)
Les Néandertaliens perçaient des caries pour soigner les maux de dents il y a 59 000 ans - Ars Technica Une découverte archéologique majeure révèle que les Néandertaliens pratiquaient la dentisterie il y a 59 000 ans. Un molaire supérieur découvert dans la grotte de Chagyrskaya en Sibérie présente un trou inhabituellement grand et des marques de forage, indiquant une intervention intentionnelle pour traiter une carie sévère. Des paléoanthropologues, dont Alisa Zubova, ont utilisé des microscopes électroniques et la spectroscopie Raman, puis reproduit l'intervention avec des outils en pierre sur des dents modernes, confirmant l'authenticité de cette procédure paléolithique. Cette "micro-chirurgie" consistait à percer la dent pour atteindre la chambre pulpaire infectée, soulageant ainsi la douleur. Le patient a survécu et utilisé la dent pendant des années, témoignant du succès de l'opération. Cette pratique dénote une capacité de résolution de problèmes et une connaissance médicale avancée, défiant l'idée que Homo Sapiens était intrinsèquement plus intelligent. Alors que des soins de base étaient connus, cette intervention représente un traitement médical actif et ciblé, bien plus sophistiqué que l'extraction ou le simple brossage. Cette découverte nous force à réévaluer la complexité des sociétés néandertaliennes. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48125623) - **Article source** : [Neanderthals drilled cavities to treat a toothache 59,000 years ago - Ars Technica](https://arstechnica.com/science/2026/05/neanderthals-drilled-cavities-to-treat-a-toothache-59000-years-ago/)