Air — Project Vision

Founding document — Version 1.0

What Air is

Air is a desktop environment for Linux systems, designed with care and built for the long term. It takes the form of a coherent set of software layers, from system primitives up to applications, organised as a vertical stack where each level has a clear responsibility and a stable contract with its neighbours.

Layered architecture is a well-established engineering principle, shared by serious operating systems for several decades. Air inherits it and adapts it to the possibilities offered by the modern Linux ecosystem and by the Rust language. Each layer is designed with a clear scope, stable interfaces, and an objective of industrial-grade quality.

The project targets two operating profiles, designed with equal care. The console profile, called air-base, provides a complete desktop environment in text mode, suitable for machines without a graphical interface or for purely console-oriented uses. The graphical profile, called air-desktop, extends this foundation with a Wayland compositor, a declarative UI framework, and the full set of components expected from a modern desktop. Both profiles share the same foundations and differ only at the top of the stack.

Air is written mostly in Rust, a language chosen for its memory safety guarantees, its mature ecosystem, and its ability to produce libraries exposable in C, and therefore consumable from Swift, Python, Ruby, and other languages. Air is designed as polyglot from the outset: its central components expose their APIs in a form accessible to several languages, with no language-specific glue to write for each.

Who Air is for

Air is built for users who want a credible, productive desktop operating system that they can trust with their data. Four profiles in particular are on the project’s horizon.

Users coming from macOS or Windows and frustrated by the direction those systems have taken. Rising prices, planned hardware obsolescence, advertising in the user interface, mandatory accounts, pervasive telemetry, gradual transformation of the user into the product. Air offers an alternative that takes these concerns seriously, without turning them into marketing material.

Institutions, public administrations, universities, and non-profit organisations needing a workstation that is predictable, auditable, and free from commercial surprises. Air, whose code is fully free under the MPL 2.0 licence, whose governance is progressively transferred to a non-profit foundation, and whose design prioritises contractual stability, is built to meet these needs without dependency on any single commercial actor.

Developers in search of a modern, coherent, industrial-grade Unix environment. Air offers a polyglot SDK, libraries with clear contracts, a capability-based approach to security, and a development infrastructure (tests, fuzzing, benchmarks) that will be open to contributors with the same level of rigour as the code itself.

Users concerned about the longevity of their hardware. Air is built to run sustainably on modest or older machines. An Intel MacBook Pro that Apple has stopped supporting, a mid-range PC from 2018, a Raspberry Pi 4: all should remain fully usable under Air for at least ten years after their commercial release.

Air is not designed for every use. It is not aimed at high-end gamers seeking maximum exploitation of the latest GPUs. It is not aimed at users requiring every mainstream application in its exact native form; a wide range of applications will be available via Flatpak during the incubation phase, but a native Air application ecosystem will take years to develop. It is not aimed at early adopters wanting to try the newest feature first; Air will move slowly, prioritising quality over novelty.

Why Air, and why now

The Linux desktop ecosystem is in a paradoxical state. Its underlying technical quality has never been higher. The Linux kernel, systemd, Wayland, PipeWire, Vulkan, the open-source graphics drivers: all mature foundations to build on. Modern languages, Rust foremost among them, offer tools that make systems programming approachable without the historical fragilities of C.

And yet, at the level of user experience, the Linux desktop remains fragmented and uneven. GNOME and KDE, the two major desktop environments, deliver considerable work of high quality; each has its philosophy, its loyal users, and its contributions to the ecosystem. General-purpose users, however, remain largely absent from the Linux desktop as a whole: market share progresses slowly despite the real technical quality, and many users coming from macOS or Windows do not immediately find their bearings.

Air proposes a third alternative, built with care over time, alongside the two established environments. The project does not seek to replace GNOME or KDE, nor to duplicate their work. It explores another approach, founded on different technical choices and a different pace of evolution, in complementarity rather than opposition. While this construction takes place, Linux distributors have nothing to change in their current offerings. Once Air has demonstrated its quality and stability, they will be free to package it as a third official environment, doing what they do better than we do: packaging and distributing at scale. The progressive transmission of the project to established distributors is part of the plan, not a contest.

The timing is favourable for several reasons. Rust has reached a maturity that allows an ambitious systems stack to be undertaken with confidence. Wayland has replaced X11 as the modern display protocol, opening the possibility of rethinking the compositor without inherited debt. The Asahi Linux project has opened Apple Silicon hardware to Linux, extending the range of accessible machines to an important hardware base. Users have a growing fatigue with dominant commercial ecosystems. And the open-source ecosystem has shown, through projects such as Blender, that free software governed by a foundation can reach a level of industrial quality recognised in its field.

Founding principles

Air is guided by five principles that shape every decision in design and governance.

Credible rather than extraordinary. Air does not aim to be the best, the most beautiful, the fastest, or the most secure in absolute terms. Air aims to be credible: a system one can trust for daily use, that does its job without noise or display. Credibility is built through consistency and care, not through marketing.

Productive day to day. Air is a working tool, not a technology showcase. Design choices privilege what makes the user productive: fast startup, applications that launch quickly, smooth navigation, coherent integration. No lengthy animations that look nice but slow things down. No intrusive notifications. The system serves the user, never the other way around.

Trust by default. Users should be able to trust Air without having to keep an eye on it. Air is built with the awareness that user data is actively sought, monetised, and exfiltrated by default in most commercial ecosystems. Air is designed not to do this, ever. No user telemetry. No mandatory accounts. No forced cloud. No data sharing by default. An application sandbox based on capabilities protects apps from each other and protects user data from all of them.

Longevity of hardware. Air is designed to run on machines for a long time. At least ten years after their commercial release, or ten years after their abandonment by the original manufacturer. This constraint is deliberate and structural: it orients design towards fluidity on modest hardware rather than maximum exploitation of high-end machines. The project’s reference machines, on which Air is continuously validated, are modest and varied (Raspberry Pi 4 for ARM64, Mac mini and MacBook Pro Intel for x86_64).

Independence and institutional durability. Air is fully free, governed by a non-profit foundation to be established, independent of any single commercial actor. The funding model is diversified to avoid any critical dependence on a single sponsor. The “Air” trade mark is intended to become the property of the foundation and protected against hostile appropriation. This is not an ideological posture but a condition of long-term user trust: a system whose governance can be bought is not a system one can entrust with one’s data.

The architecture in brief

Air is organised in six software layers, designed bottom-up. Each layer has a clear scope and a stable contract with adjacent layers. The description below remains at the level of an overview; a separate macro-architecture document presents the details.

Layer 0 is a clean Rust facade over kernel services: system calls, asynchronous I/O via io_uring, sandboxing primitives via Landlock and seccomp, inter-process communication via Unix sockets. It abstracts the kernel without hiding it, and remains thin enough that a Unix systems developer keeps their bearings.

Layer 1 provides fundamental system primitives: processes, threading, memory, time, sockets, cryptography, device access via udev. It is written in Rust, also exposed as a C ABI, and designed with the objective of 100% test coverage.

Layer 2 is the conceptual heart of the system. It hosts Air’s object model, exposed as a C ABI, which gives every class a runtime identity, observable properties, and bindability with no language-specific glue. It also hosts AirCom, Air’s IPC protocol: capability-based, schema-first, performant, replacing D-Bus for communication internal to the Air stack while allowing interoperability with the existing freedesktop ecosystem. It provides the unified event loop, Unicode-aware collections, the notification system, integration with systemd, and the fundamental services consumed by all higher layers.

The choice of AirCom as Air’s internal IPC, rather than D-Bus, deserves a note. D-Bus is the historical IPC mechanism of the Linux ecosystem, used by systemd, NetworkManager, BlueZ, polkit, and the vast majority of freedesktop services. Air acknowledges this and continues to speak D-Bus to interoperate with those existing services. For communication between Air’s own native services, however, Air has designed AirCom, which addresses specific needs around capability-based security, contractual stability over ten years, and performance on modest hardware that D-Bus does not cover by construction. This is neither a rejection of D-Bus nor a reinvention for its own sake: it is a complement oriented towards Air’s specific requirements. The complete technical justification, the sources, and the articulation with the other decisions of the project are recorded in ADR-001.

Layer 3 handles rendering and composition. It includes two twin compositors that share their backend (DRM, evdev, seats via logind, glyph rendering): air-wm for graphical Wayland mode, and air-console for text mode. Console mode is not a degraded sub-case of graphical mode; it is a full compositor that bypasses the limitations of the kernel console to give TUI applications access to true input events and full rendering control via DRM/KMS. Layer 3 also includes the audio engine (consuming PipeWire) and text rendering with bidirectional support for right-to-left scripts.

Layer 4 provides application frameworks. It comes in two symmetric frameworks: air-ui for graphical mode, and air-tui for text mode. Both share a declarative view composition model, inspired by SwiftUI and Xilem, transposed to idiomatic Rust with an emphasis on explicit data flow rather than hidden magic. An Air application can be written to run in both modes with a single codebase, with certain features being capability-gated depending on the execution context.

Layer 5 handles application lifecycle and cross-cutting services. Air applications are distributed as .airapp bundles (or .airservice for system components): signed, self-contained, movable, structured as directories grouping the binary, its resources, and its manifest. The launcher applies the application’s declarative entitlements at startup: isolation via namespaces, sandboxing via Landlock, distribution of initial AirCom capabilities. The user retains fine-grained control over what each application is permitted to do.

Accessibility and internationalisation are not optional modules added afterwards; they are designed from layer 2. The C-ABI object model carries universal accessibility properties, which makes every Air application accessible by construction. The system consumes icu4x for internationalisation, supports Unicode 16 and beyond, and is designed for bidirectional text and complex input methods from the outset.

Schedule and patience

Air will be built slowly, in phases, with a quality objective rather than a date objective. The phasing follows a bottom-up logic: each phase produces a demonstrable end-to-end deliverable, and each phase rests on the stability of the previous ones.

A preliminary phase sets up the quality infrastructure: continuous integration, test coverage, fuzzing, benchmarks, code conventions, hardware validation infrastructure. This significant initial investment pays off in every subsequent phase.

Phase 0 builds the system abstraction layer and the core of the system primitives, with an objective of 100% test coverage. Phase 1 builds the C-ABI object model and the AirCom transport. Phase 2 adds Cap’n Proto typing, systemd integration, and delivers the first demonstrable system service, marking the project’s first public publication. Phase 3 builds air-console, the text-mode compositor. Phase 4 builds air-tui and a first demonstration application; it marks the release of air-base 1.0, a complete and usable console environment.

The subsequent phases build the air-wm Wayland compositor, the air-ui graphical framework, the graphical applications, and the ecosystem needed for air-desktop. A version of Air OS able to comfortably welcome general-purpose users will come thereafter, once the entire stack has reached the required maturity.

Air does not commit to public dates for these phases. The experience of ambitious projects shows that date commitments lead either to compromise on quality or to disappointment. Air will communicate on its progress as it is achieved, without overpromising.

This patience is a choice. It matches the pace of careful construction, the time needed to validate each decision in practice, and the realistic horizon for adoption by Linux distributors. More simply, it matches what quality work requires.

Before version 1.0 is frozen, Air will enter an exploratory period during which the public APIs will be marked as stable candidates but may still be corrected on the basis of real user feedback. This period aims to freeze the stable ABI only when real-world use has validated it. The ten-year stable ABI commitment begins from Air 1.0 frozen, not before.

How Air lives

Air’s code is fully published under the Mozilla Public License 2.0. This licence protects the project’s core against proprietary appropriation while allowing applications, free or commercial, to consume Air’s libraries freely. External contributions are welcomed under the Developer Certificate of Origin, which guarantees that contributors retain their rights.

Technical governance evolves with the project. During the incubation phase, the founder takes on the role of BDFL, making technical decisions and arbitrating disagreements. When the project reaches a regular base of contributors, a Technical Committee is formed, composed of the founder and contributors first co-opted and later elected. Structural decisions go through a public RFC process, on the proven model of Rust. In time, when the project reaches Air 1.0, a non-profit foundation will be established to carry the project legally, manage the trade mark, and guarantee institutional independence.

The economic model takes inspiration from the Blender Foundation, without mechanically copying it. Individual donations, sponsoring by companies with no exclusive directional power, partnerships with Linux distributors and hardware manufacturers, optional services (enterprise support, developer certification, training) operated by the foundation. No advertising in the system. No data sales. No freemium model crippling the free version.

The “Air” trade mark will be legally protected with a permissive usage policy inspired by the Linux model: free use for the community, distributions, and application publishers, with no formal prior authorisation; legal action reserved for manifest abuses.

When the time comes for adoption at a larger scale, established Linux distributors will be invited to package Air as a third desktop environment alongside GNOME and KDE. The quality work done beforehand — stable ABI honoured, minimal and audited dependencies, reproducible tests, complete documentation — will make this work possible without friction. Air does not aim to become yet another major Linux distribution; it aims to become a credible desktop environment, distributable by those that already exist.

One last thing

This document is a compass, not a contractual promise. Air is a project under construction. Some architectural decisions will be refined through use. Some schedule estimates will be revised. But the principles set out here are stable, and the structural decisions taken before the project’s public opening — recorded in seventeen founding ADRs, in the Project Charter, and in the Engineering Principles — frame any future evolution.

Air is an invitation to build something clean, patiently.

Document licence: MPL 2.0 Status: Founding document, immutable. Any evolution requires a dedicated RFC.