Flatpak Is Not the Future

[0]: https://en.wikipedia.org/wiki/Common_Desktop_Environment

For example Ubuntu is trying very hard to push snaps. In contrast to flatpaks only they can run the store for it so there's clearly a motivation of vendor lock-in.

This kind of thing makes me suspicious and more critical of new tech. I'd first want to see if it offers me any value. In this case I don't see the big benefit even though flatpak doesn't seem to carry the lock-in that snap does. But I like the optimisation of dynamic libraries and the way I can update openssl once and have all the apps patched that use it.

Systemd is a different story. It's open enough but a bit too heavy and complex for my liking. It's not bad though and I use it on some of my boxes. Alpine is working on an alternative based on s6 and I'll probably end up using that when it matures.

Anyway I didn't choose Linux/BSD because I cared about having the same as everyone else :) Being able to deviate from the beaten track is one of the benefits of these. I currently use FreeBSD because it has the least corporate meddling right now.

I'd argue they never did. Hard drives have always been slow and when they were the primary means of storage on the PC, people were always trying to find ways to speed things up. Now it takes seconds to boot rather than minutes.

"Laptop manufacturers are switching to smaller flash drives to improve performance while preserving margins. Budget laptops circa 2015 shipped with 256 GB or larger mechanical drives. Now in 2021 they ship with 120 GB flash. "

This is outdated information. I just checked Lenovo's store and while they do have a super low end machine at $200 with 64Gb of EMMC, their real budget model laptops start with a 256Gb SSD. The standard ThinkPad we order this year for users had a 1Tb SSD. Is it budget? No. But building towards the lowest common denominator is rarely worthwhile without good reason.

"Chromebooks are even smaller as they push everything onto cloud storage. Smartphones are starting to run full-fledged Linux distributions. The Raspberry Pi 4 and 400 use an SD card as root device and have such fantastic performance that we’re on the verge of a revolution in low-cost computing. "

Chromebooks and RPi's are not PCs. Yes, some enthusiasts use them that way but that is a niche and done by people who know what they are doing. They can easily enough avoid flatpacks.

Linux is a big place and its versatility allows for designing distros around multiple use cases. Flatpack and Snaps are meant to make software distribution easier. Constraints such as storage are not a primary concern for most users. Most machines have enough. Their mere existence does not mean other methods of deploying software aren't available so if storage is a constraint, then simply don't use them.

A lot of the arguments against Flatpack and Snap seem to be based around "it's not good for my usecase" ok. Then don't use it.

"Each app with a new runtime adds another hundred megs or more of RAM usage. This adds up fast. Most computers don’t have enough RAM to run all their apps with alternate runtimes. The Raspberry Pi 400 has only 4 GB of RAM. Low-end Chromebooks have only 2 GB. Budget laptops tend to have 8 GB, mostly thanks to the bloat of Windows 10, but these app packaging solutions are catching up to it."

My case in point. Still referencing niche machines. Most RPi's are used for a dedicated purpose. 99% of Chromebooks never exist Google's ecosystem for it. And their concept for what qualifies as a lot of memory is, I think, out of touch. 8GB is the base for an x86 PC. Not a Chromebook but a real PC. Many have 16 gigs and its not uncommon to see up to 32 in laptops and even more in workstations.

"Why shouldn’t storage shrink anyway? Software should be getting more efficient, not less."

My knee jerk response is "why?". My more thoughtful one is that efficiency can be measured in many ways. Resource usage becomes inefficient when the user determines it is. And everyone has a different idea of where that lies. Nobody is multitasking more than a couple of applications at any one time on a PC. Servers are different but Servers aren't an intended use case for Flatpack and Snaps. If I can run the software I want at acceptable performance then its resource consumption is efficient enough. But you know what Flatpacks are more efficient with? Time. I don't have to deal with dependencies. I just tell it to install and it works. Given how awful the application management experience is in Linux traditionally, I am willing to take the downsides for that massive upside.

"Such an app can drop a malware executable anywhere in your home folder and add a line to your ~/.profile or a desktop entry to ~/.config/autostart/ to have it auto-started on your next login. Not only will it run outside of any container, it will even persist after the app is uninstalled."

I think he has a point with security. Permissions can be vague and misleading. And they do have a supply chain attack vulnerability. But that's true of any software you get from the repository, store etc. If the official Fedora's official Flatpacks can have malware then so can their official Repo.

His section about identifies clashes is not an inherent problem with Flatpack but rather a procedural problem with Fedora and Flathub. I think its weird he brought it up when he started the article saying he wouldn't include easily solvable issues. Yet here we are.

"You would think that these packaging mechanisms would embrace simplicity if they want to attract software developers. In fact they are doing the opposite. "

This is the efficiency problem again. Define simplicity. What is simple in one area is complex in another. The fact is nothing as complex as software on a computer can be simple everywhere. If it were it would be useless. So the question is not how to make it simple. It is where are you placing your complexity. Traditional package management places the complexity on the user while keeping the software simple. Flatpacks place the simplicity on the UX while making the software complex. None is inherently superior. Its all about design goals.

"All of these app packaging systems require that the user have some service installed on their PC before any packages can be installed."

And? All software has dependencies and a lot requires some kind of run time. Does he also consider all Java software problematic because they require a JVM first? What about all web based applications requiring a compliant browser? This is a non issue in context of how everything else works in the 21st century.

"A major goal of most of these technologies is to support an “app store” experience: Docker Hub, Flathub, the Steam Store, Snapcraft, and AppImageHub (but not AppImageHub?) These technologies are all designed around this model because the owners want a cut of sales revenue or fees for enterprise distribution. (Flathub only says they don’t process payments at present. It’s coming.)"

Conceptually there is no difference between an app store and repository. They are the same thing. App stores are just repos that are more user friendly.

"This is very far from the traditional Windows experience of just downloading an installer, clicking Next a few times, and having your app installed with complete desktop integration. This is true freedom. There are no requirements, no other steps, no hoops to jump through to install an app. This is why the Windows Store and to some extent even the macOS App Store are failing. They can’t compete with the freedom their own platforms provide."

I didn't expect him to advocate for the windows model. And I actually agree. Windows handles application management the best. However a lot of the criticisms he gives Flatpack would apply to windows too though. You are guaranteed to end up with multiple copies of certain dependencies because Microsoft's answer to dependency hell was to let developers ship their dependencies with their product and not have to care what everyone else had. This is extremely space inefficient and can make for ugly under the hood management but it works very well. The author misses that in his article because he just measures the size of an installer, often Windows software ships not as one file but as many and the install.exe merely orchestrates the process. Again, its all about where you place your complexity. In Windows world the complexity is rarely encountered. Apps get to bring their baggage with them and decide where it all goes. This means program files can get ugly and inconsistent and you may have to learn the behavior or individual software but it usually works the first time.

"The Current State of Backwards Compatibility"

I have news for you. Linux's biggest problem here isn't that new revisions break compatibility. Its that old versions can become unavailable. The repo model of software distribution lends itself to "link rot" Load up an older version of Ubuntu and it cant talk to the repos anymore. The servers are gone. And since until recently almost all software was distributed this way and managed by a package manager you effectively can't get software working in old Linux. Software preservation becomes monumental if not impossible. With older windows versions, if I have the install media whatever form it may take then I can install and use the software because it shipped with all of its dependencies included. No nebulous server required. DRM notwithstanding of course.

RedHat did not create libcontainer and it was never rewritten to go (it was always go). libcontainer was started by Michael Crosby at Docker as a replacement to execing out to (at the time unstable) LXC, later donated to OCI (not CNCF) as a piece of tooling called "runc", which is still in use today. As part of OCI RedHat and others have certainly contributed to its development. libcontainer lives in runc, and is actively discouraged to use directly because go is really quite bad at this case (primarily due to no control of real threads), and runc's exec API is the stable API here. Side note: much of runc is written in C and imported as cgo and initialized before the go runtime has spun up. That is not to say libcontainer is bad, just that it is considered an internal api for runc.

RedHat did end up creating an alternative to runc called "crun", which is essentially runc in C with the goal of being smaller and faster.

-- edit to add more context on development in OCI