La version officielle de la naissance du noyau NT/XP: aussi bien techniquement (fortement inspiré de la théorie du micronoyau) qu'économique et social: l'article explique comment Microsoft fonctionne en petits groupes indépendants, voire concurrents.
(trouvé grace à l'excellent site de JY)
Aller plus loin
- Comment nait un noyau (4 clics)
- Le joueb à JY (2 clics)
- Théorie du Micro Noyau (4 clics)
- Les micronoyaux, c'est nul! (4 clics)
# microsoftfr.org
Posté par Henri . Évalué à 7.
Car dans la lignée de ms-dos qui fut racheté, flight sim aussi car Monseigneur Bill aimait y jouer, foxpro aussi car leur code était trop performant et faisait de l'ombre au bébé Access qui est né avec des tares génétiques, ... et bien une part non-négligeable du noyau NT a été réalisé par d'autres boites.
Au premier rang, DEC. Feu DEC, un des vrais de l'informatique, qui a innové avec des VAX qui marchent encore, VMS qui inspire FreeVMS, le processeur Alpha 64 bits (bien bien avant l'IA-64), et bien pensait développer son Alpha grace à Windows, et pour se faire il a gentiment contribué avec ses développeurs de 1er choix à la base NT. Que dire également concernant le micro-noyau de la réincorporation d'idées voire de code venant d'IBM via l'arnaque OS/2...
Décidément, on nous cache des choses.
# Réponse au document: Les micronoyaux, c'est nul!
Posté par Manuel Menal . Évalué à 10.
MA> AT prêchait pour les micro-noyaux. LT était parti de Minix, mais AT considérait son "oeuvre" comme un jouet ou un vague support de cours.
Effectivement. AT est un chercheur. Il a donc fait Minix dans une optique de recherche. Le Hurd n'est pas fait par des chercheurs pour des chercheurs, et cherche à être la vraie alternative à Linux. D'ailleurs, Minix existait et tournait assez bien, quoi qu'on en dise.
MA> A une époque reculée, tout le monde était persuadé que la seule façon de faire un système portable était d'utiliser un micro-noyau.
MA> Linux et NetBSD ont prouvé le contraire.
A une époque reculée, on le pensait peut-être, je ne peux me prononcer au nom de ceux qui argumentaient pour les micro-noyaux alors que je marchais à peine. Il est clair que la théorie des micro-noyaux aide forcément à construire un système portable. (Le Hurd a récemment était porté sous PPC très facilement, à l'aide d'une version de OSF Mach précédemment portée sous PPC. On peut penser que par la suite, entre autre avec le passage à L4, le port vers d'autres architectures se fera très facilement, vu la taille de L4 et le fait qu'il existe déjà pour de nombreuses architectures). Cependant, aucune notion d'exception là-dedans. On peut très bien faire du code au maximum portable dans un noyau monolithique. Dire le contraire serait une aberration... Comme on peut faire du code non portable en utilisant un micro-noyau.
MA> * MkLinux va a peine plus vite que MacOS sur Power Mac.
Super. Et ensuite ? Prendre des exemples n'est pas combattre une théorie. Ensuite, il faut savoir que MkLinux est basé sur le noyau Mach, qui n'est certainement pas le plus rapide, en tant que noyau de première génération. (contrairement à L4..) De plus, il s'agit d'un mono-serveur, ce qui n'aide généralement pas pour les performances. A ce sujet, on pourra lire 'The Performances of µ-Kernel-based systems', disponible à l'adresse: http://os.inf.tu-dresden.de/pubs/sosp97/(...) (et bien entendu toutes les autres publications sur http://os.inf.tu-desden.de/L4/doc.html(...) ).
MA> * Hurd, est totalement instable, rame, et n'est justifié que par la haine de RMS envers Linux.
Il est évident que je ne peux pas laisser passer ça.. Tout d'abord, petite correction qui montre que l'auteur ne s'est même pas renseigné avant: on écrit le Hurd, et pas Hurd. Deuxièmement, l'argument d'instabilité est un peu ridicule.. Évidemment qu'il l'est. Le Hurd n'est pas abouti. Sa stabilité s'améliore de jour en jour, et devient de plus en plus utilisable. Il a des points faibles, qu'on connaît: pfinet, un mauvais hack de la pile TCP de Linux qui limite de façon considérable ses capacités réseau. (PPP est sur le point de fonctionner parfaitement cependant! :), le serveur ext2fs, et la VM de Gnumach. (qui a dit, Gnumach en général? :) zalloc en particulier.). Mais il n'est pas particulièrement instable, il peut déjà tenir un uptime de plus d'un mois, et pourrait bien plus s'il n'y avait pas ces problèmes de zalloc. (ce qui n'est pas un problème du Hurd, qui comme chacun sait est en théorie indépendant du micro-noyau.)
Quant à sa lenteur, elle est effective. Les performances représentent un sujet très difficile à traîter car sujet à de nombreux paramètres en particulier liés à l'implémentation. Juger les performances d'un système non abouti ne me semble pas être très représentatif. On pourra notamment citer Evolution, qui était *extrêmement* lent jusqu'il y'a peu et qui a, quoi qu'on en dise, améliorer grandement ses perfs. (no troll, please..). Il faut quand même savoir que:
1) Le Hurd n'est optimisé d'aucune façon. Les perfs n'ont pas été le but originel, et même si c'est un sujet que les développeurs gardent en tête lors du développement, ça n'est pas la préoccupation principale, et elle se concrétise plutôt par des comments sur ce qu'on devrait faire (et qui est faisable.. donc susceptible d'être fait dans le futur) que par du code, permettant ainsi de se concentrer plutôt sur le feature set.
2) Mach, même si ça n'est pas la seule raison de la lenteur du Hurd, n'est pas un modèle concernant les performances (je vous incite toujours à lire le papier ci-dessus...), et encore moins Gnumach.
Quant à RMS, je ne vois pas ce qu'il a à faire là-dedans. RMS ne suit plus le développement du Hurd depuis longtemps, et la FSF est peu au courant de ce qui s'y passe généralement.. (un sursaut soudain vient d'arriver, et on espère qu'on aura bientôt un nouveau développeur à plein temps..). RMS n'a aucune haine envers Linux, pour en avoir discuté avec lui, et pour avoir lu nombre de ses publications.. Il est effectivement en désaccord avec Linus, qui se soucie peu, à vrai dire, du côté philosophique du libre. Il me semble que le Hurd s'inscrit dans la logique du projet GNU: refaire un système du type Un*x, mais pas une simple réécriture libre d'Un*x, ce qu'est finalement, à la base, Linux (les améliorations se trouvant avant tout dans l'implémentation et non dans le design..). Je pense que le Hurd est viable, mais n'ai aucun moyen concret de le prouver tant que le Hurd n'est pas totalement abouti et ne représente pas une alternative viable à Linux sur le bureau et sur les serveurs. L'attitude à adopter me semblerait plutôt être: Let's code it and see if it can be as cool as they say. (ou, let them code it si vous n'avez aucune envie de vous plonger dedans..)
MA> * Spring, l'OS expérimental de Sun, est arrêté. Je ne crois pas qu'ils aient relaché les sources. Le labo qui l'a conçu s'est amusé un moment avec, ils ont tenté de
MA> * récupérer certaines idées dans SunOS 5, puis ils sont passés à autre chose.
Effectivement. Et ensuite ? Il me semble qu'il s'agissait plutôt d'un OS expérimental à des fins de recherche, qui n'avait d'autre but que d'être un lieu de test pour des fonctionnalités à implémenter dans l'OS qu'ils comptaient garder comme seul OS principal, SunOS. Je me garderais bien de tout commentaire, ne connaissant pas bien son design autrement..
MA> * WinNT, est loin de la maturité et se débarrassera probablement de l'aspect micro-noyau avant de se débarrasser de ses nombreuses bogues.
L'expérience, et Windows 2000, prouve que celà est faux. On notera d'ailleurs que (NO TROLL PLEASE) Windows 2000 est probablement le meilleur des Windows existants, et à ce que j'en ai entendu dire, plus fiable que ses prédécesseurs. Excusez-moi, mais un système à micro-noyau où au fur et à mesure on a implémenté le maximum dans le kernel space (je sens que je vais avoir le droit au pBpG), on peut difficilement prendre ça comme référence.. D'autant plus qu'on en a pas les sources, ce qui rend le jugement assez difficile.
MA> * DEC OSF/1 est maintenant un machin monolythique. On ne voit plus mentionné le micro-noyau dans leurs docs.
MA> En fait, ça ressemble furieusement à un SunOS 4, même si c'est (très) différent en interne.
Même chose: et alors ? Ils sont passés à autre chose, parce qu'ils avaient d'autres besoins, que Mach ne comblait finalement pas.. Ca n'est pas un argument concernant les micro-noyaux, que je sache. Si mes souvenirs sont bons, on m'a dit en cours de français qu'un exemple n'était pas un argument.
MA> * AIX aurait été micro-noyautesque en des temps trèèès anciens ?! Mais vu tout ce qui a été tartiné autour, personne n'a jamais vu le micro-noyau.
De même. Je ne connais pas le cas d'AIX, mais une chose courante est que les développeurs, après avoir eu de bonnes idées concernant le design, n'étant contrôlés par pas grand monde, se laissent aller à la facilité et mette tout ça de façon inorganisée un peu n'importe où, voire même dans le micro-noyau. Programmer un système à micro-noyau demande certainement de la rigueur, c'est sûr: il est tellement facile de faire un foutoir du genre monolithique tel que le décrit André Tanenbaum dès les premiers chapitres de tous ses livres sur les OS.
MA> * Dans Mach 4, ils ont remonté le réseau dans le micro-noyau pour des questions de perfos.
MA> C'était prohibitif -- une demie-douzaine de context switch sur chaque paquet (au bas mot), il y a de quoi mettre à genoux n'importe quelle bécane.
Tiens donc. Il m'avait toujours semblé, à la lecture des docs OSF/CMU (dès les docs de Mach3) que ç'avait été pour permettre d'avoir un système à plusieurs hosts/nodes, plusieurs Mach tournant.
Pour les context switches, l'argument est un peu vague. Où est la demi-douzaine? J'aimerais le savoir, à la vue de pfinet et, surtout, des projets qui ont été faits pour le remplacer.
MA> Fondamentalement, c'est une aberration. Quand on voit le nombre d'attaques ou de bogues qui tournent autour de TCP/IP,
MA> on se dit que la robustesse du micro-noyau en prend un vieux coup sous la ligne de flottaison.
J'avoue que j'ai du mal à comprendre, là. Avoir la gestion réseau (la pile TCP, etc..) dans le noyau est une aberration, parce qu'elle est susceptible de faire crasher l'intégralité du système ? On est bien d'accord, et c'est là un argument contre les noyaux monolithiques. De plus, il ne me semble pas que la gestion du réseau soit totalement implémentée dans Mach4. Et encore une fois, Mach n'est pas le seul micro-noyau. L4 serait un exemple plus intéressant d'un vrai µ-noyau.
MA> * Dans le dernier Mach OSF, certains envois de message ont été remplacés par des appels de procédures ;
MA> certains serveurs partagent dans le même espace d'adressage pour éviter les context switchs.
1) Oui, on limite au maximum les messages, puisque cela transite par le noyau. Et ensuite ?
2) Pardon ? un exemple plus précis ? Si l'on peut éviter des context switches, par des biais tout à fait sain, on le peut. Que je sache, ce que vous décrivez n'a pas été fait tel quel.
De plus, c'est un argum^Wexemple contre Mach. Pas contre la théorie des micro-noyaux.
MA> Admettons : on peut "valider" certains serveurs et les passer dans le noyau. Mais c'est se faire des noeuds au cerveau:
MA> quand tout sera "validé", on aura un OS monolythique pas forcément plus stable qu'un autre -- BSD au hasard.
Ca n'a jamais été le but des concepteurs de micro-noyau, et encore moins celui du Hurd. (par exemple). Le mouvement se fait dans le sens inverse, au fil du temps: mettre le maximum de choses dans l'user space pour n'avoir dans le kernel space qu'une IPC basique, et une gestion de la mém et des procs basiques (et un accès hard minimal, quand même..): c'est ce que fait L4, encore une fois.
MA> les micro-noyaux se rapprochent des OS monolythiques et les OS monolythiques intègrent des fonctions qui ressemblent à ce qu'on trouve sur les micro-noyaux.
MA> Par exemple, les "modules" et pilotes chargeables de Linux.
Dans le premier cas, je ne suis pas du tout d'accord, et l'évolution dans la recherche sur les micro-noyaux (et l'évolution du Hurd) montre le contraire, le mouvement kernel space->user space que je citais précédemment.
Dans l'autre sens, il est évident qu'on ne peut comparer les modules Linux et les serveurs du Hurd... Cependant, effectivement, cela a apporté une souplesse importante. (d'ailleurs, dans certaines versions récentes de Mach, ce système existe.) Il me semble que ça n'est jamais que ce qui se fait habituellement sous Linux, rajouter un truc, intéressant certes, par dessus, sans tout changer en profondeur. (faire un micro-noyau!) (pensez à ftpfs sous Linux...)
MA> Donc quelque part, tout ce travail n'a pas été inutile puisqu'il est récupéré dans les systèmes modernes.
Les systèmes modernes, comme le Hurd, comme QNX ? ;P
MA> Un projet comme Hurd est-il bien raisonnable ?
MA> Ne serait-ce pas "l'art pour l'art" ? Dans Computer power and human reason, Josef Weizenbaum dénonce the empire of instrumental reason.
MA> Nous y voila...
C'est ce que le Hurd tend à prouver: que les micro-noyaux ne sont pas une vue de l'esprit, un jouet de recherche sans intérêt pratique.. Il me semble clairement que le Hurd, qui est aujourd'hui
utilisable et existe réellement, le montre déjà. Et qu'il présente des intérêts, c'est indéniable: on peut déjà montrer les avantages du Hurd, au niveau sécu, au niveau shadowfs, etc..
MA> In fact, this made me think that the microkernel approach was essentially a dishonest approach aimed at receiving more dollars for research.
Effectivement, c'est un argument qu'il a maintes fois énoncé contre le Hurd par la suite: qu'il est trop théorique et pas assez pratique. A cette question, je pense qu'on ne peut que répondre: regardez. Il existe. Il marche. Il s'améliore.
Des gens le codent. Rendez-vous dans quelques années...
Voilà, that's all folks.
DISCLAIMER: aucune attaque contre l'auteur, qui est par ailleurs quelqu'un de compétent. Le document ne présente pas *aucun* intérêt, et on ne peut pas le comparer aux FUD habituels, faits par Microsoft, notamment. Mais les propos ne m'en semblent pas plus justifiés..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.