Skip Navigation
215 comments

  • I think it's a good way for people to release software for Linux without having to deal with specific distro stuff (which historically has pretty much been "just provide a .deb for Ubuntu and a .tar.gz for other people to figure out").

    I'm hoping that it pushes for more people porting stuff to Linux because it's a single target that gives you access to Steam Decks, Chromebooks and desktops.

    I don't think it makes sense for things that aren't desktop applications such as servers or libraries, just because those tend to be open source, don't need to be that up to date and benefit from tighter system integration. I see it as something that sits on top of other package managers rather than replacing them.

    For Flathub? Eh, if they turn out to be bad we can just all move to another server, we're not snap. :P I'm willing to bet that someone has already made a flatpak repo for Citra and Yuzu.

  • I personally prefer to use Flatpaks over traditional packages because of the added security, sandboxing, and overall convenience of not having to deal with dependency hell. It's especially nice being able to have proprietary applications sandboxed from the rest of my system without worrying that Steam is snooping on my 'super-important-tax-documents'.

    Flatpaks are also very useful for having up-to-date packages on distros like Debian, and it's derivatives. People can still use their preferred distro without having to worry about not getting a certain update, feature, bug fix, etc, for their applications.

    Being able to restrict what applications have access to is a game-changer for me. A lot of times Flatpaks, by default, have very lenient permissions, and with the use of Flatseal I can restrict it to my liking. Worried about Audacity's telemetry?? Turn network permissions off. Now, not all applications will work well (or at all) without internet connectivity, but for applications like Audacity, it works great!! Flatpaks can also be very useful for developers.

    That's not to say that Flatpaks are without their fair share of issues. Are they bloated?? Yeah, and although it's not an issue for me, it may be for some people. Desktop integration is, meh. Themes, and fonts don't always integrate the best. (A while back there were issues with Flatpak's sandbox, but I won't touch on that because I need to refresh my mind on it, and it was actively being developed to fix those issues so it possibly isn't even an issue anymore.)

    Overall I think Flatpaks are absolutely wonderful.

  • I use them for some things and I think they are fine. Mostly apps that are kinda messy and I want to keep them and their atrocious dependency tree away from my base system. I also like to use them for proprietary apps or apps where I actually want to use the sandbox. Other than that I prefer native packages 99% of the time.

    Flatpak is slower to update than pacman, the cli interface just doesn't feel good to use. There is the weird naming, no real way to get a dependency tree, can't hide those annoying eol messages even for apps that I specifically don't want to update. Another thing is that not every app was made to run in a sandbox or it is just more difficult to use sometimes. A lot of people tend to cite ide's, but in my case I was having issues with the steam flatpak. Running games with steam was fine, but anytime I wanted to hook up something third party eg: mods, cheat engine, etc. Doing so in the flatpak either required some tinkering around the sandbox or straight up didn't work.

    I feel like that last sentence sums up the whole experience. If you just need to point and click and have it work. Flatpak does that amazingly. If you need any kind of integration with other things, expect problems.

    Edit: just wanted to add that, the whole point and click and work is fine for 99% of people which is why I and many others choose to use it.

  • Flatpak is fantastic for end-user GUI applications

    Flathub is also great, but the fact that it's really the only repo that flatpak maintainers are using concerns me. I know I'm dreaming, but I would love to see some sort of federated or P2P hosting

  • Its a solution to one of the typical Linux issues. Its a step toward overcaming the fragmentation of Linux package managers.

    I don't personally like it too much, I prefer the distro package stuff, but I understand the app developers cannot manage a plethora of different package formats.

    Distro maintainters should, but its clearly more and more a massive task for different distros to keep up with the amount of apps out there.

    Also, npm, pip and the various "packaging" ways existing add to the chaos.

    I see distro package managers converge toward providing basic packages for the general system and some other solution like flatpack to provide additional stuff.

    I think it would be wrong for flatpack/containers to replace package managers as well, it's not their scope.

  • I use it as the primary way of installing apps on my Steam Deck, as well as my Ubuntu PC (I also use Snap over there). The apps installed via Flatpak just work, so I have nothing to complain about.

  • I prefer Flatpaks because it's a nice easy way of getting software without the chance of broken or missing dependencies for a program.

    Much better than Snaps, snaps is flatpaks but MUCH worse and slower.

  • I got sick and tired of the AUR for the simple packages so I started using it for most things I would use the AUR for, and I'm very happy with it. I think some packages have issues with default permissions - I was wondering why 86Box would forget my hard drive images but then I realised the permissions on my home folder weren't set properly - but that can be sorted anyway.

  • My main problem with Flatpak is that it hands temporary /var/run/1000 file links to programs instead of real filenames. That would almost be bearable, if Flatpak also took responsibility for keeping those links from breaking sometime after your next reboot.

    If I say "here is a path that an app is allowed to use", flatpak should just allow an open() in there to work. It should not lie about the name of files in there. An app should be able to open a file there, remember that name, and count on being able to access it again in the future.

    Other than that, Flatpaks are the bees knees. I love finding something I want to do, finding a solution in the flatpak store, and click-click I'm already doing shit. Finding Windows software is absolute garbage next to this.

    • Thats basically persistent portals. Would be possible if Distro portals had a button to give the app permanent (static) permission to that dir.

      Would indeed be useful and not hard to implement. In the portal window just add a button "permanent" which does 

       
          
flatpak override --filesystem=$PWD org.app.name

      Want to open a discussion or Feature request for your desktops portal?

  • How does it stack up against traditional package management and others like AUR and Nix?

    I only used AUR for a few packages (<5 at a time). It's to be avoided and only used if the other options are a massive pain (unless it's an official package).

    Then I left Arch and eventually landed on MX. During that time Nix with home-manager has slowly replaced flatpak, and I don't even have it installed anymore. Nix is better in every way, except for ease of use.

    Flatpak has great gui integration (for gui tools). You can click through everything, and the updates are unified. It usually works perfectly fine if you just need to install a few programs.

    With nix, there's a lot more setup, but there are many benefits. You end up with a list of packages, and that's really useful because you can take a fresh install, install nix and home manager, and then run a single line to reinstall everything. You can rollback updates, pin specific versions, install packages from a repo (if it has a flake.nix with outputs), and also configure them. I'm using the unstable branch, and it's giving me bleeding edge packages on Debian. And there's no risk of outdated system libraries, like with flatpak, because it provides everything.

  • I still prefer traditional packages, but I get why devs of complicated graphical apps with lots of dependencies hate them. As for Flatpak specifically, I'm not super impressed. It's just going to get more annoying over time having more old versions of all their libraries and more and more apps that aren't updating to the latest version so they eat up a ton of drive space and give constant notices to harass the devs, but out of all the major distro agnostic options they suck the least and they're getting better the fastest, which is why I think they've pretty much won at this point. I'm not currently using them, but it's pretty much inevitable that I'll have to at some point, and overall that's probably more good than bad. I think AppImages could have been better if the lead dev wasn't a walking, talking collection of weird hills to die on, but I'm afraid that ship has already sailed.

    • I mean if the apps are not maintained, they wouldnt work well as distro packages too, would they?

      • Not really. It's actually pretty common for simpler, unmaintained apps to get small changes in each distro made by the distro maintainers to stay compatible with their current library versions. There's nobody doing that on Flathub.

  • I'll always prefer the repositories, but Flatpak comes in handy for applications with weird dependencies where you need to compile everything needed on your own - or outdated 32 bits software.

  • Haven’t had issues, elementary uses them for system apps

  • I really like them. They give us a reliable application that doesn't depend the distro building a version for specific platform. For example if the newest versions are compiled for Ubuntu 24.04 but you're on 22.04 it might take a while to get the update.

    It does come at a cost though, it'll have to package all the dependencies for 24.04 in a layer of the package so it'll take a long time to start up and take a lot more memory than necessary.

    This is mitigated by flatpaks using same base for their application (like Ubuntu with Electron) but it still isn't the same as just starting up a proper apt program.

    I really like it since we can have a modern version of a program for small distros and in general the barrier to entry so much lower so companies can't just say "oh we can't support all Linux distros, not feasible".

    Aur you compile yourself for your own distro instead of it being done already by apt and the like.

    Nix is a super cool since you can just setup and configure pretty much everything so that you just press "install" and you'll have your Gimp, VPN and whatever apps all done for you. You'll have to do some heavy configuration so programming knowledge is not necessary but really helps.

  • Doesn't work properly, apps are bigger and don't always apply GTK themes. I also can't easily edit the desktop file to edit the icons. I therefore only use it as a backup when I can't find an app on the AUR or office repositories, which is very rare.

    • "Dont ask yourself if it works, but how it works"

      For editing desktop entries, copy it fron this strange directory ~/.local/share/flatpak/exports/share/applications/ to your normal ~/.local/share/applications which will always override the others.

  • I like it but I would prefer it to be more restrictive out of the box. Such as have apps declare a list of urls the are permitted to contact , a browser could have * .

    I'd like a more granular filesystem list too more akin to apparmors were each file path needed is explicitly defined, in some cases you would need a wildcard or a directory but for most apps this could be done.

215 comments