Analysis The Linux Flatpak cross-platform packaging format has been in the spotlight this week, with the “fundamental issues inherent in [its] design ”criticized in a scolded article by Canadian software developer Nicholas Fraser.
Fraser wrote in a blog post on November 23 that “this is not the future of desktop Linux applications,” citing a litany of technical, security and usability issues. His claims about disk usage and the sharing of runtime between applications were hotly contested by Will Thompson, director of operating systems at Endless OS Foundation a day later in an article titled: “On the Flatpak disk usage and deduplication ”, but there’s no denying that it’s horribly inefficient.
Most people don’t care anymore, you might say. But they should.
The Linux world has been trying to invent a cross-platform packaging format for years, but the main competitors – the older, older, vendor-independent AppImage format, as well as Ubuntu’s Snap and Fedora’s Flatpak – are all getting serious. problems.
They might be groundbreaking and mean Linux is getting easier to develop, but it’s already complicated enough that some mainstream distros are avoiding all of that.
In comparison, installing software in Windows is straightforward. Download an installer, run it, and you have a new app. The snags are that it means trusting binaries unknown to the internet – and that it teaches Windows users that it’s okay and a perfectly normal thing to do.
Simple Win32 programs have unlimited access to your computer. This is why Microsoft invented the Windows Store: it would only contain safe, verified, approved, “modern” applications written in “managed code”. (And sure enough, Microsoft was able to keep a share of the revenue.)
The plan encountered some glitches, and in the end, Win32 apps were allowed as well.
How about them Apples
It’s not unfair to say that everyone is trying to catch up with Apple. Not the App Store – it’s must-have (and extremely lucrative) on iOS, but you can pretty much skip it on a Mac, if you want to. No, the target is macOS
.app app bundles, which macOS inherited from its 1989 ancestor NeXTstep – though they usually come in classic MacOS style
.dmg disk image file.
Apps on macOS are a specially structured folder, containing all of the program’s supporting “resources” and binaries for as many processor architectures as the app creator supports. It works pretty well, but not without a hitch. For example, there is no comprehensive way to update all of your apps (unless you got them from the App Store). Apps tend to be big, but that’s okay because if you can afford Macs, you can afford a big drive and fast broadband, right?
Ironically, Linux could easily have had much the same thing as all the functionality already exists in GNUstep, the venerable FOSS rewrite of NeXTstep’s core libraries. Unfortunately, no mainstream Linux uses the GNUstep desktop, and the Star project to modernize it and make it a little more Mac is dying. The basic, superficially-like Mac operating system would have been richer and more capable if its developers had started from Star or GNUstep, but they didn’t – it’s just a facelift for GNOME 3, like Mint’s Cinnamon and Zorin OS.
Many of the developers behind Flatpak are from the GNOME and Fedora communities, or their corporate sponsor Red Hat, but this is a desktop independent effort and is installed by default on some Debian and Ubuntu derivatives. It uses Red Hat technologies such as OStree to handle binaries in the same way as Git.
Somewhere deep within your operating system is a complex directory tree filled with your Flatpak apps and all their dependencies, as opposed to a prominent place you can interact with, like on macOS or GNUstep.
Rather than a macOS-style directory filled with files, Ubuntu’s Snap format compresses an application and all of its dependencies into a single, compressed SquashFS file, which is looped during system startup.
Flatpak and Snap have a lot in common. Both keep your apps inside
/var/lib (although Snap makes them visible to
/snaps, and Flatpak will allow you to install in your home directory if you prefer). Both require the installation of a support framework. Both do some degree of app sandboxing, but aren’t as sure as their advertisements might lead you to believe. Both do things like run automatic, silent updates in the background, in a very Windows way – bad news if you’re using a limited connection. It also means that if you update your operating system with a shell command, these apps will not be included.
The AppImage format has similar advantages and disadvantages to macOS app bundles, such as the lack of a global update mechanism, as it was born out of technology of a similar age. The AppImage developer took the AppDirs from ROX Desktop and put them in a SquashFS (which probably inspired the developers of Snap). ROX and AppDir are FOSS recreations of Acorn’s RISC operating system, which appeared slightly before NeXTstep in 1987. It doesn’t require any supporting framework and you can keep your AppImages anywhere you want.
All three share a weakness in that they include almost all of an app’s supporting libraries and other dependencies in its package, so the packages tend to be very large – on the order of hundreds of megabytes. – just like updates. Installing large Linux apps from the command line usually takes anywhere from a few seconds to tens of seconds, but installing a Snap or Flatpak, even over a fast connection, can take several minutes – and of course ignores any local mirrors you have configured for your distro’s built-in package manager.
Thompson of Endless makes a good point, however. The Flatpak format allows something that single file formats cannot: if the files in different Flatpaks are identical, OStree can reduce duplication by linking them together … although in principle a sufficiently intelligent file system can. do the same at the block level.
There are alternative cross-distribution systems. Many avoid installing applications into the operating system at all and simply grab them from the Internet into your home directory when needed. Examples include 0install, from the developer of the ROX desktop. This inspired AppFS – which does something similar to CERN’s independent CernVM-FS. And then there are functional package managers, which are a whole different kind of software management tool that we’ll get to in another article. Suffice it to say that there are several vendor independent ways of distributing Linux software that precede the Big Three. All of them are lighter, more efficient, the packages are generally much smaller, and all of them are seriously obscure and you will never come across them in a mainstream distribution.
Of course, because of the uninvented syndrome here endemic to the Linux industry, all of these systems are totally ignoring each other. This at least has the advantage of being able to install most of them side by side on the same operating system and try them out, with no real penalty, except using a lot of disk space. But at least it’s cheap these days.
There are so many alternatives vying for the space that it’s hard to pick winners. This is partly because competitors are creating their own tools rather than cooperating, and partly because there is almost no money to be made with desktop Linux, only servers – so there is little investment and the sometimes sketchy prototypes of engineers end up being shipped.
What seems likely is that the lean, efficient but daringly unconventional technology will go nowhere, while the inefficient and space-hungry variants will be heavily pushed and widely used.
However, AppImage probably won’t get much bigger, as there isn’t a big company behind it. Ubuntu’s Snap system has some advantages over GNOME’s Flatpak, such as being useful on servers, etc. but Ubuntu runs the only Snap Store and the only open source backend is obsolete and has been removed.
In contrast, Flatpak, by its own admission, is a desktop tool – but anyone can host their own repositories, and several already exist.
With Red Hat’s considerable influence, Flatpak’s chances look good. But whoever wins, over time we will probably have to get used to distributions taking up terabytes of disk and needing hundreds of gigs of regular updates … and memories of the small, efficient systems before will be lost in the story. Isn’t progress great? ®