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:
$ flatpak config languages --set "en;nl;"
$ sudo flatpak updateThe 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 users1 – 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.
- Even in a country like the United States, which we think of as an English-speaking country, there are currently 42 million Spanish-speaking people, who most likely also have to use English on a daily basis. The way multilingual features are treated as afterthoughts by the tech industry – even the open source one – is baffling. ↩︎
Strange that these immutable Linux announcements don’t mention NixOS, which has zero reliance on Flatpaks.
I’m a writer, an Italian writer, but I like my UI to be en-us. I assume in these kind of distros LibreOffice is a Flat as well? That simply doesn’t work for me. Last night I backed up everything, finally ready to jump ship. Flats on Mint are very easily wiped out (there are actually no Flats installed, just 3 or 4 support packages). Does this apply to Snaps as well? Or should I rather jump two ships and land safely on Debian Sid?
Couldn’t support for multiple language libraries be added to Flatpak?
Couldn’t Flats and Snaps be banned? Like *forever*? Debian, Mint and Asmi, the first .deb distros that come to mind: this World of Choices seems to making all the choices for me. Feels *very* much like Windows. Thanks but no thanks.
I don’t believe in banning any open source project from the public at large. Of course, any distro can decide for themselves what they will and won’t support, and I as an individual can choose what I want to use. I use Void Linux and while it does support Flatpak I don’t use it. The only application I need that Void doesn’t supply in the repos, Pinta, is available as a Flatpak but I prefer to build it myself even though that involves messing around with .NET/mono garbage. It’s worth the extra time and effort to avoid Flatpak’s themeing issues and bloat.
As for Snap, that pile of horse manure can die a lonely painful death as far as I’m concerned. The harder Canonical pushes that trash, the more I dislike it. Their refusal to open source the Snap server speaks volumes, and is one of the reasons I avoid Ubuntu and Ubuntu based distros these days. As much as I like Pop!_OS, until it rebases on Debian or Fedora it’s dead to me.
Morgan,
Some people want their distros to stick to repos. When repos have the right version of software need, it works out well. But I also understand the criticism of centralized repos and why a decentralized medium like flatpak can be important.
I installed OBS studio from debian repos and while it worked, all the plugins for it that I wanted to sideload/use are naturally built against the latest version. Installing the official flatpak managed by the official developers works quite well, much easier than building the project and managing the dependencies myself. I wouldn’t be against building from source if everything just worked, but it gets so tedious and to be honest I’ve just grown tired of dependency hell so if I can find a way to avoid it I will.
I also had a similar experience with VLC. The repo version worked but was outdated. The flatpak version provided an easy path to the latest official version.
All the usual criticisms of flatpak apply, but it still seems to me that many will find the tradeoffs worth it anyway.
Morgan,
I forgot to respond to this, but I agree completely. The stack not being completely open source is extremely unappealing.
Of course support for language support packages can be added. And support for IME. And support for NVDA. And support for sharing files between processes by shoving them in /tmp.
At some point, all parts of the typical Linux desktop are reinvented, usually losing the institutional knowledge encoded in the sources of the previous iteration.
It’s the CADT model (https://www.jwz.org/doc/cadt.html) at work.
Alternatively, Flatpak, Snap et al could just not sandbox what they don’t understand but instead build up their sandbox feature by feature instead of locking everything down and expecting people to complain when it breaks. But that won’t give the folks at IBM or Suse a promotion as quickly, so they won’t.
I personally would be happy if Debian would decide, in addition to software packaged in .deb format, to provide Snap/Flatpak and AppImage packages, at first for the most popular software. On the long run this woudl lead to trust, much less maintenance burden and would additionally strengthen GNU/Linux as a viable desktop operating system option.
I don’t get the Linux world’s love of flatpck. It stupidly inefficient. Monster downloads, tied up bandwidth, and power wastage. Not everyone is on unmetered accounts either. It just doesn’t gel with ideal of lean, efficient computing. I’m very happy with my distro’s packaging endeavours and the only thing they don’t have I compiled myself using the provided instructions.
Shifu,
I get every one of your criticisms, however flatpak kind of exists to work around the critisisms of the centralized repos, which themselves have their own cons. Flatpak gives linux app installation capabilities closer to that of android/ios (both for better and for worse).
Flatpack (or similar environments) turns Linux from OS into a platform because it provides standardized application environment that eliminated human labour in integrating each application. It’s not Linux in general (or Linux users) that love it, it’s distribution maintainers and application developers, because it saves thousands of mandays in maintainence work. It’s simple economy.
dsmogor,
+1.
Some people don’t want to consider software beyond the centrally managed repos,, but the truth is that central repos require a huge amount of labor to keep all projects and dependencies synchronized. By letting every project manage itself you loose some of the repo benefits, but you save so much work and it would seem logical for flatpak distros to have a competitive edge in terms of reducing maintainer overhead.
The first real immutable Linux was and still is the Chrome OS (or rather Chromium OS).
I was based on.,. wait for it… Gentoo.
https://wiki.gentoo.org/wiki/ChromeOS
So, yes, no need for Flatpaks as long as you have deterministic build systems.
(note: I am talking in the modern sense, where immutable system can be upgraded, and so on. Otherwise we had the DSL and other ISO based Linuxes for decades)
Chrome is Crap, not GNU/Linux, period.
What are the metrics what make Chromium OS “crap”? And why is it not GNU/Linux?
Nope. Check *your* metrics. Even Android * is not* Gnu/Linux.
Well,
They are a “free and open-source Linux distribution”, and use the GNU runtime. But what would I know?
https://en.wikipedia.org/wiki/ChromiumOS
ChromeOS is ditching Gentoo.
Yes, I can see them wanting more control.
According to:
https://www.zdnet.com/article/the-secret-origins-of-googles-chrome-os/
Okay wow, I don’t like that at all.
I’ve actually been kind of pro-flatpak overall just due to how much software (both FOSS and proprietary) has been made available across almost all distros in that format. With the built in sandboxing it’s especially suited to proprietary stuff like Steam that you wouldn’t want to give unfettered system access. Yes, yes, AppArmor exists, but there are no commonly shipped profiles for basically anything – and in the case of nosy proprietary software it doesn’t have to be good MAC anyway, only good enough to keep the software from snarfing up your browser history etc. Flatpak is the thing that’s let me stop using Windows completely for my personal devices.
This poor language support is really bad, though, and it’s part of a pattern – we see this with Wayland too, with things like input methods and accessibility being second class citizens. And there is really no excuse for this IMO.
And so Debian/Sid it is, with all the blobs included and FireFox ESR . I honestly can’t believe that you guys, the OSNews crowd would actually support such a huge paradigm switch.
I speak 3 languages. I can read and translate about 10 or 12. And I’m the idiot who does not support this racist policy? I mean, really???
Racist policy? Give me a break.
There really is an excuse for this. Lack of developers, I assume. Why are you and Thom not contributing language support if it’s so important to you?
Absolutely fed up of the whining on this comment section about free software, especially when we have to hear it from the article writer.
By all means continue to carp from the sidelines if that’s what floats your boat.
Because I believe Flats and Snaps are fundamentally flawed.
.debs are not. And if you write or translate this is a °HUGE° deal. I’d like to hear from Ubuntu and/or GNOME where do they stand about this.
And thank God I’m not a mono-lingual US-English-speaking person.
And what about my € 290 Corsair KB? Not supported even on W11 without proprietary drivers.
Don’t fschk with me.
As a mono-lingual English speaker, this all seems fine to me. I don’t understand your ‘thank god’ point.
Anyway, distros that service a particular requirement will always exist, and feel free to spin up your own.
I hade one of those keyboards as well, it did barely work with anything, could not even enter EFI/BIOS with it, i had to get another keyboard for that since the keyboard is initiatet too late in the boot process to be able to press the go to settings option.
I bought it as a replacement for my IBM-m series keyboard from 1984, it lasted me 36 years. The corsair looks nice and all but it was fundamentally flawed in the perspective from what i want. I got rid of it and bought a Unicomp keyboard imported from the US. It was rather expensive and the VAT and customs was higher than the entire price of the product, but it is a complete delight to be back to a buckling spring keyboard.
One of my first experiences with Flatpak was when I installed Fedora and wanted to install dconf-editor, and I couldn’t access the relevant settings because the application was sandboxed. I avoided flatpak for years after that.
On my Steam Deck I do love the convenience of Flatpak because so much is available and right now it does ‘just work’. Getting flatpak games to launch through the Steam Deck UI is a bit of a hassle but it does work.
I’m not a huge fan of all the overhead, but as a way of making certain software works without being dependent on compatibility with the OS library versions… it does make some sense.
You don’t need to use Flatpak if you don’t want to. You can use distrobox to create an image of your choice (Ubuntu, Fedora, Alpine or whatever), install an application from the distros’ repository and export it to the host via distrobox-export (https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-export.md).
I’ve been using immutable distros for a while now and you need to do a little bit of research based on what you expect of a distribution and its goals.
I just wanted to post something useful instead of what I’m reading lately in the comments.
Hey Thom, I think this particular case is the distro failing to properly communicate its supported languages settings to flat pack engine. User shouldn’t be expected to maintain that connection manually.
While having to make such links explicit is the “beauty” of sandboxed application environment, a distro that prides itself to support them shall do its job properly in that ragard and it clearly failed to do. I wouldn’t put all the blame to flatpack.
Having used linux as my main desktop os for 25 years, and not been that excited about flatpaks or snaps, I decided to try Aeon and installed it on my main machine month ago, as btrfs snapshots seemed interesting and good way to provide this immutable desktop or whatever you want to call it. And Im still running it, absolutely love it, and I think I will be running this for many years to come. Gnome desktop with all apps as flatpaks works very well, you get all the graphical applications and updates to them via gnome software center, that has good interface for discovering them. My main shell is tumbleweed container with distrobox, so I have all other bits I need, and that also works trouble free. Then I have one bookworm container for one graphical application needing that env, launcher exported via distrobox-export so it shows up in gnome shell, that also works flawlessly. Another build env for openwrt build stuff, all these switching is simple and can easily re-create if messing things up or want something else or start clean. So I think if you give something good chance and try it out, you might be surprised in good way. Big thanks to Aeon developers for great work and looking forward to improvements towards release.
Oh and what comes to language rant, my flatpak config lists en;fi by default.
What if there was a centralized registry of libraries indexed to the programs that depend on them. That way, when I install a file, I only install the libs I need, instead of having xyzMiB sitting on my hard drive. Program updated?, refer to the index, change or replace what’s needed – just what’s needed, and then update the index. If you need a program in a sandbox, can’t you chroot or jail(8) it?
Flatpacks sound like a nice idea, but it doesn’t get around the lack of a common, universal, *smart* package/library manager.