Oui, j'ai « testé » le Hurd. Non, ce n'est pas un noyau. Au risque de passer pour un vieux radoteur, ce que je suis probablement, me direz-vous, « est noyau tout code qui tourne avec les permissions spéciales du proc' réservées au .. noyau, soit le fameux 0 sur processeurs Intel ». C'est ce qui différencie, d'ailleurs, le mode noyau du mode utilisateur. (kernel space.. user space). Tout le code du Hurd tourne en mode utilisateur. Il s'agit juste d'une série d'applications _normales_, n'ayant pas plus de permissions que les autres.
Ces précisisons étant dîtes, répondons. Qu'apporte-t-il ? Il faudrait bien plus d'un commentaire pour répondre à cette question. (la partie de ma présentation sur le Hurd à ce sujet fait déjà plus de cinq pages, et j'en suis à juste un peu plus du tiers :). À la base, l'esprit du Hurd est l'esprit du GNU - ou ce qu'il devrait être: étudier et reprendre les logiciels existants, essaye d'en retirer les avantages et les limites, et essayer de les casser, en faisant au maximum novateur, au maximum repensé. Pas juste une réécriture. C'est là où le Hurd diffère de Linux: Linux n'est qu'une réécriture d'Unix, où les améliorations résident dans l'implémentation. Le Hurd est différent d'Unix, puisque GNU's not Unix.
Les différences sont multiples. La première, et la principale, à laquelle on pense automatiquement est l'architecture d'un système GNU: au lieu d'un très gros programme - monolithique, donc - fournissant un tas de fonctionnalités dîtes de base pour un OS - là, la définition de ce qu'est un service de base n'est pas claire, puisque la seule vraiment rigoureuse serait de dire que c'est ceux fournit par le noyau Unix à la base - on a une serie de petits programmes indépendants, qui se chargent chacun d'une tâche - pfinet, pour tout ce qui est PF_INET (PF <=> Protocol Family, je vous laisse deviner pour INET), nfs pour le NFS, ext2fs pour ext2, password pour le serveur de passwords, etc, ces applications -- appelées serveurs -- communiquant entre elles via le micro-noyau. Ceci présente plusieurs avantages:
* Une plus grande modularité, au sens où l'on peut bâtir facilement des systèmes extrêmement minimaux ne contenant que les quelques services de base - les quatre ou cinq serveurs nécessaires au Hurd.
* Une plus grande stabilité. Entendons nous bien,
le Hurd n'apporte pas la stabilité absolue, les programmeurs sont malgré tout humains. :). Cependant, ce que peut faire un OS-base, c'est de réduire la gravité de ces bugs afin qu'un problème dans une application puisse difficilement rendre l'ensemble du système totalement inutilisable.
Il est clair que plus le programme est gros, plus il y'a de chance qu'un bug arrive. Ainsi, Linux devenant de plus en plus gros, il arrive, fréquemment - quasiment de plus en plus ;-) - qu'un bug dans une partie non-essentielle de Linux survienne, ce qui provoque, bien évidemment, un crash de l'ensemble du noyal. Sous le Hurd, dans la majorité des cas - c'est à dire, dans les cas où le bug survient sur un des serveurs n'étant pas essentiel a la « survie » du système - seule l'application responsable crashera, et ça n'ira pas plus loin. Par exemple, lorsque Jeff Bailey a mis, il y'a quelques temps de ça un serveur Web sous GNU, et l'a annoncé un peu partout, et que la nouvelle s'est retrouvée sur /., pfinet n'étant pas très solide, il n'a évident pas tenu la charge d'un slashdottage en règle.. (pensez bien, un truc comme ça). Dans le cas de Linux, cela aurait causé un crash du système et une non-disponibilité pendant quelques temps. Dans le cas du Hurd, il a suffit de relancer pfinet, et c'était reparti pour un tour. De plus, les opérations risquées peuvent facilement être faîtes dans un sub-Hurd, équivalent de UML - User-Mode Linux - qui est totalement naturel pour le Hurd, puisqu'il ne s'agit que de relancer des applications normales, et ne pose aucun problème -- contrairement à UML qui évolue lentement, nécessite des patches, et, du fait que Linux n'est pas prévu pour ça, pose pas mal de problèmes encore..
* Une plus grande disponibilité, en partie pour les questions de stabilité décrites ci-dessus, et également parce qu'il est plutôt rare d'avoir à changer le noyau, et que le changement de presque tout le reste peut se faire « à chaud ». De plus, la flexibilité pourrait imaginer deux pfinet tournant en parallèle, l'un relayant l'autre dès que le premier a fini, ceci permettant d'éviter les déconnexions en cas de problème, et par exemple, d'effectuer un changement de pfinet sans aucune déconnexion. Ce n'est qu'un exemple: la flexibilité qu'apporte la modularité du Hurd peut autoriser _nombre_ de choses très intéressantes comme cela, qui n'ont pas toutes été implémentées à l'heure actuelle.
* Enfin, il me semble que c'est quand même beaucoup plus beau, clean. Les rôles sont beaucoup mieux repartis, et chaque partie peut être facilement remplacée sans perturber les autres.
Mais ce n'est pas tout. On ne peut limiter le Hurd a son architecture: elle n'est qu'un élément de la recherche du toujours mieux, toujours plus novateur. On citera par exemple:
* Le principe des translators. Comme dit précédemment, les différentes applications - serveurs - du Hurd communiquent entre eux via un micro-noyau, actuellement, et encore pour un bon bout de temps, Mach. Le rôle de ce micro-noyau est de passer des messages - on dit qu'il est message-passing. Pour ce faire, il introduit le concept de ports. Un port est un canal unidirectionnel qui n'est matérialisé que par un droit sur ce port: un droit d'envoi, un droit « send-once » (envoi d'un seul message, utile pour les réponses vu que c'est unidirectionnel), et un droit de réception. (ce dernier n'étant bien entendu détenu que par une seule tâche..). C'est par le biais de ces ports que les applications communiquent entre elles, et par ce biais par exemple qu'une application du Hurd - ext2fs, par exemple - peut authentifier un utilisateur - via le serveur password, en lui envoyant un message, ou vérifier qu'il a le droit de faire telle ou telle opération -- en envoyant un message au serveur 'auth', etc... Le problème qui se pose alors, généralement, dans la conception de tel système est: comment une application - une tâche, au sens Mach - peut-elle obtenir un droit sur un port en direction de telle ou telle application ? Le moyen standard, et logique, est de faire un serveur de noms, exactement comme pour la résolution de noms via DNS. Vous m'accorderez cependant que c'est une solution relativement lourde, et peu élégante, puisqu'elle nécessite que chaque application s'enregistre au préalable, etc.. Dans le Hurd, l'idée est radicalement différente: on n'utilise plus un serveur de noms, mais on considère le file system comme un espace de nom! Ainsi, chaque fichier est attaché à une application, et écrire dans un fichier revient à envoyer un message à l'application qui écoute sur ce fichier. Pour un fichier « classique », il s'agira probablement d'un translator ext2fs - qui « écoute » sur tous les fichiers du système de fichiers montés, donc - qui agira à peu près comme
la gestion des FS de Linux. Cependant, cela permet des choses qui sont très difficilement faisables sous GNU/Linux. L'exemple le plus courant est celui du translator - un translator est une application qui « écoute » sur un fichier - de fortunes: votre client mail ne supporte pas les signatures aléatoires, or, vous voulez mettre des fortunes dans votre signature ? Aucun problème! Il vous suffira d'avoir un translator 'fortune', qui écrira, par exemple, dans ~/.signature (~ <=> le home de l'utilisateur qui a lancé le translator), mettant à jour la fortune grâce à l'utilitaire fortune à chaque fois que le fichier est accédé. Et voilà, votre application supporte maintenant les signatures aléatoires! :-) Je voua laisse imaginer les autres applications du principe des translators..
* La refonte du VFS - utilisant tout ce que permet la modularité du Hurd. Le nouveau VFS permet d'implémenter facilement - de façon stable, fonctionnelle - des systèmes de fichiers distribués (je pense principalement à ftpfs, qui permet de « monter » (si tant est que cela veuille dire quelque chose avec le Hurd) un FTP comme une partition), des nouveaux systèmes de fichiers - très intéressants.. - comme ShadowFS (cf. http://lists.debian.org/debian-hurd/1999/debian-hurd-199909/msg0004(...)),
etc.
Une application du concept des translators est montrée par le log suivant:
mmenal@dryden:~$ settrans -c /home/mmenal/ftp/ /hurd/hostmux /hurd/ftpfs /
mmenal@dryden:~$ cd /home/mmenal/ftp/ftp.fr.debian.org
mmenal@dryden:~/ftp/ftp.fr.debian.org$ ls
debian debian-cd debian-non-US
mmenal@dryden:~/ftp/213.245.76.60$ cd /home/mmenal/ftp/213.245.76.60/debs/
mmenal@dryden:~/ftp/213.245.76.60/debs$ ls
libdianewcanvas0-dev_0.6.4-1_i386.deb libdianewcanvas0_0.6.4-1_i386.deb libglade2-dev_1.99.5-1_i386.deb libglade2_1.99.5-1_i386.deb sources
Ainsi, on voit qu'on sort bien du concept classique des fichiers sous Unix, pour permettre au translator écoutant sur le répertoire /home/mmenal/ftp -- hostmux, pour host deMUXer -- de gérer comme il veut un accès à un fichier - en l'occurence, donc, en se connectant au ftp de même nom que le même fichier, et en le passant à ftpfs pour qu'il fasse son boulot à son tour.
C'est-y pas magnifique? :)
Enfin, le dernier avantage que je citerai est le système de sécurité. Pour résumer très brièvement (j'espère): on casse le modèle une application à un UID (et EUID, etc.). On considère ces « UIDs »
comme des jetons t'autorisant à un certain nombres de choses -- disant au serveur auth que tu as le droit de faire, telle, telle, ou telle opération. Ainsi, la gestion des UGIDs ne se limite plus à quelques changements, mais arrive à une vraie gestion de collections de droits: on peut rajouter des droits (addauth, en s'authentifiant, en demandant au serveur password si l'authentification est bonne), en enlever. On note par exemple qu'il existe ainsi un _vrai_ cas où une application n'a plus de droit: le cas où elle ne possède plus aucun jeton. La possibilité d'ajouter simplement des droits - ce qui n'existe pas naturellement dans le cadre d'Unix - permet ainsi d'éviter beaucoup de passages en root, et de n'avoir que les permissions nécessaires à chaque opération, pour limiter au *maximum* les dégâts potentiels d'une faille.
Bon, je pense que je vais m'arrêter là. Je suis désolé pour vous avoir encore donné un post immondede, indigeste, trop long, verbeux, et j'espère faire mieux en reprenant tout ça de façon bien organisée dans ma présentation à venir..
[^] # Re: rms l'utilise deja ...
Posté par Manuel Menal . En réponse à la dépêche GNU/Linux est mort, vive GNU !. Évalué à 10.
Ces précisisons étant dîtes, répondons. Qu'apporte-t-il ? Il faudrait bien plus d'un commentaire pour répondre à cette question. (la partie de ma présentation sur le Hurd à ce sujet fait déjà plus de cinq pages, et j'en suis à juste un peu plus du tiers :). À la base, l'esprit du Hurd est l'esprit du GNU - ou ce qu'il devrait être: étudier et reprendre les logiciels existants, essaye d'en retirer les avantages et les limites, et essayer de les casser, en faisant au maximum novateur, au maximum repensé. Pas juste une réécriture. C'est là où le Hurd diffère de Linux: Linux n'est qu'une réécriture d'Unix, où les améliorations résident dans l'implémentation. Le Hurd est différent d'Unix, puisque GNU's not Unix.
Les différences sont multiples. La première, et la principale, à laquelle on pense automatiquement est l'architecture d'un système GNU: au lieu d'un très gros programme - monolithique, donc - fournissant un tas de fonctionnalités dîtes de base pour un OS - là, la définition de ce qu'est un service de base n'est pas claire, puisque la seule vraiment rigoureuse serait de dire que c'est ceux fournit par le noyau Unix à la base - on a une serie de petits programmes indépendants, qui se chargent chacun d'une tâche - pfinet, pour tout ce qui est PF_INET (PF <=> Protocol Family, je vous laisse deviner pour INET), nfs pour le NFS, ext2fs pour ext2, password pour le serveur de passwords, etc, ces applications -- appelées serveurs -- communiquant entre elles via le micro-noyau. Ceci présente plusieurs avantages:
* Une plus grande modularité, au sens où l'on peut bâtir facilement des systèmes extrêmement minimaux ne contenant que les quelques services de base - les quatre ou cinq serveurs nécessaires au Hurd.
* Une plus grande stabilité. Entendons nous bien,
le Hurd n'apporte pas la stabilité absolue, les programmeurs sont malgré tout humains. :). Cependant, ce que peut faire un OS-base, c'est de réduire la gravité de ces bugs afin qu'un problème dans une application puisse difficilement rendre l'ensemble du système totalement inutilisable.
Il est clair que plus le programme est gros, plus il y'a de chance qu'un bug arrive. Ainsi, Linux devenant de plus en plus gros, il arrive, fréquemment - quasiment de plus en plus ;-) - qu'un bug dans une partie non-essentielle de Linux survienne, ce qui provoque, bien évidemment, un crash de l'ensemble du noyal. Sous le Hurd, dans la majorité des cas - c'est à dire, dans les cas où le bug survient sur un des serveurs n'étant pas essentiel a la « survie » du système - seule l'application responsable crashera, et ça n'ira pas plus loin. Par exemple, lorsque Jeff Bailey a mis, il y'a quelques temps de ça un serveur Web sous GNU, et l'a annoncé un peu partout, et que la nouvelle s'est retrouvée sur /., pfinet n'étant pas très solide, il n'a évident pas tenu la charge d'un slashdottage en règle.. (pensez bien, un truc comme ça). Dans le cas de Linux, cela aurait causé un crash du système et une non-disponibilité pendant quelques temps. Dans le cas du Hurd, il a suffit de relancer pfinet, et c'était reparti pour un tour. De plus, les opérations risquées peuvent facilement être faîtes dans un sub-Hurd, équivalent de UML - User-Mode Linux - qui est totalement naturel pour le Hurd, puisqu'il ne s'agit que de relancer des applications normales, et ne pose aucun problème -- contrairement à UML qui évolue lentement, nécessite des patches, et, du fait que Linux n'est pas prévu pour ça, pose pas mal de problèmes encore..
* Une plus grande disponibilité, en partie pour les questions de stabilité décrites ci-dessus, et également parce qu'il est plutôt rare d'avoir à changer le noyau, et que le changement de presque tout le reste peut se faire « à chaud ». De plus, la flexibilité pourrait imaginer deux pfinet tournant en parallèle, l'un relayant l'autre dès que le premier a fini, ceci permettant d'éviter les déconnexions en cas de problème, et par exemple, d'effectuer un changement de pfinet sans aucune déconnexion. Ce n'est qu'un exemple: la flexibilité qu'apporte la modularité du Hurd peut autoriser _nombre_ de choses très intéressantes comme cela, qui n'ont pas toutes été implémentées à l'heure actuelle.
* Enfin, il me semble que c'est quand même beaucoup plus beau, clean. Les rôles sont beaucoup mieux repartis, et chaque partie peut être facilement remplacée sans perturber les autres.
Mais ce n'est pas tout. On ne peut limiter le Hurd a son architecture: elle n'est qu'un élément de la recherche du toujours mieux, toujours plus novateur. On citera par exemple:
* Le principe des translators. Comme dit précédemment, les différentes applications - serveurs - du Hurd communiquent entre eux via un micro-noyau, actuellement, et encore pour un bon bout de temps, Mach. Le rôle de ce micro-noyau est de passer des messages - on dit qu'il est message-passing. Pour ce faire, il introduit le concept de ports. Un port est un canal unidirectionnel qui n'est matérialisé que par un droit sur ce port: un droit d'envoi, un droit « send-once » (envoi d'un seul message, utile pour les réponses vu que c'est unidirectionnel), et un droit de réception. (ce dernier n'étant bien entendu détenu que par une seule tâche..). C'est par le biais de ces ports que les applications communiquent entre elles, et par ce biais par exemple qu'une application du Hurd - ext2fs, par exemple - peut authentifier un utilisateur - via le serveur password, en lui envoyant un message, ou vérifier qu'il a le droit de faire telle ou telle opération -- en envoyant un message au serveur 'auth', etc... Le problème qui se pose alors, généralement, dans la conception de tel système est: comment une application - une tâche, au sens Mach - peut-elle obtenir un droit sur un port en direction de telle ou telle application ? Le moyen standard, et logique, est de faire un serveur de noms, exactement comme pour la résolution de noms via DNS. Vous m'accorderez cependant que c'est une solution relativement lourde, et peu élégante, puisqu'elle nécessite que chaque application s'enregistre au préalable, etc.. Dans le Hurd, l'idée est radicalement différente: on n'utilise plus un serveur de noms, mais on considère le file system comme un espace de nom! Ainsi, chaque fichier est attaché à une application, et écrire dans un fichier revient à envoyer un message à l'application qui écoute sur ce fichier. Pour un fichier « classique », il s'agira probablement d'un translator ext2fs - qui « écoute » sur tous les fichiers du système de fichiers montés, donc - qui agira à peu près comme
la gestion des FS de Linux. Cependant, cela permet des choses qui sont très difficilement faisables sous GNU/Linux. L'exemple le plus courant est celui du translator - un translator est une application qui « écoute » sur un fichier - de fortunes: votre client mail ne supporte pas les signatures aléatoires, or, vous voulez mettre des fortunes dans votre signature ? Aucun problème! Il vous suffira d'avoir un translator 'fortune', qui écrira, par exemple, dans ~/.signature (~ <=> le home de l'utilisateur qui a lancé le translator), mettant à jour la fortune grâce à l'utilitaire fortune à chaque fois que le fichier est accédé. Et voilà, votre application supporte maintenant les signatures aléatoires! :-) Je voua laisse imaginer les autres applications du principe des translators..
* La refonte du VFS - utilisant tout ce que permet la modularité du Hurd. Le nouveau VFS permet d'implémenter facilement - de façon stable, fonctionnelle - des systèmes de fichiers distribués (je pense principalement à ftpfs, qui permet de « monter » (si tant est que cela veuille dire quelque chose avec le Hurd) un FTP comme une partition), des nouveaux systèmes de fichiers - très intéressants.. - comme ShadowFS (cf. http://lists.debian.org/debian-hurd/1999/debian-hurd-199909/msg0004(...)),
etc.
Une application du concept des translators est montrée par le log suivant:
mmenal@dryden:~$ settrans -c /home/mmenal/ftp/ /hurd/hostmux /hurd/ftpfs /
mmenal@dryden:~$ cd /home/mmenal/ftp/ftp.fr.debian.org
mmenal@dryden:~/ftp/ftp.fr.debian.org$ ls
debian debian-cd debian-non-US
mmenal@dryden:~/ftp/213.245.76.60$ cd /home/mmenal/ftp/213.245.76.60/debs/
mmenal@dryden:~/ftp/213.245.76.60/debs$ ls
libdianewcanvas0-dev_0.6.4-1_i386.deb libdianewcanvas0_0.6.4-1_i386.deb libglade2-dev_1.99.5-1_i386.deb libglade2_1.99.5-1_i386.deb sources
Ainsi, on voit qu'on sort bien du concept classique des fichiers sous Unix, pour permettre au translator écoutant sur le répertoire /home/mmenal/ftp -- hostmux, pour host deMUXer -- de gérer comme il veut un accès à un fichier - en l'occurence, donc, en se connectant au ftp de même nom que le même fichier, et en le passant à ftpfs pour qu'il fasse son boulot à son tour.
C'est-y pas magnifique? :)
Enfin, le dernier avantage que je citerai est le système de sécurité. Pour résumer très brièvement (j'espère): on casse le modèle une application à un UID (et EUID, etc.). On considère ces « UIDs »
comme des jetons t'autorisant à un certain nombres de choses -- disant au serveur auth que tu as le droit de faire, telle, telle, ou telle opération. Ainsi, la gestion des UGIDs ne se limite plus à quelques changements, mais arrive à une vraie gestion de collections de droits: on peut rajouter des droits (addauth, en s'authentifiant, en demandant au serveur password si l'authentification est bonne), en enlever. On note par exemple qu'il existe ainsi un _vrai_ cas où une application n'a plus de droit: le cas où elle ne possède plus aucun jeton. La possibilité d'ajouter simplement des droits - ce qui n'existe pas naturellement dans le cadre d'Unix - permet ainsi d'éviter beaucoup de passages en root, et de n'avoir que les permissions nécessaires à chaque opération, pour limiter au *maximum* les dégâts potentiels d'une faille.
Bon, je pense que je vais m'arrêter là. Je suis désolé pour vous avoir encore donné un post immondede, indigeste, trop long, verbeux, et j'espère faire mieux en reprenant tout ça de façon bien organisée dans ma présentation à venir..