Je parle du cas où tu (= admin de la machine) veux avoir un serveur FTP qui permette aux utilisateurs d'utiliser leur login/mot de passe et droits Unix.
Sous GNU/Linux et tous les autres Unix, tu es obligé de lancer un serveur FTP avec les droits root pourqu'il puisse ensuite faire setuid() avec l'UID de celui qui vient de s'authentifier. Ton serveur FTP est donc un énorme trou de sécurité potentielle puisqu'il est root.
Sous GNU, tu dois toujours lancer ton serveur avec des droits spéciaux pour qu'il puisse faire un bind() sur le port 21. Mais ensuite il peut abandonner tout privilège, toute identité, et lorsque quelqu'un lui donnera un login/mdp il demandera alors des droits au serveur de mot de passes.
Dans les deux cas, seul l'admin (ou quelqu'un de privilégié) a pu lancer le serveur FTP sur le port 21, donc tu ne compromets pas du tout la sécurité de la manière dont tu parles. Mais par contre un trou dans ton serveur FTP n'aura que des conséquences mineures, et ne pourra jamais donner un shell root à un cracker.
Bien sur, un user normal peut lancer un serveur FTP de ce type sur un port > 1024, mais là c'est celui qui est suffisament inconscient pour donner son mdp dans de telles conditions qui commet une faute, et pas une erreur de conception du Hurd.
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.
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.
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)
Le Hurd est un ensemble de serveurs tournant par dessus un micro-noyau et proposant aux programmes des fonctionnalités équivalentes (ou supérieures) à celles fournies par les noyaux monolithiques comme Linux.
Un parralèle à Linux ?
Si on veut, disons qu'un micro-noyau (GNU Mach, OSKit Mach, ...) + le Hurd peut (pourra) remplacer Linux dans un système.
Il y a une différence fondamentale ?
Oui, plusieurs différences fondamentales, tout a déjà été expliqué plus haut par Manuel Menal et moi (entre autres), relis les commentaires.
C'est la FSF qui devellope HURD et Linus qui devellope Linux c'est ça ??
C'est plus compliqué que ça. Linux est développé par un grand nombre de programmeur, dont Linus qui est "l'architecte"; dans le cas du Hurd "l'architecte" serait plutôt Marcus.
Le Hurd est un projet GNU officiel, au même titre que GNU Emacs, gcc, la GNU libc ou GNU bash, mais il n'est pas développé directement par la FSF, mais plus par des contribueurs de part le monde, comme Linux ou les autres projets libres.
Le Hurd tourne pour l'instant de façon sûre et testée sur x86 et PPC. Mais, c'est basé sur GNU Mach, qui est à la base un OSF Mach dont la licence a été changée - avec l'autorisation de l'OSF/CMU - et OSF Mach est porté - des implémentations pas toujours libres, cependant.. - sur de nombreuses plate-formes (cf http://www-2.cs.cmu.edu/afs/cs/project/mach/public/FAQ/platforms(...) )
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.
Ne parle pas trop vite:
man smbmount:
NOTE: smbmount calls smbmnt(8) to do the actual mount. You must make sure that smbmnt is in the path so that it can be found.
(kilobug@drizzt, 12) ~/download $ ls -l `which smbmnt`
-rwsr-xr-x 1 root root 429192 mar 5 23:24 /usr/bin/smbmnt
Justement, comme linux interdit aux utilisateurs de monter ne serait-ce qu'un cdrom ou faire ce qu'ils veulent avec leur FS
Il est possible sous Linux de laisser un utilisateur monter des cd-roms avec l'option "user" du fstab, mais ça nécessite un mount suider-root, ... c'est pas génial génial niveau sécurité tout ça.
il va me mettre un [-] vous allez voir !
Je mets très rarement des -, et là je ne t'en ai pas mis.
un système comme l'hurd permet des backdoors
Pas plus que sous Linux. Dans les deux cas si tu lances un logiciel propriétaire (ou que tu n'as pas vérifié) toutes les données auxquelles tu peux accéder sont potentiellement en danger. Le Hurd ne compromet pas la sécurité à ce niveau là.
Arf :) je suis loin d'être l'expert sur le Hurd et les micro-noyaux ici, cela fait juste quelques mois que je m'intéresse au sujet et que je me docuemente, m'enfin bon....
Oui, GNU (GNU/Hurd si vous voulez) respectera les normes POSIX, tout en offrant d'avantages de possibilités, comme c'est toujours le cas dans le projet GNU. Bash est un shell POSIX avec des extensions, gcc 3.x est un compilateur C ISO 99 avec des extensions, ...
Maintenant à l'heure actuelle, l'intégralité de la norme POSIX ne doit pas encore être supportée par le Hurd (il manque les pthreads par exemple)
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.
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).
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)
Meme si le hurd progresse à grand pas je suis pas sure qu'il soit pour le moment un candidat serieux au remplacement de notre cher GNU/linux...
Le Hurd n'est pas un remplacement de GNU/Linux, juste de Linux. Tous les outils (glibc, ld, gcc, XFree, emacs, ...) restent à peu près les mêmes.
Pour le moment, non, il n'est pas un candidat sérieux pour remplacer Linux sur les machines de prod. Pour le moment. RMS est optimiste et prévoit qu'il sera en 2002, pour ma part je dirais plutôt mi-2003, mais ni lui ni moi ne sommes des devins, ni même les mieux placés pour faire des prédictions.
Ok, ils ont trouvé une solution plus souple, mais qui n'est pas implémentée, donc pour l'instant on se trouve comme des cons non ?
ShadowFS est implémenté maintenant je crois.
Limite tout de meme. Je sais que sur un serveur le nombre de cartes est limitées mais bon ...
Le Hurd va passer sur OSKit Mach d'ici peu.
Là c'est du foutage de gueule ...
Ce sera corrigé d'ici la fin de l'année, et ce n'est pas du "foutage de gueule" pour une version de développement. Et la limite n'est pas d'1 Go partout elle varie de 1 Go à 4 Go suivant les machines.
Pas top non plus pour de la prod ca ....
Idem, c'est une limitation de GNU Mach qui n'existe pas dans OSKit Mach, pas une limitation du Hurd.
L'API de la glibc (attention, ne pas confondre glibc (GNU Lib C) et la GLib (bibliothèque de base de GTK)) est la même sur GNU et sur GNU/Linux, modulo quelques extensions (je pense).
XFree doit être modifié pour le DRI uniquement, actuellement c'est simple: il n'y a pas de DRI sous GNU, il faut le désactiver.
Les FS peuvent être les mêmes ou bien ils peuvent être différents, pour l'instant la Debian GNU/Hurd utilise ext2fs par défaut. Un FS sous GNU ce n'est qu'un translator, un programme user-space normal, et il est donc possible d'en rajouter relativement simplement.
Les éxécutables sont en ELF, mais la compatibilité binaire ne fonctionne pas actuellement.
Pour l'init, ça dépend de la distrib je dirais... L'init n'est pas la même entre une Slackware te une Debian je crois, par exemple. Actuellement la Debian GNU/Hurd utilise une init System V comme la Debian GNU/Linux. Un nouveau système d'init est actuellement à l'étude.
Si les mainteneurs font bien leur travail, on devrait pouvoir passer d'un kernel a l'autre de maniere presque transparente ou est ce qu'il faudra maintenir 2 OS complets ?
Actuellement il faut des OS complets à cause du manque de compatibilité binaire, mais ce sont les mêmes programmes qui tournent sur les deux OS (en gros)
Non, un serveur ce n'est pas du tout comme un module noyau. Un module noyau s'exécute en mode noyau sur le processeur et peut absolument tout faire, il est donc normal que seul root puisse en lancer. Un serveur du Hurd est un programme comme un autre, qui tourne avec l'indentité de l'utilisateur qui l'a lancé et ne peut rien faire de plus que ce que l'utilisateur a le droit de faire.
Donc oui, n'importe qui peut lancer un serveur, mais ce serveur ne pourra faire que ce que l'utilisateur peut faire. Typiquement pour un translator lancé sur une image ISO, il faut que l'utilisateur puisse lire l'image ISO et possède le répertoire où l'image va être montée.
Ce ne sera peut-être pas forcément à la pointe ni super fonctionnel
Qu'est-ce qui te permet d'affirmer ça ? A court terme peut-être, mais à long terme je pense que c'est plutôt Linux qui aura du mal à ce maintenir au niveau du Hurd sur les possibilités, la sécurité, ...
Il suffit de voir comment on galère juste pour avoir du ftpfs sous Linux...
Ou bien explique moi comment tu fais un serveur FTP non-anonyme sans lui donner les droits root...
l'hurd permet à l'utilisateur de se passer du root
Déjà on dit le Hurd, pas l'hurd, merci. Ensuite, le Hurd ne permet à l'utilisateur de se passer du root et ne nuit pas du tout à la sécurité, au contraire. Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
Par exemple, avec Linux, si tu veux faire du ftpfs (monter un répertoire FTP dans ton VFS), il faut passer root, charger le module ftpfs, et introduire donc un nouveau programme, potentiellement buggué, dans le noyau. Avec le Hurd, tu lances un translator FTP, qui tourne sous ton identité, qui a tes privilèges, comme une application normale.
<i>n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux.</i<
Je suis d'accord sur le fond: la diversité est une bonne chose.
Par contre, il faut faire attention à ce que l'on dit: le Hurd n'est pas un OS, ce n'est même pas vraiment un noyau, c'est un ensemble de serveurs pour micro-noyau pouvant être utilisés (en conjonction avec un µ-k) pour remplacer un noyau monolithique dans un système (ici le système GNU).
GNU/Linux et GNU ne sont donc pas deux système complétement différents comme le sont GNU/Linux et FreeBSD par exemple.
Pour les applications propriétaires, si la compatibilité binaire entre GNU/Hurd et GNU/Linux n'existe pas actuellement, elle ne pose aucun problème théorique et sera implémentée dés que quelqu'un jugera bon de le faire (et l'intéret premier de ça n'est pas de faire tourner des applis propriétaires AMHA, mais de faciliter les dual-boots GNU/Linux-GNU/Hurd).
La compatibilité binaire entre GNU et GNU/Linux n'existe pas à l'heure actuelle, il faut recompiler les applications.
Il y aussi d'autres choses qui sont légèrement différentes, par exemple LILO ne sait pas charger le Hurd, il faut utiliser Grub, le système de translator est légèrement différent du système de points de montages (avec les translators passifs par exemple il n'est pas nécessaire de relancer un mount /dev/hda2 /home à chaque boot, ...)
Mais il existe une Debian GNU/Linux Sid et une Debian GNU/Hurd qui sont assez proches et ont beaucoup d'applications en commun. Pour un utilisateur final, les différences sont peu visibles, si ce n'est que le Hurd offre plus de possibilités, et surtout de manière plus propre (plus de besoin d'une couche gnome-vfs ou kioslave pour acceder à un répertoire FTP ou un .tar de manière transparente, ...)
[^] # Re: RMS est mort, vive Linus
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.
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: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.
Sous GNU/Linux et tous les autres Unix, tu es obligé de lancer un serveur FTP avec les droits root pourqu'il puisse ensuite faire setuid() avec l'UID de celui qui vient de s'authentifier. Ton serveur FTP est donc un énorme trou de sécurité potentielle puisqu'il est root.
Sous GNU, tu dois toujours lancer ton serveur avec des droits spéciaux pour qu'il puisse faire un bind() sur le port 21. Mais ensuite il peut abandonner tout privilège, toute identité, et lorsque quelqu'un lui donnera un login/mdp il demandera alors des droits au serveur de mot de passes.
Dans les deux cas, seul l'admin (ou quelqu'un de privilégié) a pu lancer le serveur FTP sur le port 21, donc tu ne compromets pas du tout la sécurité de la manière dont tu parles. Mais par contre un trou dans ton serveur FTP n'aura que des conséquences mineures, et ne pourra jamais donner un shell root à un cracker.
Bien sur, un user normal peut lancer un serveur FTP de ce type sur un port > 1024, mais là c'est celui qui est suffisament inconscient pour donner son mdp dans de telles conditions qui commet une faute, et pas une erreur de conception du Hurd.
[^] # Re: RMS est mort, vive Linus
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.
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
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 8.
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: Retour vers le futur
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 4.
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: Oui mais...
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 3.
Le Hurd est un ensemble de serveurs tournant par dessus un micro-noyau et proposant aux programmes des fonctionnalités équivalentes (ou supérieures) à celles fournies par les noyaux monolithiques comme Linux.
Un parralèle à Linux ?
Si on veut, disons qu'un micro-noyau (GNU Mach, OSKit Mach, ...) + le Hurd peut (pourra) remplacer Linux dans un système.
Il y a une différence fondamentale ?
Oui, plusieurs différences fondamentales, tout a déjà été expliqué plus haut par Manuel Menal et moi (entre autres), relis les commentaires.
C'est la FSF qui devellope HURD et Linus qui devellope Linux c'est ça ??
C'est plus compliqué que ça. Linux est développé par un grand nombre de programmeur, dont Linus qui est "l'architecte"; dans le cas du Hurd "l'architecte" serait plutôt Marcus.
Le Hurd est un projet GNU officiel, au même titre que GNU Emacs, gcc, la GNU libc ou GNU bash, mais il n'est pas développé directement par la FSF, mais plus par des contribueurs de part le monde, comme Linux ou les autres projets libres.
[^] # Re: Curiosité
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 3.
[^] # Re: la guerre des kernels
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 6.
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: Troll des cavernes
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.
man smbmount:
NOTE: smbmount calls smbmnt(8) to do the actual mount. You must make sure that smbmnt is in the path so that it can be found.
(kilobug@drizzt, 12) ~/download $ ls -l `which smbmnt`
-rwsr-xr-x 1 root root 429192 mar 5 23:24 /usr/bin/smbmnt
Qu'est-ce que tu disais à propos du suidé-root ?
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 4.
Il est possible sous Linux de laisser un utilisateur monter des cd-roms avec l'option "user" du fstab, mais ça nécessite un mount suider-root, ... c'est pas génial génial niveau sécurité tout ça.
il va me mettre un [-] vous allez voir !
Je mets très rarement des -, et là je ne t'en ai pas mis.
un système comme l'hurd permet des backdoors
Pas plus que sous Linux. Dans les deux cas si tu lances un logiciel propriétaire (ou que tu n'as pas vérifié) toutes les données auxquelles tu peux accéder sont potentiellement en danger. Le Hurd ne compromet pas la sécurité à ce niveau là.
[^] # Trop gros, passera
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 2.
................_---________---__________.............................
...............|..........PLEASE.........}............................
...............|.........................}............................
............../....DO.NOT.FEED.THE.TROLL.\............................
..............\____....................__/............................
...................-------------------`...............................
...........................|#:|.......................................
...........................|#:|.......................................
...........................|#:|.......................................
........................\\\|#:|/./....................................
............~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.......................
-1
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 7.
Arf :) je suis loin d'être l'expert sur le Hurd et les micro-noyaux ici, cela fait juste quelques mois que je m'intéresse au sujet et que je me docuemente, m'enfin bon....
Oui, GNU (GNU/Hurd si vous voulez) respectera les normes POSIX, tout en offrant d'avantages de possibilités, comme c'est toujours le cas dans le projet GNU. Bash est un shell POSIX avec des extensions, gcc 3.x est un compilateur C ISO 99 avec des extensions, ...
Maintenant à l'heure actuelle, l'intégralité de la norme POSIX ne doit pas encore être supportée par le Hurd (il manque les pthreads par exemple)
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
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
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
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
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
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: GNU/Linux vs GNU/*
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 1.
-1 [jeretournesurlatribune]
[^] # Re: Retour vers le futur
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
[^] # Re: GNU/Linux vs GNU/*
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
Le Hurd n'est pas un remplacement de GNU/Linux, juste de Linux. Tous les outils (glibc, ld, gcc, XFree, emacs, ...) restent à peu près les mêmes.
Pour le moment, non, il n'est pas un candidat sérieux pour remplacer Linux sur les machines de prod. Pour le moment. RMS est optimiste et prévoit qu'il sera en 2002, pour ma part je dirais plutôt mi-2003, mais ni lui ni moi ne sommes des devins, ni même les mieux placés pour faire des prédictions.
[^] # Re: utilisable ?
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 7.
ShadowFS est implémenté maintenant je crois.
Limite tout de meme. Je sais que sur un serveur le nombre de cartes est limitées mais bon ...
Le Hurd va passer sur OSKit Mach d'ici peu.
Là c'est du foutage de gueule ...
Ce sera corrigé d'ici la fin de l'année, et ce n'est pas du "foutage de gueule" pour une version de développement. Et la limite n'est pas d'1 Go partout elle varie de 1 Go à 4 Go suivant les machines.
Pas top non plus pour de la prod ca ....
Idem, c'est une limitation de GNU Mach qui n'existe pas dans OSKit Mach, pas une limitation du Hurd.
[^] # Re: Différences
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
XFree doit être modifié pour le DRI uniquement, actuellement c'est simple: il n'y a pas de DRI sous GNU, il faut le désactiver.
Les FS peuvent être les mêmes ou bien ils peuvent être différents, pour l'instant la Debian GNU/Hurd utilise ext2fs par défaut. Un FS sous GNU ce n'est qu'un translator, un programme user-space normal, et il est donc possible d'en rajouter relativement simplement.
Les éxécutables sont en ELF, mais la compatibilité binaire ne fonctionne pas actuellement.
Pour l'init, ça dépend de la distrib je dirais... L'init n'est pas la même entre une Slackware te une Debian je crois, par exemple. Actuellement la Debian GNU/Hurd utilise une init System V comme la Debian GNU/Linux. Un nouveau système d'init est actuellement à l'étude.
Si les mainteneurs font bien leur travail, on devrait pouvoir passer d'un kernel a l'autre de maniere presque transparente ou est ce qu'il faudra maintenir 2 OS complets ?
Actuellement il faut des OS complets à cause du manque de compatibilité binaire, mais ce sont les mêmes programmes qui tournent sur les deux OS (en gros)
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 9.
Donc oui, n'importe qui peut lancer un serveur, mais ce serveur ne pourra faire que ce que l'utilisateur peut faire. Typiquement pour un translator lancé sur une image ISO, il faut que l'utilisateur puisse lire l'image ISO et possède le répertoire où l'image va être montée.
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 7.
Qu'est-ce qui te permet d'affirmer ça ? A court terme peut-être, mais à long terme je pense que c'est plutôt Linux qui aura du mal à ce maintenir au niveau du Hurd sur les possibilités, la sécurité, ...
Il suffit de voir comment on galère juste pour avoir du ftpfs sous Linux...
Ou bien explique moi comment tu fais un serveur FTP non-anonyme sans lui donner les droits root...
[^] # Re: Troll des cavernes
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
Déjà on dit le Hurd, pas l'hurd, merci. Ensuite, le Hurd ne permet à l'utilisateur de se passer du root et ne nuit pas du tout à la sécurité, au contraire. Il permet à l'utilisateur de faire des choses qui ne nuisent pas à l'intégrité du système mais qui sont impossibles à faire avec un noyau monolithique.
Par exemple, avec Linux, si tu veux faire du ftpfs (monter un répertoire FTP dans ton VFS), il faut passer root, charger le module ftpfs, et introduire donc un nouveau programme, potentiellement buggué, dans le noyau. Avec le Hurd, tu lances un translator FTP, qui tourne sous ton identité, qui a tes privilèges, comme une application normale.
<i>n'importe quel soft à la windows a plus d'affinités avec l'hurd qu'avec linux.</i<
Que veux-tu dire par là ??
[^] # Re: La mort annoncée de GNU/Linux ?
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
Par contre, il faut faire attention à ce que l'on dit: le Hurd n'est pas un OS, ce n'est même pas vraiment un noyau, c'est un ensemble de serveurs pour micro-noyau pouvant être utilisés (en conjonction avec un µ-k) pour remplacer un noyau monolithique dans un système (ici le système GNU).
GNU/Linux et GNU ne sont donc pas deux système complétement différents comme le sont GNU/Linux et FreeBSD par exemple.
Pour les applications propriétaires, si la compatibilité binaire entre GNU/Hurd et GNU/Linux n'existe pas actuellement, elle ne pose aucun problème théorique et sera implémentée dés que quelqu'un jugera bon de le faire (et l'intéret premier de ça n'est pas de faire tourner des applis propriétaires AMHA, mais de faciliter les dual-boots GNU/Linux-GNU/Hurd).
[^] # Re: Une distribution, deux noyaux, c'est comme ca que ca va finir
Posté par Gaël Le Mignot . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
Il y aussi d'autres choses qui sont légèrement différentes, par exemple LILO ne sait pas charger le Hurd, il faut utiliser Grub, le système de translator est légèrement différent du système de points de montages (avec les translators passifs par exemple il n'est pas nécessaire de relancer un mount /dev/hda2 /home à chaque boot, ...)
Mais il existe une Debian GNU/Linux Sid et une Debian GNU/Hurd qui sont assez proches et ont beaucoup d'applications en commun. Pour un utilisateur final, les différences sont peu visibles, si ce n'est que le Hurd offre plus de possibilités, et surtout de manière plus propre (plus de besoin d'une couche gnome-vfs ou kioslave pour acceder à un répertoire FTP ou un .tar de manière transparente, ...)