Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
-- Software is like sex: It's better when it's free. Linus Torvalds
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est
foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle
est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en
particulier) qui ont l'air bien intéressant dans Hurd...
--
Software is like sex: It's better when it's free.
Linus Torvalds
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
-- Software is like sex: It's better when it's free. Linus Torvalds
Emmanuel Florac
Le Mon, 05 Sep 2011 16:26:44 +0200, remy a écrit:
7. introduire un peut de programmation objet au niveaux des drivers pour ne pas a subir les changements d'api
Le noyau est déjà écrit dans un style objet. Le changement d'ABI (et non pas d'API) est VOULU et RECHERCHÉ. Si tu veux une ABI stable, RedHat se charge de ça. Sinon il y a Solaris, aussi.
-- Pluralitas non est ponenda sine necessitate. Guillaume d'Ockham.
Le Mon, 05 Sep 2011 16:26:44 +0200, remy a écrit:
7. introduire un peut de programmation objet au niveaux des drivers pour
ne pas a subir les changements d'api
Le noyau est déjà écrit dans un style objet. Le changement d'ABI (et non
pas d'API) est VOULU et RECHERCHÉ. Si tu veux une ABI stable, RedHat se
charge de ça. Sinon il y a Solaris, aussi.
--
Pluralitas non est ponenda sine necessitate.
Guillaume d'Ockham.
7. introduire un peut de programmation objet au niveaux des drivers pour ne pas a subir les changements d'api
Le noyau est déjà écrit dans un style objet. Le changement d'ABI (et non pas d'API) est VOULU et RECHERCHÉ. Si tu veux une ABI stable, RedHat se charge de ça. Sinon il y a Solaris, aussi.
-- Pluralitas non est ponenda sine necessitate. Guillaume d'Ockham.
Stephane CARPENTIER
Emmanuel Florac wrote:
Le Mon, 05 Sep 2011 21:10:11 +0200, Stephane CARPENTIER a écrit:
La pratique, c'est que le noyau monolithique, c'est Linux avec tous ses défauts.
Oui, c'est bien ce que j'ai dit d'ailleurs si tu lis bien :)
Oui, mais il vaut mieux un utiliser truc foireux que d'attendre indéfiniment qu'un truc bien sorte un jour.
Emmanuel Florac wrote:
Le Mon, 05 Sep 2011 21:10:11 +0200, Stephane CARPENTIER a écrit:
La pratique, c'est que le noyau monolithique, c'est Linux avec tous ses
défauts.
Oui, c'est bien ce que j'ai dit d'ailleurs si tu lis bien :)
Oui, mais il vaut mieux un utiliser truc foireux que d'attendre indéfiniment
qu'un truc bien sorte un jour.
Le Mon, 05 Sep 2011 21:10:11 +0200, Stephane CARPENTIER a écrit:
La pratique, c'est que le noyau monolithique, c'est Linux avec tous ses défauts.
Oui, c'est bien ce que j'ai dit d'ailleurs si tu lis bien :)
Oui, mais il vaut mieux un utiliser truc foireux que d'attendre indéfiniment qu'un truc bien sorte un jour.
JKB
Le 05 Sep 2011 21:01:45 GMT, Emmanuel Florac écrivait :
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement à la légende urbaine, MacOS X non plus), mais sur un noyau hybride qui embarque un tas de choses qui ne devraient rien faire dans un micronoyau. En d'autres termes, le noyau de Hurd (comme celui de MacOS X) est pollué avec un tas d'"unixismes". Il y a deux problèmes à cela : 1/ un tas de trucs tourne dans le même plan mémoire que le noyau (gestion des processus et tout ce qui est attaché à cette gestion comme les sémaphores, les zones de mémoire partagée...) ; 2/ tu es obligé de penser Unix comme s'il n'y avait que ça dans la vie ; 3/ les autorisations sont directement issues du concept d'autorisation du monde Unix (alors qu'il existe des choses carrément plus intelligentes).
L'intérêt d'un micronoyau, c'est justement d'avoir un truc minimal (un L4/X2 n'a que 7 appels système, le reste est implanté sous la forme de serveurs) sur lequel tu fais ce que tu veux. Un micronoyau à la Hurd ou à la MacOS X est aberrant du point de vue technique. Le seul avantage est d'être un peu plus robuste qu'un noyau monolithique, mais à ce moment, autant aller au bout de la démarche puisque tu as déjà pénalisé ton OS en gérant des IPC.
Typiquement, un L4 ne gère que des threads dans des plans d'adressage. Rien d'autre. Il ne sait même pas ce qu'est un processus. Tu peux donc gérer des processus avec un paradigme bien mieux fichu que le paradigme Unix, par exemple en regardant un processus comme une ressource et non comme un service. Tu peux aussi décider que tous les pilotes tournent dans des espaces d'adressage distincts (ça permet d'émuler les niveaux de protection d'OS/2, de Multics ou de VMS sur un processeur qui ne les comprend pas), ce qui te permet d'avoir un système qui résiste au plantage d'un pilote sans avoir un abominable panic ou un oops.
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour cela que le développement est aussi lent. MacOS X est intensément développé, mais surtout parce que c'est un OS incontournable sur matériel Apple.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Hurd est loin d'être fini parce que le paradigme de base est
foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle
est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en
particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement
à la légende urbaine, MacOS X non plus), mais sur un noyau hybride
qui embarque un tas de choses qui ne devraient rien faire dans un
micronoyau. En d'autres termes, le noyau de Hurd (comme celui de
MacOS X) est pollué avec un tas d'"unixismes". Il y a deux problèmes
à cela :
1/ un tas de trucs tourne dans le même plan mémoire que le noyau
(gestion des processus et tout ce qui est attaché à cette gestion
comme les sémaphores, les zones de mémoire partagée...) ;
2/ tu es obligé de penser Unix comme s'il n'y avait que ça dans la
vie ;
3/ les autorisations sont directement issues du concept
d'autorisation du monde Unix (alors qu'il existe des choses
carrément plus intelligentes).
L'intérêt d'un micronoyau, c'est justement d'avoir un truc minimal
(un L4/X2 n'a que 7 appels système, le reste est implanté sous la
forme de serveurs) sur lequel tu fais ce que tu veux. Un micronoyau à
la Hurd ou à la MacOS X est aberrant du point de vue technique. Le
seul avantage est d'être un peu plus robuste qu'un noyau
monolithique, mais à ce moment, autant aller au bout de la démarche
puisque tu as déjà pénalisé ton OS en gérant des IPC.
Typiquement, un L4 ne gère que des threads dans des plans
d'adressage. Rien d'autre. Il ne sait même pas ce qu'est un
processus. Tu peux donc gérer des processus avec un paradigme bien
mieux fichu que le paradigme Unix, par exemple en regardant un
processus comme une ressource et non comme un service. Tu peux aussi
décider que tous les pilotes tournent dans des espaces d'adressage
distincts (ça permet d'émuler les niveaux de protection d'OS/2, de
Multics ou de VMS sur un processeur qui ne les comprend pas), ce qui
te permet d'avoir un système qui résiste au plantage d'un pilote
sans avoir un abominable panic ou un oops.
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour
cela que le développement est aussi lent. MacOS X est intensément
développé, mais surtout parce que c'est un OS incontournable sur
matériel Apple.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le 05 Sep 2011 21:01:45 GMT, Emmanuel Florac écrivait :
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement à la légende urbaine, MacOS X non plus), mais sur un noyau hybride qui embarque un tas de choses qui ne devraient rien faire dans un micronoyau. En d'autres termes, le noyau de Hurd (comme celui de MacOS X) est pollué avec un tas d'"unixismes". Il y a deux problèmes à cela : 1/ un tas de trucs tourne dans le même plan mémoire que le noyau (gestion des processus et tout ce qui est attaché à cette gestion comme les sémaphores, les zones de mémoire partagée...) ; 2/ tu es obligé de penser Unix comme s'il n'y avait que ça dans la vie ; 3/ les autorisations sont directement issues du concept d'autorisation du monde Unix (alors qu'il existe des choses carrément plus intelligentes).
L'intérêt d'un micronoyau, c'est justement d'avoir un truc minimal (un L4/X2 n'a que 7 appels système, le reste est implanté sous la forme de serveurs) sur lequel tu fais ce que tu veux. Un micronoyau à la Hurd ou à la MacOS X est aberrant du point de vue technique. Le seul avantage est d'être un peu plus robuste qu'un noyau monolithique, mais à ce moment, autant aller au bout de la démarche puisque tu as déjà pénalisé ton OS en gérant des IPC.
Typiquement, un L4 ne gère que des threads dans des plans d'adressage. Rien d'autre. Il ne sait même pas ce qu'est un processus. Tu peux donc gérer des processus avec un paradigme bien mieux fichu que le paradigme Unix, par exemple en regardant un processus comme une ressource et non comme un service. Tu peux aussi décider que tous les pilotes tournent dans des espaces d'adressage distincts (ça permet d'émuler les niveaux de protection d'OS/2, de Multics ou de VMS sur un processeur qui ne les comprend pas), ce qui te permet d'avoir un système qui résiste au plantage d'un pilote sans avoir un abominable panic ou un oops.
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour cela que le développement est aussi lent. MacOS X est intensément développé, mais surtout parce que c'est un OS incontournable sur matériel Apple.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Helena
On 2011-09-05, yves wrote:
Le 09/05/11 18:41, Stéphan Peccini a écrit :
ptilou a écrit Dans le message<3bcb05de-8fe3-4892-a0e3- :
Merci d'exprimer votre accord ou désaccord !
Je ne vois pas en quoi un système d'exploitation (désolé de faire l'amalgame) pourrait être génial. Un système marche plus ou moins bien mais de là à dire qu'il est génial ... il faut s'appeler Flavie Flament.
Mais je n'échangerais pas mon environnement GNU/Linux contre autre chose actuellement.
Méme pas contre un FreeBSD? ou *BSD
Faut vraiment avoir des besoins spécifique vu que BSD dispose de moins de drivers, moins de soft en même pas flash :)
On 2011-09-05, yves <local@fai.fr> wrote:
Le 09/05/11 18:41, Stéphan Peccini a écrit :
ptilou a écrit
Dans le message<3bcb05de-8fe3-4892-a0e3-
e68fd9830bfb@1g2000vbu.googlegroups.com> :
Merci d'exprimer votre accord ou désaccord !
Je ne vois pas en quoi un système d'exploitation (désolé de faire
l'amalgame) pourrait être génial. Un système marche plus ou moins bien mais
de là à dire qu'il est génial ... il faut s'appeler Flavie Flament.
Mais je n'échangerais pas mon environnement GNU/Linux contre autre chose
actuellement.
Méme pas contre un FreeBSD? ou *BSD
Faut vraiment avoir des besoins spécifique vu que BSD dispose de moins
de drivers, moins de soft en même pas flash :)
ptilou a écrit Dans le message<3bcb05de-8fe3-4892-a0e3- :
Merci d'exprimer votre accord ou désaccord !
Je ne vois pas en quoi un système d'exploitation (désolé de faire l'amalgame) pourrait être génial. Un système marche plus ou moins bien mais de là à dire qu'il est génial ... il faut s'appeler Flavie Flament.
Mais je n'échangerais pas mon environnement GNU/Linux contre autre chose actuellement.
Méme pas contre un FreeBSD? ou *BSD
Faut vraiment avoir des besoins spécifique vu que BSD dispose de moins de drivers, moins de soft en même pas flash :)
Tonton Th
On 09/05/2011 10:27 PM, JKB wrote:
Regarde un peu la doc d'un truc comme L4/X2, c'est ardu, mais le concept est largement supérieur à tout ce que j'ai pu voir.
Un lien vers ce point précis ?
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 09/05/2011 10:27 PM, JKB wrote:
Regarde un peu la doc d'un truc comme L4/X2,
c'est ardu, mais le concept est largement supérieur à tout ce que
j'ai pu voir.
Un lien vers ce point précis ?
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Regarde un peu la doc d'un truc comme L4/X2, c'est ardu, mais le concept est largement supérieur à tout ce que j'ai pu voir.
Un lien vers ce point précis ?
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
yves
Le 09/06/11 09:56, Helena a écrit :
On 2011-09-05, yves wrote:
Le 09/05/11 18:41, Stéphan Peccini a écrit :
ptilou a écrit Dans le message<3bcb05de-8fe3-4892-a0e3- :
Merci d'exprimer votre accord ou désaccord !
Je ne vois pas en quoi un système d'exploitation (désolé de faire l'amalgame) pourrait être génial. Un système marche plus ou moins bien mais de là à dire qu'il est génial ... il faut s'appeler Flavie Flament.
Mais je n'échangerais pas mon environnement GNU/Linux contre autre chose actuellement.
Méme pas contre un FreeBSD? ou *BSD
Faut vraiment avoir des besoins spécifique vu que BSD dispose de moins de drivers, moins de soft en même pas flash :)
FreeBSD a un systéme de ports assé fourni en logiciels (22462)
<http://www.freebsd.org/ports/>
FreeBSD moins de drivers c'est pas sur,exemple nvidia fournit les drivers freebsd
Le 09/06/11 09:56, Helena a écrit :
On 2011-09-05, yves<local@fai.fr> wrote:
Le 09/05/11 18:41, Stéphan Peccini a écrit :
ptilou a écrit
Dans le message<3bcb05de-8fe3-4892-a0e3-
e68fd9830bfb@1g2000vbu.googlegroups.com> :
Merci d'exprimer votre accord ou désaccord !
Je ne vois pas en quoi un système d'exploitation (désolé de faire
l'amalgame) pourrait être génial. Un système marche plus ou moins bien mais
de là à dire qu'il est génial ... il faut s'appeler Flavie Flament.
Mais je n'échangerais pas mon environnement GNU/Linux contre autre chose
actuellement.
Méme pas contre un FreeBSD? ou *BSD
Faut vraiment avoir des besoins spécifique vu que BSD dispose de moins
de drivers, moins de soft en même pas flash :)
FreeBSD a un systéme de ports assé fourni en logiciels (22462)
<http://www.freebsd.org/ports/>
FreeBSD moins de drivers c'est pas sur,exemple nvidia fournit les
drivers freebsd
ptilou a écrit Dans le message<3bcb05de-8fe3-4892-a0e3- :
Merci d'exprimer votre accord ou désaccord !
Je ne vois pas en quoi un système d'exploitation (désolé de faire l'amalgame) pourrait être génial. Un système marche plus ou moins bien mais de là à dire qu'il est génial ... il faut s'appeler Flavie Flament.
Mais je n'échangerais pas mon environnement GNU/Linux contre autre chose actuellement.
Méme pas contre un FreeBSD? ou *BSD
Faut vraiment avoir des besoins spécifique vu que BSD dispose de moins de drivers, moins de soft en même pas flash :)
FreeBSD a un systéme de ports assé fourni en logiciels (22462)
<http://www.freebsd.org/ports/>
FreeBSD moins de drivers c'est pas sur,exemple nvidia fournit les drivers freebsd
Regarde un peu la doc d'un truc comme L4/X2, c'est ardu, mais le concept est largement supérieur à tout ce que j'ai pu voir.
Un lien vers ce point précis ?
http://l4ka.org/l4ka/l4-x2-r7.pdf
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Helena
On 2011-09-06, JKB wrote:
Le 05 Sep 2011 21:01:45 GMT, Emmanuel Florac écrivait :
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement à la légende urbaine, MacOS X non plus), mais sur un noyau hybride qui embarque un tas de choses qui ne devraient rien faire dans un micronoyau.
Où l'on retombe dans le débat micronoyau vs piconoyau...
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour cela que le développement est aussi lent. MacOS X est intensément développé, mais surtout parce que c'est un OS incontournable sur matériel Apple.
Mais un piconoyau n'est pas ce que veut le peuple, parce que faire tourner les drivers (en particulier vidéo) dans un espace d'adressage à part va manger de la ressource processeur au grand plaisir de Phoronix (et d'un certain animal célèbre pour ses problèmes de fécondité et son régime à base de bambou) qui nous dira que c'est plus lent, donc c'est forcément moins bien.
On 2011-09-06, JKB <jkb@koenigsberg.invalid> wrote:
Hurd est loin d'être fini parce que le paradigme de base est
foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle
est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en
particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement
à la légende urbaine, MacOS X non plus), mais sur un noyau hybride
qui embarque un tas de choses qui ne devraient rien faire dans un
micronoyau.
Où l'on retombe dans le débat micronoyau vs piconoyau...
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour
cela que le développement est aussi lent. MacOS X est intensément
développé, mais surtout parce que c'est un OS incontournable sur
matériel Apple.
Mais un piconoyau n'est pas ce que veut le peuple, parce que faire
tourner les drivers (en particulier vidéo) dans un espace d'adressage à
part va manger de la ressource processeur au grand plaisir de Phoronix
(et d'un certain animal célèbre pour ses problèmes de fécondité et son
régime à base de bambou) qui nous dira que c'est plus lent, donc c'est
forcément moins bien.
Le 05 Sep 2011 21:01:45 GMT, Emmanuel Florac écrivait :
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement à la légende urbaine, MacOS X non plus), mais sur un noyau hybride qui embarque un tas de choses qui ne devraient rien faire dans un micronoyau.
Où l'on retombe dans le débat micronoyau vs piconoyau...
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour cela que le développement est aussi lent. MacOS X est intensément développé, mais surtout parce que c'est un OS incontournable sur matériel Apple.
Mais un piconoyau n'est pas ce que veut le peuple, parce que faire tourner les drivers (en particulier vidéo) dans un espace d'adressage à part va manger de la ressource processeur au grand plaisir de Phoronix (et d'un certain animal célèbre pour ses problèmes de fécondité et son régime à base de bambou) qui nous dira que c'est plus lent, donc c'est forcément moins bien.
JKB
Le Tue, 6 Sep 2011 08:12:09 +0000 (UTC), Helena écrivait :
On 2011-09-06, JKB wrote:
Le 05 Sep 2011 21:01:45 GMT, Emmanuel Florac écrivait :
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement à la légende urbaine, MacOS X non plus), mais sur un noyau hybride qui embarque un tas de choses qui ne devraient rien faire dans un micronoyau.
Où l'on retombe dans le débat micronoyau vs piconoyau...
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour cela que le développement est aussi lent. MacOS X est intensément développé, mais surtout parce que c'est un OS incontournable sur matériel Apple.
Mais un piconoyau n'est pas ce que veut le peuple, parce que faire tourner les drivers (en particulier vidéo) dans un espace d'adressage à part va manger de la ressource processeur au grand plaisir de Phoronix (et d'un certain animal célèbre pour ses problèmes de fécondité et son régime à base de bambou) qui nous dira que c'est plus lent, donc c'est forcément moins bien.
Non, c'est faux. C'est ce qui se passe avec les noyaux hybrides comme les Mach, XNU et consorts qui sont plein de unixismes. Un IPC sur noyau L4, c'est un peu plus d'une centaine de cycles pour transférer plusieurs Mo de données d'un pilote à un autre. Avec un scheduler à temps réel (et non un scheduler Unix de base), c'est parfaitement faisable sans perte de performances à une cadence de 30 images par seconde. Le problème du micronoyau, c'est qu'il faut raisonner micronoyau et non essayer de coller sur le micronoyau les concepts du noyau monolithique.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 6 Sep 2011 08:12:09 +0000 (UTC),
Helena <lna57005@gmail.com> écrivait :
On 2011-09-06, JKB <jkb@koenigsberg.invalid> wrote:
Hurd est loin d'être fini parce que le paradigme de base est
foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle
est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en
particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement
à la légende urbaine, MacOS X non plus), mais sur un noyau hybride
qui embarque un tas de choses qui ne devraient rien faire dans un
micronoyau.
Où l'on retombe dans le débat micronoyau vs piconoyau...
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour
cela que le développement est aussi lent. MacOS X est intensément
développé, mais surtout parce que c'est un OS incontournable sur
matériel Apple.
Mais un piconoyau n'est pas ce que veut le peuple, parce que faire
tourner les drivers (en particulier vidéo) dans un espace d'adressage à
part va manger de la ressource processeur au grand plaisir de Phoronix
(et d'un certain animal célèbre pour ses problèmes de fécondité et son
régime à base de bambou) qui nous dira que c'est plus lent, donc c'est
forcément moins bien.
Non, c'est faux. C'est ce qui se passe avec les noyaux hybrides
comme les Mach, XNU et consorts qui sont plein de unixismes. Un IPC
sur noyau L4, c'est un peu plus d'une centaine de cycles pour
transférer plusieurs Mo de données d'un pilote à un autre. Avec un
scheduler à temps réel (et non un scheduler Unix de base), c'est
parfaitement faisable sans perte de performances à une cadence de 30
images par seconde. Le problème du micronoyau, c'est qu'il faut raisonner
micronoyau et non essayer de coller sur le micronoyau les concepts du
noyau monolithique.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 6 Sep 2011 08:12:09 +0000 (UTC), Helena écrivait :
On 2011-09-06, JKB wrote:
Le 05 Sep 2011 21:01:45 GMT, Emmanuel Florac écrivait :
Le Mon, 05 Sep 2011 20:24:47 +0000, JKB a écrit:
Hurd est loin d'être fini parce que le paradigme de base est foireux. Il y a eu une étincelle avec Hurd/L4, mais la vision actuelle est carrément mauvaise.
Des détails? Parce qu'il y a des concepts (d'autorisations en particulier) qui ont l'air bien intéressant dans Hurd...
Hurd ne fonctionne pas sur un micronoyau (d'ailleurs, contrairement à la légende urbaine, MacOS X non plus), mais sur un noyau hybride qui embarque un tas de choses qui ne devraient rien faire dans un micronoyau.
Où l'on retombe dans le débat micronoyau vs piconoyau...
Bref, Hurd, c'est une fausse bonne idée, et c'est certainement pour cela que le développement est aussi lent. MacOS X est intensément développé, mais surtout parce que c'est un OS incontournable sur matériel Apple.
Mais un piconoyau n'est pas ce que veut le peuple, parce que faire tourner les drivers (en particulier vidéo) dans un espace d'adressage à part va manger de la ressource processeur au grand plaisir de Phoronix (et d'un certain animal célèbre pour ses problèmes de fécondité et son régime à base de bambou) qui nous dira que c'est plus lent, donc c'est forcément moins bien.
Non, c'est faux. C'est ce qui se passe avec les noyaux hybrides comme les Mach, XNU et consorts qui sont plein de unixismes. Un IPC sur noyau L4, c'est un peu plus d'une centaine de cycles pour transférer plusieurs Mo de données d'un pilote à un autre. Avec un scheduler à temps réel (et non un scheduler Unix de base), c'est parfaitement faisable sans perte de performances à une cadence de 30 images par seconde. Le problème du micronoyau, c'est qu'il faut raisonner micronoyau et non essayer de coller sur le micronoyau les concepts du noyau monolithique.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
