[audiojunkie]

I've been going back and reading the comments to the blog post, "Flatpak Is Not The Future", and they have been interesting. There are some good arguments FOR containerization. Some of the comments:

Quoted Post:

I’m sorry but I’m going to have to disagree strongly with you, for the same reason that “sysvinit/OpenRC/etc. is all you need” anti-systemd people are wrong. RPM and DEB are only good enough if your use-cases are circumscribed by the needs they were originally developed for.

To some extent, the containerization side of Flatpak is EXACTLY like systemd, in that it’s a “we’ve given you twenty years to fix this. We’re tired of waiting” response to people who preach about “the right way to do it” and then fail to get sufficient traction out of initiatives like the LSB.

For example:

1. I want to run an LTS distro, but I also need one or two newer apps. My choices are a PPA, which is the wild west as far as trust goes, or Flatpak, which provides a centralized system of sandboxing, allows me to easily customize the sandboxing manifest, and, if it’s Flathub, approval isn’t *fully* automatic like for PPAs.

2. Ubuntu has decided to stop packaging Firefox with APT in favour of official Mozilla snaps. Mozilla also officially maintains their Flatpak and binary tarballs with automatic updates… which one has sandboxing?

3. I want to sandbox as many desktop applications as possible for improved security. Which is less likely to cause me strife: Retrofitting other people’s packages using Firejail or just tweaking the Flatpak installs using Flatseal?

Beyond that, I’m reminded of articles like Drew DeVault’s “Developers: Let distros do their job” which say “Ship your software as a simple tarball. Don’t ship pre-built binaries” and “One thing you shouldn’t do is go around asking distros to add your program to their repos. Once you ship your tarballs, your job is done. It’s the users who will go to their distro and ask for a new package.” and brush under the rug the effect it has: “We developers should be elite gatekeepers over everyone who doesn’t know how to compile software from source”… imagine if audiophiles got to have veto power over every product targeted at the market segment of people who don’t know how to hook up a multi-component hi-fi system!

"This is apparently working as intended. They want runtimes to be a free-for-all, filling your hard drive with gigabytes of custom junk for every app."

No, this is “Red Hat/Debian/whoever didn’t make an RPM/Deb/etc. for the app I wanted” all over again… literally. Flatpak is just less willing to foist “Run alien and pick up the pieces” off on the end users in the 21st century.

"Today, on my machine, the KCalc Snap takes a full seven seconds to start up. Not just the first time after boot; every time, without fail. Seven seconds to start a calculator."

No argument. Snap’s architecture is garbage, even by containerized application standards.

"Flatpak allows apps to declare that they need full access to your filesystem or your home folder, yet graphical software stores still claim such apps are sandboxed."

Do I really need to start enumerating things GNOME gets wrong in other spheres?

The Flatpak CLI is the first-party UI and it gets announcing required permissions right. The KDE Discover plugin doesn’t make a half effort like that and just presents Flatpak packages with the same UI as native packages. Don’t be that infamous anti-Flatpak FUD site I won’t give free publicity to.

In short, this is another case of “WORKSFORME/WONTFIX: Your needs are invalid”, just like the last two decades that inspired Flatpak and snaps and AppImage and the like.

"This is the most complicated and brittle way to implement this"

The passage you quoted says “meaning that applications don’t need to do any additional work”. “Don’t need”, not “shouldn’t”. Emphasis mine.

It also omits the next sentence: “Applications that aren’t using a toolkit with support for portals can refer to the xdg-desktop-portal API documentation for information on how to use them.”

That sounds like a pretty standard “Don’t reinvent platform APIs if you can work within them” that would also be appropriate for something like ensuring reliability on the Linux Standard Base or SDL or any other means of ensuring forward compatibility with the proposed paradigm.

This argument sounds like a disingenuous case of “Any solution but mine must run up against a heavy incumbent advantage that favours my solution”. Retrofitting the platform APIs is a very elegant way to get most of the way there with little to no demand on each individual upstream developer’s time and the main reason it works as poorly as it does in my experience is that GtkFileChooserNative is a young API.

"How can Fedora justify publishing apps while masquerading as the upstream developers?"

How is this any different from the mess with Debian vs. Fedora RPM vs. OpenSuSE RPM vs. etc. when it comes to package naming? A good tool can’t magically fix a bad maintainer.

Don’t play the nirvana fallacy card when APT/RPM, Linux itself, and UNIX before it, are perfect examples of “good enough” solutions running rings around attempts to attain perfection.

The post even mentions “Worse is Better” in the next section, so I get a strong sense that this is a disingenuous article, not arguing in good faith. As I said before, people who think like you have had 20 years to come up with a solution that meets the needs Flatpak has set its sights on.

"Proponents of containerization believe it is the solution to every problem, the hammer for every nail."

More an acknowledgement that Linux can’t afford to ignore the “Windows won because it was backwards compatible with DOS. Later Windows won because all 32-bit versions of Windows are still compatible with 16-bit Windows apps. etc. etc. etc.” network effects.

Flatpak is an acknowledgement that you only argue for a clean-slate approach to sandboxing if you *want* it to fail.

Not pictured: Steam and the game running directly on the user’s native environment, like they do on every other OS.

"Not pictured: Steam spyware-ing the user’s DNS cache and doing other shady things in the name of “anti-cheat”."

"A major goal of most of these technologies is to support an “app store” experience […] Flathub only says they don’t process payments at present. It’s coming."

This is willfully blind at best.

Canonical already tried this using traditional APT-and-Deb packaging, no snaps needed. Containerized packaging is orthogonal to attempts to monetize.

All you need is a repository-based package manager (APT) and suitable metadata (AppStream)… both of which are requirements completely independent of these new packaging formats.

"Just in the past week, I’ve used several Linux apps distributed as plain binary tarballs that run on my native environment."

Oh, like my Humble Bundle games where, to this day, I have to root around through old Ubuntu/Debian package archives for libraries with the right `.so` version or google up answers for why they crash mysteriously on startup?

"GOG.com’s strategy for Linux support is just about the opposite of Steam’s, and works just like traditional installers for Windows."

…and every time I upgrade my Ubuntu, I’ll have at least one or two games where I have to go in and delete one of the bundled libraries to resolve a “crashes on startup” issue.

Not to mention, vintage games don’t have the “security updates are being released that need to make it to the end users promptly” issue.

As a retro-computing enthusiast, this reminds me of the Good Old Days™ of Windows 9x when malware was in its infancy and gamers hadn’t yet started to trickle away to the convenience of consoles before Steam made things more convenient.

"Imagine if millions of office workers used Excel on Ubuntu. How loudly do you think businesses would complain if a distribution upgrade broke it?"

An “Easier said than done.” argument. Where do you draw the line on which libraries are safe to assume will be present in perpetuity? How do you get distros to agree on it? How do you ensure they keep offering access to the same ancient versions forever? What if upstream don’t properly follow SONAME versioning for ABI compatibility? (Automatic analysis has shown humans suck at that)

How do propose that we *now* get all the distros agreeing on dependency metadata for packages they consider beneath their notice when they weren’t before.

Again, the phrase that defines Flatpak’s raison d’etre… “things the open-source ecosystem is failing to deliver on”… just like why systemd replaced sysvinit.

"The GTK problem"

I have no argument with this. As a KDE user, I agree that the “and pre-installed on the vast majority of Linux desktop” makes his argument accurate.

…I won’t use GTK 3.x now that it’s grown too many GNOME-isms and still lacks stuff Qt provides by default like minimal toolbar customization, but I agree with the idea to arm-twist GNOME into being better stewards of it.

"Is Flatpak Fixable?"

Let me know when you manage to get sufficient buy-in on that “declare library dependencies that don’t care about Debian vs. Fedora vs. OpenSuSE vs. Arch vs. … naming conventions”, “Convince all app developers to retrofit their apps for a new API”, and “Deprecate install-time permissions so aggressively as to kill off any momentum already gained”.

Final Verdict: Talk is cheap. Prove you can do differently than the last 20 years of APT and RPM that inspired these packaging systems and I’ll listen.