Luc Lenôtre nous parle de Maestro, son kernel de type Unix écrit en Rust
Noyau rouillé
Maestro est un noyau de type Unix. Développé par un ingénieur français, Luc Lenôtre, il constitue pour l’instant un projet issu d’une passion. Son auteur, à qui nous avons parlé, compte cependant le faire évoluer fortement cette année. Avec, pourquoi pas, une ouverture aux contributions.
Le 10 janvier à 11h53
6 min
Logiciel
Logiciel
Lorsque l’on parle de distributions Linux, on évoque souvent son noyau, ou kernel. Il s’agit de la pièce maîtresse dans le système, le composant central sans lequel rien n’est possible. Bien sûr, c’est la même chose dans tous les systèmes. Dans le monde Linux toutefois, le noyau revêt une importance particulière. Il peut d’ailleurs être mis à jour, comme n’importe quel autre composant ou même application.
Luc Lenôtre est un jeune ingénieur français. Il a fait ses armes à l’école 42 et travaille actuellement comme développeur dans une société de marketing. Il a cependant une passion : la programmation système, qu’il a débutée quand il avait 14 ans, après s’être lancé dans le développement à 10 ans. Plus le temps passait, plus il était intéressé par le code bas niveau.
« L’idée d’un kernel a fait son chemin avec le temps. J’ai finalement commencé en 2018, en tant que projet scolaire », nous raconte-t-il. À cette époque, le travail débute en C. « C’était le langage par défaut pour le développement système. L’avantage était aussi que nous l’apprenions à l’école ».
Passage à Rust
Comme aujourd’hui, il s’agissait d’un projet personnel, développé pour le plaisir. « J’aime l’idée de faire fonctionner du code n’appartenant qu’à moi sur mon ordinateur. Pour des questions de plaisir et de contrôle de ce qui s’y passe. C’est fantastique, je trouve, d’avoir son code à soi ».
Au fur et à mesure de l’avancée des travaux cependant, il se rend compte que son code va nécessiter une large refactorisation. À cette époque, une idée lui vient alors : « Je me suis dit qu’en passant à Rust, je pourrais me débarrasser de nombreuses contraintes imposées par le C et supprimer des catégories entières d’erreurs potentielles. La transition a pris environ un an ».
Rust est en effet un langage qualifié de « memory safe ». La gestion de la mémoire étant confiée au compilateur, le développeur n’a plus besoin de la prévoir, notamment dans le cas des pointeurs. En 2019, lors d’une présentation à la conférence Bluehat IL, Matt Miller, du MSRC (Microsoft Security Response Center), constatait ainsi que 70 % des failles corrigées par Microsoft étaient liées à la mémoire.
Depuis sa création en 2006 par Mozilla, le langage Rust a largement gagné en visibilité. Sa maturité l’a fait entrer dans de nombreuses entreprises comme Dropbox, Facebook ou encore AWS. Il est particulièrement adapté au développement système grâce à ses performances élevées. Ces dernières années, on a ainsi vu le Rust se faire une place dans le noyau Linux. Microsoft réécrit certaines bibliothèques de Windows dans ce langage, et même plusieurs parties du noyau.
Maestro aujourd’hui
Actuellement, Maestro représente 48 800 lignes de code environ, réparties sur 615 fichiers. « Idéalement », indique Luc Lenôtre, « il pourrait remplacer le kernel Linux à terme ». Mais la route est encore très longue.
Maestro gère à ce jour 31 % des appels système Linux, plus précisément 135 sur 437. Comme le développeur nous l’explique cependant, « il y a beaucoup d’autres choses que les appels système. Pour obtenir une parité, il faudrait encore des années de travail ». D’autres composants sont présents, comme un gestionnaire de daemons (Solfège, qui gère aussi le boot) ainsi qu’un autre pour les paquets (blimp). Des outils vitaux comme bash, musl et les principaux outils GNU sont donc gérés.
Les fonctionnalités de Maestro sont pour l’instant limitées. Par exemple, le VGA est le seul mode d’affichage géré. Seule l’architecture 32 bits est prise en compte et l’exécution des tâches ne peut se faire que sur un seul cœur. Luc Lenôtre est conscient de ces limitations, qui ne posent aucun problème dans le cadre d’un projet personnel.
Une ouverture à venir aux contributions ?
Maestro reste pour l’instant un « développement-passion ». Cependant, la visibilité accrue de ces derniers jours pourrait changer le destin du projet. « Le code est open source et sous licence MIT sur GitHub. Je veux simplement montrer ce que je fais. Le code n’est pas ouvert aux contributions, mais j’ai reçu une dizaine de demandes. Donc c’est possible », ajoute Luc Lenôtre.
Nous avons demandé quels étaient les développements prévus pour cette année. « J’ai beaucoup de choses prévues. D’abord passer au 64 bits, parce que le 32 bits est obsolète. Je voudrais aussi supporter le multicœur, parce que c’est pareil, plus personne ne fait de monocœur. Je prévois également de me passer du VGA pour afficher plus d’informations. Le plus gros apport pour moi serait d’ajouter le support du réseau, parce qu’il permettrait de récupérer mes propres paquets quand j’en ai besoin ».
Beaucoup de travail en perspective donc. Une passion dévorante ? « J’y passe tout mon temps libre : mes soirs, mes week-ends, mes vacances ». L’ouverture aux contributions extérieures pourrait permettre au projet d’accélérer, mais la nouvelle ampleur et l’inévitable travail de synthèse à réaliser apporteraient leurs propres lots de tâches.
Luc Lenôtre nous parle de Maestro, son kernel de type Unix écrit en Rust
-
Passage à Rust
-
Maestro aujourd’hui
-
Une ouverture à venir aux contributions ?
Commentaires (25)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/01/2024 à 13h32
Le 10/01/2024 à 13h35
Le 10/01/2024 à 13h52
Le 10/01/2024 à 14h17
Après, il ne faut pas voir cet OS comme étant au même niveau que Linux, ou alors au niveau de Linux 0.01 de 1991. Pas de multi-arch, uniquement 32 bits, pas de multi-core. C'est encore très très rudimentaire.
Le 10/01/2024 à 14h20
Le 10/01/2024 à 17h47
Oh wait! et si on réécrivait BeOS avec ce nouveau kernel :) ?
Le 10/01/2024 à 22h30
Le 11/01/2024 à 08h32
Le 10/01/2024 à 17h32
Le 11/01/2024 à 08h45
Les environnements d'exécution, c'est pas nouveau. OpenVMS en avait pour émuler d'anciennes versions, CP/M pour le DOS, Windows NT en avait pour lancer des utilitaires Unix, FreeBSD sait lancer des exécutables Linux (à une époque il était même doué et plus rapide).
Windows d'ailleurs sait toujours différencier différents type d'exécutables .EXE et charger les DLL et l'environnement en conséquence.
Par un moment, les pilotes xfree étaient prévus pour être utilisé sur différents systèmes (Linux, FreeBSD, Solaris) avec le même exécutable quelque soit l'OS.
Linux lui-même doit encore avoir le support du a.out et de l'ELF en même temps, et il a été possible d'exécuter un EXE DOS ou Windows directement depuis le bash.
Des projets pour maintenir "en vie" BeOS étaient basés sur des kernels différents, tout en exécutant des programme natifs BeOS.
Donc lancer un exécutable d'un autre OS proche, c'est faisable et même courant. Après, kernel space, user-space, c'est à choisir.
Si c'est pour avoir un OS compatible Linux pour des conteneurs sans aucun besoin de support matériel, ça doit être assez léger à faire.
Modifié le 11/01/2024 à 10h44
Et je doute encore plus que l'on puisse se permettre ça sur Linux actuellement. Il y aurait beaucoup trop de problèmes de compatibilité. Pour faire ça sur un produit si établi, il faut être une entité forte comme Apple ou Microsoft. Sur du libre ça conduirait fatalement à des forks et un risque de fragmentation de l'écosystème.
D'ailleurs, même Microsoft a abandonné son expérimentation de remplacement du noyau NT de Windows, de peur de déstabiliser son écosystème.
Le 11/01/2024 à 10h40
Je crois me rappeler que ça a été abandonné il y a au moins deux ans, ça.
Le 10/01/2024 à 13h53
Le 10/01/2024 à 13h58
https://linux.developpez.com/actu/352802/-Rust-est-une-solution-pour-eviter-au-noyau-Linux-et-aux-mainteneurs-de-plonger-dans-la-stagnation-d-apres-Linus-Torvalds-a-propos-de-l-impact-de-ce-langage-dans-le-developpement-du-kernel/
Modifié le 11/01/2024 à 04h23
Le 10/01/2024 à 13h59
Généralement c'est l'effort d'un petit groupe, voire d'une seule personne.
En tant que (ancien) dev, je trouve ça très impressionnant.
Mais professionnellement parlant, je trouve que ca fait beaucoup de candidats et de ré-inventage de roue.
Le monde pro attend la consolidation de tous ces projets autour d'un ou deux OS supporté par des grands du secteur.
Ca me rappelle l'effervescence des nouveaux framework javascript qui commence à s'agglutiner autour de Angular (Google) et React (Facebook).
Le 10/01/2024 à 14h07
Après, je pense que le succès de Linux est aussi grâce à la communauté qui s'est très rapidement construite autour et aux entreprises qui ont investi dedans très tôt (coucou Red Hat ou encore Yggdrasil, première distrib commerciale). Ironiquement, Linux avait été aussi démarré comme projet "perso et sans grosses ambitions comme GNU", et depuis c'est un composant majeur là où Hurd n'a jamais réellement percé alors qu'il est porté par la FSF au même titre que GNU.
Et à côté nous avons pourtant les noyaux BSD qui sont très matures, mais beaucoup moins bruyants que Linux.
Mais c'est aussi la beauté de l'open source, plein de projets qui naissent, se développent, et meurent, avec un cycle de vie inlassable. Parfois le ré-inventage de roue n'est pas forcément une idée négative : ça peut permettre de trouver des approches un peu plus innovantes. Mais sur le plan professionnel, très peu d'entreprises ont l'envie de le faire.
Modifié le 10/01/2024 à 15h23
Le 10/01/2024 à 15h35
Je dis que Rust, malgré toutes ses promesses intrinsèques sur la sécurité, ne dispense pas d'avoir la promesses de service/support à long terme. Et que, dans le monde pro, cette promesse de service/support à long terme doit venir d'un grand groupe (question de confiance sur la pérennité).
Modifié le 11/01/2024 à 05h40
Beaucoup de projet resteront discrets et oubliés, c'est la dure loi de la sélection
naturellelogicielle. 😊Modifié le 10/01/2024 à 20h11
Il faut une très bonne valeur ajoutée dans un projet d'OS *nix qui ne soit pas 100% linux/bsd.
Par exemple dans Moturus OS (un autre *nix en Rust), la valeur ajoutée c'est que ca tourne spéficiquement sur KVM/Hypervisor et que l'ABI aussi est en Rust.
Pour moi, que ca soit "ecrit en Rust" n'est pas une valeur ajoutée qui se suffit à elle même.
Le 11/01/2024 à 04h43
En effet Moturus OS a une bien meilleure valeur ajoutée. Redox OS d'un autre coté à aussi l’intérêt de miser sur une architecture micro-kernel et de proposer une alternative au traditionnel UNIX.
Le 12/01/2024 à 10h07
Le 12/01/2024 à 10h11
Le 12/01/2024 à 10h21
Comme quoi, l'IA a parfaitement atteint une des principales caractéristique humaines : la flemme.