InterviewMarcusWikiNerds

De HurdFr_Wiki
Aller à : Navigation, rechercher

Ceci est une traduction, réalisée par Manuel Menal, de l'interview de Marcus Brinkmann menée par Nikolaos S. Karastathis (NSK) pour WikiNerds. Vous pouvez trouver le texte originel ici. Merci à Marcus Brinkmann et Nikolaos Karastathis d'avoir donné leur permission pour cette traduction. Merci aussi à Samuel Thibault et à Matthieu Lemerre pour leur relecture attentive.

Sommaire

Interview de Marcus Brinkmann, développeur du Hurd

Marcus Brinkmann est à vingt neuf ans un des développeurs principaux du Hurd et du projet Hurd/L4. Le 3 février dernier, le portail Wikinerds a publié un article [NdT: relayé sur DLFP] qui relatait l'aventure du premier programme exécuté sur Hurd/L4, suite aux travaux de Brinkmann sur le code d'initialisation de processus. Lorsque l'article s'est fait slashdotter, NSK a contacté M. Brinkmann et lui a demandé de faire une interview de lui pour Wikinerds.

Introduction au Hurd

Le Hurd fait partie du projet GNU, dont le sponsor est la Free Software Foundation. Son nom est formé par un double acronyme mutuellement récursif  : 'Hurd' signifie "Hird of Unix-Replacing Daemons", et 'Hird' à son tour signifie "Hurd of Interfaces Representing Depth".

Le projet GNU a été créé par Richard M. Stallman dans les années 1980 dans le but de créer un système compatible Unix entièrement libre, but qu'il a aujourd'hui accompli. Un grand nombre de distributeurs ont décidé d'associer GNU avec le noyau Linux, créant de ce fait le système que l'on connaît aujourd'hui sous le nom de GNU/Linux.

Le Hurd est une collection de serveurs qui tournent par-dessus un micro-noyau, c'est-à-dire un noyau minimaliste. Ces serveurs fournissent les services qu'on trouve habituellement dans les noyaux des autres systèmes d'exploitation, comme les systèmes de fichiers, les protocoles réseaux (TCP/IP), etc. Le premier prototype fonctionnel de GNU/Hurd utilise le micro-noyau GNU Mach, fournissant ainsi la base d'une distribution : Debian GNU/Hurd.

L4 est un micro-noyau de seconde génération originellement développé par le Dr Jochen Liedtke. Le projet Hurd/L4 vise à créer un système d'exploitation stable et utilisable en portant le Hurd sur L4.

L'interview

Nikolaos S. Karastathis : Pouvez-vous vous présenter et décrire les projets sur lesquels vous travaillez actuellement ?

Marcus Brinkmann : Mon nom est Marcus Brinkmann, je suis né et je vis en Allemagne, dans la vallée de la Ruhr. C'est une région avec une histoire riche liée aux mines de charbon et à la production d'acier, mais qui a changé très rapidement et continue à changer. C'est pour ça que plutôt que de fondre de l'acier, je fais de l'informatique.

Je travaille à temps partiel pour g10 code, la SSLL de Werner Koch, où mon boulot est de maintenir GPGME. Dans mon temps libre, je bosse sur le Hurd, en particulier sur le port du Hurd sur le micro-noyau L4.

Les premiers pas

Nikolaos S. Karastathis : Comment avez-vous appris à programmer, et quand avez-vous touché votre premier ordinateur ? Aimez-vous programmer, et pourquoi ?

Marcus Brinkmann  : J'ai d'abord appris à utiliser un ordinateur, et ensuite à programmer. En 1982 - j'avais 7 ans -, j'ai pu avoir accès à un Commodore 64. Je suis devenu instantanément accro. Je jouais, évidemment, mais à cette époque il y avait plein de magazines informatiques intéressants, où l'on trouvait des listings de programmes que vous pouviez entrer dans votre ordinateur. Pendant quelques temps, ça a été ma principale source de logiciels. J'achetais des magazines, et je rentrais les programmes dont le listing était fourni.

Parfois, je faisais des erreurs de frappe. Je n'arrêtais pas de me demander comment l'ordinateur faisait pour savoir où j'avais fait une erreur (évidemment, ce n'était pas toujours le cas - mais la plupart causaient des erreurs de syntaxe, ce que l'ordinateur me faisait immédiatement remarquer). Donc, entre les moments où je me suis demandé comment l'ordinateur fonctionnait, et les moments où je découvrais comment on pouvait lui apprendre à faire ce qu'on voulait (les magazines ne contenaient pas que des programmes aboutis, mais aussi des cours de programmation), j'ai découvert l'informatique. C'était l'époque de l'informatique personnelle.

La programmation était pour moi un challenge intellectuel, et un outil pour arriver à faire ce que je voulais (comme imprimer une représentation de l'ensemble de Mandelbrot, ou ce genre de choses). J'aime programmer parce que c'est un environnement totale prévisible et contrôlé. Si on exclut les problèmes matériels et le côté aléatoire des entrées, il n'y a pas d'incertitude. En même temps, il manque à la programmation pure toute la complexité de la vie humaine, et du coup elle peut être assez ennuyeuse.

Les choses ont énormément changé quand j'ai commencé à utiliser Internet, et que je suis rentré en contact avec la communauté du logiciel libre. Aujourd'hui, bosser sur du logiciel libre est au moins autant une quête intellectuelle qu'une lutte politique. La programmation est maintenant un outil pour la transformation sociale, et ça me rend vraiment heureux.

Le premier programme

Nikolaos S. Karastathis : Est-ce que vous vous souvenez du premier programme non trivial que vous avez écrit vous-même ? Qu'est-ce que c'était ?

Marcus Brinkmann : Je ne suis pas bien sûr, mais je me souviens avoir écrit un petit programme d'entraînement aux mathématiques sur mon Commodore 64, où vous aviez une montagne en ASCII art en fond d'écran, et une petite image de skieur au premier plan, et à chaque fois que vous répondiez correctement à une questions de maths toute simple (comme 7+5), le skieur passait une des portes du slalom. Ça doit remonter à quand j'étais à l'école primaire.

La philosophie du Libre

Nikolaos S. Karastathis  : Les réalisations de la communauté du logiciel libre sont considérables, et, comme vous l'avez dit, la programmation est maintenant un outil pour la transformation sociale. Pouvez-vous décrire la philosophie du Libre et ce qu'elle représente pour vous  ? Quelle est votre opinion sur les brevets logiciels, et comment ils affectent les développeurs de logiciel libre ?

Marcus Brinkmann  : Le logiciel libre est une obligation morale pour moi. Comme l'a formulé le fondateur de la Free Software Foundation, Richard Stallman, il est fondé sur trois droits : le droit d'utiliser et de distribuer un programme, le droit de le modifier, et le droit de distribuer vos modifications. Sans ces trois droits, le progrès est muselé, et le développement de notre culture est freiné.

Une licence restrictive vous retire ces droits, ces droits sont "réservés". Les brevets logiciels vont encore plus loin : ils vous empêchent toute forme d'expression sur une idée particulière. C'est pourquoi les brevets logiciels sont potentiellement bien plus dangereux pour notre patrimoine culturel que le droit d'auteur  : on peut toujours trouver des moyens d'expression différents, mais nous partageons tous les mêmes idées fondamentales.

Quelle que soit la façon dont on les étudie, les brevets logiciels sont une idée absurde. Presque tous sont triviaux, et ils n'ont aucune justification morale, économique, légale ou démocratique, et leurs conséquences sont absurdes. Personne ne voudrait vivre dans un monde où toutes les idées peuvent être brevetées et utilisées exclusivement par un tiers.

Tant que ce ne sont que les grandes entreprises qui ont à subir ça, ils ne sont pas un problème pour la majorité. Elles ont les moyens de mener bataille sur bien des plans, en particulier d'envoyer leurs troupes d'avocats se battre les uns contre les autres. Mais la menace est bien là : les brevets logiciels seront de plus en plus utilisés pour combattre le logiciel libre, pour lui empêcher la compatibilité, pour ruiner ses distributeurs et créateurs, qui sont majoritairement des individus isolés ou des petites entreprises.

Les brevets logiciels en Europe ont été institués par des avocats et grandes entreprises à l'insu du peuple, à l'origine principalement pour leurs propres intérêts : les avocats trouvent leur intérêt parce qu'ils créent encore plus de travail pour eux, et le système de brevets est entre les mains des groupes qui profitent le plus d'eux. Mais c'est à nous de savoir si nous préfèrerons laisser les brevets logiciels être institutionnalisés et devenir une arme contre le logiciel libre, ou si nous avons la volonté de mener la lutte.

Votre participation au Hurd

Nikolaos S. Karastathis : Comment en êtes-vous arrivé à contribuer au Hurd ? Qu'est-ce qui vous a attiré dans ce projet, et vous a motivé pour y contribuer ?

Marcus Brinkmann : En 1996, j'ai trouvé une version de SuSE dans une librairie, qui disait inclure TeX. Je connaissais TeX, j'en avais utilisé une version DOS des années auparavant, et j'avais étudié le TeX Book et le Metafont Book [NdT: deux livres de Donald Knuth] (je suis également mathématicien). Je ne connaissais rien d'autre de ce qu'ils disaient sur l'emballage, mais je voulais TeX. J'ai lentement compris que j'avais dans mes mains un système d'exploitation alternatif complet.

Quelqu'un dans un magasin d'informatique m'a dit qu'utiliser GNU/Linux sans avoir Internet n'avait pas grande utilité. J'ai réalisé que c'était vrai. Apparemment, il y avait de nouvelles versions des logiciels "là-bas", et aussi plein d'autres choses. J'ai donc acheté un modem et je me suis connecté, et je me suis retrouvé dans un monde totalement nouveau. Jusque là, je n'avais que les magazines et les vieux livres de bibliothèque pour apprendre l'informatique et la programmation. Tout à coup j'avais accès à ce qui se faisait de mieux dans la vraie programmation, et une énorme communauté autour.

Je me suis alors renseigné sur les options qui s'offraient à moi, et j'ai préfèré quitter SuSE en faveur de Debian GNU/Linux, une distribution crée et maintenue par la communauté. J'aimais l'idée des DFSG [NdT: Debian Free Software Guidelines, la définition du logiciel libre par Debian], et ce changement m'a aussi permis de ne plus payer les mises à jour. Après quelques mois d'utilisation, j'ai commencé à contribuer en participant aux listes de diffusion, et en devenant développeur Debian moi-même.

Un an plus tard, en 1997, j'avais acquis un bagage plus solide, et j'ai commencé à m'intéresser au projet GNU et à la Free Software Foundation. J'étais d'accord avec la ligne politique de la FSF. GNU était pour moi une garantie de qualité. Tous les projets GNU importants étaient de grande qualité, et je recherchais plus d'informations à propos du projet GNU. C'est à ce moment là que je suis tombé sur le site du GNU Hurd.

Encore une fois je ne savais pas à quoi m'attendre. J'avais compris que c'était encore un autre système d'exploitation alternatif. Il était libre. Il était mené par le projet GNU. Ca avait l'air intéressant, et je voulais le découvrir. Je me suis donc lancé dans cette longue aventure qu'était le téléchargement de 70MB de logiciel, ce qui a duré trois longues nuit. Je pouvais alors creuser la chose.

Je n'ai pas été déçu. Bien que le système soit plein de bugs, sa conception était intrigante. J'ai commencé par trouver et reporter des bugs, et puis plus tard par les corriger moi-même. Le système m'intéressait, il avait besoin de travail, mais personne n'était là pour le faire, et ça me plaisait bien de le faire  : c'est ce qui m'a décidé à contribuer.

J'ai lu dans le fichier TODO que GNU cherchait un système de paquets, et au vu de mon expérience avec Debian, j'ai pensé que j'étais la bonne personne pour ça. Alors j'ai commencé la distribution Debian GNU/Hurd en 1998. Presque tout ce que je faisais à l'époque était destiné à obtenir une distribution fonctionnelle de Debian GNU/Hurd.

Progressivement, j'ai commencé à travailler plus sur les sources du Hurd que sur les paquets Debian. C'était en général parce que c'était nécessaire pour porter telle ou telle application, mais plus j'apprenais, plus je comprenais, et plus je me rendais compte de ce qui manquait au Hurd et que certains problèmes de conception (aussi dans Mach) ne pourraient être corrigés par des petits changements ici et là. J'ai commencé à m'intéresser au Hurd dans son ensemble, et j'ai découvert que ses fondements méritaient d'être ré-évalués.

En un clin d'oeil, je me suis retrouvé à bosser avec d'autres sur la conception des couches basses du Hurd, et sur leur réécriture, en utilisant les dernières avancées dans le domaine de la conception de systèmes d'exploitation. C'est ce que je fais encore aujourd'hui.

L'architecture du Hurd

Nikolaos S. Karastathis  : Pouvez-vous décrire le Hurd, son architecture et ses principales spécificités ? Comment le projet Hurd et son port sur L4 ont-ils démarré ? Quels sont les avantages de L4, comparativement à GNU Mach, et à l'approche monolithique traditionnelle ?

Marcus Brinkmann : Le Hurd est un système multi-serveurs, tournant sur un micro-noyau. Cela signifie que des fonctionnalités du noyau, comme la pile TCP/IP, l'authentification, les systèmes de fichiers, sont implémentés sous la forme de processus distincts dans l'espace utilisateur, et non dans le noyau. Il y a peu de vrais systèmes multi-serveurs : la plupart des systèmes à micro-noyau que vous avez pu voir ne comportent qu'un seul gros serveur qui tourne par-dessus le micro-noyau, et sont donc en fait très similaires aux noyaux monolithiques comme Unix et ses clones.

La conception du Hurd va plus loin encore que les autres systèmes multi-serveurs et est centrée sur le droit de l'utilisateur à étendre et améliorer le système d'exploitation, en y apportant ses propres fonctionnalités. Les différents composants qui composent le Hurd ne sont pas obligés de se faire confiance. De ce fait, l'utilisateur, peut lancer ses propres systèmes de fichiers, et les rattacher (les "monter") au système de fichier principal. Il peut aussi ignorer les systèmes de gestion des processus fournis par le système, et créer et lancer ses propres services, pas forcément similaires à ce qu'indique POSIX.

Le but originel du Hurd était d'écrire un système d'exploitation pour les outils GNU, qui représentaient déjà un ensemble très complet au début des années 1990. Thomas Bushnell, le principal concepteur, a conçu le Hurd, et l'a écrit en utilisant le micro-noyau Mach. Roland McGrath a ensuite écrit la bibliothèque C GNU [NdT: GNU C Library], qui est également utilisée sous GNU/Linux de nos jours. Mais le caractère "multi-serveurs" s'est avéré difficile à implémenter. Les bugs étaient difficiles à trouver. Quand le système est devenu accessible et utilisable, Linux, dont la conception était beaucoup plus simple, avait déjà bien plus de fonctionnalités et était beaucoup plus mature : c'est pour ça qu'il est aujourd'hui tant utilisé comme base pour les outils GNU de nos jours.

Aujourd'hui, le GNU Hurd sur Mach est un prototype fonctionnel. Il en existe une distribution maintenue, Debian GNU/Hurd, que j'ai créée en 1998, et qui fournit des milliers de programmes prêts et compilés pour GNU/Hurd. Cependant, si vous utilisez cette version du Hurd, vous ne disposerez que de peu de support matériel, et il est assez lent, même pour un système à base de micro-noyau. Nous avons atteint un stade où nous avons pu prendre un peu de recul, et commencer à ré-évaluer le système dans son ensemble.

C'est ce qu'a fait Neal Walfield, en tenant compte des développements de la recherche sur les systèmes d'exploitation depuis la conception de Mach. Il a identifié un certain nombre de problèmes de conception dans Mach qui empêchaient le Hurd d'être pleinement fonctionnel. Le véritable problème avec Mach, c'est que même si bien des composants comme les systèmes de fichiers ont été enlevés du noyau, d'autres, fondamentaux, comme le mécanisme de communication entre processus [NdT: IPC, Inter-Process Communication] et la gestion des files de messages, ainsi que la gestion de la mémoire virtuelle, y ont été laissés.

Le problème avec le système d'IPC de Mach, c'est que même pour le plus simple des messages, vous devez subir le coût du traitement complexe des messages, et des multiples copies (vers le noyau, vers le destinataire, ...), alors que dans le cas général, nous n'en avons pas besoin.

Le problème de la gestion de la mémoire virtuelle de Mach est qu'il ne dispose pas d'assez d'informations sur comment la mémoire est utilisée pour la gérer intelligemment. Les noyaux monolithiques savent comment la mémoire est utilisée parce qu'ils peuvent l'associer à des systèmes de fichier, au réseau, aux tubes nommés, etc. Mais Mach ne connaît pas ces subtilités [NdT: qui sont reléguées à l'espace utilisateur et aux serveurs], et doit donc considérer toute la mémoire uniformément, ce qui amène beaucoup de mauvaises décisions qui affectent grandement les performances du Hurd.

C'est pourquoi nous avons commencé à étudier d'autres possibilités, et le micro-noyau L4, développé par le professeur Liedtke à Karlsruhe, nous a semblé être le choix évident. Il est fondé sur le principe qu'un noyau ne doit fournir que des mécanismes simplifiés à l'extrême. Mais ça voulait dire bien sûr que nous devions re-concevoir notre système de gestion de la mémoire, et notre système d'IPC. Neal a commencé le travail pendant l'été 2002, en se concentrant surtout sur la gestion de la mémoire, pendant que je développais ses idées à propos de la gestion des RPC [NdT: Remote Procedure Calls, les appels entre serveurs qui utilisent les mécanismes de communication entre processus] en espace utilisateur. Notre idée de base était que toutes ces décisions devaient maintenant être faites par les tâches elles-mêmes, qui ont toutes les données sous la main pour décider intelligemment. Par exemple, chaque tâche disposera d'une somme de mémoire physique, et maintiendra elle-même sa mémoire virtuelle. Toutes les décisions lui reviendront, de sorte que vous pourrez facilement utiliser votre propre algorithme de gestion de la mémoire, optimisé pour votre application.

Les couches supérieures du système ne changeront que très peu. Les changements que nous apportons sont assez radicaux, mais comme le Hurd est bien conçu à la base, le port ne requiert que peu de modifications. Bien entendu, c'est aussi une opportunité de corriger quelques erreurs mineures et d'aller encore plus loin dans les améliorations.

Vos contributions au Hurd

Nikolaos S. Karastathis : Quelles sont vos principales contributions au Hurd et à Hurd/L4, et quels sont les outils qui ont été importants pour vous pendant vos développements ?

Marcus Brinkmann : J'ai commencé par la création et la maintenance de Debian GNU/Hurd, qui m'a amené à trouver et corriger beaucoup de bugs dans le code du Hurd. Après ça, je me suis intéressé de plus en plus au Hurd lui-même, et j'ai commencé à ajouter des fonctionnalités plus qu'à en corriger. Mes principales contributions ont été l'écriture de FATfs, un serveur gérant le système de fichiers FAT, et la console du Hurd, qui est composée d'un client extensible par des greffons et d'un serveur qui supporte l'UTF-8, la possibilité de détacher et de rattacher à plusieurs endroits des terminaux virtuels [NdT: comme GNU screen(1)].

Je me concentre maintenant sur développement du Hurd sur L4. Pour l'instant, j'ai écrit le serveur qui gère les privilèges [NdT: c'est le serveur destiné à implémenter le contrôle de la communication entre processus ; il est écrit sous la forme d'une bibliothèque], et le code de démarrage. J'ai également commencé à porter la glibc, et ajouté des fonctionnalités manquantes à L4 (comme le support de TLS (Thread Local Storage)). Ce qui est bien, c'est qu'il y a déjà plein de code sur lequel on peut se fonder. On n'écrit vraiment que ce qui est totalement nouveau, et on puise le reste dans la version du Hurd pour Mach, ou dans la glibc. Bien entendu, comprendre et porter ces sources demande beaucoup de travail, et nous essayons toujours de les améliorer au passage, mais on n'a pas pas tout à réécrire.

Le développement du Hurd utilise le projet Savannah, et CVS comme outil de gestion des sources. J'utilise Emacs pour écrire mon code et gérer le CVS, gdb pour débugger, et QEMU pour tester. QEMU est un émulateur x86 rapide, écrit par Fabrice Bellard. Les mots manquent pour exprimer à quel point QEMU m'est utile, même si ses fonctionnalités de debugging sont quelque peu limitées comparées aux simulateurs existants. J'utilise aussi le debuggeur intégré à L4 avec beaucoup de succès. Bien sûr, j'utilise également les outils que nous utilisons tous, comme les binutils (surtout objdump). Bientôt, vous pourrez débugger vos propres programmes pour Hurd/L4 en utilisant gdb via une liaison série.

Taille des sources du Hurd

Nikolaos S. Karastathis : Combien de lignes compte le projet Hurd/L4 actuellement ?

Marcus Brinkmann : sloccount (de David A. Wheeler) donne ces résultats pour les sources de hurd-l4 :

Totals grouped by language (dominant language first):
ansic:        34737 (72.90%)
sh:           12815 (26.90%)
asm:             96 (0.20%)

Pour le CVS du Hurd :

Totals grouped by language (dominant language first):
ansic:       208441 (97.01%)
sh:            3937 (1.83%)
asm:           2153 (1.00%)
awk:            183 (0.09%)
perl:           158 (0.07%)

Il y a également une grande partie de code lié au Hurd dans la GLibc :

libc/hurd:

Totals grouped by language (dominant language first):
ansic:         6600 (100.00%)

libc/sysdeps/mach/hurd/

Totals grouped by language (dominant language first):
ansic:        14139 (98.34%)
awk:            132 (0.92%)
asm:            107 (0.74%)

Est-ce que ces chiffres ont une signification ? Pas pour moi du moins :)

Nikolaos S. Karastathis : Pour moi, ça veut dire que vous avez beaucoup bossé ;)

Des micro-noyaux

Nikolaos S. Karastathis : Pensez-vous que les systèmes à micro-noyau sont de façon inhérente plus lents que les systèmes à noyau monolithique ? Quelles sont les performances du Hurd sur L4, comparé à GNU/Linux et au Hurd sur Mach ?

Marcus Brinkmann  : Je ne pense pas que les systèmes à base de micro-noyau soient plus lents que les systèmes à base de noyaux monolithiques, de façon générale. Comme toujours, ça dépend de ce que vous faites, et de comment vous le faites. Bien sûr, il est vrai que si vous prenez un système d'exploitation traditionnel, comme le noyau Linux, et que vous le portez sous la forme d'un serveur au dessus d'un micro-noyau (comme MkLinux ou L4Linux), vous aurez une perte de performance globale. Dans le cas de L4Linux, elle est de l'ordre de 5 à 10%. Donc proposer de faire quelque chose du genre n'a évidemment pas de sens.

Il y a un argument théorique assez répandu qui veut que toutes les optimisations qu'on peut apporter aux systèmes d'exploitation à base de micro-noyaux peuvent être utilisés par les systèmes monolithiques, et que de ce fait les seconds seront toujours plus performants que les premiers. Ceci est seulement vrai dans un certain modèle de confiance, et seulement si vous vous intéressez aux performances brutes et non à tous les autres coûts en jeu.

Les micro-noyaux sont intéressants, parce qu'ils fournissent des possibilités que ne permettent pas les noyaux monolithiques, à un coût moyen inférieur. Vous échangez un peu de rapidité contre un temps de développement plus bas, par exemple. Prenons la sécurité, par exemple : est-il imaginable de prouver qu'un noyau monolithique est correct ? C'est très improbable. On peut au moins essayer de prouver qu'un micro-noyau l'est, et peut-être un sous-ensemble du système d'exploitation qui se greffe par-dessus (c'est ce que le projet Coyotos fait, par exemple).

Le but du Hurd est la flexibilité. Nous voulons rabaisser la barrière qui existe entre code "système" et "utilisateur" sous Unix, et cela sans compromettre la sécurité comme le font les systèmes totalement ouverts [NdT: notamment les exo-noyaux ou méta-noyaux]. Ce que les micro-noyaux permettent en terme de sécurité sont pour nous un levier pour garantir la liberté de l'utilisateur. C'est pour cela que nous développons des protocoles pour que les différents composants ne soient pas obligés de se faire confiance.

Si vous ne considérez que les performances brutes, sur la base de ce que les systèmes monolithiques peuvent faire pour vous, les systèmes à base de micro-noyaux ont mauvaise mine. Mais si vous vous intéressez à ce que les systèmes à base de micro-noyaux peuvent faire pour vous, les systèmes monolithiques ont _encore_ plus mauvaise mine, parce qu'ils ne peuvent pas faire bien des choses que nous pouvons faire, et parce que faire ce que nous faisons, même quand ils le peuvent, représente un coût prohibitif.

Pour le Hurd sur L4, nous n'avons aucune idée des performances, puisque nous n'avons pas encore un système complet pour tester. Nous savons que certaines opérations seront plus lentes que dans dans les systèmes monolithiques. Mais en revanche, nous fournirons des fonctionnalités que vous n'avez pas dans les autres systèmes. Par exemple, le fait que les tâches gèrent leur mémoire eux-mêmes. Bien sûr, pour en tirer parti, il faudra modifier les applications. Mais la beauté du Hurd, c'est qu'il trouve des moyens de permettre ces modifications et ces améliorations, tout en restant dans le contexte d'un système compatible POSIX. Mais je ne peux pas donner de chiffres pour l'instant.

Le Hurd et la sécurité

Nikolaos S. Karastathis : Les utilisateurs sont de plus en plus avides de sécurité et de stabilité. Est-ce que la sécurité a été une priorité pendant le développement du Hurd et son port sur L4  ? À quels points le Hurd et Hurd/L4 sont-ils stables actuellement ? Comment le système gère-t-il les plantages et les situations d'interblocage [NdT: deadlocks] ? Utilise-t-il un ramasse-miettes [NdT: garbage collector] ou des sémaphores ?

Marcus Brinkmann : Sécurité et stabilité sont deux questions très proches et profondément liées. Ce sont deux questions majeures pour n'importe quel système à micro-noyau. Cependant, nous pensons que sécurité ne doit pas vouloir dire perte de liberté. C'est un peu plus difficile, mais on peut être sûr tout en augmentant la liberté des utilisateurs. C'est notre but.

Le Hurd est conçu comme un ensemble de serveurs, chacun tournant dans son propre espace d'adressage. L'ensemble de ces serveurs fondent le système d'exploitation. Bien entendu, il y a des services critiques qui, s'ils plantent, vont faire redémarrer le système - c'est son dernier espoir de sauver la situation. Mais pour beaucoup d'autres services, un plantage n'est pas fatal au système. Si un serveur de système de fichiers (qui n'est pas le système de fichiers racine) plante, vous avez juste à le redémarrer (ou alors c'est fait automatiquement par le système). Les situations d'interblocages nécessitent une intervention manuelle, qui consistera simplement à tuer le serveur fautif, l'enlever du système et libérer les ressources qui y étaient associées.

Le Hurd allie stabilité et sécurité en fournissant aux composants des protocoles qui ne nécessitent pas une confiance mutuelle. Ainsi, même si un utilisateur peut lancer son propre système de fichiers et l'attacher à l'arborescence principale, même si le système de fichiers parents redirigera les accès au point de montage au système de fichiers de l'utilisateur, il n'y a rien que le système de fichiers de l'utilisateur puisse faire pour affecter le reste du système. Les serveurs du Hurd sont écrits pour attendre le pire de ceux à qui ils s'adressent, c'est-à-dire pour considérer qu'ils en veulent au système. Du coup, la tolérance aux failles est naturelle.

Évidemment, dans la vraie vie, ça n'est pas aussi simple que la théorie. Le code actuel comporte beaucoup de bugs, et quelques problèmes mineurs de conception qui rendent le système sensible aux attaques, en particulier aux denis de service. Quelques uns seront corrigés par le port du Hurd sur L4, puisqu'ils sont concernés par le travail de re-conception. Il est probable que les quotas par utilisateur ne fonctionneront pas d'entrée de jeu : c'est un problème très intéressant, mais difficile à résoudre. Je pense que ça peut faire l'objet d'ajouts ultérieurs, si les bases sont saines.

Des pilotes de périphériques

Nikolaos S. Karastathis : Pouvez-vous nous dire comment un programmeur peut écrire un pilote de périphériques pour le Hurd, et son port sur L4. Qu'est-ce que ces programmeurs doivent connaître du Hurd  ? Peut-on porter les pilotes de GNU/Linux vers le Hurd et vers Hurd/L4 ?

Marcus Brinkmann  : Nous considérons que les pilotes de périphériques sont quelque peu extérieurs à la portée de notre projet. Nous pensons qu'ils sont de fait du code "système", en quoi on doit faire confiance. Nous n'avons donc pas de théorie sur comment faire des pilotes de périphériques "à la Hurd", et nous ne fournissons pas de fonctionnalité orthogonale particulière, comme l'accès direct au matériel que permettent les exo-noyaux. Nous avons donc créé un second projet, qui vise à développer les fondements d'un système de pilotes de périphériques, mais il n'a pas beaucoup avancé pour le moment. Nous avons un serveur d'accès aux périphériques, qui permet d'englober ce système de gestion des périphériques de façon à ce qu'il s'intègre bien au Hurd. Ceci doit vous permettre, en théorie, d'utiliser différents systèmes de gestion des pilotes avec Hurd/L4.

La vraie raison pour laquelle nous ne nous en chargeons pas nous-même est qu'il n'y a rien d'intéressant à faire avec les pilotes de périphériques, de nos jours. En fait, utiliser directement les primitives L4 pour le développement de pilotes permet de simplifier grandement le code, et c'est même très amusant à faire. Mais il existe tellement de matériels divers que, pour être réaliste, vous devez vous préparer à récupérer des pilotes existants et à les ré-utiliser pour votre système, par un mécanisme contrôlé. Ca n'a donc plus grand sens de fournir des abstractions particulières pour ces programmes.

Cependant, nous nous préoccupons beaucoup du système de gestion des pilotes. Par exemple, notre système de conteneurs nous permettra d'acheminer les données du pilote à l'utilisateur sans aucune copie de données [NdT: mécanisme dit zero-copy].

Le développement de pilotes est donc assez indépendant du Hurd, à moins que vous ne souhaitiez écrire le code de liaison [NdT: avec les différents systèmes de pilotes]. Il y a quelques projets intéressants qui visent à ré-utiliser les pilotes de Linux dans un environnement L4, mais nous ne les avons pas vraiment étudiés de près pour l'instant.

Conseils pour les nouveaux programmeurs

Nikolaos S. Karastathis  : Je suis certain que bien des lecteurs réfléchissent à devenir programmeur. Pouvez-vous leur donner des conseils ? Pensez-vous qu'il est mieux d'apprendre plusieurs langages à la fois, ou d'apprendre un seul langage, mais dans sa totalité ? Quels sont les principales qualités qu'on programmeur doit avoir ?

Marcus Brinkmann : Vous devriez découvrir autant de langages que vous pouvez en rencontrer (dans la limite du temps disponible). De même pour tous les autres outils. Vous ne pourrez pas être un expert dans tous, ou même dans un grand nombre, mais vous aurez une idée de ce qui existe et de ce qu'ils sont et font, et ainsi vous vous exposerez à plein de nouvelles idées. Remarquez cependant qu'un langage n'est jamais qu'un moyen d'exprimer vos idées sous une forme codifiée. Comme tous les outils, vous devrez apprendre quand et comment vous pouvez l'utiliser pour un programme particulier. Et comme tous les outils, il peut vous aider, ou vous freiner.

Pour devenir un programmeur expert, vous devrez connaître les outils disponibles, mais aussi en choisir quelques-uns qui correspondent à vos besoins, et devenir un utilisateur aguerri. Vous devrez donc apprendre à fond certains langages. Malheureusement, comme toujours dans la vraie vie, quand vous quittez l'abstraction et descendez dans les détails de l'implémentation, les outils comme les compilateurs devront cesser d'être des boîtes noires pour vous. Par exemple, vous commencerez à vous intéressez à la façon dont votre programme accède à la mémoire, et comment il interagit avec le cache du CPU. Ce savoir-là, vous ne le trouverez pas dans les livres  : vous devrez le découvrir par l'expérience.

Tenez, un exemple tiré de la vraie vie. Il y a bien des années, j'ai acheté un PDA avec GNU/Linux dessus, l'Agenda VR3. Ce matériel avait beaucoup de problèmes, et n'a pas bien marché. En particulier, la fonction "Calendrier" était très lente. Quelqu'un a décidé d'étudier [NdT: profile] le code en action, et en a trouvé la cause. Le calendrier utilisait les bits d'un champ entier comme des drapeaux [NdT: flags]. Mais plutôt que d'utiliser un décalage binaire de la forme "1 << n" pour accéder à chaque bit, le programmeur avait utilisé la fonction mathématique "pow (2, x)", et sur cette architecture, toutes les opérations à virgule flottante se trouvaient être particulièrement lentes. On se demande toujours ce à quoi l'auteur pensait. Évidemment son code était "correct", dans le sens qu'il atteignait son but. Peut-être le programmeur considérait-il "pow()" comme une boîte noire. Peut-être savait-il qu'il utilisait des opérations à virgule flottante mais pensait que le compilateur saurait l'optimiser de façon à utiliser un décalage binaire. Dans ce cas, l'auteur ne connaissait pas assez bien son langage et son compilateur (si je me souviens bien, les règles liées à la conversion de type interdisaient ce genre d'optimisations).

Je pense que ça illustre bien ma pensée : la plus grande qualité d'un programmeur, c'est de garder en tête ce que l'ordinateur est en train de faire quand vous lui donnez telle ou telle instruction. C'est important, aussi bien pour être sûr que votre code est correct, et plus en détails pour avoir une bonne estimation des performances de votre code en utilisation réelle. La plupart des programmeurs sont très mauvais quand il s'agit de prédire l'efficacité de leur code. Mieux vous connaissez vos outils, plus vous avez d'expérience avec, plus vous pourrez être sûr de ce que l'ordinateur fait réellement de votre code, et plus vous pourrez l'optimiser pour qu'il se comporte exactement de la façon dont vous le voulez. Bien sûr, vous aurez également besoin de debuggeurs et de profileurs pour vous aidez dans cette tâche.

Je voudrais ajouter une chose  : vous programmez certes pour une machine, mais avant tout pour des êtres humains. N'oubliez jamais ça. Le meilleur code au monde peut être complètement inutile si personne n'arrive à comprendre ce qu'il fait et pourquoi il le fait de cette façon. Une autre qualité primordiale est donc d'écrire de la documentation, de bons commentaires dans votre code source, et de structurer votre travail de façon à ce qu'il soit accessible pour les autres développeurs. La plupart des grands travaux de programmation aujourd'hui sont réalisés en équipe. Tirez l'inspiration de code source que vous savez être de grande qualité, et respectez les règles quant au style de code.

Participer au Hurd

Nikolaos S. Karastathis : Comment un développeur peut-il rejoindre les projets Hurd et Hurd/L4 ? Comment se passe le développement du Hurd ? Pouvez-vous fournir des informations que vous considérez nécessaires aux développeurs qui veulent participer au projet ?

Marcus Brinkmann  : Vous ne "rejoignez" pas le Hurd comme vous rejoindriez un club. Vous participez juste. Peu de gens ont accès en écriture au CVS, et nous n'ajoutons pas tous les contributeurs : nous préférons relire les patchs et les ajouter nous même quand nous en sommes satisfaits. C'est une exigence considérable, mais la plupart des patchs sont d'abord intégrés au paquet Debian GNU/Hurd du Hurd, où ils sont testés, avant d'intégrer le CVS. Notre FAQ décrit la façon dont doivent être soumis les patchs. Vous devriez rejoindre les listes et annoncer que vous souhaitez travailler sur telle ou telle chose.

Nous exigeons des contributeurs qu'ils transfèrent leurs droits d'auteur à la FSF pour les changements qu'ils font sur le Hurd. De plus en plus de projets le font, et vous verrez que ça continuera. Une des préoccupations de la FSF a toujours été de défendre le respect du droit d'auteur et de l'intégrité du code dont elle détient le droit d'auteur, mais d'autres vont commencer à comprendre à quel point il est important de s'en préoccuper, au fur et à mesure que les violations de licence - lorsque les distributeurs intègrent du code libre dans des systèmes propriétaires par exemple - et que les attaques contre le logiciel libre - lorsque des personnes réclament les droits sur du code qu'ils n'ont pas écrit - se font légion.

Ceci dit, il est assez difficile d'appréhender le Hurd, à cause de sa conception multi-serveur multi-threadée. Vous devez vous attendre à passer quelques mois à étudier et apprendre avant d'être opérationnel pour mener des projets plus importants. Mais même ça est plutôt amusant, surtout si vous l'accompagnez de tâches plus simples comme la chasse aux bugs. Pour les programmeurs compétents, c'est une opportunité d'apprendre plein de choses qu'ils n'apprendront pas dans d'autres projets.

Le futur...

Nikolaos S. Karastathis : Qu'est-ce que vous voyez comme futur pour le Hurd et son port sur L4 ? Surtout pour Hurd/L4 : dans quelle direction le développement va-t-il aller maintenant ? Quels sont vos objectifs personnels pour le futur, en-dehors du Hurd ?

Marcus Brinkmann : Pour le port du Hurd sur L4, nous essayons de vraiment prendre le projet par les cornes et de corriger les problèmes fondamentaux qui nous sont apparus dans le Hurd ou dans Mach. Nous essayons de porter le principe de "tout-faire-dans-l'espace-utilisateur-sans-faire-confiance" à l'extrême, et de trouver de nouvelles solutions à d'anciens problèmes, comme une allocation intelligente des ressources. Par exemple, sous GNU/Linux, si vous gravez un CD et qu'en parallèle vous essayez de jouer un fichier audio, la lecture saute régulièrement. Bien que la lecture nécessite peu de bande passante, il la lui faut au bon moment. La gravure de CD interfère avec ce processus. C'est un problème aussi vieux que les systèmes d'exploitation, pour lequel il n'y a pas de bonnes solutions prouvées, juste de la recherche et des idées que nous allons essayer parce qu'elles se fondent bien dans notre conception globale.

Comme nous sommes en train de construire un système fondé sur les privilèges, nous rencontrons évidemment les mêmes problèmes que tous les autres systèmes de ce genre : comment les implémenter de façon sûre et efficace à la fois ? C'est également une question à laquelle il n'y a pas de réponse unique et définitive actuellement.

Ce sont les problèmes fondamentaux que nous rencontrons. Une fois que nous aurons réussi à implémenter ces primitives d'une façon satisfaisante, nous pourrons alors porter la personnalité POSIX du Hurd avec peu de changements.

Nikolaos S. Karastathis  : Merci beaucoup d'avoir pris de votre temps pour répondre aux questions. Continuez votre excellent boulot sur Hurd/L4 !


Le texte de cet article est Copyright (C) 2005 par Marcus Brinkmann et Nikolaos S. Karastathis. La copie et la redistribution verbatim du texte entier de l'article sont permises, sous réserve que cette notice soit préservée et qu'une référence à l'adresse originelle soit fournie. Les réponses de Marcus Brinkmann sont sous licence CC-SA.

Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Outils