flatpak
flatpak isn't eliminating any effort, and i think this particular trail of thought is damaging. it is simply moving the problem somewhere else. the amount of effort expended isn't just magically vanishing into the ether.
in some cases this not only comes at the expense of user choice, but also subverts user expectations. for instance, i am unsure why kcalc needs a proprietary media codec to function. the user had no choice in this matter, nor are they informed. they're only told it's the "kde platform". this is apparently all users need to know.
flatpaks using the platform model, ignoring how much it feels like passing around a .net runtime, allow devs to rely on a common set of libraries and runtimes. for anything those platforms don't provide, you're on your own. should a vulnerability be found in these - given there are no package maintainers patching the single instance of openssl you have in the distro repositories - you wait for upstream of every single one of the apps using this library to recognise and fix the issue. apparently, this has never happend and never will, i guess.
at the moment, everyone mostly relies on flathub. it "is run by the community, and is not owned by any single company or individual". that's great, but should anything happen to flathub, what then? do we:
- use other flatpak repositories (which is basically what the non-flatpak model is); or
- go grab them direct from the developers (which is what package maintainers do now in the non-flatpak model)?
if the second, where are the common platforms coming from now?
there are technical execution issues i have with the existing design, but they can (hopefully) be improved over time. a couple of good instances are browser sub-sandboxing, and child process management (e.g., steam launching a game undetected by host). both of those are still active issues within flatpak that seem easy to write off as gamer moments, but they are legitimate technical concerns caused by other assumptions made about how users will use the flatpak model.
the security sandboxing functionality is great. i wish that was everywhere. it is not, however, magic, and i think using it as a standard bearer is disingenuous. it is so unlike magic, in fact, that users are told to ignore the big "unsandboxed" warning in flatpak app stores, or otherwise disable it to fix other issues (setenforce 0, anyone?), treating them to a brand new alert fatigue before the service even becomes mainstream and hoping that it can be reversed when sandboxing becomes actually plausible with apps that conform to the flatpak model. they currently don't, which is remedied by package maintainers putting in the effort.
one of my favourite things about flatpak currently is the following patch note (emphasis mine):
Two new features are present in Flatpak 1.16 that improve the handling of devices:
The new input device permission Support for USB listing
The first, while technically still a sandbox hole that should be treated with caution, allows some apps to replace --device=all with --device=input, which has a far smaller surface.
so instead of doing it right, we're doing it fast. or something.
there are some great things about flatpak, and i absolutely don't believe the existing common model is perfect, but flatpak is not a healthy way. i'm not going to pretend i have an answer, but i'm extremely reluctant to believe the current iteration of flatpak is it. perhaps flatpak 2?
as an aside, i'm not a package maintainer for any distro anymore, but i would imagine they do not appreciate being referred to as "gatekeepers" in what was clearly a derogatory tone. the gatekeepers argument is actually kind of ironic, given the "manual review process" is such a selling point of the authenticity of flathub. in many cases, the patches made by maintainers are there - to put it bluntly - to fix upstream's mistakes. i wouldn't call patches ripping out tracking or some such functionality as mis-packaging, either.