Fomos - un OS expérimental développé en Rust

• Une tentative de créer un OS non-Unix avec Rust.
• À ce stade, il prend en charge l’affichage graphique, l’allocation dynamique, l’exécution concurrente ainsi que le clavier et la souris.
• Sa particularité est d’avoir été conçu pour que toutes les applications puissent fonctionner comme une fonction unique.
  • Les applications s’exécutent en recevant un Context qui inclut les fonctionnalités de l’OS, si bien que toutes les interactions passent par ce Context.
  • Cela rend le sandboxing et le débogage très faciles, et comme l’état mémoire est lui aussi conservé via le Context, le redémarrage et la mise en veille sont facilités.
• La conception des applications n’est pas encore finalisée, ce qui laisse des problèmes en suspens, comme le fait que toutes les applications puissent voir la mémoire des autres.
• Le stockage persistant, le GPU, la prise en charge réseau, etc. restent encore à implémenter.

[honglu]

Le concept est séduisant. Tout le monde est en Rust... hahaha

[botplaysdice]

« Les applis peuvent voir la mémoire des autres »... :)

[ahwjdekf]

Oui, c’est vraiment très drôle.

[xguru]

VirGL - GPU 3D virtuelle utilisable dans une VM QEMU

La prise en charge de VirGL permet de l’installer et de le tester dans QEMU.

[kuroneko]

• Fil HN

L’avenir où l’on exécute des programmes Rust sur un OS en Rust… ? Le monde entier est en Rust.

[heycalmdown]

Ce serait bien que neo résume automatiquement s’il y a un fil HN dans les commentaires lol, je ne peux plus vivre sans neo.

[kuroneko]

À partir de maintenant, je vais essayer d’inclure aussi les résumés IA. Fait intéressant, on dirait qu’ils résument par affirmation formulée par chaque personne ?

• danhau : s’interroge sur le fait de savoir si l’ordonnancement coopératif est voué à l’échec comme d’autres le prétendent, et s’inquiète du fait que les applis coopèrent déjà. Il craint que des attaques par déni de service puissent facilement interrompre ce type de système.
• aseipp : est d’accord avec danhau et dit que l’ordonnancement coopératif peut rendre des erreurs simples fatales pour le système, ce qui peut poser problème pour l’exécution de programmes arbitraires.
• gnulinux : suggère que ce n’est peut-être pas le cas dans tous les scénarios, et qu’il pourrait exister des moyens de permettre des applis coopératives tout en évitant qu’une boucle infinie ne bloque le système. Il mentionne par exemple des timeouts ou la détection de boucle.
• DSMan195276 : affirme que ce n’est pas forcément absolu, parce que les programmes coopératifs partent du principe qu’ils ne seront pas préemptés. Il ajoute que même une réduction du niveau de préemption obligerait à changer la façon d’écrire les programmes.
• getpokedagain : dit que tous les systèmes d’exploitation n’ont pas besoin d’exécuter des applis multi-utilisateurs imprévisibles, et que le modèle coopératif peut fonctionner sur des systèmes contraints comme les appareils embarqués ou les consoles de jeu.
• Symmetry : explique que les CPU modernes disposent de plusieurs threads, donc si l’OS peut continuer à tourner tout en surveillant l’usage excessif de certains threads, le modèle de Fomos pourrait fonctionner sans être totalement bloquant.
• cmrdporcupine : note que certains cas d’usage spécialisés ont l’avantage de pouvoir utiliser un modèle attribuant directement le travail à des cœurs libres, mais que la complexité de la gestion de la concurrence ne serait pas forcément beaucoup plus simple que d’implémenter du time-slicing.
• JoeAltmaier : souligne qu’une boucle while(true) sur un thread peut ne pas affecter les autres threads, mais que l’augmentation de la batterie consommée et de la température reste un problème de ressources à gérer.
• keyle : se dit enthousiasmé par ce projet et son approche minimaliste, et attend davantage de développements, comme un système de fichiers répondant aux exigences traditionnelles permettant de faire tourner DOOM.
• mepian : précise que les méthodes Smalltalk sont appelées entre objets plutôt que comme des fonctions indépendantes, et explique que certains premiers OS Lisp utilisaient aussi des fonctions avant l’arrivée des systèmes objets.

[xguru]

Heureusement ? Neo a traité le même article haha

Fomos : un système d’exploitation expérimental construit en Rust

[xguru]

Le problème, c’est que moi aussi j’étais en train de le résumer en regardant ce lien, ouin

Vous pouvez même comparer pas moins de trois versions du résumé, haha

• Je voulais essayer de créer un OS non-Unix
• L’exo-kernel est intéressant, mais comme cela reste surtout théorique, ça aide à comprendre ce pattern
• Fonctionnalités
  • sortie graphique, allocation dynamique, toutes les applis s’exécutent dans une boucle asynchrone
  • souris/clavier Virtio (les pilotes aussi sont des tâches asynchrones)
  • ordonnancement coopératif (les applis rendent le contrôle autant que possible)
  • aucun changement de contexte après le démarrage
  • prend presque en charge Virgl™
• Points originaux
  • signature de l’appli pub extern "C" fn _start(ctx: &mut Context) -> i32
  • les applis n’ont pas besoin de bibliothèque standard, et toutes les fonctionnalités de l’OS leur sont transmises via Context
  • dans Fomos, une appli n’est qu’une seule function. C’est le point le plus important. Les exécutables des OS Unix/Windows sont très complexes comparés à une fonction.

[roxie]

Il n’y a pas de bouton « thumbs down », alors comment votre karma a-t-il pu devenir négatif ?