GitHub - tastyeffectco/sandboxes : Environnements de développement auto-hébergés avec URL de prévisualisation. Une commande. Sans Kubernetes, idéal pour les agents de codage et les usines SaaS. Le projet open-source `sandboxed` de tastyeffectco se positionne comme un moteur essentiel pour les constructeurs d'applications basés sur l'IA. Il fournit des environnements de développement cloud isolés, intégrant des agents de codage et des URL de prévisualisation en direct. L'outil est conçu pour être auto-hébergé sur une seule machine, s'activant avec une unique commande, et se distingue par sa capacité à optimiser les ressources en mettant en veille les sandboxes inactifs. Contrairement aux solutions ad hoc basées sur de simples scripts, `sandboxed` révèle toute sa pertinence pour les plateformes gérant de nombreux environnements utilisateur, comme les générateurs d'applications IA ou les plateformes d'agents. Il simplifie drastiquement le déploiement d'infrastructures complexes de prévisualisation et d'isolation multi-tenant. Bien qu'il privilégie une approche "sans Kubernetes" pour la simplicité, sa conception modulaire permet d'envisager une intégration future avec des environnements K8s. Cet outil offre une base solide aux startups cherchant à itérer rapidement avec des agents d'IA, en facilitant le test interactif du code généré. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48388909) - **Article source** : [GitHub - tastyeffectco/sandboxes: Self-hosted dev sandboxes with preview URLs. One command. No Kubernetes, perfect for coding agents and Saas factories · GitHub](https://github.com/tastyeffectco/sandboxes)
Archives
Tag : #reglementation • 60 articles • Page 3 sur 5Le tas Lisp de Lone Le développement de l'interpréteur Lisp `lone`, écrit en C dans un environnement dit "freestanding" — c'est-à-dire sans la bibliothèque standard (`libc`) sur Linux — révèle une évolution ingénieuse de sa gestion mémoire. L'approche initiale reposait sur un allocateur maison simple, basé sur une première allocation rapide avec scission et coalescence de blocs. Bien que fonctionnel pendant trois ans, ce système souffrait de performances médiocres et d'une fragmentation importante, principalement due à des balayages linéaires incessants. L'intégration d'un ramasse-miettes efficace a rapidement exposé les limites de cette gestion. Le défi de la "tyrannie des pointeurs" est devenu manifeste : la réallocation des blocs de mémoire, nécessaire pour optimiser l'espace, rendait tous les pointeurs existants obsolètes. La solution radicale fut de transformer la représentation des valeurs `lone` de pointeurs directs en simples index au sein d'un grand tableau monolithique, le "tas". Cette indépendance de la position a permis une gestion plus flexible, utilisant `mremap` de Linux pour manipuler le tas comme une collection de pages mémoire, sans coûteuses opérations de copie. Les valeurs sont désormais alignées sur des lignes de cache, optimisant l'accès. Le système reste néanmoins confronté au défi de rechercher les valeurs "mortes" via des balayages linéaires pour leur réutilisation. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48313142) - **Article source** : [The lone lisp heap](https://www.matheusmoreira.com/articles/lone-lisp-heap)
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/)
Objectifs de Financement et Trajectoire de Star Citizen Star Citizen se distingue par son modèle de financement participatif unique, où les contributions des joueurs sont directement allouées à son développement ambitieux. Ayant franchi de nombreux paliers financiers au fil des ans, le projet a accumulé des centaines de millions de dollars, dépassant les 750 millions de dollars en 2024, avec des revenus annuels en constante croissance. Cette manne financière permet au studio de poursuivre une vision expansive sans compromis, sans date de sortie ferme, priorisant l'achèvement du jeu selon ses propres standards élevés. Malgré cette accumulation impressionnante de fonds et des progrès tangibles, le jeu demeure en phase alpha, souvent caractérisé par des bugs persistants. Toutefois, une communauté fervente loue une expérience de jeu d'une immersion et d'une échelle sans précédent, saluant la richesse des possibilités offertes et la qualité visuelle. Loin du sensationnalisme, ce parcours reflète une entreprise aux grandes ambitions, soutenue par une base de fans dévouée qui trouve une valeur indéniable dans le voyage de développement lui-même. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48262153) - **Article source** : [Stretch Goals - Roberts Space Industries | Follow the development of Star Citizen and Squadron 42](https://robertsspaceindustries.com/en/funding-goals)
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/)
Des règles d'immigration américaines plus strictes suscitent l'inquiétude mondiale L'article n'a pas pu être chargé. Une nouvelle directive administrative de l'USCIS exigeant que la plupart des demandeurs de carte verte postulent désormais depuis l'extérieur des États-Unis, mettant fin à l'« Adjustment of Status » pour de nombreux cas internes, suscite de vives critiques. Cette mesure est perçue comme un durcissement significatif de la politique migratoire américaine, entraînant des implications majeures. Les observateurs craignent une augmentation substantielle des délais, des coûts et des séparations familiales, affectant particulièrement les conjoints de citoyens américains et les détenteurs de visas de travail. Le départ du pays pour le traitement consulaire peut déclencher des interdictions de réadmission de plusieurs années pour certains, rendant le processus infaisable. Cette politique pourrait également dissuader les talents qualifiés, tels que les médecins et ingénieurs, impactant la compétitivité économique du pays. Beaucoup y voient une intention de réduire l'immigration légale par des moyens administratifs, plutôt qu'une réforme constructive, certains défendant la mesure comme une correction d'un laxisme antérieur. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48241890) - **Article source** : [](https://www.nytimes.com/2026/05/22/us/politics/green-card-changes-trump.html)
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)
DOS Zone | Les jeux DOS dans votre navigateur DOS Zone se présente comme une plateforme en ligne offrant une vaste collection de jeux DOS classiques, incluant des titres russes/CEI et des classiques mondiaux traduits, accessibles via navigateur. Le service promet une expérience gratuite et sans publicité, s'appuyant sur des dons pour sa pérennité. Bien que la plateforme évoque une nostalgie bienvenue, les utilisateurs rencontrent d'importants défis de performance. Des freezes et des plantages récurrents rendent certains jeux de simulation injouables, empêchant la sauvegarde et soulevant des questions sur la capacité de l'infrastructure à gérer la demande, surtout pour des titres plus exigeants comme les FPS. Le projet illustre les complexités de l'émulation web, des contrôles tactiles à l'optimisation des performances. La suppression de titres majeurs, tel que Grand Theft Auto: Vice City, suite à des requêtes DMCA, souligne les tensions entre la préservation du patrimoine ludique et les droits d'auteur. Ce débat s'inscrit dans un engouement croissant pour le rétrogaming et l'émulation avancée, attirant un public toujours plus large. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48215418) - **Article source** : [DOS Zone | DOS games in browser](https://dos.zone/)
OpenBSD 7.9 : Sécurité, Installation et Débats OpenBSD 7.9, nouvelle version axée sur la sécurité, propose des paquets pré-construits et des guides d'installation détaillés pour diverses architectures, ainsi qu'une mise à niveau simplifiée. La sortie s'accompagne d'éléments distinctifs : mascotte Puffy et chanson thématique. Le système se démarque par une approche proactive de la sécurité, intégrant des innovations telles que W^X, ASLR, pledge et unveil pour minimiser la surface d'attaque et isoler les privilèges. Cette rigueur, souvent comparée à Linux, soulève des débats sur l'interprétation des CVEs, compte tenu des contextes variés. Il excelle comme pare-feu, serveur de messagerie ou infrastructure à faible maintenance, grâce à sa cohérence, sa documentation et une philosophie évitant la complexité. Des critiques subsistent : compromis de performances (désactivation de l'Hyperthreading), défis de gestion des partitions, résilience limitée aux coupures de courant (absence de journalisation), et lacunes Wi-Fi (malgré l'expérimentation du Wi-Fi 6). Face à FreeBSD (performance) ou NetBSD (portabilité), OpenBSD privilégie sécurité intrinsèque et simplicité. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48192882) - **Article source** : [OpenBSD 7.9](https://www.openbsd.org/79.html)
Fabricked : Compromettre le calcul confidentiel d'AMD Une nouvelle attaque logicielle, nommée Fabricked, expose une faille critique dans les processeurs AMD EPYC, ciblant la technologie de calcul confidentiel SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging). Cette vulnérabilité permet à un hyperviseur malveillant de contourner les protections matérielles conçues pour isoler les machines virtuelles confidentielles (CVMs) des fournisseurs de cloud. Fabricked manipule le composant Infinity Fabric, responsable du routage mémoire, en altérant la configuration via le firmware UEFI. En interceptant les transactions mémoire critiques du co-processeur sécurisé (PSP) lors de l'initialisation de SEV-SNP, l'attaque empêche la mise en place correcte des règles de contrôle d'accès mémoire (RMP). Il en résulte un RMP corrompu qui permet à l'attaquant d'accéder en lecture et écriture à l'espace mémoire des CVMs. Cette attaque est purement logicielle, déterministe et efficace à 100%, affectant les processeurs AMD Zen 3, Zen 4 et Zen 5. Elle souligne les défis de la sécurité dans les environnements cloud, où la confiance envers le fournisseur est intrinsèquement limitée. Pour les organisations gérant des données sensibles, cela relance le débat sur la supériorité des solutions d'auto-hébergement ou de colocation physique face aux machines virtuelles cloud, souvent perçues comme plus exposées aux vulnérabilités au niveau de l'infrastructure hôte. AMD a reconnu la faille, assignée sous CVE-2025-54510. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48173708) - **Article source** : [Fabricked | XCA](https://xca-attacks.github.io/fabricked/)
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/)