docdemarrage

docs/ft-linux/references/README.md

@@ -0,0 +1,15 @@
+# Références liées par le sujet
+
+Le PDF pose cinq liens. Chacun pointe vers un ouvrage long, maintenu ailleurs, et protégé par son auteur. Ici, une fiche par lien : de quoi il s’agit, quels chapitres servent à ft_linux, et comment les lire. L’adresse officielle reste la source à jour.
+
+| Ancre dans le PDF | Ouvrage | Fiche locale | Noté ? |
+|-------------------|---------|--------------|--------|
+| `standards` | Filesystem Hierarchy Standard 3.0 | [fhs.md](fhs.md) | L’objectif « hiérarchie conforme » renvoie ici |
+| `The Bible` | Linux From Scratch, livre stable | [lfs.md](lfs.md) | C’est la méthode de construction |
+| `Autotools` | Manuel Automake | [autotools.md](autotools.md) | Outil de construction de la plupart des paquets |
+| `this` | POSIX, Single UNIX Specification | [posix.md](posix.md) | Le sujet dit de le lire. Il dit aussi qu’on n’est pas noté dessus |
+| `that` | Linux Standard Base | [lsb.md](lsb.md) | Même phrase : à lire, pas noté |
+
+Livre stable consulté pour ces fiches : LFS publié le 1er septembre 2025 (noyau 6.16.1, GCC 15.2.0, Glibc 2.42). Les numéros de version bougent à chaque édition du livre. Le sujet laisse les versions libres, avec un plancher : noyau >= 4.0.
+
+Le site `refspecs.linuxfoundation.org` (FHS et LSB) a répondu 403 au moment de cette rédaction. Les fiches FHS et LSB s’appuient sur le texte connu de FHS 3.0 et de LSB 5.0, et sur le chapitre « LFS and Standards » du livre stable, qui cite ces deux documents.

docs/ft-linux/references/autotools.md

@@ -0,0 +1,40 @@
+# Autotools — le lien Automake
+
+Adresse du PDF : <https://www.gnu.org/software/automake/manual/html_node/index.html#SEC_Contents>
+
+Le mot du sujet est `Autotools`. Le lien ouvre le manuel GNU Automake, un des outils de la famille, pas les quatre à la fois. Le manuel est sous licence GNU. On ne le recopie pas.
+
+## La famille, dans l’ordre où elle sert
+
+Presque chaque paquet de la liste se construit ainsi :
+
+```text
+./configure
+make
+make install
+```
+
+Derrière ces trois lignes, quatre outils. Le sujet les liste tous.
+
+| Outil | Rôle |
+|-------|------|
+| M4 | Langage de macros. Autoconf est écrit dedans. Sans M4, Autoconf ne tourne pas |
+| Autoconf | Lit `configure.ac` et produit le script `configure`. Ce script teste la machine : compilateur, en-têtes, bibliothèques |
+| Automake | Lit `Makefile.am` et produit `Makefile.in`. `configure` transforme `Makefile.in` en `Makefile` adapté à cette machine |
+| Libtool | Enveloppe la création de bibliothèques partagées (`.so`). Les règles diffèrent entre systèmes. Libtool masque ces différences |
+| Pkg-config (Pkgconf dans le LFS de 2025) | Pas un autotool, mais le voisin. Un paquet demande « où est installée la bibliothèque X ? » et obtient les flags de compilation |
+
+`make` exécute le `Makefile`. Ce n’est pas un autotool. C’est l’outil qui lance le compilateur selon les règles produites au-dessus.
+
+## Pourquoi l’ordre de LFS place ces paquets tard
+
+On peut compiler Binutils, GCC et Glibc sans avoir encore Automake : leurs archives contiennent déjà un `configure` généré par les auteurs. Automake et Autoconf servent le jour où l’on modifie un `Makefile.am`, ou quand un paquet plus haut dans le livre régénère ses scripts. Le livre les installe quand même, parce qu’un système où l’on construit des logiciels en a besoin. Le sujet les met dans la liste pour la même raison.
+
+## Ce qu’il suffit de reconnaître dans un chapitre LFS
+
+- `./configure --prefix=/usr` : installer sous `/usr`, pas sous `/usr/local`. LFS fixe le préfixe pour coller au FHS.
+- `--enable-...` et `--disable-...` : options du script produit par Autoconf. Chaque chapitre du livre dit lesquelles passer. On ne les invente pas.
+- `make` puis `make check` quand le livre le demande. Check, DejaGNU, Expect et Tcl existent pour ces tests. Un test qui échoue se lit. On ne « corrige » pas le paquet pour faire passer un test sans comprendre l’échec.
+- `make install` : copie le résultat dans la hiérarchie. Avant le `chroot`, le livre dirige souvent l’installation vers `$LFS/usr` pour ne pas écraser l’hôte.
+
+Le manuel Automake décrit le langage des `Makefile.am` (variables `bin_PROGRAMS`, `AM_CFLAGS`, etc.). On en a besoin le jour où un paquet ne fournit pas de `configure` prêt, ou pour lire un `Makefile.am` cassé. Pour suivre le livre chapitre par chapitre, les trois commandes ci-dessus suffisent, avec les options écrites dans le chapitre.

docs/ft-linux/references/fhs.md

@@ -0,0 +1,43 @@
+# FHS 3.0 — le mot `standards` du sujet
+
+Adresse du PDF : <http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html>
+
+Filesystem Hierarchy Standard, version 3.0, publié par le Linux Foundation. C’est une norme de rangement : quel répertoire existe, et quel genre de fichier a le droit d’y être. Elle ne dit pas comment compiler un paquet.
+
+Le sujet n’écrit pas « FHS ». Il écrit « a filesystem hierarchy compliant with the standards », et le mot `standards` est le lien vers ce document. LFS, de son côté, dit suivre FHS 3.0.
+
+## L’idée en une phrase
+
+Deux fichiers qui ont le même rôle sur deux distributions doivent avoir le même chemin. `/bin/sh` est un shell, `/etc` est de la configuration, `/boot` est ce que le bootloader lit. Un programme écrit pour une distribution en trouve un autre sans deviner.
+
+## Les répertoires que ft_linux va vraiment remplir
+
+| Chemin | Rôle dans la norme | Dans ce projet |
+|--------|--------------------|----------------|
+| `/` | Racine. Tout le reste est en dessous | Une partition dédiée. Le sujet l’appelle `root` |
+| `/boot` | Noyau et fichiers du bootloader | Une partition à part. Le fichier `vmlinuz-<linux_version>-<student_login>` vit ici, avec la config GRUB |
+| `/bin` | Commandes essentielles, utilisables même si `/usr` n’est pas monté | `sh`, `ls`, `mount`. LFS y place les outils dont le boot a besoin |
+| `/sbin` | Commandes d’administration essentielles | `init`, `shutdown`, `fsck`, souvent `ip` selon les versions |
+| `/lib` | Bibliothèques essentielles, et souvent les modules du noyau dans `/lib/modules/<version>` | Le chargeur de modules cherche les `.ko` ici |
+| `/etc` | Configuration propre à cette machine | `/etc/hostname` (le login), `/etc/fstab` (les partitions), `/etc/passwd`, scripts SysV |
+| `/dev` | Fichiers de périphériques | Créés au boot par udev / devtmpfs, pas copiés à la main. `/dev/sda`, `/dev/tty1` |
+| `/proc` | Fenêtre sur le noyau, en mémoire | `ps`, et plus tard `/proc/mymounts` de Little Penguin, lisent ici. Ce n’est pas un disque |
+| `/sys` | Fenêtre sur les périphériques et les modules | udev écoute ce que le noyau y publie |
+| `/tmp` | Fichiers temporaires, effaçables | Droit d’écriture pour tout le monde, souvent un `tmpfs` |
+| `/usr` | La partie partageable du système, programmes non essentiels au tout premier boot | `/usr/bin`, `/usr/lib`, `/usr/share` |
+| `/usr/src` | Sources | Le sujet y met le noyau : `/usr/src/kernel-$(version)`. La norme prévoit ce répertoire pour du code source |
+| `/usr/include` | En-têtes C | Vient de Glibc et des en-têtes du noyau. GCC les lit pour compiler |
+| `/var` | Données qui changent : journaux, caches, files | `syslog` écrit dans `/var/log` |
+| `/home` | Répertoires des utilisateurs | Pas exigé par une ligne du sujet. Utile dès qu’on se connecte autrement qu’en root |
+| `/root` | Répertoire personnel du superutilisateur | Distinct de la partition racine `/` |
+| `/run` | Données d’exécution depuis le dernier boot | PID files, socket udev. Remplace l’ancien `/var/run` |
+| `/opt` | Logiciels ajoutés en dehors du système de base | Souvent vide dans un LFS minimal |
+| `/mnt`, `/media` | Points de montage temporaires | Vides au départ |
+
+Le swap n’a pas de chemin FHS. C’est une partition que le noyau utilise comme mémoire, déclarée dans `/etc/fstab` avec le type `swap`. On ne crée pas de système de fichiers dessus.
+
+## Deux distinctions qui évitent des erreurs
+
+**Partition et répertoire.** `/boot` est un répertoire. Le sujet demande aussi que ce répertoire soit une partition : un morceau de disque monté sur ce répertoire au boot. On peut avoir le répertoire `/boot` sans partition séparée. Le sujet veut les deux.
+
+**`/bin` et `/usr/bin`.** Historiquement, `/bin` survit si `/usr` est sur un autre disque pas encore monté. Beaucoup de distributions récentes fusionnent les deux par des liens. LFS explique son choix dans le chapitre qui crée l’arborescence. Pour le sujet, l’arbre doit rester lisible selon cette table.

docs/ft-linux/references/lfs.md

@@ -0,0 +1,62 @@
+# Linux From Scratch — « The Bible »
+
+Adresse du PDF : <http://www.linuxfromscratch.org/lfs/view/stable/index.html>
+
+Livre de Gerard Beekmans, éditeur Bruce Dubbs. Édition consultée : 1er septembre 2025. Licence du livre : Creative Commons et MIT, indiquées dans l’annexe F du livre. On ne le recopie pas ici.
+
+## À quoi sert ce lien
+
+LFS est une recette pour construire un système Linux en compilant chaque paquet depuis les sources, sur une partition vide. ft_linux demande exactement cela, avec quelques contraintes en plus (login dans la version du noyau, trois partitions, chemin des sources, checksum de l’image). Quand le sujet dit « The Bible », c’est ce livre, pas un autre tutoriel.
+
+Le mot `stable` dans l’URL suit l’édition courante. Le sommaire ci-dessous est celui du 1er septembre 2025. Au moment de construire, rouvrir cette URL et noter le numéro de noyau du chapitre 10.
+
+Il existe une variante systemd du même livre, à une autre URL. Le sommaire de `stable` à cette date contient SysVinit et les scripts de boot System V. C’est la variante qui correspond à la liste du sujet (`Sysvinit`). systemd reste permis par la phrase « like SysV or SystemD », mais ce n’est pas le livre que cette URL ouvre.
+
+## Comment le livre est organisé
+
+Le livre se lit dans l’ordre. Sauter un chapitre casse la toolchain : un compilateur construit trop tôt ne sait pas encore produire des programmes pour le nouveau système.
+
+| Partie | Ce qu’on fait | Lien avec ft_linux |
+|--------|----------------|--------------------|
+| Préface | Public, architectures, prérequis, rapport aux standards, pourquoi chaque paquet est là | Le chapitre « LFS and Standards » cite POSIX.1-2008, FHS 3.0 et LSB 5.0. Ce sont les trois autres liens du sujet |
+| I. Introduction | Vue d’ensemble : hôte, nouvelle partition, toolchain temporaire, puis système final | C’est le plan de tout le projet |
+| II. Préparer | Chapitre 2 : la machine hôte, la partition, le système de fichiers, la variable `$LFS`. Chapitre 3 : la liste des archives et des correctifs. Chapitre 4 : un utilisateur `lfs`, l’environnement, les SBU, les tests | La partition du chapitre 2. Le sujet en veut au moins trois : racine, `/boot`, swap. Le livre insiste surtout sur une partition racine et traite le swap à part |
+| III. Toolchain temporaire | Chapitres 5 à 7. On compile un compilateur croisé, puis des outils temporaires, puis on entre en `chroot` | On n’utilise pas le GCC de l’hôte pour le système final. Sinon la distro dépend de la machine qui l’a construite |
+| IV. Le système | Chapitre 8 : les paquets définitifs, dans un ordre précis. Chapitre 9 : nom d’hôte, réseau, scripts de boot, locale. Chapitre 10 : `fstab`, noyau, GRUB. Chapitre 11 : redémarrage | C’est ici que tombent le hostname = login, Internet, le noyau >= 4.0, GRUB, et le chargeur de modules |
+| V. Annexes | Sigles, dépendances, scripts de boot, règles udev, licences | L’annexe C dit quel paquet doit être construit avant quel autre. L’annexe D est le démarrage SysV |
+
+SBU : Standard Build Unit. Le livre mesure le temps de chaque paquet en multiples du temps que prend le premier GCC. Ça sert à prévoir la durée, pas à être noté.
+
+`chroot` : la commande change la racine vue par les processus. À partir du chapitre 7, `/` n’est plus le disque de l’hôte, c’est la partition LFS. On compile « dedans » avant que ce disque sache booter tout seul.
+
+## Ce que le livre stable de 2025 ne fait pas à la place du sujet
+
+À garder sous les yeux pendant la construction. Le livre est la méthode. Le PDF est la consigne notée.
+
+| Consigne du sujet | Dans LFS stable (1er sept. 2025) |
+|-------------------|----------------------------------|
+| Noyau >= 4.0 | Le chapitre 10 construit Linux 6.16.1. Ça passe |
+| Sources dans `/usr/src/kernel-$(version)` | Le livre compile le noyau depuis l’arbre des sources du chapitre 3, souvent sous `$LFS/sources`. Le sujet demande en plus une copie, ou le déballage, à cet endroit. `/usr/src` est le répertoire FHS prévu pour les sources |
+| Version qui contient le login, fichier `vmlinuz-<linux_version>-<student_login>` | Le livre installe `vmlinuz-<version>` selon le `Makefile` du noyau. Le login se ajoute avec `CONFIG_LOCALVERSION` ou `EXTRAVERSION`, puis le nom du fichier dans `/boot` et la ligne GRUB suivent le sujet |
+| Hostname = login | Chapitre 9, fichier `/etc/hostname`. On y met le login, pas `lfs` |
+| Au moins racine, `/boot` et swap | Le livre peut se contenter d’une racine. Le sujet en veut trois. Le swap est une partition sans système de fichiers, activée par `swapon`, déclarée dans `/etc/fstab` |
+| Chargeur de modules « comme udev » | Le livre n’installe plus Eudev. Il construit « Udev from Systemd » : les sources udev extraites de l’archive systemd, sans faire de systemd le processus PID 1. Le sujet liste encore `Eudev` et `Udev-lfs Tarball`, qui sont les noms des éditions plus anciennes. Le sujet dit que `udev` est un exemple remplaçable par un équivalent |
+| `Sysvinit` dans la liste | Présent : SysVinit 3.14 et les bootscripts. C’est le PID 1 de cette édition |
+| GRUB | Présent : GRUB 2.12, chapitre 10 |
+| Pouvoir télécharger et installer encore des paquets | Le chapitre 3 suppose qu’on a déjà récupéré les archives (wget ou un navigateur, depuis l’hôte). curl ou wget dans la distro finie, c’est le sujet qui le demande pour la soutenance, pas le sommaire du chapitre 8 |
+
+## Paquets du livre absents de la liste du sujet
+
+L’édition 2025 construit aussi, entre autres : Python, OpenSSL, Meson, Ninja, lz4, zstd, libxcrypt, libelf, libffi. Le noyau et certains outils récents ne se compilent plus sans OpenSSL ni Python. Les ajouter ne contredit pas le sujet : il demande de pouvoir installer des paquets, et il dit que les versions sont libres. Ce ne sont pas des lignes de la liste notée. À la soutenance, on montre la liste du PDF, et on sait expliquer pourquoi OpenSSL est là en plus.
+
+## Ordre réel, pas l’ordre alphabétique du PDF
+
+La liste du chapitre IV du sujet est un inventaire. L’ordre de compilation est celui du chapitre 8 du livre. Exemples qui cassent si on inverse :
+
+- GMP, puis MPFR, puis MPC, puis GCC. GCC refuse de se construire sans ces trois bibliothèques de calcul.
+- Binutils avant GCC. Le compilateur a besoin de l’assembleur et du linker.
+- Glibc après les en-têtes du noyau. La bibliothèque C doit connaître les appels système de ce noyau.
+- Bash, Coreutils, Grep, Sed après Glibc. Ce sont des programmes, ils se lient à la libc.
+- GRUB et le noyau tout à la fin, quand `/boot` et `/etc/fstab` existent.
+
+L’annexe C du livre est la table de ces dépendances.

docs/ft-linux/references/lsb.md

@@ -0,0 +1,27 @@
+# LSB — le mot `that` du sujet
+
+Adresse du PDF : <http://refspecs.linuxfoundation.org/lsb.shtml>
+
+Linux Standard Base. Dernière version majeure citée par LFS : LSB 5.0, 2015. Quatre cahiers : Core, Desktop, Languages, Imaging, plus des essais Gtk3 et Graphics. Le but historique : qu’un logiciel propriétaire compilé une fois s’installe sur toute distribution certifiée, parce que les bibliothèques et les chemins ont les mêmes noms.
+
+## Ce que le sujet en fait
+
+Même phrase que pour POSIX : à lire, pas noté. LFS le dit aussi, dans « LFS and Standards » : beaucoup de gens contestent ces exigences. La LSB sert surtout les binaires propriétaires. Une LFS se construit depuis les sources, donc on choisit ses paquets. Passer les tests de certification LSB demande beaucoup de paquets que le livre LFS ne construit pas. Ils sont dans BLFS, Beyond Linux From Scratch, un second livre.
+
+## Ce que l’édition LFS de septembre 2025 couvre déjà
+
+Le chapitre « LFS and Standards » range ainsi les paquets du livre de base :
+
+| Volet LSB | Déjà fourni par le livre LFS |
+|-----------|------------------------------|
+| Core | Bash, Bc, Binutils, Coreutils, Diffutils, File, Findutils, Gawk, GCC, Gettext, Glibc, Grep, Gzip, M4, Man-DB, Procps, Psmisc, Sed, Shadow, SysVinit, Tar, Util-linux, Zlib |
+| Languages | Perl |
+| Desktop, Imaging, Gtk3, Graphics | Rien dans le livre de base |
+
+Le volet Desktop, c’est X, polices, GTK. C’est le territoire du bonus du sujet (serveur X, GNOME, KDE, i3), pas de l’obligatoire.
+
+## Écarts assumés
+
+Même le livre LFS ne fournit pas tout le Core LSB. Il manque, entre autres, `at`, `cpio`, `ed`, les outils LSB eux-mêmes, PAM, un MTA (sendmail, postfix ou exim). Certaines bibliothèques que la LSB nomme en version 5 (`libncurses.so.5`) sont fournies en version 6 par Ncurses actuel. Python 2, exigé par l’ancienne LSB, n’est plus dans le livre. Python 3 y est.
+
+Pour ft_linux : connaître cette limite. Ne pas ajouter Postfix ou X « pour la LSB ». Le sujet dit que ce respect n’est pas noté.

docs/ft-linux/references/posix.md

@@ -0,0 +1,25 @@
+# POSIX — le mot `this` du sujet
+
+Adresse du PDF : <http://pubs.opengroup.org/onlinepubs/9699919799/>
+
+C’est la Single UNIX Specification, publiée par The Open Group, alignée sur IEEE POSIX. L’édition ouverte à cette URL est celle que le sujet lie. LFS stable (1er septembre 2025) dit suivre POSIX.1-2008.
+
+Le texte intégral est long de plusieurs milliers de pages et reste la propriété de The Open Group. On ne le recopie pas. Cette fiche dit ce que le mot recouvre pour ft_linux.
+
+## Ce que le sujet en fait
+
+Phrase exacte : ce n’est pas REQUIRED, mais on SHOULD lire `this` et `that` tout de suite. On ne sera pas noté sur le respect de ces standards. `this` est POSIX. `that` est la LSB.
+
+Lire, ici, veut dire savoir ce que la norme garantit, pas implémenter un système certifié UNIX.
+
+## Les trois morceaux utiles
+
+**Les appels système et la bibliothèque C.** `open`, `read`, `write`, `fork`, `exec`, `malloc`. Glibc est l’implémentation Linux de cette bibliothèque. Le noyau, lui, fournit les vrais appels. Un programme POSIX appelle Glibc, qui appelle le noyau. ft_linux ne demande pas d’écrire ces fonctions. Il demande d’installer Glibc, qui les fournit.
+
+**Les utilitaires.** La norme décrit le comportement de `sh`, `ls`, `cp`, `mv`, `grep`, `sed`, `awk`, `find`, `diff`, `make`. Dans la liste du sujet, ce sont Bash, Coreutils, Grep, Sed, Gawk, Findutils, Diffutils, Make. Un script écrit selon la norme tourne sur cette distro parce que ces paquets sont là.
+
+**Le système de fichiers.** POSIX décrit des idées (`/`, `/tmp`, `/dev`) que le FHS détaille pour Linux. Pour l’arborescence notée, la fiche à suivre est [fhs.md](fhs.md).
+
+## Ce qu’on ne fait pas
+
+On ne passe pas la suite de tests de certification POSIX. On ne remplace pas Bash par un shell minimal qui ne saurait que le strict POSIX, sauf à le décider : le sujet liste Bash, qui est un sur-ensemble de `sh`. LFS crée en général un lien `/bin/sh` vers bash.