Pensez-vous que les OS gérés sont une bonne idée? [fermé]

Les systèmes d'exploitation gérés comme Microsoft Singularity et JNode sont un concept assez intéressant. Essentiellement, le système d'exploitation est amorcé avec du code écrit dans un langage de bas niveau (C / C ++ / Assembly), qui implémente essentiellement une machine virtuelle. Le reste du système d'exploitation (et toutes les applications utilisateur) s'exécutent sur la machine virtuelle. Il y a de grandes choses à ce sujet. Par exemple, vous rendez soudainement obsolètes des pointeurs arbitraires. Et si c'est bien écrit, vous vous débarrassez d'une tonne de crud hérité que la plupart des systèmes d'exploitation modernes ont actuellement.

Cependant, comme inconvénient, vous êtes bien plus éloigné du matériel et, en tant que développeur, vous perdez la possibilité de descendre à un niveau d'abstraction inférieur et de vous salir les mains.

quelles sont vos opinions a ce sujet?

Je pense que c'est un autre cas où "ça dépend".

Si vous écrivez des applications telles que des navigateurs Web, des traitements de texte, etc. où les performances ultra-rapides ne sont pas nécessairement un problème, cette approche a ses avantages. En utilisant cette approche, vous pouvez offrir à vos clients une expérience plus sûre et plus contrôlée. Non seulement vous limitez les dommages qui peuvent être causés par les logiciels malveillants, mais vous exécutez également dans un environnement plus cohérent.

C'est comme la différence entre les jeux sur console et les jeux PC. Les premiers savent exactement avec quel matériel ils ont besoin de travailler et peuvent donc utiliser ces connaissances tandis que les seconds doivent être en mesure de faire face à une plus grande variété de cartes graphiques, de cartes son, de vitesses de disque dur, etc.

Cependant, il y aura des applications (comme les jeux!) Qui nécessitent un accès de bas niveau et devront toujours être exécutées "nativement".

Comme pour les langues gérées, vous devrez utiliser l'outil approprié pour le travail.

En général, je pense que c'est une bonne idée, mais comme il n'y en a pas beaucoup autour ou presque complètement cuit, il est très difficile de dire comment ils fonctionneraient dans le monde réel. Je souhaite que MS ait mis à jour le projet Singularity afin que nous puissions voir où cela allait, mais je suppose que certains d'entre eux sont en cours d'utilisation dans une version de Windows

Je pense que les avantages d'un système d'exploitation entièrement géré sont énormes et que cela pourrait vraiment être l'avenir, mais il faudra encore de nombreuses années.

Un bon système d'exploitation géré vous fournira tous les points d'entrée gérés dont vous avez besoin pour faire toutes les choses de bas niveau dont vous avez besoin, indépendamment de la gestion: intercepter les interruptions et effectuer des E / S avec des périphériques. C # autorise également le code dangereux (traitant des pointeurs) mais il ne sera autorisé que dans les "pilotes de périphérique" (qui ne seront qu'un autre type de processus logiciel isolé).

Les avantages en termes de sécurité, d'uniformité, de portabilité et surtout de fiabilité dépasseront certainement tout inconvénient de performances. Un système entièrement géré est alors étonnamment rapide, car il n'est plus nécessaire de changer de contexte.

Les OS gérés sont probablement en quelque sorte des micro-noyaux - vous sacrifiez les performances au nom de la sécurité.

Il pourrait y avoir des problèmes similaires car cela nécessite de diviser le code en 2 parties:

• Noyau de bas niveau écrit en C / assembleur
• Noyau de niveau supérieur écrit en langage managé

Selon le coût d'entrée / sortie en toute sécurité du langage HL, cela peut imposer des problèmes similaires à ceux des micro-noyaux - peut-être un peu plus rapidement (quitter HL est plus rapide que le changement de contexte complet, mais IIRC par exemple JNI est assez coûteux).

L'application utilisateur aurait également probablement besoin de contextes distincts car de nombreuses applications sont écrites sur d'autres plateformes (disons C, Java ou .Net). Dans les mêmes cas, les applications peuvent être liées au processeur (compilateurs, convertisseurs de musique, etc.) et nécessitent même une optimisation de l'assembleur pour fonctionner à une vitesse suffisante. En outre - la protection MMU implémentée en langage HL ne sera probablement pas aussi rapide que celle matérielle, même si elle peut être beaucoup plus affinée.

Le langage HL ne maîtrise pas non plus les opérations de bas niveau. Bien que les logiciels soient généralement conçus avec de «bonnes» pratiques de codage, les pilotes ne sont pas nécessaires. Je ne pense pas qu'ils protègeront contre au moins certaines erreurs car les noyaux nécessitent parfois une mémoire à gestion manuelle.

Enfin, je ne pense pas qu'un tel système d'exploitation nécessiterait une machine virtuelle complète. Étant donné que le système d'exploitation ne peut pas être construit avec les principaux langages HL de compilation une fois exécutée partout (même avec GC & co.), Ce serait un meilleur candidat.

Par exemple, vous rendez soudainement obsolètes des pointeurs arbitraires.

Le système d'exploitation est intrinsèquement de bas niveau. Vous passez au matériel non seulement au «pointeur arbitraire», mais probablement à l'adresse physique plutôt qu'à l'adresse virtuelle. Certains DMA ne peuvent gérer que les 16 premiers Mo de mémoire. Bien que ce système d'exploitation puisse simplifier beaucoup, il ne supprimera pas les adresses.

Et si c'est bien écrit, vous vous débarrassez d'une tonne de crud hérité que la plupart des systèmes d'exploitation modernes ont actuellement.

1. Il existe de nombreux matériels hérités. Bien plus que dans le logiciel. Vous commencez d'abord en mode réel, puis activez la porte A20 (ne demandez pas), passez en mode protégé puis en mode long.
2. La compatibilité API / ABI est bonne. Disons qu'ils ont écrit un tel système d'exploitation - que feriez-vous? Firefox - non (C et C ++ utilisant WinAPI). Java - il avait probablement besoin d'être porté ou avait quelques problèmes mineurs via ikvm - à moins qu'il ne soit heureux d'utiliser JNI. Je suppose que MSSQL (et pour sûr Oracle, MySQL, Postgresql ...) n'est pas écrit en langage managé donc il ne conviendrait pas au serveur.
3. Même la compatibilité des bogues est "bonne". AFAIK MS passe beaucoup de temps à tester et à vérifier si certains logiciels n'utilisent pas l'API de manière intelligente (lecture incorrecte). Comme le problème de l'utilisation du pointeur après freelorsque Windows a réellement commencé à libérer de la mémoire.

Je suppose que cela gagnera en popularité à peu près en même temps que les micro-noyaux.

Personnellement, je pense que l'idée d'un OS géré est un peu comme le communisme: bonne en théorie, mais peu pratique à mettre en œuvre.

Le problème est que je ne vois tout simplement aucun moyen d'amener le système d'exploitation géré sans réécrire complètement le système d'exploitation à partir de zéro (et j'espère que quelqu'un pourra me prouver le contraire sur cette partie). De plus, comment pouvez-vous intégrer des décennies de code non managé dans un système d'exploitation géré?

Les noyaux des systèmes d'exploitation les plus populaires sont testés au combat et ont mûri au cours des deux dernières décennies. Vous ne les réécrivez pas simplement sur un coup de tête. Sans oublier que l'histoire regorge d'exemples de conceptions de processeurs et d'architectures de noyau qui étaient indéniablement meilleures mais qui n'ont jamais réussi à convaincre qui que ce soit le coût de leur modification.

Enfin, comment une entreprise comme Microsoft ou Apple va-t-elle vendre un OS géré à ses clients? L'utilisateur moyen d'un ordinateur se souciera-t-il même si son système d'exploitation est géré ou non?

Ce qui précède, j'espère que je me trompe et que les OS gérés vont être une réalité. Mais je suis sceptique. Si nous le voyons, ce ne sera probablement pas avant une décennie ou deux.

Le code managé n'est qu'une extrapolation de ce que la protection de la mémoire virtuelle vous achète aujourd'hui, à savoir la capacité de l'ordinateur à refuser l'accès aux ressources.

IBM le fait déjà sur leurs systèmes mainframe (ils l'appellent simplement autre chose), donc ce n'est à mon avis qu'une question de temps avant que cela ne se produise sur les systèmes disponibles pour le grand public.

Seriez-vous intéressé si un ordinateur portable Google (qui exécute Chrome et pratiquement rien d'autre) fonctionne ou non avec du code managé?

Cependant, comme inconvénient, vous êtes bien plus éloigné du matériel et, en tant que développeur, vous perdez la possibilité de descendre à un niveau d'abstraction inférieur et de vous salir les mains.

Ce n'est pas vraiment vrai. Dans JNode par exemple, il existe une Unsafeclasse (et d'autres) qui vous permettent d'accéder aux emplacements de mémoire, etc. Il existe également des classes / méthodes "magiques" qui sont traduites en instructions privilégiées par le compilateur JIT. L'accès à ces classes / méthodes est (ou sera) restreint par le gestionnaire de sécurité, le compilateur JIT, etc. Mais si vous écrivez du code qui s'exécute au niveau du système d'exploitation, ces fonctionnalités sont à votre disposition.

La mise en garde est (bien sûr) qu'une utilisation incorrecte des Unsafeclasses associées peut entraîner des plantages du système d'exploitation immédiatement ou en fin de compte.

Je doute de leur utilité pour les ordinateurs de bureau. Mais le temps peut me prouver le contraire sur ce point.

Mais un potentiel intéressant à mes yeux est en tant que système d'exploitation serveur, plus spécifiquement en tant que système d'exploitation invité dans un environnement virtualisé. Il ne m'est jamais venu à l'esprit d'installer une installation complète de serveur Windows dans un environnement de serveur virtuel, sachant combien de services inutiles il exécute, y compris l'interface graphique complète.

Maintenant, installer quelque chose comme Singularity sur un serveur virtuel pour héberger des applications ASP.NET, cela a plus de sens. En supposant qu'ils peuvent garder un système d'exploitation léger.