It really only makes sense to me when your distro is older or doesn't have the software you want. I fully prefer native packages too, though, but I use Flatpak on phone.
this post was submitted on 04 Mar 2025
149 points (98.1% liked)
Linux
52195 readers
967 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Flatpak is supposed to "just work" everywhere.
The real thing that Flatpak offers is one place to publish for Linux. You put your app in the App Store for Apple, you put it in the Play Store for Android, you put it in Flathub for Linux.
Maybe but probably not. People that develop applications can save a major headache by choosing flatpaks so the ecosystem will gravitate towards it.
At some point new applications that didn't launch a Linux version will do so but only on flatpak and older applications will start moving towards flatpaks since it's less dev time.
It looks to me as inevitable that the best versions of an app will be a flatpak but if you're on Ubuntu based system you can probably get by for very long without them.
Just use Nix. It can run all the packages on whatever platform. It has the largest repository of software & are some of the most up-to-date.
But then I'd have to run Nix.
So? Not everything is packaged on all distros & you can benefit from sharing & reusing declarative configuration even if for specific scopes (meaning not just NixOS).
That’s why Arch has the AUR. :)
AUR has a lot of packages but still nowhere near as much as Nixpkgs
If there is nothing appealing on flatpak, then sure. But for me it was really appealing and I still ignored it because you need to download big files at the beggining. But later on i started using it for steam and all because that thing is better staying as user-installed files in some form of permission sandbox
So far I have also completely ignored them. From what I understand they technically allow you to install old versions of software, potentially having multiple at the same time. This could come in a clutch when working with stuff like Godot or Blender where constantly upgrading to the latest version would cause issues on bigger projects. This is the only thing I can see myself using them for, at least in the near future.
I never use flatpaks and am doing just fine. I don't want my packages to be installed from a bunch of different places; I want it all managed by one package manager, which for me is my distro package manager. I've never noticed a problem arising out of not using flatpaks; everything I want is either already packaged for me, or I can make a package myself.
This is what's so great about Linux, you can use whatever the hell you want.
Flatpaks provide some cool security functionalities like revoking network access to a specific application. Maybe you care about this, maybe you don't.
My personal policy is to always install from the repos. Occasionally something is only available in flathub, which is fine for me. I really understand how hard is maintaining something for every single package manager and diatributions and totally respect the devs using a format that just works everywhere. If I were to release a new Linux app, I would totally use flatpak.
I really understand how hard is maintaining something for every single package manager and distributions
But for apps distributed in your system’s package manager, it’s not the devs that are distributing them in every package manager. It’s the distribution itself that goes to each repository, checks and tests the dependencies they need and creates the package for the distribution, along with a compiled binary.
When they aren’t offered in the distro’s package manager (or the version is outdated because the distro isn’t rolling release) things become more complicated indeed, and sometimes you can’t even do it because the dependencies are older than the ones you require.
Same boat. As a user, I greatly prefer everything to come from the repos. However, as a distributor, Flatpak makes so much more sense.
The only Flatpak I have installed is pgAdmin. I looked at the build on Flathub with the idea of porting the package myself but got scared off. It was a maze of Python dependencies running in Electron. That seems like exactly the kind of thing that may be better off in its own sandbox.
Personally it depends on distro and package manager.
If your on arch yes you can in a easyish way some aur packages may require you to compile it.
Other distros you can either compile the software from source or convert .deb to .rpm (for example) this is mediumish and takes time to do.
If the distro is rolling release, it can always support the latest software in theory, you’d just need to have the correct package formula, which is exactly what AUR offers.
The problem with AUR is just that the author of the package is likely not the author of the software and not affiliated with the distro, so you should normally check what the script is doing.
Agreed
I'm using MX Linux AHS, it is Debian based, it is always up to date, like latest firefox a few hours after it's out, kernel 6.12.17 as of today, etc.
It has no systemd, no snap, no flatpak. It just uses the good old .deb and everything is working fine.
Glad it is working well for you. What does that have to do with this post?
no flatpak. chill.
view more: next ›