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 une 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
- Un système d’exploitation qui fonctionne ?
- Pourquoi cela ne marchera pas
- Pourquoi cela pourrait marcher
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 flatpaks 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.
Aller plus loin
- Site du projet (995 clics)
- GitLab du projet (90 clics)
- Écrire son système d’exploitation en une heure (286 clics)
- Un vieux journal sur Redox (147 clics)
# c'est vraiment la caractéristique numéro 1 ?
Posté par nokomprendo (site web personnel) . Évalué à 10.
Désolé de paraitre si négatif mais à mon avis ça décrédibilise vraiment le propos quand le point numéro 1 d'un projet c'est d'être "écrit en RUST"
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par Aldebaran (site web personnel) . Évalué à 3.
C'est vrai que si ça se limite à "Rust c le bi1 !", le projet n'a pas grand intérêt.
Après tout le monde me dit (et moi même je me laisse de plus en plus convaincre) que le Rust c'est bien parce que ça permet de faire du code plus sure, de plus haut niveau, etc…
Mais je suis vraiment curieux de voir ce que ça donne, si on voit réellement rejaillir les avantages annoncés du langage sur le produit fini. Je regarderai un peu plus en détail, j'étais passé à côté du principe de tout est URL, je ne vois pas bien ce que ça veut dire en fait. Tout est URL, genre pour avoir accès à un fichier on va taper sur localhost/fileserver/file.txt ?
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par tisaac (Mastodon) . Évalué à 4.
Pour plus d'info sur le tout est url, peut-être que la documentation en cours d'écriture peut être intéressante.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . Évalué à 4.
Tu peux regarder la liste des CVE liées à des buffers overflows. Hors
unsafeça fait parti des classes d'erreurs qui sont impossibles (avec d'autres comme les races conditions, les danglings pointers,…).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par Glandos . Évalué à 4.
J'aime bien Rust, mais justement, quand on écrit un OS, on tape pas souvent le
unsafe?Ou alors, c'est justement quand on écrit un programme d'espace utilisateur qui doit s'interfacer avec une
libcqui n'est pas écrite en Rust ?[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . Évalué à 4.
Pas autant qu'on ne pourrait l'imaginer je pense. Ça va concerner les drivers, le bootstrap du noyaux, quelques interfaçages pas niveau (pour les IRQ j'imagine), mais il reste un tas de choses à faire comme le scheduling, le mappage mémoire, la pile IP,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . Évalué à 5.
J'essai de suivre les avancé de Rust et y'a quand même beaucoup d'effort de fait pour éviter l'unsafe (plein d'api qui se stabilisent sur par exemple de la gestion fine de la mémoire) et donc de réduire le scope de code "dangereux".
Bien évidement, ça ne sera jamais parfait et des outils tel que Miri permettent de détecter un certain nombres de cas dans la partie unsafe.
Rust, malgré ses qualités peut avoir des soucis d'overflow et de bugs au runtime : la différence notable c'est que quand ça "panic", le programme s'arrête directement et il est donc plus délicat d'avoir des soucis de fuite de mémoire d'exploiter ces bugs (comme en C) pour un usage frauduleux.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par StyMaar . Évalué à 4.
Pas tant que ça en fait, y'a forcément des trucs
unsafe, mais même dans un OS c'est largement minoritaire et ça peut s'encapsuler facilement. Comme son nom l'indique, le blog writing an OS in Rust, par de développement d'OS en Rust, et il y a assez peu deunsafeen réalité (et plus l'OS devient complexe, proportionnellement plus il y a de logique (safe)).[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par abriotde . Évalué à 0. Dernière modification le 07 décembre 2020 à 23:24.
En fait dire que c est programmé en Rust sous-entends que l os est axé sur la sécurité. Et en ce sens on comprends qu il ai choisi le micro noyau, c est plus sécurisé.
Il pourrait dans un futur, encore lointain faire de l ombre à open-bsd lui aussi micro noyau axé sécurité mais dont le principal point faible est qu il soit écrit en C… A ce moment il pourrait vraiment décoller.
Il faut bien comprendre qu actuellement certains service critiques cherchent un OS le plus sécurisé possible et ont les moyens d investir…
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par nokomprendo (site web personnel) . Évalué à 10.
Heu non, Openbsd c'est du noyau monolithique. Tu dois confondre avec Hurd ou Minix.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par cosmocat . Évalué à 3.
Peut-être quelques indices de compréhension: https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . Évalué à 8.
En soit, c'est vrai que ça peut paraître un peu présomptueux surtout que y'a quand même une vague de fans de Rust qui ont tendance à vouloir réécrire le monde avec.
Rust est un des seuls langages (à ma connaissance) suffisamment mature (y'a D sans doute également, Zig et V mais ces 2 derniers sont trop jeunes) pour remplacer du C ou C++, obtenir des perfs équivalentes tout en donnant plus de sécurité (attention, c'est pas parfait, y'a tjs des blagues possibles au runtime) et permettant de faire des choses plus haut niveau notamment en terme de concurrence.
Le kernel linux commence à envisager des drivers en Rust, M# et Apple commencent à l'utiliser pour des parties critiques de leurs OS respectifs.
Bref, vu que le projet commence à se démarquer d'un simple POC et que l'essence de ces qualités proviennent en grande partie du langage choisi, je ne trouve pas ça déconnant.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Chez Haiku ça nous arrange bien que Redox existe. Quand des gens sont tenté d'essayer d'ajouter du Rust dans Haiku on peut les rediriger vers un projet qui leur convient mieux :o)
Sinon, dans les langages morderes qui marchent bien, il y a Swift et Go à ne pas oublier, quand même. Et dans les moins modernes il y a aussi plein de trucs (Object Pascal, Ada, …) mais ça n'intéresse jamais personne.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . Évalué à 4.
héhé
Pour ce qui est de Go et Swift, ils utilisent des Garbage collector. Ca ne rend pas la tâche impossible mais ça présente quand même un défaut de taille pour faire des OS un tant soit peu sérieux.
Pour les autres langages moins modernes, même si ils peuvent être pertinent, ils n'auront sans doute jamais la popularité pour être des candidats viables.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Swift utilise du reference counting (comme Rust et comme les shared_ptr en C++).
De toutes façons quel que soit le langage, pour faire un OS y'aura forcément un bout d'assembleur à écrire à la main quelque part. C'est juste un plus ou moins gros bout en fonction du langage choisi.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par dinomasque . Évalué à 7. Dernière modification le 08 décembre 2020 à 19:58.
Ca m'intrigue : quels sont les cas ou on est "obligé" de passer par l'assembleur pour écrire un OS ?
Quelqu'un sur Quora a compté en 2019 plus de 271 000 lignes d'assembleur dans Linux soit 1.58%.
Ca me parait beaucoup (même si ces lignes sont vraisemblablement dupliquées pour chaque architecture supportée par le noyau).
Je me demande également si ce code est encore écrit et maintenu par des humains.
BeOS le faisait il y a 20 ans !
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Principalement le switch de contexte entre les threads (au moins en C, ou il n'y a pas de coroutines inclues dans le langage).
Plein de choses dans la libgcc, mais ça compte pas, ça fait partie du compilateur (multiplications, divisions, etc pour différents types).
Les opérations atomiques ou de synchronisation de mémoire cache (souvent une seule ligne d'assembleur via un inline en C), encore que, gcc fournit des "builtins" qui évitent d'écrire ça directement.
Je crois que Linux a aussi ses propres trucs pour des raisons de performances (opérations sur des bitfields, par exemple? ça fait un moment que j'ai pas mis le nez dedans)
Probablement un petit morceau de bootloader, encore que, avec EFI ou openfirmware, on a déjà un environnement assez confortable au démarrage pour que ça ne soit pas nécessaire.
Ça c'est si on fait du C. Mais si on fait un langage qui ne permet pas de faire tout ce que fait le C (volatiles, trucs moches avec des pointeurs pour l'accès direct à la mémoire, par exemple), on sera probablement obligé de mettre un peu plus d'assembleur pour faire les trucs en question.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par lym . Évalué à 3.
Il y a des tas de choses à bas niveau qui sont propres à chaque architecture et qui n'ont pas leur place dans des langages de haut niveau, même ceux qui permettent déjà beaucoup de choses comme le C.
Sans même parler du strict démarrage (va appeler du C sans avoir initialisé une pile, donc une RAM qui est souvent un bout de mémoire cache plateforme dévoyé le temps de la complexe initialisation DDR!), niveau OS, toutes les primitives bas niveau touchant à la mémoire cache justement, la mémoire virtuelle, préfixes/postfixes d'interruptions, opérations atomiques (test&set)…
Cela ne représente plus grand chose (on n'écrit donc pas vraiment un OS en asm), même s'il y en a quand même de planqué ailleurs (sous forme d'asm inline) que dans des fichiers complets, mais c'est la portion inévitable.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
En fat, de nos jour, l'initialisation du matériel se fait plutôt par le bootloader que par l'OS lui même.
Si tu utilises EFI tu démarres avec ta pile (et le reste de la mémoire) déjà initialisée, tu as même de quoi afficher des choses à l'écran, utiliser des périphériques USB, …
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par lym . Évalué à 5.
Je ne crois pas avoir dit le contraire… mais l'UEFI ne va pas gérer la mémoire virtuelle de l'OS, ses IT, sa configuration cache et les finasseries pour maintenir sa cohérence très dépendantes de l'architecture.
Je dirais même que l'UEFI est une saloperie codé cochon, qui crée des dépendances évitables entre le boot loader et l'OS… avec pour résultat un code de démarrage en 3 phases quasi étanches (SEC/PEI/DXE), faisant intervenir jusque 3 origines de sources (RC/MRC, les réference code Intel source clos fournis uniquement aux éditeurs de BIOS/UEFI ; EDK2, implémentation de référence tirée encore par Intel ; Code glue/menu/log/selection boot device… historique de l'éditeur de BIOS).
Cad que le code commun se retrouve souvent avec 3(SEC/PEI/DXE)x3(sources code RC/EDK2/Editeur intégrant le patchwork)=9 duplicats…
Tout ce qu'on essaie d'ordinaire d'éviter. Avec au final un tas de m…. de l'ordre de grandeur du kernel linux en nb de lignes de code juste pour booter la machine, fournir qq services à l'OS (car microsoft n'a jamais su s'en passer, cf les ancêtres "interruptions" BIOS des boot services UEFI actuels), après avoir fait l'énumération PCI.
Et un truc plus long en temps (chargé d'une flash SPI) d'execution que le démarrage de l'OS complet derrière.
Pour fournir quoi d'utile? Un menu de config assez basique et un shell pas sans rappeler la boite DOS (en particulier les scripts, on revient au temps du .BAT): Un u-boot qu'on a longtemps fait tenir sur un secteur de 512k de flash NOR sur du powerPC est de ce point de vue mieux foutu que ces BIOS qui réclament une flash de 16MB (avec les firmwares en pagaille, autre spécificité Intel).
Stp, ne me parles plus d'UEFI…
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . Évalué à 4.
De ce que j'ai lu (pas grand chose, certes), le D semble très très fortement influencer ses utilisateurs pour utiliser le poubellier, ce qui est admis comme étant incompatible avec la performance (que ce soit de vitesse ou d'occupation mémoire, mais pour la vitesse d'écriture ça aide, probablement).
Des langages que tu cites et que je peux trouver facilement dans wikipedia fr, seul rust peut concurrencer C ou C++. Et il me semble pas que rust puisse embarquer du C aussi facilement que C++ (un simple
#includebien souvent), alors qu'il s'agit probablement de la base de code la plus importante, et une des plus vieilles, avec donc pas mal de correctifs de bugs.D'ailleurs, ce point est important: toutes les failles de sécurités ne sont pas liées à la mémoire, loin de la. Et c'est encore pire pour les bugs, alors que tout refaire (peu importe le langage cible), c'est aussi devoir reprendre tous les debugs, de 0.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . Évalué à 2.
Le langage D, j'en ai parlé car j'en entend souvent parlé mais j'ai si peu développé que je ne peut pas avoir d'avis objectif sur la question.
Rust peut s'interfacer avec C de plusieurs façon mais le plus courant est de créer des binding avec https://doc.rust-lang.org/std/ffi/index.html
Je suis vraiment pas expert dans le domaine (surtout en matière de sécu au niveau OS) mais du peu que je vois passer, 95% des failles les plus faciles à exploiter s'appui sur des buffer overflow non ?
En effet, c'est plus large mais Rust évite une paire de bugs de concurrence, de type et de conversion de type, de logique (pattern matching) etc.
Après, sur les aspects fonctionnels, métiers, les contournements logiciels pour des bugs matériels etc. y'a pas de magie en effet.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . Évalué à 4.
Moi non plus, mais j'ai déjà exploité une injection SQL ou PHP (sur des sites spécialisés). J'ai déjà essayé d'exploiter un programme avec un bug mémoire: c'est pas la même.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . Évalué à 2.
Oui, là tu parles de failles sur du web donc c'est pas vraiment comparable.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . Évalué à 4.
Pourquoi ça ne serait pas comparable? Ici on ne parle pas de développer juste un noyau, mais un système d'exploitation complet. Basé, justement, sur un micronoyau, dont le fonctionnement se base sur des architectures client-serveur en grand nombre.
Perso, je me dis que ça serait très dommage de nos jours de limiter les IPC à une et une seule machine, alors que de plus en plus de monde dispose d'un PAN.
Dans les cas que j'ai cités, c'est du texte, mais le plus important c'est que ce sont des messages réseau.
Et une application qui ne souffre pas de problèmes de mémoire peut malgré tout avoir des problèmes de concurrence, qu'un langage ne pourra jamais résoudre car liés à des problèmes d'interaction avec les autres machines ou juste d'autres processus.
Tiens, d'ailleurs, c'set quoi leur système d'init? Non parce que s'il est inspiré de sysVinit et RC, avec cette gestion des fichiers de PID bien foireuse, ben, c'est balo pour la sécu :) (je me doute qu'ils ont fait un truc plus propre, mais je suis curieux malgré tout).
Bref, un bug ou une faille réseau, parfois, ça peut déclencher des problèmes de mémoire, mais je doute vraiment que ça soit l'élément le plus fragile de nos jours.
Dans le thread, il y a une liste des failles liées à la mémoire. J'ai fait quelques "mesures": chercher un mot clé, tout copier, balancer un
xclip -o | grep '^CVE-2020' | wc -let j'ai trouvé ça (la méthodo est foireuse, je sais):Donc oui, ok, les buffer overflow et problèmes de mémoire existent, c'est indéniable, mais je trouve que c'est limite négligeable comparé au reste, d'une part en nombre, et d'autres part en facilité d'exploitation: encore une fois, amuses-toi a exploiter un buffer overflow, avec les symboles des lib partagées chargés à l'exécution au hasard… oh, justement!
Les lib partagées… rust, ça encourage pas le static linking, justement? Ça rend ce type de protection plus compliquées à mettre en place, j'imagine.
Et leur kernel, il supporte les mécanismes de type ASLR? Parce que sinon, rust c'est safe… lol?
Perso, j'ai rien trouvé.
Dans celles-ci (les failles de buffer de 2020), je n'en vois aucune liée à linux ou bsd (grep n'a rien trouvé). Donc, aucun noyau libre ici. Ça cause pas mal d'apple, mais difficile de dire si c'set le noyau ou… un serveur (redox: µkernel, tout plein de serveurs…).
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par mothsART . Évalué à 2.
Comme dis, je ne suis pas vraiment légitime pour ce genre de sujet car le dev niveau OS ne m'est pas familier et j'oriente peu ma veille autours de la sécu.
Sur tes mesures, j'ai compris dans les grandes lignes comment tu as pu ressortir ces chiffres mais est-ce qu'ils ont réellement une pertinence ?
J'ai regardé en rapide une dizaine de lignes sur du Denial of service et quand on lit l'origine du soucis, on voit que c'est lié à un buffer overflow donc du coup, ça fausse sans doute pas mal ta conclusion.
C'est pas parce qu'un langage protège de certaines failles qu'il protège de tout, on est bien dac.
La vrai question serait plutôt : est-ce que les garantis de sécurité de Rust qui ne sont pas disponible dans C sont suffisamment pertinentes pour le remplacer ?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-4701, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8249 et https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28575
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . Évalué à 4.
C'est déjà plus pertinent que de dire "y'a cette faille" sans mettre de comparatif à côté :)
Sinon: non, c'est pas pertinent, parce que ces chiffres sont bruts, on ne sait pas facilement si le système affecté est bien dans un OS précis (freebsd,openbsd, debian/kLinux, debian/kHurd, windows NT4, etc) ou par un logiciel tiers.
On ne sait pas non plus si les gens qui ont écrit le code s'en torchent ou pas, de la sécurité et de la stabilité, et je pense que le langage est largement secondaire comparé à l'outillage et les procédures mises en places pour gérer les bugs: analyse statique, preuve de coq pour les plus matheux, test unitaires, fuzzing, etc.
Hors, dans ce cas, on parle de jeter l'histo des correctifs de bugs de plusieurs centaines d'applications pour réimplémenter dans un langage qui lave plus blanc que blanc… enfin, c'est l'impression que ça me donne quand les gens en parlent.
Ajoutes la question: est-ce que les garanties qu'offre un langage non standardisé, ne disposant que d'une seule implémentation de compilateur, sont assez pertinente pour écrire un OS qui prétend remplacer les distributions GNU/Linux, et on aura un meilleur débat :)
Je t'avoues avoir juste grep le bloc… par contre, on reviens sur ce que je dis plus haut:
Redox-os embarque des outils en C, c'est dans le journal: netsurf. La différence, c'est qu'ici, netsurf est considéré comme partie de la distro, de l'OS. Ces outils peuvent peut-être aussi tourner pour redox-os, et si c'est le cas, comment le fait que la plupart de l'OS soit écrit en rust aide en quoique ce soit?
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . Évalué à 6.
Unix a était conçu avec un langage adhoc (tout neuf, non standardisé, une seule implémentation faite pour le projet lui-même).
Comme quoi ça peut chémar.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par freem . Évalué à 5.
C'est sûr, ça peut marcher (ça serait génial, que celui-ci marche: un OS avec un code tout propre, tout frais, à base de µkernel!). Ça donnait quoi, la concurrence à l'époque?
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par nokomprendo (site web personnel) . Évalué à 6.
C'est ce que fait Minix 3 : commencé en 2005, micro-noyau, recodé de zéro. Et il fait tourner les paquets NetBSD.
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par barmic 🦦 . Évalué à 9.
multics évidement le prédécesseur le plus direct d'unix, celui qui a inventé les fichiers, les arborescence et tout un tas de trucs repris par unix. Si linuxfr existait à l'époque, on aurait expliqué à Ken Thomson que ça sert à rien d'essayer de recréer un multics from scratch qu'en plus se lancer dans un nouveau langage alors qu'il y a déjà l'embarra du choix avec PL/1 (et ses alternatives), Fortran, lisp, COBOL,…
Après il y avait GECOS, IBSYS et un tas d'autres OS. C'est difficile de comparer 50 ans après, l'UNIX de l'époque n'était pas ce qu'on connaît aujourd'hui et je n'ai jamais vu tourner multics (mais son code a était libéré dernièrement).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: c'est vraiment la caractéristique numéro 1 ?
Posté par tisaac (Mastodon) . Évalué à 2.
Je crois que tu trouveras des infos de ce côté là.
Surtout, ne pas tout prendre au sérieux !
# Typos
Posté par Frédéric Blanc . Évalué à 4.
À mon avis, au lieu de :
c'est :
qu'on devrait lire.
[^] # Re: Typos
Posté par Davy Defaud . Évalué à 3.
C’est corrigé. Merci du signalement.
# Note pour les futurs webmester Redoxfr.org
Posté par woffer 🐧 . Évalué à 9.
Hey, les futurs webmester de redoxfr.org, n'oubliez pas d'y accoler GNU (GNU/Redox.org), sinon RMS ne voudra pas venir faire une interview !!!
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par gouttegd (site web personnel) . Évalué à 10.
Au-delà de la boutade, il est intéressant de noter qu’apparemment (d’après un rapide coup d’œil sur la documentation et les dépôts du projet) le système n’utilise pas, ni ne compte utiliser, l’userland GNU (rendant une appellation GNU/Redox totalement injustifiée). Le projet a en effet :
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par barmic 🦦 . Évalué à 10.
Ça me fait toujours très peur de voir des projets s'attaquer à un projet complexe et trouver le moyen de s'éparpiller sur un paquet de sujets. Pour des projets comme Haiku ça s'explique car c'est un écosystème qui existait déjà et qu'ils cherchent à maintenir. De plus l'ambition n'est pas de remplacer linux.
Il faut combien de temps pour stabiliser btrfs ou zfs ? Se lancer dans un autre FS, c'est s'acheter des soucis. Je n'ai aucun doute que c'est fait avec toute la bonne volonté du monde, qu'avec un couplage de dingue ils peuvent faire un truc super efficace, mais rester un peu concentré sur avoir un noyau me paraît de loin plus important.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par abriotde . Évalué à 1.
Autant je suis d accord sur le fait que ce soit inutile de trop s éparpiller autant je trouve que ce qu a fait Hurd est plus inutile que Redox.
Redox ne s attaque pas à Linux mais a OpenBSD ils ne cherchent pas a avoir tous les pilotes mais a avoir un os sécurisé.
Hurd cherche à reproduire un OS en partant avec 20 ans de retard et une équipe limitée tout ça pour éviter de migrer des applications…
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par nokomprendo (site web personnel) . Évalué à 8.
Heu non, Hurd c'est juste un noyau. Et le projet a débuté avant le projet Linux.
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par barmic 🦦 . Évalué à 8.
GNU a passé 7 ans à reconstruire un userland de 83 à 90 et en 90 ils se sont attaqué au dernier morceau qui leur manqué pour avoir un OS. La démarche est largement moins éparpillée. 30 ans après on peut les juger, mais avoir des concepts novateurs n'est pas déconnant pour se démarquer. L'équipe limité dont tu parle a commit des petites choses tel que qu'emacs ou gcc. Ils n'ont pas démarré de but en blanc tout un OS en commençant par les parties les plus compliquées.
Ça n'est pas mis en avant. A part si on fait du rust signifie ça ce qui n'est évidement pas le cas. C'est dis dans leurs objectifs, mais il y ai aussi dis qu'ils veulent être une alternative à linux. Ce qui est dommage je trouve dans cet optique, c'est que :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par tisaac (Mastodon) . Évalué à 3.
La sécurité est quand même un des arguments (que l'on peut débattre) souvent mis en avant comme avantage des architectures microkernel versus monolithique, non ?
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par barmic 🦦 . Évalué à 2.
C'est pas faux. J'entends souvent ça pour la résilience, mais c'est vrai. Par contre j'ai pas encore tout lu sur le sujet mais le tout est URL fait plutôt peur pour la sécurité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par Renault (site web personnel) . Évalué à 8.
Je pense qu'on se trompe de débat. Une architecture micro-noyau et l'usage de Rust permettent de limiter certains types d'erreurs ou d'attaques, mais c'est loin d'être suffisant pour dire que leur adoption implique une meilleure sécurité par essence.
La sécurité, c'est un peu comme la performance, c'est transversale dans le projet. Et en plus c'est un sujet assez complexe qui évolue vite, donc faire les choses bien demandent surtout beaucoup d'expérience et de moyens pour les mettre en œuvre.
Si Linux part avec un handicap de ce côté à cause de sa conception et du langage C, il a eu pas mal de fonctionnalités pour contrer ces faiblesses et pour apporter des protections plus complexes. Puis le langage C malgré ses défauts a pas mal d'outils au point pour détecter les erreurs les plus courantes et certaines failles potentielles. Dont les compilateurs qui sont de plus en plus rigoureux à ce sujet. Le recul avec le C est important. Et globalement les développeurs du noyau ont quand même une certaine expérience et s'ils font des erreurs comme tout le monde, ils n'incluent pas des failles à chaque ligne ajoutée non plus.
Donc si la sécurité de Redox OS repose sur Rust et l'architecture micro-noyau, cela ne signifie absolument pas qu'il soit plus sécurisé à utiliser que le noyau Linux en l'état actuel.
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par abriotde . Évalué à 2.
Tu as raison sur tout mais il n empêche que partir d une base plus sécurisé donne un avantage. Et à terme si redoxos se développe suffisamment pour avoir de bonnes ressource il pourra offrir une meilleure sécurité à moindre coût.
Actuellement il est sécurisé plus par le fait qu aucun virus existant ne s zttaque à ses failles. Tout comme Linux il y a 20 ans ;)
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par Cactus . Évalué à 3.
Il y avait déjà des virus Linux en 2000…
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par zimoun . Évalué à 2.
Tout à fait d'accord. Surtout que Rust n'est pas bien loti pour toutes les attaques type Trusting Trust : le compilo est difficile à bootstrapper, avec une taille de graine non-négligeable et il n'y a pas beaucoup d'implémentations pour faire du Diverse Double Compilation. Entre autres.
En revanche, avoir plusieurs noyaux sur lesquels on pourrait compiler le noyau linux permettrait d'appliquer les principes de DDC sur linux lui-même et donc renforcer sa sécurité. ;-)
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par freem . Évalué à 6.
Tu veux dire que cargo est vulnérables aux mêmes problèmes que npm? Hop moi…
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par lym . Évalué à 1.
Les outils d'analyse de code C permettent en effet de compenser les avantages de conception de Rust, en évitant en prime de devoir cumuler (au niveau logiciel de base) la complexité de la machine (un processeur/SoC actuel) avec celle du langage (devoir en particulier en permanence s'embêter avec les problèmes d'appartenance).
Je n'ai pas étudié l'affaire de très près, ceci dit, mais vu de haut je vois plus Rust utile côté applicatif que pour coder un système d'exploitation voir ses modules/drivers.
Ce ne serait pas le 1er challenger du C de l'histoire à échouer!
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par abriotde . Évalué à 1.
Les outils d'analyse de code C sont bien mais sont plus de l'ordre du patch. Ou du moins permette juste de faire un peu mieux mais pas aussi bien que Rust.
Quant à l'argument que coder en Rust serait plus complexe qu'en C, permet moi d'en douter. C/C++ est loin d'être simple avec ses instructions pré-processeur entre autre… Par contre un programmeur habitué ne réfléchi pas vraiment aux complexitées du langages. Il en est de même pour Rust et les "problèmes d'appartenance". C'est un problème de débutant.
Rust est clairement mieux que C. Et en tant que successeur (plus que remplaçant) il a déjà été beaucoup plus loin que les autres prétendants. La seul question qu'on peut se poser, c'est : est-il raisonnable de tout recoder pour autant? Je n'ai pas la réponse.
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par lym . Évalué à 1.
Comme précisé, je ne suis pas allé très loin dans l'examen car j'apprécie vraiment la liberté laissée par le C. Et là je n'ai d'entrée pas trouvé mon compte pour du soft plateforme/bas niveau: La rapport bénéfice/emmerdement ne me parait pas positif.
Maintenant, pour de l'applicatif actuel (surtout en frontal avec l'extérieur) ou des ajouts du langage seront utiles (apports thread/reseau) autant que, par construction, limiter les erreurs possibles quasiment aux seules fautes de logique du programmeur, au bénéfice de la sécurité/fiabilité: OK, d'ailleurs Mozilla n'a-t'il pas crée ce langage exactement pour cela?
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par claudex . Évalué à 5.
Je suis d'acccord, mais développer ses propres outils, ça permet aussi d'avoir plus de liberté dans les interfaces et donc d'avoir un système qui n'apportera peut-être pas grand chose par rapport à l'existant. Par exemple, si tu prends les gnu coreutils, tu vas être très restreint et les modifier pour t'adapter va être plus compliqué que d'écrire un truc de 0.
Par contre, il faut aussi savoir se rendre compte qu'au final, les outils ne sont pas très différent de l'existant et merger les modification dans l'existant. Mais je pense que pour l'expérimentation, c'est un plus (surtout si on ne vise pas uniquement la compatiblité posix).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par Zenitram (site web personnel) . Évalué à 2.
En fait, déjà la licence (libre) le ferait hurler (trop libre pour lui).
[^] # Re: Note pour les futurs webmester Redoxfr.org
Posté par tisaac (Mastodon) . Évalué à 0.
La licence trop libre : de LinuxFR ou de Redox-OS ou les deux ?
Au minimum, celle de LinuxFR, non ?
Surtout, ne pas tout prendre au sérieux !
# Pourquoi faire ?
Posté par Jean-Baptiste Faure . Évalué à 6.
Je suis surpris que cette dépêche n'expose pas clairement le diagnostic, l'analyse du marché des OS qui ont conduit les promoteurs de ce projet à se lancer. Ou alors c'est juste pour le fun, pour voir si on est capable de le faire ? Évoquer seulement un caractère prétendument plus sécurisé sans plus de précision, je trouve ça un peu court.
[^] # Re: Pourquoi faire ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 10.
Hello,
Pour moi, cette dépêche est très bien: elle parle d'un sujet autour du libre et, en plus, nous fait découvrir un petit projet très intéressant.
On découvre d'ailleurs régulièrement passer ce bandeau sur la page d'accueil:
C'est des nouvelles faites par la communauté et pour la communauté, nous n'avons pas de vocation à faire des articles totalement objectifs et de qualité journalistique 😉
Pour plus d'informations, voire la page à propos.
[^] # Re: Pourquoi faire ?
Posté par tisaac (Mastodon) . Évalué à 8.
En fait, implicitement, j'en parle dans le passage suivant de la dépêche :
En fait, pour moi, c'est pas hyper clair pourquoi il faut vraiment développer ce nouvel OS. Sur le site de Redox-OS, ils développent un peu les raisons d'un nouvel OS et on y trouve cette phrase assez explicite:
Après, même si je regrette régulièrement la balkanisation des projets dans le monde du libre, cela reste une motivation légitime (même si certains la trouveront futile).
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Pourquoi faire ?
Posté par freem . Évalué à 3.
C'est la meilleure des motivations, et un excellent moteur pour faire du code de qualité. Quand on se fait chier, on est moins concentré, et la qualité s'en ressent. Hors, faire du code de merde ultra-sécurisé, moi, je n'y crois pas une seule seconde.
[^] # Re: Pourquoi faire ?
Posté par Jean-Baptiste Faure . Évalué à 6.
Merci pour la réponse.
Autant ce type de motivation me parait tout-à-fait légitime pour se lancer dans un tel projet, autant ça me parait insuffisant pour convaincre d'autres développeurs d'y participer, par exemple pour développer les pilotes nécessaires.
# Pas de pilotes...
Posté par rewind (Mastodon) . Évalué à 6.
J'ai bien été convaincu par les arguments qui disent que ça ne marchera pas. Beaucoup moins par ceux qui disent que ça marchera (qui me semblent plus relever de la méthode coué).
Ceci dit, le principal inconvénient, noté dans la dépêche, c'est qu'il n'y a pas de pilotes. C'est un peu le point faible de tous les noyaux alternatifs, c'est qu'ils ne s'intéressent qu'à la structure du noyau. Mais un noyau, pour être utilisé, doit avoir des pilotes sinon il ne sert à rien. Plutôt que de réinventer la roue carrée en userland, il serait sans doute beaucoup plus pertinent d'ajouter des pilotes.
[^] # Re: Pas de pilotes...
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
Ce que je ne comprends pas du tout est que le "pas de pilote" n'est pas du tout un problème si l'OS visait à supporter les hyperviseurs avec l'usage de virtio qui propose des belles performances.
Il y a un marché pour un OS plus petit que Linux pour fonctionner dans des VM, surtout si il est rapide et sécurisé.
Pour ce genre d'usage, il faut une compatibilité Posix et une pile IP en béton.
"La première sécurité est la liberté"
[^] # Re: Pas de pilotes...
Posté par gouttegd (site web personnel) . Évalué à 4. Dernière modification le 08 décembre 2020 à 12:34.
Un système d’exploitation conçu pour ne fonctionner que dans des VM peut-il encore être qualifié de « système d’exploitation » ?
Dans toutes les définitions usuelles de « système d’exploitation », on trouve l’idée que l’OS sert d’« intermédiaire entre le matériel et les logiciels », « gère les ressources matérielles », ou plus généralement « permet l’utilisation d’un ordinateur »…
Un « OS pour machine virtuelle » est sans doute un exercice intéressant et c’est peut-être même utile, mais s’il dépend entièrement d’un « vrai » OS sous-jacent pour faire tout le boulot difficile, je trouve ça un peu gonflé d’appeler ça un « OS » et de le comparer à Linux, BSD & Co.
[^] # Re: Pas de pilotes...
Posté par claudex . Évalué à 5.
Ça reste les mêmes contraintes qu'un OS classique, il y a du matériel (virtuel) à gérer et tout l'userland. Il ne me semble pas que des gens font une distinction entre un Linux qui tourne dans une VM et un Linux qui tourne sur du matériel (avec dans certains cas tellement de boulot fait par les firmware ou autre trucs connectés que ce n'est pas très différent d'une VM).
Sinon, ce n'est pas parce qu'un OS peut être utile dans une VM qui ne développera pas pour du matériel pour après, c'est juste que dans un premier temps, il peut avoir une utilisé avec un nombre de driver limité. C'est une différence par exemple avec Haiku qui ne me semble pas pertinent en VM (sauf pour du test ou développement1) (c'est mon point de vue, je peux me tromper).
Ou du VDI mais je n'ai pas encore vu d'offre qui l'incluait :) ↩
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas de pilotes...
Posté par barmic 🦦 . Évalué à 5. Dernière modification le 08 décembre 2020 à 14:01.
Et c'est de plus en plus faux, il y a une couche de plus en plus présente sous l'OS est-ce que tu pense que ça les dénatures ? C'est un logiciel qui permet d'exploiter une machine, le fait que cette machine soit virtuelle ne me semble pas changer la nature du problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas de pilotes...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
On aime bien les couches… Disons que sur le marché, les 2 trucs moyen mature, c'est l'OS dédié pour les VM (lancement rapide de function lambda par exemple, démarrage rapide d'un truc type k8s) et l'OS pour iot pour les trucs trop petit pour Linux (en gros <4Mo de RAM).
"La première sécurité est la liberté"
[^] # Re: Pas de pilotes...
Posté par orfenor . Évalué à 2.
Je n'en connais pas d'autres que des Linux allégés. Si tu as des exmples, ça m'intéresse.
[^] # Re: Pas de pilotes...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
cf https://fr.wikipedia.org/wiki/Unikernel
"La première sécurité est la liberté"
[^] # Re: Pas de pilotes...
Posté par Psychofox (Mastodon) . Évalué à 5.
@imil a fait une démonstration de comment le faire à partir d'une netbsd:
https://imil.net/blog/posts/2020/fakecracker-netbsd-as-a-function-based-microvm/
Le principe est le même quelque soit le type de noyau, supprimer tout support matériel autre que les éléments virtualisés et éventuellement bypasser l'ordonnanceur typique pour ne lancer que l'executable demandé.
Il n'y a pas forcément besoin de recréer un OS ou forker un OS existant.
[^] # Re: Pas de pilotes...
Posté par nokomprendo (site web personnel) . Évalué à 5.
Oui, si j'ai bien compris, c'est ce que font les unikernels comme MirageOS.
[^] # Re: Pas de pilotes...
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Oui, c'est ça. Même si j'ai du mal à comprendre comment un langage à GC peut faire un kernel.
"La première sécurité est la liberté"
[^] # Re: Pas de pilotes...
Posté par tisaac (Mastodon) . Évalué à 2.
nokomprendo, Nicolas, n'hésitez pas à creuser ces questions et à aider Dinosaure à avancer dans sa dépêche sur MirageOS :-)
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Pas de pilotes...
Posté par nokomprendo (site web personnel) . Évalué à 3.
Merci pour l'info. Perso, je ne connais pas bien le sujet mais j'essaierai d'y regarder.
[^] # Re: Pas de pilotes...
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Il y a eu des OS Java.
Ce n'est pas idiot de mettre le GC au niveau de l'OS non? On peut voir la mémoire comme une ressource partagée gérée automatiquement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de pilotes...
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Oui, mais comment tu écris le GC ? Dans ce genre de langage, le GC est écrit en C et utilise des appels systèmes à l'OS pour avoir de la mémoire. Linus n'aimait pas C++ surtout à cause des allocations mémoires un peu caché (passage de structure par valeur).
Comment écrire le bout de code de gestion mémoire dans de tel OS ? Avec un sous-langage bridé ? Mais l'absence d'allocation est souvent demandé (gestion d'exception, contexte d'interruption, …)est-ce que l'on ne risque pas d'avoir un deuxième langage à gérer en plus du premier ?
"La première sécurité est la liberté"
[^] # Re: Pas de pilotes...
Posté par devnewton 🍺 (site web personnel) . Évalué à 7. Dernière modification le 09 décembre 2020 à 11:12.
Avec un langage qui permets à la fois une gestion manuelle et une gestion automatique selon le contexte ?
Après tout on fait bien ça en C: il y a des contextes où on ne peut pas faire un malloc :(
Ca me rappelle que sous PalmOS, la mémoire allouée pouvait bouger et qu'on était obligé de la verrouiller avant usage!
https://www.codeproject.com/articles/3154/the-palm-memory-manager-api
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas de pilotes...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Idée récupérée des premières versions de Mac OS, d'ailleurs. Ça permettait de défragmenter la mémoire, bien utile sur ces systèmes ou il n'y a pas de MMU.
Et effectivement ça se fait beaucoup mieux dans un langage qui utilise peu ou pas du tout de pointeurs (Pascal à l'époque, mais Java peut convenir aussi) que avec du code C ou on est jamais sûr de qui pointe sur quoi (et on laisse donc les développeurs d'applis se débrouiller tout seuls pour locker et délocker à la main des morceaux de la mémoire).
En tout cas je ne vois pas ce qui empêcherait d'écrire un garbage collector en Java. Il faudra forcément un bout de code bas niveau pour intéragir avec le matériel (dire au MMU d'allouer de la mémoire physique, par exemple), mais toute la gestion de quelle mémoire est allouée à qui peut tout à fait se faire en Java, pourquoi pas?
Au passage il faut rappeler que Java peut aussi être un langage compilé. Et que la machine virtuelle Java n'est jamais qu'un CPU virtuel assez simple et qui peut servir à tout autre chose que faire du Java. On peut le programmer en assembleur java bytecode si on veut.
# micro-noyau
Posté par karteum59 . Évalué à 10. Dernière modification le 08 décembre 2020 à 13:06.
Mouais…
[^] # Re: micro-noyau
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 08 décembre 2020 à 13:33.
Et y'a Fuchsia chez Google qui est en production sur certains de leurs produits (pas pour remplacer Android, mais sur certains de leurs gadgets connectés il me semble).
Sans compter le prédecesseur "lk", qui est un micronoyau (sans OS autour) utilisé à plusieurs endroits pour le même genre de choses.
[^] # Re: micro-noyau
Posté par cosmocat . Évalué à 5.
J'ai tické sur la même phrase et j'allais donner cet exemple jusqu'à ce que j'aille vérifier et lise:
Source : https://en.m.wikipedia.org/wiki/Google_Fuchsia
[^] # Re: micro-noyau
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4.
La source du passage que tu cites ne mentionne rien à propos de micro-noyau ou de syscalls, elle a dû être modifiée depuis. Cela dit, sur le site officiel de Fuschia, on trouve ceci :
[^] # Re: micro-noyau
Posté par cosmocat . Évalué à 5.
Modifié il y a 2h… C'est un complot!!!! :D
[^] # Re: micro-noyau
Posté par Claude SIMON (site web personnel) . Évalué à 6.
À l'époque, il y avait aussi l'AmigaOS…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# pas une alternative a linux, et ne le sera jamais...
Posté par freem . Évalué à 10. Dernière modification le 08 décembre 2020 à 14:18.
Parce que linux, c'est un noyau.
La, les mecs font juste la même chose que GNU, 30 ans après, avec un langage tout frais (la ou le C avait déjà de la bouteille et essuyé des plâtres j'imagine), et ce, en vrac (déjà été dis mais peu importe).
À côté de ça, linux, c'était "juste" un noyau, Linus Torvalds ne s'est "pas fait chier", il a repris l'existant. Beaucoup.
Je pense que tout est dis ici: d'un côté, la réutilisation de l'existant, le pragmatisme, de l'autre, l'idéal théorie et le NIH.
Au fait, j'ai un scoop: les failles de sécurité les plus faciles à exploiter… c'est pas les buffer overflows, ce sont les injections de code et les déni de service (un jeune de 16 ans peut exploiter ce type de failles).
Et c'est pas côté kernel, mais userland. C'est bien d'avoir un noyau et des outils de ligne de commande en béton armé (contre les problèmes de mémoire uniquement je suppose, pas contre les bugs fonctionnels, qui sont bien plus délicats à repérer), mais ce qui est important pour un serveur ou une machine embarquée, ce sont les daemons. Pour une machine de bureau, c'est l'interface graphique qui marche pour de vrai, l'accès au web (d'ailleurs, netsurf qu'ils embarquent n'est pas codé en rust) qui supporte le
bloatjavascript, une suite bureautique et la performance (parce que le jeu vidéo fait aussi partie des usages importants).Bref. On peut faire une distribution autour de linux en utilisant les outils gnu, le navigateur web de mozilla et le bureau KDE. C'est ça, la force des distros GNU/Linux: le bazar.
Ce nouvel OS aura: moins de développeurs que les devs des BSD (un langage moins répandu), moins d'outils (parce qu'il faut du spécifique rust à tous les coups) et pas de support matériel (parce que si c'était si facile, ça ne serait pas aussi galère sous linux, et si un µkernel étais la panacée, GNU/Debian/kHurd serait stable).
Zut, on est pas vendredi.
Pour contrebalancer un peu tout ça: je pense que c'est bien. J'aime énormément l'idée des µkernels perso, et si j'avais plus de motivation, je bricolerais bien avec hurd. En faire un en rust? Pourquoi pas.
Dommage de vouloir faire l'OS complet, par contre, mais bon, on a le droit de faire son «pet project» :)
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par mothsART . Évalué à 6.
L'injection de code sur du compilé, je demande à voir.
Le DDOS c'est une problématique réseau, je vois pas le parallèle avec un OS.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par freem . Évalué à 1.
Ça se fait, pourtant, c'est justement une des charges utiles pour exploiter un buffer overflow.
Un OS qui ne fournit aucun service réseau n'est bon que pour les chiens et autres charognards de nos jours.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par mothsART . Évalué à 2.
Pour moi, c'est plus des instructions machines que t'injectes mais bon, je m'amuse pas a exploiter des buffers overflow tous les 4 matins donc j'ai sans doute des lacunes dans le domaine.
Je pense que la grande majorité des soucis (ou en tout cas des exploitations) DDOS ne sont pas lié à l'OS mais aux applicatifs, à leur mise en place et config.
Si c'est lié à l'OS, il faut déjà que l'attaque soit orienté vers ce dernier en particulier.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par freem . Évalué à 4.
Je ne suis pas non plus expert, mais bon, faire appeler la fonction
system()à un processus (qui ne l'appelle jamais dans le code) en se démerdant pour lui passer la bonne commande, c'est bien une injection de code, non?Concrètement, les injections de code, c'est rendu possible par la mauvaise gestion de l'entrée. Que ça soit un buffer overflow ou "un simple oubli d'assainir", c'est la même chose: on détourne l'exécution.
À noter que, il y a peut-être un point sur lequel rust encourage de manière effective la sécurité à ce niveau: il encourage l'édition de liens statique, donc on ne peux pas exploiter LD_PRELOAD :p
Mais moi aussi.
Sauf que moi, je ne précise pas "DDoS". Juste, la grande majorité. Combien de failles font partie de l'OS, comparé au nombre de failles provenant d'une application tiers?
Et quelle est la complexité des services rendus par l'OS quand c'est le cas? Parce qu'un windows qui expose un AD, il ya de bonne chances qu'il soit troué, oui. Par contre il permets un partage de fichiers et d'imprimantes simple à utiliser et administrer (comparé à du FTP/http/NFS, notamment grâce aux ihm), la synchronisation des horloges, des utilisateurs, des configurations système (avec les GPO)!
Et dans tout ça, les failles que je lis dans Misc (parce que le sujet m'intéresse un peu, donc quand je prend le train j'essaie de prendre un misc magazine pour la route, même si le niveau est trop haut pour moi, je comprend quelques trucs et j'apprend beaucoup) sont pas nécessairement des buffer overflow ou des problèmes de C, mais bien des problèmes de configuration par les admins!
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par octane . Évalué à 4.
bin, system(machin) au hasard. ou n'importe quoi qui manipule un autre truc et qui le parse mal.
et encore une fois, les vulns les plus critiques sont souvent orthogonales au langage. VNC s'est fait trouer pendant longtemps. Pourquoi? Tu peux choisir (protocolairement) le mode d'authentification. La faille: tu envoies ton login (admin), et tu dit que tu n'as aucun mode d'authentification. Le serveur disait, oui d'accord, on valide le login sans authent puisqu'il n'y en a pas. Code compilé, bug logique -> drame. Le RUST ou le C ou le java ou l'asm pur n'aide pas dans ces situations.
après pour revenir à l'injection de code sur du compilé, si tu entends de l'exploitation mémoire, il y en a encore qui existe. Il y a pleins de challenges on-line qui permettent de t'entrainer à l'exploiter de manière propre avec et sans fonctions de sécurité (ASLR on/off, canary ou pas, code pie ou pas, avec leak ou pas, etc…)
déni de service c'est pas tout à fait pareil qu'un DDOS. Et du déni de service en local, ça se fait.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Yth (Mastodon) . Évalué à 2.
Le déni de service n'est pas une faille de sécurité.
C'est un blocus de camionneurs sur l'autoroute, une grève pas l'occupation des locaux, installer des tentes sur la voie ferrée pour empêcher les trains de partir, etc.
Le service n'est plus rendu, mais il n'y a pas eu de faille de sécurité, l'intégrité du service et de ses données n'est pas engagée.
Ne mélangeons pas tout !
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par claudex . Évalué à 8.
Cela dépend de ce que tu inclus dans la sécurité, mais pour moi le déni de service fait partie des problèmes de sécurité. La sécurité, ce n'est pas uniquement la sécurité des données. Si tu ne peux pas envoyer de mail pendant 15 jours, tu vas quand même pas mal galérer1. Prenons l'actualité, une société de vaccins qui ne peut pas communiquer avec ses usines parce qu'elle subit un DDoS.
Imaginons un site qui expose un bouton poweroff qui éteint le serveur, c'est clairement une faille de sécurité pour moi, mais c'est déni de service.
Après il y a aussi la frontière plus floue où le DDoS va permettre d'utiliser une faille, ou surtout, de cacher une attaque.
Je suis bien d'accord que ce n'est pas une attaque envers l'intégrité des données.
En plus, tu risque de mettre à mal tes données en utilisant des solutions alternatives. ↩
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par freem . Évalué à 5.
Ralentir la cible pour pouvoir répondre avant elle aux messages légitimes, aussi.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par orfenor . Évalué à 3.
Ou ralentir la cible pour utiliser les failles de sécurité avant qu'elle soient corrigées.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Yth (Mastodon) . Évalué à 4.
Mais tout ça ne fait pas du (D)DoS une faille de sécurité en tant que telle.
Ça en fait une attaque, et une attaque affaiblit toujours un peu sa cible, permettant parfois à une autre attaque d'atteindre sa cible.
Une faille c'est un moyen d'atteindre ta cible sans avoir à profiter d'un affaiblissement lié à une attaque massive.
Le gros bouton ON/OFF accessible est une fonctionnalité, pas une faille, si il a été mis là c'est probablement pour une bonne raison. Sinon c'est qu'on a affaire à des bras cassés, et des failles il y en a probablement des douzaines encore plus faciles à exploiter…
Un système sans failles peut quand même tomber, être spoofé, être l'objet de phishing, ou d'arnaques en tout genre.
Ça n'en fait pas des failles de sécurité, même si ça reste des problèmes graves pour lesquels on peut mettre en place des mesures.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Pour un système "safety critical", la disponibilité est plus importante que la sécurité des informations. (système d'hôpitaux, gestion d'appel d'urgence, avion, train, …)
"La première sécurité est la liberté"
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par claudex . Évalué à 5.
Alors, justement, du DoS, ce n'est pas une attaque massive. Et du DDoS ne demande pas forcément d'être massif. On ne parle pas de protéger la première boulangerie venue d'une attaque de plusieurs Pbps.
C'est évidemment une exagération mais ce genre de truc accessible, ça arrive.
Pas forcément plus facile à exploiter.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Yth (Mastodon) . Évalué à 5.
Mais en fait, pour faire un DoS, en pratique il faut exploiter une faille, et le symptôme est un déni de service.
Comment tu fais tomber un service avec une attaque simple si tu n'exploite pas une faille dans le service ?
Alors qu'un DDoS c'est autre chose : tu satures le service rendant impossible d'y accéder pour les gens. C'est 2500 personnes qui font la queue à la gendarmerie pour porter plainte contre une vache, et toi qui veut signaler le vandalisme sur ta voiture, ben tu peux pas.
Bref, on joue sur les mots un peu, mais je classifierait plutôt les (D)DoS comme des types d'attaques plutôt que des failles…
Ce qui n'empêche pas de chercher des solutions pour s'en prémunir, mais ces solutions ne sont pas liés à la sécurité intrinsèque de tes outils, ou à la présence ou non de failles logicielles.
Plutôt à l'organisation de ton réseau. Et c'est relativement indépendant des OS sous-jacents.
Bon, inutile de pinailler plus, ça ne fait pas tellement avancer le schmilblick…
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par kna . Évalué à 4.
Avec une attaque type slowloris par exemple.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
(digression)
https://en.wiktionary.org/wiki/molly-guard
(traduction rapide) à l'origine, une protection improvisée en plexiglas sur le Gros Bouton Rouge du gros serveur IBM 4341 après que la fillette d'un programmeur, nommée Molly, ait appuyé dessus deux fois en une journée.
ou encore le paquet
molly-guardqui oblige à donner le nom d'une machine avant d'avoir le droit de la redémarrer (pour éviter de se tromper de fenêtre si on a des SSH ouverts sur 42 serveurs par exemple) :[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par claudex . Évalué à 7.
Paquet que j'aurais bien aimé d'avoir installé sur une machine distante une fois…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par orfenor . Évalué à 4.
Dans les annés 90, j'ai réveillé un collègue à 5h du matin parce qu'il avait accès physiquement au bouton On/Off pour redémarrer un serveur qui se trouvait de l'autre côté de l'atlantique. Il l'a très bien pris, il avait fait la même bêtise quelques jours plus tôt.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Pol' uX (site web personnel) . Évalué à 7.
Ça c'est la conf par défaut, pédante mais pas très utile. Mais on peut faire des truc géniaux avec Molyguard, par exemple avertir que cette machine nécessite une procédure particulière de reboot, mentionner l'url de la doc, et exiger avant de poursuivre la saisie d'un secret qui témoigne que la personne a parcouru la doc. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par octane . Évalué à 3.
a partir du moment ou tes données ne sont plus accessibles, on peut dire que c'est un problème de sécurité, non?
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 09 décembre 2020 à 14:54.
je pense que l'incompréhension vient du terme faille. Un Dos est un problème de sécurité mais ce n'est pas une faille qui permet de faire de la pénetration.
[^] # Re: pas une alternative a linux, et ne le sera jamais...
Posté par octane . Évalué à 2.
Kevin Mitnick a fait un Dos sur une machine, lui permettant de se connecter en root sur sa cible (une autre machine, certes).
ensuite, est-ce que toutes les failles sont de l'intrusion? quand sur mon site web marchand j'achète une chemise à 50€ et que j'ajoute -10 chaussettes à 5€ pièce, je paye 0€. Pas de pénétration, mais une faille quand même, je dirais.
# Orbtk
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Est-ce que Orbtk permets de faire une application graphique sans dépendance à un autre toolkit ?
Ils sont bien rare ceux qui ne dépendent pas d'un toolkit en C (Qt, Gtk ou TK).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Orbtk
Posté par mothsART . Évalué à 3.
Oui, à priori ça permet de faire une appli graphique sans toolkit en C.
C'est cross-plateforme et ça s'appui sur https://github.com/jrmuizel/raqote
Dans la liste des GUI supportés en Rust https://www.areweguiyet.com/, t'en as quelques une qui sont en pure Rust : Azul et druid par exemple. Le reste c'est en effet des bindings C.
[^] # Re: Orbtk
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Est-ce que l'on a une idée de tendance sur ces différentes toolkit :
- Ceux qui respecte la façon "rust", typiquement pas d'objet que l'on retrouvera dans les mapping de Qt.
- utilisation du pattern entity-composant-system qui donne les meilleurs perfs et qui permet le multithreading (perf x10 dans unity3D !)
- utilisation du pattern "redessiner le monde" mais optimiser à mort comme dans React (API très simple, mais code rapide),
- voir utilisation des hooks de React qui sont vraiment top.
"La première sécurité est la liberté"
# Petit point d'histoire sur les circonstances
Posté par orfenor . Évalué à 10.
Linux est vraiment arrivé au bon moment :
Et puis il y avait la doc.
La doc GNU, les tutoriels, les how-to… fleurissaient partout, tandis que pour Sun ou Digital on devait se contenter des docs officielles. Quand la poste américaine a installé des trieurs de courrier sous Linux (un kernel pré 0.99 en 1993 je crois) le mode d'emploi a circulé. Très vite des livres sont parus sur Linux.
Et l'effet communauté entraînée par des gens nouveaux
C'était un gros changement les communautés faciles à rejoindre, dans l'enthousiasme du projet à construire (tandis que les BBS demeuraient peu accessibles et centrés sur les jeux). Pour ceux qui l'ont oubliée, l'annonce de Linus était enthousiasmante (« vous souvenez-vous quand les hommes étaient des hommes et écrivaient leur propre système ») et quand il a coupé la chique à Andrew Tannembaum c'était les mots d'un leader en paroles, en actes et en savoir. Donc il y avait ce jeune type à suivre, dans la même cour que Richard Stallman et Tim Berners Lee, un tas de projets à inventer sur internet, face à un type détesté : Bill Gates, qui voulait nous enfermer dans son monde d'argent, de licences, de système plantogène et d'internet privé à la Compuserve.
Même les dates tombaient bien. C'était peu avant l'an 2000, on allait bâtir le monde de science-fiction des magazines.
Je suis sûr que BeOS a eu autant de retentissement à cause de ces mêmes circonstances.
Il y en certainement d'autres que j'oublie, mais je crois que ce sont les circonstances qui ont favorisées Linux, le contexte est différent, je ne vois pas trop quel enthousiasme semblable pourrait susciter RedoxOS. La conquête de Mars peut-être ?
[^] # Re: Petit point d'histoire sur les circonstances
Posté par Jean Parpaillon (site web personnel) . Évalué à 10.
Je suis entièrement d'accord: le succès d'une technologie dépend presque entièrement des circonstances (économiques, culturelles, etc) et non pas de ses qualités techniques intrinsèques (cf. Windows 3.x vs NEXTstep/Geoworks/OS-2/BeOS/etc)
Ceci dit, ces circonstances sont assez nombreuses et inconnues pour ne pas fermer la porte au succès d'un nouvel OS même si, pour un noyau comme Linux, il a quand même fallu attendre 7 ans pour la première tentative d'OS grand public (Mandrake) et plus de 25 ans pour le premier déploiement massif grand public, avec la première release d'Android.
Pour les serveurs, l'intérêt de Linux pour les serveurs est venu beaucoup plus tôt, mais avec également beaucoup plus de concurrent, l'adoption massive de Linux sur les serveurs a quand même mis un peu de temps.
A-t-on besoin de RedoxOS ? Je pense que personne n'a la réponse (en 1991, on n'avait pas besoin d'un OS pour smartphone…).
A-t-on besoin de nouveaux OS ? Je suis convaincu que oui, à cause d'une expérience récente. Après avoir utilisé exclusivement Linux depuis 20 ans et Debian quasi-exclusivement, j'ai voulu tester SmartOS (version allégée de OpenSolaris, et dédiée à l'hébergement de services) il y a quelques mois. J'ai été alors frappé à quel point je m'étais habitué aux défauts de Linux. Cela m'a presque rappelé mon incompréhension face aux utilisateurs de Windows qui prétendaient utiliser un "bon OS" juste parce qu'ils avaient appris à gérer ses défauts.
J'avais donc oublié qu'un OS pour serveurs sert à gérer un CPU, du stockage (volatile et persistent) et du réseau… et c'est tout. Et quelle surprise de découvrir qu'un OS pouvait proposer pour cela (je simplifie à peine) 3 commandes: une pour CPU/RAM, une pour le stockage (zfs) et une pour le réseau. Tout cela, bien sûr avec une doc à jour, cohérente. Du coup, difficile de revenir en arrière… Moi qui était persuadé que Debian était bien parce que documenté (tout bon package doit contenir sa manpage, même si pas à jour), simple (pour démarrer un service, on avait
/etc/init.d/...et puisinvoke-rc.det puis aussisystemctlet puis… et puis…), qu'il intègre LVM (hum, alors par-dessus dm, ou tout seul ? Et puis quel FS au-dessus ?). En fait, non, on peut faire beaucoup mieux.Donc, oui, je pense qu'il y a clairement de la place pour de nouveaux OS, mais ce n'est pas forcément évident de savoir quelle technologie pourra vraiment marquer une différence à l'usage. Donc, bon courage à RedoxOS, surprenez-nous :)
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Petit point d'histoire sur les circonstances
Posté par tisaac (Mastodon) . Évalué à 7.
Cela ferait un bon sujet de dépêche, non ?
On ne peut que t'y encourager ;-)
Surtout, ne pas tout prendre au sérieux !
# a 99th one more
Posté par tkr (Mastodon) . Évalué à -6.
à en voir les commentaires de cette page, on comprend immédiatement pourquoi les systèmes libres non embarqués resteront à jamais de niche et n'auront l'attention des geeks/nerds ad vitae eternam :
un débat énorme, où tout un chacun amène sa science
la science de chacun est supérieure à celle de l'autre
un système d'informations concu par de geeks/nerds/hackers pour les g/n/h. Period.
Et comme le résume une image du xkcd l'illustre à merveille, ce projet sera sans doute un graal pour des ingénieurs ultra-spécialistes, mais un projet cauchemardesque pour le grand public, qui suscitera inévitablement incompréhension et interrogations des passionnés :
[^] # Re: a 99th one more
Posté par freem . Évalué à 4.
Linux. Le monde est peuplé en majorité de geeks \o/ (enfin, pour ceux qui ont un smartphone)
# À propos du nom Redox
Posté par xavier philippon . Évalué à 4.
C'est étrange que le nom du projet n'ai fait réagir personne.
Redox, c'est un diminutif d'oxydoréduction. C'est un clin d’œil appuyé à Rust qui veut dire rouille ou oxydation.
Du coup, je vois cet initiative comme un "proof of concept" en faveur de Rust. C'est au départ, un exercice de style qui pourrait devenir un véritable OS.
# Redox OS 0.6.0
Posté par tisaac (Mastodon) . Évalué à 2.
Depuis la publication de cette dépêche, une nouvelle version de Redox est sortie.
Surtout, ne pas tout prendre au sérieux !
# Flatpack vs sécurité
Posté par tao popus . Évalué à 1.
https://flatkill.org/
Et ça a tendance à pousse certains développeur d'applications à pousser vers Flatpak, plutôt que de résoudre les problèmes complexes d'architectures systèmes hétérogènes. C'est bien pratique pour dépanner d'avoir une solution temporaire qui assure un bon fonctionnement, mais ça ne devrait pas être une finalité. On va se retrouver, comme c'est la tendance avec le monde d'Electron avec n copies des mêmes bibliothèques sur le disque du système, et autant en mémoire, dans un monde qui a de plus en plus besoin de sobriété.
Sinon, article très intéressant, belle découverte, merci. Au pire si ça n'est pas beaucoup utilisé, les développeurs auront eu une expérience intéressante, et certaines innovations pourront être réutilisées ailleurs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.