Overview
Layers
From the hardware up, an Eydos system is made of:
| Layer | Component | Role |
|---|---|---|
| Base | Debian | Kernel, packaging, system services |
| Display | Forge | Wayland compositor on KMS/DRM |
| Shell | Crustace | Top bar, launcher, notifications, lock screen |
| Toolkit | ltk | UI toolkit for the shell and applications |
| Integration | eydos-notifier, xdg-desktop-portal-eydos, liberux-loginmanager | Notifications, portals, greeter |
| Applications | Native, Flatpak and Android | See application classes |
The eydos-desktop meta-package installs the display, shell, toolkit and integration layers in one step.
One rule
Everything else in the architecture follows from one rule: only the system and applications run, and an application is whatever has an identity and a sandbox.
- The system is what the base installs: kernel, services, compositor, shell, toolkit and first-party apps. It is trusted.
- An application is a Flatpak or an Android package. It has an identity (its app id or package name) and runs confined. Everything it wants from the outside, from the camera to a file, goes through the permission system.
- Anything else, a downloaded binary or a script, only runs by becoming an application: the system launcher gives it an identity and a sandbox on the spot.
Trust boundaries
Requests cross the dashed line upwards only through D-Bus, to the portals or to the service that owns a resource. The consent dialog lives in the compositor because it is the only process that can guarantee the dialog is really on screen and not covered or faked. Decisions are stored once, by identity, so Settings has a single place to show and revoke them.
The security model page describes how each boundary is enforced, and application distribution how software gets to the device in the first place.