On June 27, 2026, we published the article that introduced Linxira OS. That post described a prototype built on Linux Mint — today the situation is completely different. Linxira is now a Direct Arch workstation built directly on Arch Linux, and the first experimental stable release is out. This article supersedes that post's description of the current state and is the authoritative version of where the project stands; the old post remains as a historical record.
Early Linxira sat on top of Linux Mint (the Ubuntu LTS ecosystem), hoping a stable distribution layer would carry the preinstalled software and first-party tools. The problem with that direction: what we actually needed was not another Ubuntu derivative, but full control over upstream updates and the software supply chain. Linux Mint's release cadence and Ubuntu LTS's version cycle meant Linxira software would always wait for the distribution layer to coordinate.
So we switched to the Direct Arch route: built directly on Arch Linux, using pacman and the official Arch repositories, with no distribution layer stacked on top. Arch is a rolling-release distribution — upstream updates (including security fixes) land in its repositories as soon as they are published, with no release-cycle coordination. Linxira's own software ships through an independent repository that the project controls and signs. The documentation home states it plainly: "Linxira is a Direct Arch workstation, using pacman and the official Arch repositories." The decision turned Linxira from "a distribution with tools" into "a workstation whose software chain we fully control."
The immediate payoff is architectural simplicity: no stacked distribution layer, no version conflicts from below, and every component coming from either the official Arch repositories or our signed, reviewed repository. What users get is Arch — plus a reviewed set of preinstalled software and first-party tools on top.
The Mint prototype years also left something valuable behind: the criteria for choosing preinstalled software, the idea of organizing software in layers, and the insistence on "works out of the box". What we abandoned is the distribution layer, not those lessons — they survive in a different carrier: the preinstalled software list is now driven by a reviewed catalog instead of being hardcoded into a distribution's package set. A side benefit is that Arch Wiki applies directly: because Linxira is built on Arch, the enormous body of documentation, tutorials, and troubleshooting accumulated by the Arch community works for Linxira users verbatim, with no "distribution-specific wording" to translate.
Linxira is now positioned as a Desktop Supercomputer: it keeps full regular desktop functionality, adds a headless scientific-computing mode, and reproduces other people's environments losslessly in containers — while letting others reproduce ours. First and foremost it is a desktop computer that works out of the box: KDE Plasma, browser, office software, Chinese input. At the same time it is a scientific-computing workstation that can handle training, containers, and remote computation.
For most users, the simplest way to think about it comes from the beginner's guide: treat it as "a Linux computer with research software preconfigured." You do not need to understand distribution concepts; it is usable right after installation. When every megabyte of RAM needs to go to a compute job, headless mode turns the desktop off with one command; when you need to reproduce someone's research environment, the container ecosystem (Podman, Distrobox, Apptainer, Docker) is available by default, so the host's rolling updates never pollute a pinned project environment.
The key to this positioning is "both, not either-or": everyday desktop use and scientific computing are not mutually exclusive. Nothing in the design cripples the system for "server" or "desktop" duty — both use cases share the same install and update mechanisms.
It also answers "who is it for": researchers and scientists (bioinformatics, physics and chemistry, paper writing with LaTeX), developers (full-stack, Rust/Go/Node.js/Python, AI/ML engineers running CUDA and local models), and students (undergraduates and graduates who want to learn Linux or need a well-configured research environment). What these people share is a pain point — setting up a usable research computer takes a lot of time — and Linxira's goal is to compress that time into "installed and usable".
Linxira's software ecosystem is organized around a single reviewed catalog: 93 curated applications across 14 categories, vetted through catalog v3's review — license, source, and availability checked item by item. Scientific-computing and gaming software is installed by default in the stable release, while the external ecosystem (AUR and similar) is off by default and must be enabled explicitly by the user.
All first-party software is hosted in the official signed repository [linxira] (https://linxira-os.github.io/linxira-packages/x86_64), with both database and package signatures enforced on the pacman side. Unreviewed AUR recipes are never presented as official software; we would rather ship a smaller catalog than put unreviewed sources into the default recommendations.
The catalog is not a static checklist — it is the single metadata source consumed by the installer, the welcome screen, and graphical package management. That architecture is covered in a dedicated article later in this series. For users, the effect is simple: what the installer offers, what the welcome screen recommends, and what the software manager shows are the same reviewed set of applications — no competing lists.
"Reviewed" is not a slogan; it has three concrete dimensions: license (can it be distributed with Linxira), source (official repository or third party, reproducible or not), and availability (actually usable on the current architecture and baseline). All 93 applications pass these three checks before entering the catalog; every application in it corresponds to a responsible, traceable decision rather than a "install it and see" guess.
Around this ecosystem we have built 17 first-party tools, guided by three design principles: reviewed catalog metadata (software lists are driven by a human-reviewed catalog), deterministic transactional backends (system changes go through controlled backends executing deterministic transactions), and read-only / planning safety model (interfaces only display and plan; writes are centralized and confirmable).
The ones most relevant to daily use: Linxira Welcome is the Plasma-native status and routing hub, opens automatically at boot, and displays the catalog and install receipt read-only; Config Hub (linxira-config) is the administrator CLI for SSH, mirrors, network diagnostics, and security status; Shelly is the default graphical software manager after install (CLI + GTK + update notifications) and only performs approved package operations — it never participates in installer transactions; Package Center offers category-tree installation of curated applications with a plan / confirm / apply three-step transaction; Component Manager handles capability packages, runtimes, and toolchains with a three-state selection (required / recommended / optional).
Underneath sit lhwd (hardware detection and driver configuration, a Rust implementation of the complete CHWD port) and linxira-update (update notifications and maintenance assistant, which creates a Timeshift snapshot before updates by default). All 17 tools share one safety model: interfaces never touch the system directly, and system modifications always go through deterministic, confirmable transactions.
Each of the three principles lands somewhere concrete: "reviewed catalog metadata" means the Welcome recommendations and the software manager's category tree come from the same human-reviewed catalog rather than separately hardcoded lists; "deterministic transactional backend" means every system modification is planned first, executed second, and recorded — the same plan always produces the same result; "read-only / planning safety model" means no graphical interface has the power to run arbitrary commands — it can only submit a plan, and the backend decides and executes. For users the effect is that installing software behaves identically and predictably from every entry point.
On August 14, 2026, Linxira released its first experimental stable (linxira-2026.08.14-x86_64.iso). This release passed a complete installation test — first-party software installed with zero errors, and the signed repository worked. The ISO is available on the download page, with release details on linxira-iso GitHub Releases.
Note the word "experimental": this is the first public direct-Arch stable release, which means we have proven the full chain from source build to install to daily use — but subsequent versions will keep iterating per the build guide. Verify the ISO's SHA-256 checksum before installing.
The "complete installation test" is not just "does the installer launch": it covers booting the Live environment, Calamares partitioning and install, first entry into the installed system, and first-party software installation and signed-repository updates along the whole chain, with the conclusion that first-party software installed with zero errors and the signed repository worked. That is why this is an "experimental stable" rather than another "beta" — the chain is fully walked; what remains is covering more hardware and use cases, which real-user feedback drives.
This is the biggest difference from the June introduction post: back then "no public direct-Arch ISO was available"; now it can be downloaded, installed, and used.
Public information going forward lives on two pages: the roadmap describes what we plan to do, and the release log records every published ISO build. Release cadence, build methods, and how to build your own ISO are covered in the building guide.
This post is the "state of the union" — it answers "what is it now." The "why it is designed this way" questions are covered one by one by the technical articles in this series: signed repositories and supply-chain security, the reviewed catalog, btrfs snapshot rollback, headless mode, the AI toolchain, and the beginner's guide design. If you only care about downloading, head straight to the download page.
One usage suggestion to close with: after installation, walk through the quick start guide to enable the signed repository and update the system, then install software as needed; when something goes wrong, start with the FAQ. The system update model is rolling, and paired with btrfs snapshot rollback, daily maintenance is no heavier than on a fixed-release distribution — which is one of the most worth-experiencing parts of the current state.