Mon Dieu.. On en tient un beau. Je me demandais quand ils allaient arriver, les gens qui, en dépit de tout ce qu'on peut leur répondre, tienne toujours le même discours, toujours le même, uniforme, sans rien.
Hurd = 10 ans de développement et toujours pas pret
Où ? Quand ? Le Hurd n'est pas activement développé depuis dix ans. Du tout. Son développement a commencé en '90, il est vrai. Mais, il est généralement admis que son développement a été arrêté pendant près de sept ans, pour n'être repris environ qu'en 99, et que de façon très progressive, le temps que le Hurd sorte de cette réputation de projet du passé dont tu es la preuve vivante qu'elle n'a pas cessé.
Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
De quoi ? Si le Hurd apporte de nombreux avantages aux développeurs, il me semble avoir suffisamment dit et montré comment une architecture basée sur un micro-noyau pouvait apporter nombre d'avantages à l'utilisateur, notamment en lui permettant d'avoir ses propres montages - notamment, NFS - très facilement, comment il pouvait, via un « addauth » acquérir facilement des droits plus élevés sans avoir le mot de passe root, etc. De plus, il me semble que c'est l'affaire de tous d'avoir une machine qui ne reboote pas pour un rien, une machine extrêmement sécurisée, qui n'a
pas besoin d'être rebootée de façon régulière pour mise à jour du noyau, etc.
Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
As-tu déjà regardé une seule fois les sources d'un programme qui fait usage du système d'IPC que tu évoques ? Le développement de telles applications n'a _rien_ de complexe. Ce qui est complexe, en revanche, effectivement, c'est de repenser une architecture de fond en comble, d'essayer de faire tout de la meilleure façon possible plutôt que de le faire de façon à ce que ça marche maintenant, et qu'après, on se rende compte que c'est absolument immaintenable, inadaptable, et qu'il faut tout refaire un nombre impressionant de fois..
Effectivement, le développement de Linux a été beaucoup plus facile, puisque, comme le disait très justement Linus il n'y a pas longtemps, Linux n'a pas de design, il se contente de reprendre tous les principes utilisés par Unix - dont l'utilité a certes été prouvée, mais 30 ans d'utilisation d'Unix a aussi montré que ce système avait un certaines nombres d'erreurs de conceptions, et qu'il n'était pas forcément adapté
aux systèmes d'aujourd'hui de bien des manières. Mais, devrait-on pour autant se contenter de refaire à chaque fois la même chose, par des gens différents ? (avec la différence, certes, que Linux est un logiciel libre, ce qui était son avantage majeur.) L'évolution serait donc totalement condamnée dans le monde de l'informatique ? Je ne l'espère pas.
De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles.
De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence. En revanche, pour aborder le thème de la performance des systèmes à base de micro-noyaux, il est claire qu'elle n'est pas évidente, étant donner qu'un système multi-serveurs à micro-noyau implique une multiplication des changements de contexte, et des appels noyaux concernant l'IPC. L'important est justement à ce niveau: pour qu'un système à base de micro-noyau soit rapide, au moins aussi rapide si ce n'est plus qu'un système à base de noyau monolithique, il faut que ces appels concernant l'IPC soient extrêmement lightweight, extrêmement rapides, et n'entraînes pas le même coût en performance qu'un appel système « traditionnel. ».
Dans le cas de Mach, c'était déjà le cas: les appels à mach_msg étaient _extrêmement_ moins coûteux que les autres kernel traps. Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident. La rapidité, et la concision, ont été tdepuis le début le but du projet L4, comme je l'ai déjà dit. Ils y sont _vraiment_ parvenus, grâce à des moyens très intéressants et très savants, expliqués pour beaucoup sur http://www.l4ka.org/publications/(...) . De plus, une fois le problème de l'IPC réglé, l'architecture à base de micro-noyaux peut s'avérer plus performante qu'une architecture à base de noyaux monolithiques. En effet, nombre d'appels qui sont traditionellement des appels systèmes ne sont plus implémentés dans le noyau, mais dans la libc (C Library), et ne se servent que de RPC vers les programmes chargés de l'exécution réelle de tels appels. Ainsi, ils économisent le gros overhead produit par un appel système « traditionnel » dans un programme.. (qui n'est pas négligeable: vous êtes vous déjà interrogés sur le pourquoi de la stdio - bufferisée, donc - alors qu'on pourrait utiliser read() et write() - comme woof - ? Avez-vous déjà comparé les performances d'un programme effectuant des opérations d'I/O fréquentes utilisant read()/write() ou printf()/fgets() ?)
ertes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi.
Argument frappant, je dois le dire. Quand l'article, d'une dizaine de pages, te décris en détail les modifications effectuées sur Linux pour qu'il soit porté sur L4, ce qu'on a testé précisément - et pourquoi - et qu'il te donne les performances obtenues par différentes batteries de tests réalisées par des logiciels _indépendants_ des auteurs, et qui ont été choisis parmi les meilleurs, et qu'il se trouve que ce benchmark est très facilement reproductible, qu'il l'a été fait, et que les résultats ont toujours été dans le même ordre d'idée, voire même meilleurs que ceux proposés dans le document, je sais pas que demander de plus.. Si tous les benchmarks pouvaient être aussi clairs, impartials, ...
D'autant plus que ce benchmark n'a pas été fait dans un but de FUD, puisqu'il ne s'agit pas pour l'équipe de L4Ka - des universitaires, principalement - de vendre leur produit, mais bien de tester leurs avancées _réelles_, pour eux-même, dans un but scientifique...
Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver.
Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ? J'ai sous la main un L4Linux tout à fait disponible, et en mesure d'exécuter tout test que tu désirerais lui faire subir.
Personnellement Java => ajout d'un couche d'abstraction (vm) => super long.
Quel rapport ? Il n'y a pas de « couche d'abstraction », ou en tous pas à la base, dans le Hurd. Le micro-noyau n'est pas du tout une couche d'abstraction.
cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau).
Cela reste à prouver.. De plus, de telles pratiques s'avèrent être, de fait, des pratiques courantes dans des énormes développements propriétaires comme l'est Windows, où les développeurs cèdent souvent à la facilité - car l'utilisation d'un « fourre-tout ·» reste toujours plus aisée dans un premier temps que la séparation laire, la modularité. Ainsi, le programmeur débutant a toujours tendance à faire un seul fichier source, une seule fonction, etc. La programation d'un système multi-serveurs à base de micro-noyau demande effectivement plus de rigueur.
De plus, les principes des développeurs du Hurd - toujours au mieux, toujours différent - rendent effectivement le développement du Hurd un peu plus difficile. Mais je suis convaincu que, comme la séparation interface/reste, la séparation en modules, fonctions, etc., cette rigueur, difficile à acquérir au début, rend beaucoup de tâches pour la suite des choses beaucoup plus faciles.
Notamment, le fait que toutes ces facilités ayant recours à des hacks x86-only - mais performants - aient été refusés de tout temps par les concepteurs du Hurd a permis à des gens de porter le Hurd sur PPC en à peine quelques jours et 2/3 modifications.. Comparez avec le temps qu'il a fallu pour un port de Linux sur PPC, et sur l'avancée de ce port.
les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon.
C'est cette partie qui me fait franchement penser qu'il s'agit d'un fake - voire d'un piège à Kilobug. Mais, ces arguments étant extrêmement classiques, je tiens à y répondre une fois pour toutes.
Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
Le Hurd, basé sur GNU Mach, est aujourd'hui nettement moins performant que Linux, pour de multiples raisons. On ne peut pas comparer les performances d'un logiciel se voulant être à la base de systèmes utilisés partout dès maintenant, et un projet qui n'est pas abouti et dont le développement est loin d'être fini..
De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
Ceux qui profèrent ce genre de non-sens sont des ânes. Mais, qu'est-ce que cela a à voir avec le sujet qui nous occupe ?
Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.
Tu compares des choses qui n'ont rien à voir.. Ai-je cité, dans tous mes posts, des choses qui seraient faisables avec les modules Linux ? Je ne le pense sincèrement pas. Les modules ont été une grande avancée pour Linux, et ce sont de très bonnes choses. D'ailleurs, les modules chargeables dynamiquement existent également dans certaines versions de Mach - puisque traditionellement, les drivers matériels sont dans Mach et non en user space, bien que ce micro-noyau le permette - en offrant la possibilité d'envoyer des messages spéciaux au micro-noyau qui se chargent de les traduire en interruptions matérielles.
Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher.
Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi. Je ne peux prévoir l'avenir du Hurd, l'avenir de GNU, ni l'avenir de GNU. Si tu veux montrer que le Hurd n'a aucun avenir, attends. Et s'il ne triomphe jamais, tu pourras jubiler en te disant « j'avais raison! ». En attendant, tu n'as pas de moyen de démontrer tes propos, si ce n'est d'attendre. Alors, je te propose que tu attendes en faisant autre chose, pendant qu'on continue notre projet. Et voyons bien ce qui arrivera.
N'en déplaise à Stallman et à son égo surmesurer.
Encore un non-argument, trollesque, sans _aucun_ intérêt - nous sommes pas là pour juger des personnes, que tu ne connais pas personellement, qui plus est. Et je ne pense pas que la mort du Hurd soit un tel drame pour Stallman: il l'a cru mort - Stallman suit peu le développement du Hurd, il faut l'avouer - pendant longtemps, et il a l'air de tenir le choc.
[^] # Re: RMS est mort, vive Linus
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 6.
Les micros noyau, ca pue
J'ai déjà répondu à ça, exactement le même titre. Je t'invite à consulter: http://linuxfr.org/comments/thread.php3?news_id=6461&com_id=889(...)
et si tu as des arguments, de venir nous voir, sur #hurdfr sur OpenProjects, notamment.
Hurd = 10 ans de développement et toujours pas pret
Où ? Quand ? Le Hurd n'est pas activement développé depuis dix ans. Du tout. Son développement a commencé en '90, il est vrai. Mais, il est généralement admis que son développement a été arrêté pendant près de sept ans, pour n'être repris environ qu'en 99, et que de façon très progressive, le temps que le Hurd sorte de cette réputation de projet du passé dont tu es la preuve vivante qu'elle n'a pas cessé.
Le but d'un micro-noyau c'est surtout pour les développeurs, possibilité de développer des modules en mode utilisateur, possibilité d'avoir des systèmes de fichier en tournant en mode utilisateur, ...
De quoi ? Si le Hurd apporte de nombreux avantages aux développeurs, il me semble avoir suffisamment dit et montré comment une architecture basée sur un micro-noyau pouvait apporter nombre d'avantages à l'utilisateur, notamment en lui permettant d'avoir ses propres montages - notamment, NFS - très facilement, comment il pouvait, via un « addauth » acquérir facilement des droits plus élevés sans avoir le mot de passe root, etc. De plus, il me semble que c'est l'affaire de tous d'avoir une machine qui ne reboote pas pour un rien, une machine extrêmement sécurisée, qui n'a
pas besoin d'être rebootée de façon régulière pour mise à jour du noyau, etc.
Le problème c'est que si le passage de messages et la communication entre les processus rend le développement tellement compliqué qu'il multiplie le temps de développement par 10 je vois pas trop l'intéret pour les développeurs d'utiliser un m icro-noyau.
As-tu déjà regardé une seule fois les sources d'un programme qui fait usage du système d'IPC que tu évoques ? Le développement de telles applications n'a _rien_ de complexe. Ce qui est complexe, en revanche, effectivement, c'est de repenser une architecture de fond en comble, d'essayer de faire tout de la meilleure façon possible plutôt que de le faire de façon à ce que ça marche maintenant, et qu'après, on se rende compte que c'est absolument immaintenable, inadaptable, et qu'il faut tout refaire un nombre impressionant de fois..
Effectivement, le développement de Linux a été beaucoup plus facile, puisque, comme le disait très justement Linus il n'y a pas longtemps, Linux n'a pas de design, il se contente de reprendre tous les principes utilisés par Unix - dont l'utilité a certes été prouvée, mais 30 ans d'utilisation d'Unix a aussi montré que ce système avait un certaines nombres d'erreurs de conceptions, et qu'il n'était pas forcément adapté
aux systèmes d'aujourd'hui de bien des manières. Mais, devrait-on pour autant se contenter de refaire à chaque fois la même chose, par des gens différents ? (avec la différence, certes, que Linux est un logiciel libre, ce qui était son avantage majeur.) L'évolution serait donc totalement condamnée dans le monde de l'informatique ? Je ne l'espère pas.
De plus rajouter des interfaces et des couches d'abstraction c'est peut-etre beau sur le papier, mais à chaque fois ca entraine des chutes de performance terribles.
De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence. En revanche, pour aborder le thème de la performance des systèmes à base de micro-noyaux, il est claire qu'elle n'est pas évidente, étant donner qu'un système multi-serveurs à micro-noyau implique une multiplication des changements de contexte, et des appels noyaux concernant l'IPC. L'important est justement à ce niveau: pour qu'un système à base de micro-noyau soit rapide, au moins aussi rapide si ce n'est plus qu'un système à base de noyau monolithique, il faut que ces appels concernant l'IPC soient extrêmement lightweight, extrêmement rapides, et n'entraînes pas le même coût en performance qu'un appel système « traditionnel. ».
Dans le cas de Mach, c'était déjà le cas: les appels à mach_msg étaient _extrêmement_ moins coûteux que les autres kernel traps. Cependant, Mach n'est pas un modèle de vélocité, et faire un système performant basé sur ce micro-noyau n'est pas évident. La rapidité, et la concision, ont été tdepuis le début le but du projet L4, comme je l'ai déjà dit. Ils y sont _vraiment_ parvenus, grâce à des moyens très intéressants et très savants, expliqués pour beaucoup sur http://www.l4ka.org/publications/(...) . De plus, une fois le problème de l'IPC réglé, l'architecture à base de micro-noyaux peut s'avérer plus performante qu'une architecture à base de noyaux monolithiques. En effet, nombre d'appels qui sont traditionellement des appels systèmes ne sont plus implémentés dans le noyau, mais dans la libc (C Library), et ne se servent que de RPC vers les programmes chargés de l'exécution réelle de tels appels. Ainsi, ils économisent le gros overhead produit par un appel système « traditionnel » dans un programme.. (qui n'est pas négligeable: vous êtes vous déjà interrogés sur le pourquoi de la stdio - bufferisée, donc - alors qu'on pourrait utiliser read() et write() - comme woof - ? Avez-vous déjà comparé les performances d'un programme effectuant des opérations d'I/O fréquentes utilisant read()/write() ou printf()/fgets() ?)
ertes il y aura toujours des articles pour dire que la perte de performance n'est pas si terrible que ca, mais il y a toujours des articles pour dire n'importe quoi.
Argument frappant, je dois le dire. Quand l'article, d'une dizaine de pages, te décris en détail les modifications effectuées sur Linux pour qu'il soit porté sur L4, ce qu'on a testé précisément - et pourquoi - et qu'il te donne les performances obtenues par différentes batteries de tests réalisées par des logiciels _indépendants_ des auteurs, et qui ont été choisis parmi les meilleurs, et qu'il se trouve que ce benchmark est très facilement reproductible, qu'il l'a été fait, et que les résultats ont toujours été dans le même ordre d'idée, voire même meilleurs que ceux proposés dans le document, je sais pas que demander de plus.. Si tous les benchmarks pouvaient être aussi clairs, impartials, ...
D'autant plus que ce benchmark n'a pas été fait dans un but de FUD, puisqu'il ne s'agit pas pour l'équipe de L4Ka - des universitaires, principalement - de vendre leur produit, mais bien de tester leurs avancées _réelles_, pour eux-même, dans un but scientifique...
Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver.
Soit plus précis. Que proposerais-tu de tester que les réalisateurs du benchmark n'ont pas testés ? J'ai sous la main un L4Linux tout à fait disponible, et en mesure d'exécuter tout test que tu désirerais lui faire subir.
Personnellement Java => ajout d'un couche d'abstraction (vm) => super long.
Quel rapport ? Il n'y a pas de « couche d'abstraction », ou en tous pas à la base, dans le Hurd. Le micro-noyau n'est pas du tout une couche d'abstraction.
cependant, je trouve qu'un des seules avantages de windows sur Linux est justement d'etre plus rapide au niveau de l'affichage (car le système de fenêtrage et justement dans le noyau).
Cela reste à prouver.. De plus, de telles pratiques s'avèrent être, de fait, des pratiques courantes dans des énormes développements propriétaires comme l'est Windows, où les développeurs cèdent souvent à la facilité - car l'utilisation d'un « fourre-tout ·» reste toujours plus aisée dans un premier temps que la séparation laire, la modularité. Ainsi, le programmeur débutant a toujours tendance à faire un seul fichier source, une seule fonction, etc. La programation d'un système multi-serveurs à base de micro-noyau demande effectivement plus de rigueur.
De plus, les principes des développeurs du Hurd - toujours au mieux, toujours différent - rendent effectivement le développement du Hurd un peu plus difficile. Mais je suis convaincu que, comme la séparation interface/reste, la séparation en modules, fonctions, etc., cette rigueur, difficile à acquérir au début, rend beaucoup de tâches pour la suite des choses beaucoup plus faciles.
Notamment, le fait que toutes ces facilités ayant recours à des hacks x86-only - mais performants - aient été refusés de tout temps par les concepteurs du Hurd a permis à des gens de porter le Hurd sur PPC en à peine quelques jours et 2/3 modifications.. Comparez avec le temps qu'il a fallu pour un port de Linux sur PPC, et sur l'avancée de ce port.
les belles idées sur le papier on a vu ce que ca a donné avec le communiste et apparemment on peut généraliser à pas mal de domaine la leçon.
C'est cette partie qui me fait franchement penser qu'il s'agit d'un fake - voire d'un piège à Kilobug. Mais, ces arguments étant extrêmement classiques, je tiens à y répondre une fois pour toutes.
Le seul micro noyau que j'ai utilisé pour l'instant est minix (qui est nettement plus long que linux), mais j'ai des copains qui ont utilisés Hurd et Mac OS X et il m'ont dit que les performances étaient moins bonne que sur les OS monolithiques.
Le Hurd, basé sur GNU Mach, est aujourd'hui nettement moins performant que Linux, pour de multiples raisons. On ne peut pas comparer les performances d'un logiciel se voulant être à la base de systèmes utilisés partout dès maintenant, et un projet qui n'est pas abouti et dont le développement est loin d'être fini..
De plus j'ai lu qq part que de toutes facon on n'avait de plus en plus de ressources processeurs et donc que les performances n'étaient pas si primordiales que ca. Cet argument est l'argument (récurrent) e plus débile de l'histroire de l'informatique. On aura _jamais_ trop de ressource et donc on se doit de concevoir les systèmes le plus efficacement possible.
Ceux qui profèrent ce genre de non-sens sont des ânes. Mais, qu'est-ce que cela a à voir avec le sujet qui nous occupe ?
Quand à la modularité, avec Linux on a la modularité au niveau du source. De plus les modules ne constituent pas du rafistolage mais plutot le juste milieu.
Tu compares des choses qui n'ont rien à voir.. Ai-je cité, dans tous mes posts, des choses qui seraient faisables avec les modules Linux ? Je ne le pense sincèrement pas. Les modules ont été une grande avancée pour Linux, et ce sont de très bonnes choses. D'ailleurs, les modules chargeables dynamiquement existent également dans certaines versions de Mach - puisque traditionellement, les drivers matériels sont dans Mach et non en user space, bien que ce micro-noyau le permette - en offrant la possibilité d'envoyer des messages spéciaux au micro-noyau qui se chargent de les traduire en interruptions matérielles.
Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher.
Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi. Je ne peux prévoir l'avenir du Hurd, l'avenir de GNU, ni l'avenir de GNU. Si tu veux montrer que le Hurd n'a aucun avenir, attends. Et s'il ne triomphe jamais, tu pourras jubiler en te disant « j'avais raison! ». En attendant, tu n'as pas de moyen de démontrer tes propos, si ce n'est d'attendre. Alors, je te propose que tu attendes en faisant autre chose, pendant qu'on continue notre projet. Et voyons bien ce qui arrivera.
N'en déplaise à Stallman et à son égo surmesurer.
Encore un non-argument, trollesque, sans _aucun_ intérêt - nous sommes pas là pour juger des personnes, que tu ne connais pas personellement, qui plus est. Et je ne pense pas que la mort du Hurd soit un tel drame pour Stallman: il l'a cru mort - Stallman suit peu le développement du Hurd, il faut l'avouer - pendant longtemps, et il a l'air de tenir le choc.