Linux desktop leaders unite behind Flathub app store. Here's why

Flatpak is great for self contained apps, but it seems problematic when it has to reach outside the sandbox. I ran into this in VSCode and with CUDA video processing filters, but I'm sure there are more examples.

And thats what distro packages are for, I guess.

On Win32 you don't static link everything, all OS functionality is provided through shared libraries (aka DLLs), the OS provides a ton more functionality out of the box (GUI, multimedia, input, graphics, etc) than you'd get with Linux, which while it provides strong backwards compatibility is just the kernel and practically everything else a regular desktop program uses is provided by libraries talking with it.

The big difference isn't static vs dynamic but that on Windows the DLLs that come with the OS do not break backwards compatibility so applications can rely on them whereas on Linux only a very tiny number of libraries do not break backwards compatibility (from the top of my head that'd be glibc[0], X11/Xlib/etc, curl and OpenGL). Most importantly the libraries for making a GUI application do tend to break backwards compatibility (see the breakage in Gtk1->Gtk2->Gtk3->Gtk4 and Qt1->Qt2->Qt3->Qt4->Qt5->Qt6 though with the latter being C++ they can't help it as C++ itself makes it harder with not having a stable ABI). Not all do (AFAIK Motif has been backwards compatible since the early 90s) but those that don't aren't that common (for unrelated reasons - e.g. most provide only a small fraction of the functionality Gtk/Qt provide or, in cases like Motif, the license was unpopular with FLOSS developers so no ecosystem was built around it).

[0] they do break compatibility for programs using unsupported APIs though

I actively use both Nix and Flatpak, and my perspective is that they're tuned for different purposes:

- Flatpak doesn't require apps to be rebuilt when the runtime changes, whereas Nix would require a rebuild. This is, of course, an intentional selling point for Nix: you don't have to worry about keeping track of ABIs and the like. This is, however, less fun when you have to update a large amount of applications for little reason. - When using flakes, it's easy to end up with a lot of extra disk usage because of a proliferation of different nixpkgs versions. Flatpak's runtimes help avoid this, since apps target a runtime version and can run under any individual commit for that version. - Flatpak has a massive amount of internal infra for sandboxing that would take a moderate effort to reproduce elsewhere. - This also means that running Flatpaks always involves new user namespaces; this can't just use environment variables like Nix does. - Flatpak's entire setup is more tuned towards GUI applications, with support for stuff like swapping out the graphics drivers. (nixOS can ofc do this, but you need nixGL otherwise.) - Flatpak has support for downloading non-redistributable files at install time and placing them in the same location as the application's main files. - Flatpak's summaries that it downloads from the server are much smaller than nixpkgs checkouts. - Flatpak dedups individual files across apps.

Really, it's just that Flatpak prefers keeping the build process and usage simpler to focus the energy on sandboxing, leading to design decisions like the more straightforward runtime/app split (easier for a user to understand / manage) and all of the built-in extras for graphical applications. Nix has a significantly more complex UX but is infinitely more flexible and also far better suited for development environments.

If your thought is "most of this isn't structural", that wouldn't be incorrect: there is no reason that:

- building flatpaks couldn't use a more nix-like model - nix couldn't add sandboxing and summary support on top

Heck, you could probably build a Flatpak from a Nix derivation, if you figured out how to separate the "runtime" and "app" parts. But at the end of the day, every tool has some limited degree of development bandwidth, and as-is, Flatpak and Nix just optimized that bandwidth for different targets.

You're listing one of the biggest reasons flatpaks was even created as the only benefit. The reason it got some attention lately is the growing interest in immutable distributions where flatpak is sold as the userspace package manger while ostree handles the root system.

There you have it. Apples and oranges.

Flatpak is great! Flathub on the other hand... The app submission process is very convoluted and the documentation is super vague.

Snap is much easier to publish and a joy to use with the dashboard and analytics. I hope Flathub improves their submission system and documentation because it's still a mystery to me.