La création de la distribution, 1re partie

1.  La naissance de la distribution Gentoo Linux

Linux et moi

Pour chaque geek Linux, il y a un moment où Linux devient plus qu'un nom et se révèle être comme quelque chose de plus merveilleux, plus puissant et plus intrigant que tout ce qu'un développeur n'a jamais rencontré. Ma révélation est venue pendant que je travaillais à l'Université du Nouveau Mexique (University of New Mexico) comme administrateur système. Notre serveur NT fonctionnait assez bien et j'avais un peu de temps libre. Alors, j'ai installé Debian sur un serveur en Pentium 166 et j'ai commencé à apprendre, à apprendre, à apprendre et à apprendre. Et alors, j'ai été accroché.

Tout d'abord, j'ai appris les bases de Linux en long, en large et en travers : comment l'enrichir, réaliser des sauvegardes, faire fonctionner Samba, etc. Puis j'ai installé Qmail et Apache, j'ai appris la programmation en Python et en Shell. J'ai construit un intranet départemental. J'ai installé Linux à la maison et j'ai commencé à essayer différentes distributions. Finalement, j'ai installé Stampede Linux. Vous savez comment ça commence : d'abord, vous vous battez pour comprendre les bases de Linux, puis quand vous commencez à en avoir une bonne connaissance, vous personnalisez votre Linux tout en continuant à apprendre. Parce que Linux n'a rien à cacher, vous pouvez explorer la technologie et les outils tandis que vous vous améliorez dans la maîtrise de Linux.

Linux est un potentiel

Linux a offert quelque chose que je n'ai jamais vu avant. Si je devais mettre un mot sur cette chose de magique, ce serait « potentiel » : le potentiel de modifier, d'améliorer, de corriger des choses et oui, même de casser des choses. Au fur et à mesure que je faisais des mises à jour vers des nouvelles versions du noyau, j'ai vu Linux s'améliorer devant mes yeux et se transformer presque quotidiennement. Et c'était parti ! J'étais une pièce de la transformation. C'était amusant.

Si vous êtes quelqu'un comme moi, avant que vous n'ayez été exposé à Linux et à l'open source, vous avez regardé ces grandes compagnies de Redmond et de Cupertino fournir un système d'exploitation de la nouvelle génération qui travaillerait enfin comme vous le voudriez. Mais hélas, ce rêve n'est jamais devenu une réalité. Et tandis que nous attendions, Linux est arrivé. Et bien qu'il y ait eu beaucoup d'imperfections, il nous a fourni quelque chose que nous pouvions améliorer en attendant la prochaine grande chose. Alors un jour, nous nous sommes réveillés pour constater que Linux était devenu cette prochaine grande chose. Et continuant à sourire, nous avons continuer à bidouiller.

Linux est un ensemble de personnes

Ce que j'ai appris ensuite, c'est que Linux est un ensemble de personnes. Ce n'est pas rafraîchissant ? Linux n'est pas juste qu'un bouquet de code source. C'est une communauté. Nous comptons sur cette communauté pour trouver la réponse à nos questions et nous commençons à faire partie de la communauté quand nous commençons à aider les autres en y faisant partager notre expertise et en y consacrant un peu de notre temps.

IRC (Internet relay chat) est un grand endroit pour rencontrer des gens et pour y passer énormément de temps. Le canal #stampede sur irc.openprojects.net est devenu mon lieu de visite officiel. C'est là où je posais mes questions sur Linux. C'est aussi là où j'ai commencé la première fois à dépanner d'autres personnes. Le canal #stampede avait désespérément besoin d'utilisateurs Linux expérimentés pour aider les débutants qui venaient juste d'installer la distribution. Comme c'est souvent le cas sur l'IRC, beaucoup des personnes expérimentées sur Stampede ont perdu leur ardeur pour répondre à une question (encore une autre) d'un débutant. Mais j'étais si excité de savoir répondre aux questions des débutants que je ne pouvais pas résister à les aider. Et c'est comme ça que ma participation avec Stampede a commencé. J'étais juste un autre gars qui aimait répondre aux questions. Bien sûr, ce n'était pas entièrement altruiste parce que je me suis également aidé à améliorer mes connaissances d'expert Linux avec l'aide que pouvaient m'apporter les personnes les plus expérimentées sur le canal (pour ne pas dire les développeurs Stampede eux-mêmes !).

S'impliquer

Quand les gens me demandent comment s'impliquer dans un projet open source, je leur dis de trouver un endroit où ils peuvent être utiles, même si c'est juste en aidant avec des questions Linux de base. Un désir sincère d'aider les autres est un billet d'entrée important dans la communauté Linux parce que ce sentiment est au coeur de tous les développements open source (incluant Linux). Du moins, il devrait l'être.

Sur la route, vous rencontrerez inévitablement des personnes qui en savent plus que vous et vous apprendrez d'eux tout comme les débutants continuent à apprendre grâce à vous. C'est aussi comme ça que vous vous acquerrez plus d'expérience en trouvant des occasions d'aider de différentes façons. Peut-être que quelques uns des développeurs que vous rencontrerez par hasard vous suggérerons quelque chose ou demanderont de l'aide par eux-mêmes. Ils peuvent même vous inviter à faire partie de l'équipe de développement. Si vous êtes intéressé pour aider les autres, ils seraient idiots de vous laisser passer. Si vous dépannez beaucoup de personnes, vous serez certainement remarqué dans la communauté. C'est un peu de cette façon que ça s'est passé entre Stampede et moi.

Progressivement, je suis devenu de plus en plus impliqué dans le développement de Stampede. Peu après, j'étais un développeur officiel de Stampede. Avec la bénédiction de skibum (Matt Wood, le fondateur de Stampede), j'ai commencé à travailler sur une nouvelle version du format de paquets « .slp » de Stampede. À ce moment-là, le format de paquets « .slp » consistait en un fichier contenant une archive « .tar.bz2 » suivie d'une zone à taille fixe permettant de stocker des informations sur l'auteur du paquet, une description du contenu, etc. Cette approche avait deux problèmes majeurs : les champs étaient d'une longueur fixe dans une zone pas si grande que cela et aucun mécanisme d'extensibilité n'avait été prévu (on ne pouvait même pas rajouter un nouveau champs). Évidemment cela a nécessité une révision majeure.

En travaillant avec d'anciens développeurs Stampede, j'ai préparé une proposition sur la façon de traiter le problème. Puis j'ai commencé à coder un prototype des outils en Python. Le nouveau format (appelé slpv6) était quelque chose de similaire au format de fichier IFF du monde Amiga. Ce format « .slp » de nouvelle génération pouvait accepter 2^32 champs différents, 2^32 catégories de champs et une longueur maximale pour les données de 2^32 octets. Non seulement le format était vraiment extensible, mais c'était aussi plus compact que du simple texte et facile à analyser. Les données binaires et au format texte pouvaient être enregistrées, ce qui permettait beaucoup de possibilités pour l'avenir. L'idée était de coller cet en-tête dynamique de nouvelle génération sur la fin du fichier d'archive produisant ainsi un format « .slp » de nouvelle génération qui servirait aux utilisateurs de Stampede pour les années à venir et maintiendrait en même temps la compatibilité avec les formats d'archives standards d'Unix.

Les gens peuvent devenir laids

Le développement de slpv6 se passait bien et tous les anciens développeurs étaient heureux de mon travail. Mais malheureusement, deux développeurs Stampede d'un plus petit niveau ont voulu contrôler le projet de slpv6. Ils n'aimaient pas la direction que je prenais et ils passaient la plupart de leur temps à insulter le nouveau système slpv6. Bien que j'ai passé des heures dans des discussions de développement échauffées pour défendre la proposition face à leurs attaques, nous n'avons pas été capables de résoudre quoi que ce soit. Finalement, c'est devenu clair qu'ils argumentaient naturellement et qu'ils ne seraient pas heureux tant qu'ils n'avaient pas raison. Heureusement pour moi, mon projet a eu l'approbation des anciens développeurs de Stampede. Mais ces discussions ont commencé à me fatiguer et le développement de Stampede devenait très désagréable. Pouah !

Je ne pouvais pas éviter ces gars car je devais aller sur le canal #stampede pour discuter avec les développeurs de plus haut niveau. Et chaque fois que j'étais sur le canal, ils commençaient à être agressifs en essayant de saper mon travail. Ils utilisaient des techniques tordues comme demander des réunions de développement (en réalité, c'était juste une opportunité d'insulter mon travail en face des anciens développeurs). Ils ont essayé aussi de demander des votes pour essayer d'obtenir le contrôle de Stampede. Bien sûr, ils ont juste demandé un vote au moment où ils avaient convaincu assez de personnes d'être d'accord avec eux. Malgré tout cela, j'ai continué mon développement de slpv6. Inutile de le dire, les anciens développeurs ont aimé mon travail et voulaient que je continue (sans leur support, je n'aurais pas été capable d'y arriver).

Comprendre les détracteurs

Ces deux gars appartiennent à une catégorie de développeurs que j'aime appeler « les détracteurs » (« freaks »). Mais malgré le fait qu'ils m'aient rendu le travail de développement désagréable, j'ai aussi appris beaucoup sur la façon d'avoir affaire à eux. À ce sujet, je voudrais vous offrir un exposé des développeurs détracteurs, une sorte de vue d'ensemble complète : les qualités qui en font un, leur mode de fonctionnement et comment vous, le chef de projet du développement, pouvez confronter et probablement en venir à bout sans exercer beaucoup d'efforts.

Afin d'éviter des dommages émotifs, vous aurez besoin d'un pré-requis : une colonne vertébrale. Si vous n'êtes pas capable de confronter le détracteur d'une façon respectueuse mais ferme, il n'y a aucun espoir. Son but est de contrôler autant que possible votre projet de sorte qu'il se sente puissant. Il utilisera plusieurs techniques pour y parvenir. Tout d'abord, il commencera à critiquer injustement ou à se plaindre amèrement au sujet d'un projet et/ou des développeurs qui travaillent sur un projet. Puis ils s'abstiendront d'apporter des solutions constructives. Ils ne seront également pas disposés à contribuer au projet d'aucune manière à moins qu'ils ne soient promus au rôle de chef de projet. Leur but est de vous convaincre de leur donner autant d'autorité que possible alors ils peuvent résoudre des problèmes qu'eux seulement, avec leurs yeux de détracteurs finement entraînés, peuvent voir.

Si la critique et le fait de se plaindre ne sont pas efficaces, ils demanderont une réunion de développeurs. Ce sera leur opportunité d'essayer de diviser votre équipe de développeurs en deux camps. Quand ils pensent qu'ils ont assez de personnes de leur côté, ils demandent un vote (sachant qu'ils gagneront). S'ils ne gagnent pas le vote ou s'ils sont outrepassés, ils provoqueront une autre réunion de développeurs la semaine suivante dans laquelle ils essaieront encore de diviser votre équipe de développement. Ils répéteront indéfiniment ce processus.

Si l'approche de la réunion de développeurs ne fonctionne pas, les détracteurs deviendront des réformateurs. En adoptant ce rôle, ils vont essayer de rationaliser (lisez : saper) le processus décisionnel exécutif accablant et injuste en essayant de le remplacer avec quelque chose de plus démocratique (lisez : facilement manipulable). Cela impliquera souvent de vous convaincre que vous devez faire ce que la majorité des développeurs veulent. Les détracteurs aiment cela parce que vous ne pouvez plus outrepasser ces votes de réunion de développeurs (muhahaha !). Si vous permettez que cela se produise, vous leur avez donné la clef de votre Lexus. Vous êtes impuissant.

Dans une autre approche, les détracteurs irriteront et vous conduiront loin vos développeurs productifs. Alors ils entraîneront votre équipe entière dans une frénésie comme ils essaient avec force de réformer la structure puissante du projet. Si tous leurs efforts sont finalement vains, ils essaieront de rassembler autant de déserteurs que possible pour travailler sur une nouvelle version de votre projet. Aïe !

Gérer les détracteurs

Vous pouvez identifier ces gars assez facilement. Il y a ceux qui n'écrivent aucun code (et qui n'ont pas l'intention de le faire). Au lieu de ça, ils passent leur temps à parler de choses plus importantes. Vous savez, ces solutions de management. Si vous êtes un chef de projet, c'est assez facile de traiter avec eux. Dites-leur juste que vous ne prendrez en compte aucune proposition excepté s'ils produisent du code qui fonctionne. Ou insistez sur le fait qu'ils aident le projet en cours, incluant l'obéissance du chef de projet avant de leur donner l'opportunité d'apporter n'importe quelle critique (constructive). S'ils écrivent un peu de bon code ou commencent à être plus utiles, super. Sinon, dites-leur de partir. Soit ils laisseront le projet (si vous les ignorez assez longtemps) ou alors ils prendront acte et commenceront à écrire du code et, en général, deviendront plus agréables.

Malheureusement les anciens développeurs de Stampede ne connaissent pas la gestion des détracteurs. En d'autres mots, ils ont permis à ces gars de m'agacer (et d'en agacer d'autres) à n'en pas finir. Bien que les anciens développeurs étaient toujours en faveur de mon travail de développement, ils n'ont pas fait grand chose pour avoir ces gars sous contrôle. Alors un jour, j'ai décidé qu'il serait plus facile de créer ma propre distribution plutôt que de devoir accepter les deux détracteurs. J'ai démissionné du développement de Stampede et j'ai commencé à faire des plans pour produire ma propre distribution.

Même si je me sentais un peu bizarre de quitter un projet à cause de deux développeurs de bas niveau, le fait qu'ils n'aient pas vraiment été gérés indiquait que le projet avait de sérieux problèmes de gestion. Si les développeurs de plus haut niveau ne pouvaient pas ou n'étaient pas disposés à ce que les efforts pour le développement de Stampede soient plaisants et gratifiants alors je n'avais rien à y faire.

Le fait de recommencer

Une fois que je suis parti, j'ai eu un grand soupir de soulagement. Wouah ! Enfin, les choses étaient calmes et tranquilles. Maintenant, c'était le moment de définir ce que ma distribution devait être et comment elle pouvait contribuer sur la scène des distribution Linux. L'une des choses qui m'avait attiré dans la distribution Stampede était sa rapidité d'exécution (grâce à son utilisation du compilateur expérimental pgcc optimisé pour Pentium). Alors j'ai décidé de m'intéresser d'abord à la performance. En plus de minimiser l'utilisation du CPU, je voulais aussi minimiser la taille. Trop de distributions activent tellement de services par défaut que vous n'avez quasiment plus de mémoire RAM disponible après avoir ouvert un terminal « xterm ». Je voulais que ma distribution soit maigre et moyenne et je me suis intéressé à maximiser la performance du matériel sur lequel elle tournerait. J'ai décidé d'adopter une approche holistique et d'aborder le problème de performance par tous les angles.

Mais j'ai eu un sérieux manque de ressources puisque j'étais le seul développeur pour ma distribution ! Comment pouvais-je créer quelque chose qui serait comparable à la « Caldera » ou à la « RedHat » moi-même ? La réponse était l'automatisation. J'ai eu à écrire des scripts pour tout automatiser de sorte à avoir besoin d'un minimum de temps à consacrer aux tâches répétitives. Après tout, c'est ce que les ordinateurs font de mieux.

J'ai rapidement vu que d'écrire des scripts simples pour automatiser ne serait pas assez. J'ai dû concevoir un système complet pour générer une distribution Linux à partir de zéro. Je l'ai appelé à titre d'essai le système « ebuild » et j'ai commencé à travailler. Le système « ebuild » devait être capable de créer automatiquement tous les binaires de la distribution, tout automatiser de la décompression, à l'application des correctifs lors de la compilation, à l'installation et au packaging. Après avoir obtenu un prototype de l'« ebuild », j'ai commencé à créer des scripts « ebuild » pour les composants-clés d'une distribution Linux (comme gcc, glibc, binutils, util-linux et compagnie). Mon environnement de développement de Stampede devenait progressivement mon propre système car j'ai remodelé les scripts d'initialisation (les basant sur les scripts d'initialisation de Stampede que j'avais précédemment conçus), testé et installé chaque nouveau paquet que je créais.

Quelques mois plus tard, j'avais eu une distribution Linux complète et son propre hébergement. Je l'ai appelée Enoch, je me suis rassis et j'ai souri, satisfait. Mais qu'est devenu Enoch et comment a-t-il évolué en Gentoo Linux ? Rejoignez-moi dans mon article suivant où je vous raconterai l'histoire de comment Enoch est devenu Gentoo Linux et les nombreux nouveaux challenges auxquels j'ai dû faire face.

Ressources

• Continuez à lire mon histoire avec « La création de la distribution, 2e partie et 3e partie ».
• Visitez le site web Gentoo Linux pour plus d'informations sur la distribution.
• Apprenez-en plus sur le système d'ebuild de Gentoo Linux dans cet article de Daniel, Bash par l'exemple, 3e partie.

À propos de l'auteur

Daniel Robbins vit à Albuquerque au Nouveau Mexique. Il a été le président de Gentoo Technologies Inc., l'architecte en chef du projet Gentoo et il est un auteur ayant contribué à plusieurs livres publiés par MacMillan : « Caldera OpenLinux Unleashed », « SuSE Linux Unleashed » et « Samba Unleashed ». Daniel s'est intéressé aux ordinateurs suivant une certaine mode vers l'âge de 7 ans (« second grade ») quand il a été exposé au langage de programmation Logo et à une dose potentiellement mortelle de « Pac Man ». Cela explique probablement pourquoi il a depuis servi d'artiste graphique à « SONY Electronic Publishing ». Daniel aime passer le temps avec son épouse Mary et sa nouvelle fille Hadassah. Vous pouvez contacter Daniel en écrivant à drobbins@gentoo.org