Air — Vision du projet

Document fondateur — Version 1.0

Qu’est-ce qu’Air

Air est un environnement de bureau pour systèmes Linux, conçu avec soin sur la durée. Il prend la forme d’un ensemble cohérent de couches logicielles, des primitives système jusqu’aux applications, organisées comme un stack vertical où chaque niveau a une responsabilité claire et un contrat stable avec ses voisins.

L’architecture en couches est un principe d’ingénierie éprouvé, partagé par les systèmes d’exploitation sérieux depuis plusieurs décennies. Air en hérite et l’adapte aux possibilités offertes par l’écosystème Linux moderne et par le langage Rust. Chaque couche y est conçue avec un périmètre clair, des interfaces stables, et un objectif de qualité industrielle.

Le projet vise deux profils de fonctionnement, conçus avec un soin égal. Le profil console, appelé air-base, fournit un environnement de bureau complet en mode texte, utilisable sur des machines sans interface graphique ou pour des usages purement console. Le profil graphique, appelé air-desktop, étend ce socle avec un compositeur Wayland, un framework UI déclaratif, et l’ensemble des composants attendus d’un bureau moderne. Les deux profils partagent leurs fondations et ne se distinguent que par le sommet de la pile.

Air est écrit majoritairement en Rust, langage choisi pour ses garanties de sûreté mémoire, son écosystème mature, et sa capacité à produire des bibliothèques exposables en C, donc consommables depuis Swift, Python, Ruby, et d’autres langages. Air est pensé comme polyglotte dès sa conception : les composants centraux exposent leurs APIs dans une forme accessible à plusieurs langages, sans glue spécifique à écrire pour chacun.

Pour qui Air est fait

Air est construit pour des utilisateurs qui veulent un système d’exploitation desktop crédible, productif, et auquel ils peuvent faire confiance pour leurs données. Quatre profils en particulier sont à l’horizon du projet.

Les utilisateurs venant de macOS ou de Windows et frustrés par les évolutions de leurs systèmes actuels. Hausse des prix, obsolescence matérielle programmée, publicité dans l’interface, comptes obligatoires, télémétrie envahissante, transformation progressive de l’utilisateur en produit. Air offre une alternative qui prend ces préoccupations au sérieux, sans les transformer en argument marketing.

Les institutions, administrations, universités, organisations à but non lucratif, qui ont besoin d’un poste de travail prévisible, auditable, et libre de surprises commerciales. Air, dont le code est entièrement libre sous licence MPL 2.0, dont la gouvernance est progressivement transférée à une fondation à but non lucratif, et dont la conception privilégie la stabilité contractuelle, est conçu pour répondre à ces besoins sans dépendance à un acteur commercial unique.

Les développeurs en quête d’un environnement Unix moderne, cohérent, et de qualité industrielle. Air offre un SDK polyglotte, des bibliothèques aux contrats clairs, une approche capability-based de la sécurité, et une infrastructure de développement (tests, fuzzing, benchmarks) qui sera ouverte aux contributeurs avec le même niveau d’exigence que le code lui-même.

Les utilisateurs soucieux de la longévité de leur matériel. Air est conçu pour fonctionner durablement sur des machines modestes ou anciennes. Un MacBook Pro Intel que Apple a cessé de supporter, un PC milieu de gamme de 2018, un Raspberry Pi 4 : tous doivent rester pleinement utilisables sous Air pendant au moins dix ans après leur sortie commerciale.

Air n’est pas conçu pour tous les usages. Il n’est pas pensé pour les gamers haut de gamme cherchant l’exploitation maximale des GPU les plus récents. Il n’est pas pensé pour les utilisateurs qui ont besoin de toutes les applications mainstream sous leur forme native exacte ; un grand nombre d’applications seront disponibles via Flatpak pendant la phase d’incubation, mais l’écosystème natif d’applications Air prendra des années à se constituer. Il n’est pas pensé pour les early adopters qui veulent essayer la dernière fonctionnalité en avant-première ; Air avancera lentement, en privilégiant la qualité à la nouveauté.

Pourquoi Air, et pourquoi maintenant

L’écosystème Linux desktop est dans un état paradoxal. Sa qualité technique sous-jacente n’a jamais été aussi bonne. Le kernel Linux, systemd, Wayland, PipeWire, Vulkan, les drivers graphiques libres : autant de fondations matures sur lesquelles construire. Les langages modernes, Rust en tête, offrent des outils qui permettent d’aborder la programmation système sans les fragilités du C historique.

Pourtant, au niveau de l’expérience utilisateur, le Linux desktop reste fragmenté et inégal. GNOME et KDE, les deux environnements de bureau majeurs, fournissent un travail considérable et de grande qualité ; chacun a sa philosophie, ses utilisateurs fidèles, et ses contributions à l’écosystème. Les utilisateurs grand public, cependant, restent largement absents du Linux desktop dans son ensemble : la part de marché progresse peu malgré la qualité technique réelle, et beaucoup d’utilisateurs venant de macOS ou de Windows n’y trouvent pas immédiatement leurs marques.

Air propose une troisième alternative, construite avec soin sur la durée, à côté des deux environnements établis. Le projet ne cherche pas à se substituer à GNOME ou KDE, ni à dupliquer leur travail. Il explore une autre approche, fondée sur d’autres choix techniques et une autre cadence d’évolution, en complémentarité plutôt qu’en opposition. Pendant que cette construction se fait, les distributeurs Linux n’ont rien à changer à leurs offres actuelles. Quand Air aura démontré sa qualité et sa stabilité, ils pourront choisir de le packager comme un troisième environnement officiel, en faisant ce qu’ils savent faire mieux que nous : packager et distribuer à grande échelle. La transmission progressive du projet aux distributeurs établis fait partie du plan, pas de la concurrence.

Le moment est favorable pour plusieurs raisons. Rust a atteint la maturité qui permet d’envisager sereinement un stack système ambitieux. Wayland a remplacé X11 comme protocole d’affichage moderne, ouvrant la possibilité de repenser le compositeur sans dette héritée. Le projet Asahi Linux a ouvert le matériel Apple Silicon à Linux, étendant les machines accessibles à un parc important. Les utilisateurs ont une fatigue croissante face aux écosystèmes commerciaux dominants. Et l’écosystème open source a démontré, avec des projets comme Blender, qu’un logiciel libre gouverné par une fondation peut atteindre une qualité industrielle reconnue dans son domaine.

Les principes fondateurs

Air est guidé par cinq principes qui orientent tous les choix de conception et de gouvernance.

Crédible plutôt qu’extraordinaire. Air ne cherche pas à être le meilleur, le plus beau, le plus rapide, ou le plus sécurisé dans l’absolu. Air cherche à être crédible : un système dans lequel on peut avoir confiance pour son usage quotidien, qui fait son travail sans bruit ni démonstration. La crédibilité se construit par la constance et par le soin, pas par le marketing.

Productif au quotidien. Air est un outil de travail, pas une vitrine technologique. Les choix de conception privilégient ce qui rend l’utilisateur productif : démarrage rapide, applications qui se lancent vite, navigation fluide, intégration cohérente. Pas d’animations longues qui font joli mais ralentissent. Pas de notifications intrusives. Le système sert l’utilisateur, jamais l’inverse.

Confiance par défaut. Les utilisateurs doivent pouvoir faire confiance à Air sans avoir à le surveiller. Air est construit en sachant que les données des utilisateurs sont activement recherchées, monnayées, exfiltrées par défaut dans la plupart des écosystèmes commerciaux. Air est conçu pour ne pas faire cela, jamais. Aucune télémétrie utilisateur. Aucun compte obligatoire. Aucun cloud forcé. Aucun partage de données par défaut. Un sandboxing applicatif fondé sur des capabilities protège les apps les unes des autres et les données de l’utilisateur de toutes.

Longévité du matériel. Air est conçu pour fonctionner sur des machines pendant longtemps. Au moins dix ans après leur sortie commerciale, ou dix ans après l’abandon par leur fabricant d’origine. Cette contrainte est volontaire et structurante : elle oriente le design vers la fluidité sur matériel modeste plutôt que l’exploitation maximale de matériel haut de gamme. Les machines de référence du projet, sur lesquelles Air est validé en continu, sont des machines modestes et diversifiées (Raspberry Pi 4 pour ARM64, Mac mini et MacBook Pro Intel pour x86_64).

Indépendance et durabilité institutionnelle. Air est entièrement libre, gouverné par une fondation à but non lucratif à constituer, indépendante d’un acteur commercial unique. Le modèle de financement est diversifié pour éviter toute dépendance critique à un sponsor. La marque “Air” est destinée à devenir propriété de la fondation et protégée contre l’appropriation hostile. Ce n’est pas une posture idéologique, c’est une condition de la confiance utilisateur sur le long terme : un système dont la gouvernance peut être achetée n’est pas un système auquel on peut confier ses données.

L’architecture en bref

Air est organisé en six couches logicielles, conçues bottom-up. Chaque couche a un périmètre clair et un contrat stable avec les couches adjacentes. Cette description reste à un niveau d’aperçu ; un document distinct de macro-architecture en présente les détails.

La couche 0 est une façade Rust propre sur les services du kernel Linux : syscalls, I/O asynchrone via io_uring, primitives de sandboxing via Landlock et seccomp, communication inter-processus via Unix sockets. Elle abstrait le kernel sans le cacher, et reste assez fine pour qu’un développeur système retrouve ses repères Unix.

La couche 1 fournit les primitives système fondamentales : processus, threading, mémoire, temps, sockets, cryptographie, accès aux devices via udev. Elle est écrite en Rust, exposée également en ABI C, et conçue avec un objectif de couverture de tests de 100 %.

La couche 2 est le cœur conceptuel du système. Elle porte le modèle d’objet d’Air, exposé en ABI C, qui permet à toute classe d’avoir une identité runtime, des propriétés observables, et d’être bindable sans glue spécifique depuis n’importe quel langage. Elle porte également AirCom, le protocole IPC d’Air, capability-based, schema-first, performant, qui remplace D-Bus pour les communications internes au stack Air tout en permettant l’interopérabilité avec l’écosystème freedesktop existant. Elle fournit l’event loop unifié, les collections Unicode-aware, le système de notification, l’intégration avec systemd, et les services fondamentaux que toutes les couches supérieures consomment.

Le choix de AirCom comme IPC interne d’Air, plutôt que D-Bus, mérite une note. D-Bus est le mécanisme d’IPC historique de l’écosystème Linux, utilisé par systemd, NetworkManager, BlueZ, polkit, et la grande majorité des services freedesktop. Air le reconnaît et continue à parler D-Bus pour interopérer avec ces services existants. En revanche, pour les communications entre les services Air natifs eux-mêmes, Air a conçu AirCom, qui répond à des besoins spécifiques de sécurité capability-based, de stabilité contractuelle sur dix ans, et de performance sur matériel modeste que D-Bus ne couvre pas par construction. Ce n’est ni un rejet de D-Bus, ni une réinvention pour le plaisir : c’est un complément orienté vers les exigences propres d’Air. La justification technique complète, les sources, et l’articulation avec les autres décisions du projet sont consignées dans l’ADR-001.

La couche 3 prend en charge le rendu et la composition. Elle inclut deux compositeurs jumeaux qui partagent leur backend (DRM, evdev, seats via logind, rendu de glyphes) : air-wm pour le mode graphique Wayland, et air-console pour le mode texte. Le mode console n’est pas un sous-cas dégradé du mode graphique ; c’est un compositeur à part entière qui contourne les limitations de la console kernel pour offrir aux applications TUI l’accès aux véritables événements d’entrée et un rendu pleine maîtrise via DRM/KMS. La couche 3 inclut également le moteur audio (consommation de PipeWire) et le rendu de texte avec support bidirectionnel pour les écritures de droite à gauche.

La couche 4 fournit les frameworks applicatifs. Elle se décline en deux frameworks symétriques : air-ui pour le mode graphique, et air-tui pour le mode texte. Les deux partagent un modèle de composition de vues déclaratif, inspiré de SwiftUI et de Xilem, transposé en Rust idiomatique avec une emphase sur l’explicitation du flux de données plutôt que la magie cachée. Une application Air peut être écrite pour fonctionner dans les deux modes avec un seul code, certaines fonctionnalités étant capability-gated selon le contexte d’exécution.

La couche 5 prend en charge le cycle de vie des applications et les services transverses. Les applications Air sont distribuées sous forme de bundles .airapp (ou .airservice pour les composants système), signés, autonomes et déplaçables, sous la forme d’un répertoire structuré qui regroupe le binaire, ses ressources et son manifeste. Le launcher applique au démarrage les entitlements déclaratifs de l’application : isolation par namespaces, sandbox par Landlock, distribution des capabilities AirCom initiales. L’utilisateur conserve un contrôle fin sur ce que chaque application peut faire.

L’accessibilité et l’internationalisation ne sont pas des modules optionnels ajoutés après coup ; elles sont conçues dès la couche 2. Le modèle d’objet C-ABI porte les propriétés accessibility universelles, ce qui rend toute application Air accessible par construction. Le système consomme icu4x pour l’internationalisation, supporte Unicode 16 et au-delà, et est conçu pour le bidirectionnel et les méthodes de saisie complexes dès le départ.

Calendrier et patience

Air sera construit lentement, par phases, avec un objectif de qualité plutôt qu’un objectif de date. Le phasage suit une logique bottom-up : chaque phase produit un livrable démontrable de bout en bout, et chaque phase repose sur la stabilité des phases précédentes.

Une phase préliminaire met en place l’infrastructure de qualité : intégration continue, couverture de tests, fuzzing, benchmarks, conventions de code, infrastructure de validation matérielle. Cet investissement initial significatif rapporte ensuite à chaque phase.

La phase 0 construit la couche d’abstraction système et le noyau des primitives système, avec un objectif de couverture de tests de 100 %. La phase 1 construit le modèle d’objet C-ABI et le transport AirCom. La phase 2 ajoute le typage Cap’n Proto, l’intégration systemd, et livre le premier service système démontrable, marquant la première publication publique du projet. La phase 3 construit air-console, le compositeur de mode texte. La phase 4 construit air-tui et une première application démonstrative ; elle marque la sortie d’air-base 1.0, un environnement console complet et utilisable.

Les phases suivantes construisent le compositeur Wayland air-wm, le framework graphique air-ui, les applications graphiques, et l’écosystème nécessaire à air-desktop. Une version d’Air OS capable d’accueillir confortablement des utilisateurs grand public viendra ensuite, quand l’ensemble du stack aura atteint la maturité requise.

Air ne s’engage pas sur des dates publiques pour ces phases. L’expérience des projets ambitieux montre que les engagements de date conduisent soit au compromis sur la qualité, soit à la déception. Air communiquera sur ses avancées au fur et à mesure qu’elles seront acquises, sans surpromettre.

Cette patience est un choix. Elle correspond à la cadence d’une construction soigneuse, à la durée nécessaire pour valider chaque décision en pratique, et à l’horizon réaliste de l’adoption par les distributeurs Linux. Elle correspond aussi, plus simplement, à ce que demande un travail de qualité.

Avant que la version 1.0 ne soit figée, Air entrera dans une période exploratoire pendant laquelle les API publiques seront marquées comme stables candidates mais pourront encore être corrigées sur la base des retours utilisateurs. Cette période vise à figer l’ABI stable seulement quand l’usage réel l’aura validée. La promesse de stabilité ABI sur dix ans commence à partir d’Air 1.0 figé, pas avant.

Comment Air vit

Le code d’Air est entièrement publié sous la licence Mozilla Public License 2.0. Cette licence protège le cœur du projet contre l’appropriation propriétaire tout en permettant aux applications, qu’elles soient libres ou commerciales, de consommer librement les bibliothèques d’Air. Les contributions externes sont accueillies sous le Developer Certificate of Origin, qui garantit aux contributeurs qu’ils conservent leurs droits.

La gouvernance technique évolue avec le projet. Pendant la phase d’incubation, le fondateur assume le rôle de BDFL, prenant les décisions techniques et arbitrant les désaccords. Quand le projet atteint une base régulière de contributeurs, un comité technique est constitué, composé du fondateur et de contributeurs cooptés puis élus. Les décisions structurantes passent par un processus de RFC public, sur le modèle éprouvé de Rust. À terme, lorsque le projet atteindra Air 1.0, une fondation à but non lucratif sera constituée pour porter juridiquement le projet, gérer la marque, et garantir l’indépendance institutionnelle.

Le modèle économique s’inspire de la Blender Foundation, sans copier mécaniquement. Donations individuelles, sponsoring d’entreprises sans pouvoir directionnel exclusif, partenariats avec distributeurs Linux et fabricants de matériel, services optionnels (support entreprise, certification développeurs, formations) opérés par la fondation. Aucune publicité dans le système. Aucune vente de données. Aucun modèle freemium amputant la version libre.

La marque “Air” sera protégée juridiquement avec une politique d’usage souple inspirée du modèle Linux : usage libre pour la communauté, les distributions, les éditeurs d’applications, sans autorisation préalable formelle ; action juridique réservée aux abus manifestes.

Quand viendra le temps de l’adoption à plus grande échelle, les distributeurs Linux établis seront invités à packager Air comme un troisième environnement de bureau à côté de GNOME et KDE. Le travail de qualité accompli en amont — stabilité ABI tenue, dépendances minimales et auditées, tests reproductibles, documentation complète — rendra ce travail possible sans friction. Air n’a pas vocation à devenir une distribution Linux majeure de plus ; il a vocation à devenir un environnement de bureau crédible, distribuable par celles qui existent déjà.

Une dernière chose

Ce document est une boussole, pas une promesse contractuelle. Air est un projet en construction. Certaines décisions architecturales seront raffinées à l’usage. Certaines estimations de calendrier seront révisées. Mais les principes posés ici sont stables, et les décisions structurantes prises avant l’ouverture publique du projet — consignées dans dix-sept ADRs fondateurs, dans la Charte du projet, et dans les Principes d’ingénierie — encadrent toute évolution future.

Air est une invitation à construire patiemment quelque chose de propre.

Licence du document : MPL 2.0 Statut : Document fondateur immuable. Toute évolution requiert un RFC dédié.