Developers are lazy, thus Flatpak

In the final decade I’ve seen a really gradual however regular shift to options for packaging software program that attempt to isolate the software program from host techniques to supposedly make issues simpler. My first expertise with this was Docker, now Flatpak is the factor for desktop functions.

The promise of Flatpak

So the factor Flatpak is meant to repair for me as developer is that I needn’t care about distributions anymore. I can bolt on no matter dependencies I need to my app and it is handled. I additionally needn’t fear about having software program in distributions, if it is in Flatpak it is in all places. Flatpak offers me that unified base to work on and every little thing shall be excellent. World starvation shall be solved. Finally peace on earth.

Sadly there’s actuality. The actuality is to get away from the evil distributions the Flatpak creators have made… one other distribution. It is just not a very good distribution, it would not have an honest package deal supervisor. It would not have a system that makes it straightforward to do packaging. The developer interface is painfully shoehorned into Github workflows and it provides all of the downsides of containerisation.

Flatpak is a distribution

While the builders prefer to faux actual exhausting that Flatpak is just not a distribution, it is nonetheless suspiciously shut to at least one. It lacks a kernel and some providers and it lacks the usual Linux base listing specification but it surely’s nonetheless a distribution you must goal. Instead of offering seperate packages with a package deal supervisor it offers a runtime that comes with a bunch of dependencies. Conveniently it additionally offers a number of runtimes to verify there’s not truly a single base to work on. Because typically you want Gnome libraries, typically you want KDE libraries. Since there is not any package deal supervisor these shall be in seperate runtimes.

While Flatpak breaks most expectations of a distribution it is nonetheless a set of software program and libraries construct collectively to make a system to run software program in, thus it is a distribution. A very bizarre one.

No in-built package deal supervisor

If you want a dependency that is not within the runtime there is not any package deal supervisor to drag in that dependency. The resolution is to additionally package deal the dependencies you want your self and let the flatpak tooling construct this into the flatpak of your software. So now as an alternative of being the developer to your software you are additionally the maintainer of all of the dependencies on this semi-distribution you are delivery beneath the disguise of an software. And one factor is for certain, I do not belief software builders to take care of dependencies.

This will get actually nuts by some software program that offers with multimedia. Lets take a look at the Audacity flatpak. It builds as dependency:

• wxwidgets
• ffmpeg
• sqlite
• chrpath
• portaudio
• portmidi

So lets take a look at how effectively dependencies are managed right here. Since we’re now virtually precisely half a 12 months into 2023 I’ll take a look at the updates for the final 6 months and evaluate it to the identical dependencies in Alpine Linux.

• audacity has been up to date 4 instances within the flatpak. It has been up to date 5 instances on Alpine.
• ffmpeg has been up to date to six.0 in each the flatpak and Alpine, however the ffmpeg package deal has had 9 updates as a result of if codecs which were up to date.
• sqlite hasn’t been up to date within the flatpak and has been up to date 4 instances in Alpine
• wxwidgets hasn’t been up to date within the flatpak and has been up to date 2 instances in Alpine
• chrpath hasn’t had updates
• portaudio hasn’t had updates in flatpak and Alpine.
• portmidi hasn’t had updates

This is only a random package deal I picked and it already had much more maintainance of the dependencies than the flatpak has. It almost certainly would not scale to have all builders hold monitor of all of the dependencies of all their software program.

The concept of isolation

One of the large execs that is all the time talked about with Flatpak is that the functions run in a sandbox. The concept is that this sandbox will protect you from all of the evil functions can achieve this it’s very protected to belief random builders to push random Flatpaks. First of all this sandbox has the identical subject any permission system that exists additionally has. It wants to inform the person in regards to the particular holes which were poked within the sandbox to make the applying work in a manner that finish customers perceive what the safety implications of these permissions are.

For instance this is Gnome Software prepared to put in the flatpak for Edge:

I discover the permission handleing applied right here very attention-grabbing. There’s completely no warning in any respect in regards to the bypassed safety on this Flatpak untill you scroll down. The set up button will instantly set up it with out warning about all of the bypassed sandboxing options.

So in the event you do scroll down there’s extra particulars proper? Sure there may be!

There’s a pleasant crimson triangle with the phrases Unsafe! pfew, everybody is ok now. So this makes use of a legacy windowing system which in all probability means it makes use of X11 which isn’t safe and breaks the sandbox. Well if that is the one safety subject then it would possibly be acceptable? Let’s click on that button.

Well yeah… let’s disguise that from customers. Of course the browser wants to put in writing to /and many others. This is all unimportant to finish customers.

The even worse information is that since that is proprietary software program it is not likely potential to audit what this could do, and even when it is audited it is ridiculously straightforward to push a brand new extra evil model to Flathub since virtually solely the primary model of the app you push is thorougly checked out by the Flathub maintainers.

Even if there weren’t so many holes within the sandbox. This doesn’t cease functions from doing extra evil issues that are circuitously associated to filesystem and daemon entry. You need analytics in your customers? Just requirest the web permission and ship off all of the monitoring knowledge you need.

So what about conventional distributions

I’ve heard many argument for Flatpaks by customers and builders however ultimately I am unable to actually say the professionals outweigh the cons.

I feel it is crucial that builders don’t have the permissions to push no matter code they need to everybody beneath the disguise of a safe system. And that is my opinion as a software program developer.

Software packaged by distributions has a minimum of some extent of scrutiny and it typically ends in a minimum of ensuring construct flags are set to disable person monitoring and such options.

I additionally imagine software program generally is best if it is made with the expectation that it’s going to run exterior of Flatpak. It’s not that arduous to ensure you do not rely on bleeding edge variations of libraries whereas that is not wanted. It’s not that arduous to have elective dependencies in software program. It’s not that arduous to really comply with XDG specs as an alternative of hardcoding paths.

But packaging for distributions is tough

That’s one of the best factor! Developers are not speculated to be those packaging software program so it is not exhausting in any respect. It’s not your activity to get your software program in all of the distributions, in case your software program is beneficial to folks it tends to get pulled in. I’ve software program that is packaged in Alpine Linux, ALT Linux, Archlinux AUR, Debian, Devuan, Fedora, Gentoo, Kali, LiGurOS, Nix, OpenMandriva, postmarketOS, Raspbian, Rosa, Trisquel, Ubuntu and Void. I didn’t need to package deal most of this.

The most I discover from different distributions packaging my software program is patches from maintainers that enhance the software program, often in coping with some edge case I forgot with a hardcoded path someplace.

The most time I’ve ever spent on distribution packaging is definitely the few items of software program I’ve managed to push to Flathub. Dealing with variations between distributions is simple, coping with variations between runing inside and out of doors Flatpak is tough.

But Flatpaks are simpler for finish customers

I’ve bumped into sufficient points as finish person of flatpaks. A package deal being on Flathub doesn’t imply that will probably be installable for an finish person. I’ve bumped into this by putting in packages on the PineBook Pro which generated some relatively complicated error messages in regards to the repositories lacking. It seems that the Aarch64 structure was lacking for these flatpaks so the software program was simply not out there. Linux distributions usually attempt to allow as a lot architectures as potential when packaging, not simply x86_64.

A second subject I’ve had on my Pinebook Pro is that it has a 64GB rootfs. Using too many flatpaks is simply very wasteful of area. In concept you could have a runtime that has your main dependencies after which a couple of Megabytes of stuff in your software flatpak. In apply I almost have an distinctive platform per flatpak put in as a result of the flatpaks rely on totally different variations of that platform or simply on totally different platforms.

Another subject is with finish customers of a few of my Flatpaks. Flatpak doesn’t deal effectively with software program that communicates with precise {hardware}. A bunch of my software program makes use of libusb to speak with sepecific units as a alternative for some Windows functions and Android apps I might in any other case want. The subject finish customers will run in to is that they first want to put in the udev guidelines of their distribution to verify Flatpak can entry these USB units. For the distribution packaged model of my software program it Just Works(tm)

Flatpak does have it is makes use of

I would not say Flatpak is totally ineffective. For sure usecases it’s nice to have out there. It suppose Flatpak makes most sense for when closed supply software program would have to be distributed.

I wish to see this be extra strict although. I would not need to have flatpaks with holes within the sandbox with a proprietary license for instance. Which is precisely what the Edge flatpak is.

It’s fairly unhappy that Flatpak insanity has gone so deep into the Gnome ecosystem that it is now unimaginable to run the good Gnome Builder IDE with out having your software in a flatpak. (EDIT: Turns out that utilizing Builder with out Flatpak is feasible once more)

I do not suppose having each app on a Linux machine being Flatpak is something I’d need, If I wished to provide builders that a lot energy to push updates to anyplace in my system with out accountability I’d simply go run Windows.