Author: Thom Holwerda
Source
The openSUSE project recently announced the second release candidate (RC2) of its Aeon Desktop, formerly known as MicroOS Desktop GNOME. Aside from the new coat of naming paint, Aeon breaks ground in a few other ways by dabbling with technologies not found in other openSUSE releases. The goal for Aeon is to provide automated system updates using snapshots that can be applied atomically, removing the burden of system maintenance for “lazy developers” who want to focus on their work rather than desktop administration. System-tinkerers need not apply. The idea behind Aeon, as with other immutable (or image-based) Linux distributions, is to provide the core of the distribution as a read-only image or filesystem that is updated atomically and can be rolled back if needed. Google’s ChromeOS was the first popular Linux-based desktop operating system to follow this model. Since the release of ChromeOS a number of interesting immutable implementations have cropped up, such as Fedora Silverblue, Project Bluefin (covered here in December 2023), openSUSE’s MicroOS (covered here in March 2023), and Ubuntu Core. ↫ Joe Brockmeier at LWN With the amount of attention immutable Linux desktops are getting, and how much work and experimentation that’s going into them, I’m getting the feeling that sooner or later all of the major, popular desktop Linux distributions will be going this route. Depending on implementation details, I actually like the concept of a defined base system that’s just an image that can be replaced easily using btrfs snapshots or something like that, while all the user’s files and customisations are kept elsewhere. It makes intuitive sense. Where the current crop of immutable Linux desktops fall flat for me is their reliance on (usually) Flatpak. You know how there’s people who hate systemd and/or Wayland just a little too much, to the point it gets a little weird and worrying? That’s me whenever I have to deal with Flatpaks. Every experience I have with Flatpaks is riddled with trouble for me. Even though I’m a KDE user, I’m currently testing out the latest GNOME release on my workstation (the one that I used to conclude Windows is simply not ready for the desktop), using Fedora of course, and on GNOME I use the Mastodon application Tuba. While I mostly write in English, I do occasionally write in Dutch, too, and would love for the spell check feature to work in my native tongue, too, instead of just in English. However, despite having all possible Dutch dictionaries installed – hunspell, aspell – and despite those dictionaries being picked up everywhere else in GNOME, Tuba only showed me a long list of variants of English. After digging around to find out why this was happening, it took me far longer than I care to publicly admit to realise that since the latest version of Tuba is only really available as a Flatpak on Fedora, my problem probably had something to do with that – and it turns out I was right: Flatpak applications do not use the system-wide installed spellcheck dictionaries like normal applications do. This eventually led me to this article by Daniel Aleksandersen, where he details what you need to do in order to add spellcheck dictionaries to Flatpak applications. You need to run the following commands: The list of languages uses two-letter codes only, and the first language listed will serve as the display language for Flatpak applications, while the rest will be fallback languages – which happens to include downloading and installing the Flatpak-specific copies of the spellcheck libraries. Sadly, this method is not particularly granular. Since it only accepts the two-letter codes, you can’t, say, only install “nl-nl”; you’ll be getting “nl-be” as well. In the case of a widely spoken language like English, this means a massive list of 18 different varieties of English. The resulting menus are… Not elegant. This is just an example, but using Flatpak, you’ll run into all kinds of issues like this, that then have to be solved by hacks or obscure terminal commands – not exactly the user-friendly image Flatpak is trying to convey to the world. This particular issue might not matter to the probably overwhelming English-speaking majority of Flatpak developers, but for anyone who has to deal with multiple languages on a daily basis – which is a massive number of people, probably well over 50% of computer users – having to mess around with obscure terminal commands hidden in blog posts just to be able to use the languages they use every day is terrible design on a multitude of levels, and will outright make Flatpak applications unusable for large numbers of people. Whenever I run into these Flatpak problems, it makes it clear to me that Flatpak is designed not by users, for users – but by developers, for developers. I can totally understand and see why Flatpak is appealing to developers, but as a user, they bring me nothing but grief, issues, and weird bugs that all seem to stem from being made to make developers’ lives easier, instead of users’. If immutable Linux distributions are really hellbent on using Flatpak as the the means of application installation – and it seams like they are – it will mean a massive regression in functionality, usability, and discoverability for users, and as long as Flatpak remains as broken and badly designed as it is, I really see no reason to recommend an immutable Linux desktop to anyone but the really curious among us.
