Will Flatpak and Snap replace desktop Linux native apps?
Actually, the better question is: When will they replace most desktop Linux programs?
Opinion I've been using desktop Linux since before many of you were born. Seriously. I first ran it when I downloaded the source code from Linux kernel developer Theodore Ts'o's MIT FTP server in 1991. So, when I say it's time to wave bye-bye to using package managers such as
dnf and replace them with containerized package managers such as Appimage, Snap, or Flatpak, I do have a clue about what I'm talking about.
Before going into why, let me give you a quick refresher on application installation on Linux. In the beginning, there was the source code. We downloaded it, built it, and compiled it. You can still do it that way today, as in this example of how to install Node.js v8.1.1 to your Linux desktop.
Most people don't do it that way because it's a pain. Only developers build from source code these days. The vast majority of users use package managers. For users, they're easy whether you use a GUI interface such as Linux Mint's Software Manager or a shell-based package manager such as DPKG, Pacman, Yum, and Zipper.
It's another story, though, if you're a Linux distribution maintainer. Then, you're the one who must build the application from source code for every last version of your distro that you're supporting. And, then, you must do it all over again, every time there's an application upgrade or patch. In some cases, such as with Firefox daily builds, this gets old fast.
It's also expensive. It can also be really irritating when your long-term support (LTS) distribution from four years ago doesn't have the new library needed to support the latest version of, say, the imaginary FireChrome web browser. This way leads to what programmers like to call dependency hell. This is not a place you want to be.
But, as Alexander Larsson, Flatpak's founder, told me a few years back, while the main point is to make life easier for desktop app developers, "users get to take advantage of it. It makes it easier for developers to ship apps to users."
You see, at one time or another, all Linux users complain, why can't I get Quicken, Photoshop, or whatever on Linux. The reason is application developers don't want the hassle of rewriting their code to work on multiple, mutable Linux distributions.
But what if you enabled them to write once and publish once and not worry about the underlying Linux distro and what version of what libraries are supported? That's the promise of the containerized Linux package systems.
It's a promise that's already been delivered. If you're using, say, Spotify on your Linux desktop today, you're probably running it via a Snap or Flatpak.
Flatpak and its rivals can also run on any Linux distribution. They can run any program by containerizing all its necessary libraries and associated files. And, because they run them in a virtual sandbox, the containerized apps are more secure.
There are endless debates about which one is better. Honestly, I use all of them, and I see little difference between them. What I think is really going on is there's one group that favors Red Hat, while the other loves Ubuntu. In the meantime, I'd like to remind both sides that Windows users are snickering at them from the mountains as the Linux distro fans fight over molehills.
All of them have problems in common. All containerized apps run slower than their native counterparts. That's because to run them, your computer must load not just the application but the containerized operating system. That also means they take up more memory.
You know what? I haven't found either to be that big of a deal. I run my Linux desktops on modern systems with powerful processors, 16GBs of RAM, and speedy SSDs. Frankly, neither performance nor a lack of RAM has been an issue for me.
Others agree. Recently the leaders from the GNOME Foundation and KDE Foundation decided to build an app store on top of Flatpak. Besides using it as a common platform for applications, they're also proposing "to add donations and payments to Flathub via Stripe, as well as a process to verify developer identities and allow direct uploads to ease the publishing process."
The goal? To build "a vendor-neutral commercial and technical ecosystem to publish and distribute end-user applications" for Linux PCs. This will be one that will make life easier and more profitable for software developers, which in turn will give users access to more and better programs.
I like this idea. I like it a lot.
- Red Hat to stop packaging LibreOffice for RHEL
- Oh Snap... Desktop Ubuntu Core to arrive in 2024
- Red Hat promises AI trained on 'curated' and 'domain-specific' data
- EU's Cyber Resilience Act contains a poison pill for open source developers
At the same time, the Linux desktop vendors are moving away from the old packaging style. Canonical, for example, stopped shipping the DEB version of Firefox years ago. Now Red Hat has essentially abandoned shipping LibreOffice RPMs at the beginning of June.
As Jorge Castro, open source community manager and Linux expert, put it: "Say what you want about Canonical and Red Hat's decision to do this, but at the end of the day, it's all about the number of contributors you have in one hand, and the amount of work required to compete in the market in the other… People don't want to hear this, so I'll just say it: distributions can no longer afford to pretend that they add value by repackaging office suites. The real value is in the hard stuff. We need a well-maintained kernel, graphical stack, desktop, and associated core tools."
If you want to keep building Linux and its apps with stone knives and bearskins, you can – more power to you. But, the future of the Linux desktop is here, and it's going to be containerized. ®