Back

@cas (1) app devs are generally not able to and should not be required to support all possible distros, platforms, and use cases (2) distro packagers quite literally protect users from app devs by auditing changes.

i understand it can be annoying to have your release cadence block on an independent review, but there is actually a reason for that. flathub is not auditing every new upload and its entirely separate mechanisms to compose code together further inhibit auditability, and often break because there is no distro packager specifically invested in maintaining a complete working system

@cas like half of the time when a project only exposes a flatpak package it's also just a massive electron app and it's clearly used because the app devs want to do as little work as possible and take shortcuts and it really sours me on the idea that flatpak is used because app devs actually care more about controlling the user experience

@cas this is an intentionally hot take in line with OP and i would love someone to show me an example of where flatpak allows app devs to curate the experience for their users in ways a distro package can't as opposed to just allowing them to avoid caring about how easy their work is to package

@cas like spack is also a unified package manager not tied to a distro, and app devs could very well provide a spack recipe for their package without coordinating with distros or even with the spack project (this means nobody from spack audits the changes as we do for the packages we support upstream).

spack does not involve an entirely separate filesystem abstraction, but instead just installs to a checksummed directory path which can be easily consumed by other packages: my re2 rust wrapper used spack this way, to build on any platform and then plug into cargo

@cas idk there are ways to achieve what flathub provides for app devs without engaging in an entirely separate deployment method which is harder to audit especially since it doesn't even use a normal filesystem. i think it's worth interrogating further what "app devs" are actually using flatpak for, and why having someone else audit code changes might be important

@hipsterelectron imho there are a lot of good technical and process critiques one can make of flathub and flatpak (and to be clear, my post isn't defending flatpak/flathub so much as it is dunking on fedora flatpaks for making the same mistake bad distros do and pissing off upstream).

as a distro maintainer I very much appreciate the distros packages I use, though notably most of these aren't GUI apps.

but the fundamental problems remain:

1. Consistent app experience
2. Sandboxing

To get (1) you need to ship a consistent environment on all distros, and have app developers use that same environment during their development/testing.

To get (2) you need to have good APIs (like xdg-desktop-portal), some tech under the hood (be in bubblewrap or micro-VMs in the case of SpectrumOS) and you need someone to meticulously describe everything the app needs access to, something which is often unintuitive, with the app developer being the best candidate, obviously.

Nobody who I've spoken to who works on Flatpak/Flathub thinks the tech is /good/, it's a step up from the literal zero sandboxing of most distros. And it's the only solution that seems to be nice enough to get people to use it (both app devs and users).

I fully expect that we'll get better sandboxing tech, i /hope/ that we'll get better solutions for packaging (because afaict the current situation is absolutely gross), and not least that we get better "runtimes" because it's abhorrently wasteful to pull so much stuff in that is already installed locally just to have a consistent environment, especially when it's all bloated glibc stuff.

And yes, we absolutely should have better review processes in place for code. Currently flathub is pretty understaffed afaik and not really set up for this. Most of the focus is on making the app pages look good, having good icons, screenshots, etc (work that is very undervalued imho). There should be people fulfilling the role of traditional distro packagers by doing more comprehensive code review, 100% agree.

But yeah, to summarise, I think flathub is basically doing EEE but FOSS, and if the end result is that apps look/behave more consistently and we manage to make Linux actually appealing to non-technical users, I will be very happy.

@cas @hipsterelectron "doing EEE but FOSS" sounds like a very bad thing.

"and if the end result is that apps look/behave more consistently" sounds like a euphemism for monoculture.

"and we manage to make Linux actually appealing to non-technical users" <- I don't buy the idea that everything needs to look and feel exactly the same to be acceptable to a broad audience. It rubs me the same way as the claims that Mastodon/fedi can't be. It's a very corporate branding way of thinking.

@dalias @hipsterelectron

ehh yeah that was not very delicate wording.

i really just meant the app store aspect.

and that apps behave consistently across distros/platforms. Fractal on Fedora should behave the same as on my postmarketOS laptop. Unless your distro for some reason makes specific changes to software that you as a user are aware of or opted into.

but no, i absolutely dont buy into the bullshit monoculture/minimalism/artless BS. probs shouldn't have gone on a poorly thought out ramble about flatpak. for what it's what, it's something i've changed my mind on multiple times for different reasons, and have discussed at length with people who work on it and distro devs.

@cas @dalias what does "behave consistently across platforms" mean? i do not understand how distros affect this property

@hipsterelectron @cas @dalias For instance, Fedora shipping a broken OBS package that they're currently being threatened with legal action over by the OBS developers.

Flatpak and Flathub provide a known functioning base that the OBS team has decided to use, and a distro is actively harming that by doing their own thing.

@kylegospo @cas @dalias gonna need at least 1% more info than that i'm not familiar with every development across all of linux

@hipsterelectron @cas @dalias https://www.gamingonlinux.com/2025/02/fedora-threatened-with-legal-action-from-obs-studio-due-to-their-flatpak-packaging/

@kylegospo @cas @dalias .....so, flatpaks are actually harder to use correctly even by distro packagers, and OBS studio is apparently going to litigation to enforce that distros avoid presenting any layer of auditing between upstream and the distro's users? and this is supposed to demonstrate what exactly other than flatpak is actually not a magical solution to app deployment, and is used as part of a show of force by app devs to remove distro packagers from the equation? the discussion i thought we were having was about flatpak vs not flatpak

@hipsterelectron @cas @dalias OBS's officially supported distribution method is a flatpak on flathub, This is an example of a distro overriding the developers decision and providing end users with a broken experience.

The good news is this has already been solved and Fedora has made their flatpak EOL. But I doubt it will be the last.

@dalias @hipsterelectron @cas you want broken packages? You want developers to have to resort to legal action so their application's reputation isn't being dragged through the mud by someone not even involved in its development?

@kylegospo @hipsterelectron @cas You seem to be refusing to answer my question about what specifically you mean by "broken"...

I strongly suspect that means upstream OBS was doing something bad that Fedora fixed, like automatically tying in to some cloud service.