Redox OS, le prochain système d’exploitation à conquérir le monde ?

dominique · décembre 10, 2020, 7:22am

Posté par tisaac le 07/12/20 à 19:35. Édité par 4 contributeurs. Modéré par Davy Defaud. Licence CC By‑SA.

7 déc.2020

Le 20 avril 2015, Jeremy Soller publiait la première version de Redox OS sur GitHub. Ce système d’exploitation est depuis lors en développement actif, avec des apports de plus de soixante‑dix développeurs. Après cinq ans de développement, on en est à la version 0.5.0.

Voici un courte présentation de Redox OS, de son état d’avancement, et quelques réflexions sur la possibilité de succès de ce projet.

Sommaire

Le projet

En bref

En très court, c’est un système d’exploitation :

écrit en RUST ;
avec une architecture de type micronoyau ;
qui s’inscrit dans la lignée des systèmes d’exploitation à la UNIX et qui assure une certaine compatibilité avec les normes POSIX ;
qui passe de la logique « tout est fichier » à « tout est lien URL » ;
publié sous licence de type MIT X11.

L’ambition est de créer un système d’exploitation complet, totalement fonctionnel et axé sur la sécurité dans un esprit open source . L’un des objectifs est de pouvoir être une alternative réelle à GNU/Linux, ainsi que d’être suffisamment compatible pour pouvoir exécuter la plupart des programmes tournant sur GNU/Linux avec un minimum de modifications.

On ne sera pas surpris que l’argument de la sécurité soit mis en avant pour justifier le choix de Rust.

Les projets annexes

Comme l’objectif de Redox OS est d’être un système d’exploitation complet, en plus du développement du noyau, il englobe une série de projets annexes, notamment :

TFS : un système de fichiers inspiré de ZFS ;
Ion : le shell de Redox ;
Orbital : le serveur d’affichage de Redox ;
OrbTK : une boîte à outils de widgets ;
pkgutils : la bibliothèque de gestion des paquets de Redox et son interface en ligne de commande ;
Sodium : un éditeur de type Vi ;
ralloc : un allocateur de mémoire ;
games-for-redox : une collection de mini‑jeux pour Redox (similaires aux jeux BSD).

Ce qui occupe actuellement Jeremy Soller est pkgar. Pkgar est un format de fichier, une bibliothèque et un exécutable en ligne de commande pour créer et extraire des collections de fichiers sécurisés par chiffrement, principalement pour une utilisation dans la gestion des paquets sur Redox OS.

Un projet vivant ?

Le développement de Redox OS est actif. Depuis le début, une septantaine de personnes a contribué au code mais, assurément, Jeremy Soller reste très largement le contributeur principal.

Si l’on regarde les publications des différentes versions, on observe des sorties assez régulières même si le rythme a peut‑être tendance à ralentir avec le temps. Voici une sélection de quelques publications du projet :

première publication d’image ISO : 0.0.3, le 1er décembre 2016 ;
rafraîchissement du visuel : 0.1.0, le 24 février 2017 ;
la publication des deux ans : 0.2.0, le 23 avril 2017 ;
le retour de Redox : 0.3.0, le 13 juillet 2017 ;
la dernière de la série 0.3.x : 0.3.5, le 21 mars 2018 ;
la série ignorée : il ne semble pas y avoir de réelle publication dans la série 0.4.x ;
la dernière en date : 0.5.0, le 24 mars 2019.

La dernière publication remonte donc à plus d’un an mais cela n’empêche pas Jeremy Soller et quelques autres de régulièrement donner des nouvelles. On peut également suivre le projet sur Twitter, sur Discourse ou encore reddit .

Mentionnons également que depuis 2018, Redox organise ses propres Summer of Code qui permettent à quelques étudiants de contribuer au développement du système d’exploitation dans le cadre de stages d’étudiant. La page News du site de Redox recueille d’ailleurs chaque année les comptes‑rendus hebdomadaires de l’avancement ce travail.

Redox OS est donc bien un projet vivant et semble être le seul projet de système d’exploitation écrit en Rust réellement actif, à l’exception éventuelle de quelques projets à visée pédagogique.

Un système d’exploitation qui fonctionne ?

Clairement, la réponse est non si vous cherchez un système d’exploitation alternatif à GNU/Linux. Aujourd’hui, Redox OS n’est pas du tout à un stade où vous pouvez facilement l’installer sur votre PC. Il est assez simple de tester Redox OS, soit en mode « média autonome », soit à l’aide d’une machine virtuelle. Mais très vite, on est confronté au manque de pilotes basiques.

Quand je l’ai testé sur un portable Dell Inspiron 17R N7110, cela fonctionnait plutôt correctement. Le clavier, le pavé tactile et l’écran fonctionnaient correctement. Malheureusement, impossible de me connecter à Internet, vu que les seuls contrôleurs Ethernet gérés pour le moment par Redox OS sont les RTL8168d et e1000d, qui ne sont, ni l’un ni l’autre, le matériel qui équipe mon Dell. Forcément, cela limite un peu les possibilités.

Au stade actuel, il y a un micronoyau fonctionnel avec quelques éléments de base supplémentaires. Redox OS dispose d’un environnement graphique avec un gestionnaire de fenêtres et quelques applications basiques. Il est possible de naviguer sur le Web grâce à son navigateur intégré (Netsurf). Vous disposez également d’un éditeur de texte, d’un gestionnaire de fichiers, d’un terminal et d’une visionneuse de documents. Et c’est pratiquement tout. Dans cette liste, il manque encore les jeux ; mais contrairement à certains et à d’autres, je n’ai pas su les faire fonctionner.

De son côté, le créateur de Redox OS a pu l’installer de manière permanente sur un System76 Galago Pro (galp3-c) en novembre de l’année dernière. Jeremy Soller semble assez satisfait de la manière dont le système fonctionne sur cet appareil.
Pour vous faire une idée du fonctionnement de Redox OS, vous pouvez regarder cette courte vidéo, ou cette vidéo un peu plus longue (une trentaine de minutes) qui présente de manière un peu plus large les capacités et limites de Redox OS.

À ce stade, le plus ennuyeux est peut‑être que malgré de nombreux efforts, Redox OS n’a pas encore atteint le stade où il peut se compiler à partir de lui‑même ( self‑hosting ). Pour l’utilisateur lambda tel que moi, cela ne signifie pas grand‑chose, mais pour pouvoir développer plus efficacement Redox OS, cela semble être une étape appréciable.

Doit‑on s’inquiéter qu’après cinq ans, cette capacité de self‑hosting n’est pas encore atteinte ? Sans doute pas. Par exemple, cela a pris huit ans à Haiku pour atteindre ce stade de maturité.

Pourquoi cela ne marchera pas

Micronoyau vs noyau monolithique, débat éternel avec toujours le même vainqueur

Dès le début de Linux, il y eut un débat sur la pertinence de l’architecture du noyau qui était monolithique. Ce débat ayant principalement lieu entre Andrew S. Tanenbaum et Linus Torvalds. D’un point de vue théorique, l’architecture avec un micronoyau offre une meilleure sécurité (et peut‑être une meilleure portabilité) au détriment de la performance. Au niveau de la performance, les plus optimistes avancent que la perte de rapidité du micronoyau par rapport au noyau monolithique peut être limitée à 6 %. Ce débat revient de temps à autre, mais force est de constater qu’aucun système d’exploitation basé sur un micronoyau n’a jamais percé. Pourquoi en serait‑il autrement aujourd’hui ?

Une dynamique qui ne décolle pas

Quand l’on regarde le développement de Linux, on se rend compte que bien que les premières années furent assez confidentielles aux yeux du grand public, il y a eu rapidement un grand nombre de personnes qui a travaillé sur ou autour de Linux.

Un des éléments explicatifs est que Linux répondait à de réels besoins. Avant tout au niveau personnel, Linus avait un vrai problème avec un ordinateur puissant (pour l’époque) mais pas vraiment de système d’exploitation exploitant toute cette puissance. Au niveau collectif, il y avait sans doute une communauté qui cherchait à développer un système d’exploitation libre. Alors que Hurd ne progressait pas réellement et que BSD était empêtré dans des questions de licence, Linux apportait une bonne part de ce qui manquait à cette communauté. Ce n’était sans doute pas le but de Linus au départ mais son travail répondait à un besoin qui dépassait largement sa personne. Concernant Redox, on ne voit pas le réel problème individuel que l’on essaie de résoudre, pas plus que de besoin plus large qu’il permettrait de satisfaire.

Argument délicat à utiliser dans le contexte du Libre, mais il y a une forme de balkanisation des développements de systèmes d’exploitation sur base de micronoyaux. Redox OS y contribue d’ailleurs, vu que ce projet a été lancé alors que d’autres systèmes d’exploitation avec une architecture de micronoyau existaient ou étaient en développement. Ceux qui sont intéressés par les systèmes d’exploitation construits avec un micronoyau visiteront avec intérêt microkernel.info . La diversité est évidemment une force et une richesse, mais elle est aussi une faiblesse quand les ressources sont limitées.

Vu de loin, il n’est pas tellement évident qu’il existe une feuille de route claire pour le développement de Redox OS. Une feuille de route explicite n’est sans doute pas totalement nécessaire, mais cela peut aider à créer une dynamique et une communauté alignée sur des objectifs cohérents.

Pourquoi cela pourrait marcher

Rust, le langage à utiliser

Le choix de Rust est sans doute très pertinent pour le développement d’un système d’exploitation. Ce n’est pas pour rien que même Apple et Microsoft se mettent à utiliser de plus en plus Rust. Sur la question de Rust comme langage pour écrire un système d’exploitation, je vous recommande les vidéos de Bryan Cantrill sur le sujet, qui sont plutôt intéressantes. Par exemple, « Is It Time to Rewrite the Operating System i Rust? » ou « Rust and Other Interesting Things ». Pour un avis moins enthousiasmant sur Rust, il y a une autre vidéo, mais j’ai quelques doutes sur la qualité de la traduction proposée en sous‑titre.

L’air du temps

Même si l’architecture avec un micronoyau n’a pas percé sur les ordinateurs de bureau, il y a quand même des évolutions dans le monde de la programmation qui vont dans un sens similaire. Par exemple, le développement des architectures en micro‑service dans le monde du Web est, même si comparaison n’est pas raison, dans un même esprit que les micronoyaux. On pourrait penser que c’est le signe d’un changement de l’air du temps qui pourrait être plus favorable aux micronoyaux.

De manière plus directement liée au monde des ordinateur de bureau, les flatpacks et autres concurrents avec le développement de bacs à sables visent, entre autres, à améliorer la sécurité en contrôlant de manière plus fine les accès des différents programmes aux différentes ressources de l’ordinateur. C’est justement une des forces des micronoyaux que de pouvoir offrir un contrôle fin de ce à quoi accède chaque logiciel. Pourquoi, pour des questions de sécurité, s’amuser à utiliser flatpack et consorts sur un noyau monolithique alors que, par conception, une architecture avec micronoyau est mieux à même d’atteindre cet objectif ?

La théorie du ketchup

Concernant la dynamique qui ne prendrait pas son envol, c’est sans doute à relativiser. De nombreux projets très valables sont développés par peu de personnes. Par ailleurs, n’est‑il pas normal que poser les bases d’un projet prenne du temps et que, aux yeux d’un néophyte, cela donne l’impression de ne pas beaucoup avancer ? Tout comme le ketchup met du temps avant de sortir de la bouteille et puis vient tout d’un coup, il est possible que Redox OS semble peu évoluer pendant une longue période et puis, une fois les fondations bien construites, puisse voir son développement largement accélérer à partir d’un moment. C’est visiblement aussi un peu l’espoir du développeur principal de Redox OS, qu’une fois que Redox OS sera self‑hosted , cela débloque les contributions possibles d’autres développeurs.