Et Richard Stallman de rajouter dans une interview à PCWorld : "We actually have the GNU kernel working, and we can now produce the GNU system, as opposed to the GNU/Linux system that people have been using so far". (TdM: "Le kernel GNU fonctionne, et nous sommes maintenant en mesure de produire le système GNU, par opposition au système GNU/Linux que les gens utilisaient jusqu'à maintenant".)
La mort annoncée de GNU/Linux ?
Note du modérateur : j'ajoute les liens vers l'interview en question et vers Hurdfr.org. La news originale contenait un lien vers OSNews qui semble cassé, je le remplace par un lien vers Slashdot.
![[en]](../images/en.png)
La news sur Slashdot (732 hits)-
L'interview de RMS (524 hits)
![[fr]](../images/fr.png)
HurdFR (2126 hits)
> Lire la dépêche (140 commentaires, moyenne: 4,9).
Vous avez demandé le commentaire #102279.
Run by 
Cette page a été générée par Templeet en 0.1177s (dont 0.009 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Retour vers le futur
The Hurd kernel of FSF's GNU system is more powerful than
Linux because it is designed using a microkernel instead of a
monolithic architecture, Stallman said.
C'est marrant, j'ai deja entendu ca :)
[^]Re: linux is obsolete
tu veux dire ici:
http://alge.anart.no/linux/history/linux_is_obsolete.txt(...)
[^]Re: Retour vers le futur
Tout dépend de ce que l'on veut dire par "more powerful", mais d'un certain point de vue, un µnoyau est quand meme très intéressant !
Sans vouloir relancer le tro^H^H débat, le noyau Linux se fait quand meme de plus en plus volumineux...
[+] [^]Re: Retour vers le futur
> le noyau Linux se fait quand meme de plus en plus volumineux...
prend une distribution qui utilise un 1.2.x si c'est un critere important et que t'as pas 50 Euro pour 256 Mo.
Ca me souale ces gnagna gnagni... Ces gus jamais content alors qu'ils ont pour gratos le top (ou presque).
[+] [^]Re: Retour vers le futur
Et tu les place ou tes 256Mo sur ton grille pain ?
Y a pas que les 'PC' qui font tourner Linux... Et puis on ne parle pas des applications autour de Linux qui sont lourdes : on parle du noyau...
[^]Re: Retour vers le futur
Evidemment, si tu prend le code source de linux avec les drivers de plein de périphériques, c'est énorme, mais le 2.4 prend moins de place qu'un 2.2 en mémoire... (avec les mêmes pilotes de périphériques...), de même, il est plutôt plus rapide... donc... je vois pas trop d'où vient le problème.
[^]Re: Retour vers le futur
Le probleme, c'est que si on suit la tendance actuelle, et en exagérant un peu, on va finir par se retrouver avec emacs dans le noyau !
Note que j'aime bien emacs, et que ca serait pas mieux avec vi, mais la conception des µnoyaux découpe plus, et ne met normalement en mode noyau que le strict nécessaire, et ca, c'est a priori une bonne idée (d'un point de vue propreté / stabilité, pas forcément performances).
[^]Retour vers le futur IV
Le HURD est bientôt là....
Il y a 10 ans, c'était l'arlésienne, la vaporware hypothétique de demain loin-là-bas...
On l'appellait pas encore "LE" hurd, mais simplement HURD. gcc, emacs, c'était pour les affranchis. Désormais, tout le monde les utilise, alors le monde est mûr pour HURD.
Le simple fait qu'il parvienne à éclore, c'est déjà la réalisation d'un rêve.
HURD et Linux ne sont pas ennemis mais frères, un peu différents, comme tous les frères qui ne sont pas jumeaux. HURD est plus vieux, encore immature, et Linux est le petit frère précoce qui n'en veut.
Celui qui prétend le contraire n'a quà répondre à la question suivante: Avec quoi fut compilé Linux le premier jour ? GCC.
Qu'est-ce que gcc ? La première fondation du GNU HURD.
Demain ne peut être que meilleur, car HURD est sur le point de naître. La liberté gagne la terre et vaincra
[^]Re: Retour vers le futur
Linus déteste emacs (et Stallman et et les unoyaux (donc Hurd) comme tout le monde sait), donc ca m'étonnerait vraiment que le noyau de Linux se mettent à ressembler à Emacs. Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées, contrairement à la branche maintenu par Alan Cox.
[^]Re: Retour vers le futur
Le noyau officiel est très nettement conservateur et seule les fonctionnalités que Linus trouve vraiment importantes sont ajoutées,
Sauf que Linus a parfois des goûts très bizarres: un serveur Web dans le noyau, un changement de VM en plein milieu d'une branche stable, refus d'intégrer des patchs pour le PCI 64-bits ou les nouvelles normes ATA, intégration de ReiserFS dans le 2.4.1 qui devait ne contenir que des bugs fixes, ...
Je respecte beaucoup Linus et je trouve que globalement il fait du très bon boulot, mais il commet aussi parfois de grosses erreurs AMHA, et son obstination à dénigrer les micro-noyaux et le Hurd frise parfois le ridicule (par exemple sur le coup du MAP_COPY où il reproche à l'équipe du Hurd quelque chose qui est lié à GNU Mach et non au Hurd)
[^]Re: Retour vers le futur
Euh, mettre 256Mo sur mon 486 qui fait Gateway ou sur mon Amiga 1200, c'est un peu plus cher que 50Euros, et un peu moins facile aussi.....
[+] [^]Re: Retour vers le futur
The Hurd kernel of FSF's GNU system is more powerful than Linux because it is designed using a microkernel instead of a monolithic architecture, Stallman said.
Puissant => bouffe plus le CPU => plus lent ;)
[^]Re: Retour vers le futur
Lis les docs que l'on trouve sur http://www.l4ka.org/publications/(...) et en particulier http://os.inf.tu-dresden.de/pubs/sosp97/(...) et tu verras que les performances d'un système à base de micro-noyau ne sont pas nécessairement beaucoup plus faibles que celles des systèmes à base de noyau monolithique.
[^]Re: Retour vers le futur
En l'occurence, pour l'instant, sur un système "monolithique" du genre PC, entre Linux et Hurd, pour l'instant y'a pas photo ...
Par contre sur une machine bien parallèlle, peut être que la tendance s'inverse.
Mais comme aujourd'hui la plupart des systèmes que l'on rencontre sont des PC ...
[^]Re: Retour vers le futur
Euh... lis les articles justement. Un simple port brutal de Linux sur L4 ne donne que 5% de perte de performances, alors que ce port n'utilise pas les capacités particulières des micro-noyaux, et que ce test a été réalisé il y a longtemps et que beaucoup de progrès sur l'IPC ont été fait dans L4 depuis.
Actuellement le Hurd est plutôt lent car non optimisé (par contre les développeurs savent comment faire pour l'optimiser, ce n'est pas la priorité c'est tout) et qu'il utilise GNU Mach, qui n'est pas non plus un modèle de vélocité.
Mais à terme, lorsque le Hurd sera sur L4, la différence de vitesse entre GNU et GNU/Linux devrait être négligeable, surtout comparé à tout ce que GNU apporte (et à la puissance des machines qui s'accroit sans cesse, le CPU étant rarement le facteur limitant d'une machine)
[+] [^]Re: Retour vers le futur
De plus, sur ce qui a été précisé au dessus , la plus part des kernels linux utilisé sont modulaires, et non monolythique ...
est ce que le modulaire et le monolythique sont aussi rapide ?
@++
Code34
[^]Re: Retour vers le futur
Le noyau Linux est monolithique dans le sens où en mémoire le noyau est un seul gros programme qui tourne en mode noyau, et où un bug dans un module noyau peut avoir des conséquences sur tout le reste du noyau. Par contre c'est un noyau modulaire, puisqu'il est possible de charger/décharger des modules en cours d'exécution (Linux est donc monolithique modulaire).
D'un point de vue performances, il y a un très léger surcoût à utiliser des modules, de l'ordre de quelques cycles CPU par appel système se trouvant dans un module (la valeur exacte se trouve dans "Le noyau Linux" de chez O'Reilly, je pourrais regarder chez moi), mais concrètement c'est totalement négligeable (sachant qu'un kernel trap a déjà un coût moyen estimé d'environ 170 cycles, sans compter le traitement de l'appel système, les quelques cycles de plus ne sont vraiment pas importants).
[^]Re: Retour vers le futur
Monolithique mais très modulaire !!
Donc si t'as pas besoin, tu prends pas.
Je pense que la taille du noyau n'est pas un critère puisque ce qui ne sera pas dans le noyau pour HURD, le sera dans un module en mode user.
[^]Re: Retour vers le futur
Oui, mais c'est une différence de taille.
Un programme sans bugs ça n'existe pas. Un plus un programme est gros, plus il a de risques d'être buggué (à toutes autres choses égales). Donc plus tu as de code qui s'exécute en mode noyau, plus tu as de bugs potentiels en mode noyau. Or, un bug d'un programme s'exécutant en mode noyau peut avoir des conséquences gravissimes, allant du plantage au trou de sécurité, en passant par la corruption de données, voir des dégâts sur le matériel dans des cas extrêmes.
Dans le cas du Hurd où on a une collection (un troupeau ;) ) de serveurs indépendants qui tournent en mode utilisateur, un bug dans l'un de ces serveurs a des conséquences beaucoup plus réduites sur le système en général. Sans compter que pour débugguer un module noyau c'est beaucoup plus compliqué qu'un serveur du Hurd, qui lui se débugue comme un programme normal avec gdb, la libefence et autres.
Mettre un "module" en mode noyau, c'est jouer avec le feu, c'est lier le sort du système entier au sort du programme, et c'est donc à éviter autant que possible.
[+] [^]Re: Retour vers le futur
C'est pas vraiment fonction de la taille c'est fonction de la compléxité.
Par exemple, faire un petit tableur en assembleur modulaire aura surement plus de bug qu'un intégré à la xxxxx office. Et la complexité vient avant tout de la conception.
Le débat est vieux d'au moins 10 ans:
http://www2.educ.umu.se/~bjorn/mhonarc-files/obsolete/msg00000.html(...)
Je ne dirais qu'une chose à propos de Linux :
et pourtant il tourne.
De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte
[^]Trop gros, passera
De toute façon, GNU n'est pas un logiciel, c'est au mieux une secte
................_---________---__________.............................
...............|..........PLEASE.........}............................
...............|.........................}............................
............../....DO.NOT.FEED.THE.TROLL.\............................
..............\____....................__/............................
...................-------------------`...............................
...........................|#:|.......................................
...........................|#:|.......................................
...........................|#:|.......................................
........................\\\|#:|/./....................................
............~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.......................
-1
[^]la guerre des kernels
Personnellement, du point de vue de la rapidité, je ne pense pas qu'il puisse y avoir une différence flagrante.
Je vois cependant un avantage MAJEUR aux microkernels : rappelez des OS du style BE, dans le repertoire utilisateur, on peut charger ses modules, qui fonctionnement en mode utilisateur, j'avais adoré ca. si le module deconne, on efface.
C'est idéal pour tester une config pour eventuellement la valider et généraliser le module qu'on aura préalablement testé en faisant un simple copier-coller en root. Les utilisateurs pourront choisir les modules de leur choix et chaque utilisateur pourra avoir son hurd perso.
C'est quand même assez génial à mon avis.
Je vois un inconvénient, cependant. Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
Si quelqu'un est plus éclairé que moi sur le sujet, j'aimerais bien qu'il m'explique.
Je pense donc que les microkernels c'est assez génial, je ne sais pas quels seront les inconvenients.... il n'y a rien a voir entre un petit BeOS et un gros serveur linux...
[^]Re: la guerre des kernels
Personnellement, du point de vue de la rapidité, je ne pense pas qu'il puisse y avoir une différence flagrante.
Si on ne fait pas attention, si, l'échange de messages entre les différents serveurs peut venir devenir très très couteux. Mais en prenant quelques précautions, en implémentant l'IPC de manière performante, ... on arrive à réduire grandement les pertes.
Si les modules utilisateurs sont trop nombreux, ils peuvent peut-être vite encombrer la ram, non ?
En théorie oui, sans doute, mais les serveurs sont des programmes normaux qui peuvent être swappés s'ils ne sont pas utilisés par exemple, et puis comparé aux couches types Gnome-VFS ou kioslave qui sont nécessaires sous Linux pour avoir des fonctionnalités équivalentes, ça me semble quand même beaucoup plus léger.
[^]Re: Retour vers le futur
"plus un programme est gros, plus il a de risques d'être buggué"
Je suis d'accord mais si l'on veut comparer Linux et le Hurd, je suppose qu'il faut comparer la quantité totale de code, et si les deux sysèmes doivent remplir les memes fonction, ils doivent representer plus ou moins la meme quantite de code donc de bugs...
Alors il est vrai qu'un bug dans un des serveurs du Hurd ne compromet que ce serveur, pas le système entier, alors que pour le noyau Linux, c'est tout le systeme qui se vautre. Certes. Mais AMHA le probleme est peu different : dans tous les cas il faut corriger le bug ou le service en question ne marchera pas. Alors redemarrer juste le service au lieu du systeme entier, c'est pas la solution miracle. Et puis en ce qui me concerne, j'ai rencontré beaucoup plus de bugs dans les programmes user space (donc que l'on peut redemarrer simplement sans rebooter) sous Linux que de bugs liés au noyau lui-meme et aboutissant a un reboot violent, donc l'architecture actuelle de Linux et le fait qu'il tourne en mode noyau ne me parait pas etre un problème si sérieux, et le fait que le Hurd utilise des serveurs et pas le mode noyau ne me parait pas non plus etre l'arme supreme... Enfin bon je demande à tester :o)
[+] [^]RMS est mort, vive Linus
Les micros noyau, ca pue
Hurd = 10 ans de développement et toujours pas pret
Linux = Pret en moins d'1 an, fonctionnel en une poignée d'années
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, ...
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.
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. Certes 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. Il suffit de se baser sur certaines mesures précises pour prouver ce qu'on veut prouver. Personnellement Java => ajout d'un couche d'abstraction (vm) => super long. De meme le fait que X est un processus dans l'espace utilisateur est certe une très bonne chose niveau conception (et je pense que pour le coup on a eu raison) 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). Et pour les micros noyaux, c'est encore le meme probleme, belle conception en apparence => chute de performance. 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. 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.
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.
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.
D'ou ma conclusion :
Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
[^]Re: RMS est mort, vive Linus
Les micros noyau, ca pue
Ca c'est de l'argumentation ! Chapeau !
Hurd = 10 ans de développement et toujours pas pret
Le développement Hurd a été (presque) complètement stoppé pendant des années, c'est 1999 que Marcus l'a relancé.
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 micro-noyau.
Le passage de messages ne complique pas vraiment le développement, mais par contre le fait d'avoir des programmes en user-space normaux que l'on débugguer avec gdb, qui n'obligent pas à redémarrer la machine lors d'un segfault, ... augmente nettement la facilité de développement.
mais à chaque fois ca entraine des chutes de performance terribles.
Tu as lu les autres commentaires sur cette page ? Tu es allé voir les articles sur L4Linux, L4KA et les techniques d'optimisation de l'IPC ? Alors renseigne-toi avant de parler et de sortir des arguments bidons que tu as lu l'aveille sur /. Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
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.
Encore une fois, lis ce qui a été dit ici. Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité. Pour Mac OS X c'est plus la couche Quark/Aqua qui rame que Darwin.
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 as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
Hurd ne remplacera _jamais_ Linux car si Hurd devait triompher Hurd aurait _déjà_triompher. N'en déplaise à Stallman et à son égo surmesurer.
Le but du Hurd n'est pas de remplacer Linux, mais de proposer une alternative mieux conçue et plus puissante. Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
[+] [^]Re: RMS est mort, vive Linus
>>Les micros noyau, ca pue
>Ca c'est de l'argumentation ! Chapeau !
L'argumentation vient après. On t'a pas appris quand tu étais petit qu'il fallait commencer les paragraphes avec l'idée principale est l'argumenter après.
Le développement Hurd a été (presque)
complètement stoppé pendant des a
nnées, c'est 1999 que Marcus l'a relancé.
Justement ca montre bien que les micros noyaux rendent la conception plus difficile. Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
Et crois-moi, je ne dis pas ça pour être méchant, vu que ce genre d'arguments je les sortais il y a quelques mois avant que je ne me renseigne vraiment sur la question (j'ai un peu honte de moi maintenant mais bon... errare humanum est)
Et oh, faut pas etre gentil comme ca, une réputation de trolleur ca ce travail ;)
Le Hurd n'est pas optimisé pour l'instant. Les développeurs savent où sont les principales lacunes, savent comment y remédier, mais ce n'est pas la priorité
La performance n'est pas une priorité, je crois réver. La performance devrait toujours etre une priorité.
Tu as lu tout ce que Manuel Menal et moi (entre autres) avons dit sur les possibilités du Hurd ? Comment tu fais le translator FTP + Hostmux sous Linux ? Ou le générateur de fortune ? Ou le serveur Apache qui n'a jamais besoin des droits root pou binder le port 80 ? Ou le serveur FTP non anonyme qui n'est pas suidé root ? Et le fait qu'un bug dans un module fasse cracher la totalité du système ? Alors relis tout ce qu'on a dit sur cette page avant de sortir des phrases toutes faites comme ça.
Ces fonctionnalités sont interessantes au niveau de la sécurité et du développement, mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances. De la même facon je préfère coder en C qu'en Java. Certes en java il y a un demi milliards de mécanismes pour prendre des précautions qui n'existe pas en C. Un code C a ainsi beaucoup plus de chance de planter à l'exécution qu'un code Java. Mais il est aussi beaucoup plus rapide (Je sais je n'aurais pas du prendre l'exemple de Java car la lenteur est principalement du à la vm, mais j'ai assez peu d'expérience avec le C++). Et les tests ca existent. La communauté Linux jouent sur la rapidité de développement et le feed back rapide des problèmes pour avoir un système sur et sécurisé. Je préfère cette approche que l'approche : on prend énormément de précaution et on optient une chute de performances.
Quand à la personnalité de RMS, déjà je ne suis pas du tout d'accord avec ton jugement sur lui, et en plus je ne vois pas ce qu'il a à voir que le Hurd.
Tu ne vois pas ce qu'il a avoir avec le Hurd !!!????!!?!. Le système GNU ca te dit qqchose ? Le Hurd est le noyau officiel du système, pas Linux. Et Stallman est bien verreux que Linux (ou Linus si tu préfère) lui ait piqué la chandelle : les messieurs tout le monde dans la rue connaissent moins stallman que Linus.
[^]Re: RMS est mort, vive Linus
Je ne pense pas que les développeurs HURD soient des brels, alors s'ils se sont découragés c'est bien que ca devait etre difficile.
Non, c'est parce qu'il y avait déjà Linux et que la priorité n'était donc plus au niveau du "noyau".
La performance n'est pas une priorité, je crois réver.
Et ben non, quand tu développes un programme tu commences par le faire robuste et fiable, et après tu optimises. L'optimisation de l'implémentation n'est pas une priorité dans le début du développement d'un programme.
mais bon je préfère un système ou l'on prend plus de risque et on l'on favorise avant tout les performances.
T'es bouché ou tu le fais exprès ? La perte de performance peut être dimunée au point d'être négligeable ! Pendant que tu y es aussi on fait tourner en mode noyau sans protection mémoire ni rien pour économiser un peu de perf ? Et compare des choses qui sont comparables STP, un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.
Tu ne vois pas ce qu'il a avoir avec le Hurd !!!??
Ce n'est pas RMS qui contrôlle le Hurd, qui prend les décisions de design ou autres. Il ne participe même au code IIRC. Quand a ton mépris pour RMS, ça ne concerne que toi et je ne partage pas du tout ton avis. Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
[^]Re: RMS est mort, vive Linus
un micro-noyau c'est beaucoup moins lourd et coûteux qu'une JVM et ça apporte beaucoup plus AMHA.
C'est vrai. Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.
Si tu n'as pas compris que les différents entre RMS et Linus sont plus idéologiques qu'autre chose (RMS défendant le logiciel libre pour des raisons éthiques, Linus ne s'intéressant qu'au côté technique), et bien c'est dommage.
Bien sur que je connais les différents idéologique entre le mouvement Open Source et la FSF. Bien sur que je sais que les 9 clauses de l'OSD sont plus pragmatique qu'idéologique.
Maintenant les différents sont aussi technique. Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas. Tu ne vas pas me dire qu'il ne s'agit pas de différent technique. D'une facon générale les différents entre les 2 sont avant tout basé sur une vision différente du monde : d'un coté il y a un pragmatique qui tire ces idées de l'expérience, de l'analyse du réel et de l'autre il y a un théoricien qui préfère les belles idées. Moi je me reconnais parfaitement dans la première vision du monde et pas du tout dans la deuxième. C'est mon droit maintenant tu es libres de penser différemment.
[^]Re: RMS est mort, vive Linus
Mais le problème de base reste le meme : en ajoutant des couches logiciels on s'éloigne du hard et on perd en performance.
Mais on ajoute pas de couches logicielles... tu n'as pas compris ce qu'était un µ-noyau justement.
Linus n'aime pas emacs et Hurd. RMS aime les unoyaux, Linus ne les aime pas.
Emacs c'est un micro-noyau ? Et la marmotte ? Le rapport entre Emacs et le Hurd STP (à part que ce sont des projets GNU ?)
Et encore une fois je te répète que RMS n'a pas grand chose à voir avec le Hurd et qu'il ne contrôle pas du tout l'évolution du projet.
[^]Re: RMS est mort, vive Linus
emacs n'est pas un micro noyau, mais un maxi-kernel =)
<donotfeedthetroll figlet="yes">
[^]Re: RMS est mort, vive Linus
Je ne suis absolument pas d'accord.
Je vois personnellement Hurd, non pas prenant aujourd'hui la place de Linux , mais comme une expérience afin de créer un nouvel OS libre pour demain.
Sa structure micro-noyau, le freine aujourd'hui, mais tout évolue; avec la rapide évolution de la technologie (matériel et logiciel), peut on être sûr que Hurd ne peut avoir une place demain (sécurité, parallélisme, ...)
Toute expérience prend du temps (surtout quand on change d'avis en cours de route ;), commence par des essais (souvent non optimisés) et apporte des réponses différentes (j'adore la gestion des droits et le VFS sous Hurd).
Le premier système Unix fut écrit en assembleur puis réécrit en C, pour le rendre plus facile à dévolopper; le premier java était très lent, mais on est passé à l'air du JustInTime.
Oui, Linux est actuellement très défendu car c'est un peu grâce à lui que nous sommes ici, mais je pense que chacun peut avoir sa place, chacun peut surement quelque chose à l'autre.
[^]Re: RMS est mort, vive Linus
>Le but d'un micro-noyau c'est surtout pour les >développeurs [snip]
bon j'ai coupe mais ca ne change rien. L'interet est aussi grand pour les utilisateurs : avec un micro noyau, on met ce qu'on veut autour, mais vraiment ce que l'on veut --> on peut a peu pres tout faire, et ce sur des configs tres modestes si on ne fait presque rien tourner autour du noyau.
>mais il y a toujours des articles pour dire >n'importe quoi
l'argument peut etre retourne : il y aura tjs des articles pour dire que ca ralentit tout mais...
>Les belles idées sur le papier on a vu ce que ca >a donné avec le communiste
bon la avis perso, vous auriez pu trouver une autre comparaison :)
>Il suffit de se baser sur certaines mesures >précises pour prouver ce qu'on veut prouver.
et plus loin
>mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...
J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.
>Hurd ne remplacera _jamais_ Linux car si Hurd >devait triompher Hurd aurait _déjà_triompher
Linux a mis plus de qqes annees a s'imposer en tant qu'alternative viable a tout le reste (enfin aux OS proprios), je ne pense donc pas que le Hurd puisse etre le sujet de telles pensees. Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
[^]Re: RMS est mort, vive Linus
>mais j'ai des copains qui ont utilisés Hurd et >Mac OS X et il m'ont dit que...
J'ai appris a mes depends que se baser sur "ce que disent les copains" est *tres* mauvais. N'y voyez aucune agressivite de ma part, mais je ne pense pas que cet argument soit recevable.
Je suis tout à fait d'accord. Personnellement tous mes jugements repose principalement sur _mon_ expérience. Je considère que l'expérience est au dessus de tout article, avis d'expert, avis de copain. Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.
Et surtout il ne me semble pas qu'il soit question que Hurd remplace Linux.
Je n'ai rien contre le Hurd, ce qui m'énerve c'est le quasi mépris de Stallman envers Linux. Et le mépris de Linus envers le Hurd me direz vous ? Je vous l'accorde ca doit etre un truc de chef d'etre braqué. D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
[^]Re: RMS est mort, vive Linus
Maintenant mieux vaut avoir l'information d'un copain que pas d'information du tout.
Oui mais tant qu'on ne s'est pas fait son propre avis, ce n'est pas la peine de partager l'opinion de ses copains, sinon avec des avis de copains de copains ca peut aller loin.
D'un autre coté faut bien qu'ils prennent des décisions. Et as nous de choisir notre camp.
Il n'est pas question de choisir un camp, la communauté n'est pas en guerre. On a encore le droit de faire du multiboot Linux/Hurd/Bsd/Atheos et tout ce qu'on veut.
[^]Re: RMS est mort, vive Linus
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.
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.
[^]Re: RMS est mort, vive Linus
Bon j'avais déjà répondu mais le message n'a pas été posté :((
Mon Dieu.. On en tient un beau
Merci
J'ai déjà répondu à ça, exactement le même titre
Ce n'était exactement le même titre, les micro-noyaux, ca pue, c'est plus percutant que les micro-noyaux, c'est nul.
qui n'a pas besoin d'être rebootée de façon régulière pour mise à jour du noyau
Je ne sais pas si tu es au courant mais Linux est de plus en plus utilisé par des personnes qui ne savent même pas ce qu'est un noyau. Avancé cet argument pour démontrer que le HURD n'est pas seulement destiné aux développeurs c'est vraiment nul.
De quelle couche d'abstraction parles-tu ? De quelle interface ? J'avoue ne pas comprendre à quoi tu fais référence.
Avec un noyau monolithique, un appel système va directement tapé dans le noyau.
Avec un micro-noyau, les appels systèmes sont implémentés au niveau des serveurs (1ère interface), les serveurs font appels aux services fournis par les taches d'entrées sorties (2 ème interface) et enfin les taches d'entrées sorties font appels au micro-noyau qui s'occupe de gérer les ressources et de passer les messages (3ème interface). Voila ce que j'appelle ajout de niveaux d'abstraction. (Enfin c'est ce qui se passe sous minix, je connais très mal HURD)
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.
Alors pourquoi l'utiliser s'il y a moyen de faire mieux ?
<i>
> Certes 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.
<i>
Je confirme, et j'en suis fier ;)
> 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 ?
Moi ce que je souhaiterais pour changer mon avis sur les micro-noyaux c'est que Hurd soit aussi rapide (au niveau de l'utilisation j'entends) que Linux et que ce soit une _priorité_.
Pourquoi viens-tu parler du Hurd, alors ? Tu n'es pas devin, ni moi.
Pipo Argument
Prédiction de l'avenir => Test sur la compréhension du présent. Il est toujours bon d'essayer de prévenir l'avenir. Les personnes qui prédisent très mal l'avenir sont des personnes qui ont une mauvaise compréhension du présent et inversement. Ainsi pour savoir si l'on a une bonne compréhension du présent, il est bon de faire des prédictions, de les retenir et de voir quand le futur devient présent si l'on avait raison ou non. Et si l'on avait tort ils est bon de se poser des questions
> N'en déplaise à Stallman et à son égo surmesurer.
Encore un non-argument, trollesque, sans _aucun_ intérêt
Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)
nous sommes pas là pour juger des personnes, que tu ne connais pas personellement
Tu es le roi des arguments à la con à ce que je vois. Je ne connais pas personnellement les hommes politiques et cela ne m'empeche pas de les juger et ne m'empechera pas d'aller voter pour l'un d'eux aux prochaines élections. C'est meme mon devoir de citoyen.
[+] [^]Re: RMS est mort, vive Linus
mr , vous n'avez manifestement aucune connaissance objective sur HURD
vous ne répondez pas aux arguments techniques sur les possibilités de HURD que linux ne peut _pas_ reproduire.
vous melangez tout
vous ne repondez pas sur le fait que HURD permettrait de se passer de gnome-vfs ou les kioslave (et faire la même chose en plus rapide)
vous dites :
" Si les trolls n'ont aucun intérêt, que fais-tu sur linuxfr ! Les trolls sont primordiales car ils permettent de se défouler ! Et se défouler c'est important, sinon comment expliquer le succès des doom-like, quake-like, des films violents et ... de linux (qui permet de se défouler sur microsoft)"
je pense plutot que c'est vous qui avez rien à faire sur linuxfr. les trolls sont une pertes de temps. vous répondez, ecrivez a coté du sujet, vous servez à rien.
on se fiche que vous vous defouliez, linuxfr est un site d'informations et une place publique pour discuter autour de linux et les logiciels libres (et hurd s y inscrit)
manifestement il y a des gens ici qui connaissent bien mieux que vous linux ou hurd.