Ryoku: An opinionated Arch workstation with a QML shell
Opinionated premium Arch workstation for powerful desktops and laptops.
At a glance
- What is it?
- Ryoku is an Arch Linux distribution that combines Hyprland or niri, a Quickshell-based QML desktop, a guided installer, and its reproducible system definition in one repository. It is aimed at users who want a complete graphical workstation on capable x86_64 hardware, not a lightweight distribution or a dotfile layer.
- Who is it for?
- Ryoku suits users who want to replace their operating system with a complete Arch-based desktop and accept its hardware and Wayland constraints. It is a poor fit for low-resource systems, users who need broad hardware coverage, or anyone seeking only a configurable window manager.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly QML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 15, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why Ryoku installs an entire Arch workstation
Ryoku addresses people who want a coherent Linux desktop rather than an Arch installation assembled from separate configuration repositories. The distribution includes the bootloader, drivers, packages, installer, and desktop environment. Its repository acts as the system source, while an installed machine is treated as a deployment target.
The intended audience is explicit: users with capable desktops and laptops who accept an opinionated environment. Ryoku is not aimed at older or low-resource computers, and it is not a shell or dotfile collection for adding to an existing distribution. Its Hyprland and niri sessions, Quickshell desktop, guided installation flow, update tooling, and signed package repository form one operating-system product.
That choice creates a clear boundary. A user who only wants a bar, notification daemon, wallpaper, and keybindings may find Ryoku unnecessarily broad. A user who does not want to assemble and maintain those parts independently may value the integrated definition. The trade-off is control: Ryoku makes product-level decisions, but its repository does not present every desktop choice as an independent installation topic.
Ryoku's Hyprland, niri, and Quickshell desktop stack
Ryoku supports two Wayland compositors, Hyprland and niri, with its own configuration in each compositor's native format. On top of that layer sits the Ryoku shell, implemented primarily in QML through Quickshell. The shell supplies the visible desktop surfaces, including the bar, dock, launcher, control rail, lockscreen, and session controls.
The shell is designed as a set of independent surfaces rather than a collection of unrelated panels. Its frame-blob rendering and some animation curves are adapted from Caelestia, according to the README. This is attribution for specific implementation details, not a claim that Ryoku depends on Caelestia as its desktop framework. The shell is described as custom, and its visual behavior includes wallpaper-based retinting across the bar, widgets, and frame.
The launcher combines applications, commands, files, packages, radio, a calculator, and wallpaper art behind one search surface. The control sidebar groups session actions, connectivity, sound, brightness, media, calendar information, and power profiles. On first login, a welcome flow introduces keybindings and offers immediate choices for interface scale, bar placement, and desktop widgets. Later configuration is entered through Ryoku Settings using the documented shortcut `Super + ,`.
How Ryoku's repository becomes an installed system
The repository is divided into four functional areas. `ryoku/` contains the desktop, including compositor configuration, the Quickshell shell, lockscreen, application configurations, and brand assets. `system/` defines the boot chain, hardware policy, and package sets. `installation/` contains the guided TUI, its backend, and the archiso profile used to build the signed installation image. `release/` holds the `ryoku` control CLI, desktop packages, and signed `[ryoku]` pacman repository.
This layout makes the distribution definition inspectable in one place. It also means that installation is not a separate post-install configuration project. Ryoku builds an ISO from its own archiso profile, and that ISO is used to write the operating system to disk. The bootloader, hardware policy, packages, installer, and graphical session are all part of the definition.
Ryoku's history adds context but should not be mistaken for its architecture. The alpha series was a fork of Omarchy. From the beta series onward, the tree was rebuilt from an empty root. The README states that the current installer, shell, theming, tooling, and system definition are Ryoku-specific and that the current codebase shares no code with Omarchy.
Downloading the ISO and completing the first login
Ryoku does not document a package-manager or shell installation procedure. Installation begins by obtaining the project's ISO from the download page at `https://ryoku.dev`. The README identifies this as a disk installation rather than a layer placed on an existing Linux distribution.
Before attempting installation, check the two explicit platform constraints. Ryoku is limited to `x86_64` and requires UEFI boot. Its graphical session requires Wayland through Hyprland or niri, plus a GPU capable of compositing the Ryoku shell. The available documentation excerpt ends while describing a condition under which the installer refuses to proceed, so it does not provide the complete hardware checklist or the exact sequence of prompts.
Once the documented installation flow has written Ryoku to the target disk and the machine reaches its first login, the README states that a short welcome experience appears. It presents the keybindings used to open most desktop functions and allows selection of interface scale, bar configuration, and visible desktop widgets. This is the first clearly documented checkpoint after installation.
Ryoku's update path and release-channel trade-off
The `release/` area makes updates part of the operating-system definition rather than an unrelated collection of dotfile repositories. It contains desktop packages, the `ryoku` control CLI, and a signed `[ryoku]` pacman repository. The README does not provide the CLI's command syntax, so update invocation and rollback behavior cannot be confirmed from the available documentation.
Release naming indicates a project with multiple lines of change. Published artifacts include `Ryoku 0.75.3-beta.20 (Ryoku Onogoro 0.75.3-beta.20)` from 2026-09-26 and an `unstable` release, `Ryoku 0.100.5-beta.20 (unstable)`, from 2026-10-15. These labels matter to adoption because beta and unstable releases are not presented as conventional stable Arch releases.
The repository is not archived, and its last push was on 2026-10-15. That fact supports recent development, but it does not guarantee compatibility or support for a particular machine. The README also says Ryoku is led by one maintainer in spare time, with no company or full-time engineering team. Maintenance and upgrade cost therefore include accepting an opinionated beta system maintained within a community project's available capacity.
Hardware scope, licensing, and the case against Ryoku
Ryoku is a poor fit where its platform assumptions collide with the machine. It does not support non-`x86_64` hardware, requires UEFI, and assumes a GPU-composited Wayland session. It is also explicitly unsuitable as a lightweight distribution for older or resource-constrained systems. The truncated hardware-policy section means further exclusions cannot be listed responsibly.
The real alternative is an existing Arch Linux installation configured directly for Hyprland or niri. That approach separates the base operating system from the desktop and lets the user manage compositor, shell, lockscreen, applications, and updates as individual concerns. Ryoku instead treats those parts as one reproducible workstation definition. The choice is between an integrated opinionated product and a more modular, user-assembled Arch setup, not between two identical themes.
Ryoku is licensed under GPL-3.0. That matters when studying, modifying, or redistributing covered code, subject to the license's actual terms. The repository also contains `NOTICE`, `SECURITY.md`, and contribution files, but the available text does not state how Ryoku handles third-party component licenses in a particular installation. The GPL designation alone should not be treated as a complete compliance analysis for every bundled package.
Editorial conclusion
Ryoku suits users who want to replace their operating system with a complete Arch-based desktop and accept its hardware and Wayland constraints. It is a poor fit for low-resource systems, users who need broad hardware coverage, or anyone seeking only a configurable window manager. Verify x86_64 support, UEFI boot, GPU compatibility, and the installer behavior on the target machine before replacing an existing installation.
Frequently asked questions
How do I install Ryoku on a computer?
Download the ISO from `https://ryoku.dev` and use Ryoku's guided disk installer. The machine must be `x86_64`, boot in UEFI mode, and support a GPU-composited Wayland session.
Does Ryoku run on Hyprland and niri?
Yes. Ryoku provides a Wayland session for either Hyprland or niri, with compositor configuration in each project's native format and the Quickshell-based Ryoku shell above it.
Is Ryoku suitable for an old or low-resource PC?
No. The README explicitly says Ryoku is designed for capable desktops and laptops, not as a lightweight distribution for older or low-resource machines.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/ryoku-dev-ryoku)