gnosix

Once started, gnosix replaces the session's graphical shell. It is not a decoration laid over an existing desktop: it is the desktop itself, drawn in Rust and displayed natively.

A desktop spends most of its time doing nothing. gnosix takes that into account: no redraw at rest. Nothing is repainted while nothing changes, which spares the graphics card and the battery.

When something moves — the bar changing edge, the deck stretching — motion follows 4-millisecond deadlines, set to the screen's real refresh rate. The repository measured it at 75 and 165 frames per second. At 165 Hz a frame lasts about 6 ms: a 4 ms deadline leaves room never to skip one.

The workspace manager shows live window thumbnails. The repository sets their bounds: thumbnails live in memory only, are never captured while the session is locked, and a list of excluded applications keeps sensitive windows out. Notifications have per-application rules and a "do not disturb" mode.

Every input field on the desktop — search, settings, lock screen — goes through the same editor, which splits text by grapheme (a character as you see it, accents and emoji included) and accepts input methods. French and English cover the whole shell, lock screen included, and a coverage check refuses a forgotten string.

It is the project's most important architectural decision, and the easiest to explain: observing, remembering, showing and acting are four different trades. gnosix gives them four distinct planes.

The observation plane translates the compositor's facts into a typed, deterministic model: screens, workspaces, windows, focus, visibility. This model decides nothing; it describes.

The durable plane keeps identities and profiles. A plugged-in screen is not automatically "the known screen": the association between the session identity and the durable identity is explicit, and can deliberately fail.

The presentation plane projects the current state onto the screen. Geometry there is product data, not decoration: the same geometry is used to paint and to decide whether a click hits its target.

Finally, the authority plane carries out the rare gestures: locking, launching an application, switching workspaces. Each request carries a typed target and a freshness boundary. If the state is unknown or stale, the system refuses rather than inventing normal behaviour.

At the snapshot commit, gnosix holds 182,325 lines of Rust written by the project, spread over 38 packages ("crates") and a checking tool. The presentation layer, gnos-ux-gpui, carries 58% of it on its own: drawing a desktop that responds well takes more code than observing or governing it.

The repository distinguishes five states, and publishes them surface by surface. This is not rhetoric: it is what stops a successful demo from turning into a general promise.

gnosix's public repository does not tell the whole story, and says so. Development happens in a private repository; the public one receives projections of it at each release. What is visible starts on October 5, 2026.

The release policy, ratified on October 21, fits in a few rules. The private repository is the truth; the public repository is a projection written one way, by a script, with a whitelist of paths and a manifest of fingerprints. A public contribution is reviewed, integrated on the private side, and comes back with the next release.

The product is named by the year and month it ships, plus a mineral name, in alphabetical order: 26.11 « Ardoise » (slate). The crates keep semantic versioning: a crate whose interface changes must change its version, or the release check refuses it. Three channels: edge (the development branch, deployed on the author's machine), stable (the latest release), and a possible LTS, decided later.

gnosix's roadmap is driven by evidence: a work item moves when its evidence is complete and, where required, accepted by the author. Releases, on the other hand, have fixed dates — two a year, in May and November — and carry whatever is ready.