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.
Flatpak’s approach is fundamentally:
1. Don’t piss off upstream by creating downstream users who report bugs introduced by de-vendoring dependencies because they’re unaware that you’re supposed to send your bug reports to your distro for triage or don’t trust the distro to react promptly.
2. Automatically deduplicate identical files in transit and on disk.
3. Provide aids like Runtimes made by people who know Flatpak, the shared-modules manifest repository, and Base Apps (eg. Electron, Wine) to maximize how many files will be byte-for-byte identical and, thus, will be deduplicated when upstreams take the path of lowest resistance.
It’s another aspect of them basically deciding that 20 years is long enough to fight over having their concerns addressed, distro packaging has failed, and they’re going to route around it before any more non-daemon projects decide to make Docker their primary supported release channel.
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
Yeah, if the software has been modified it’s impossible for a normal user to know who’s responsible for a bug. The distro’s package maintainers might be responsible, but they may not be. Either way though, this model creates a lot of extra work for the distro. Flatpak shifts most of the work back upstream (for better or for worse).
This is technically easy to do. However unless there’s some deliberate underlying coordination happening, the odds of different packages happening to consistently use identical dependencies are quite small and therefor negate the benefits of automatic deduplication. In other words I’m not against this, but it doesn’t help that much.
It’s a good idea at least in theory. In practice though the same is also true of sharing the dependencies put out by ordinary distros – it’s the path of least resistance. And yet it is frequently the case for projects to build and update assets at their own pace and leave it up to repo managers to resolve any and all conflicts. So I’m all for coordinating downstream dependencies, hypothetically it should help. in practice though once you take away repo managers things tend to turn into a free for all.
I think flatpak applications with bundled dependencies is the future. It lets distros take less responsibility The inefficiencies are real and software optimization used to be a bigger priority. But those days are long gone and the industry has largely accepted the reality of bloated applications. It’s already a done deal and people don’t even blink when a trivial package comes in at 100MB. It’s expected and the solution is just to buy better hardware, wasteful though it may be.
Snap conflates two separate concerns. That’s where constrained and unconstrained snaps come from.
In the Flatpak world, OSTree is the common “git for your OS” component, tools like rpm-ostree are equivalent to unconstrained snaps, and Flatpak is explicitly about layering containerization on top of it.
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.