| 1 |
# Project Alloy |
| 2 |
|
| 3 |
*An opinionated, TUI-first tiling user layer for Fedora Silverblue.* |
| 4 |
|
| 5 |
## What Alloy is |
| 6 |
|
| 7 |
Project Alloy is to Silverblue what Omarchy is to Arch: a curated, beautifully-defaulted, keyboard-driven, tiling-first environment that fuses an immutable base, a Wayland compositor, an opinionated terminal-first stack, and a project-authored design system into one coherent system. The name is the thesis: an alloy is stronger than its component metals. |
| 8 |
|
| 9 |
Alloy is terminal-native. The one thing it authors is a ratatui design system and the `alloy` console built on it. Everything graphical it needs, it adopts. |
| 10 |
|
| 11 |
## What Alloy is not |
| 12 |
|
| 13 |
- Not a from-scratch package manager. The previous `sap` design (typed configuration language, federated curator registry, content-addressed outputs) is shelved; we live on rpm-ostree. |
| 14 |
- Not a from-scratch distro. The previous `mountaineer` design (curated Alpine, apk-on-`/etc/apk/world`, s6 init) is shelved; we live on Fedora Silverblue. |
| 15 |
- Not a ublue spin. Alloy is **alongside** Universal Blue (Bluefin, Bazzite, Aurora), not downstream of it; the name was picked specifically to avoid the ublue "Blue\*" prefix convention. |
| 16 |
- Not a gaming distro. The audience overlaps with Omarchy and Omakub, not with Bazzite. |
| 17 |
- Not a GNOME spin. Alloy's authored design system is custom-drawn (ratatui) and does not pick up libadwaita theming. |
| 18 |
|
| 19 |
## Audience |
| 20 |
|
| 21 |
Developers, keyboard-driven power users, Linux-native sensibility. People who would rather configure once than configure often, who prefer modern Rust tools over decades-old legacy ones, who live in the terminal, and who want the tiling-first immutable experience that no existing Fedora atomic variant currently delivers as a curated whole. |
| 22 |
|
| 23 |
The empty quadrant Alloy fills: |
| 24 |
|
| 25 |
|
| 26 |
|
| 27 |
| **GNOME** | Silverblue | Bluefin | |
| 28 |
| **KDE** | Kinoite | (none) | |
| 29 |
| **Tiling (Sway)** | Sericea | **Alloy** | |
| 30 |
| **Gaming** | (none) | Bazzite | |
| 31 |
|
| 32 |
Sericea and Kinoite are bare windowing on an immutable base with no opinionated user layer. Bluefin is GNOME-flavored developer experience. Bazzite is gaming. Alloy is opinionated tiling. |
| 33 |
|
| 34 |
## Guiding principles |
| 35 |
|
| 36 |
1. **Modern, well-featured, Rust-written tools.** When competitive Rust-native options exist, pick them. Where they don't, name the gap honestly and consider filling it. |
| 37 |
|
| 38 |
2. **Native to Alloy's design system, not native to GNOME.** Alloy authors in ratatui and maintains a design-system crate, `alloy_tui`: a palette, themed widgets, footer chrome, and reserved keys that the authored console and any future authored TUI pull from. Heterogeneity with adopted apps (sway's own chrome, swaylock, mako) is a knowing trade, not an accident. |
| 39 |
|
| 40 |
3. **Non-reactive by principle.** Alloy avoids the reactive UI pattern in everything it authors. State-to-view binding, declarative property graphs, async data trickling into UI components, the cluster of patterns that produces staged appearance, animation creep, hover-everywhere, and state-divergence bugs, is the "web-shaped feel" Alloy refuses on principle. ratatui is immediate-mode: it renders the whole frame from current state each cycle, making state divergence architecturally impossible. (egui, immediate-mode GUI, shares this property; Alloy no longer authors GUI apps, but the principle is the same one and would apply if it ever did.) |
| 41 |
|
| 42 |
4. **Backwards compatible with hardware, not with software.** Same principle as `_meta`'s cross-cutting rule. Operators are expected to be on the current Alloy release; hardware support is broad. |
| 43 |
|
| 44 |
5. **Opinionated defaults; the configuration is the documentation.** Every default is a position we will defend in writing. |
| 45 |
|
| 46 |
6. **The console teaches the mental model.** The wedge is the `alloy` console: a terminal-native front door to the system, including a package view that makes Silverblue's three-surface install model (rpm-ostree layered / Flatpak / distrobox) legible. That model is the hardest thing about Silverblue and the thing GNOME Software does not address well. |
| 47 |
|
| 48 |
## What we author vs what we adopt |
| 49 |
|
| 50 |
**Alloy authors** (in Rust): |
| 51 |
- `alloy_tui`, the ratatui design-system crate (palette, themed widgets, footer chrome, mock-or-real backend detection). It is the design system. |
| 52 |
- The `alloy` console (ratatui): info, services, storage, wifi/net, image swaps, generation rollback, a package view, and `alloy config` schema-driven config editing. The mountaineer-sysop pattern carries over directly; see [CONSOLE.md](CONSOLE.md). |
| 53 |
|
| 54 |
**Alloy curates** (from upstream): |
| 55 |
- Fedora Silverblue as the base. |
| 56 |
- Sway as the compositor. |
| 57 |
- swaylock (lockscreen), mako (notifications), swaybar (bar): the graphical pieces a TUI cannot serve, adopted rather than authored. |
| 58 |
- The userland stack; see [STACK.md](STACK.md). |
| 59 |
|
| 60 |
## Status |
| 61 |
|
| 62 |
Pre-v0. This document is the project. Code follows. |
| 63 |
|
| 64 |
Pivoted 2026-07-17 from an egui-authored, Niri scrolling-tiler design to this TUI-first, Sway shape. The scrolling-tiler model and the egui marquee-app wedge (lockscreen, package GUI, notification daemon, egui bar) were dropped; the immediate-mode thesis carried over unchanged because ratatui is immediate-mode too. |
| 65 |
|