13 ms·

The Future of Flatpak

306 points by dxs 1y ago

mrbluecoat 1y ago
I'd choose a single appimage binary any day over flatpak, snap, or containers. It's just so portable and user friendly!
k_bx 1y ago
Biggest problem with flatpak for me is that it's not suitable for server-side software, which is well supported in Snap. Is that even planned at some point?
synergy20 1y ago
it was really for cross-distro GUI desktop applications. I saw it's used in embedded linux projects that has no GUI, for its portability at a heavy price(flatpak is quite fat, it needs to install a full sandbox)
- osn9363739 1y ago
  I chose flatpak some time ago over snaps for gui apps and I don't remember why. I think there are benefits to packaging software this way (especially for immutable OS images) but at the same time there are so many negatives too. I hope they make it more of a priority. Or something better comes out on top.
conradev 1y ago
The permissions issues are real. It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. macOS has an API to ask for permissions to add an interface/change routes.
- curt15 1y ago
  Thanks to said API, Tailscale on MacOS is even distributed as a sandboxed app through the Mac App Store [1]. Flatpak's restrictions make certain classes of software difficult to use on "atomic" Linux distros like Silverblue or Bluefin that provide a read-only base system and expect users to get their software through Flatpak. [1] https://tailscale.com/kb/1016/install-mac https://tailscale.com/kb/1016/install-mac
  - curious_ralts 1y ago
    I daily drive an immutable Fedora spin and if I wanted to install Tailscale I would most likely add it to the base image via `rpm-ostree` instead of trying to reach for Flatpak - not because i'm aware of the issues but because it makes more sense to me to add a more system-wide networking layer to the base image. That being said there are many apps that are not packaged as Flatpaks that I end up adding to the base layer out of necessity which I would have liked to use as Flatpaks.
- wmf 1y ago
  Maybe Tailscale should be a sysext not a Flatpak.
- WD-42 1y ago
  I'm not sure I'd install tailscale as a flatpak even if it were possible. I've always seen flatpak as a way to install large, potentially crappy desktop applications without polluting your system. OBS studio is a perfect example - it's a great app but it's the only one I use that uses QT, thanks to flatpak I don't even have the QT libraries installed on my system. Tailscale is more like a system service that I'd prefer a distro package for (Arch Linux repos contain Tailscale, btw).
  - vrighter 1y ago
    You don't have QT libraries installed on your system. You just have then in some archive somewhere along with a bunch of copies of stuff you do already have installed on your system.
    - porridgeraisin 1y ago
      Why does that matter? Copies of a few libraries is just not a problem.
      - vrighter 1y ago
        if it doesn't matter then why is them not being in an archive along with a bunch of other duplicate stuff a bad thing?
- klabb3 1y ago
  Im not really much of a flatpak user but to me it seems like permission system on top of Linux is an incredible undertaking. Solving both packaging and retrofitting permissions at the same time seems too big of a cookie to swallow. I don’t know whether the permission system is what killed the momentum and caused this seeming burnout. But it seems incredibly complex. To me, Linux doesn’t have a granular modern permission system, and I don’t expect my package manager to solve it for me. I still run proprietary software on it, because I kind of have to. Is that an ideal situation? No. But I rather have a distribution system and vet vendors (which I’m doing anyway) than wait another decade for permissions to be perfect. Distribution, packaging and updates is the pressing need imo.
- ChocolateGod 1y ago
  > It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. It's possible but not ideal. The application could use flatpak-spawn (to get out the sandbox) and then polkit-exec (to ask user for root perms for arbitrary use) to get root privileges on the host, but you're removing nearly all sandboxing.
dismalaf 1y ago
Interesting read. While Flatpak does work nicely for a lot of things, the downsides are real and have me almost preferring Snap for the most part. Flatpak terminal apps are annoying, the permissions thing is annoying, sound, etc... Interesting that the creator is thinking about the next thing already.
- ikiris 1y ago
  Its more likely that its not a priority for RedHat and its harder to work on non priority projects in the era of mass layoffs or perfoffs.
- OsrsNeedsf2P 1y ago
  > Flatpak terminal apps are annoying, They could have been good, but they chose not to go down this route. This is one area Snap shines. Flathub rejects terminal only apps for this reason as well
  - linmob 1y ago
    Yet, there are a select few non-gui flatpaks. One I use frequently is Zola [0], a static site generator that I use because it's significantly faster in building my site with 'zola serve' than the native Alpine Linux package. All I had to do to make it convenient was aliasing flatpak run org.getzola.zola to zola. [0]: https://flathub.org/apps/org.getzola.zola https://flathub.org/apps/org.getzola.zola
  - ChocolateGod 1y ago
    The use case is taken by Podman/Docker
charcircuit 1y ago
Hopefully the money from selling apps can fund development like other app stores work.
- OsrsNeedsf2P 1y ago
  Flathub introduced donations a few years ago and nothing really came of it Edit: I could be misremembering, but there was an attempt to add donations. Maybe it was rejected
ndiddy 1y ago
> Wick started his talk by saying that it looks like everything is great with the Flatpak project, but if one looks deeper, ""you will notice that it's not being actively developed anymore"". There are people who maintain the code base and fix security issues, for example, but ""bigger changes are not really happening anymore"". He said that there are a bunch of merge requests for new features, but no one feels responsible for reviewing them, and that is kind of problematic. I think Red Hat should really be stepping up more here, especially since with RHEL 10 they stopped maintaining a ton of desktop packages with the advice for users of those packages being "get the package from Flathub instead of from us" (see https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/removed-features https://docs.redhat.com/en/documentation/red_hat_enterprise_... , search for Flathub). If that's Red Hat's attitude towards desktop software, they should be providing the resources to make Flatpak a viable alternative. > A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak. I'm glad he brought that up as a problem. I maintain a game on Flathub that has audio and controller support. Because of the limited permissions granularity, that means that the game is displayed as requiring arbitrary device access (--device=input is too new, so the Flathub maintainers don't allow it in packages yet) and being able to listen to your device's microphone (the audio permission doesn't allow only accessing speakers but not microphones). I hope that Flatpak adds backwards compatibility for permissions so newer Flatpak versions can start having more granular permissions.
- bigfatkitten 1y ago
  Red Hat has since walked some of this back. Firefox and Thunderbird were supposed to go Flatpak only for RHEL 10, but they eventually shipped rpms for GA. Seems there were a myriad of causes for this including lack of Native Messaging, no ability to deploy policies centrally, and broken integrations with various other parts of the desktop ecosystem.
  - ndiddy 1y ago
tomrod 1y ago
Drat. Does this mean Fedora is hosed? I don't really follow metastories on Linux...
- noisem4ker 1y ago
  I'd be more worried about Fedora Silverblue and Kinoite, its variants which rely on Flatpak more, as their point is to experiment with a minimal immutable base OS with every user facing app installed as a Flatpak on top. As long as Red Hat wants to stay in business selling RHEL, Fedora as a distribution is probably not going away nor losing development focus.
apitman 1y ago
It's too complex. An application format shouldn't need to rely on 5 different APIs to be secure. And the apps aren't portable. I think something like WebAssembly is going to be the way forward.
- zbentley 1y ago
  I hope you're right. But how is WASM going to answer questions like "how does the application play sound?" or "how does the application request a password from the system keychain?" WASM solves a lot of problems, but I don't think its chances of providing a uniform API to things like that are any better than Snap/Flatpak's, because those problems are fundamentally not about the runtime/packaging system. They're caused by OS functionality being a fragmented and moving target. Directly executable applications have to deal with those complexities themselves. Containerized applications in WASM/Docker/Snap/Flatpak/whatever rely on the container layer to do it. But someone's software has to chase that moving target, and it moves very fast.
binkHN 1y ago
Nice breakdown. I'm new to Linux and didn't know about this: > Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio That's a pretty decent sized hole.
- gjsman-1000 1y ago
  I sometimes see Linux users sneering at Windows and Mac design mistakes or lack of “freedom”… but then there’s stuff like this. Of course, Linux is then conveniently redefined in a way that nobody can be responsible, with finger pointing on every issue, rather than admit design flaws like this plague Linux as a whole.
  - frollogaston 1y ago
    I wish there were such thing as just "installing Linux" on a computer, and it shows the penguin when you boot up.
    - andrewmcwatters 1y ago
      There sort of is, but you can't do anything with it, because you essentially have no user space utilities? For all of the crap that people gave the term "GNU/Linux" it's even more true today considering there are Linux-based operating systems that don't use GNU utilities. gjsman-1000 talks about "design flaws" in Linux above, but Linux is just the kernel. There is no "Linux" operating system, despite everyone, and even Linus probably? using that term. If you call booting init and getting a black screen "an operating system," well... that's cool I guess. I doubt Linus ever talks to the GTK people in any meaningful way, or any other desktop environment authors. So, what design flaws? Do you call a ladder a badly designed scaffold because it doesn't have a horizontal platform? No, it's just something entirely different all together.
      - frollogaston 1y ago
dejw 1y ago
Does flatpak support qemu emulation? Can I use it on arm to run x64 images?
- OsrsNeedsf2P 1y ago
  No it does not. The metadata file includes the available architectures, and Flathub exposes it in the UI[0] [0] An example https://flathub.org/apps/vet.rsc.OpenRSC.Launcher https://flathub.org/apps/vet.rsc.OpenRSC.Launcher
bee_rider 1y ago
Is there an active Flatpack community that is actually interested in it, in the same way communities form around distros and their repos? It seems like probably no… I dunno. So far my experience with these third party store things (or whatever) is that occasionally Firefox gets switched to a Snap, requiring active intervention and possibly nuking my profile is I do it wrong. It is… pretty annoying.
- OsrsNeedsf2P 1y ago
  There's a Flathub Discourse[0], but it's died down a lot [0] https://discourse.flathub.org/ https://discourse.flathub.org/
OsrsNeedsf2P 1y ago
This one hits close for me. Flatpak is probably the best way to distribute desktop apps on Linux. I say this as an app dev, a packager, and a user. At one point I maintained close to a dozen packages. I eagerly waited for months to see what they would do next - what magical features they would introduce. I was active on the forums helping other users package apps, helped review Flathub submissions (since it was always the same problems each time), and started checking out what PRs were happening. Silence. The months turned into years, and as more years came, I slowly fell away from engaging with Flatpak. I'm back to using the AUR for most things (Arch, btw), but I'm quite sad to hear the situation get spelt out. Flatpak really was revolutionary; bringing modern apps and painless distribution to all desktops - LTS or rolling release. But it hasn't really changed at all since it first took off years ago.
- WD-42 1y ago
  I feel the same. Like a few years ago Fedora + GNOME + Flatpak was the magic sauce. Not so much anymore. I’m back to Arch as well, which seems as if its package repositories have only grown. The AUR is there but I’m shocked how little I need from it.
- MindSpunk 1y ago
  I have almost never had a good experience with Flatpaks as a user, outside of ease of installation. They almost never integrate with the system properly. Wrong theme, wrong cursors, wrong file picker, permission issues, drag-and-drop issues. You often need extra tools that broaden the permissions of apps post-install because some feature won't work (global push-to-talk in Discord is always fun, especially with Wayland). I couldn't care less about sandboxing if the UX sucks as a result. If binary portability wasn't such a complete joke on Linux we wouldn't need Flatpak, but here we are.
  - Gigachad 1y ago
    Flatpak does have answers for this stuff but it's more the programs inside them aren't utilizing the right APIs, they are meant to use the portals api for filepickers which would use the system filepicker and securely portal stuff through the sandboxing. But many apps just don't. Theme is also an odd one. GUI design in general has shifted away from an OS theme and more towards an app/product theme which stays consistent between the product on different platforms. Discord for example looks largely the same on Linux, Windows, iOS, and web.
thangalin 1y ago
Years ago, I wrote an on-screen display (OSD) in Java for showing keypresses and mouse clicks[1]. Someone thought a flatpack would be useful[2]. I didn't see the point. It meant: (a) maintaining two installation processes; (b) collating download stats from two sources; (c) trusting a third-party system to maintain package indexes over time[3]; (d) adding yet another package manager to a system that already has a package manager; and (e) bloating the repo with another repo. Years later, I still only see drawbacks. [1]: https://gitlab.com/DaveJarvis/KmCaster https://gitlab.com/DaveJarvis/KmCaster [2]: https://github.com/flathub/com.whitemagicsoftware.kmcaster https://github.com/flathub/com.whitemagicsoftware.kmcaster [3]: https://flathub.org/apps/search?q=kmcaster https://flathub.org/apps/search?q=kmcaster - whoops!
- rbits 1y ago
  The upsides would be - Easy use on immutable distros - The user doesn't have to make sure they have the right version of Java installed - Auto-updates even if there is no repo for your specific distro And also you can find it through searching on Flathub I guess
  - thangalin 1y ago
    > And also you can find it through searching on Flathub I guess Did you click the third link I posted, which searches Flathub for KmCaster only to come up dry? This was point (c): You have to trust that their search engine is correct, maintained, and updated. That doesn't come for free, it takes effort, and things go wrong.
    - Lariscus 1y ago
      This isn't a bug. Kmcaster is unmaintained and has been removed from flathub. [0] https://flathub.org/apps/com.whitemagicsoftware.kmcaster https://flathub.org/apps/com.whitemagicsoftware.kmcaster
      - thangalin 1y ago
        This only supports my point about having more stuff to maintain. Now there's this GitHub page having a large "Download on Flathub" link that goes absolutely nowhere because the package is unmaintained. Who makes the GitHub page go away? https://github.com/flathub/com.whitemagicsoftware.kmcaster?tab=readme-ov-file https://github.com/flathub/com.whitemagicsoftware.kmcaster?t... Also, the image on that page is outdated, which would have been one more thing to maintain. In addition, the install instructions are four lines of code to run, compared with three lines of code to download without Flathub. My point stands: Flathub adds an unnecessary maintenance burden (to some projects).
sabslikesobs 1y ago
I've switched to a flatpak-based immutable distro lately. It's great when it works. But so many niceties don't work, and then it feels like my computer is not really the fantastic tool it should be. For example: - I had to run around with a distrobox running WINE and a bunch of permissions and kludges to run an external tool for Godot - I gave up on the flatpak for Firefox because it can't talk to my KeepassDX flatpak - The Godot and Krita flatpaks are oddly unstable and crash more than they did on Windows (may just be Gnome or something) - non-flatpak tools like AppImages and .rpms feel pretty dang grungy I want to see more cool stuff with Flatpak so seeing the state it's in is kind of a bummer.
ggm 1y ago
If a packaging mechanism, respecting virtualisation had been capable of existing 30 years ago we'd have one. Now, given how the fracture lines run, we're fated to have three or more. It's pythons virtual environment and pip-is-weak problem, magnified. It's homebrew or Mac ports or fink or pkgsrc. Mechanisms designed after fork, are never fork neutral.
- Ferret7446 1y ago
  None of the common cross-distro packaging mechanisms have anything to do with virtualization. The core problem is software dependencies.
  - ggm 1y ago
    A mechanism which can bundle its dependencies into an isolated runtime means dependencies do not fate share except at the ABI to the underlying OS. Virtualised container apps have simpler dependencies.
AStonesThrow 1y ago
20 years ago: "Oh no, the distros are struggling over packaging! We've got apt, yum, dnf, rpm, nix, docker..." https://m.xkcd.com/927/ https://m.xkcd.com/927/ For a long time, there was a pax debiana in my world. I used Ubuntu mostly (swapped to Debian and added Fedora towards the end) and the package management was really good. APT was a great tool and I got quite chummy with its ways. It was straightforward to keep my system updated and resolve dependencies. It was way smoother than any other updater system had been, even across major system upgrades. I sort of lost it when snap started usurping stuff. I knew it was coming, because docker was already making inroads. Then we had flatpak and company. As an admin, as a system architect, I felt that's the point when I lost control of my system. It wasn't possible to know its update state anymore. It wasn't possible to centrally manage or monitor those updates. It became a free-for-all of self-updates and shadow updates. Ubuntu was also introducing livepatch and kernel updates that went outside the apt model. I think that perhaps it became too great a burden for the major distros to be packaging all of their own downstream packages. Perhaps they saw the opportunity to offload some of that packaging burden on a really pro service that could just package everything, and make pan-distro packages available. If Debian and RHEL packagers are doing less downstream packaging, then perhaps they could focus on their core competencies. I noticed that nearly every Ubuntu package needed to include Ubuntu-specific tweaks, and basically when Ubuntu was already downstream from Debian, why should Canonical be maintaining every damn package themselves as well? So what's the endgame for all this? Would apt or dnf/rpm eventually get abandoned and have them go all-in on a new system? Or does the proliferation and splintering continue? Many of us said that the beauty of Linux is our freedom of choice. Well there's too much choice. Look at Distrowatch and be paralyzed by not knowing what to choose. Windows or macOS on your desktop is easy to choose because there's... one of each. When I visited Catalonia my friend took me to Carrefour. We strolled the aisles and I spotted pig-legs (jamon serrano) on every counter. A huge selection of eggs. Everything my stomach could desire. She led me into the olives aisle and gestured around to all the olives there. She said pick whichever I want. There were so many. They were all in fancy jars. I knew nothing of olives. I left without choosing any. Linux will die a death of a thousand cuts, until some consolidation and unification can happen that's beyond the kernel.
- tenebrisalietum 1y ago
dbolgheroni 1y ago
I've installed flatpak to install VSCode/Codium to have an usable debugger for a Python project I'm working on. After some time tweaking VSCode/Codium trying to get the debbuger to work, just realized flatpak could be the problem. After another considerable amount of time trying different flatpak permissions, realized this is not a good use of my time. Installed the same packages from snap, and everything worked OK.
- bjoli 1y ago
  The emacs flatpak is just a long and painful road leading nowhere.
- Ferret7446 1y ago
  Flatpak is far better for applications rather than system tools, e.g., Chrom{e,ium}, due to the sandboxing.
itsrouteburn 1y ago
If not Flatpak, what is the future for portable sandboxed applications on Linux? I would love a solution where I can run semi-trusted or untrusted applications (e.g. vscode+extensions) confident that it doesn't have uncontrolled access to whatever my userid privileges permit.
- LtWorf 1y ago
  The solution for untrusted code is to not run it.
foresto 1y ago
> Flatpak now has --device=input to allow an application to access input devices without having access to all devices. Oh, hey... I made that feature. Nice to see that other people want narrower permissions, too.
SubiculumCode 1y ago
Both flatpak and snap have been a bane with inconsistent behaviors, permissions bugs, and a bunch of stuff I never figured out. I got so frustrated with them that I wiped, put Debian on and just the old package systems.
- MattPalmer1086 1y ago
  I'd largely agree. Snap was what drove me away from Ubuntu, after the calculator app started taking ages to load. The calculator! It was instant before snapification. I have played with using FlatPak, and while it seems snappier than snap, I always ended up with something not quite working, because of permissions or sandboxing. The answer to a lot of problems seemed to be "don't use the FlatPak version". The set of software I use complex enough to need something like FlatPak while also not needing to interact with other things is basically very, very small.
  - lproven 1y ago
    When was this? Snap _was_ a bit slow in the early days. It's not any more. I use Ubuntu 22.04, 24.04 and 25.04. Snap is pretty fast these days. I have gone around purging all my custom repos and PPAs, removing those apps, and reinstalling the snap versions. It's just easier and it works. I am running 3 quite elderly Thinkpads in near-daily use: an X220, T420, and W520. All Core i7, all with RAM maxed out, all with SSDs. They are perfectly usable for what I need and they have great keyboards which no more modern Thinkpads do. Ubuntu 22.04 on a 13-year-old Thinkpad loads snap apps in an eyeblink now. I can't detect any delay compared to natively-packaged apps. Yes, it uses a bit more disk space. I used to remove all snaps and then `apt purge snapd` but it's not worth the extra effort any more.
    - SubiculumCode 1y ago
      See, I really don't understand how my experiences were so different from yours. Not in terms of speed, but in terms of just working. It was always things like missing or misconfigured apparmor profiles causing errors with snap and/or flatpak, sandboxes needing to run/be owned as root error messages, failure to save documents in one of my home folders, adjusting permissions for that, still doesn't work...and on and on.
amluto 1y ago
In case anyone ever seriously contemplates a new design, here's an anecdote: Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents. I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too. However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better. (This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)
- dartharva 1y ago
  Mildly OT but I have longed for this kind of app portability in Android too. Some OEMs like Xiaomi apparently took note a few years back, offering inbuilt app "duplication" features in their OS's but only for a few popular apps like WhatsApp.
- zzo38computer 1y ago
  Yes, that would be better, for specific instances of the running program to have a set of permissions instead. However, I think this is not the only issue. It is what I had wanted too, not only you. I think that the entire operating system should need to be redesigned for many reasons (I mentioned before how to design a better one), and it would have that effect, that specific instances of a running program would be given capabilities as arguments (or through other capabilities, but the first ones must be given as arguments), and these capabilities can have restricted permissions, as well as more versatile things e.g. to log access, or to go through a proxy, or to set a disk quota, etc.
zbentley 1y ago
I see the real utility these tools are providing to many folks, but ... It just feels so ugly. Square peg meets round hole. We built all these tools for defining security boundaries for user-installed applications, and it turned out that the Linux packaging/distribution landscape was such a wasteland that people spent a lot of time duct taping software distribution artifact reproducibility onto the security-boundary tools. So now we're in this weird worst-of-all-worlds spot: The simplicity, performance, and decades of work we spent to make it easy to develop powerful applications that run directly on userland is now bifurcated/trifurcated and a mess. The legibility of "I want to run an application that dynamically links a cryptography library; that library is provided by the distro and I know it is both patched and compatible with the rest of the distro" or "my application can access files/devices at /path/to/whatever and use those resources if it has permission to do so" is buried under tons of container indirection. Meanwhile, as TFA explains in detail, the actual security/encapsuation boundaries that these tools were originally built for proved to be a fast-moving target for which tons of support is still missing years later. We can see the possibilities of what could have been in other systems. Take BSD's pledge(2) for example: its approach is so aggressively oriented towards only solving the security problem that I can't really imagine a world where the pledge/capability system "grew" a packaging/distribution ecosystem the way Snap and Flatpak did. Or take plan9's approach: perhaps if we had modeled the entirety of the OS in such a way that the basic SysV permissions model (users, groups, files, permissions) covered as much as possible of applications' security sandboxing needs, then things like SElinux/snap/flatpak wouldn't have ended up being necessary. The biggest thing that got us into this state wasn't the tools, though--it was the human stuff: the tensions between "distro/package repo maintainers are burnt out and want to support a relatively small number of dependency targets and ways to add things to the package graph on a given OS"; "app developers want to make complex software available to users as quickly as possible"; and "users are very willing to do insecure things to get new applications to run, but are generally unwilling to do complex things (configure/make, customize AUR sources, know what nix is) in order to install stuff". Fast forward a few years, add a lot of false starts and other bullshit due to dueling desktop environments/compositors/audio systems, and where we ended up is not good. The current situation is basically: "Come on down to DLL hell but way worse, we have: tons of brittleness when apps want to talk to the rest of the OS (sucks for users--but only when apps need rare and advanced functionality like ... uuuh basic audio playback), all baked into highly complex container systems (sucks for application authors) aimed at delivering apps that each package their own look/feel/OS integrations (sucks for distro maintainers and consistency of UX) in massive "it's not actually static linking, I promise" images, each of which contains 75% of an OS, running on leaky isolates (sucks for the security patchers) with an update story of "just download the universe again" (sucks for bandwidth/CDN costs)." Like, I understand how we got here. I get that it's better than the bad old days of "but which autoconf?"/"I just wanted to update my browser but then glibc-2.11-compat-compat-compat-but-for-real-this-time-FINAL updated and broke my bootloader". And I get that some of those areas might improve over time (e.g. OCI images help with redownload-the-world; eventually Wayland will percolate around and the container runtime X compositor geometric complexity explosion will die down; someday someone will finally fix universal D-Bus discoverability and security for the eighteenth time...). But overall it is and will remain a mess at a fundamental, philosophical level. Seems like the Linux ecosystem did this in a maximally slow and fragmented way, which is nothing new. But it sucks to see such an "everyone loses" end state as the result.
lleymrl651 1y ago
Nice breakdown.
dartharva 1y ago
It still irks me that AppImages (the unambiguously superior choice) are not more successful than Flatpak or Snap solely because Linux users (in their characteristic laziness) are only used to getting their software from monolith stores and repositories.
- 0xpgm 1y ago
  At least in the case of Snap, I felt that Canonical itself played a role in making it dominant in Ubuntu so that they could control the ecosystem. Personally I use AppImage whenever it's an option. It's the closest we get to Windows and MacOS executable applications
- plst 1y ago
  I love AppImages, but Flatpak tried to go way beyond - centralized updates, sandboxing/permissions system, package once, run on many distributions... Getting software from repositories is not just laziness, you automatically get updates and the software from repos is supposed to work with your distro, that apparently is not always true with AppImages.
sohrob 1y ago
I'm not an open source maintainer or even a dev, but it seems bonkers to me that with all the numerous distributions out there, all facing the same problem of package management, that they couldn't just refocus their combined efforts toward improving Flatpak and guiding it toward universal adoption.
- palata 1y ago
  Maybe one reason why many "distributions" exist is that they don't feel like "distributing" the same way :-). Diversity is good. I don't want "one distribution" that chooses the init system, distribution, compositor, window manager, etc. I want to have choice. When it comes to distributing packages, I personally like system package managers. Not such a big fan of flatpak.
- LtWorf 1y ago
  Many people disagree on the idea that flatpack is useful at all. For example it's completely useless to me. Why do you expect me to help on something I don't use?
- yencabulator 1y ago
  By that logic, only GNOME is allowed to exist. No thanks. The people in power often make decisions a big chunk of the community disagrees with.
nycticorax 1y ago
I don't agree with him 100%, but I always find Drew DeVault to be thoughtful on this topic: https://news.ycombinator.com/item?id=32936114 https://news.ycombinator.com/item?id=32936114 https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job.... Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users." The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.
- sbt 1y ago
  The problem is that now you have to package for N distros. And the people who run the distro may not want to spend time on it, so you have to do it yourself.
  - Arnavion 1y ago
    It doesn't have to be gated by "the people who run the distro". I started packaging a few pieces of software for a distro I use because I wanted to use that software, and I don't "run" the distros in any capacity. Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux. If you don't have even one user willing to do that for the distro they use, you probably weren't going to have users on that distro anyway.
    - troyvit 1y ago
      > Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux. I feel like there's a constant tug of war on this issue. If you leave it up to app developers then they have to package their app for N distros. If you leave it up to the distro maintainers then they have to compile N apps for their distro. I don't envy either group given how different distros are and how varied apps are in quality, methodology, etc. I look at Podman. In my opinion it could be (could have been?) a huge disruptor, but its RedHat (or Fedora or CentOS or whatever the hell those guys do now) versions are way higher than versions for other distributions, which creates for me (just a home user) an interoperability problem between all my different Linux boxes. RedHat if anybody has the resources to fix this but I guess they'd rather try to use it as a way to force adoption of their distro? I don't even know. Both the apps and the distros are volunteer-heavy. App packaging is a big job for either side. I'm still hopeful that Flatpak can help that job
zzo38computer 1y ago
I think D-bus has many problems and isn't very good. I also think the sandboxing (of Flatpak and other systems) has problems, e.g. lack of some kinds of permissions (e.g. permissions that depend on command-line switches, permissions to execute user-specified external programs by popen (without the restrictions affecting them too), and more), inability to properly use character encodings, etc. There are other issues as well, even though I think that the sandboxed execution is not a bad idea in general.
willmarquis 1y ago
Flatpak’s biggest bug isn’t in the code, it’s the bus factor. > Tons of features are stuck in merge-request limbo because there just aren’t enough reviewers, and if we don’t swap some “+1”s for actual PR reviews (or funding), we’ll be shipping apps in 2030 with a sandbox frozen in 2024 while everything else rides OCI.
forrestthewoods 1y ago
Over here in Windows land I can’t fathom why you need something like Flatpak just so users can reliably launch and run a program. I mean trust me I understand that Linux is so broken it needs something like flatpak. But imagine saying you’re disappointed the Windows executable format isn’t evolving! Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.
- SomeoneOnTheWeb 1y ago
  Thing is, .exe on windows is broken on so many levels. You don't have sandboxing, apps don't always follow standards as to where to store their data, there's no dependency management but if you don't have the correct version of e.g. java installed your app won't work. Etc.
- dsego 1y ago
  > Running an exe shouldn’t require decades of maintenance. That's why windows is so full of malware and viruses.
- Propelloni 1y ago
  > Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be. What do you think is all that stuff in C:\Program Files, C:\Program Files (x86), c:\Windows\System, C:\Windows\System32, C:\Windows\SysWOW64, %USERPROFILES%\%APPDATA%\Local and %USERPROFILE%\%APPDATA%\LocalLow or the seven versions of the C/C++ VS Redistributable you have installed? EDIT: typos
  - Barrin92 1y ago
    in reality a bunch of stuff no user ever has to look at. On Windows literally anyone can click on a 20 year old executable and in all likelihood it just works because the good people at Microsoft care about giving the user a decent supply of libraries and stable ABIs and an actual operating system people can build against. The Linux world is just in complete shambles in this regard. You build something on one LTS release, you don't know if it executes on the next. As the joke goes (it isn't even really a joke), it's so bad that Win32 is the only stable ABI on Linux
tannhaeuser 1y ago
Great, after bringing Pulse (+ Limewire to fix it), systemd, wayland, dbus, flatpak to dilute and overcomplicate everything, RHEL is now abandoning the desktop alltogether. Meanwhile, zero new desktop apps have been created for Linux in like two decades. Today even Firefox on Ubuntu and Fedora can't access a webcam for teams/gmeet because of permission problems of layered container frameworks that are there just to protect fictional, as in non-existant, apps from accessing your damn files. Seriously, the only way out and where progress has been made seems to be embracing win32 apps using wine/proton, but maybe using SteamOS/Arch instead since bazzite is based on fedora.
blippage 1y ago
I'm currently using Slackware current. I use an approach of compiling from source or using AppImage. Things like Flatpak and Snaps are an opaque black box to me. I have AppImages for things like Zoom, KeePass and LibreOffice. I don't need to keep updating them. They do what I want them to do. I have them on a separate partition. If I reinstall my system they're all ready to go out of the gate. It's ridiculously simple. I did try out Fedora awhile ago, but decided it wasn't for me. Why is everything a Flatpak? Just use the repo mechanism.
- pvdebbe 1y ago
  Same system with me. Running gentoo without systemd or pulseaudio makes Flatpak and Snap totally nonstarters. I compile most of my stuff from gentoo's official repos and supplement things with select AppImages that work out of the box, curiously well.
- mixmastamyk 1y ago
  I don’t use flatpak on my main fedora box, rather added rpmfusion instead.
lucas_membrane 1y ago
I've been using Fedora 41 about half a year, and flatpak has not made it better. Fedora 41 started with a bunch of apps distributed as rpm, but some of them have since been updated as flatpaks when I run 'sudo dnf update'. Splendid, except that the rpm apps, now a little out-of-date, are not deleted, which may be good or bad, but that explains why I have duplicate icons for the same app all over my desktop, and its pretty confusing trying to tell which is which, which is better, or how to manage the all the differences and conflicts, which Fedora 41 makes anything but scrutable. The thing about the microphones and speakers getting tangled up, as explained in TFA, also was somethig of and for which I was unaware and unprepared respectively when I had some problem with the old-fashioned way and decided to install musescore as a flatpak. I've been thinking about upgrading to Fedora 42, but this article is giving me considerable premonitions of additional inconvenience and incidental despair. Anyone have this stuff under control?
enriquto 1y ago
Never understood the point of flatpak, snap and the like. Can't you just distribute static binaries? They are not that hard to compile. (I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)
- dale_glass 1y ago
  They're not at all trivial on anything big and complex. And the code I work on has loadable plugins, too.
- brnt 1y ago
  I did not find packaging up an AppImage that is actually compatible across distro's and version all that straightforward, and we were not even using Qt or GTK/libadwaita. How is this easy, in your experience?
  - enriquto 1y ago
    > How is this easy, in your experience? add -static to your link flags? Sometimes you need to fiddle a bit with the order of the libraries, but that's it. In the ideal case, for maximum portability, i'd like to use the αpε format!
    - sirwhinesalot 1y ago
      Have you actually tried to make a fully statically linked GUI app on Linux?
      - enriquto 1y ago
        Just did it! I had to add "-static" to LDFLAGS and "-lxcb -lXau -lXdmcp" to LDLIBS, for an increase in binary size from 1MB to 3MB. It's a plain X program, i guess if you use fancy toolkits it may be harder.
ChocolateGod 1y ago
I use NixOS and Flatpak I found is the easiest way to install and update applications. The Nix model is great for system software, but not an ideal way of updating and installing desktop apps. The only problem I've had is fonts installed system wide not being available in the sandbox, but this is due to how NixOS exports fonts and can be solved by telling NixOS to publish fonts in /usr/share/fonts.
vrighter 1y ago
I think flatpaks are all about bringing android's limitations to mainstream linux.
poulpy123 1y ago
Linux has the worst software distribution model towards the general public of all OS. The one of windows (and probably MacOS but I don't know much) is also full of issues, but is still infinitely better than linux. When you compound the number of distributions, the number of their versions, the number of software, and their versions, you realize that having the distribution managed by the distribution or the software authors is unsustainable. In comparison, windows and mac only require at most 2 versions of the software each to reach at list 90% of the users. I don't know if flatpak or appimage or whatever are a solution, and I cannot propose one myself. But I really think that at one point the linux model will completely fail if it doesn't improve BTW I'm not saying that the linux model is always inferior. Actually it is often superior: in the server world were professionals take care of things, in the embedded world where the resources are scarce, the possibilities to configure and select everything to the smallest detail make it great.
- lproven 1y ago
  This is why the single most widely-used desktop/laptop Linux distribution in the world has a simple, brilliant solution to app packaging: It has none. You can't install new apps. It's ChromeOS. It has something like quarter to half a billion users, judging from the sales numbers of ChromeBooks and their supported lifetime. Real ChromeBooks let you install Android apps, but that is side-stepping the issue. ChromeOS Flex on a PC, which I use, doesn't offer that. You can open a Debian shell and install Debian packages in there, though. Handy for VLC. Ubuntu, from its own numbers, has maybe 20-30 million users. Debian about a third of that. All the RH distros less than Debian, maybe a tenth. In China, UnionTech says it passed 3 million paying users of UOS last year, implying numbers maybe comparable to Ubuntu's. Which in turn implies that most of China still runs on pirated MS Windows. All the other distros put together come to about 10% of the number of ChromeBooks sold in the last 3-4 years. The way to win in Linux packaging seems to be: don't do it at all. "A strange game. The only winning move is not to play."
  - curt15 1y ago
    As a long-time Linux user, I also find it ironic that after years of Linux nerds basking in the "superiority" of their package managers, Homebrew on Mac OS has eclipsed them all in terms of universality and ease of use. For example, compare the install instructions for kubectl: Linux DEB/RPM (https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/ https://kubernetes.io/docs/tasks/tools/install-kubectl-linux...): 1. sudo apt-get install -y apt-transport-https ca-certificates curl gnupg 2. curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg 3. sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # allow unprivileged APT programs to read this keyring 4. echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list 5. sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # helps tools such as command-not-found to work correctly Mac OS (https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos https://kubernetes.io/docs/tasks/tools/install-kubectl-macos...): 1. brew install kubectl
Imustaskforhelp 1y ago
Side note but I wanted to build a cli program on flatpak and I kind of couldn't. I have unfortunately not read the whole thing but I just want these two things: better cli support better permission support as I have had some issues with permissions. Currently using nix-shell as a sort of substitute against flatpak because I just want to use ephemeral environments without any permission issue or smth. Like I do nix-shell -p obs-studio and run obs and then close the shell and be peaceful as I rarely use obs for example and dependency hell. I may have wrote the exact same comment in the past but I want to use archlinux so much but nix-shell is way more comfortable to use on nix(I know its available on arch as well) and nix has the same name but arch might have different name so IDK.
rollcat 1y ago
This is a bit unfortunate. Flatpak is outright just a better tool than Snap. (I've had nightmare stories with Docker-via-Snap.) I do like AppImage better (it's simpler), but there's no equivalent of FlatHub, the discoverability is just poor. Also, per TFA: https://m.xkcd.com/2347/ https://m.xkcd.com/2347/
ongytenes 1y ago
I really dislike Flatpak because the humongous sizes of packages. I noticed that Telegram flatpak was 1.1GB in size and requires 3.6GB of the hard drive, whereas the regular DEB install was 28MB and needs only 82 MB. And there was no DEB available for Signal in the LinuxMint package manager. It also was a 1.1GB download that required 3.6GB of hard drive. Reason there is no Signal app on my desktop.

306 points by dxs 1y ago

I'd choose a single appimage binary any day over flatpak, snap, or containers. It's just so portable and user friendly!

k_bx 1y ago

Biggest problem with flatpak for me is that it's not suitable for server-side software, which is well supported in Snap. Is that even planned at some point?

synergy20 1y ago

it was really for cross-distro GUI desktop applications. I saw it's used in embedded linux projects that has no GUI, for its portability at a heavy price(flatpak is quite fat, it needs to install a full sandbox)

osn9363739 1y ago
I chose flatpak some time ago over snaps for gui apps and I don't remember why. I think there are benefits to packaging software this way (especially for immutable OS images) but at the same time there are so many negatives too. I hope they make it more of a priority. Or something better comes out on top.

conradev 1y ago

The permissions issues are real. It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. macOS has an API to ask for permissions to add an interface/change routes.

curt15 1y ago
Thanks to said API, Tailscale on MacOS is even distributed as a sandboxed app through the Mac App Store [1]. Flatpak's restrictions make certain classes of software difficult to use on "atomic" Linux distros like Silverblue or Bluefin that provide a read-only base system and expect users to get their software through Flatpak. [1] https://tailscale.com/kb/1016/install-mac https://tailscale.com/kb/1016/install-mac
- curious_ralts 1y ago
  I daily drive an immutable Fedora spin and if I wanted to install Tailscale I would most likely add it to the base image via `rpm-ostree` instead of trying to reach for Flatpak - not because i'm aware of the issues but because it makes more sense to me to add a more system-wide networking layer to the base image. That being said there are many apps that are not packaged as Flatpaks that I end up adding to the base layer out of necessity which I would have liked to use as Flatpaks.
wmf 1y ago
Maybe Tailscale should be a sysext not a Flatpak.
WD-42 1y ago
I'm not sure I'd install tailscale as a flatpak even if it were possible. I've always seen flatpak as a way to install large, potentially crappy desktop applications without polluting your system. OBS studio is a perfect example - it's a great app but it's the only one I use that uses QT, thanks to flatpak I don't even have the QT libraries installed on my system. Tailscale is more like a system service that I'd prefer a distro package for (Arch Linux repos contain Tailscale, btw).
- vrighter 1y ago
  You don't have QT libraries installed on your system. You just have then in some archive somewhere along with a bunch of copies of stuff you do already have installed on your system.
  - porridgeraisin 1y ago
    Why does that matter? Copies of a few libraries is just not a problem.
    - vrighter 1y ago
      if it doesn't matter then why is them not being in an archive along with a bunch of other duplicate stuff a bad thing?
klabb3 1y ago
Im not really much of a flatpak user but to me it seems like permission system on top of Linux is an incredible undertaking. Solving both packaging and retrofitting permissions at the same time seems too big of a cookie to swallow. I don’t know whether the permission system is what killed the momentum and caused this seeming burnout. But it seems incredibly complex. To me, Linux doesn’t have a granular modern permission system, and I don’t expect my package manager to solve it for me. I still run proprietary software on it, because I kind of have to. Is that an ideal situation? No. But I rather have a distribution system and vet vendors (which I’m doing anyway) than wait another decade for permissions to be perfect. Distribution, packaging and updates is the pressing need imo.
ChocolateGod 1y ago
> It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. It's possible but not ideal. The application could use flatpak-spawn (to get out the sandbox) and then polkit-exec (to ask user for root perms for arbitrary use) to get root privileges on the host, but you're removing nearly all sandboxing.

dismalaf 1y ago

Interesting read. While Flatpak does work nicely for a lot of things, the downsides are real and have me almost preferring Snap for the most part. Flatpak terminal apps are annoying, the permissions thing is annoying, sound, etc... Interesting that the creator is thinking about the next thing already.

ikiris 1y ago
Its more likely that its not a priority for RedHat and its harder to work on non priority projects in the era of mass layoffs or perfoffs.
OsrsNeedsf2P 1y ago
> Flatpak terminal apps are annoying, They could have been good, but they chose not to go down this route. This is one area Snap shines. Flathub rejects terminal only apps for this reason as well
- linmob 1y ago
  Yet, there are a select few non-gui flatpaks. One I use frequently is Zola [0], a static site generator that I use because it's significantly faster in building my site with 'zola serve' than the native Alpine Linux package. All I had to do to make it convenient was aliasing flatpak run org.getzola.zola to zola. [0]: https://flathub.org/apps/org.getzola.zola https://flathub.org/apps/org.getzola.zola
- ChocolateGod 1y ago
  The use case is taken by Podman/Docker

charcircuit 1y ago

Hopefully the money from selling apps can fund development like other app stores work.

OsrsNeedsf2P 1y ago
Flathub introduced donations a few years ago and nothing really came of it Edit: I could be misremembering, but there was an attempt to add donations. Maybe it was rejected

ndiddy 1y ago

> Wick started his talk by saying that it looks like everything is great with the Flatpak project, but if one looks deeper, ""you will notice that it's not being actively developed anymore"". There are people who maintain the code base and fix security issues, for example, but ""bigger changes are not really happening anymore"". He said that there are a bunch of merge requests for new features, but no one feels responsible for reviewing them, and that is kind of problematic. I think Red Hat should really be stepping up more here, especially since with RHEL 10 they stopped maintaining a ton of desktop packages with the advice for users of those packages being "get the package from Flathub instead of from us" (see https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/removed-features https://docs.redhat.com/en/documentation/red_hat_enterprise_... , search for Flathub). If that's Red Hat's attitude towards desktop software, they should be providing the resources to make Flatpak a viable alternative. > A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak. I'm glad he brought that up as a problem. I maintain a game on Flathub that has audio and controller support. Because of the limited permissions granularity, that means that the game is displayed as requiring arbitrary device access (--device=input is too new, so the Flathub maintainers don't allow it in packages yet) and being able to listen to your device's microphone (the audio permission doesn't allow only accessing speakers but not microphones). I hope that Flatpak adds backwards compatibility for permissions so newer Flatpak versions can start having more granular permissions.

bigfatkitten 1y ago
Red Hat has since walked some of this back. Firefox and Thunderbird were supposed to go Flatpak only for RHEL 10, but they eventually shipped rpms for GA. Seems there were a myriad of causes for this including lack of Native Messaging, no ability to deploy policies centrally, and broken integrations with various other parts of the desktop ecosystem.
- ndiddy 1y ago

tomrod 1y ago

Drat. Does this mean Fedora is hosed? I don't really follow metastories on Linux...

noisem4ker 1y ago
I'd be more worried about Fedora Silverblue and Kinoite, its variants which rely on Flatpak more, as their point is to experiment with a minimal immutable base OS with every user facing app installed as a Flatpak on top. As long as Red Hat wants to stay in business selling RHEL, Fedora as a distribution is probably not going away nor losing development focus.

apitman 1y ago

It's too complex. An application format shouldn't need to rely on 5 different APIs to be secure. And the apps aren't portable. I think something like WebAssembly is going to be the way forward.

zbentley 1y ago
I hope you're right. But how is WASM going to answer questions like "how does the application play sound?" or "how does the application request a password from the system keychain?" WASM solves a lot of problems, but I don't think its chances of providing a uniform API to things like that are any better than Snap/Flatpak's, because those problems are fundamentally not about the runtime/packaging system. They're caused by OS functionality being a fragmented and moving target. Directly executable applications have to deal with those complexities themselves. Containerized applications in WASM/Docker/Snap/Flatpak/whatever rely on the container layer to do it. But someone's software has to chase that moving target, and it moves very fast.

binkHN 1y ago

Nice breakdown. I'm new to Linux and didn't know about this: > Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio That's a pretty decent sized hole.

gjsman-1000 1y ago
I sometimes see Linux users sneering at Windows and Mac design mistakes or lack of “freedom”… but then there’s stuff like this. Of course, Linux is then conveniently redefined in a way that nobody can be responsible, with finger pointing on every issue, rather than admit design flaws like this plague Linux as a whole.
- frollogaston 1y ago
  I wish there were such thing as just "installing Linux" on a computer, and it shows the penguin when you boot up.
  - andrewmcwatters 1y ago
    There sort of is, but you can't do anything with it, because you essentially have no user space utilities? For all of the crap that people gave the term "GNU/Linux" it's even more true today considering there are Linux-based operating systems that don't use GNU utilities. gjsman-1000 talks about "design flaws" in Linux above, but Linux is just the kernel. There is no "Linux" operating system, despite everyone, and even Linus probably? using that term. If you call booting init and getting a black screen "an operating system," well... that's cool I guess. I doubt Linus ever talks to the GTK people in any meaningful way, or any other desktop environment authors. So, what design flaws? Do you call a ladder a badly designed scaffold because it doesn't have a horizontal platform? No, it's just something entirely different all together.
    - frollogaston 1y ago

dejw 1y ago

Does flatpak support qemu emulation? Can I use it on arm to run x64 images?

OsrsNeedsf2P 1y ago
No it does not. The metadata file includes the available architectures, and Flathub exposes it in the UI[0] [0] An example https://flathub.org/apps/vet.rsc.OpenRSC.Launcher https://flathub.org/apps/vet.rsc.OpenRSC.Launcher

bee_rider 1y ago

Is there an active Flatpack community that is actually interested in it, in the same way communities form around distros and their repos? It seems like probably no… I dunno. So far my experience with these third party store things (or whatever) is that occasionally Firefox gets switched to a Snap, requiring active intervention and possibly nuking my profile is I do it wrong. It is… pretty annoying.

OsrsNeedsf2P 1y ago
There's a Flathub Discourse[0], but it's died down a lot [0] https://discourse.flathub.org/ https://discourse.flathub.org/

OsrsNeedsf2P 1y ago

This one hits close for me. Flatpak is probably the best way to distribute desktop apps on Linux. I say this as an app dev, a packager, and a user. At one point I maintained close to a dozen packages. I eagerly waited for months to see what they would do next - what magical features they would introduce. I was active on the forums helping other users package apps, helped review Flathub submissions (since it was always the same problems each time), and started checking out what PRs were happening. Silence. The months turned into years, and as more years came, I slowly fell away from engaging with Flatpak. I'm back to using the AUR for most things (Arch, btw), but I'm quite sad to hear the situation get spelt out. Flatpak really was revolutionary; bringing modern apps and painless distribution to all desktops - LTS or rolling release. But it hasn't really changed at all since it first took off years ago.

WD-42 1y ago
I feel the same. Like a few years ago Fedora + GNOME + Flatpak was the magic sauce. Not so much anymore. I’m back to Arch as well, which seems as if its package repositories have only grown. The AUR is there but I’m shocked how little I need from it.
MindSpunk 1y ago
I have almost never had a good experience with Flatpaks as a user, outside of ease of installation. They almost never integrate with the system properly. Wrong theme, wrong cursors, wrong file picker, permission issues, drag-and-drop issues. You often need extra tools that broaden the permissions of apps post-install because some feature won't work (global push-to-talk in Discord is always fun, especially with Wayland). I couldn't care less about sandboxing if the UX sucks as a result. If binary portability wasn't such a complete joke on Linux we wouldn't need Flatpak, but here we are.
- Gigachad 1y ago
  Flatpak does have answers for this stuff but it's more the programs inside them aren't utilizing the right APIs, they are meant to use the portals api for filepickers which would use the system filepicker and securely portal stuff through the sandboxing. But many apps just don't. Theme is also an odd one. GUI design in general has shifted away from an OS theme and more towards an app/product theme which stays consistent between the product on different platforms. Discord for example looks largely the same on Linux, Windows, iOS, and web.

thangalin 1y ago

Years ago, I wrote an on-screen display (OSD) in Java for showing keypresses and mouse clicks[1]. Someone thought a flatpack would be useful[2]. I didn't see the point. It meant: (a) maintaining two installation processes; (b) collating download stats from two sources; (c) trusting a third-party system to maintain package indexes over time[3]; (d) adding yet another package manager to a system that already has a package manager; and (e) bloating the repo with another repo. Years later, I still only see drawbacks. [1]: https://gitlab.com/DaveJarvis/KmCaster https://gitlab.com/DaveJarvis/KmCaster [2]: https://github.com/flathub/com.whitemagicsoftware.kmcaster https://github.com/flathub/com.whitemagicsoftware.kmcaster [3]: https://flathub.org/apps/search?q=kmcaster https://flathub.org/apps/search?q=kmcaster - whoops!

rbits 1y ago
The upsides would be - Easy use on immutable distros - The user doesn't have to make sure they have the right version of Java installed - Auto-updates even if there is no repo for your specific distro And also you can find it through searching on Flathub I guess
- thangalin 1y ago
  > And also you can find it through searching on Flathub I guess Did you click the third link I posted, which searches Flathub for KmCaster only to come up dry? This was point (c): You have to trust that their search engine is correct, maintained, and updated. That doesn't come for free, it takes effort, and things go wrong.
  - Lariscus 1y ago
    This isn't a bug. Kmcaster is unmaintained and has been removed from flathub. [0] https://flathub.org/apps/com.whitemagicsoftware.kmcaster https://flathub.org/apps/com.whitemagicsoftware.kmcaster
    - thangalin 1y ago
      This only supports my point about having more stuff to maintain. Now there's this GitHub page having a large "Download on Flathub" link that goes absolutely nowhere because the package is unmaintained. Who makes the GitHub page go away? https://github.com/flathub/com.whitemagicsoftware.kmcaster?tab=readme-ov-file https://github.com/flathub/com.whitemagicsoftware.kmcaster?t... Also, the image on that page is outdated, which would have been one more thing to maintain. In addition, the install instructions are four lines of code to run, compared with three lines of code to download without Flathub. My point stands: Flathub adds an unnecessary maintenance burden (to some projects).

sabslikesobs 1y ago

I've switched to a flatpak-based immutable distro lately. It's great when it works. But so many niceties don't work, and then it feels like my computer is not really the fantastic tool it should be. For example: - I had to run around with a distrobox running WINE and a bunch of permissions and kludges to run an external tool for Godot - I gave up on the flatpak for Firefox because it can't talk to my KeepassDX flatpak - The Godot and Krita flatpaks are oddly unstable and crash more than they did on Windows (may just be Gnome or something) - non-flatpak tools like AppImages and .rpms feel pretty dang grungy I want to see more cool stuff with Flatpak so seeing the state it's in is kind of a bummer.

ggm 1y ago

If a packaging mechanism, respecting virtualisation had been capable of existing 30 years ago we'd have one. Now, given how the fracture lines run, we're fated to have three or more. It's pythons virtual environment and pip-is-weak problem, magnified. It's homebrew or Mac ports or fink or pkgsrc. Mechanisms designed after fork, are never fork neutral.

Ferret7446 1y ago
None of the common cross-distro packaging mechanisms have anything to do with virtualization. The core problem is software dependencies.
- ggm 1y ago
  A mechanism which can bundle its dependencies into an isolated runtime means dependencies do not fate share except at the ABI to the underlying OS. Virtualised container apps have simpler dependencies.

AStonesThrow 1y ago

20 years ago: "Oh no, the distros are struggling over packaging! We've got apt, yum, dnf, rpm, nix, docker..." https://m.xkcd.com/927/ https://m.xkcd.com/927/ For a long time, there was a pax debiana in my world. I used Ubuntu mostly (swapped to Debian and added Fedora towards the end) and the package management was really good. APT was a great tool and I got quite chummy with its ways. It was straightforward to keep my system updated and resolve dependencies. It was way smoother than any other updater system had been, even across major system upgrades. I sort of lost it when snap started usurping stuff. I knew it was coming, because docker was already making inroads. Then we had flatpak and company. As an admin, as a system architect, I felt that's the point when I lost control of my system. It wasn't possible to know its update state anymore. It wasn't possible to centrally manage or monitor those updates. It became a free-for-all of self-updates and shadow updates. Ubuntu was also introducing livepatch and kernel updates that went outside the apt model. I think that perhaps it became too great a burden for the major distros to be packaging all of their own downstream packages. Perhaps they saw the opportunity to offload some of that packaging burden on a really pro service that could just package everything, and make pan-distro packages available. If Debian and RHEL packagers are doing less downstream packaging, then perhaps they could focus on their core competencies. I noticed that nearly every Ubuntu package needed to include Ubuntu-specific tweaks, and basically when Ubuntu was already downstream from Debian, why should Canonical be maintaining every damn package themselves as well? So what's the endgame for all this? Would apt or dnf/rpm eventually get abandoned and have them go all-in on a new system? Or does the proliferation and splintering continue? Many of us said that the beauty of Linux is our freedom of choice. Well there's too much choice. Look at Distrowatch and be paralyzed by not knowing what to choose. Windows or macOS on your desktop is easy to choose because there's... one of each. When I visited Catalonia my friend took me to Carrefour. We strolled the aisles and I spotted pig-legs (jamon serrano) on every counter. A huge selection of eggs. Everything my stomach could desire. She led me into the olives aisle and gestured around to all the olives there. She said pick whichever I want. There were so many. They were all in fancy jars. I knew nothing of olives. I left without choosing any. Linux will die a death of a thousand cuts, until some consolidation and unification can happen that's beyond the kernel.

tenebrisalietum 1y ago

dbolgheroni 1y ago

I've installed flatpak to install VSCode/Codium to have an usable debugger for a Python project I'm working on. After some time tweaking VSCode/Codium trying to get the debbuger to work, just realized flatpak could be the problem. After another considerable amount of time trying different flatpak permissions, realized this is not a good use of my time. Installed the same packages from snap, and everything worked OK.

bjoli 1y ago
The emacs flatpak is just a long and painful road leading nowhere.
Ferret7446 1y ago
Flatpak is far better for applications rather than system tools, e.g., Chrom{e,ium}, due to the sandboxing.

itsrouteburn 1y ago

If not Flatpak, what is the future for portable sandboxed applications on Linux? I would love a solution where I can run semi-trusted or untrusted applications (e.g. vscode+extensions) confident that it doesn't have uncontrolled access to whatever my userid privileges permit.

LtWorf 1y ago
The solution for untrusted code is to not run it.

foresto 1y ago

> Flatpak now has --device=input to allow an application to access input devices without having access to all devices. Oh, hey... I made that feature. Nice to see that other people want narrower permissions, too.

SubiculumCode 1y ago

Both flatpak and snap have been a bane with inconsistent behaviors, permissions bugs, and a bunch of stuff I never figured out. I got so frustrated with them that I wiped, put Debian on and just the old package systems.

MattPalmer1086 1y ago
I'd largely agree. Snap was what drove me away from Ubuntu, after the calculator app started taking ages to load. The calculator! It was instant before snapification. I have played with using FlatPak, and while it seems snappier than snap, I always ended up with something not quite working, because of permissions or sandboxing. The answer to a lot of problems seemed to be "don't use the FlatPak version". The set of software I use complex enough to need something like FlatPak while also not needing to interact with other things is basically very, very small.
- lproven 1y ago
  When was this? Snap _was_ a bit slow in the early days. It's not any more. I use Ubuntu 22.04, 24.04 and 25.04. Snap is pretty fast these days. I have gone around purging all my custom repos and PPAs, removing those apps, and reinstalling the snap versions. It's just easier and it works. I am running 3 quite elderly Thinkpads in near-daily use: an X220, T420, and W520. All Core i7, all with RAM maxed out, all with SSDs. They are perfectly usable for what I need and they have great keyboards which no more modern Thinkpads do. Ubuntu 22.04 on a 13-year-old Thinkpad loads snap apps in an eyeblink now. I can't detect any delay compared to natively-packaged apps. Yes, it uses a bit more disk space. I used to remove all snaps and then `apt purge snapd` but it's not worth the extra effort any more.
  - SubiculumCode 1y ago
    See, I really don't understand how my experiences were so different from yours. Not in terms of speed, but in terms of just working. It was always things like missing or misconfigured apparmor profiles causing errors with snap and/or flatpak, sandboxes needing to run/be owned as root error messages, failure to save documents in one of my home folders, adjusting permissions for that, still doesn't work...and on and on.

amluto 1y ago

In case anyone ever seriously contemplates a new design, here's an anecdote: Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents. I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too. However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better. (This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)

dartharva 1y ago
Mildly OT but I have longed for this kind of app portability in Android too. Some OEMs like Xiaomi apparently took note a few years back, offering inbuilt app "duplication" features in their OS's but only for a few popular apps like WhatsApp.
zzo38computer 1y ago
Yes, that would be better, for specific instances of the running program to have a set of permissions instead. However, I think this is not the only issue. It is what I had wanted too, not only you. I think that the entire operating system should need to be redesigned for many reasons (I mentioned before how to design a better one), and it would have that effect, that specific instances of a running program would be given capabilities as arguments (or through other capabilities, but the first ones must be given as arguments), and these capabilities can have restricted permissions, as well as more versatile things e.g. to log access, or to go through a proxy, or to set a disk quota, etc.

zbentley 1y ago

I see the real utility these tools are providing to many folks, but ... It just feels so ugly. Square peg meets round hole. We built all these tools for defining security boundaries for user-installed applications, and it turned out that the Linux packaging/distribution landscape was such a wasteland that people spent a lot of time duct taping software distribution artifact reproducibility onto the security-boundary tools. So now we're in this weird worst-of-all-worlds spot: The simplicity, performance, and decades of work we spent to make it easy to develop powerful applications that run directly on userland is now bifurcated/trifurcated and a mess. The legibility of "I want to run an application that dynamically links a cryptography library; that library is provided by the distro and I know it is both patched and compatible with the rest of the distro" or "my application can access files/devices at /path/to/whatever and use those resources if it has permission to do so" is buried under tons of container indirection. Meanwhile, as TFA explains in detail, the actual security/encapsuation boundaries that these tools were originally built for proved to be a fast-moving target for which tons of support is still missing years later. We can see the possibilities of what could have been in other systems. Take BSD's pledge(2) for example: its approach is so aggressively oriented towards only solving the security problem that I can't really imagine a world where the pledge/capability system "grew" a packaging/distribution ecosystem the way Snap and Flatpak did. Or take plan9's approach: perhaps if we had modeled the entirety of the OS in such a way that the basic SysV permissions model (users, groups, files, permissions) covered as much as possible of applications' security sandboxing needs, then things like SElinux/snap/flatpak wouldn't have ended up being necessary. The biggest thing that got us into this state wasn't the tools, though--it was the human stuff: the tensions between "distro/package repo maintainers are burnt out and want to support a relatively small number of dependency targets and ways to add things to the package graph on a given OS"; "app developers want to make complex software available to users as quickly as possible"; and "users are very willing to do insecure things to get new applications to run, but are generally unwilling to do complex things (configure/make, customize AUR sources, know what nix is) in order to install stuff". Fast forward a few years, add a lot of false starts and other bullshit due to dueling desktop environments/compositors/audio systems, and where we ended up is not good. The current situation is basically: "Come on down to DLL hell but way worse, we have: tons of brittleness when apps want to talk to the rest of the OS (sucks for users--but only when apps need rare and advanced functionality like ... uuuh basic audio playback), all baked into highly complex container systems (sucks for application authors) aimed at delivering apps that each package their own look/feel/OS integrations (sucks for distro maintainers and consistency of UX) in massive "it's not actually static linking, I promise" images, each of which contains 75% of an OS, running on leaky isolates (sucks for the security patchers) with an update story of "just download the universe again" (sucks for bandwidth/CDN costs)." Like, I understand how we got here. I get that it's better than the bad old days of "but which autoconf?"/"I just wanted to update my browser but then glibc-2.11-compat-compat-compat-but-for-real-this-time-FINAL updated and broke my bootloader". And I get that some of those areas might improve over time (e.g. OCI images help with redownload-the-world; eventually Wayland will percolate around and the container runtime X compositor geometric complexity explosion will die down; someday someone will finally fix universal D-Bus discoverability and security for the eighteenth time...). But overall it is and will remain a mess at a fundamental, philosophical level. Seems like the Linux ecosystem did this in a maximally slow and fragmented way, which is nothing new. But it sucks to see such an "everyone loses" end state as the result.

lleymrl651 1y ago

Nice breakdown.

dartharva 1y ago

It still irks me that AppImages (the unambiguously superior choice) are not more successful than Flatpak or Snap solely because Linux users (in their characteristic laziness) are only used to getting their software from monolith stores and repositories.

0xpgm 1y ago
At least in the case of Snap, I felt that Canonical itself played a role in making it dominant in Ubuntu so that they could control the ecosystem. Personally I use AppImage whenever it's an option. It's the closest we get to Windows and MacOS executable applications
plst 1y ago
I love AppImages, but Flatpak tried to go way beyond - centralized updates, sandboxing/permissions system, package once, run on many distributions... Getting software from repositories is not just laziness, you automatically get updates and the software from repos is supposed to work with your distro, that apparently is not always true with AppImages.

sohrob 1y ago

I'm not an open source maintainer or even a dev, but it seems bonkers to me that with all the numerous distributions out there, all facing the same problem of package management, that they couldn't just refocus their combined efforts toward improving Flatpak and guiding it toward universal adoption.

palata 1y ago
Maybe one reason why many "distributions" exist is that they don't feel like "distributing" the same way :-). Diversity is good. I don't want "one distribution" that chooses the init system, distribution, compositor, window manager, etc. I want to have choice. When it comes to distributing packages, I personally like system package managers. Not such a big fan of flatpak.
LtWorf 1y ago
Many people disagree on the idea that flatpack is useful at all. For example it's completely useless to me. Why do you expect me to help on something I don't use?
yencabulator 1y ago
By that logic, only GNOME is allowed to exist. No thanks. The people in power often make decisions a big chunk of the community disagrees with.

nycticorax 1y ago

I don't agree with him 100%, but I always find Drew DeVault to be thoughtful on this topic: https://news.ycombinator.com/item?id=32936114 https://news.ycombinator.com/item?id=32936114 https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job.... Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users." The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.

sbt 1y ago
The problem is that now you have to package for N distros. And the people who run the distro may not want to spend time on it, so you have to do it yourself.
- Arnavion 1y ago
  It doesn't have to be gated by "the people who run the distro". I started packaging a few pieces of software for a distro I use because I wanted to use that software, and I don't "run" the distros in any capacity. Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux. If you don't have even one user willing to do that for the distro they use, you probably weren't going to have users on that distro anyway.
  - troyvit 1y ago
    > Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux. I feel like there's a constant tug of war on this issue. If you leave it up to app developers then they have to package their app for N distros. If you leave it up to the distro maintainers then they have to compile N apps for their distro. I don't envy either group given how different distros are and how varied apps are in quality, methodology, etc. I look at Podman. In my opinion it could be (could have been?) a huge disruptor, but its RedHat (or Fedora or CentOS or whatever the hell those guys do now) versions are way higher than versions for other distributions, which creates for me (just a home user) an interoperability problem between all my different Linux boxes. RedHat if anybody has the resources to fix this but I guess they'd rather try to use it as a way to force adoption of their distro? I don't even know. Both the apps and the distros are volunteer-heavy. App packaging is a big job for either side. I'm still hopeful that Flatpak can help that job

zzo38computer 1y ago

I think D-bus has many problems and isn't very good. I also think the sandboxing (of Flatpak and other systems) has problems, e.g. lack of some kinds of permissions (e.g. permissions that depend on command-line switches, permissions to execute user-specified external programs by popen (without the restrictions affecting them too), and more), inability to properly use character encodings, etc. There are other issues as well, even though I think that the sandboxed execution is not a bad idea in general.

willmarquis 1y ago

Flatpak’s biggest bug isn’t in the code, it’s the bus factor. > Tons of features are stuck in merge-request limbo because there just aren’t enough reviewers, and if we don’t swap some “+1”s for actual PR reviews (or funding), we’ll be shipping apps in 2030 with a sandbox frozen in 2024 while everything else rides OCI.

forrestthewoods 1y ago

Over here in Windows land I can’t fathom why you need something like Flatpak just so users can reliably launch and run a program. I mean trust me I understand that Linux is so broken it needs something like flatpak. But imagine saying you’re disappointed the Windows executable format isn’t evolving! Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.

SomeoneOnTheWeb 1y ago
Thing is, .exe on windows is broken on so many levels. You don't have sandboxing, apps don't always follow standards as to where to store their data, there's no dependency management but if you don't have the correct version of e.g. java installed your app won't work. Etc.
dsego 1y ago
> Running an exe shouldn’t require decades of maintenance. That's why windows is so full of malware and viruses.
Propelloni 1y ago
> Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be. What do you think is all that stuff in C:\Program Files, C:\Program Files (x86), c:\Windows\System, C:\Windows\System32, C:\Windows\SysWOW64, %USERPROFILES%\%APPDATA%\Local and %USERPROFILE%\%APPDATA%\LocalLow or the seven versions of the C/C++ VS Redistributable you have installed? EDIT: typos
- Barrin92 1y ago
  in reality a bunch of stuff no user ever has to look at. On Windows literally anyone can click on a 20 year old executable and in all likelihood it just works because the good people at Microsoft care about giving the user a decent supply of libraries and stable ABIs and an actual operating system people can build against. The Linux world is just in complete shambles in this regard. You build something on one LTS release, you don't know if it executes on the next. As the joke goes (it isn't even really a joke), it's so bad that Win32 is the only stable ABI on Linux

tannhaeuser 1y ago

Great, after bringing Pulse (+ Limewire to fix it), systemd, wayland, dbus, flatpak to dilute and overcomplicate everything, RHEL is now abandoning the desktop alltogether. Meanwhile, zero new desktop apps have been created for Linux in like two decades. Today even Firefox on Ubuntu and Fedora can't access a webcam for teams/gmeet because of permission problems of layered container frameworks that are there just to protect fictional, as in non-existant, apps from accessing your damn files. Seriously, the only way out and where progress has been made seems to be embracing win32 apps using wine/proton, but maybe using SteamOS/Arch instead since bazzite is based on fedora.

blippage 1y ago

I'm currently using Slackware current. I use an approach of compiling from source or using AppImage. Things like Flatpak and Snaps are an opaque black box to me. I have AppImages for things like Zoom, KeePass and LibreOffice. I don't need to keep updating them. They do what I want them to do. I have them on a separate partition. If I reinstall my system they're all ready to go out of the gate. It's ridiculously simple. I did try out Fedora awhile ago, but decided it wasn't for me. Why is everything a Flatpak? Just use the repo mechanism.

pvdebbe 1y ago
Same system with me. Running gentoo without systemd or pulseaudio makes Flatpak and Snap totally nonstarters. I compile most of my stuff from gentoo's official repos and supplement things with select AppImages that work out of the box, curiously well.
mixmastamyk 1y ago
I don’t use flatpak on my main fedora box, rather added rpmfusion instead.

lucas_membrane 1y ago

I've been using Fedora 41 about half a year, and flatpak has not made it better. Fedora 41 started with a bunch of apps distributed as rpm, but some of them have since been updated as flatpaks when I run 'sudo dnf update'. Splendid, except that the rpm apps, now a little out-of-date, are not deleted, which may be good or bad, but that explains why I have duplicate icons for the same app all over my desktop, and its pretty confusing trying to tell which is which, which is better, or how to manage the all the differences and conflicts, which Fedora 41 makes anything but scrutable. The thing about the microphones and speakers getting tangled up, as explained in TFA, also was somethig of and for which I was unaware and unprepared respectively when I had some problem with the old-fashioned way and decided to install musescore as a flatpak. I've been thinking about upgrading to Fedora 42, but this article is giving me considerable premonitions of additional inconvenience and incidental despair. Anyone have this stuff under control?

enriquto 1y ago

Never understood the point of flatpak, snap and the like. Can't you just distribute static binaries? They are not that hard to compile. (I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)

dale_glass 1y ago
They're not at all trivial on anything big and complex. And the code I work on has loadable plugins, too.
brnt 1y ago
I did not find packaging up an AppImage that is actually compatible across distro's and version all that straightforward, and we were not even using Qt or GTK/libadwaita. How is this easy, in your experience?
- enriquto 1y ago
  > How is this easy, in your experience? add -static to your link flags? Sometimes you need to fiddle a bit with the order of the libraries, but that's it. In the ideal case, for maximum portability, i'd like to use the αpε format!
  - sirwhinesalot 1y ago
    Have you actually tried to make a fully statically linked GUI app on Linux?
    - enriquto 1y ago
      Just did it! I had to add "-static" to LDFLAGS and "-lxcb -lXau -lXdmcp" to LDLIBS, for an increase in binary size from 1MB to 3MB. It's a plain X program, i guess if you use fancy toolkits it may be harder.

ChocolateGod 1y ago

I use NixOS and Flatpak I found is the easiest way to install and update applications. The Nix model is great for system software, but not an ideal way of updating and installing desktop apps. The only problem I've had is fonts installed system wide not being available in the sandbox, but this is due to how NixOS exports fonts and can be solved by telling NixOS to publish fonts in /usr/share/fonts.

vrighter 1y ago

I think flatpaks are all about bringing android's limitations to mainstream linux.

poulpy123 1y ago

Linux has the worst software distribution model towards the general public of all OS. The one of windows (and probably MacOS but I don't know much) is also full of issues, but is still infinitely better than linux. When you compound the number of distributions, the number of their versions, the number of software, and their versions, you realize that having the distribution managed by the distribution or the software authors is unsustainable. In comparison, windows and mac only require at most 2 versions of the software each to reach at list 90% of the users. I don't know if flatpak or appimage or whatever are a solution, and I cannot propose one myself. But I really think that at one point the linux model will completely fail if it doesn't improve BTW I'm not saying that the linux model is always inferior. Actually it is often superior: in the server world were professionals take care of things, in the embedded world where the resources are scarce, the possibilities to configure and select everything to the smallest detail make it great.

lproven 1y ago
This is why the single most widely-used desktop/laptop Linux distribution in the world has a simple, brilliant solution to app packaging: It has none. You can't install new apps. It's ChromeOS. It has something like quarter to half a billion users, judging from the sales numbers of ChromeBooks and their supported lifetime. Real ChromeBooks let you install Android apps, but that is side-stepping the issue. ChromeOS Flex on a PC, which I use, doesn't offer that. You can open a Debian shell and install Debian packages in there, though. Handy for VLC. Ubuntu, from its own numbers, has maybe 20-30 million users. Debian about a third of that. All the RH distros less than Debian, maybe a tenth. In China, UnionTech says it passed 3 million paying users of UOS last year, implying numbers maybe comparable to Ubuntu's. Which in turn implies that most of China still runs on pirated MS Windows. All the other distros put together come to about 10% of the number of ChromeBooks sold in the last 3-4 years. The way to win in Linux packaging seems to be: don't do it at all. "A strange game. The only winning move is not to play."
- curt15 1y ago
  As a long-time Linux user, I also find it ironic that after years of Linux nerds basking in the "superiority" of their package managers, Homebrew on Mac OS has eclipsed them all in terms of universality and ease of use. For example, compare the install instructions for kubectl: Linux DEB/RPM (https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/ https://kubernetes.io/docs/tasks/tools/install-kubectl-linux...): 1. sudo apt-get install -y apt-transport-https ca-certificates curl gnupg 2. curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg 3. sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # allow unprivileged APT programs to read this keyring 4. echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list 5. sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # helps tools such as command-not-found to work correctly Mac OS (https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos https://kubernetes.io/docs/tasks/tools/install-kubectl-macos...): 1. brew install kubectl

Imustaskforhelp 1y ago

Side note but I wanted to build a cli program on flatpak and I kind of couldn't. I have unfortunately not read the whole thing but I just want these two things: better cli support better permission support as I have had some issues with permissions. Currently using nix-shell as a sort of substitute against flatpak because I just want to use ephemeral environments without any permission issue or smth. Like I do nix-shell -p obs-studio and run obs and then close the shell and be peaceful as I rarely use obs for example and dependency hell. I may have wrote the exact same comment in the past but I want to use archlinux so much but nix-shell is way more comfortable to use on nix(I know its available on arch as well) and nix has the same name but arch might have different name so IDK.

rollcat 1y ago

This is a bit unfortunate. Flatpak is outright just a better tool than Snap. (I've had nightmare stories with Docker-via-Snap.) I do like AppImage better (it's simpler), but there's no equivalent of FlatHub, the discoverability is just poor. Also, per TFA: https://m.xkcd.com/2347/ https://m.xkcd.com/2347/

ongytenes 1y ago

I really dislike Flatpak because the humongous sizes of packages. I noticed that Telegram flatpak was 1.1GB in size and requires 3.6GB of the hard drive, whereas the regular DEB install was 28MB and needs only 82 MB. And there was no DEB available for Signal in the LinuxMint package manager. It also was a 1.1GB download that required 3.6GB of hard drive. Reason there is no Signal app on my desktop.