Package Managers that are not the one your Operating System Ships With on the Desktop are Stupid and everyone should agree with me.

An Essay By Lucas.

(This will be long)

((I am not sorry))

(((I will now begin)))

First, some terminology:

"system package" - the apps and dependencies that ship with your operating system, or built by you with the tools and libraries on your Distro.

"external package" - a snap / flatpak / appimage / anything that's not shipped by your Distro, or compiled against system libraries.

I know there are differences between the external package systems. I'm ignoring all of the differences, because they all suffer from the same fundamental flaw: they're solving the wrong problems.

So, the "problem": Maintaining packages is hard. I'm not contending that.

People say that external packages are "just as fast" - they are not. You can measure the difference. I have measured the difference. On SuSE Tumbleweed Gimp starts 17% slower from a flatpack, or half a second. "But it's just half a second" you say. I genuinely don't see why "it's nearly as good, so it's OK" is an acceptable answer. As Mr Incredible said: we're celebrating mediocrity.

People say that the flatpak versions are more up to date. The version of GIMP in Tumbleweed is the same as the version that's installed via flatpak, but the flatpack version requires a futher 867Mb of dependencies to be installed on top of the 127Mb for Gimp, which means they need to be loaded from disk, and put into RAM. Other programs from Tumbleweed can use the dependencies pulled in by Gimp, so there's a chance the GTK+ libraries are already in RAM, waiting to be called.

Firefox is another example. The Tumbleweed version is the same version as the flatpack version. Firefox is already installed by a default install. Installing the flatpak pulls in another 547Mb of dependencies, in addition to the 140Mb needs for firefox itself.

"Yeah, but they're running in a container! It's more secure!" With both of these peices of software, if I start one version and then the second, Gimp comes to the front with whichever version I start first, and firefox starts a new window - but about:help says we've just forked another instance of the already running binary. If they really were containerised and as secure as people would have me believe, I should be able to run two copies of both gimp and firefox.

The fact that they're finding the "other" running application and bringing it to the front means it's not nearly as sandboxed as people want us to belive.

Back to the topic of dependencies, with ones that ship with your distro, you "know" where they came from, and what version they are. They're (hopefully) vetted by people that (hopefully) have an active interest in making their distribution as good as they can make it. My test Tumbleweed system has two flatpaks installed (gimp, firefox), and four copies of libssl, one system package, and three external packages, two of the external packages are identical in filesize.

I've been told that flatpak will deduplicate dependances. Clearly this is also incorrewct, or I'd only have one, or at most, two, copies libssl inside my flatpak overlay.

How are we to ensure that everyone using libssl as a dependency updates it when there's a new CVE? What if they refuse to update a version because they'll have to refactor some code, inviting potential 0-day exploits in the future? At least with the versions packaged with the distro, you know where to go to see if a package's dependencies have been updated.

But most importantly: why do we need more than one libssl on the system anyway? The one that ships with the OS should be the preference.

"RAM is Cheap" or "SSDs are fast" isn't the answer, either. We're just adding bloat and compute overhead to the linux desktop experience because we're trying to solve the wrong problems. Just because I have a combined 62GHz of CPU power, it does not mean I want to spend it all loading different versions of the same libraries. I want to use it for my chosen task.

So, what problems are we trying to solve? Essentially: "Different people like differnt things" - Some distros are nothing but the bleeding edge versions of everything, with the most agressive compiler optimisations enabled. Some are a few versions old, but with all of the latest security patches, and *all* of the hardening enabled. Most distros are somewhere in the middle.

People will run the flatpak version of something instead of the hardened version from their repos because it's faster. Yeah it's faster, all the security flags have been turned off. I would say that these particular people are running the wrong distro for their use-case. In the case of firefox on tumbleweed, doing the speedometer 2.1 test from browserbench.org the flatpak is actually faster (~180 vs ~140)

But the flatpak is also missing anti-alising on the fonts. So it's faster, but a feature which has been a staple on the desktop for over 2 decades is also missing. This is why Distros exist: to ensure all of the parts work together.

If you want peak performance and the latest software, you probably want Tumbleweed or Arch. If you want a reliable workhorse that with months of uptime, you probably want Debian Stable or RedHat. If you want to experience the joy of punching yourself in the genitals, try Ubuntu.

If you develop on arch and the oldest package on your system is three days old, expect trouble getting your software to run on RedHat where the most recent package is three months old. Library developers SHOULD be releasing libraries that are interface-compatible across a minor version numbers. There should not be a case where lib-1.2.3 will run, but lib-1.2.4 breaks. Those breakages should have gone into lib-1.3.0 and time should have passed for the various distros to adjust to the change.

This falls to the library maintainers to not break downstream applications, making life hard on applicaiton devs. By the same token, if lib-1.3.0 came out last week, you can certianly test against it, but don't expect all of the distros to suddenly have the new library because it's been released. You don't need to be on the beeding edge all of the time, give it 6 months before you require it as a hard dependency.

The work of packaging an app for every OS shouldn't fall to the application developer, either. Provide a robust build script, and users that are on unsupported Distros will probably build it themselves. Hopefully you get bug reports or pull requests.

We absolutely need better build tools. "make" was great back in the day, but now we have well... the list is long and exhaustive. gone are the days of `./configure && make clean && make && make install` There are too many ways to even build an application. But, different people like different things.

BUT. If we do need to re-invent the wheel, why not make it round this time? Why not internet-scale build labs? Instead of folding@home or BTC mining, how about dedicating some CPU to building? Automated bug reports collated by LLMs from a few thousand real systems would provide better debugging information than one dev trying to guess what 1000 users are using.

Collate the results, and you'll either end up with a lot of release binaries for a lot of system configurations, or a very good idea of which commit broke compatability with which dependencies. This could even allow us to provide hardened binaries along side so-many-cflags-they-almost-dont-work binaries. Build-hosts can announce what they'll build with. App developrs can announce what they want built.

If there's a match, the job gets deployed and the build takes place. How would we protect against malicoius actors returning binaries that have been tampered with? checksums! if only one build comes in from one host, don't make it available until it's either verified by a known-safe builder, or there have been multiple builds on the same configuraiton come in with matching hashes.

That does sound like a lot of work, and probably more overhead than having 15 copies of libssl on my system, but if Gentoo can make a whole distro around building from source, surely someone can make a build system that actually makes life easier for their fellow deveopers, and delivers performance gains for the end users at the same time!