> Maybe I'm just old-fashioned, but I don't like Flatpak (or Snap or AppImage).
That's certainly your prerogative, and I hope traditional distro packages stick around — I think they will, since they are the basis of so much fundamental infrastructure. And I'm sure there will be a cottage industry of converting flatpaks to .debs or .RPMs in the future if flatpaks become the dominant way of distributing GUI software :)
> They still don't seem to have solved all the desktop integration issues.
They haven't solved all of the issues yet, but while snaps and appimages are still struggling mightily, flatpaks seem to be making pretty good progress on that front, at least if you stick with modern Electron (not the old version Discord has!), QT, and GTK applications. And I think generally all of the issues are solvable, and not only that, but solving them will leave the Linux desktop in a much better place than it was before, because we can build in broker-based sandbox permissions, and things like making each GUI toolkit automatically use the native file-picker of the user's desktop environment (something GTK4 and Qt5 support via the relevant Flatpak portal).
> I don't trust the app developers to be on top of security issues. I trust Debian maintainers (despite mistakes in the past) to keep my system's base libraries up to date and patched. Why would I trust some random developers of some random app to do the same?
I understand where you're coming from here and this is a common objection to sandbox packaging solutions, but I think there are a few problems with it.
First of all, Dependabot exists: all maintainers of Flatpaks need to do to keep their dependencies up-to-date is enable it for their application repository and then just keep an eye out for emails from the bot and approve the automated pull request when those emails show up. You can do it all from your smartphone! I've done it. Importantly, there would be absolutely no need to manually patch system libraries or backport patches, or any of that nonsense, if we didn't adhere to the distribution model of packaging, because then there would be no delay in releasing libraries, you could just get the libraries directly from upstream, and there would be no point releases or anything of the sort. So a lot of the very appreciated and difficult work that distribution maintainers have to do every day is work that is made necessary by the model of distribution in the first place. So yes, we'd be expecting application maintainers to keep their dependencies up to date, but that job would itself become much easier.
You might say that part of the distribution maintainers' job is to actually inspect library updates from upstream to find vulnerabilities or whatever, but there are far too many packages and dependencies for them to actually do that. I very highly doubt they are actually trawling through all of the code to try to spot vulnerabilities, and that seems like a job best left to the far greater number of much more knowledgeable eyes directed at open source libraries upstream.
This model doesn't just eliminate a lot of unnecessary work either — it distributes the workload; now, instead of one team having to break themselves to keep every system library up to date, everyone shares the burden of keeping the libraries they use up to date. This does open up the possibility of lazy application developers not pressing the "fix my dependencies" button, to be sure, but the amount of dependency hell and cross-distribution portability problems that packaging dependencies with applications solves I think outweighs that concern. Security isn't the only consideration here, there's also other practical considerations. Otherwise, we'd all be using Qubes xP
Furthermore, it should be noted that many of the larger dependencies of Flatpaks, at least, are handled through platforms and platform extensions and SDKs, where bundles of interrelated dependencies are actually separate packages from the application Flatpaks, and thus can be updated by upstream independently. The key with them is just that they, too, like regular applications, become insoluble independent of distribution, and capable of being maintained by upstream as a result, and you can also install multiple versions of them if necessary.
In the end, I think it's a trade-off. But I seriously don't think dynamic linking and having to keep all of the versions of every package on your operating system in perfect lockstep to keep them all using the same version of a dependency, tying your system library versions and app versions and OS versions itself into one big tangled ball of interdependency, where you can't upgrade application B because it shares a dependency with application A and would require a newer version than application A knows how to use if you upgraded it, and having to continually backport security patches from newer versions of that dependency to the version that your system is still in lockstep with is a sustainable and sensible model, especially because of how much work it foists on one single team.