There’s a ton of interest in immutable, image-based versions of various Linux distributions, since they offer a number of benefits that make them a good fit for some users. Updates can’t really go wrong, rollback is easy, application management through Flatpak is more in line with systems like Android and iOS – they may not be advantages sought by everyone, but they clearly are by some. Still, there are also a number of annoying limitations, most notably around testing nightly releases of Flatpaks, testing system components, and installing command-line tools.
The team behind GNOME OS is addressing these issues. The first thing they’re working on in something they’ve preliminarily call Test Center, which makes it much easier to install nightly releases of Flatpaks alongside their regular versions. This is something you can already do today, but the flow is cumbersome and not exactly user-friendly; with Test Center, developers will be able to share a direct link to install test releases.
They intend to use this same Test Center for testing system components:
Our idea here is to use the same “Test Center” app mentioned above for installing and managing experiments at the system level as well. Similar to Flatpak bundles generated in CI, we generate system extension images (sysext) for every merge request. You can install experiments from a sharing link, and they will apply as a sysext over your existing system. Because those images are non-destructive overlays, you can always go back to the original system.
↫ Jordan, Jonas, and Tobias
The last and final issue is that of command-line tools, something Flatpak is simply not designed for. On this front, the GNOME OS team states they are working on a solution as well, but they’re not quite ready to go into much more detail at this point.
Regardless, these are very welcome improvements.
Honestly, Flatpak is pretty close if they weren’t actively refusing to support the use-case.
With the script I wrote to produce/update launchers with proper, tab-completion-friendly names that wrap the –file-forwarding option, the main thing that I notice is the lack of MPV’s manpage.
https://gist.github.com/ssokolow/db565fd8a82d6002baada946adb81f68
Yep, this is the one, albeit pretty huge, oversight of Flatpak in comparison to Snap, which was designed with CLI in mind from day one.
Also what irritates me are the multiple gigabytes’ worth of multiple versions of shared framework libraries that constantly ask to be updated. I don’t really get why new versions of Flatpaks apparently insist on changing minor versions of their dependencies all the time, apparently remaining on old versions, just slightly newer updates of said old versions. Thus my system is littered with 5 copies each of giant meta packages like the Freedesktop Platform and Freedesktop SDK each version half a gigabyte in itself. I know this is a “feature” of Flatpak but in practice it’s just so much more unnecessary-seeming churn.
Moochman,
This is the conundrum. The repos solve this by having centralized maintainers doing the work to consolidate software libraries. Flatpaks cannot automatically determine compatibility though. At best they’d have fallible heuristics. Expecting publishers to coordinate on their own just isn’t realistic because different software developers have radically different schedules for upgrading library versions. Some stick to bleeding edge libraries while others stick with stable libraries forever. Repos need maintainers to do the hard job of strictly enforcing library versions, but none of this happens with flatpak. We might consider fixing it by hiring staff to essentially replicate what the repos do except with flatpak. However part of the goal with flatpak was to avoid this work. I don’t see any easy fix.
Hypothetically AI agents could test and patch thousands of flatpak packages so they can share the same libraries, but even if it worked it still wouldn’t make everyone happy.
I was just looking into immutable Linux variants. If anyone wants to experiment in this area, Fedora Atomic Desktops offers five options with different desktop environments: https://fedoraproject.org/atomic-desktops/
You might also consider Bazzite (https://bazzite.gg/), a gaming-focused immutable distribution built on Fedora Atomic.
I’ve been on Bazzite for a while now, and the immutable nature of it has solved MANY long standing problems I’ve had with Linux in general, including update corruption, config mismatch on update, etc. It’s a little harder to mess about with some developer-ish stuff, when you need to actually install some system level things, but for the most part, this is just a better way to organize the system, in my strong opinion.