Une Atari Jaguar, la console de 1993 qu'Atari vendait comme la première machine 64 bits et que le marché a snobée, vient de booter sous Linux pour la première fois ! Derrière ce hack, un développeur connu sous le pseudo de Cakehonolulu , qui a collé un vrai noyau sur le Motorola 68000 de la bécane.

Le 68000 n'a pas de MMU , ce circuit qui gère la mémoire virtuelle et dont dépend le Linux que vous faites tourner sur votre PC. Sauf que le noyau embarque depuis toujours une branche pour les puces qui en sont privées, l'antique μClinux , et c'est elle qui fait tout le taf ici.

La Jaguar offre seulement 2 Mo de RAM et jusqu'à 6 Mo de ROM sur la cartouche, du coup Cakehonolulu a coupé le noyau en deux : le code qui ne bouge pas, le .text et le .rodata, reste dans la ROM et s'exécute directement depuis là en XIP, pendant que les données qui changent atterrissent dans les 2 Mo de RAM. Bref, chaque octet compte.

Après, ce n'était pas simple non plus parce que le 68000 ne sait pas lire une donnée qui serait mal alignée en mémoire. Alors que les processeurs modernes savent le faire sans broncher. Et comme le cross-compilateur d'Ubuntu générait quand même ce type de données mal alignées, alors qu'on lui précise bien que la cible c'était un 68000, ça faisait des plantages en cascade.

L'astuce a donc été de recompiler tout le toolchain à la main, puis de bâtir un user space minimal avec BusyBox et uClibc, tout ça en binaire FLAT au lieu du classique format ELF.

Et voilà, la Jaguar affiche maintenant fièrement ses 1,04 BogoMIPS. Soit une puissance de feu qui ferait chialer une calculatrice. Mais bon, elle boote et c'est le principal. Si vous avez encore une Jaguar dans un placard, vous pouvez parfaitement installer ça dessus, puisque le code est disponible sur GitHub .

Voilà, c'est assez génial parce qu'en fait, ça montre bien que Linux est vachement résilient. On est en 2026 et pourtant, le support des 68000 est encore présent dans le noyau, et bien vivant même !

Voilà, tant que ce bon vieux noyau gardera tous ses vieux pilotes, eh bien n'importe quelle console oubliée pourra toujours renaître avec un petit terminal dessus. Et ça, je trouve que ça clôt tous les débats sur la conservation et le poids du code legacy dans le kernel.

Source

Une Megadrive qui fait tourner du bon gros Linux qui tâche, vous en avez rêvé ? Hé bien Daniel Palmer l'a fait !!

Le souci, c'est que le processeur 68000 de la console n'a pas de MMU, ce petit composant que Linux réclame normalement pour gérer la mémoire. Du coup Daniel a compilé le kernel dans un mode spécial qui s'en passe, ce qui est déjà un joli exploit.

Autre problème, une Megadrive toute seule n'a pas assez de mémoire pour un kernel. L'astuce, c'est donc de passer par une cartouche. Un Mega EverDrive de chez Krikzz vient glisser 4 Mo de RAM dans la console, et hop, comme ça elle se transforme en mini-ordinateur le temps d'un boot. Welcome LinuxMD !!

Le menu de la cartouche Mega EverDrive, par lequel on lance le démarrage.

Vous branchez ensuite la cartouche à votre PC en USB, et là, le kernel se met à cracher du log sur votre terminal, comme une vraie machine !

Et il y a même un mode qui affiche le shell directement sur la télé, avec un petit carré vert qui clignote pour dire que le kernel tourne, et un rouge pour l'activité du disque. Plutôt classe !

Le shell Linux affiché sur la télé via la puce graphique de la Megadrive. Le carré vert qui clignote = le kernel tourne.

Après c'est lent. Daniel le dit lui-même, y'a de quoi vous faire un café entre deux commandes. Et si vous n'avez pas de Megadrive sous la main parce que les brocantes de geeks c'est pas votre truc, c'est pas grave, il a prévu un émulateur pour jouer avec sans avoir le matos.

Bref, c'est pas très praticable, vous ne pourrez pas vous en servir comme d'un PC au quotidien mais c'est beau quand même !

Source : Hackaday

L' ordonnanceur du noyau Linux vient de recevoir une proposition de mise à jour qui fait grimper les perfs de façon assez spectaculaire sur certaines charges. Hygon, le fondeur chinois qui fabrique des x86 sous licence de l'architecture Zen d'AMD, a envoyé une série de patches pour étendre le cache-aware scheduling, et les chiffres annoncés montent jusqu'à 360% de mieux en termes de transactions par seconde sur MySQL.

Pour comprendre le délire, faut revenir au cache-aware scheduling de base, le fameux CAS, conçu par les ingénieurs d'Intel (Tim Chen, Chen Yu et Peter Zijlstra) et tout juste mergé dans Linux 7.2. Sur un CPU moderne avec plusieurs caches de dernier niveau, le fameux LLC, l'ordonnanceur essaie de regrouper sur le même domaine de cache les tâches qui partagent des données. Du coup, moins de ratés de cache, moins de données qui font des allers-retours entre les caches, et donc de la perf en plus sans toucher au matos mais juste en plaçant mieux les tâches.

Le hic, c'est que ce CAS de base raisonne au niveau d'un seul LLC. Tant que votre charge tient dans un domaine de cache, nickel. Mais dès que la charge dépasse ce que peut contenir un seul cache partagé, l'ordonnanceur ne sait pas regrouper les tâches au niveau du dessus : elles se dispersent sur des cœurs qui ne partagent plus le même cache, et toute la localité s'évapore. Et ça tombe mal pour Hygon, dont les puces récentes ne sont pas un bloc unique mais un assemblage de chiplets (le C86-7490 en réunit quatre), avec plusieurs caches partagés éparpillés sur la galette.

D'où l'idée de développer ces patches, qui permettent un regroupement hiérarchique et offrent la possibilité de s'étendre ou de se contracter dynamiquement selon la taille de la charge et la topologie de la machine.

Hygon annonce donc jusqu'à +49% sur Hackbench , +20% sur Schbench (non, pas le rappeur), et ce fameux +360% sur MySQL !! C'est le feu !

Maintenant, avant de revendre votre PC pour en prendre un sous Hygon, attention ! Ces chiffres, ce sont des "jusqu'à", mesurés sur des topologies multi-domaines, donc typiquement de gros serveurs à plusieurs chiplets. Sur votre laptop avec un seul LLC, vous ne verrez donc sans doute rien passer.... Ouais, je sais, sniiiif. Le 360% n'est pas un gain universel, mais plutôt le pic sur la config qui souffrait le plus du problème.

Un fondeur chinois qui, parti d'une licence Zen d'AMD, en vient à pousser du code dans Linux pour faire tourner tout le monde plus vite, Intel et AMD compris, c'est chouette quand même. Si ça vous intéresse, les patches viennent d'être postés sur la mailing list du kernel , donc rien n'est encore intégré mais si ça passe la revue, c'est de la perf gratuite pour les machines qui en bavent le plus.

Source

Admettons que vous ayez besoin de transmettre des fichiers d'une machine A à une machine B, le plus vite possible et sans vous prendre la tête ?

Et bien j'ai ce qu'il vous faut et ça s'appelle USB4STREAM, qui vient d'être fraîchement mergé dans Linux 7.2. C'est Intel qui a pondu ce protocole "super simple" (c'est leur expression) pour balancer des paquets bruts d'une machine à une autre, directement par le câble USB4 ou Thunderbolt sans serveur intermédiaire... Juste deux bécanes et un fil.

Et effectivement, comme ils le disent, c'est super simple ! Une fois le module chargé et le stream configuré (un petit tour par ConfigFS pour faire apparaître le device), votre noyau expose des périphériques /dev/tbstreamX, et n'importe quelle application qui sait faire un read/write peut alors taper dedans.

Vous branchez le câble, et il vous suffit ensuite d'écrire dans le device qui doit expédier les données d'un côté, puis de les recevoir sur l'autre machine. C'est tout... Du Unix pur jus, où tout est un fichier.

Et les usages sont beaucoup plus larges qu'on ne croit... Y'a donc du transfert de fichiers d'un ordinateur à un autre, évidemment (un peu comme Croc , mais sans passer par le réseau du tout) mais aussi, pourquoi pas, du partage de webcam entre deux systèmes, ou permettre un accès à n'importe quel flux de données brutes en basse latence. Ainsi, plus besoin de passer par des serveurs tiers dans le cloud, ou d'installer un outil de transfert en réseau local .

Ça me rappelle quand je jouais avec les copains à des jeux vidéos en utilisant un port série sur le PC... À l'ancienne comme on aime, sauf qu'on est en 2026 et qu'on a maintenant 40 Gb/s dans le tuyau !

Puis contrairement à Thunderbolt qui nous promettait la vitesse de l'éclair il y a plus de dix ans (ouais, je vous sors les archives là...lol), là c'est natif Linux, et dispo pour tout le monde via un simple device !

Le choix raffiné : le câble, pas le cloud

Le patch d'Intel est d'ailleurs passé tranquillou puisqu'ils l'ont glissé dans le pull USB/Thunderbolt de la merge window, et c'est Linus Torvalds lui-même qui l'a mergé sur master sans la moindre objection. Et quand Linus laisse passer sans râler, c'est plutôt bon signe.

Le reste du lot vaut le coup d'œil aussi puisque cette même pull améliore l'allocation des tunnels DisplayPort en multi-écran sur Thunderbolt, et ajoute un pilote de température pour le contrôleur xHCI du chipset AMD Promontory 21. Notez que ce dernier a été écrit en partie par Codex, l'agent de codage d'OpenAI... Mais balek tant que c'est propre et que ça fonctionne.

Bref, si vous avez deux machines en USB4 sous la main, gardez un œil sur le noyau Linux 7.2...

Source

Une faille planquée pendant 9 ans dans le noyau Linux, voilà ce que les chercheurs de Qualys viennent de déterrer. Son petit nom, c'est ssh-keysign-pwn ou DirtyDecrypt (CVE-2026-46333 pour les intimes), et elle permet à n'importe quel utilisateur local sans privilèges de passer root, de lire votre /etc/shadow et de piquer les clés SSH privées de votre serveur.

Et ce bug dormait là depuis novembre 2016, c'est-à-dire depuis la version 4.10 du kernel. Personne ne l'avait jamais vu et autant vous dire que 9 ans, en cybersécu, c'est une éternité !!

Le truc se cache dans une fonction au nom barbare, __ptrace_may_access(). En gros, quand un processus privilégié abandonne ses droits, y'a une micro-fenêtre, le temps d'un battement de cils, où il reste "accrochable" via ptrace. Vous combinez ça avec l'appel système pidfd_getfd() et hop, vous récupérez les fichiers ouverts d'un process root.

Et l'exploit disponible vise des binaires SUID que tout le monde a sur sa machine, genre ssh-keysign, chage, pkexec ou accounts-daemon.

Du coup, première chose à faire : vous mettez à jour, genre rapidos ! Linus Torvalds a poussé le correctif et si vous ne pouvez pas patcher tout de suite, faut taper la commande sysctl -w kernel.yama.ptrace_scope=2 qui a pour effet de refermer la porte en attendant.

Niveau distros, ça touche à peu près tout le monde, d'Ubuntu 14.04 jusqu'à la 26.04, en passant par Debian, Fedora et toute la famille Red Hat.

Et le plus gênant, c'est que ssh-keysign-pwn, c'est la 4e faille kernel en moins de trois semaines. On a eu CopyFail , Dirty Frag début mai, puis Fragnesia juste après, et maintenant celle-ci. Aïe aïe aïe ! Je commence à me lasser, sérieux ^^.

Le noyau Linux prend cher en ce moment et comme les exploits fonctionnels sont déjà publics, le compte à rebours est lancé pour tous ceux qui traînent !

Alors après tout le monde va vous parler des cybercriminels et des serveurs compromis, et c'est vrai, faut patcher. Mais pour moi, ce genre de faille, c'est aussi une clé qui sert aux bidouilleurs pour reprendre la main sur leur propre matériel. Votre routeur verrouillé, votre objet connecté que le fabricant a laissé tomber depuis quelques années, ce bon vieux NAS dont plus personne ne livre de firmware... une faille comme ça, c'est parfois le seul moyen de le faire revivre !

Bref, faites vos mises à jour. Et gardez en tête que ces mêmes failles qui font flipper les sysadmins, ce sont aussi celles qui redonnent vie au matos verrouillé qui n'avait pas d'autre avenir que de finir à la déchetterie.

Source

Vous ne le savez peut-être pas mais votre serveur Linux embarque plusieurs milliers de modules kernel et pourtant, il n'en utilise que quelques centaines à peine. Tout le reste ça prend la poussière et ça peut vous exposer à des problèmes de sécurité. Hé bien c'est exactement à ces modules inutiles que Jasper Nuyens, le fondateur de Linux Belgium, vient s'attaquer avec son outil ModuleJail .

Ce script lit /proc/modules pour savoir ce qui tourne vraiment sur votre machine, et considère ensuite cet ensemble comme étant intouchable. Par contre, pour tout le reste il ajoute une ligne install <module> /bin/true dans /etc/modprobe.d/modulejail-blacklist.conf.

Comme ça si un jour quelque chose essaie de charger un de ces modules endormis, c'est modprobe qui exécutera /bin/true à la place... et il ne se passe rien !!

C'est malin, hein ? Vous pouvez installer ModuleJail via le script dispo sur la page Github ou grâce aux paquets .deb et .rpm si vous préférez. Et ensuite, pour vérifier que c'est bien en place, un petit modprobe -n -v module_banni devrait vous répondre install /bin/true.

En tout cas, je trouve que ModuleJail tombe très bien parce que la chasse aux failles kernel est clairement en train de changer d'échelle. Je pense notamment à tous ces outils de scan assistés par IA qui débusquent à la chaine des bugs d'élévation de privilèges planqués dans le code depuis des années.

Le script propose 3 profils via le flag -p, minimal pour le strict nécessaire, conservative par défaut (serveur classique plus drivers VM courants) et desktop qui garde WiFi, Bluetooth, audio et vidéo. Vous pouvez aussi ajouter votre propre whitelist.

Et la règle d'or non négociable, c'est de le lancer quand la machine est dans un état stable, avec tous les services démarrés, et tous les disques montés. Car oui, ModuleJail ne devine rien, mais se contente de photographier ce qui tourne à l'instant T. Donc sur un système à moitié démarré, ce serait un peu couillon qu'il bannisse un module dont vous aurez besoin plus tard.

Après pour tout ce qui est compilé en dur dans le kernel (le fameux =y de la config) ça reste là, donc une faille dans le cœur du noyau façon Dirty Cow , ça n'y changera rien du tout. Et si vous branchez une webcam six mois après, son module sera déjà banni donc faudra pas oublier de retirer sa ligne du fichier ou relancer le script avec une whitelist, car un simple modprobe ne suffira pas !

Donc c'est pas forcement le pied pour un Linux Desktop mais pour un parc de serveurs en prod qui ne bougent pas, c'est une petite couche de sécurité en plus.

Source

Linus Torvalds vient de donner son avis sur l’IA et le vibe coding et ça ne va pas plaire à tout le monde, ahahaha.

Hé oui car pendant que le monde tech se déchire entre les évangélistes de l’IA qui veulent tout automatiser et les énervés qui refusent l’IA par principe idéologique, Linus débarque dans le game avec un avis… de complet normie.

Lors de l’Open Source Summit à Séoul qui vient d’avoir lieu, Linus a partagé sa vision sur l’IA générative et le fameux “vibe coding”. Et son avis, c’est que l’IA c’est juste un outil de plus !

Ah putain, ça fait plaisir de lire ça ! ( Tout comme cet article d’ailleurs )

Le vibe coding, pour ceux qui débarquent, c’est ce terme inventé par Andrej Karpathy d’OpenAI qui consiste à décrire ce que vous voulez coder à un LLM. Ce dernière génère alors le code, et vous testez si ça marche ou si ça marche pas. Et ensuite vous demandez des ajustements et ainsi de suite !

Autant dire que c’est devenu un sujet chaud pour pleiiiins de raisons.

Bref, Linus se déclare “plutôt positif” sur le vibe coding mais uniquement comme point d’entrée en informatique. Pour des petits projets, des prototypes rapides…etc c’est top car ça permet à des gens qui ne savent pas coder de faire des trucs super ! Mais après pour du code critique en production, il est cash en expliquant que ça risque d’être “horrible, horrible d’un point de vue maintenance”. Et je ne peux pas lui donner tort.

Linus n’utilise pas personnellement d’IA pour coder mais il voit bien que des gens testent l’IA pour travailler sur du code critique dans le noyau Linux et ça il s’en méfie à raison car les mainteneurs du kernel se prennent régulièrement des bugs reports et des security notices complètement bidons générés par des gens qui utilisent mal les IA.

Les crawlers IA posent aussi des problèmes techniques sur kernel.org car ces bots qui aspirent tout le code pour nourrir leurs modèles font ramer les serveurs. Quoiqu’il en soit, Linus est plutôt modéré sur le sujet de l’IA générative pour coder et attend avec impatience le jour où l’IA sera un truc moins hype. En gros, qu’on arrête d’en parler H24 et qu’on l’utilise juste quand c’est pertinent…

C’est vrai que d’un côté, vous avez ces fifous pro-IA à toutes les sauces qui pensent qu’on va tous devenir des prompt engineers et que les devs vont disparaître (spoiler : non). Et de l’autre, les donneurs de leçons en pureté technologique qui refusent l’IA en bloc sans jamais se poser la moindre question.

Du coup, je vous avoue que je suis content de voir qu’au milieu de tout ce bordel, y’a ce bon vieux Linus qui nous explique que c’est juste un stupide outil et qu’il faut simplement apprendre à l’utiliser intelligemment.

Et si votre serveur Linux était comme un appart en coloc où tout le monde partage la même cuisine, le même salon, les mêmes chiottes ?? Forcément, ça finit toujours mal avec quelqu’un qui monopolise les toilettes pendant que vous avez une urgence en spray, un autre fait crasher la machine à laver avec ses expérimentations douteuses de voyage dans le temps, et au final personne n’est content.

Hé bien figurez-vous qu’un développeur nommé Cong Wang de Multikernel Technologies vient de proposer une solution radicale qui consiste à donner à chaque processus son propre kernel Linux, avec ses propres core CPU, comme des colocataires qui auraient enfin chacun leur studio…

Selon le patch soumis sur la Linux Kernel Mailing List (LKML), cette architecture “multikernel” permettrait de faire tourner plusieurs noyaux Linux indépendants sur la même machine physique. C’est pas vraiment de la virtualisation classique façon VMware ou KVM, mais c’est plutôt comme si vous découpiez votre ordinateur en tranches et que chaque tranche vivait sa vie. Le truc marrant, c’est que Cong Wang n’est pas un petit nouveau qui débarque avec ses idées folles. Le bonhomme a déjà contribué à plus de 1000 patches au noyau Linux et il maintient le sous-système de traffic control . Autant dire qu’il sait de quoi il parle quand il touche au code du noyau.

D’ailleurs cette idée de séparer les kernels rappelle furieusement le projet Barrelfish que Microsoft Research et l’ETH Zurich avaient lancé il y a quinze ans. À l’époque, ils voulaient traiter l’OS comme un système distribué où chaque core CPU aurait son propre kernel qui communique avec les autres par messages. Sauf que voilà, c’était trop tôt. Les processeurs n’avaient pas assez de cores pour qu’on puisse se permettre ce genre de luxe, et puis franchement, qui avait besoin de ça en 2009 ?

Aujourd’hui avec nos CPU à 128 cores et nos problèmes de sécurité qui explosent, l’idée prend soudainement tout son sens.

Selon Phoronix et les patches sur la LKML, l’implémentation de Wang utilise kexec, ce mécanisme qui permet normalement de redémarrer directement dans un nouveau noyau sans repasser par un reboot. Sauf qu’ici, au lieu de remplacer le noyau existant, on en charge plusieurs qui vont cohabiter. Chaque kernel se voit attribuer ses propres cores CPU et ils communiquent entre eux via un système d’interruptions inter-processeurs (IPI) spécialement conçu pour l’occasion. Et dans les 7 patches proposés en RFC, Wang prévoit des mécanismes de surveillance pour gérer tous ces petits mondes parallèles.

Et pendant que Cong Wang bricolait son multikernel dans son coin, les géants du cloud comme Amazon, Microsoft et Google ont développé en parallèle une technologie appelée KHO ( Kexec HandOver ) qui permet de préserver l’état système lors du changement de kernel. En gros, ils veulent pouvoir mettre à jour le noyau Linux de leurs serveurs sans perdre les VMs qui tournent dessus. Sauf que si le multikernel de Wang fonctionne vraiment, ça pourrait rendre leur stack de virtualisation complètement obsolète.

Car pourquoi s’embêter avec des hyperviseurs complexes quand on peut juste donner à chaque workload son propre kernel ?

Le plus drôle dans tout ça, c’est que Wang admet candidement dans son RFC que pour l’instant, ça marche “que sur sa machine de dev avec des paramètres hardcodés”.

Maintenant si cette techno décolle, on pourrait voir des trucs assez dingues. Genre un kernel temps réel qui gère les processus critiques pendant qu’un kernel classique s’occupe du reste. Ou alors des kernels spécialisés pour différents types de workloads : un pour le machine learning, un pour les bases de données, un pour le réseau. Vous pourriez même imaginer des kernels avec différents niveaux de sécurité du genre un kernel ultra-paranoia pour vos données sensibles et un kernel plus relax pour Netflix. Et le plus beau c’est que si un kernel plante, les autres continuent de tourner tranquillement.

C’est comme avoir plusieurs systèmes de secours intégrés directement dans la machine.

Mais attention, on parle quand même d’une RFC, et pas encore d’un truc prêt pour la prod. La communauté des barbus du noyau va probablement passer des mois à débattre de chaque ligne de code, et c’est tant mieux parce que toucher à l’architecture fondamentale de Linux, c’est pas comme patcher un bug dans Firefox. Si ça merde, c’est potentiellement des millions de serveurs qui partent en vrille.

Au final, que ce patch soit accepté ou pas, ça montre surtout que Linux continue d’évoluer de manière radicale pour toujours aller plus loin ! Et si vous l’évolution de ce projet, tout se passe sur la LKML .

Source

Créer un système d’exploitation complet from scratch pour s’amuser, c’est le genre de projet un peu foufou qu’on ne voit plus tellement aujourd’hui. Pourtant SkiftOS existe !

SkiftOS c’est un OS écrit entièrement depuis zéro, et pas un n-ième fork de Linux ou d’une distribution BSD. Non, c’est un vrai OS avec son propre kernel, son interface graphique et même les bases d’un moteur de navigateur web.

J’ai découvert ce projet en me baladant sur les Top GitHub et ça m’a rappelé cette époque d’avant ma naissance où créer son OS était un genre de rite de passage pour tous les développeurs passionnés. Sauf qu’ici, on n’est plus dans les années 70 et le projet utilise du C++20 moderne avec une architecture microkernel très propre.

Et malgré son statut de projet “hobby”, il fonctionne réellement. Il tourne pour le moment sur du hardware x86_64 et l’équipe travaille sur le support RISC-V.

L’architecture modulaire du projet est d’ailleurs particulièrement bien pensée. Chaque module a son petit nom, c’est rigolo. Hjert gère le microkernel avec les fonctions essentielles telles que la gestion mémoire, l’ordonnancement et l’IPC (Inter-Process Communication). Karm fournit la bibliothèque C++ de base sans dépendre de la STL (Standard Template Library) . KarmUI propose un framework d’interface réactive. Hideo s’occupe du bureau et de l’environnement graphique. Et Vaev ambitionne de devenir un moteur de navigateur web complet.

Pour compiler tout ça, l’équipe a également développé CuteKit, leur propre système de build qui gère les dépendances et la cross-compilation. Bah oui, quand on réinvente un OS, autant réinventer aussi tous les outils pour le construire.

Cette approche “tout fait maison” rend en tout cas le projet fascinant d’un point de vue pédagogique. Car oui le code source est disponible sur GitHub donc si vous voulez comprendre comment fonctionne un OS moderne sans vous perdre dans les millions de lignes de code de Linux ou de Windows (pour les vieilles versions qui ont leakée), c’est une excellente opportunité pour apprendre. Pas besoin donc d’être Microsoft ou Apple pour développer un système d’exploitation fonctionnel.

Faut “juste” de la motivation, du temps, des compétences en C++ moderne, et surtout l’envie de construire quelque chose de différent.

Vous l’aurez compris, SkiftOS ne remplacera probablement jamais votre OS principal, c’est clair mais pour les développeurs curieux qui veulent comprendre les entrailles d’un système d’exploitation, ou pour ceux qui cherchent un projet open source technique sympa où contribuer, c’est une sacrée mine d’or.

Et qui sait, peut-être que dans quelques années on parlera de SkiftOS comme on parle aujourd’hui des débuts de Linux…

La guerre fait rage dans les coulisses du noyau Linux car d’un côté, nous avons les vétérans du C qui hurlent à la trahison, et de l’autre, les évangélistes de Rust qui brandissent leurs promesses de sécurité mémoire !

Et au milieu de tout ça, y’a Linus Torvalds qui joue les arbitres en essayant de calmer tout le monde. Et pendant que les développeurs se chamaillent sur les forums comme des gosses dans une cour de récré, Rust vient discrètement de marquer un point décisif avec la sortie du kernel Linux 6.15.