Journal : Hurd, une si belle idée et pourtant.
Posté par David Roon () le 23 octobre 2006
Non, Hurd n'a tjs pas avancé, Hurd est tjs pas stable, il a même l'air d'avoir de la peine à avancer.
Un journal ça sert à lancer une discussion donc pour ceux qui connaissent mieux le projet que moi, j'ai une question:
Pourquoi donc ce projet ne décolle-t-il pas?
Je vous rassure, je ne viens pas de découvrir le projet, mais qu'elle n'a pas été ma surprise quand j'ai vu que l'annonce par la FSF du lancement du projet datait de... 1991!!!
Le projet est vieux et pourtant aucune entreprise n'a osé se lancer dedans, personne n'en fait réelement quelque chose ,Debian n'est pas une entreprise, et si qqun veut en faire un business, qu'il me dise qui ca m'intéresse.
Le truc c'est que Hurd est vraiment une nouvelle idée. Mon problème avec tous les Unix like c'est qu'en fin de compte ils reprennent une idée vieille de 40 ans. Quand on regarde en arrière, on voit que les OS qui sont sur le marché ne sont en rien révolutionnaire.
La on a un système qui est stable par design ce qui veut dire que nous avons un système qui ne peut, théoriquement, pas complètement planté. On a également plus besoin de redémarrer, on peut utiliser plusieurs versions d'un même driver en même temps et le maintient du noyau est bien plus facile parce que la question est-ce qu'il faut oui ou non implémenter tel ou tel fonctionnalité n'existe pas vraiment. On arriverait dans la même situation que celle d'une distribution. Chacun développe sa partie, chacun est responsable de son code et tout le monde est content.
Conclusion, je n'ai ni les connaissances ni l'argent pour pouvoir réelement aider ce projet mais je crois qu'un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source car, pour la première fois depuis longtemps, l'open source aura devancer la concurrence.
Voila voila, bonne lecture, bon commentaires
Un journal ça sert à lancer une discussion donc pour ceux qui connaissent mieux le projet que moi, j'ai une question:
Pourquoi donc ce projet ne décolle-t-il pas?
Je vous rassure, je ne viens pas de découvrir le projet, mais qu'elle n'a pas été ma surprise quand j'ai vu que l'annonce par la FSF du lancement du projet datait de... 1991!!!
Le projet est vieux et pourtant aucune entreprise n'a osé se lancer dedans, personne n'en fait réelement quelque chose ,Debian n'est pas une entreprise, et si qqun veut en faire un business, qu'il me dise qui ca m'intéresse.
Le truc c'est que Hurd est vraiment une nouvelle idée. Mon problème avec tous les Unix like c'est qu'en fin de compte ils reprennent une idée vieille de 40 ans. Quand on regarde en arrière, on voit que les OS qui sont sur le marché ne sont en rien révolutionnaire.
La on a un système qui est stable par design ce qui veut dire que nous avons un système qui ne peut, théoriquement, pas complètement planté. On a également plus besoin de redémarrer, on peut utiliser plusieurs versions d'un même driver en même temps et le maintient du noyau est bien plus facile parce que la question est-ce qu'il faut oui ou non implémenter tel ou tel fonctionnalité n'existe pas vraiment. On arriverait dans la même situation que celle d'une distribution. Chacun développe sa partie, chacun est responsable de son code et tout le monde est content.
Conclusion, je n'ai ni les connaissances ni l'argent pour pouvoir réelement aider ce projet mais je crois qu'un système comme celui-là qui viendrait à être utilisable en production serait un gros coup de pouce pour l'open source car, pour la première fois depuis longtemps, l'open source aura devancer la concurrence.
Voila voila, bonne lecture, bon commentaires
> Lire le journal (83 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #767749.
Run by 
Cette page a été générée par Templeet en 0.0727s (dont 0.0107 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Parallélisme, nouveau défi
Depuis quelques années, on assiste à la généralisation des puces multicoeur. En effet le nombre de transistors que les nouvelles finesse de gravure permettent de caser sur un bout de silicium impose aux fondeurs de mettre plusieurs processeurs par coeur, en ayant beaucoup trop pour faire un seul coeur qui serait extrêmement complexe et chauferait trop.
Cela risque de se généraliser, dixit intel themselves (aller, au hasard : http://www.x86-secret.com/popups/articleswindow.php?id=125 ) avec des architectures masivement multicoeurs.
Le problèm est que le niveau technique des programmeurs pour gérer le massivement multi thread ne va pas évoluer exponentiellement lui.
Et les archi d'Os actuelles vont rapidement trouver leur limite (ceux qui me connaissent vont comprendre, "suivez mon regard", oui je sais, mais mon propos n'est pas de défendre ma crèmerie, simplement de faire un constat).
Ils ont à mes yeux deux défauts :
- Ils sont basés sur une architecture paginés, même pas segmentée, mais paginée. Hors une archi paginée tue le parrallélisme : elle oblige à passer très souvent par le noyau, avec tous les problèmes que cela comporte.
- Ils sont essentiellement architecturés pour être procéduraux et ne permettent le fonctionnement de logiciel émergent (architecture Com/Dcom et maintenant .Net chez kro, et Kpart chez Kde) que par l'intermédiaire de bidouille plus ou moins "crade".
Alors Hurd ? Ben j'y crois pas.
Le problème du Hurd est que son micronoyau possède peu d'info, et qu'il a donc du mal à optimiser.
Et en plus c'est encore écrit dans un langage à pointeur ce qui le rend amha trop complexe à gérer.
[^]Re: Parallélisme, nouveau défi
Puisque tu ne dis pas, je me lance ;-)
Il est clair que le Hurd est intéressant mais ne décolle pas. D'un autre coté, l'informatique a bien évolué depuis 15 ans. Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.
Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?
Bon, pour faire cela, il faudrait que l'INRIA joue pour une fois vraiment le jeu de l'opensource avec IsaacOS. L'INRIA a une carte à jouer, c'est à elle d'abattre son jeu si elle souhaite pouvoir un jour remplacer sur nos postes le système Linux. Mais qu'elle ne traine pas trop !
[^]Re: Parallélisme, nouveau défi
Alors je suis allé voir sur wikipedia pour IsaacOS.
A lire le petit explicatif ça a l'air pas mal mais je ne suis pas sûr de comprendre comment ça marche. Si j'ai bien compris il n'y a pas de noyau mais il y a des objets qui cohabitent. Je ne comprends juste pas comment ça marche, c'est à dire qui décide quel est le niveau de sécurité de chaque objet? C'est un objet?
Sinon c'est vrai c'est intéressant. Affaire à suivre également
[^]Re: Parallélisme, nouveau défi
En gros, c'est un OS constitué d'objets indépendant capables de gérer un héritage dynamique. Tous les objets dialoguent par envoi de message. Tout objet est nommé dans le système.
Ca veut dire que Inode peut hériter de Controleur_DD ou controleur_USB, comme ça quand tu fais des appels vers le parent, ça va au bon endroit.
Le noyau est "émergent" : tu as quelques objets "noyau", le sheduler, le gestionnaire mémoire, et comme ils ont tendance à naturellement communiquer en permanence, ça forme un noyau.
Pour la sécurité, pour le moment, il n'y en a pas. Ca sera aux futur devs de IsaacOs de se préoccuper de ce genre de chose.
[^]Re: Parallélisme, nouveau défi
J'y pense : tu trouveras un papier synthétique sur ce qu'est IsaacOS : http://isaacos.loria.fr/papers/cfse4.pdf
[^]Re: Parallélisme, nouveau défi
>Il est clair que le Hurd est intéressant mais ne décolle pas.
moi je le vois évoluer tous les jours, dernièrement un dev à fait fonctionner du pcmcia et du wifi ....
>Quittes à faire autre chose, autant le faire dans un autre langage que le C qui montre quand même ses limites aujourd'hui.
tu peux expliquer ? que conseille tu comme langage pour programmer un OS ?
>Pourquoi pas dans un langage à prototype qui parait très bien adaptés à la problèmatique. Pourquoi pas en Lisaac ?
moi je veux bien, mais lisaac il fait comment pour écrire dans les regsitres de ton controlleur scsi ? je voudrais bien voir le code en lisaac qui fait ça ... et si c'est pour le faire direct et avoir un accès en ring 0, ça doit être beau... si c'est pas le cas il faut bien un noyau même petit ou simili pour faire l'interface sécursié entre le userland et le hardware ...
alors issacos c'est bien joli mais moi hurd, je le démarre et je peux faire l'irc avec, isaacos, je demande à voir ... et puis hurd pêche par le nombre de dev mais même si isaacos est le truc conceptuel le meilleur du monde si les dev ne sont pas intéressés par le langage et par porter des applications dessus ça ne décollera pas plus voir même jamais ...
M.
eucd.info : sauvons le droit d'auteur !!!
[^]Re: Parallélisme, nouveau défi
moi je le vois évoluer tous les jours, dernièrement un dev à fait fonctionner du pcmcia et du wifi ....
Heureusement, ça fait tou même 15 ans qu'il existe !
tu peux expliquer ? que conseille tu comme langage pour programmer un OS ?
Lisaac puisqu'il a été principalement conçu pour ça.
http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Page 48.
En gros l'astuce consiste à inliner du C dans une section INTERRUPT (qui sera donc compilé en fonction), et quitte à inliner du C, inlinons directement de l'ASM.
En particulier pour une interruption tu ouvres une section __BEGIN_INTERRUPT__
Tout l'IsaacOs a été codé comme ça, et sont écris en Lisaac le driver du controleur disque, le driver vidéo, clavier, souris, etc...
Pour ce qui concerne la sécurité, l'OS est conçu pour utiliser les 4 ring des processeurs intel, mais ça n'a pas été implémenté pour faciliter le port sur des processeurs sans ring.
Tu trouveras toutes les explications ici :
http://isaacos.loria.fr/papers/cfse.pdf
alors issacos c'est bien joli mais moi hurd, je le démarre et je peux faire l'irc avec, isaacos, je demande à voir ... et puis hurd pêche par le nombre de dev mais même si isaacos est le truc conceptuel le meilleur du monde si les dev ne sont pas intéressés par le langage et par porter des applications dessus ça ne décollera pas plus voir même jamais ..
Ce sont des OS qui n'ont pas du tout le même age, et le deuxième n'est pas encore libéré, rien n'est comparable.
On en reparle dans deux ans !
[^]Re: Parallélisme, nouveau défi
On a l'autorisation de libérer IsaacOS, mais le compilateur nouvelle version totalement réécrit allant arriver bientôt, on s'occupe d'abord de lui, pour ensuite veiller à ce que l'on réussisse à recompiler IsaacOS avec ce nouveau compilateur (syntaxe un peu changé, quelques subtilités dans le système de type aussi, etc...).
Donc comme on aime faire bien les choses, on le fera quand le compilo fonctionnera bien, que la doc de la lib sera faite, et surtout qu'on réussira à faire tourner IsaacOS dans un qemu, le tout dans un distrib assurant au dev d'être à l'aise.
Je suis contre (et Benoit aussi) le fait de lancer dans la nature un Os qui compile pas, avec une lib pas documentée, etc... Ca donnerait une très mauvaise image au projet qui raterait ainsi son décollage.
Tout cela étant dit, je pense que ça sera prêt dans moins de 6 mois (j'espère) :)
[^]lisaac
je trouve qu'ils ont un choix de lunettes un peu restreint
[^]Re: Parallélisme, nouveau défi
Il y a sans doute quelque chose qui m'echappe, mais en quoi une architecture paginée tue le parellelisme, et quels sont les problèmes qui en découlent ?
Amha :
- C'est les architecture memoire des machines qui sont basées sur la pagination, l'os ne fait que s'adapter. La majorité des problèmes se trouvent au niveau hardware (synchronisation du/des cache(s))
- La pagination permet d'offrir un espace d'adressage propre à chaque processus, et je vois mal comment faire du parrallèlisme sur sans cet espace d'adressage unique.
- Quelque soit l'os (considéré comme preemptif), on passera toujours par le noyau pour gerer l'ordonnancement et la priorité des processus (c'est son role !), un ou n processeurs embarqués sur la machine ne changent rien à cet etat de fait. La contrainte introduit par la pagination sur l'os est le comportement à adopter en cas de defaut de page, et ça releve plus d'une insuffisance matérielle (pas assez de memoire) que d'un defaut de conception de l'os.
[^]Re: Parallélisme, nouveau défi
Pour ce qui est du multi-coeur, j'ai vu l'autre jour un waffer expérimental de chez Intel : 80 coeurs, 1 terraflops sur une puce !
Le temps que la R&D finisse tout ça et on aura ça dans nos machines. A priori, même pour les machines bas de gamme, ce sont les processeurs mono-coeur qui vont se faire rares d'ici quelques mois.
[^]Re: Parallélisme, nouveau défi
J'ai lu récemment le dernier troll Tanenbaum vs. Linus, et sur ce coup là, Linus a largement gagné :)
Une bonne question aux aficionados des micronoyaux est "comment allez vous donner un accès matériel ala DRM/DRI aux applications ?"
[+] [^]Re: Parallélisme, nouveau défi
etrangement, quelque chose me dis qu'ils ne veulent pas des DRM/DRI...
[^]Re: Parallélisme, nouveau défi
On ne parle pas de WMA ici, mais de Direct Rendering Infrastructure, avec le Direct Rendering Manager en kernel-space. Et oui, ça fait des années que le noyau linux a des modules DRM depuis des années :)
http://dri.freedesktop.org/
http://www.google.com/codesearch?q=show:uSI_CHtkHCM:xMKMVx97(...)
[^]Re: Parallélisme, nouveau défi
Oups... j'avais pas compris... serais je un boulet ?
sinon, merci pour l'info, ça m'évitera de dire une connerie la prochaine fois !