Omarchy system components: how the Linux desktop fits together
Learn Omarchy’s Arch foundation, desktop and service relationships through ten layers, complete catalogued lists and practical tasks.
Omarchy combines an Arch Linux foundation, a Wayland desktop, background services and applications with its own configuration and tools. Start with what a component does, then follow the connections to the next layer.
Browse the component catalogue → · Search the package manifests
How the main parts cooperate
Section titled “How the main parts cooperate”Think of a task crossing boundaries: firmware and boot tools start the system; the graphical session manages windows and input; panels let you control background services; applications perform the work. Omarchy supplies defaults and integration across those parts. This is a simplified learning path, not a claim that every action passes through one strict chain.
For example, a video call needs an application, a working connection, an audio route and possibly desktop sharing. A functioning desktop does not prove the microphone selection is correct. Start with the failed action, identify the responsible layer, then inspect its cooperating components.
| Question | Layer to begin with | Related task guide |
|---|---|---|
| How does the computer reach the desktop? | Boot → desktop | Installation and startup |
| Who draws the bar and organizes windows? | Interaction and desktop | Customization |
| Who handles Wi-Fi, Bluetooth and sound? | Network and media | Hardware and connectivity |
| What interprets commands and edits projects? | Development | Apps and tools |
| What protects system state and personal work? | Storage | Maintenance and recovery |
Choose a way to explore
Section titled “Choose a way to explore”- Learn the architecture: follow the ten layer pages below. Each starts with cooperation and then explains all components currently catalogued in that category.
- Look up one program: use the searchable component catalogue for purpose, configuration entry points, related components and upstream evidence.
- Check a package name: use the manifest index. Being listed in source is different from being installed on your machine.
The layer pages provide conceptual and practical explanations. The catalogue is the quick lookup interface. The manifest index preserves source membership. These views share evidence but answer different questions.
A map of the system
Section titled “A map of the system”Follow a layer name to its dedicated page for an explanation and complete component list, or a component name for its details. All currently catalogued components appear below, grouped by primary function rather than strict dependencies.
All 40 catalogued components · 10 categories
| Layer | Purpose | Catalogued components |
|---|---|---|
| Boot & base system →2 components | Firmware starts a bootloader; the kernel and system services bring up the system. Platform boot chains differ. | Limine · Plymouth |
| Desktop & windows →3 components | A login manager starts a session; the compositor organizes windows and displays. | Hyprland · UWSM · SDDM |
| Desktop interaction →2 components | Menus, panels and notifications provide controls for services beneath them. | Quickshell · wl-clipboard |
| Network & connectivity →4 components | Connection management, Bluetooth and local discovery solve different problems. | NetworkManager · BlueZ · Avahi · UFW |
| Audio & video →6 components | Media processing, routing and desktop sharing have separate responsibilities. | WirePlumber · PipeWire · Hyprland desktop portal · GPU Screen Recorder · mpv · wf-recorder |
| Input & display →5 components | Input-method engines differ from keyboard layouts; backlight differs from monitor color temperature. | Fcitx 5 · Fcitx 5 Chinese Addons · hyprsunset · brightnessctl · ddcutil |
| Terminal & development →8 components | A terminal hosts a shell; editors, prompts and runtime managers add capabilities. | Foot · Starship · tmux · Neovim · Git · Lazygit · mise · Docker |
| Applications & packages →4 components | Applications do the work; package tools install and update software. | Chromium · Files / Nautilus · yay · CUPS |
| Storage & maintenance →4 components | Mounting, system rollback and personal-file backup are different tasks. | udiskie · Snapper · Btrfs tools · Power Profiles Daemon |
| Omarchy integration →2 components | Omarchy connects upstream tools through presets, menus and its own applications. | Omarchy Neovim configuration · Omasnap |
Learn through a real task
Section titled “Learn through a real task”For an entity-level learning route, start with Hyprland: compositor, runtime inspection and personal configuration or Quickshell: host, plugins and an independent QML exercise. The layer pages retain the complete catalogued component list; these guides add specific tasks rather than a second inventory.
- Connect to Wi-Fi: the desktop network panel is the interface; NetworkManager manages connections. Start with the Wi-Fi guide, then inspect the component.
- Fix a Bluetooth headset: BlueZ handles Bluetooth; PipeWire processes audio; WirePlumber manages routing and policy. Follow the audio and Bluetooth guide.
- Customize the desktop: Hyprland handles windows; the Quickshell-based Omarchy shell draws the bar and panels. Their configuration files have different jobs. Start with your first change.
- Understand Chinese input: Fcitx 5 is the framework; Chinese Addons supplies engines. Having a package installed is not the same as selecting an input method. See the input guide.
Read the catalogue correctly
Section titled “Read the catalogue correctly”This first edition documents 40 components and indexes every unique package named in five official manifest files at the linked commit. It does not enumerate all transitive dependencies, every optional menu installer or all historical components. The quattro snapshot is a source baseline, not a release compatibility claim.
“Core manifest” means listed in the base manifest, with architecture exceptions possible. “Other install candidates” is deliberately broader than “optional”: the source mixes system packages, hardware drivers and optional installs. The package index preserves the original file memberships.
Detail links marked Learn together describe useful relationships, not package dependencies. Inspection commands only read local package metadata. Check your installed version before copying configuration from a different Omarchy generation.
Configuration ownership: your overrides belong in ~/.config; /usr/share/omarchy contains managed defaults. See the official dotfiles documentation.
A useful learning exercise
Section titled “A useful learning exercise”Pick one task, such as connecting a headset. List the user-facing action, the controlling service, the relevant application setting and the expected result. Follow the related components from the map; read the purpose and inspection sections before changing configuration.
Then describe the failure boundary in one sentence: “pairing succeeds, speaker playback works, but this application records from the laptop microphone.” That description points to a narrower investigation than reinstalling the complete audio stack. Apply the same method to windows, input and networking.
For the broader introduction, read What is Omarchy?. For investigation rather than architecture study, use hardware and connectivity. The map explains ownership; the task guides explain how to prove the outcome.