GitHub - coder/boo: Un multiplexeur de terminal façon GNU screen basé sur libghostty. `coder/boo` est un multiplexeur de terminal moderne, conçu sur le modèle de GNU screen, mais construit avec le cœur d'émulation `libghostty-vt` et écrit en Zig. Sa principale innovation réside dans sa capacité à maintenir une connaissance exacte de l'état de chaque session, incluant le contenu, les styles, le curseur et l'historique de défilement. Cette approche garantit une restitution fidèle de l'affichage du terminal lors de la reconnexion et permet aux applications interactives (TUI) de fonctionner sans accroc même lorsque les sessions sont détachées. Contrairement à l'émulateur vieillissant de GNU screen, `boo` assure une représentation visuelle fidèle, essentielle pour l'utilisateur et cruciale pour l'automatisation. Il facilite l'intégration de scripts et d'agents d'IA pour interagir avec des programmes complexes, offrant des fonctionnalités améliorées pour l'envoi de commandes et la lecture d'écran. Bien qu'il adhère à la simplicité de screen, il se différencie de tmux par sa philosophie de conception. Le projet est encore jeune et se positionne comme une alternative prometteuse plutôt qu'un remplacement direct de GNU screen. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48496250) - **Article source** : [GitHub - coder/boo: A GNU screen style terminal multiplexer built on libghostty.](https://github.com/coder/boo)
Archives
Tag : #opensource • 72 articles • Page 3 sur 6L'histoire derrière les enseignes qui illuminent notre quotidien : Signalisation thermoformée et connexion humaine Les enseignes en plastique lumineuses, souvent tridimensionnelles et gaufrées, sont omniprésentes sur les Main Street américaines, guidant discrètement vers les commerces locaux depuis des décennies. Nées dans les années 1950, suite aux avancées des plastiques durant la Seconde Guerre mondiale et l'invention du thermoformage sous vide, elles ont révolutionné l'affichage électrique dominé auparavant par le néon. Cette technologie a permis de fabriquer des signes plus durables, personnalisables et produits en série, comme l'explique un ancien fabricant décrivant le processus manuel et précis de création des moules et de formage des feuilles de plastique chauffées sous vide. Des entrepreneurs comme Conrad Escalante et Kozy Boren ont été pionniers, inventant dès 1958 des solutions innovantes telles que la "flèche Superior" pour les petites entreprises. Par la suite, la société Signtronix (successeur de Gulf Development) a démocratisé ces enseignes abordables pour les commerces indépendants ("Mom & Pop"), en développant des formats iconiques comme le "Dynalite" et le "Big Sig", souvent conçus avec des designs génériques pour faciliter leur réemploi. Loin des approches plus standardisées observées ailleurs, ce style de signalisation est devenu un élément distinctif du paysage urbain américain, contribuant à l'identité culturelle locale et favorisant des micro-interactions humaines, bien au-delà de leur simple fonction commerciale. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48470748) - **Article source** : [The History Behind the Signs Lighting Up Our Daily Lives: Vacuum-Form Signage and Human Connection](https://bethmathews.substack.com/p/the-history-behind-the-signs-lighting)
Historique des versions d'Elfeed sur GitHub Le journal des modifications d'Elfeed, un agrégateur de flux RSS intégré à Emacs, révèle une évolution technique marquée, depuis sa première version en 2013 jusqu'à une future mise à jour majeure prévue pour 2026. Un défi technique central a été la gestion des incompatibilités avec les versions successives d'Emacs. Un tournant majeur est survenu avec l'introduction d'Emacs 26, qui a modifié son type de "record", rendant obsolète le format de base de données d'Elfeed basé sur `cl-defstruct`. Cette rupture a nécessité une intervention délicate. Dès la version 2.4.0 d'Elfeed, un mécanisme de migration automatique et irréversible a été mis en place. Lors de l'exécution sous Emacs 26, les bases de données d'Emacs 25 étaient silencieusement converties, avec une sauvegarde `index.backup` créée au préalable. La conséquence directe pour les utilisateurs était qu'une base de données ainsi mise à jour devenait inaccessible pour Emacs 25, apparaissant comme vide. Cette approche soulignait la nécessité d'adapter les applications aux évolutions de leur environnement hôte, tout en gérant les risques de rétrocompatibilité pour les utilisateurs. Les mises à jour continuent, la version 3.4.2 étant documentée en juillet 2024. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48428652) - **Article source** : [elfeed/NEWS.org at main · emacs-elfeed/elfeed · GitHub](https://github.com/emacs-elfeed/elfeed/blob/main/NEWS.org)
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)
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)
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/)
Runtime - La plateforme d'exécution pour les agents de votre équipe Runtime s'impose comme une solution d'infrastructure essentielle pour déployer et gérer les agents de codage IA à l'échelle de l'entreprise. La plateforme répond aux défis majeurs rencontrés lors de l'intégration de ces agents, tels que les déploiements risqués, les configurations incohérentes, la difficulté à maintenir le contexte ou la gestion des secrets, qui freinent l'adoption généralisée au-delà des équipes techniques. L'outil fournit des environnements bac-à-sable pré-configurés, sécurisés et dotés d'outils, de garde-fous et d'une gestion des secrets via un proxy. Il orchestre la mise en place d'environnements complets, y compris les services et bases de données, garantissant un démarrage rapide des sessions collaboratives et une compatibilité avec les agents et modèles d'IA existants. Runtime s'intègre aux outils de travail courants comme Slack ou GitHub, permettant à diverses équipes – de l'ingénierie aux finances – de travailler avec des agents en toute sécurité. Des tableaux de bord de visibilité, de suivi des coûts et de gouvernance sont intégrés, tandis que son cœur open-source et ses options d'auto-hébergement soulignent une volonté de flexibilité et de contrôle pour les entreprises. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48225040) - **Article source** : [Runtime - The runtime for all your team's agents](https://www.runtm.com/)
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)
‘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/)
Pourquoi les développeurs seniors peinent à communiquer leur expertise Le problème central réside dans un décalage entre les priorités : les entreprises visent la **réduction rapide de l'incertitude** pour explorer le marché, tandis que les développeurs seniors se concentrent sur la **gestion de la complexité** pour garantir la stabilité et la maintenabilité des systèmes. Cette divergence crée des échecs de communication. Les seniors, voyant l'IA comme un facteur de déstabilisation augmentant la complexité, ont du mal à exprimer les risques à long terme dans des termes compréhensibles pour l'entreprise. Leur expertise consiste à identifier les développements superflus et à concevoir des solutions stables et efficaces. Une approche suggérée est de dédoubler le développement en une version "vitesse" (pour l'expérimentation rapide, potentiellement pilotée par l'IA) et une version "stabilité" (pour des systèmes robustes, gérés par les seniors agissant comme des "éditeurs"). Cela permet à l'entreprise d'innover rapidement pendant que les seniors assurent une croissance stable et responsable. L'expertise profonde, un "modèle du monde" interconnecté acquis par l'expérience, ne se transmet cependant pas simplement. Les développeurs seniors doivent traduire leur compréhension de l'intégrité des systèmes en solutions qui ciblent explicitement la réduction de l'incertitude, par exemple en proposant "Pouvons-nous essayer quelque chose de plus rapide ?". Cette stratégie équilibre l'innovation avec une stabilité essentielle et une responsabilité critique, en utilisant l'IA comme un outil guidé par l'expertise humaine. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48109460) - **Article source** : [Why senior developers fail to communicate their expertise | nair.sh](https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise)
Valve met à disposition les fichiers CAO du Steam Controller sous licence Creative Commons | Digital Foundry Valve a récemment publié les fichiers de conception assistée par ordinateur (CAO) de son nouveau Steam Controller et de son Puck, les mettant à disposition sous une licence Creative Commons (CC BY-NC-SA 4.0). Cette initiative vise à encourager la communauté des "moddeurs" à créer une gamme étendue d'accessoires personnalisés, tels que des coques, des supports de charge ou des fixations pour smartphones. La publication de ces fichiers s'inscrit dans la continuité de la politique d'ouverture de Valve, déjà appliquée pour le Steam Deck et le Valve Index, et est perçue comme un geste favorable aux consommateurs. Elle permet une personnalisation profonde du matériel, offrant des solutions innovantes, notamment pour les aménagements destinés aux personnes à mobilité réduite. Bien que la licence restreigne l'usage commercial direct, elle prévoit un contact avec Valve pour les entités intéressées par la production d'accessoires. Toutefois, des analyses révèlent que la pleine fonctionnalité du contrôleur, particulièrement sous Windows, peut rester liée au logiciel Steam, soulevant des questions sur l'équilibre entre l'ouverture matérielle et la dépendance à l'écosystème logiciel de la plateforme. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=48037555) - **Article source** : [Valve releases Steam Controller CAD files under Creative Commons license | Digital Foundry](https://www.digitalfoundry.net/news/2026/05/valve-releases-steam-controller-cad-files-under-creative-commons-license)
DeepSeek V4 : Un pas vers la frontière technologique, à une fraction du prix Les modèles DeepSeek-V4-Pro et DeepSeek-V4-Flash ont été lancés, marquant une avancée significative pour l'IA open-weights. Le modèle Pro, avec 1,6 trillion de paramètres au total, est le plus grand modèle à poids ouverts à ce jour. Leur atout majeur réside dans un coût d'utilisation extrêmement bas : le V4-Flash est le plus économique des petits modèles, et le V4-Pro des grands modèles frontières, offrant des économies substantielles. Des tests de codage complexes ont coûté moins de 0,10 $ avec le V4-Pro, comparé à une dizaine de dollars pour des alternatives propriétaires. Cette performance tarifaire est rendue possible par une efficacité accrue en contexte long, grâce à des innovations comme HCA et mCH, réduisant considérablement les FLOPs et la taille du cache KV par rapport aux versions précédentes. Bien que DeepSeek-V4-Pro soit légèrement en deçà des modèles d'IA de pointe absolus (estimé à 3-6 mois de décalage), il se montre très compétitif, notamment dans le raisonnement spatial pour le codage. Des déploiements locaux sont déjà possibles, permettant de traiter un million de jetons avec une meilleure performance et en utilisant moins de ressources GPU que la version précédente, renforçant la vision d'une IA accessible et moins centralisée. - **Discussion HN** : [Lire la discussion](https://news.ycombinator.com/item?id=47977026) - **Article source** : [DeepSeek V4—almost on the frontier, a fraction of the price](https://simonwillison.net/2026/Apr/24/deepseek-v4/)