Étude — Le chemin : d’un jeu de composants sur Ubuntu à un système Air amorçable

Statut : note de travail. Ne fait autorité sur rien ; sert de matière à des décisions ultérieures. Aucune décision n’est prise ici. Le §10 (roadmap) est une première formulation explicitement provisoire, versée pour être retravaillée.

Pourquoi. Air se développe aujourd’hui sur Ubuntu : son noyau, son systemd, son apt, ses services. La cible est un système Air amorçable, avec son propre lanceur, son propre gestionnaire de paquets et son modèle de sécurité. Cette note instruit comment on passe de l’un à l’autre — dans quel ordre, avec quelles étapes intermédiaires, et selon quelle méthode pour décider ce qu’il faut écrire.

1. La question de méthode : « remplacer chaque composant » est un mauvais cadre

C’est le réflexe naturel : lister ce qu’Ubuntu installe, et écrire l’équivalent Air de chaque ligne. Il faut y résister, pour une raison simple : cela revient à importer la décomposition d’autrui.

La liste des composants d’Ubuntu est le produit de trente ans d’histoire et de contraintes qui ne sont pas celles d’Air : compatibilité ascendante avec les conventions des distributions, omniprésence de D-Bus, conformité POSIX, support de tout le matériel existant, cohabitation de plusieurs environnements de bureau. Reprendre la liste, c’est hériter des contraintes qui l’ont produite.

Le cadre juste est fonctionnel : quelles fonctions le système doit-il rendre ? Puis, fonction par fonction, l’un de quatre verdicts :

La catégorie dissous est celle qu’on oublie, et c’est là que sont les économies. Air en a déjà un exemple abouti : udev est un démon chez Ubuntu ; chez Air, air-device est une bibliothèque de couche 1. La fonction — découvrir les périphériques, suivre le branchement à chaud — est rendue, mais il n’y a pas de démon. Personne n’a « remplacé udevd » : le besoin a été satisfait autrement.

2. Ce qu’on peut décider maintenant, et ce qu’on ne peut pas

La frontière est nette, et elle est utile.

On peut décider maintenant tout ce qui est sous la pile graphique : démarrage, supervision, périphériques, comptes, console, journal, réseau de base, paquets. Ces fonctions sont bien comprises, normalisées, et Air possède déjà la plupart des primitives.

On ne peut pas décider utilement maintenant la couche bureau — compositeur, audio, portails, entrées. Ces choix dépendent de décisions non prises (Wayland ? un protocole Air ?) et surtout d’un système qui n’existe pas encore. Les instruire aujourd’hui produirait des spécifications contre un système imaginaire.

Cette frontière n’est pas une esquive : elle dit où le travail d’analyse est rentable aujourd’hui.

3. Première passe d’inventaire par fonction

État relevé dans l’arbre le 2026-08-02.

Les trois exemples que la question nommait méritent d’être traités séparément, parce qu’ils appellent trois verdicts différents.

3.1 NetworkManager — à réduire, pas à répliquer

NetworkManager est un démon de politique : profils de connexion, choix d’interface, itinérance, orchestration du client DHCP, configuration DNS, greffons VPN — le tout exposé sur D-Bus pour que des interfaces graphiques le pilotent.

Air n’a pas besoin de NetworkManager. Il a besoin de certaines de ses fonctions, et il faut les séparer :

• indispensable au premier système amorçable : monter un lien, obtenir une adresse (DHCP ou statique), poser une route, résoudre des noms. C’est tout. La résolution est déjà faite (air-socket) ; le reste ne l’est pas du tout ;
• utile plus tard : profils, bascule filaire/sans-fil, itinérance, VPN ;
• artefact : la surface D-Bus elle-même, qui n’a de sens que dans l’écosystème dont elle vient.

Le périmètre du premier jalon réseau est donc très inférieur à NetworkManager : du netlink pour le lien et la route, un client DHCP minimal. C’est un travail borné.

3.2 wpa_supplicant — à différer explicitement

Celui-ci est d’une autre nature, et il ne faut pas se raconter d’histoire. Ce n’est pas de la politique, c’est du protocole et de la cryptographie : authentification 802.11, WPA2 et WPA3 (SAE), EAP dans ses nombreuses variantes, gestion des clés, dialogue avec le noyau via nl80211. Normalisé, critique pour la sécurité, et volumineux.

Écrire cela en Rust pur est un sous-projet à part entière, comparable en ampleur à ce qu’a représenté air-sshd. Et la doctrine « pas de C » rend l’enveloppement de wpa_supplicant inconfortable.

La bonne nouvelle est qu’aucun des jalons ci-dessous n’en a besoin : QEMU fournit du virtio-net, et les machines du catalogue ADR-014 ont toutes de l’Ethernet. Le Wi-Fi doit donc être différé explicitement, avec la mention qu’il faudra un jour l’instruire comme un chantier propre — plutôt que de le laisser en dette implicite dans un coin de tableau.

3.3 logind — probablement dissous

logind fait : sessions, sièges, inhibiteurs de veille, touche d’extinction, découpage des ressources par utilisateur, et surtout — c’est ce dont tout le monde dépend réellement — qui est connecté sur quel siège, et ce processus a-t-il le droit d’accéder à l’affichage et aux périphériques d’entrée.

Dans le modèle d’Air, cette dernière question est déjà celle du modèle d’octroi et du lanceur. Il est donc plausible que logind n’existe pas comme composant, et que ses fonctions se répartissent entre le lanceur (sessions, cycle de vie) et le modèle d’octroi (accès aux périphériques). À instruire — mais probablement en dissous, pas en « à écrire ».

4. Deux axes à ne pas confondre

L’axe A n’est plus un prérequis : les cibles rt/targets/*-unknown-linux-air*.json sont dans main, et les campagnes de couche 2 s’exécutent dessus (air-sshd est testé sur notre std, sans glibc). Cette note porte sur l’axe B, dont rien n’existe : aucun crate init, boot, launch ou image dans l’arbre.

Un signal à regarder en face : le mécanisme de livraison actuel est cargo xtask deb. Chaque incrément fait d’Air un meilleur citoyen Ubuntu. C’est rationnel aujourd’hui, mais ce n’est pas un chemin vers l’autonomie — c’est un chemin vers l’intégration. La bascule ne surviendra pas d’elle-même.

5. QEMU d’abord, matériel ensuite

L’argument décisif n’est pas le confort, c’est la CI : une image qui démarre sous QEMU peut être un gate sur chaque PR ; une image exigeant du matériel physique ne peut pas l’être. C’est exactement le compromis déjà tranché pour les tests (x86 primaire en CI, aarch64 natif sur main et en nightly) — il suffit de l’appliquer au démarrage.

S’y ajoutent l’itération en secondes, les instantanés (on peut faire paniquer PID 1 cent fois par jour), l’absence de risque pour les machines de développement, et une console série scriptable donc assertable.

Le matériel réel reste indispensable, mais comme validation : QEMU masque les arbres de périphériques, les pilotes réels, la temporisation et les particularités de firmware.

6. Les jalons

L’ordre est dicté par la dépendance de démarrage, pas par l’importance. On ne peut pas commencer par le gestionnaire de paquets : il lui faut un système qui tourne.

Jalon 1 — hello-init

Critère de sortie : QEMU démarre une image Air, PID 1 affiche un message sur la console série, ne panique pas, et répond à SIGTERM.

Contenu minimal : monter /proc, /sys, /dev, moissonner les orphelins, gérer les signaux, rester vivant. C’est peu de code et beaucoup d’inconnues levées : ligne de commande du noyau, format d’image, montage de la racine, console.

C’est la fonction de forçage du programme, au même titre que hello-std l’a été pour le portage de la bibliothèque standard.

Jalon 2 — un shell

Critère de sortie : on ouvre une session sur la console série et on exécute ls.

Force la console et le tty, l’exec, la libc Air, un système de fichiers réel, et l’authentification. Les briques existent (air-terminal, air-account, air-libc-*) : il s’agit de les assembler, pas de les écrire.

Jalon 3 — ssh vers une machine Air

Critère de sortie : depuis une autre machine, ssh utilisateur@machine-air aboutit sur un shell.

C’est le jalon structurant. Il réutilise ce qui est déjà le plus mûr du projet — air-sshd, son privsep, air-log, air-account, air-async — et exerce d’un seul geste le réseau, la supervision de services, le journal et les comptes. Spectaculaire, vérifiable par un tiers, et il valide toute la pile. C’est le hello-std du système.

Prérequis réseau : lien, adresse, route (§3.1). Pas de Wi-Fi (§3.2).

Jalon 4 — l’image se met à jour elle-même

Critère de sortie : l’image bascule d’une version à la suivante en A/B, la nouvelle est vérifiée avant démarrage, et un échec rebascule automatiquement.

À partir de là, tout le reste est de l’ajout incrémental.

7. L’étape intermédiaire : l’image hybride

Faut-il tout écrire avant de démarrer ? Non — et l’étape intermédiaire est classique : une image Air qui démarre avec air-launchd mais utilise encore des binaires d’origine Ubuntu pour les fonctions non écrites, en attendant de les remplacer une à une.

Ce n’est pas un compromis honteux : c’est ainsi que s’amorcent les systèmes. Et cela s’aligne exactement sur la doctrine de provenance — un binaire étranger s’exécute confiné.

Mais cela exige quelque chose de la doctrine, et il faut le dire. Si la politique retenue est « refus pur du binaire non conforme », alors le chemin hybride est fermé : aucun binaire Ubuntu ne pourra tourner, même transitoirement. Le mode « étranger, donc confiné » ne peut pas rester une note de bas de page doctrinale ; il doit être un mode réel, implémenté et testé, parce que c’est le mode dans lequel le système s’amorcera pendant des mois.

C’est un argument issu du chemin en faveur de la politique « refus par défaut, confinement sur octroi explicite » : elle est la seule des deux qui rende l’amorçage possible.

8. Deux décisions qui vont mordre tôt

Le noyau est un composant, et Air n’en a pas. Expédie-t-on celui d’Ubuntu ? Un vanilla avec une configuration propre ? Ce n’est pas cosmétique : dm-verity, Landlock, IPE et seccomp exigent des options de compilation précises, et ADR-025 (« Stratégie de builds reproductibles ») promet des artefacts reproductibles — un noyau reproductible sera un chantier en soi. Pour le jalon 1, un noyau standard avec une configuration documentée suffit ; mais il faut le décider, pas le subir.

Initramfs ou pas ? Avec dm-verity, on en veut généralement un. Pour le premier démarrage, le chemin le plus court est l’inverse : tout compilé en dur dans le noyau, root= sur la ligne de commande, aucun initramfs. Moins de pièces mobiles au jalon 1 ; l’initramfs arrive avec dm-verity au jalon 4.

9. Le piège

La tentation sera de commencer par le gestionnaire de paquets, parce que c’est le sujet intellectuellement le plus riche. Il faut y résister : il dépend de décisions non prises — format du manifeste, arbitre de lancement, modèle d’octroi — et surtout d’un système qui n’existe pas. Écrit maintenant, il sera à réécrire.

10. Roadmap — deuxième formulation

Toujours provisoire. Cette section a été retravaillée le 2026-08-03 sur cinq critiques de la première formulation. Elle ne fige toujours ni l’ordre ni le périmètre, mais elle repose désormais sur un inventaire vérifié dans l’arbre, plus sur une lecture de liste.

10.1 Corrections d’inventaire

Trois affirmations de la première formulation étaient fausses. Elles sont corrigées ici, et chacune réduit le travail.

Le substrat n’est plus un prérequis. La std sur PAL était donnée « quasi terminée » ; elle est mergée et en production (§4). Rien à attendre de ce côté.

Trois « manques » n’étaient pas des syscalls à envelopper :

Et le lot de descellement annoncé était surévalué d’un tiers. Il était donné à cinq syscalls — mount, umount, pivot_root, reboot, clock_settime. Contrôle fait dans crates/air-sys-syscall/ : clock_settime est déjà là (src/time.rs), comme waitid et signalfd. Le lot réel est de quatre : mount, umount2, pivot_root, reboot — et le §10.4 en retire encore un de la phase 0.

Un seul ADR de descellement suffit, sur le modèle d’ADR-051 (« Descellement de la couche 0 pour le runtime et la libc ») ou d’ADR-085 (« Descellement cumulé pour la libc et std »).

10.2 Pourquoi commencer par les APIs — et pourquoi ça ne contredit pas le §9

Le §9 met en garde contre la construction de composants sans système cible. Cet avertissement ne s’applique pas aux APIs, et la distinction est nette :

• un composant de politique — gestionnaire de paquets, arbitre de lancement, modèle d’octroi — se conçoit contre un système. Sans système, on conçoit contre une fiction, et on réécrit ;
• une enveloppe de syscall n’a aucun risque de conception : mount(2) est mount(2), sa forme est dictée par le noyau.

Le travail d’API est donc le seul disponible aujourd’hui à risque de conception nul. Il a de surcroît un avantage de calendrier décisif : il se fait entièrement sur Ubuntu, avec la CI actuelle, la couverture à 100 %, le fuzzing et le property-testing. Aucune image, aucun QEMU requis.

10.3 Le piège de la campagne d’API, et sa parade

Le risque n’est pas de commencer par les APIs : c’est de mener une campagne sur liste papier, puis de découvrir au moment de démarrer qu’il en manque trois, que deux ont la mauvaise forme, et qu’une ne sert à rien.

La parade est celle déjà éprouvée avec hello-std : faire de hello-init le critère de sortie de la campagne d’API, et non la phase suivante. La définition de « terminé » n’est pas « la liste est cochée » mais « ça démarre ». On garde la rigueur du travail d’API, on gagne la validation empirique de la liste.

10.4 Ce que PID 1 doit faire — et ce que cela exige, exactement

La parade du §10.3 dit de faire de hello-init le critère de sortie. Autant l’appliquer tout de suite, sur le papier : on écrit les obligations de PID 1, on en dérive la liste d’APIs, et on regarde ce qui tombe. C’est un exercice de dix lignes qui élague une phase entière.

Ce que l’exercice retire. pivot_root ne sert qu’avec un initramfs, et le §8 a tranché qu’il n’y en aurait pas au jalon 1 : il part en phase 3, avec dm-verity. clock_settime est déjà en couche 0 et ne concerne de toute façon que la synchronisation d’horloge, plus tard. Le descellement de la phase 0 se réduit donc à trois syscalls : mount, umount2, reboot.

Ce que l’exercice retire aussi — et c’est le point important. Aucune de ces cinq obligations n’appelle AirSandboxManager, AirDeviceManager ni AirTerminalManager. Un init minimal ne confine personne, ne pilote aucun périphérique, et écrit sur une console série qui n’est qu’un descripteur de fichier. Ces trois Managers étaient rangés en phase 0 par la première formulation : ils n’y ont pas leur place, non parce qu’ils sont inutiles, mais parce que le critère de sortie de la phase 0 ne les discipline pas. C’est exactement le mécanisme par lequel une phase enfle et glisse.

10.5 Deux voies, pas une suite de phases

De là, un découpage en deux voies de nature différente, qu’il ne faut pas mélanger dans un même compteur d’avancement :

Réserve sur air-sandbox. Dire de la voie B qu’elle est « délégable telle quelle » est vrai pour air-device et air-terminal, et faux pour air-sandbox. Pour les deux premiers, la surface médiatrice ne fait qu’exposer proprement du code écrit et testé : la forme est contrainte par le domaine, et se tromper coûte un renommage. Pour le troisième, la surface est le modèle de sécurité. Décider ce qu’est un profil, ce que vaut le profil par défaut, qui a le droit de l’élargir et par quel geste, comment le manifeste et l’octroi s’y branchent, ce qui se passe quand une demande dépasse l’enveloppe — ce ne sont pas des choix d’API, ce sont des arbitrages de doctrine, et plusieurs restent ouverts : le sort d’ADR-046 D6, la première classe du mode « étranger confiné » (§7), la forme de l’arbitre de lancement.

AirSandboxManager n’est donc pas moins prioritaire — il est moins délégable. Le travail d’exposition peut être préparé en parallèle ; les décisions qu’il cristallise doivent être tranchées avant, sous peine de graver dans une surface médiatrice des choix qui n’ont jamais été faits. C’est la même mise en garde que le §9, appliquée à un Manager plutôt qu’à un composant.

Les deux voies ne sont d’ailleurs pas indépendantes pour toujours : elles ont des rendez-vous. AirTerminalManager devient critique au jalon 2 (le tty d’une session de console), et AirSandboxManager au moment où les premiers services tournent confinés — ce que la doctrine exige par défaut, y compris pour les services Air. Mieux vaut que la voie B ait de l’avance sur ces deux points que l’inverse ; mais l’avance sur air-sandbox se prend en décidant, pas en codant.

10.6 Voie A — le chemin critique

Phase 0. Critère de sortie : hello-init démarre sous QEMU, affiche, survit, et répond à SIGTERM.

1. Le harnais d’image et QEMU — en tête, et bloquant. La première formulation le rangeait « en parallèle » ; c’est faux. On ne peut pas évaluer « démarre sous QEMU » sans image, sans noyau et sans invocation QEMU : c’est l’item qui conditionne le critère de sortie, donc il passe devant. Forme candidate : cargo xtask image, sur le modèle de cargo xtask deb.
2. L’esquive du noyau et du chargeur, assumée. QEMU sait démarrer un noyau directement (-kernel), sans chargeur d’amorçage et sans initramfs (§8). La phase 0 prend donc le noyau d’Ubuntu, avec sa configuration documentée, et la question du chargeur est différée jusqu’à la phase 3 — où le modèle A/B et la vérification de signature la poseront pour de bon. C’est un report explicite, pas un oubli.
3. Un ADR de descellement couche 0 : mount, umount2, reboot.
4. AirMountManager et AirPowerManager sur ce descellement.
5. Le moissonnage des orphelins médié par AirTaskManager, sur waitid et signalfd déjà présents.

Phase 1. Critère de sortie : jalon 2 — une session sur la console série, ls s’exécute. AirCgroupManager (sur cgroupfs, donc sans descellement) et AirServiceManager. Rendez-vous avec la voie B : AirTerminalManager est requis ici.

Phase 2. Critère de sortie : jalon 3 — ssh utilisateur@machine-air aboutit sur un shell. AirLinkManager : codec rtnetlink en sans-IO (ADR-091), plus un client DHCP minimal.

Correction du 2026-08-03 — cette phase part de moins loin qu’annoncé. Le §3 disait « rien » pour la configuration d’interface. C’est vrai du code, pas de la conception : ADR-079 tranche le transport netlink générique et la spec air-netlink 0.1 le décrit déjà — framing des messages, codec d’attributs TLV, corrélation requête/réponse/dump, motif sans-IO. Il reste à écrire la crate, pas à concevoir le sous-système. Une spec air-dhcp existe également (couche 5), sans ADR.

Cette phase ne produit pas son composant de destination. air-sshd existe, il est le chantier le plus actif du projet, et il tourne déjà sur notre std. Il ne lui manque que le substrat : une interface qui monte, une adresse, une route. C’est une différence d’échelle considérable avec ce que le libellé « jalon ssh » laisse croire, et il faut en tenir compte dans l’évaluation.

Phase 3. Critère de sortie : jalon 4 — bascule A/B vérifiée, retour arrière automatique. AirVolumeManager (device-mapper : là, un descellement est bien nécessaire), pivot_root et initramfs, dm-verity, et la décision de chargeur d’amorçage différée en phase 0.

10.7 Voie B — la résorption d’ADR-077

Trois Managers manquants sur des domaines déjà mûrs — air-device, air-terminal, air-sandbox. Aucun syscall neuf, aucun matériel.

Correction du 2026-08-03. Une première rédaction disait ces trois domaines « sans surface objet ». C’est faux : ils exposent AirDevice/AirDeviceEnumerator/AirDeviceMonitor, AirSandbox, AirTerminal. Ce qui manque n’est pas l’objet, c’est le rôle de médiateur qu’ADR-077 impose — un point d’entrée unique que les toits consomment. La voie B est donc plus petite qu’annoncé, et les trois cas ne sont pas de même gravité : faible pour air-device (surface objet complète, il manque le point d’entrée), fort pour air-terminal (l’essentiel est en fonctions libres, et ADR-077 exige nommément un AirTerminalManager). L’état complet est consigné dans l’amendement d’ADR-077.

Mais les trois ne sont pas de même nature, et la réserve du §10.5 se traduit ici en deux lots :

• AirDeviceManager et AirTerminalManager — conception de surface sur du code écrit, testé et couvert. Aucune décision en attente. Délégable, et à lancer en premier : AirTerminalManager a de surcroît un rendez-vous daté au jalon 2 ;
• AirSandboxManager — même travail d’exposition, mais adossé à des arbitrages ouverts (§10.5). Le lot est précédé d’une étape de décision, pas de code : sort d’ADR-046 D6, statut du mode « étranger confiné », forme de l’arbitre de lancement, articulation manifeste/octroi. Tant que ces points ne sont pas tranchés, écrire la surface revient à les trancher par défaut — c’est-à-dire mal.

10.8 Ce qui peut démarrer aujourd’hui

Trois choses, et trois seulement : l’item 1 de la phase 0 — le harnais d’image et QEMU —, AirDeviceManager et AirTerminalManager. Rien d’autre n’est prêt : le descellement attend son ADR et les Managers de la phase 0 en dépendent, tandis qu’AirSandboxManager attend des décisions de doctrine.

Questions ouvertes

1. Le noyau : lequel, avec quelle configuration, et reproductible à partir de quand ? Réponse partielle en phase 0 (§10.6) : celui d’Ubuntu, configuration documentée. La question de fond — vanilla, options dm-verity/Landlock/IPE, reproductibilité — reste entière.
2. Le chargeur de démarrage : GRUB, systemd-boot, U-Boot, ou un chargeur Air ? La réponse dépend du modèle A/B du jalon 4 et de la vérification de signature. Explicitement différée à la phase 3 (§10.6) : le démarrage direct par -kernel sous QEMU permet de ne pas la poser avant.
3. Le mode « étranger confiné » est-il un mode de première classe ? Le chemin hybride en dépend (§7), et cela contredit la politique de refus pur.
4. logind : dissous dans le lanceur et le modèle d’octroi, ou composant à part ? (§3.3)
5. Le Wi-Fi : différé jusqu’à quand, et instruit comme chantier propre quand ?
6. Le format d’image : que contient-elle exactement, et qui la produit — cargo xtask image sur le modèle de cargo xtask deb ?

Licence du document : MPL 2.0 Statut : note de travail, sans autorité.