Redox is a Unix-like Operating System written in Rust, aiming to bring the innovations of Rust to a modern microkernel and full set of applications.
Inspired by Plan 9, Minix, BSD and Linux
Implemented in Rust
Microkernel Design
Includes optional GUI - Orbital
Supports Rust Standard Library
MIT Licensed
Drivers run in Userspace
Includes common Unix commands
Custom libc written in Rust (relibc)
Faut revoir le débat Tanenbaum vs Torvalds au début du noyau Linux pour avoir les arguments de l'époque qui ont peut changé depuis.
En gros ce choix de conception fait partie des noyaux dits micro-noyaux (Hurd, Minix, Redox OS, autres) et ceux dits monolithiques (Linux, BSD, etc.). Windows et macOS ont clairement une approche hybride en mettant le maximum en espace utilisateur mais gardant malgré tout pour des raisons de performances certaines choses dans l'espace noyau.
Le nerf de la guerre c'est donc fiabilité contre performance. Car le passage de l'espace utilisateur à espace noyau est coûteux en temps (car le processeur doit faire certaines actions, tu peux perdre en cache des données, etc.) et y passer tous les pilotes en espace utilisateur a donc un impact significatif à cet égard. Cela augmente aussi la nécessité d'échanger des messages entre les pilotes et le reste du noyau ce qui ajoute un peu de complexité.
Mais l'avantage c'est que si le pilote crashe (corruption mémoire ou autre), cela n'affectera pas à priori le reste du noyau qui pourra le relancer si nécessaire. Dans le cas d'un noyau monolithique comme Linux ton ordinateur est souvent bon à redémarrer suite à un kernel panic généré dans ce cas.
30 ans après on voit que les approches absolutistes ont échoué. Les micro-noyaux purs sont peu répandus et les approches hybrides semblent privilégiés. C'est ce qui permet par exemple à Windows de relancer le pilote graphique quand il plante ce qui peut arriver, ces pilotes étant très gros et complexes un crash peut arriver de temps en temps.
Est-ce que l’approche monolithique de Linux n’impose pas, au moins partiellement, des pilotes en gpl, et pérennes ? Le premier dans la mesure où ils sont inclus dans du code en gpl, et le second parce qu’ils sont inclus dans le noyau. Pour certains ces conséquences de l’approche monolithique de Linux ne sont-elles pas un vrai atout : pas de matériel qui cesse définitivement de fonctionner pour cause de politique commercial ?
Question de point de vue. L'approche de Linux est qu'ils n'hésitent pas à modifier les interfaces entre le noyau et les pilotes, donc un pilote de périphérique qui veut survivre longtemps a tout intérêt à être inclus dans le noyau et à se trouver un mainteneur pour faire les mises à jour.
Une autre approche serait d'avoir une interface stable entre le lyau et les pilotes, et dans ce cas, le pilote pourrait etre écrit une bonne fois pour toutes et nécessiter peu de maintenance. Peut-être que les entreprises construisant du matériel arriveraient mieux à maintenir leurs pilotes à jour dans ce cas, et sans avoir à publier leur code source (il y a une certaine culture du secret sur le sujet…)
Les deux modèles peuvent se défendre, mais dans tous les cas, c'est toujours mieux d'avoir le code source sous une license qui permet d'assurer soi-même la maintenance
Si les constructeurs pouvaient aussi se calmer sur la complexité et utiliser des standards…
Quelques exemples :
pour les manettes, sur USB on a les variantes DirectInput/Xinput/HID et une variante par console. En sans fil, on a le Bluetooth qui ne fait pas semblant de marcher, les dongles 2.4G où chaque constructeur a son standard et une variante par console => ils ne peuvent pas se mettre d'accord pour gérer quelques axes et boutons ? ;
pour les imprimantes, c'est le chaos absolu, là où imprimer devrait se résumer à envoyer un pdf + quelques options ;
HDMI dont le protocole de négociation est tellement complexe qu'il faut plusieurs secondes pour caler l'affichage avec de nombreux bugs, là où un bon vieux VGA marchait immédiatement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Billet source
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 22 juillet 2023 à 16:21.
L'idée générale : how to use the driver of another OS in order to run your apps on Redox OS ?
# Contexte
Posté par Xanatos . Évalué à 2.
[^] # Re: Contexte
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 23 juillet 2023 à 11:20.
Une idée des raisons de ce choix d'ailleurs ?
[^] # Re: Contexte
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
Que si un driver a un souci (plantage, bloquage…), il peut être immédiatement relancé sans tout un pataquès dans le noyau ?
[^] # Re: Contexte
Posté par antistress (site web personnel) . Évalué à 4.
Ok, et une raison que d'autres ne fassent pas ce choix ?
[^] # Re: Contexte
Posté par Renault (site web personnel) . Évalué à 10.
Faut revoir le débat Tanenbaum vs Torvalds au début du noyau Linux pour avoir les arguments de l'époque qui ont peut changé depuis.
En gros ce choix de conception fait partie des noyaux dits micro-noyaux (Hurd, Minix, Redox OS, autres) et ceux dits monolithiques (Linux, BSD, etc.). Windows et macOS ont clairement une approche hybride en mettant le maximum en espace utilisateur mais gardant malgré tout pour des raisons de performances certaines choses dans l'espace noyau.
Le nerf de la guerre c'est donc fiabilité contre performance. Car le passage de l'espace utilisateur à espace noyau est coûteux en temps (car le processeur doit faire certaines actions, tu peux perdre en cache des données, etc.) et y passer tous les pilotes en espace utilisateur a donc un impact significatif à cet égard. Cela augmente aussi la nécessité d'échanger des messages entre les pilotes et le reste du noyau ce qui ajoute un peu de complexité.
Mais l'avantage c'est que si le pilote crashe (corruption mémoire ou autre), cela n'affectera pas à priori le reste du noyau qui pourra le relancer si nécessaire. Dans le cas d'un noyau monolithique comme Linux ton ordinateur est souvent bon à redémarrer suite à un kernel panic généré dans ce cas.
30 ans après on voit que les approches absolutistes ont échoué. Les micro-noyaux purs sont peu répandus et les approches hybrides semblent privilégiés. C'est ce qui permet par exemple à Windows de relancer le pilote graphique quand il plante ce qui peut arriver, ces pilotes étant très gros et complexes un crash peut arriver de temps en temps.
[^] # Re: Contexte
Posté par antistress (site web personnel) . Évalué à 3.
Top, merci !
[^] # Re: Contexte
Posté par barmic 🦦 . Évalué à 0.
Tu trouve que linux a échoué ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Contexte
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Est-ce que l’approche monolithique de Linux n’impose pas, au moins partiellement, des pilotes en gpl, et pérennes ? Le premier dans la mesure où ils sont inclus dans du code en gpl, et le second parce qu’ils sont inclus dans le noyau. Pour certains ces conséquences de l’approche monolithique de Linux ne sont-elles pas un vrai atout : pas de matériel qui cesse définitivement de fonctionner pour cause de politique commercial ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Contexte
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Question de point de vue. L'approche de Linux est qu'ils n'hésitent pas à modifier les interfaces entre le noyau et les pilotes, donc un pilote de périphérique qui veut survivre longtemps a tout intérêt à être inclus dans le noyau et à se trouver un mainteneur pour faire les mises à jour.
Une autre approche serait d'avoir une interface stable entre le lyau et les pilotes, et dans ce cas, le pilote pourrait etre écrit une bonne fois pour toutes et nécessiter peu de maintenance. Peut-être que les entreprises construisant du matériel arriveraient mieux à maintenir leurs pilotes à jour dans ce cas, et sans avoir à publier leur code source (il y a une certaine culture du secret sur le sujet…)
Les deux modèles peuvent se défendre, mais dans tous les cas, c'est toujours mieux d'avoir le code source sous une license qui permet d'assurer soi-même la maintenance
[^] # Re: Contexte
Posté par devnewton 🍺 (site web personnel) . Évalué à 6. Dernière modification le 25 juillet 2023 à 11:24.
Si les constructeurs pouvaient aussi se calmer sur la complexité et utiliser des standards…
Quelques exemples :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Contexte
Posté par Psychofox (Mastodon) . Évalué à 3.
Displayport est assez bien fait je crois comme protocole/standard
[^] # Re: Contexte
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Dans les systèmes à micronoyaux il faut quand même citer Fuchsia chez Google, même si il n'est pas très utilisé en dehors de l'entreprise.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.