SakuraOS Blog
Release

SakuraOS 1.0 Cherry Blossom

Arch Linux with the parts that usually take a weekend already decided, and a way back when an update goes wrong.

SakuraOS 1.0 is here. It is Arch underneath, with KDE Plasma on the desktop, a kernel chosen by what your processor actually supports, and four applications built specifically for it. Installing it does not ask you to pick a bootloader or compare filesystems.

This first release is about one idea. Arch has the best software model in Linux, and the worst recovery story. We kept the first and fixed the second.

A way back that does not need a live USB

A restore point is taken before every package transaction. Not nightly, not on a schedule you configure: before each one, so the state you can return to is the state you were in a second earlier.

If an update leaves the machine unable to start, you do not need to know what a chroot is. After three failed starts the recovery environment opens by itself, lists the restore points in plain language, and puts the system back when you pick one. Your home directory is on a separate subvolume and is not touched either way.

The SakuraOS recovery screen listing restore points to go back to
Recovery, started by the machine itself after three failed boots.

The rollback keeps what it replaced rather than deleting it, so changing your mind is possible in both directions. On an encrypted install it asks for your passphrase first, then behaves identically.

Updates that were installed somewhere else first

Every night, a machine is installed from scratch, the day's Arch updates are applied to it, it is restarted, and forty-four checks are run against what comes back. Anything that breaks it is held back from you, with the reason attached. Everything else arrives at Arch speed, because holding packages back on a schedule is how a rolling release stops being one.

This is not a promise about a future version. The canary runs nightly now, and what it publishes is what your machine reads before it applies anything.

The terminal, without the cliff

Immutable distributions have real advantages, and a real cost: eventually you need to do something the system will not let you do. SakuraOS stays fully writable, and puts a little over thirty rules in front of the commands known to break an Arch install.

The important ones run inside pacman itself, so they apply whether the operation started in a terminal, a script, yay, or the App Store. When a rule stops something it explains why, shows the safer form, and prints the exact override. It can be set to warn instead of block, or turned off entirely, in Settings.

The AUR, with the scary part handled

The AUR is off on a fresh install, because it is build scripts written by other users that nobody reviews. Turning it on is one switch in Settings.

Once it is on, two things happen that do not happen elsewhere. Everything you have installed is checked against every published AUR attack campaign, from inside pacman, after every install and upgrade. And before a package builds you see the script, what changed since the version you last accepted, and the signals that matter: a maintainer who changed last week, a package adopted three days ago, a download that is not coming from the project.

What is in the box

The kernel is chosen by probing whether your processor supports x86-64-v3. If it does you get the tuned CachyOS build; if it does not you get the standard one, and nothing about the install changes. Both ship on the same image.

Getting it

One image, x86_64, about 3.2 GB. There is no edition to choose between. Everything above is on the media, so an install works with the cable out, including a browser.

The wiki describes what each part does and how to change it. Bugs and questions are welcome on r/SakuraOS.