[ad_1]
analysis The cross-platform Linux packaging format Flatpak has moved into the spotlight this week as the “fundamental issues” [its] design “in a devastating contribution by the Canadian software developer Nicholas Fraser.
Fraser wrote on a blog posted on November 23 that “these are not the future of desktop Linux apps,” quotes a litany of technical, security and usability problems. His claims about disk usage and runtime sharing between apps have been fiercely contested by Will Thompson, Director of OS at the Endless OS Foundation one day later in a post titled “On Flatpak disk use and deduplication,” but there’s no denying that it’s terribly inefficient.
Most people don’t care anymore, one might argue. But they should.
The Linux world has been trying to invent a cross-platform packaging format for years, but leading competitors – the older, vendor-neutral AppImage format, as well as Ubuntu’s Snap and Fedora’s Flatpak – all have serious problems.
They may be revolutionary and mean Linux is easier to develop, but it’s enough chaos that some mainstream distributions avoid it.
In comparison, installing software on Windows is easy. Download an installer, run it and you have a new app. The catches are that it means trusting unknown binaries from across the internet – and that it teaches Windows users that this is fine and a perfectly normal thing.
Simple Win32 programs have unrestricted access to your computer. This is why Microsoft invented the Windows Store: it would only contain safe, tested, approved, “modern” apps written in “managed code”. (And of course Microsoft has to cut its revenue.)
The plan ran into some issues and it ended up allowing Win32 apps as well.
How about apples
It’s not unfair to say that everyone is trying to catch up with Apple. Not the App Store – it’s a must-have (and hugely lucrative) on iOS, but on a Mac, you can all but ignore it if you want. No, the goal is that of macOS .app Application packages that macOS inherited from its 1989 predecessor NeXTstep – although they usually come in classic macOS style .dmg Disk image file.
Applications on macOS are a specially structured folder that contains all of the program’s supporting “resources” and compiled binaries for as many CPU architectures as the app creator supports. It works pretty well, but not without a catch. For example, there is no global way to update all of your apps (unless you got them from the App Store). Apps tend to be big – but that’s fine because if you can afford Macs, you can afford a big hard drive and fast broadband, right?
Ironically, Linux could easily have had the same thing since all the functionality is already there GNUstep, the venerable FOSS rewrite of NeXTstep’s core libraries. Unfortunately, no mainstream Linux uses the GNUstep desktop, and the toilé Modernizing a project and making it a bit Mac-like is deathly sick. The superficially Mac-like Elementary OS would have been richer and more powerful if its developers had gone from Étoilé or GNUstep, but they didn’t – it’s just a facelift for GNOME 3, like Mints Cinnamon and Zorin OS.
Lots of the developers behind it Flatpak comes from the GNOME and Fedora community or their corporate backer Red Hat, but it’s a desktop-independent effort and comes standard on some Debian and Ubuntu derivatives. It uses Red Hat technologies like Ostree to manage binary files similar to Git.
Somewhere deep in your operating system is a complex directory tree full of your Flatpak applications and all of their dependencies, as opposed to a place where you can interact with it, like macOS or GNUstep.
Instead of a macOS-style directory full of files, Ubuntu’s Snap format compresses an application and all of its dependencies into a single compressed one SquashFS File that is put into a loop when the system is booted.
Flatpak and Snap have a lot in common. Both keep your apps inside /var/lib (although snap makes them visible at /snaps, and Flatpak will have you installed to your home directory if you prefer). Both require the installation of a supporting framework. Both of them do some degree of sandboxing of apps but aren’t as secure as their advertisements might lead you to believe. Both of them do things like run automatic, scheduled updates in the background, in a very Windows-like way – bad news if you have a metered 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 as the app bundles of macOS – e.g. The developer of AppImage has the ROX desktop‘S App directories and put each in a SquashFS (which probably inspired the Snap developers). ROX and AppDir are FOSS replicas of Acorn’s RISC OS, which was released shortly before NeXTstep in 1987. It doesn’t require any supporting frameworks and you can keep your AppImages anywhere you want.
All three have a weakness in that they package almost all of an application’s supporting libraries and other dependencies in their package, so packages are typically very large – on the order of hundreds of megabytes – and so are updates. Installing large Linux apps from the command line generally takes anywhere from seconds to tens of seconds, but installing a Snap or Flatpak can take many minutes, even with a fast connection – and of course ignores any local mirrors you might have configured for integrated package manager of your distribution.
Endless’ Thompson makes a good point, however. Flatpak’s format allows for something that single file formats can’t: if files are identical in different Flatpaks, OStree can reduce duplication by firmly tying them together … although, in principle, a sufficiently intelligent block-level file system could do the same thing.
What’s next?
There are alternative cross-distribution systems. Some avoid installing apps in the operating system at all and simply fetch them from the Internet into your home directory when necessary. Examples include 0 install, from the developer of the ROX Desktop. That inspired AppFS – which does something similar to that of CERN that has nothing to do with each other CernVM-FS. And then there are functional package managers, which are an entirely different type of software management tool that we’ll come back to in another article. Suffice it to say that there are several vendor-neutral ways to distribute Linux software older than the big three. All of them are lighter, more efficient, the packages are generally much smaller, and all are seriously opaque and you will never find them in a mainstream distribution.
Of course, due to the rampant Not-Invented-Here syndrome of the Linux industry, all of these systems completely ignore each other. Which has at least the advantage that you can install and try most of them side by side on the same operating system with no real drawbacks other than taking up a lot of disk space. But at least that’s cheap these days.
There are so many alternatives vying for place that it is hard to pick winners. This is partly because competitors build their own tools instead of cooperating, and partly because there’s almost no money to be made with desktop Linux, just servers – so the investments are low and the engineers sometimes have sketchy prototypes are shipped.
What is likely is that the sleek, efficient, but daring unconventional technology is getting nowhere, while the inefficient and space-hungry variants are heavily advanced and widespread.
Because of this, AppImage is unlikely to get much bigger as it doesn’t have a big company behind it. Ubuntu’s Snap system has several advantages over GNOME’s Flatpak, such as: B. that it is useful on servers etc. turned off.
In contrast, Flatpak alone entry, is a desktop tool – but anyone can host their own repos, and already several exist.
With Red Hat’s considerable clout behind them, Flatpak’s chances are good. But whoever wins, we’ll probably have to get used to the fact that distributions take up terabytes of hard drive and need hundreds of gigs of regular updates … and memories of the small, efficient systems of yore will be lost to history. Isn’t the progress great? ®
[ad_2]
