Hi everyone 
I wanted to share a project I’ve been building around running NixOS on the Framework 13 AMD (Strix Point / AI 300) platform.
The project is called Nyx, and the goal is not just to maintain dotfiles — but to explore what a declarative, modular, forward-extensible desktop architecture can look like when the hardware platform itself is modular and repairable.
This is still actively evolving, but the core design is now stable enough to share and discuss.
What Nyx is
Nyx is an opinionated NixOS flake configuration built around:
-
Niri (scrollable tiling Wayland compositor)
-
Stylix-driven unified theming
-
dual desktop “personality” profiles
-
selectable system performance / memory profiles
-
layered hardening + observability defaults
-
hardware-aware install flow
The repository lives here:
(link once migrated to org)
The main idea: a “Desktop Router”
Instead of treating the desktop stack as a single fixed configuration, NyxOS treats it more like routing between frontend shells over a shared backend substrate.
Right now there are two selectable desktop profiles:
-
Noctalia
-
modern, widget-oriented, Quickshell-driven UI
-
more graphical and Material-like interaction model
-
-
Aurora Waybar
-
retro-futuristic / cyberpunk text-forward environment
-
fast, minimal, information-dense workflow
-
Both share:
-
the same compositor
-
the same keybind normalization layer
-
the same theming pipeline
-
the same shell / CLI ergonomics
-
the same system tuning + security posture
Switching profiles is declarative and rebuild-driven rather than runtime mutation.
The idea is to make UI experimentation safe and reversible without fragmenting the rest of the system.
System Profile Architecture
Another major design axis is flake-evaluation-time system profiling.
NyxOS exposes selectable profiles such as:
-
latency-first
-
balanced
-
throughput
-
battery
-
memory-saver
These control:
-
ZRAM strategy
-
dirty writeback behavior
-
governor choices
-
swap priority / compression
-
optional latency layers
This lets the same machine pivot between:
-
interactive desktop
-
long compile / data workloads
-
travel / thermal constrained use
…without maintaining separate host configs.
Security & operational posture
NyxOS defaults to:
-
hardened kernel knobs (ASLR, kptr restrictions, dmesg gating)
-
USBGuard declarative policy support
-
Network Time Security via Chrony
-
systemd NoNewPrivileges baseline
-
doas-first privilege escalation model
-
optional Secure Boot path via Lanzaboote
There’s also built-in monitoring hooks (Netdata / Node Exporter / optional Grafana).
The goal is not maximum lockdown, but transparent and inspectable baseline hardening that developers can reason about.
Hardware-aware installation
The installer records detected hardware facts declaratively and gates vendor modules behind them.
This helps avoid:
-
closure bloat
-
accidental driver activation
-
confusing cross-machine drift
It also makes the configuration more portable across Framework SKUs.
AI / dev workflow angle
The system is also tuned for local experimentation:
-
ROCm tooling
-
local AI chat tooling + persona switching helpers
-
isolated browser instances for web app workflows
This is still an area I’m expanding.
Current status
Right now I’m preparing to:
-
migrate the repo into an organization namespace
-
perform a structural checkpoint / refactor
-
continue modularizing installer + profile surfaces
-
begin documenting extension patterns
So this post is partly:
-
sharing early
-
inviting architectural discussion
-
and seeing whether other Framework / Nix users are exploring similar ideas
Feedback welcome
If you’re running NixOS (especially Wayland/Niri) on Framework hardware, I’d be very interested in hearing:
-
what problems you’ve hit
-
what abstractions you wish existed
-
how you handle multi-mode performance tuning
-
how much UI stack flexibility you want vs stability
Thanks for reading — happy to answer questions or dig into specifics.