Aurora immutable KDE Plasma workstation: Big, slow, and confusing

Based on Universal Blue, it's akin to Fedora Kinoite with knobs on… A lot of knobs

Aurora, a relatively young distro from Austria, bills itself as "your stable, privacy-respecting and ultimate productivity OS." These are rather bold claims, though many other Linux distros make the same promise.

The upstart distro is based on Universal Blue images built from the core technologies of Fedora Atomic. That means that the components are from Fedora, but deployed in an immutable form, with most of the filesystem read-only, and updates to the OS itself managed by OSTree. Universal Blue is the basis of a few other distros, including the gaming-focused Bazzite and the developer-oriented Bluefin.

Sign in to sound off

Register for The Register's Forums here.

There already is an immutable KDE-based Fedora called Kinoite, which The Register looked at way back in 2021. Kinoite sticks very close to its roots, though: it's the immutable Fedora Atomic, with a largely stock version of KDE Plasma and the default apps, plus Toolbx for container-based development.

KDE's Info Centre tells us this is based on Kinoite 42 with August's Plasma 6.4.4 - Click to enlarge

Aurora customizes this shared base, adding and replacing many stock KDE tools. Although the main project website is very shiny, it's a little scant on technical detail – but the documentation page makes up for that. It tells us that Aurora pre-installs more media codecs, has drivers for additional hardware, and replaces multiple stock KDE apps – for instance, it uses the Bazaar app store (as well as KDE's own Discover), the Ptyxis terminal emulator, and the Starship shell prompt. As well as the two app stores, there's also Warehouse for Flatpak management, and if that's not enough, it also includes the Linux version of the macOS Homebrew package manager.

Immutable distros prevent experienced users from installing OS packages in the normal way, so Aurora provides Distrobox, which we looked at a while ago, to provide a choice of familiar Linux environments running in containers, with the DistroShelf GUI wrapper to make it easier. At command-line level, there's also a special ujust command for enabling extra features and changing system settings. Between Flatpak, Homebrew, and running a conventional non-immutable distro in a container, there should be a way to run pretty much any Linux app from any distro on Aurora – if you can work out how.

There's a lot here, and that means that Aurora is pretty big. The installer ISO is a 6.8 GB download, and once installed in VMware, it took 14 GB of the default 20 GB virtual drive. At idle from a fresh boot, it takes 1.5 GB of RAM. KDE Plasma 6 is nowhere near as svelte as Plasma 5 ended up becoming later in life.

There's an awful lot in Aurora, and if that's not enough, there's also a separate mode for developers called Aurora-DX, which can be installed on top of the base OS.

Does not play well with others

Aurora is also not very friendly towards multi-booting with other OSes. The main page does warn that Aurora is incompatible with Reg FOSS fest fave Ventoy, so we grumbled and found a fresh key. The resulting key failed to boot at all on an elderly ThinkPad T420 configured for legacy BIOS startup. It wasn't a problem with the key, as it booted successfully on the UEFI-boot ThinkPad W520 and Dell XPS on which we tried the Pop!_OS beta. However, on both of these, it then failed to install with an error about OSTree deployment.

Gracefully handling multi-boot has long been a problem with the Fedora family, and in the distant past, when this vulture worked for Red Hat, he opened a bug about it – only to have it closed WONTFIX, with a statement that Fedora only supports dual-booting with a single copy of Windows and nothing else. For us, it makes a distro much less desirable if it's significantly less flexible in how you can install it.

We've been experimenting with Aurora for a while, so our installer is a few weeks old. As such, it's not a fresh copy, and so we don't blame it when on a clean installation, Discover found 3.3 GB of updates. What we found odd, though, was that when we clicked the Update all button, that grew to 4.9 GB, and then as installation progressed, 7.8 GB. We also found it quite slow: slow to boot, slow to update, and rather sluggish and unresponsive in both VirtualBox and VMware.

Aurora uses the KDE Discover app store to manage updates… and there are a lot of them. - Click to enlarge

By default, Aurora installs onto Btrfs, just like Fedora. The website talks about its simplicity and robustness, but in our extensive experience, Btrfs is not a robust filesystem, and if something goes wrong, having a single fragile root volume makes the OS less robust rather than more.

OSTree is also a weakness here. It's a very clever tool for managing OS images in a similar way to how the notoriously complex Git manages source code, but this is only necessary because Red Hat doesn't officially support a filesystem with COW snapshots. Btrfs can do that, and distros such as openSUSE, SLE, siduction, Spiral Linux, and Garuda Linux all support this. Fedora doesn't, we suspect because it's the upstream for RHEL, and RHEL doesn't support Btrfs. Instead, OSTree does some complex file management under the covers and out of sight: what the user sees isn't the real filesystem, which is a local read-only repository. Instead, it synthesizes a virtual filesystem that looks like a conventional Linux layout.

In our humble opinion, adopting such complex tools to overcome management decisions is technologically inelegant in the extreme, and it throws grave doubt on any claims of robustness and reliability. As Professor Tony Hoare put it [PDF]:

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

The OSTree route puts us in mind of the latter. It's just as complex as the Nix filesystem layout, but at least Nix lets you see that – if you can't understand it, it's your problem. The optimal answer to an overcomplex design is not to conceal the complexity: it's to find ways to eliminate it.

We found Aurora rather overwhelming. Inconsistent UI between apps is a problem for KDE in recent years anyway: some KDE apps have conventional menu bars, title bars, and toolbars, while other KDE apps have client-side decorations and hamburger menus. Some apps have version numbers, some have version dates instead. Presumably, this doesn't bother habitual KDE users, but it irritates us.

Aurora further complicates this by replacing some KDE apps with GNOME ones, and it has a lot of duplication, such as three graphical app-management tools, and containers to imitate other distros, and two new command-line installers. We found ourselves hunting around to work out where menus were, and unsure if we were using the right tools for what we needed. It reminds us of the Oreon Lime distro: there are some good concepts here, but the developers haven't decided exactly who they are trying to target and how to do it. The result is a big, slow, confusing distribution, that's trying to cover multiple different roles at once. ®