Flatpak – St. Distro’s Package

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:
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.

Installation questions

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.


Flatpak list

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

Firefox Nightly

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.

Weather flatpak

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.

LibreOffice flatpak

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.


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.


3 thoughts on “Flatpak – St. Distro’s Package

  1. On the subject of a GUI for Flatpack, Linux Mint will incorporate Flatpack management into Mint’s Software manager for version 18.3 coming out in the next month or so. The initial incorporation into the Software manager will be configured by default to point to 2 Flatpack “remotes; Flathub and Gnome-apps. Flatpack apps can be installed and removed within the Software Manager.

    It also appears that pointing to new remotes will also be done within the Software manager as well but I’m not certain of this. Either way, it will be interesting to see how well this works.

    You can read about this in the “Why Flatpack” section of Mint’s Monthly News post for October 2017 if you haven’t already (If the link is actually posted with this comment):


  2. I’m looking to update Mint soon-ish and while I haven’t looked at these technologies closely, I’m happy that we’re moving in this direction. As a new Linux user (little over a year) with no plans to leave Mint anytime soon, the decision has been made for me as far as how integrated, at least, one of these portable technologies will be with the system

    Having said that, when I do upgrade, as an end-user I’ll be making the final decision. If I find that Snap fits my case use better, I see no reason why I couldn’t install the framework on Mint.

    Although I haven’t been long on Linux, I’ve already installed tons of packages using different methods – Software Manager, apt-get, PPAs, ‘make’ to build binaries from source, chmod’ing statically linked binaries, installing windows programs and running with Wine, unzipping DOS programs and running with DOSBox, etc…

    I don’t think that most Linux users, interested in a more portable packaging system, are going to put-off by a couple of more methods. In the end, the tech that allows me the best way of **UNinstalling** wins!

    I despise a messy system, breadcrumbs… Ever since Windows 95 came rolling around playing havoc with this and adding a registry. It’s a pet peeve but when I say uninstall, I mean uninstall ALL traces. Why should this be, in this “modern-age”, so difficult to do?

  3. In terms of hassle-free downloading and running applications from the developer’s webpage, like Windows users are accustomed to doing, AppImage wins by a long shot in my opinion. It requires no frameworks, no central package repository, and no GUI or command line package managers. But there is also a huge amount of variability among different AppImages, and yes, many of them don’t run on certain distros. They also tend to have theming and integration problems. So they’re not a panacea.

    Something I strongly dislike about FlatPak and Snap is the need for a central package repository. Yes, I understand the security implications of running software off the internet, and I appreciate the value of vetted packages. But that’s what the Linux distributions’ traditional package repositories are for, and we won’t be eliminating the need for those any time soon. In my opinion, the package manager approach that Dedo describes here for FlatPak (and Snap) is an unnecessary level of complication for users and developers. I think that anecdotal proof of this is the fact that AppImages are starting to appear in “real life” when poking around the Downloads section on websites of new and established open source software projects. FlatPak and Snap, on the other hand, are painfully absent.

    I would interested to know how FlatPak handled integration with Dedo’s desktop theme. As I mentioned before, this is usually a challenge for universal packaged apps.

Leave a Reply