Flatpak Is Not the Future

> Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which.

At the same time, the tools which solve this really shine. You inevitably run into these issues with random third party dependencies on other platforms, too, but it's further from the norm, so you end up with awful bespoke toolchains that contain instructions like "download Egub35.3.zip and extract it to C:\Users\brian\libs."

Developers on GNOME deal with this regularly, partially because of our lack of a high level SDK. So one of the tools we have to solve this is first class support for flatpak runtimes in GNOME Builder: plop a flatpak manifest in your project directory (including whatever base runtime you choose and all your weird extra libraries) and Builder will use that as an environment to build and run the thing for development. This is why pretty much everything under https://gitlab.gnome.org/GNOME has a flatpak runtime attached. It's a young IDE, but that feature alone makes it incredible to work with.

Yep, as I understand it the Snap thing is also obsolete information. Older snaps are still slow, but new snaps are more efficient to start, and that has been the case for a while now.

How so? I feel like this is just unfamiliarity / resistance to learning. It's not like these new tools prevent you from accessing their internals. The internals are all still "right there." They just have internals that have been engineered for efficiency over composability or observability.

For example, journald. People know and understand "rotated-gzipped text .log files in a /var/log directory." People don't know, but more importantly, don't want to learn, this: https://systemd.io/JOURNAL_FILE_FORMAT/. It's a simple format, that makes perfect engineering sense as a format optimized for the goals it's trying to accomplish. But it's not text — not the thing a greybeard sysadmin has spent the last 40 years working with — so it's "hard."

Instead of just learning this format and writing tools to interface with it, people instead think of this data as being impossible to access, somehow "locked away" behind journald / journalctl, as if there were some kind of DRM put into your OS prevent you from accessing your own log data.

As it happens, though, journalctl already builds in support for manipulating this data with POSIXy text-based tools — getting your journal as JSON is one `journalctl -o export` away.

But nobody knows about these features (I only just learned about it now, from the link above!), because nobody talks about these features, because the tooling already solves 99% of the real-world problems people encounter, and so it's very rare to actually need to script against the journal.

And if you are in that 1% use-case, maybe you're e.g. engineering a distributed log-ingest system for efficiency; in which case you wouldn't use `journalctl -o export` anyway, but would rather link to journald's C API to parse the journal directly, because that's what's most efficient, even if it's less convenient/UNIXy.

-----

This is similar to e.g. how people pushed back against SPDY/HTTP2.0 for being a "less debuggable" protocol, just because it's binary rather than text-based.

Of course, it's extremely rare that anyone needs to actually debug the transport, rather than debugging their own application-layer protocol they've built on the transport. And because every server and client that speaks HTTP2 still also speaks HTTP1, every application-layer protocol flowing over these links can just be debugged using HTTP1 messages.

But even if you have that 1% use-case where you need to debug the transport, there are simple POSIX-pipeline-y tools to bijectively map the binary wire representation to a text-based one.

But again, when you hit that 1% of use-cases, you're probably a professional doing something weird, such that you probably want to pull out WireShark to analyze the complete nested app-in-HTTP2-in-TLS-in-TCP-in-IP-in-Ethernet packet capture in its original binary form.

And so, even though those bijective HTTP2-to-HTTP1 observability tools do exist, nobody thinks they do, because nobody talks about them, because everybody with the 1% use-case is likely solving a large-scope problem for which the simple UNIXy solution is "underpowered."

I usually steer clear of these types of discussions because I find the arguments ultimately pointless in the end. The users pick the winner based on their experience regardless of the merits of the systems available. Also I'm certain I'll come out of this worse for wear, as is the experience whenever one crashes a heated debate among engineers arguing over which is the better standard. So I'm going to hastily step into this den of wolves and jump out again.

The fundamental issue I find with all these distribution systems is that they always seem more designed to justify a computer science degree rather than solving the problem in a user friendly way. And that applies to debs and rpms as well. All the solutions seem so over-engineered to the point that only engineers have a hope to get any kind of consistent usable experience out of it. Certainly you can try to hide all that complexity behind a nice GUI with icons and layouts, but that only works so well until something goes wrong. And then the user is stuck juggling a broken system and waiting for a reply on a support forum that may never come. That also mirrors my views on why Linux has yet to break into the mainstream desktop market.

But lets go even further, another fundamental issue. Sometimes it feels like these systems are working to justify a basic design choice of Linux that's overstayed its welcome. The idea to separate libraries and binaries was a fabulously beautiful engineering idea to fix a problem that stopped being an issue a decade ago. When your system has 32mb of storage, it makes sense, but less so when you can buy a 2tb solid state drive for $120 on Amazon. Counter to the argument in the article, storage is cheap and becoming cheaper at such a rate that continuing this philosophy will appear more odd by the day. And now we've officially come full circle and engineered it away with flatpak and appimage.

In an ideal world, these perfect systems should work beautifully. But users aren't perfect and neither are developers. That's why I now value software not by the novelty of how it solves a problem but in how few parts it can do it. For all Elon Musk's personal issues, he was letter perfect about one thing. The best system is no system. The best process is no process. For every additional step of complexity you add when solving a problem, you gain three additional problems. 1. You have to maintain it across the half-lifes of developer interests. 2. You have to teach users and developers how to use it the right way, a nearly impossible task. 3. All the systems that rely on it become more complex, duplicating problems 1 and 2 ad nauseam.

For me part of the answer was missed 12 years ago with AppImage. It works so well that I find myself breathing a sigh of relief whenever I find an application I want that uses it. That's because I know it'll just work. It's a testament to the usability of AppImages that it's still in use years later even without support from major distros. I think the linux community at large is at risk of missing something very good there. At least for user facing programs, it works wonderfully.

Ex-(long time)-Gentoo user here. Linux packaging is insane without resorting to something like this. The problem could be fixed but it would require coordinating long-term-stable (like: 5 years, minimum) versions of an entire, fairly large set of basic libraries, across (at least) every distro that matters. For desktops this would probably have to extend to long-term-stable versions of X/Wayland and their related libs, plus QT and GTK.