Flatpaks aim to be a middle ground between dependency hell and “let’s pull in the universe” bloat.
Applications packaged as Flatpaks can reference runtimes to share “bases” with other applications, and then provide their own libraries if they need anything bespoke on top of that.
And they are still, in my experience, slow to load, a cumbersome addition to the update process, and often un-necessary.
Don’t get me wrong, if you’re in a tight spot and can’t make two significant software packages work in a distribution due to conflicting library version requirements… some kind of lightweight container solution is attractive, expedient, and better than just not supporting one of the packages. But, my impression is that a lot of stuff has been moved into flatpak / snap / etc. just because they can. I don’t think it’s the best, or even preferred, way to maintain software - for the desktop environment.
(Returns to checking on his Docker containers full of server apps on the R-Pi farm…)
I’m running an immutable distro at the moment (GNOME OS), and I felt no loss of performance due to Flatpaks. Snaps, on the other hand, do have a perceivably longer launch time.
Given that it’s an immutable distro, everything I need needs to be either a Flatpak, a Snap, an Appimage or an extracted tarball, otherwise it runs in a container. The advantage of this system is stability and making the host incorruptible, as well as the ability to very easily roll back updates or failed systemd-sysext layers.
Not everything can run in a Flatpak at the moment, but we’re hoping the evolution in Flatpak, XDG portals as well as encouraging developers to use the available XDG portals can make this a possibility someday. Namely, IDEs don’t run that well in a Flatpak, but GNOME Builder has proven that it’s 100% possible with the currently available XDG portals as well as connecting your IDE or editor to a container.
Ubuntu Core, based on Snaps, is very much not ready for prime time IMO. It’s kind of a mess outside of server use.
Look instead at Fedora Silverblue, Vanilla OS, and for the bleeding edge of immutable systems, GNOME OS.
KDE is about to launch their analogue to GNOME OS relatively shortly, named “Project Banana”. These two are not exactly distros as they do not distribute the kernel, they are simply platforms that layer a bunch of images together to create a stable, reproducible system. There’s also OpenSuSE Aeon, but I don’t like its style of immutability as it’s immutable by rootfs lock-out rather than immutable by image.
As for advice, learn how to use Distrobox / Toolbx containers. If you’re a developer, this is where you will be working.
Immutable Linux is still young, and a lot of software isn’t written with it in mind, so expect some growing pains.
Thanks. In the past I have worked in Slackware, and even had Gentoo on my home system for a couple of years, but otherwise I’ve been fully saturated in Debian and its children - so that’s my “comfort zone.” I used to like KDE, but drifted away from it when I got a 4K screen notebook and KDE hadn’t figured out resolution scaling yet, while Ubuntu/Unity had. I never quite warmed up to GNOME, but definitely have done my time with it. XFCE has matured enough for me to daily drive it without too much pain now, and I love the ways it can be de-featured (don’t want a launcher bar? Don’t run it, nothing else breaks.)
Server-side, I have been filling my Raspberry Pis with Docker containers for a while now… it’s not completely alien, but I do kind of tend to “set it and forget it” when it comes to container deployments.
Flatpaks aim to be a middle ground between dependency hell and “let’s pull in the universe” bloat.
Applications packaged as Flatpaks can reference runtimes to share “bases” with other applications, and then provide their own libraries if they need anything bespoke on top of that.
And they are still, in my experience, slow to load, a cumbersome addition to the update process, and often un-necessary.
Don’t get me wrong, if you’re in a tight spot and can’t make two significant software packages work in a distribution due to conflicting library version requirements… some kind of lightweight container solution is attractive, expedient, and better than just not supporting one of the packages. But, my impression is that a lot of stuff has been moved into flatpak / snap / etc. just because they can. I don’t think it’s the best, or even preferred, way to maintain software - for the desktop environment.
(Returns to checking on his Docker containers full of server apps on the R-Pi farm…)
I’m running an immutable distro at the moment (GNOME OS), and I felt no loss of performance due to Flatpaks. Snaps, on the other hand, do have a perceivably longer launch time.
Given that it’s an immutable distro, everything I need needs to be either a Flatpak, a Snap, an Appimage or an extracted tarball, otherwise it runs in a container. The advantage of this system is stability and making the host incorruptible, as well as the ability to very easily roll back updates or failed systemd-sysext layers.
Not everything can run in a Flatpak at the moment, but we’re hoping the evolution in Flatpak, XDG portals as well as encouraging developers to use the available XDG portals can make this a possibility someday. Namely, IDEs don’t run that well in a Flatpak, but GNOME Builder has proven that it’s 100% possible with the currently available XDG portals as well as connecting your IDE or editor to a container.
Not mocking: can you share any good guides to practical immutable systems?
What I observed of Ubuntu Core made a strong “not ready for prime time, and even if it was I don’t want it” impression on me.
Ubuntu Core, based on Snaps, is very much not ready for prime time IMO. It’s kind of a mess outside of server use.
Look instead at Fedora Silverblue, Vanilla OS, and for the bleeding edge of immutable systems, GNOME OS.
KDE is about to launch their analogue to GNOME OS relatively shortly, named “Project Banana”. These two are not exactly distros as they do not distribute the kernel, they are simply platforms that layer a bunch of images together to create a stable, reproducible system. There’s also OpenSuSE Aeon, but I don’t like its style of immutability as it’s immutable by rootfs lock-out rather than immutable by image.
As for advice, learn how to use Distrobox / Toolbx containers. If you’re a developer, this is where you will be working.
Immutable Linux is still young, and a lot of software isn’t written with it in mind, so expect some growing pains.
I’m on silverblue, well, bluefin, specifically.
So far so happy 🤷♂️
Thanks. In the past I have worked in Slackware, and even had Gentoo on my home system for a couple of years, but otherwise I’ve been fully saturated in Debian and its children - so that’s my “comfort zone.” I used to like KDE, but drifted away from it when I got a 4K screen notebook and KDE hadn’t figured out resolution scaling yet, while Ubuntu/Unity had. I never quite warmed up to GNOME, but definitely have done my time with it. XFCE has matured enough for me to daily drive it without too much pain now, and I love the ways it can be de-featured (don’t want a launcher bar? Don’t run it, nothing else breaks.)
Server-side, I have been filling my Raspberry Pis with Docker containers for a while now… it’s not completely alien, but I do kind of tend to “set it and forget it” when it comes to container deployments.