I still don't get the whole #flatpak thing (vs static + dynamic linking). It all seems so difficult and complex. Why not just...
(1/?)
Also, #flatpak requires the OS to implement the flatpak runtime. Got a new OS (/distro/DE)? Well now it has to implement the flatpak and dbus apis before flatpaks work, instead of just relying on individual shared libraries.
(1/2?)
@rugk Somebody else who has now deleted their comment enlightened me to the fact that Flatpaks do a few things well:
Among other things, I'm still really upset that Flatpaks reversed certificate progress for me by years, for not enough benefit to offset.
@rugk I had also argued that I'd prefer distros adapting and having different versions of shared libraries to provide distro/DE-specific features, because the Flatpak alternative requires going through the DBUS which I argued has a few disadvantages:
@rugk Oh but Flatpak Portals also enforce a single Response-style results. Normally I'm very much against forcing an API style, but I've many headaches working with different libraries that all returned their results in different manners, so from a practical standpoint I'm leaning towards Portal Responses.
@rugk For my concern about having to create a new Flatpak runtime for a new OS/distro/DE, I was assured that the Freedesktop runtime has few/no dependencies, so it should provide Flatpak support out of the box even if it doesn't integrate well - which is fine, since in this hypothetical a new OS/distro/DE is being made, so we can live with that, plus it could provide a foundation for the developer(s) to modify incrementally as they have time. I have no way to verify this though.