- Processus de développement de Linux
-
Linux a apporté un changement radical dans la façon dont les systèmes d'exploitation sont développés, en construisant une communauté de développement autour d'Internet.
Ce développement en communauté sur Internet possède les caractéristiques suivantes qui sont détaillées dans la suite de cet article :
- Le processus de développement est public sur Internet : le code source est librement accessible; les modifications des sources sont publiées sur Internet et revues par la communauté avant d'être incluses dans la branche principale.
- Le cycle de développement est rapide et incrémental : le cycle pour la fourniture de nouvelles versions est de l'ordre de deux mois aujourd'hui contre plusieurs années pour les systèmes d'exploitation propriétaires concurrents. Ce cycle incrémental rapide permet d'obtenir plus rapidement des retours des utilisateurs et ainsi de mieux maîtriser la complexité inhérente au développement d'un système d'exploitation moderne.
- Cette méthode de développement a généré son propre outil de gestion de versions (Git) adapté à un développement décentralisé.
Ce cycle rapide n'est pas adapté à la majorité des usages industriels ou personnels. Interviennent alors les distributions Linux dont le principal rôle est d'apporter la stabilité en fournissant des versions de Linux à un rythme plus lent et en maintenant ces versions sur plusieurs années.
Sommaire
Un processus de développement public sur Internet
Greg Kroah-Hartman a expliqué pour Groklaw[1] le processus de développement de Linux. Greg Kroah-Hartman écrit des pilotes Linux depuis 1999, et est actuellement le mainteneur de certains sous-systèmes du noyau (USB, driver core, sysfs, linux-hotplug, udev, etc.).
Le concept de patch
Pour comprendre comment ce processus fonctionne, il faut d'abord comprendre ce qu'est un "patch" (ou "rustine" en français). Pour faire accepter une modification dans le noyau, les développeurs doivent produire un "patch" et l'envoyer au mainteneur du code qu'ils souhaitent modifier. Pour cela, ils effectuent leurs changements dans le code source du noyau, puis lancent un outil appelé 'diff'. Cet outil génère un fichier en format texte (le fichier patch) qui liste les lignes modifiées dans leur état d'avant et après modification, comme le montre l'exemple ci-dessous :
--- a/drivers/usb/image/microtek.c +++ b/drivers/usb/image/microtek.c @@ -335,7 +335,7 @@ static int mts_scsi_abort (Scsi_Cmnd *sr mts_urb_abort(desc); - return FAILURE; + return FAILED; } static int mts_scsi_host_reset (Scsi_Cmnd *srb)L'exemple montre que le fichier 'drivers/usb/image/microtek.c' a une ligne qui était avant changement :
return FAILURE;
et est maintenant après changement :
return FAILED;
Ce fichier texte peut être envoyé par courriel à d'autres personnes, qui peuvent voir immédiatement les lignes de code qui ont été changées et donner leur avis sur cette modification. Pour appliquer le patch, il suffit ensuite de lancer un autre programme appelé 'patch' en lui passant le fichier de patch.
La totalité du développement du noyau Linux est effectuée en envoyant publiquement des patchs par courrier électronique. En jetant un coup d'oeil à la liste de diffusion principale du développement du noyau (par exemple à http://marc.theaimsgroup.com/?l=linux-kernel), on peut voir des centaines de ces patchs envoyés à la ronde, discutés, critiqués.
La chaîne de production et de traitement des patchs
L'équipe de développement du noyau est un groupe de personnes qui se sont structurés en une pseudo-pyramide. A la base de la pyramide se trouvent les centaines de développeurs qui écrivent entre 1 et quelques milliers de patchs. Ces développeurs envoient leurs patchs au mainteneur du fichier ou groupe de fichiers qu'ils ont modifiés. La liste des mainteneurs est conservée dans le fichier MAINTAINERS qui se trouve dans les sources de la branche de développement principale du noyau. Il y a actuellement environ 300 mainteneurs différents.
Si le mainteneur estime que la modification est justifiée et l'approuve, il l'envoie alors au mainteneur du sous-système du noyau concerné. Il y a des mainteneurs pour presque tous les sous-systèmes du noyau (réseau, pilotes USB, Virtual File System, module core, driver core, pilotes Firewire, pilotes réseau, etc.) Ces personnes sont également listées dans le fichier MAINTAINERS et tous les mainteneurs de fichiers individuels ou de pilotes savent à qui adresser leurs modifications.
Les mainteneurs de sous-système envoient ensuite les patchs qu'ils ont approuvés à Linus Torvalds ou Andrew Morton et c'est alors que le patch est inclus dans la branche de développement principale du noyau.
Il faut noter que chaque personne qui touche un patch le long de cette chaîne de transmission ajoute au code une ligne "Signed-off-by:" qui montre exactement qui est à l'origine de la modification et par qui elle a été approuvée. En cas de bogue, les personnes à blâmer sont immédiatement identifiables.
La publication des patchs sur les listes de diffusion
Tous les développements sont faits par courrier électronique. Les développeurs envoient les patchs par courriel aux autres développeurs sur les différentes listes de diffusion. Il existe une liste principale 'linux-kernel'. Cette liste reçoit environ 200-300 messages par jour et presque tous les aspects du noyau y sont discutés. En raison de son fort trafic, toutes les sous-sections du noyau ont établi leurs propres listes de diffusion, pour travailler ensemble dans un domaine spécifique.
Les messages postés sur ces listes de diffusion sont archivés sur des sites spécialisés, par exemple http://marc.theaimsgroup.com et http://www.gmane.org, qui permettent la consultation et la recherche des messages diffusés dans le passé.
Ainsi un patch est posté sur une liste de diffusion. D'autres développeurs en font la revue, offrent des suggestions avec copie sur la liste pour informer tout le monde. Finalement un consensus est trouvé et le patch est accepté par le mainteneur pour le transmettre plus haut dans la chaîne.
Pour illustrer ce fonctionnement, prenons l'exemple d'Arjan Van de Ven, un développeur du noyau Linux, et son projet Fastboot de réduire le temps de démarrage d'un système GNU/Linux.
Ayant réfléchi à tout ce qui pouvait être facteur de ralentissement au démarrage du noyau, Arjan a proposé une solution sous forme d'un ensemble de 3 patchs. Ces patchs peuvent être vus ici :
patch 0/3: fastboot patches series 1 patch 1/3: fastboot: Create a "asynchronous" initlevel patch 2/3: fastboot: turn the USB hostcontroller initcalls into async initcalls patch 3/3: fastboot: convert a few non-critical ACPI drivers to async initcalls
Un certain nombre de développeurs sont intervenus, le fil de discussion peut être suivi ici :
http://thread.gmane.org/gmane.linux.kernel/709026/focus=709139
Et puis Linus Torvalds est intervenu et a estimé que la solution n'était pas satisfaisante car pas au bon niveau de granularité :
http://article.gmane.org/gmane.linux.kernel/743021/
L'auteur original a pris en compte les remarques de Linus et fait une nouvelle proposition avec la série de patchs suivants :
http://article.gmane.org/gmane.linux.acpi.devel/36513
qui ont été de nouveau commentés, et le développement a continué.
Comme le montre l'exemple ci-dessus, tout le développement du noyau est public, visible par tous, archivé en public de nouveau pour tous. Cette revue publique des modifications de code du noyau Linux par de multiples paires d'yeux est un élément essentiel car elle permet d'inscrire la qualité dans le processus de développement.
Un cycle de développement rapide et incrémental
Publier tôt, publier souvent est une règle fondamentale pour le développement des logiciels libres.
Au début du développement de Linux (vers 1991), il n'était pas rare que Linus Torvalds publie une nouvelle version du noyau Linux plusieurs fois par jour! Avec ce modèle de développement, Linus impliquait ses utilisateurs dans le processus de développement d'une façon très efficace. Et cette manière de cultiver sa communauté de co-développeurs et d'utiliser Internet comme outil de collaboration comme personne d'autre ne l'a fait avant lui ont été des facteurs-clés dans le succès de Linux.
Le cycle de développement
Depuis ce tout début, ce cycle de développement s'est un peu ralenti, cependant le noyau Linux continue à évoluer à un rythme très rapide comparé aux logiciels à source fermé (Windows XP en 2001, Windows Vista en 2007) : une version 2.6.x toutes les 8 à 12 semaines comme indiqué dans le tableau ci-dessous :
Version du noyau 2.6.0 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 Date de sortie 18 décembre 2003 9 janvier 2004 4 février 2004 18 février 2004 11 mars 2004 4 avril 2004 Version du noyau 2.6.6 2.6.7 2.6.8 2.6.9 2.6.10 2.6.11 Date de sortie 10 mai 2004 16 juin 2004 14 août 2004 18 octobre 2004 24 décembre 2004 2 mars 2005 Version du noyau 2.6.12 2.6.13 2.6.14 2.6.15 2.6.16 2.6.17 Date de sortie 17 juin 2005 29 août 2005 28 octobre 2005 3 janvier 2006 20 mars 2006 18 juin 2006 Version du noyau 2.6.18 2.6.19 2.6.20 2.6.21 2.6.22 2.6.23 Date de sortie 20 septembre 2006 29 novembre 2006 4 février 2007 25 avril 2007 8 juillet 2007 9 octobre 2007 Version du noyau 2.6.24 2.6.25 2.6.26 2.6.27 2.6.28 2.6.29 Date de sortie 24 janvier 2008 17 avril 2008 13 juillet 2008 9 octobre 2008 24 décembre 2008 23 mars 2009 Version du noyau 2.6.30 2.6.31 2.6.32 2.6.33 2.6.34 2.6.35 Date de sortie 9 juin 2009 9 septembre 2009 3 décembre 2009 24 février 2010 16 mai 2010 3 août 2010 Les différentes branches de développement
Aujourd'hui le développement du noyau Linux est effectué dans plusieurs branches :
- la branche principale (nommée aussi "2.6.x kernel tree" ou "Linus tree")
- la branche stable (appelée aussi "2.6.x.y stable tree")
- les versions quotidiennes ("git daily snapshots")
- les patchs expérimentaux d'Andrew Morton
- les patchs et versions spécifiques de sous-systèmes du noyau
La gestion de versions du noyau
Jusqu'en avril 2005, l'équipe de développement du noyau utilisait un logiciel commercial BitKeeper pour la gestion des versions des sources du noyau. Le 5 avril 2005, la société BitMover annonça qu'elle se concentrait exclusivement sur son offre commerciale BitKeeper et qu'elle retirait le client gratuit (mais non libre) utilisé par un certain nombre de développeurs libres.
Cet événement a conduit les développeurs du noyau Linux à inventer leur propre outil de gestion de versions qui a été appelé Git.
Les distributions Linux
Pour appréhender le rôle des distributions de Linux il est important d'avoir quelques notions sur le périmètre de Linux et sa modularité.
Le périmètre de Linux : le noyau, la branche du noyau et les distributions Linux
Le périmètre de Linux est souvent mal compris car le même terme "Linux" est utilisé pour le noyau Linux (le "kernel" lui-même), la branche du noyau ("kernel tree") et les distributions de Linux, qui ont chacun un périmètre de plus en plus grand comme le montre la figure ci-dessous. Une distribution Linux est un assemblage de milliers de paquets logiciels et de la branche du noyau, comprenant elle-même le noyau, les pilotes et les composants réseau et systèmes de fichier.
La modularité de Linux
Si la philosophie Unix, qui sous-tend également celle de Linux, devait être résumée en un seul mot, ce mot serait probablement celui de "modularité". Unix a été développé à l'origine avec l'objectif d'être hautement modulaire pour être plus flexible et convivial que les systèmes d'exploitation monolithiques et complexes de l'époque. Cette modularité a perduré et a été constamment retravaillée au cours des quelque 35 ans d'existence de systèmes d'exploitation de type Unix; elle a constitué un facteur majeur de leur remarquable durée de vie et constante popularité malgré leur âge (qui est important suivant les standards de l'informatique).
Linux est un système d'exploitation très modulaire. L'utilisateur peut installer seulement les parties qui lui conviennent. Dans la plupart des cas il choisira les installations par défaut proposées dans les menus d'installation, mais il n'y est pas obligé. S'il installe par exemple un serveur, il est possible de désactiver l'interface graphique de façon à libérer la mémoire et le processeur pour d'autres tâches.
La modularité commence avec le noyau. Même quand les utilisateurs ne compilent pas leur propre noyau, la présence de l'amorceur système (qui peut être lui-même GRUB ou LILO) est un rappel qu'ils ne sont pas limités à un seul noyau installé. Quand les utilisateurs compilent leur propre noyau, ils apprennent que son contenu est configurable et que de nombreux pilotes peuvent être chargés comme modules par le système quand ils sont requis plutôt que d'être compilés dans le noyau.
La même modularité se retrouve au niveau des sous-systèmes. Le noyau fonctionne avec plus de 30 systèmes différents de gestion de fichiers. La gestion de paquets logiciels a deux principaux formats, RPM et Debian, ainsi que plusieurs plus récents tels que Portage de la distribution Gentoo. D'autres systèmes alternatifs sont encore en développement.
Les sous-systèmes continuent à évoluer. Prenons l'exemple de lpd, le système d'impression d'origine, venant de l'Unix de Berkeley. Il a été étendu au fil des années par LPRng, puis remplacé par CUPS (Common UNIX Printing System). De façon identique, quand il y a quelques années XFree86 est devenu inacceptable à cause d'un changement dans sa licence qui le rendait non libre, X.org un "fork" d'une version précédente de XFree86 l'a remplacé. Plus récemment ALSA (Advanced Linux Sound Architecture) est venu se substituer à OSS (Open Sound System) dans de nombreuses distributions.
L'histoire se répète dans l'interface utilisateur. Le shell par défaut dans la plupart des distributions est GNU bash, qui a évolué au fil des ans. Cependant il existe plus d'une demi-douzaine de substituts possibles, citons tcsh, csh, pdksh, zsh et BusyBox.
Il existe la même diversité pour l'environnement de bureau. KDE et Gnome sont les environnements les plus communs, mais certains utilisateurs qui privilégient la performance sur la simplicité d'utilisation adopteront par exemple IceWM en lieu et place de KDE ou Gnome. En ce qui concerne le gestionnaire de fenêtres, KDE a choisi KWM alors que Gnome a élu Metacity mais ces gestionnaires par défaut peuvent être remplacés par des douzaines d'alternatives.
Cette modularité permet aussi de mettre à jour certaines parties du système sans affecter le reste du système. Par exemple il est possible d'installer la dernière version de Gnome ou KDE sans changer de version du noyau.
Le rôle des distributions de Linux
Cette liberté de choix n'est pas forcément adaptée à tous les utilisateurs. C'est là qu'entrent en jeu les distributions de Linux.
Comme le notait Ian Murdock, le fondateur de la distribution Debian, dans un manifeste en 1993 :
- Les distributions sont essentielles pour le futur de Linux. Elles dispensent l'utilisateur d'avoir à localiser, télécharger, compiler et installer et elles intègrent un nombre tout à fait considérable d'outils essentiels pour assembler un système Linux qui fonctionne. La charge de construction du système est placée sur les épaules du créateur de la distribution et son travail peut être partagé avec des milliers d'autres utilisateurs. Presque tous les utilisateurs de Linux vont faire leurs premières armes avec une distribution et la plupart d'entre eux vont continuer à utiliser une distribution par souci de facilité même après s'être familiarisés avec le système.
Les distributions Linux ont effectivement un rôle important dans l'éco-système construit autour de Linux.
Elles rassemblent les meilleurs paquets logiciels (par exemple la distribution Debian inclut plus de 10.000 paquets logiciels) dans une offre intégrée et adaptée à leurs utilisateurs ou clients.
De plus, peu de personnes et encore moins de sociétés peuvent se permettre de suivre le cycle rapide de 8-12 semaines de sortie des versions du noyau. Les distributions fournissent un cycle plus adapté à leurs besoins. La fréquence de sortie de nouvelles versions est laissé à l'appréciation de chaque distribution, il peut aller de 6 mois pour les distributions les plus en pointe (par exemple Fedora, Ubuntu) à 12-18 mois pour les distributions plus commerciales (Red Hat, SuSE) et même 2-3 ans pour la distribution Debian.
Le cycle de développement de quelques distributions Linux
Le cycle de développement de la distribution Red Hat
Le cycle de développement de la distribution Debian
Notes et références
Voir aussi
Liens internes
Wikimedia Foundation. 2010.
