Glyph@miss_rodent Multiple distros means multiple platforms. Multiple platforms means multiple dev targets. Multiple dev targets means that developing for "Linux" is, at minimum, *many dozens of times more expensive* than developing for macOS, or Windows, or the web.
cthos 🐱@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?
@glyph @miss_rodent The list includes but is not limited to:
- Manjaro on a 2015 Macbook Air 11" with XFCE
- Bazzite on a Framework 13" with KDE
- ZorinOS on Starlabs Starlite (which IIRC is highly skinned GNOME)
- Vanilla Ubuntu on a weirdo 10" tablet PC thingie from Chuwi (Required some config to enable because Ubuntu really loves snaps and they shouldn't)
And all my applications just work.
@cthos @miss_rodent FWIW it's not *impossible* for this to work, but it is wildly beyond *cost-effective* for most ISVs
@glyph @miss_rodent I mean, I regularly come across Flatpak wrappers around software that the maintainers did not themselves package that also just works and is maintained by one person occasinally running a CI script though so I don't think this is necessarily true for all applications.
Also RE: filesystem permissions, it's now extremely rare that I have to fire up flatseal and make any changes at all for my normal software.
@glyph @miss_rodent The one exception I can think of is Ludusavi because it has to search a huge variety of places to locate game saves and I did have to grant it permissions to a weirdo directory (but that's also kinda on me for putting the games in a nonstandard place)
@cthos @miss_rodent I think I do have some nuanced structural critique of flatpak that I sadly don’t have time to get into right now, but if I am being honest most of my systems have a weird quirk where user data lives outside home directories on external media and this causes flatpak’s weird slightly-wrong but makes-things-mostly-work heuristics absolutely violently explode in ways which cause huge issues that contributes to an overall *immediate* negative impression
@glyph @miss_rodent Understandable, and yes, there are some pretty sharp edges.
Matt Campbell
Raven667@glyph @cthos @miss_rodent i think flatpak (and AppImage, not snap) are the closest thing to standardization you are going to be able to convince linux devs to make. The desktop linux platform already has a lot which is close across distros, all the large ones use systemd and pipewire, mostly use Wayland graphics and KDE or GNOME, or a skin on top of those. GNOME especially expects a system to be set up in a more standard fashion, so distros have less flexability to pointlessly diverge in ways that break apps. Most gui apps are possible to flatpak, and run on almost any distro that is near standard (sorry for your systems which youve made difficult to support by accidently working at cross purposes to flatpak assumptions, but its hard to maintain compatibility when every computer-toucher wants to be their own ISV). Unfortunately its going to take a long time to convince Shuttleworth and Canonical that they are wasting everyones time with snaps, but Ubuntu isnt as popular as it once was. Its also going to take a long time to convince Debian, Fedora or Arch packagers that they should stop and target flatpak on the Freedesktop runtimes instead. There are a lot of devs who are personally offended by inefficiencies in the design of flatpak that leads to vendoring of libraries and duplication between runtimes, but i dont see any other way, the distro approach of deduplicating libraries creates bugs of its own and is unsustainable labor, the improvements to software build and integration that distro feedback brings to gui devs is probably not worth the effort it takes.
I dont think you are going to have much luck convincing volunteers to not work on what makes them happy, or for any existing distro to jump off a cliff for the good of the community, but you can make them irrelevant by inventing something better that the original gui dev community likes and can make work themselves. You can ask them to join your project if it looks successful and fun
@glyph @cthos @miss_rodent thinking about this more as i read further down the thread that the immutable distros (Silverblue/Bluefin/Bazzite et al) do effectively define am api and runtime by what is in the distro and what is left out. While it is _possible_ to layer on a local filesystem image built out of rpms on top of ostree, nothing can rely on that and its not the primary or expected way to extend the system with more apps, flatpak or stuff installed in your homedir like AppImage or distrobox/toolbox containers are the primary way to add on local software, which is a robust layering.
Petr Viktorin@glyph Now, imagine that we get the One And Only Distro.
Except its gatekeepers decide that this setup is weird and unsupported. You are not allowed to do things this way.
Except its gatekeepers decide that this setup is weird and unsupported. You are not allowed to do things this way.
William Oldwin@cthos @glyph @miss_rodent I very much don't want to run applications packaged by Some Random Person In Kansas. I make a deliberate effort to avoid them! I want to run applications packaged by the author/ISV or, failing that, by a team that I can have some trust in to do work of a certain standard. A distribution maintainer team would be the paradigm example of the latter. The 'Snapcrafters' model is maybe borderline.
@cthos Ah, right. Fair enough!
@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?
@glyph @matt @miss_rodent I don't agree that this is a "problem" per se, but most of the immutable distros (SteamOS, Bazzite, VanillaOS) lean _heavily_ on Flatpaks because you cannot just do `apt install {foo}`.
@glyph @matt @miss_rodent There are also other solutions for dev work, like most of those also have a contrivance for running a mutable distro in a container and then exposing binaries from that container to do stuff because not everything is a flatpak
@cthos @matt @miss_rodent immutable distros are probably the future in more ways than one. I didn’t realize this nuance, I should probably get one of these installed (other than steamos)
@glyph @matt @miss_rodent Aurora and Bluefin are the Universal Blue immutable distros for development work, with either KDE or GNOME respectively - Bazzite's their "gaming" distro. They all work pretty similarly. VanillaOS is probably the most stripped-down one I've tried. And of course Fedora provides their own series of images.
@cthos @matt @miss_rodent on the one hand this is encouraging. on the other hand omg the branding here is beyond stupid. why are these referred to as different operating systems, with unrelated nouns? are they somehow incentivized to confuse users?
@cthos @matt @miss_rodent like if I were to create an operating system for doing SMTP with twisted and a different operating system with unrelated branding for doing websockets
@cthos @matt @miss_rodent sorry I do not mean to be mean about this. but it seems like they’ve done some really good work here and are trying to snatch defeat from the jaws of victory. I have *heard* about bazzite and bluefin. at some length. i knew they were immutable distros. I had considered installing them. I did not even realize they were largely compatible let alone more or less the same thing
@glyph i think this is irreconcilable though because the software and out of the box config of an immutable distro is fixed, so you need to have different complete builds if you want different stuff in the base system. The compatability for apps is high though because the OS maker is pulling all the components out of the same pool. Like i dont think you want your general purpose desktop to boot into Steam, like Bazzite handheld builds do, but any of the flatpak apps will run just the same on all of the family, like the choice of specific flavor is driven by the hardware and purpose of the computer, but they can all run the same stuff outside the base os
@raven667 The Bazzite desktop builds don't auto-boot steam, though (but you *can* tell it to do that)
@cthos right, i run Bazzite on a laptop and a desktop, they start Steam on login, but not in big picture mode, but it was my understanding that the handheld builds *do* jump right into steam, just like steamos, eg on Lenovo Legion Go, including support for unique hardware in the base system that wouldnt be necessary or appropriate for a more general computing desktop, like motion sensors or rgb lighting
@raven667 @glyph @matt @miss_rodent they do, yes. I run Bazzite on a RoG Ally. That’s just a flag in a config file AFAIK though, i think there is a ujust script that can toggle the behavior.
@glyph @matt @miss_rodent Couldn't tell ya. Fedora does it too with Silverblue and Kinote (GNOME / KDE respectively).
@glyph @matt @miss_rodent They're all built off the same base and you can rebase from one to another at will, though.
@cthos @matt @miss_rodent thanks for all the info. there is a thick fog of war in distroland and this is very useful info
@matt @cthos @miss_rodent as long as the native version of apps still exists then that’s still 1 platform with 2 platform targets which ISVs now have a bunch of research to do to find out users are gonna be mad if they package their particular app like that. which by itself is already more work. and if your platform also supports whatever a “snap” is, god help you
@glyph @cthos @miss_rodent You might be interested in this blog post from a Fedora developer which, among other things, argues that Fedora should move away from packaging apps as RPMs: https://blogs.gnome.org/mcatanzaro/2025/07/21/fedora-must-carefully-embrace-flathub/
Fedora Must (Carefully) Embrace Flathub
Motivation Opportunity is upon us! For the past few years, the desktop Linux user base has been growing at a historically high rate. StatCounter currently has us at 4.14% desktop OS market share for Q2 2025. For comparison, when Fedora Workstation was first released in Q4 2014, desktop Linux was at 1.38%. Now, StatCounter measures...
@glyph @cthos @miss_rodent It looks like the File Chooser portal (https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.FileChooser.html) is supposed to implement a powerbox file dialog. I assume it somehow doesn't get this right.
@matt @cthos @miss_rodent I have never seen an app do this in a way which appeared to work. my experience is limited though. glad to hear it at least exists though!
@glyph i had to look up what a powerbox was, but flatpak is built around the concept and wouldnt work without a functioning xdg file chooser that lives in the baseos outside the flatpak. Ive never had a problem with it, but ive only used flatpak on GNOME on Fedora, Silverblue and Bazzite, where its a first class citizen and well integrated. Flatpak can only be a universal app packaging runtime if it actually works on all the desktop systems without fuss and drama.
@glyph i could see an effort around freedesktop and flatpak to define what dbus apis are expected to be provided by the distro/desktop to have full compatibility, and what might be outside those expectations. I dont think it makes sense to have flatpaks that only work on some distros/desktops because they depend on unique components, the baseline for running flatpak needs to declare what is required and provide reasonable errors if am amateur ISV tries to run it somehere impoverished
@cthos @miss_rodent less flippant answer:
there are of course efforts to unify the platforms around certain abstractions which paper over the differences. and some of them (flatpak included) are even close enough to kinda work some of the time. but developing a flatpak and getting it deployed, while *possible*, does not have zero marginal cost per distro.
@cthos @miss_rodent and to the extent that it succeeds, it succeeds by creating a meta-platform, flatpak, that floats on top of the distro and makes all the distinctions between them irrelevant anyway. it also doesn't fully succeed (flatpak filesystem permissions are a user-interface nightmare)
@glyph @miss_rodent Do... do we need to discuss just how many apps run on Electron on Mac and PC?
@cthos @miss_rodent Electron is definitely a more successful Flatpak than Flatpak
@glyph @miss_rodent Cool, problem solved, just run Electron everywhere. 😈
@cthos @miss_rodent … and that's exactly why I wish Linux *were* a platform