De la mise sous tension à l'invite de commande de Bash

1. Introduction

Je trouve frustrant qu'il se passe dans ma machine Linux des choses que je ne comprends pas. Si, comme moi, vous souhaitez vraiment comprendre votre système plutôt que simplement savoir comment l'utiliser, ce document devrait être un bon point de départ. Ce genre de connaissance de fond est aussi requis si vous voulez devenir un as de la résolution de problèmes sous Linux.

Je pars du principe que vous avez une machine Linux en état de marche, et que vous maîtrisez les bases d'Unix et de l'architecture matérielle des PC. Si ce n'est pas le cas, Les notions fondamentales d'Unix et d'Internet est un excellent endroit pour débuter. C'est un document concis, lisible, et qui couvre toutes les bases.

Le sujet principal de ce document est la façon dont Linux démarre. Mais il se veut également être une ressource d'apprentissage plus large. J'ai inclus des exercices dans chaque section. Si vous en faites vraiment quelques-uns, vous en apprendrez bien plus qu'en vous contentant de lire ce document.

J'espère que certains lecteurs s'attaqueront au meilleur exercice d'apprentissage de Linux que je connaisse : construire un système à partir du code source. Giambattista Vico, un philosophe italien (1668-1744) disait verum ipsum factum ce qui signifie « de l'expérience naît la compréhension » (NdT : traduction libre). Merci à Alex (voir références et remerciements) pour cette citation.

Si vous souhaitez vous réaliser votre propre installation Linux, je vous conseille d'aller voir le document de Gerard Beekmans Comment faire un système Linux à partir de zéro (Linux from scratch - LFS). LFS fournit des instructions détaillées pour bâtir un système complet et exploitable à partir du code source. Sur le site web de LFS, vous trouverez aussi une liste de discussion à la disposition des personnes qui construisent de tels systèmes. Les instructions jadis incluses à ce guide se trouvent maintenant dans un document distinct nommé « Construire un système Linux minimum à partir du code source » et qui peut être récupéré sur le site From PowerUp to Bash Prompt pour construire un système jouet, purement pour l'exercice.

Les paquets sont présentés dans l'ordre où ils apparaissent dans le processus de démarrage du système. Cela signifie que si vous installez les paquets dans cet ordre vous pouvez redémarrer après chaque installation, et voir à chaque fois le système se rapprocher petit à petit de l'état où il vous donnera la ligne de commande. Il y a une notion de progression rassurante dans cela.

Je vous recommande de commencer par lire le texte principal de chaque section, en ignorant les exercices et références, puis de décider du point jusqu'auquel vous souhaitez comprendre votre système. Reprenez alors depuis le début, en faisant les exercices et en relisant en détail.

2. Partie matérielle

Lorsque vous allumez votre ordinateur, celui-ci se teste lui-même pour s'assurer que tous ses composants sont en état de marche. Cela s'appelle l'auto-test à l'allumage (Power On Self Test - POST). Ensuite, un programme nommé chargeur d'amorçage (bootstrap loader), situé dans le BIOS en ROM, recherche un secteur d'amorçage. Un secteur d'amorçage est le premier secteur d'un disque et contient un petit programme capable de charger un système d'exploitation. Les secteurs d'amorçage sont marqués par un nombre magique (i.e. une valeur fixe caractéristique) 0xAA55 = 43603 à l'octet 0x1FE = 510. Ce sont les deux derniers octets du secteur. C'est de cette façon que la partie matérielle peut déterminer s'il s'agit d'un secteur d'amorçage ou pas.

Le chargeur d'amorçage a une liste d'endroits où chercher un secteur d'amorçage. Ma vieille machine regarde d'abord sur le lecteur de disquette, puis sur le disque dur. Les machines modernes peuvent aussi rechercher un secteur d'amorçage sur un CD-ROM. S'il trouve un secteur d'amorçage, il le charge en mémoire et passe ainsi le contrôle au programme qui charge le système d'exploitation en mémoire. Sur un système Linux classique, ce programme sera la première étape du chargeur de Lilo. Il existe malgré tout plusieurs manières différentes de configurer l'amorçage de votre système. Voir le Guide de l'utilisateur de Lilo pour plus de détails. Voir la section liens sur Lilo pour l'url.

Évidement, il y a bien plus à dire sur ce que fait la partie matérielle du PC. Mais ce n'est pas l'objet de ce document. Lisez un des nombreux livres traitant de l'architecture matérielle des PC.

3. Lilo

Lorsque l'ordinateur charge le secteur d'amorce d'un système sous Linux normal, ce qu'il charge est en fait une partie de Lilo, appelée chargeur d'amorçage de premier niveau (first stage boot loader). Il s'agit d'un mini-programme dont la seule tâche est de charger et d'exécuter le chargeur d'amorçage de deuxième niveau (second stage boot loader).

Le chargeur d'amorçage de deuxième niveau vous donne une invite de commande (s'il a été installé de cette manière) et charge le système d'exploitation de votre choix.

Lorsque votre système est monté et en état de marche, et que vous exécutez lilo, ce que vous exécutez en réalité est l'outil de définition des localisations (map installer). Celui-ci lit le fichier de configuration /etc/lilo.conf et écrit le chargeur d'amorçage sur le disque dur, avec les informations concernant les systèmes d'exploitation qu'il peut charger.

Il y a de nombreuses manières de rendre votre système amorçable. Celle que je viens de décrire est la manière la plus évidente et « normale », au moins pour une machine dont le système d'exploitation principal est Linux. Le Guide de l'utilisateur Lilo explique plusieurs exemples de méthodes d'amorçage. Cela vaut la peine de les lire, et d'en essayer quelques-uns.

4. Le noyau Linux

Le noyau (kernel) fait vraiment beaucoup de choses. Je pense qu'une bonne manière de résumer tout cela est de dire qu'il fait faire au matériel ce que les programmes veulent, proprement et efficacement.

Le processeur ne peut exécuter qu'une seule instruction à la fois, mais Linux semble faire tourner beaucoup de choses simultanément. Le noyau accomplit cela en sautant de tâche en tâche très rapidement. Il fait le meilleur usage possible du processeur en gardant trace des processus qui sont prêts à être exécutés et de ceux qui attendent quelque chose comme un enregistrement en provenance d'un disque, ou une saisie clavier quelconque. Cette tâche du noyau est appelée ordonnancement.

Si un programme ne fait rien, alors il n'a pas besoin d'être conservé en mémoire (RAM). Même un programme qui travaille peut avoir certaines parties inactives, qui n'ont donc pas besoin d'être en mémoire. L'espace adressable est divisé en pages. Le noyau garde une trace des pages les plus utilisées. Les pages qui sont moins souvent utilisées peuvent être déplacées dans la partition d'échange (swap). Lorsqu'une page est à nouveau sollicitée, une autre page inutilisée est retirée de l'espace adressable pour lui faire de la place. Cela s'appelle la gestion de la mémoire virtuelle.

Si vous avez un jour compilé votre propre noyau, vous avez remarqué qu'il y a un grand nombre d'options pour des périphériques spécifiques. Le noyau contient une grande quantité de code spécifique pour interagir avec tous types de matériels, et pouvoir les présenter d'une façon propre et uniforme aux programmes.

Le noyau prend aussi en charge la gestion des fichiers, les communications entre processus, et une grande partie du travail concernant le réseau.

Une fois le noyau chargé, la première chose qu'il fait est de rechercher un programme appelé init et l'exécuter.

---

4.1. Configuration

La majorité de la configuration du noyau est effectuée quand vous le construisez, en utilisant make menuconfig, ou make xconfig dans le répertoire /usr/src/linux/ (là ou se trouvent les sources de votre noyau Linux). La commande rdev vous permet réinitialiser le mode vidéo par défaut, la racine du système de fichiers, le périphérique d'échange et la taille du disque virtuel (disque RAM). Ces paramètres ainsi que d'autres peuvent aussi être passés au noyau depuis Lilo. Vous pouvez indiquer à Lilo les paramètres à passer au noyau soit dans lilo.conf, soit à l'invite de Lilo. Par exemple, si vous souhaitiez utiliser hda3 comme racine du système de fichiers plutôt que hda2, vous pourriez taper :

LILO: linux root=/dev/hda3

Si vous mettez en place un système à partir de ses sources, vous pouvez vous simplifier la vie en créant un noyau « monolithique », c'est-à-dire sans module. Vous n'aurez donc pas à copier ceux-ci sur le système cible.

Le fichier System.map est utilisé lors de l'écriture d'entrées dans le journal système pour déterminer les noms des modules générant les messages. Le programme top utilise également ces informations. Lorsque vous copiez le noyau vers un système cible, copiez aussi System.map.

5. La bibliothèque C de GNU

L'étape suivante qui se produit au démarrage de votre ordinateur est le chargement d'init et son exécution. Cependant, init, comme la plupart des programmes, utilise des fonctions issues de bibliothèques.

Vous avez peut-être déjà vu un exemple de programme C comme celui-ci :

	main() {
        	printf("Hello World!\n");
	}

Le programme ne définit nullement printf, alors d'où vient-il ? Il provient des bibliothèques C standard. Pour un système GNU/Linux, il s'agit de glibc. Si vous les compilez sous Visual C++, alors il provient d'une mise en œuvre Microsoft de ces mêmes fonctions standard. Il existe des masses de ces fonctions standard, pour les mathématiques, la gestion des chaînes de caractères, de l'heure et de la date, des allocations de mémoire et ainsi de suite. Tout, dans Unix (y compris Linux) est soit écrit en C, soit doit faire de son mieux pour faire comme si, de sorte que tous les programmes utilisent ces fonctions.

Si vous jetez un œil dans /lib sur votre système Linux, vous verrez un grand nombre de fichiers appelés libquelquechose.so ou libquelquechose.a et cætera. Ce sont les bibliothèques de ces fonctions. Glibc est simplement la mise en œuvre GNU de ces fonctions.

Les programmes peuvent utiliser ces fonctions de deux manières. Si vous réalisez une édition de liens statique, ces fonctions seront copiées à l'intérieur de l'exécutable généré. C'est à cela que servent les bibliothèques libquelquechose.a. Si vous réalisez une édition de liens dynamique (cas par défaut), lorsque le programme aura besoin du code d'une bibliothèque, il l'appellera directement depuis le fichier libquelquechose.so

La commande ldd vous apporte une aide précieuse lorsque vous cherchez à retrouver les bibliothèques utilisées par un programme particulier. Par exemple, voici les bibliothèques utilisées par bash:

	[greg@Curry power2bash]$ ldd /bin/bash
        	libtermcap.so.2 => /lib/libtermcap.so.2 (0x40019000)
        	libc.so.6 => /lib/libc.so.6 (0x4001d000)
        	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

6. Init

Je ne parlerai que du style d'initialisation « System V » que les systèmes Linux utilisent le plus souvent. Il existe des alternatives. En fait, vous pouvez mettre n'importe quel programme dans /sbin/init, que le noyau exécutera lorsqu'il aura fini de se charger.

Le travail d'init est de faire en sorte que tout se lance correctement. Il vérifie que les systèmes de fichier sont en bon état et les monte. Il démarre les démons (daemons) qui enregistrent les messages système, gèrent le réseau, distribuent les pages web, écoutent les signaux de la souris, et cætera. Init démarre aussi les processus getty qui vous donnent l'invite de connexion sur vos terminaux virtuels.

Il y a un processus compliqué concernant le changement de niveau d'exécution (« run-levels »), mais je vais sauter tout ça, et ne parler que du démarrage du système.

Init lit le fichier /etc/inittab, qui lui dit quoi faire. En général, la première chose demandée est l'exécution d'un script d'initialisation. Le programme qui exécute (ou interprète) ce script est bash, le même programme qui vous donne la ligne de commande. Sur les systèmes Debian, le script d'initialisation est /etc/init.d/rcS, sur Red Hat, /etc/rc.d/rc.sysinit. C'est là que les systèmes de fichiers sont vérifiés puis montés, l'horloge mise à l'heure, le fichier ou la partition d'échange (swap) activés, les noms de machines définis, et cætera.

Ensuite, un autre script est invoqué pour nous placer dans le niveau d'exécution par défaut. Cela implique simplement le démarrage d'un ensemble de sous-systèmes. Il existe un ensemble de sous-répertoires /etc/rc.d/rc0.d, /etc/rc.d/rc1.d, … , /etc/rc.d/rc6.d sous Red Hat, ou /etc/rc0.d, /etc/rc1.d, … , /etc/rc6.d sous Debian, correspondant aux niveaux d'exécution (runlevels). Si nous entrons dans le niveau d'exécution 3 sur un système Debian, le script exécute tous les scripts de /etc/rc3.d commençant par « S » (pour Start). Ces scripts sont en réalité des liens vers un autre répertoire appelé généralement init.d.

Donc, le script de notre niveau d'exécution est appelé par init, et recherche dans un répertoire les scripts dont le nom débute par la lettre « S ». Il se peut qu'il tombe sur S10syslog en premier. Les chiffres indiquent au script de gestion des niveaux d'exécution l'ordre dans lequel il doit les lancer. En l'occurrence, S10syslog est lancé en premier parce qu'il n'y pas de script commençant par S00 … S09. Mais S10syslog est en fait un lien vers /etc/init.d/syslog qui est un script chargé du démarrage et de l'arrêt du démon de gestion du journal système. Parce que le nom du lien commence par un « S », le script de gestion des niveaux d'exécution sait qu'il doit exécuter le script syslog avec le paramètre start. Il y a aussi des liens dont le nom débute par « K » (pour Kill), qui spécifient ce qui doit être arrêter, et dans quel ordre, lorsque l'on entre dans ce niveau d'exécution.

Pour changer ce que le sous-système lance par défaut, vous devez configurer ces liens dans le répertoire rcN.d, où N est le niveau d'exécution par défaut défini dans votre fichier inittab.

La dernière chose importante qu'effectue init est de démarrer les getty. Ceux-ci sont ressuscités (respawned), ce qui signifie qu'ils sont automatiquement relancés par init s'ils viennent à se terminer. La plupart des distributions fournissent six terminaux virtuels. Il se peut que vous souhaitiez en enlever pour économiser de la mémoire, ou en ajouter pour pouvoir faire tourner plus de choses à la fois, et passer rapidement de l'une à l'autre. Vous pourriez aussi avoir besoin de lancer un getty vers un terminal texte ou vers un modem. Vous devrez alors éditer inittab.

	echo "Bonjour, moi c'est rc.sysinit"

7. Le système de fichiers

Dans cette section, j'emploierai l'expression « système de fichiers » pour deux notions différentes. Il y a les systèmes de fichiers installés sur des partitions de disque ou d'autres périphériques, et il y a le système de fichier tel qu'il vous est présenté par un système Linux en état de marche. Sous Linux, vous « montez » le système de fichiers d'un disque sur le système de fichiers de Linux.

Dans la section précédente, j'ai mentionné le fait que des scripts d'initialisation vérifiaient et montaient les systèmes de fichiers. Les commandes qui effectuent ces opérations sont respectivement fsck et mount.

Un disque dur n'est qu'un grand espace dans lequel vous pouvez écrire des zéros et des uns. Un système de fichiers impose une structure à tout cela, et le présente sous la forme de fichiers, à l'intérieur de sous-répertoires, à l'intérieur de répertoires … Chaque fichier est représenté par un inode, indiquant le fichier dont il s'agit, sa date de création, et où trouver son contenu. Les répertoires sont aussi représentés par des inodes, mais ceux-ci indiquent où trouver les inodes des fichiers que les répertoires contiennent. Si le système veut lire /home/greg/groslolos.jpeg, il commence par lire l'inode du répertoire racine / dans le « superbloc », puis trouve l'inode du répertoire home dans le contenu de /, puis trouve l'inode du répertoire greg dans le contenu de home, et enfin l'inode de groslolos.jpeg qui lui dira quels blocs du disque il doit lire.

Si nous ajoutons des données à la fin d'un fichier, il peut arriver que les données soient écrites avant que l'inode ne soit mis à jour (indiquant que le nouveau bloc appartient désormais au fichier), ou vice-versa. Si le courant est coupé à cet instant précis, le système de fichiers sera cassé. C'est ce genre de chose que fsck essaie de détecter et de réparer.

La commande mount prend le système de fichiers d'un périphérique, et l'ajoute à la hiérarchie de fichiers de votre système. En général le noyau monte son système de fichiers racine en lecture seule. La commande mount est ensuite utilisée pour le remonter en lecture-écriture après que fsck aie vérifié que tout est en ordre.

Linux prend aussi en charge d'autres types de systèmes de fichiers : msdos, vfat, minix, et cætera. Les détails d'un système de fichiers spécifique sont masqués par le système de fichier virtuel (Virtual File System - VFS), qui est une couche d'abstraction. Je ne rentrerai pas dans ces détails. Il existe une discussion sur ce sujet dans « Le noyau Linux » (voir la section aller plus loin - le noyau Linux pour l'url).

Un type de système de fichiers complètement différent est monté sur /proc. C'est une véritable projection de ce qui se passe dans le noyau. On y trouve un répertoire pour chaque processus existant sur le système, dont le nom correspond au numéro dudit processus. Il existe aussi des fichiers comme interrupts et meminfo qui donnent des informations sur l'utilisation du matériel. Vous pouvez découvrir énormément de choses en explorant /proc.

8. Les démons du noyau

Si vous saisissez la commande ps aux, vous verrez quelque chose ressemblant à ce qui suit :

USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
root         1  0.1  8.0  1284   536   ? S    07:37   0:04 init [2] 
root         2  0.0  0.0     0     0   ? SW   07:37   0:00 (kflushd)
root         3  0.0  0.0     0     0   ? SW   07:37   0:00 (kupdate)
root         4  0.0  0.0     0     0   ? SW   07:37   0:00 (kpiod)
root         5  0.0  0.0     0     0   ? SW   07:37   0:00 (kswapd)
root        52  0.0 10.7  1552   716   ? S    07:38   0:01 syslogd -m 0 
root        54  0.0  7.1  1276   480   ? S    07:38   0:00 klogd 
root        56  0.3 17.3  2232  1156   1 S    07:38   0:13 -bash 
root        57  0.0  7.1  1272   480   2 S    07:38   0:01 /sbin/agetty 38400 tt
root        64  0.1  7.2  1272   484  S1 S    08:16   0:01 /sbin/agetty -L ttyS1
root        70  0.0 10.6  1472   708   1 R   Sep 11   0:01 ps aux 

C'est une liste de processus en cours d'exécution sur le système. Les informations proviennent du système de fichiers /proc que j'ai mentionné dans la section précédente. Remarquez que init est le processus numéro un. Les processus 2, 3, 4 et 5 sont kflushd, kupdate, kpiod et kswapd. Il y a quand même quelque chose d'étrange : dans les deux colonnes de la taille virtuelle de stockage (SIZE) et la taille réelle de stockage (Real Storage Size, RSS), ces processus renvoient zéro. Comment un processus peut-il ne pas utiliser de mémoire ?

Il s'agit des démons propres au noyau. La majeure partie du noyau n'apparaît même pas dans la liste des processus, et le seul moyen de connaître la mémoire qu'il utilise est de soustraire la mémoire disponible à la quantité totale de mémoire installée. Les démons du noyau sont démarrés après init, et obtiennent de ce fait des numéros de processus normaux, mais leur code et leurs données n'existent qu'au sein de la zone de mémoire occupée par le noyau.

Les noms des démons du noyau dans la liste sont écrits entre crochets car le système de fichiers /proc ne contient pas d'information sur la ligne de commande utilisée pour lancer ces processus.

Alors, à quoi servent ces démons ? Les versions précédentes de ce document présentaient ici un appel à contribution, car mes connaissances dans ce domaine sont limitées. L'explication (partielle) qui suit est une fusion de différentes réponses à cet appel, pour lesquelles j'ai une grande reconnaissance. Toutes indications, références et corrections sont bienvenues.

Toutes les entrées et sorties sont effectuées via des tampons en mémoire, ce qui accélère grandement les choses. Tout ce qu'un programme écrit peut être conservé en mémoire, puis être écrit sur le disque par blocs plus grands et plus efficaces. C'est le travail des démons kflushd et kupdate.

Très souvent, les processus sont au repos, et ceux qui tournent n'ont pas besoin d'avoir l'intégralité de leur code et de leurs données chargée en mémoire. Cela signifie que l'on peut faire un meilleur usage de notre mémoire vive, en faisait glisser les pages inutilisées des programmes en cours d'exécution vers la ou les partitions d'échange du disque dur. Le transfert des données depuis et vers la mémoire selon les besoins est assuré par kpiod et kswapd. Toutes les secondes environ, kswapd se réveille et vérifie la situation de la mémoire, et, si une page devient nécessaire en mémoire ou que l'on commence à manquer de place, invoque kpiod.

Il peut aussi exister un démon kapmd si vous avez activé la gestion avancée de l'énergie (apm) dans votre noyau.

9. Le journal système

Init démarre les démons syslogd et klogd. Ils écrivent les messages à consigner dans le journal système. Les messages du noyau sont pris en main par klogd, alors que syslogd gère les messages des autres processus. Le fichier journal principal est /var/log/messages. C'est un bon endroit où aller voir quand quelque chose tourne mal sur votre système. Vous y trouverez souvent de précieux indices.

---

9.1. Configuration

Le fichier /etc/syslog.conf indique au démon de gestion du journal système où mettre quels messages. Les messages sont identifiés par le service dont ils proviennent, et leur niveau de priorité. Ce fichier de configuration est constitué de lignes indiquant que les messages du service x avec une priorité y vont vers z, où z est un fichier, un terminal, une imprimante, une machine distante, ou autre chose encore.

Syslog a besoin que le fichier /etc/services existe. Ce fichier alloue des ports (UDP et TCP). Je ne sais pas vraiment si syslog a besoin d'un port réservé uniquement pour pouvoir enregistrer les messages des machines distantes, ou si même l'enregistrement en local se fait au travers d'un port, ou même s'il ne se contente pas d'utiliser /etc/services pour convertir les noms de services indiqués dans /etc/syslog.conf en numéros de port.

10. Getty et Login

Getty est le programme qui vous permet de vous connecter à travers un périphérique série, comme une console virtuelle, un terminal en mode texte, ou un modem. Il affiche l'invite de connexion. Une fois que vous avez saisi votre nom d'utilisateur, getty le transmet à login, qui vous demande un mot de passe, le vérifie, puis vous donne l'interpréteur de commandes (le shell).

Il existe plusieurs getty disponibles. Certaines distributions, comme Red Hat, en utilisent un très petit appelé mingetty et qui ne gère que les terminaux virtuels.

Le programme login fait partie du paquet util-linux, qui contient aussi un getty nommé agetty, qui fonctionne bien. Ce paquet contient également mkswap, fdisk, passwd, kill, setterm, mount, swapon, rdev, renice, more et bien d'autres.

11. Bash

Si vous donnez à login une combinaison valide de nom d'utilisateur et de mot de passe, il ira regarder dans /etc/passwd pour savoir quel interpréteur de commandes vous donner. La plupart du temps, dans un système Linux, ce sera bash. Le travail de bash consiste à lire vos commandes et voir ce sur quoi elles agissent. C'est à la fois une interface utilisateur, et l'interpréteur d'un langage de programmation.

Dans son rôle d'interface, il lit vos commandes, et les exécute lui-même si ces commandes sont internes, comme cd, ou bien trouve et exécute un programme s'il s'agit de commandes externes comme cp ou startx. Bash propose également plusieurs options fort sympathiques comme un historique des commandes, ou la capacité de finir automatiquement les noms de fichiers que vous entrez (lorsque vous utiliser la touche Tab).

Nous avons déjà vu bash à l'action dans son rôle de langage de programmation. Les scripts qu'init lance pour démarrer le système sont généralement des scripts shell, et sont exécutés par bash. Avoir un langage de programmation propre, parallèlement aux utilitaires systèmes disponibles depuis l'invite de commande forme une combinaison très puissante, si vous savez ce que vous faites. Par exemple (séquence frime !), j'ai eu besoin l'autre jour d'appliquer une pile entière de correctifs à un répertoire de codes source. J'ai été capable de le faire en une seule commande, la suivante :

for f in /home/greg/sh-utils-1.16*.patch; do patch -p0 < $f; done;

Ceci recherche tous les fichiers de mon répertoire personnel dont les noms commencent par sh-utils-1.16 et finissent par .patch, puis affecte un par un ces noms à la variable f et exécute les commandes invoquées entre do et done. Il y avait en l'occurrence 11 correctifs, mais il aurait pu aussi bien y en avoir 3000.

12. Les commandes

Vous effectuez la plupart des choses sous bash en saisissant des commandes comme cp. La majorité de ces commandes sont des petits programmes, bien que quelques-unes, comme cd soient intégrées à l'interpréteur de commandes.

Les commandes viennent de paquets, la plupart de la Free Software Foundation (projet GNU). Plutôt que de dresser ici la liste des paquets, je préfère vous renvoyer vers le Comment faire un système Linux à partir de zéro. Il contient une liste complète et à jour de tous les paquets allant dans un système Linux, aussi bien que des indications pour les construire.

13. Conclusion

L'un des meilleurs côtés de Linux, à mon humble avis, est que vous pouvez entrer dedans et voir réellement comment il fonctionne. J'espère que vous apprécierez cela autant que moi. Et j'espère que ces quelques notes vous y auront aidé.

14. Section administrative