@glyph @miss_rodent But things like Flatpak exist.

@cthos @miss_rodent do they? experts seem to disagree

@glyph @miss_rodent I mean, I run several different distros across several different pieces of hardware, with different desktop environments and I can install Flatpaks on all of them, so yes?

@cthos @miss_rodent FWIW it's not *impossible* for this to work, but it is wildly beyond *cost-effective* for most ISVs

@glyph @cthos @miss_rodent Then the community should definitely organize to make Flatpaks work more reliably across distros. What are the biggest problems that make it necessary for app developers to put in distro-specific work even when targeting Flatpak? (I have no experience with this yet; my main desktop app project at this point is a remote desktop access tool, so that's a whole other can of worms.)

@matt @cthos @miss_rodent flatpak does not address the deficiencies or the expense of interacting with a zillion different compositors, or for that matter different audio systems or GPS daemons. the kinds of apps that need to interact with the platform need an API shaped in terms of d-bus endpoints, and the problem that flatpak addresses is one of .so files. flatpak also requires manual management of filesystem permissions, which means apps are just slightly dysfunctional

@matt @cthos @miss_rodent the main thing is that it is missing a macOS style powerbox file dialog (which, ironically, was originally invented in linux, via bifrost in OLPC)

@matt @cthos @miss_rodent I think *most* telling though, the thing that is downstream from all the various subtle upstream problems with flatpak, is why does the platform still have “native” apps and “flatpak” apps as separate categories? is there an OS yet which is ONLY a runtime for flatpaks and doesn’t have a privileged class of “good” apps which don’t have to live in flatpak jail?