matrixOS: Fabio Erculiani’s third distro, and the caveat he put in the announcement

The person who shipped a Gentoo live DVD from this address in 2005 is shipping a Gentoo OS image in 2026. It is immutable, atomic, built on OSTree, aimed at gaming, and — according to the section of its own README marked with a warning sign — not a thing you should run on anything that matters. That warning went into the first public commit and has never come out, although it has been rewritten since, and the rewrite is worth reading too. It is also the most useful sentence anybody has written about matrixOS, so this piece starts there and then asks the question the project is actually a test of: can a distribution be immutable and source-based at the same time?

matrixOS · Shipping · Verified 2026-08-04

The disclaimer was in the first commit, not added after the coverage

2026·01·31The lxnay/matrixos repository was created at 17:02:58 UTC on 31 January 2026 and its first commit landed at 18:04:12 +0100. That commit already carried the section every reader should be given first — and it was warmer then than it is now:

That is not the sentence you will find there today, and the difference is the sort of thing an article about somebody’s own caveat has to get right. The disclaimer was rewritten twice on the evening of 14 February 2026: first at 18:10 into a blunter draft opening “matrixOS is a hobby project. Do not take it too seriously.”, then at 18:39 into the compressed version that has stood unchanged ever since:

What was cut in that rewrite was the joke and the apology, not the warning. Every version of the section since the first commit has said the same three things — hobby, homelab, not for production — and the “AS IS” / “NO WARRANTY” sentence has been there throughout. The one editorial fact worth noting is the direction of travel: three days after the largest piece of coverage ran, the author made his own disclaimer shorter and harder, not softer.

This matters because of the order things happened in. Phoronix carried the project on 11 February 2026 — by its own account, Erculiani “wrote in to Phoronix today to announce” it — under a headline about Sabayon’s creator building an immutable Gentoo. That item quoted the project’s self-description, listed the features (Mesa, NVIDIA, the NTFS driver, Btrfs with zstd, x86-64-v3) and does not contain the words “hobby” or “production” anywhere. It’s FOSS followed on 17 February and did carry the caveat, in a marked callout immediately after its introduction. So the honest characterisation is not that everyone buried it: the largest single piece of coverage omitted it, the piece a week later led with it, and the disclaimer itself had been sitting in the repository for eleven days before either ran.

Correction, 2026-08-04. An earlier piece on this site, The five candidates for “Sabayon in 2026”, said “every write-up of matrixOS this year led with the features”. That was too broad, and this research is what falsified it. That sentence has been changed and the change is logged on Corrections.

One more detail from the same fortnight, because it tells you how fast the project was moving. The description Phoronix quoted ended with the parenthetical “yes bootc will come”. That parenthetical was removed at 18:00:54 on 14 February 2026, in a commit whose message says exactly why: Remove unnecessary mention of bootc in the README description. It is the first of the three commits in that forty-minute session — description, then disambiguation, then the compressed disclaimer — which together are the project tidying up its own front page three days after the first wave of readers arrived. The intention did not disappear — it moved to an unticked box on the roadmap, where it still is.

What matrixOS is, in the shape of what it publishes

matrixOS ships no numbered releases. It publishes dated images and an OSTree repository, and the OSTree repository is the actual product: the images exist to get you a first deployment, after which sudo vector upgrade pulls commits. On 4 August 2026 the image index at images.matrixos.org listed 65 entries: a four-line LATEST pointer, and 64 artifacts making up four system variants at two build dates each. Each of those eight builds ships two images — an xz-compressed raw image to flash and a qcow2 to boot in a VM — each image with its own .sha256 and its own detached .asc signature, and each build with one copy of the signing public key and one full package manifest.

Two things in that table are worth saying out loud. The README’s desktop list has two rows, GNOME and COSMIC; the published index has four families, because bedrock and server ship as bootable images too. And every branch name contains dev. The release tooling defines two stages, dev and prod, and on 4 August 2026 the OSTree summary at ostree.matrixos.org advertised eight refs, all of them dev: the four above and a -full variant of each. There is no stable channel yet. That is not a criticism of a project that told you it was a hobby; it is the single most load-bearing fact about what you are subscribing to.

The GNOME manifest for 27 July 2026 gives the software floor without anyone having to boot it: kernel 7.1.5 (packaged in the project’s own overlay as sys-kernel/matrixos-kernel), Mesa 26.1.4, nvidia-drivers 610.43.03, GNOME Shell 49.7, systemd 260.1, glibc 2.43, GCC 15.3.0, Portage 3.0.81.2, OSTree 2025.7, btrfs-progs 7.0 — Gentoo revision suffixes elided, and three of those are revised builds rather than plain upstream releases (systemd-260.1-r2, glibc-2.43-r2, ostree-2025.7-r4) — and for gaming steam-launcher, lutris and gamescope. Flatpak, snapd, Docker and distrobox are all in the manifest too, which matters later in this piece. It is a current desktop, not a demo. On disk it is btrfs with zstd compression, auto-resizing on first boot — except for /boot, which on anything built since 1 June 2026 is vfat, a change the README’s feature list has not caught up with.

The signing is real and checkable without downloading anything large. The README names a GPG fingerprint; the images ship the corresponding public key beside each signature. I imported the published key and compared:

ReasoningA key shipped beside the signature it verifies proves only that the pair is self-consistent. What makes it worth something is that the same fingerprint is published in a second place, over HTTPS, on a host the project does not run — and that the OSTree remote’s served configuration sets gpg-verify=true. Two independent channels for one fingerprint is the whole trust model, and it is more verification metadata than several funded distributions ship.

The hardware gates are absolute and easy to miss. matrixOS requires an x86-64-v3 CPU, and the README’s callout states the consequence flatly: older hardware will fail to boot. The same callout gives the floor as “AVX2 + FMA — Intel Haswell 2013+ or AMD Ryzen 1000+ series”; that is the project’s shorthand for buyers rather than the exact instruction-set boundary, and I repeat it as its claim rather than mine. It wants 32 GB of storage and recommends 64. And the shipped credentials are documented in public: root and a matrix user both with the password matrix, plus a LUKS passphrase of MatrixOS2026Enc on encrypted builds. The README tells you to fix that with sudo vector setupOS before the machine sees a network. Both the CPU callout and the credentials warning were contributed by an outside contributor, chrisdebian, in a documentation pull request merged on 8 May 2026 — before that, both facts were true but not flagged.

The build runs twice, and what happens between the two commits is the design

The toolkit has three stages — Seeder, Releaser, Imager — the same instinct that produced Molecule, the spec-driven ISO builder Sabayon shipped, rebuilt for a different artifact. Seeder starts from an official Gentoo stage3 (the systemd one, so matrixOS is a systemd distribution) and builds four chroots in layers: 00-bedrock, then 10-server, 20-gnome and 21-cosmic on top of it. Its configured cadence is weekly. All four layers are compiled with identical compiler settings; the USE flags are not one line but a set of named groups, and those do differ by layer:

# build/seeders/20-gnome/portage/make.conf, read 2026-08-04
COMMON_FLAGS="-O2 -pipe -march=x86-64-v3"   # identical in all four layers
PYTHON_TARGETS="python3_14"
VIDEO_CARDS="amdgpu intel nouveau radeon radeonsi virgl"

NOQT_USE="-qt6 -qt5"
SECUREBOOT_USE="modules-sign secureboot"
SYSTEM_USE="abi_x86_32 dbus dist-kernel policykit modules-compress"
SOUND_USE="pipewire-alsa alsa bluetooth bluetooth-sound"
VIDEO_USE="vaapi vdpau virgl opengl X wayland"
SERVER_USE="cups samba zeroconf zstd apparmor"
DESKTOP_USE="flatpak"
USE="${NOQT_USE} ${SECUREBOOT_USE} ${SYSTEM_USE} ${SOUND_USE} ${VIDEO_USE} ${SERVER_USE} ${DESKTOP_USE}"

Four files, three configurations. 21-cosmic’s make.conf is byte-for-byte identical to the GNOME one above. 10-server builds the same groups but with -X -wayland in place of X wayland and no DESKTOP_USE at all, so no flatpak. 00-bedrock does that and also drops cups, and its ACCEPT_LICENSE is the short one — without the three NVIDIA licences the other three layers accept. The compiler configuration is genuinely uniform; the package configuration is layered, which is the point of layering it.

Then Releaser turns a finished chroot into OSTree commits — plural, and this is the part worth reading twice. It commits the whole filesystem to the -full branch first. Then, on the same tree, it runs emerge --depclean --with-bdeps=n --complete-graph, deletes /usr/include, empties /usr/lib/pkgconfig, /usr/src and /var/db/repos, walks /usr removing every .a and .la file it finds, and commits that to the shipping branch, with the full branch as its parent.

Read the list of things deleted and you have the whole architecture. /var/db/repos is the ebuild tree. /usr/include is the headers. What survives is deliberate: the Portage package database is preserved, moved out of /var — which OSTree does not carry between deployments — into a read-only copy at /usr/var-db-pkg, so a matrixOS box always knows exactly what is installed on it even though it cannot change it. The image knows its own bill of materials. It just cannot act on it.

Can a system be immutable and source-based at the same time?

This is the live design question of 2026 and matrixOS is the concrete test of it, so here is the argument rather than a shrug.

Readers arriving from Fedora Silverblue or Bazzite have a mental model that does not transfer. On rpm-ostree, rpm-ostree install layers a package client-side: the tool composes a new filesystem root from the base commit plus your package, and the layering persists across upgrades because it is re-applied to each new base. That works because RPM is a binary format with a client-side dependency solver. Portage is not that. Compiling a package on the client needs the compiler, the headers, the static libraries and the ebuild tree — precisely the mass the Releaser deletes on its way to the shipping commit, and precisely the mass that the project’s own motto — “emerge once, deploy everywhere” — exists to keep off your machine.

So matrixOS does not offer layering. It offers something blunter, in three tiers, and the tiers are honest about their costs.

# tier 1 — unlock the running deployment, transiently
sudo vector readwrite            # ostree admin unlock --transient
sudo vector readwrite --permanent # ostree admin unlock --hotfix
# transient changes are gone at reboot; hotfix changes survive reboot
# and are gone at the next upgrade. Either way, upgrade wins.

# tier 2 — get a toolchain, by switching to the other ref
sudo vector branch remote
sudo vector branch switch matrixos/amd64/dev/gnome-full
# the -full ref is the pre-shrink commit: headers, static libs, tree.

# tier 3 — stop being immutable at all
sudo vector jailbreak
# requires a -full branch and 4 GiB free; asks you to type DESTROYALL;
# clones the deployment onto the physical root, writes /etc/fstab from
# the partition UUIDs, moves /usr/var-db-pkg back to /var/db/pkg, and
# leaves a boot entry called matrixos-jailbroken.conf. One-way.

The README is blunt about tier 1 in a parenthesis most people will skip: run emerge if you like, but “switch to a *-full OSTree branch before doing this”. On the shipping branch there is nothing to emerge with. Portage’s binary is installed and GCC is installed, and neither can do anything useful without the tree and the headers.

ReasoningHere is the answer, then. Immutable and source-based do coexist in matrixOS — but not on one machine at one time. They coexist as two refs in one repository, and moving between them is a reboot, not a command. The interesting consequence is where the tuning went: it did not disappear, it moved off the client and into the build recipe. The USE flags, the -march, the video cards, the accepted licences are all still there, in a git repository you can read in a browser and fork. What you cannot do is hold an opinion about a USE flag on a running matrixOS box. You can hold it in a fork of the build system — for which the documented requirements are an x86-64-v3 CPU, 32 GB of RAM and about 70 GB of disk.

Whether that is a loss depends entirely on which Gentoo user you are. If USE flags were how you shaved a dependency you disliked out of one package, matrixOS has taken that away and given you a machine that boots the same way every time. If USE flags were how you avoided compiling KDE onto a system where you only wanted the libraries, the shipping images already made that decision for you, correctly, and you were never going to change it anyway. The -full ref is the escape hatch, and the ordinary answer for “I need this program” is the one every atomic system gives: Flatpak, Snap, Docker, AppImage or distrobox, all preloaded, all in your home directory, none of them touching the base.

Two limits on the safety net, both from the project’s own configuration. Old commits are garbage-collected after two months, so the rollback window is two months and not “forever”; and the janitor’s image cleaner is configured to keep a documented minimum of two builds in reverse chronological order, which is why on 4 August 2026 the index offered exactly two dates. Atomic rollback protects you from a bad upgrade this week. It does not archive last winter for you.

Twenty years, one idea, three distributions

This is why the piece belongs at this address rather than on a general Linux news site.

2005·11·04By November 2005 — the date of the first capture of this address that is a site rather than a redirect to a machine at home — lxnaydesign.net was the download page for a Gentoo-based live DVD, so that you did not have to compile Gentoo. In 2008 Sabayon shipped Entropy so that you did not have to compile updates either. In 2026 matrixOS ships a signed filesystem image so that you do not have to configure Gentoo. One consistent idea across twenty years and three distributions: somebody else does the expensive part once, and you get the result.

What changed is the unit of delivery, and the change looks like a lesson. Entropy shipped packages: a binary repository built from the same Portage tree, with its own client, its own dependency resolution and its own servers, which somebody had to keep answering for eleven years. matrixOS ships filesystems: a static OSTree repository behind a CDN with no solver in it at all, and the client is a Go binary that mostly calls ostree. The second one is enormously less work to keep alive, and the difference is roughly the difference between a project that needs a team and a project one person can still run in year twenty. My reading of how Sabayon actually ended is that the package layer was the part that cost the most and got the least credit — and it is exactly the part that did not get rebuilt.

The domain history closes the loop: sabayonlinux.org now 301-redirects every path to github.com/lxnay/matrixos, and matrixos.org itself 301-redirects to the same place — the project has no website, only a repository. It is deliberate enough that a workflow in that repository, on an hourly cron, asserts that matrixos.org and www.matrixos.org still answer 301 to the repository, and that the two service subdomains have not been swallowed by the same rule. The sabayonlinux.org redirect is not monitored there; I checked it myself on 4 August 2026. There is also a joke in the README’s disambiguation section, where two unrelated projects called matrixOS are listed and the note reads “We need more entropy in this world!”. Whether the capital-E reading is intended I cannot establish, and I am not going to pretend to.

What would have to be true for this to stop being a hobby project

Not a wishlist — the specific, checkable gaps between what exists on 4 August 2026 and something you could responsibly put under a workload.

A second person. Of the 2,218 commits reachable from the default branch, 2,211 are by Fabio Erculiani, four by a single outside contributor and three by dependabot. The GPG signing key belongs to a single build node and lives in a private repository whose public example is published as a template. This is not a criticism, it is arithmetic, and it is the same arithmetic that ended Sabayon and that Redcore is running today.

A prod ref. The tooling already knows the word: the release stage type accepts dev and prod. Every published ref is dev. Publishing a prod ref would be the moment the project starts making a promise, which is exactly what the disclaimer currently declines to do.

Somebody else’s hardware. The README’s contributing section makes three asks — code, resources, and donations to Gentoo rather than to matrixOS — and the resources line is specific: mirrors for the images and the OSTree repository, and compute power for builds. Whether anyone has answered I cannot tell from outside — no mirror is listed anywhere the project publishes — but every artifact on the index today is signed by the key of one build node, which is the part that can be checked.

A first-boot flow instead of a documented password. Shipping matrix/matrix with a README instruction to change it is fine for a homelab image you flash yourself. It is not fine for anything a stranger installs, and it is the kind of thing an inherited machine keeps for years.

bootc, or a decision not to. The roadmap’s open milestone is migrating off direct OSTree use to bootc with unified kernel images. The project’s own TODO says it is watching an upstream OSTree pull request — ostreedev/ostree#3359, which adds directory-based boot loader support for systemd-boot — as the trampoline to get there. That PR was opened on 19 December 2024 and was still open when I checked it on 4 August 2026, carrying 39 review comments and no merge, its most recent activity dated 29 May 2026. An outside contributor opened a matrixOS issue offering to help with the bootc migration on 16 February 2026; it is still open too. This is the honest shape of a dependency you do not control.

ReasoningAnd a number that should be read carefully rather than dramatically. Monthly commit counts run 8 (January, from the 31st alone), 1,104, 973, 69, 32, 19, 11, and 2 in August to the 3rd. The obvious reading is decline. The likelier reading is that the build-out of an entire distribution toolkit happened in two months and what follows is maintenance. All thirteen commits since 1 July are that shape: masking GNOME 49 and then unmasking it, a kernel USE flag so GDM works with NVIDIA, making systemd-boot default to entry 0 instead of @saved, giving /tmp mode 1777, adding tcpdump and traceroute to every seed, following an upstream removal of bind-tools, and — on the second and third of August — adding unrar and accepting its licence. The four not listed are a GNOME settings-daemon mask fix, a broken-symlink sweep, an update to the stage3 URL and a timing fix in the VM test harness. That is what a working system’s commit log looks like. It is also, unavoidably, what a project going quiet looks like from the outside, and the only way to tell them apart is to look again in six months — which is what the verified date at the top of this page is for.

Who this is actually for

Take the author at his word, because the word is unusually precise. A spare machine newer than 2013, a homelab, a gaming box you can reflash on a Saturday, or a virtual machine — the qcow2 images exist for exactly that and are the cheapest way to look. Not a laptop that has to work on Monday, not a server holding anything, and not the elderly hardware most likely to still be running a dead distribution, because that hardware will not boot it. If what you want is a Sabayon-shaped desktop you install and live in, the comparison piece ranks the five candidates and matrixOS is not the one it recommends. Nothing on this page is sponsored, no link here is an affiliate link, and the Disclosures page says what would change if that ever stopped being true.