The word best used to describe Linux is variety. That, or fragmentation. Whichever part of the desktop system you choose, from the environment to the text editor to the underlying software packaging mechanism, there’s always a huge number of options. Alas, plenty != choice. In fact, most of the subsystems are incompatible with one another, leading to significant management overhead.

If you want to run your software on multiple distributions, you essentially need to compile it against many subsets of libraries, some of which follow different naming schemes and hierarchy, and it takes a lot of work to achieve simple results. Instead, what makes a lot more sense is the approach embodied in the Windows-like world; self-contained plug-n-play applications. Recently, Linux has begun adopting this weight-slimming approach with AppImage, Snap, and there’s also Flatpak, which is the topic of our article today.

Setting up

My test rig is one Ubuntu 17.10 Artful Aardvark – yes, I am going to publish a review soon. To get started, you just need to install single package called flatpak. It’s essentially the service that will configure and install flatpak packages for you. Now, if you only use a single system, you won’t immediate see the value, but then, a flatpak application should be able to run on any flatpak-enabled system.

Once you have the program installed, you can start using it. At the moment, flatpak does not have any fancy GUI tool to help you catalog, install or update your applications. Much like snap, you use the CLI tool to manage stuff. There are several methods about this, but in general, it’s relatively simple.

I decided to try the most straightforward path of installing software using the reference files available on the Flatpak website, under Applications. Essentially, this is like downloading a DEB or RPM file and then installing them locally with apt or dnf. Well, almost.

flatpak install gnome-documents.flatpakref
This application depends on runtimes from:
 https://sdk.gnome.org/repo/
Configure this as new remote 'gnome' [y/n]: y

For instance, for Gnome Documents, I was asked on setting up some additional runtime libraries. Sounds a little confusing, but then I let it run. After a while, the CLI tool also started downloading Nvidia stuff, which makes sense given that the chosen test machine has an Nvidia graphics card, but still, it alarmed me somewhat. Again, I let the experiment unfold. The idea is to see how easy and convenient it is to use this software.

Installing: org.freedesktop.Platform.GL.nvidia-340-104/x86_64/1.4 from gnome
[####################] Downloading: 39.0 MB/39.0 MB (3.9 MB/s)

I continued with several more application setups, including Gnome Weather, Firefox Nightly and LibreOffice. The latter two installed in a fully self-contained manner without asking any additional questions or requiring any dependencies. Compared to the standard apt-get method, this was a bit slow, and the packages are quite big, but do remember that they need to contain everything the program needs to run without relying on the system’s intricate library tree.

Does it work?

Well, the answer is, very much so. I launched Firefox first, but then, with a current version (Firefox 56) already running, the Nightly build could not really execute. Once I closed the default browser, the Nightly launched, albeit quite slowly and with some odd command-line errors.

Firefox warning, 1509296380597 addons.xpi WARN Can't get modified time of /app/lib/firefox-58.0a1/browser/features/firefox@getpocket.com.xpi

After it started, the CPU settled, and the performance was reasonable. Gnome Weather also behaved well, and I was able to search for locations and add them without any problems. I’m not sure about some of the background aesthetics – Aurora Borealis with Paris as location, but as far as Flatpak is concerned, it delivered.

LibreOffice launched really quickly, without any delays. This is quite interesting, so I’m wondering if there are any cardinal differences as to how some of the flatpaks are built or designed, and if this could potentially affect the user. But I was rather pleased. Sure, there are some small bugs and issues, like the fact Flatpak lists both applications and runtimes, and some other minor details, but nothing drastic.

Flatpak vs Snap vs AppImage?

That’s an interesting question. If I look at what I’ve done with Snap and AppImage so far, then I think Flatpak is probably the most convenient of them all. Still not perfect, but for some odd reason, the whole experience was less painful than I remember with the other two. It’s an entirely subjective claim. The necessary preparations, the intuitiveness of the command-line tool and its switches, the errors and bugs, the complexity of finding what I needed and figuring out what I had to do. Overall, I think Flatpak gave me a somewhat superior experience over the other two.

And thus, fragmentation, all over again

Now the tricky part. We have three package-agnostic package managers … already. This isn’t unlike Linux starting in the 90s, and then having RPM vs DEB, which eventually led to more orchestration mechanisms, ending with yum and apt and whatnot, and then GUI frontends, and finally the sordid situations we have today.

What is there to stop these package frameworks from becoming the future generation of fragmentation software for Linux? If different distributions choose not to support some of them, we will eventually end up with a similar problem to the original one, and we will need to worry and fret if things will be supported and run on other distributions. This is something we need to be painfully aware, and make every effort to avoid.

The future

There’s one big problem. Flatpak has a tiny subset of programs available, and there aren’t that many production ready packages with the other two frameworks, either. Snap is most prolific, it seems, but then its collection of software is largely weird and unfamiliar, probably due to the whole Ubuntu touch story. AppImage goes for more solid results, but there are only about 50 of them on Github. Then again, I was also able to download and install Etcher, a USB-writing software, as an AppImage from its official website, and it works beautifully, including updates.

Flatpak comes with maybe a dozen programs at the moment, but they seem to work just fine. Then, there’s also FlatHub (more fragmentation),  which lists another 100 odd programs and games, some of them rather interesting. Now, there could be many more out there, but the fact I wasn’t able to find them in a few seconds of quick searching tells a lot.

Ideally, all these should fall under a central umbrella, with smart, practical GUI managers to allow users to manage their distro-agnostic software with ease and elegance. It should not be about command line, and the software should be dead-easy to find. How is this going to evolve, side by side with the implicit rivalry of these three frameworks, will be an interesting thing to follow.

Conclusion

Flatpak works well. I am pleased with my short test, and I am convinced with the benefits and flexibility that this framework offers. It seems to be quite intuitive, and it did not spew errors. That said, the road to being a first-class product is still a long one. People don’t need the dirty detail. They want beautiful application stores and sod the nuts and bolts.

I hope the distro-agnostic software takes off. It should help bring together the fragmented world of Linux, and make both maintenance and development easier, and give users the transparency that their peers on Windows enjoy. Technically, even if there’s fragmentation in the background, a clever GUI will disguise that, so we might stay with the old system, but the problem with that is, the distros suffers, and as a result, users suffer, too. The way forward is clear. The only question is, will it be one way or many? History has a way of repeating itself. To be continued. Flak away.

---

 

Cover photo: Courtesy of dimitris pedritis, freeimages.com.