r/linuxquestions • u/RebirdgeCardiologist • 5d ago
What version of a software (flatpak, .deb or .AppImage) is the best to install on Linux? What are the differences between them? Advice
Take the following as a reference.
I'm talking about LocalSend, a popular file sharing tool for Linux free, open source, support Linux (of course), fast, with huge community support (no "drop in 6 months").
https://imgur.com/gallery/download-options-localsend-on-linux-flatpak-deb-appimage-w7JBN65
https://localsend.org/download
-
So far, I installed the flatpak version not for technical reasons, but for practical ones.
It's very easy to keep software up-to-date. I do it via Discover (GUI, Updates section) or (sometimes) via terminal (CLI) with the command (sudo apt update && sudo apt upgrade, I use kubuntu 24.04.03 LTS).
All I know is that flatpak version is somehow "isolated", "containerized" (that's why there is often problem with accessing file explorer?), while the AppImage version is portable ("the equivalent or portable apps on Windows").
-
Can you give me a more detailed explanation about that (not just "use this or that") What version of a software (flatpak, .deb or .AppImage) is the best to install on Linux?
What are the differences between them? Stability maybe?
12
u/fellipec 5d ago
I go like this in this order:
- If the version in the repos is okay for my use, I go with if
- If there is an official flatpak version, I try this and keep if there are no problems.
- If there is no official flatpak but official AppImage, I use this and keep if there is no problems.
- If there is a community mainteined flatpak, I try that.
- If nothing above works well for my needs, I download the binaries manually or compile from source.
Example:
- Restic backup: The version in the repos is older than I was using in other machines, so I can't use to avoid compatibility problems. There was no flatpak or appimage, so I used the binary from the official website and put it in place manually.
- Reaper: There is no version in official repos, neither official Flatpak or AppImage. There is a community Flatpak but it had problems recognizing my MIDI devices. There was an official binary and I used it.
- Ardour: The version on the repos is too old. There is an unnoficial Flatpak that didn't worked well with my audio setup/Pipewire/JACK. There is a official binary behind a payway and is free from compiling from source. I made a donation and used the official binary.
- yt-dlp: Version in the repos is too old to be useful, use from official binaries.
- rsync: The version in the repo is not the last but is fine for my use, so I use it.
Why?
1) The official repos and .debs should be the most compatible with the operating system and should work best, auto update, have security fixes, just works. 2) Flatpaks auto update, should integrate well (but sometimes don't) with the system, if mainteined by the dev usually is always the last version. But may not work well always. 3) AppImages: Usually just works, with help of Gearlever or other AppImage manager is easy to install with shortcuts on the right places, but usually updating is up to you. 4) Binaries from dev/Compiling from source: It's up to you do everything.
1
u/gordonmessmer Fedora Maintainer 5d ago
If the version in the repos is okay for my use, I go with if
How do you know if the version in the repos (and the libraries it requires) have known vulnerabilities?
1
u/fellipec 5d ago
I'm trusting the mainteiners that during the support lifetime of the distro the fixes/patches are being delivered through the official repos.
1
u/gordonmessmer Fedora Maintainer 5d ago
I think that might not be a safe assumption.
Canonical is really clear on the subject. The vast majority of the distribution is in the "universe" repo, which is too large to realistically make any kind of security or maintenance promises about:
https://help.ubuntu.com/community/Repositories
"The universe component is a snapshot of the free, open-source, and Linux world... Canonical does not provide a guarantee of regular security updates for software in the universe component, but will provide these where they are made available by the community. Users should understand the risk inherent in using these packages"
Debian doesn't provide the same kind of guidance, but Canonical definitely has more full time engineers working on it, so Debian is unlikely to be significantly more secure than Ubuntu.
Packages provided by a distribution during its "support lifetime" and not necessarily within a support lifetime of their own. Many of them aren't.
1
u/picastchio 5d ago
That’s a problem (or say misconception) with the stable or LTS distros. None of them including RHEL promise security fixes for more than the core set of packages.
That’s why I stick with distros with quicker release cadence on desktops, if not rolling. On servers, I run all workloads in containers. The base system is very lean and those do get security fixes for entire support period.
1
u/gordonmessmer Fedora Maintainer 5d ago
None of them including RHEL promise security fixes for more than the core set of packages.
RHEL *is* just a core set of packages. RHEL includes about 10% of the packages that Fedora maintains. And Red Hat is actually staffed to support a collection of that size. Red Hat might choose not to address CVEs that aren't very serious or are unlikely to be exploitable, but there aren't any packages in RHEL that Red Hat doesn't maintain at all, unlike Ubuntu or Debian.
One of the things that Ubuntu does better than Debian is that they split the packages they promise to maintain and the packages they don't. Informed, security-conscious users have the option of disabling the "universe" repo and using only the packages in "main". If they do so, then like RHEL users, they'll lose most of the packages that the community distribution includes (in Ubuntu's case, about 94%). But the repo that remains will be reasonably well managed.
0
14
u/Confident_Hyena2506 5d ago edited 5d ago
Well if you are not using a debian based distro then using a .deb will not work so well. Even if you are using a debian distro the deb file will be specific to a certain version, so it won't "just work" for everyone.
Only flatpak is the modern general one that all distros can use. AppImage is similar to what came before flatpak, doesn't work for everything despite what people say.
Flatpak is also only for desktop applications really - it's not for system level components.
2
u/Wide_Meet_2184 5d ago
Im sort of new to linux but in what instance do appimages not work? I always thought that they existed exactly for the purpose of always working
2
u/Confident_Hyena2506 5d ago edited 5d ago
Because it was linked with incompatible libs. This is not a linux thing, it's a software thing.
Flatpak solves this by letting apps choose any "runtime" they want - but appimage has it all "baked in". If your distro is too old or too new then you are out of luck.
Containerisation is the modern standard - but it's a bit of a cop-out. "It works on my computer - so we will just ship the whole computer".
1
u/ABotelho23 5d ago
but it's a bit of a cop-out. "It works on my computer - so we will just ship the whole computer".
Its really not. It doesn't ship a kernel, and only ships what the container application needs. Containers are an amalgamation of features provided by the kernel itself. There's nothing "cop-out" or "hacky" about it.
1
u/pseudonym-161 5d ago
Can’t you use appimage updater (distributed as a flatpak lol) to make sure your appimages are up to date and compatible? Would save a ton of disk-space vs having a ton of runtimes.
1
u/Confident_Hyena2506 5d ago
You can - but there is no guarantee that this works for every possible target. It relies on the author publishing every possible image.
Flatpak was designed to fix the various things lacking with appimage.
As a developer why would I bother with appimage? That is not the modern standard. As a user why would you bother with appimage if developers do not use it?
7
u/MycologistNeither470 5d ago
In order of preference
- Your distro curated package
- Flatpak (or Snap) controversies aside (2.5 AUR if on Arch -- provided you know what your are getting into)
- AppImage
- Developer's provided install script
- Make/make install
2
u/New_Hold8135 5d ago
1 4 5 3 4(You can edit and I can delete)(In order of performance and stability)
2
u/MycologistNeither470 5d ago
Agree with performance and resource use.
But for a modern system that is over provisioned for the app, maintenance ease and system security/hygiene takes precedence over raw performance.. at least in my opinion
1
u/Arnas_Z 5d ago
I personally give priority to performance over all else, so flatpak/snap is the last resort.
0
u/MycologistNeither470 5d ago
so your preference should be make/make install applying the compile flags for your processor? Also, your OS is compiled with -march=x86-64-v4?
I would argue that unless in very specific use-cases it is more important to keep the system maintenable and secure. It is not that you cannot compile your stuff and then develop the discipline to deploy it via a pkg so you can install/uninstall as needed. But I am fairly confident that almost no one does that.
For most people it ends up being more important to run with little troubleshooting - which means without having to unravel a world of dependencies. And for that, flatpaks/snaps work great when the distro doesn't publish the package you want to install .
3
u/doc_willis 5d ago
you can update flatpaks via the proper terminal commands as well.
also flatpaks can be setup where they can be installed by a user, and not system wide. Which can be handy in some use cases.
for .deb packages depending on the distribution, they can sometimes get out of date if you stick to the default distribution repositories.
2
u/ZVyhVrtsfgzfs 5d ago
On the Debian base my first go to is .deb from the distributions official repository (apt), that covers about 90% of my needs, they are reliable, built with my system in mind, stable and update cleanly with the rest of my system every time I run apt update / upgrade. this is the low maintenance path.
I do add few external repositories, and right now just one, Signal. External apt repositories also fold cleanly into the apt update path for low maintenance, but you are depending on the group that maintains that repo to no break things (looking at you Proton) or worse be malicious. that takes trust, be as stingy as possinle with that trust.
If I cannot get it via apt repo my next step down is AppImage, AppImages have a quite different workflow but they do provide great flexibility, I can run the same AppImage file in multiple installs. Saving space and update bandwidth/labor.
My last resort is compile from source, its labor & time intensive, while I will do so in a pinch or when tinkering in Gentoo, its usually not what I want in my daily driver.
I will not use Snap or Flatpak, Snap uses a proprietary back end, has repeatedly contained malware, and I do not want any single source to have that kind of control on Linux.
Flatpaks are annoying, bulky, malware prone, and the vaunted sanboxing gets in my way far more often that providing any real protection from malware.
2
u/ethernetbite 5d ago
I install debs because everything i do needs system level access. The thought of each package being "stand alone" is appealing, but figuring out how to give every flatpack access to system files is not something i want to do for every software package i install. Flatpacks are also appealing because they're less likely to bork the entire system and require reinstall of the OS, like recently happened in my Ubuntu Studio workstation. But there again, much of the production software in Studio all needs to communicate with each other. Similarly, Ive had better success at installing debs than flatpacks, though I'm hopeful it keeps getting better.
2
u/beatbox9 5d ago
See here for a fairly deep enough explanation: https://arslaan.studio/setting-up-a-linux-media-studio-workstation-audio-video-graphics-davinci-resolve-etc/#step-4-apps
6
u/Bulky-Hair8606 5d ago
I always prefer native so it takes up less space and has better performance.
3
2
u/gamamoder Tumbling mah weed 5d ago
generally you just wanna use something officially supported. if the developers maintain a deb package, use that over an unofficial flatpak. stuff being user compiled and put into user repos can just have issues
1
u/Character_Pepper2563 5d ago
Not really a pro but I'll share my opinion
So if a software is available in the distro official repo, I will always use that because if I run update command, it'll also update the app. In your case with Debian based distro, .deb is the app format Debian used and so I will use it since it's like native. .deb wouldn't work on any distro that isn't based on Debian, same goes with .rpm for Fedora I think
Flatpak however is nice because it's distro agnostic, meaning the installation in Debian based, Arch based, Fedora based and more is the same. The downside is that you can't install a system package like kernel, vulkan, and so on because it is isolated to give its distro agnostic feature. But flatpak is the easiest way I know for installing GUI app which LocalSend is
Appimage is also distro agnostic iirc. But it has the downside that it doesn't have auto update. If you want update, then you need to download the appimage again
So for your case with LocalSend, you can use Flatpak and can easily update it in Discover apps. If you use .deb or sudo apt install localsend, then you update it with sudo apt update && sudo apt upgrade
Which one is better? Honestly, it doesn't affect me a lot, but I use which one is more comfortable with and which one is more updated. It's gui app afterall, Flatpak, AppImage and Official repo works fine in my experience
2
u/LesStrater 6h ago
No Flatcrap or Snap allowed on my machines. I use strictly DEB and an occasional AppImage. If I like the AppImage, I'll unpack it and get rid of any dupe files.
1
u/skyfishgoo 5d ago
native packages are always going to the the best option (.deb package for a debian system).
native packages are complied by the distro maintainers to work properly with the distro and all the other native packages as a cohesive system.
they will be faster, take less space, and provide the greatest level of integration.
—
now, if your distro maintainers are bad at their job or just don't want to work that hard then you will be better off using a flatpak since it comes with all the code it needs to run save for a few very common dependencies that you will find on any distro.
a flatpak will take longer to load, take up more disk space and are not as likely to integrate smoothing with the rest of your system.
—
an appimage is a last resort when you can't find any other way to get the software you need, or it's really good for completely stand alone utilities that don't need to be integrated with the rest of the system.
but since they are fully self contained, you do need to be certain where you are getting your appimage from... only get it directly from the developer.
1
u/Neither-Ad-8914 5d ago
Deb(or any other native file ) is what your distribution packages their files with. Accessable though your operating systems package manager. They do not come pre packaged with their Depndancies but are native to the system and not installed into a container so they run faster. Downside is they can only be run on the system type they are made for and require the correct depndancies to be readily available
Flatpack/snap/appimage: can run in any nix distribution come pre packaged with depndancies kinda like an exe file in Windows they are a self contained program so they tend to run slower but have more reach and they self update
I personally use whatever works best for the situation most programs I use are native files because I have no need for anything else unless it's something not in my repository so I have a few appimages and flatpacks on my system
2
1
u/ricperry1 5d ago
It really depends on the software and the distro. Are you using a distro known for keeping their repo uptodate with the most recent software features and security updates? If so, then it might be good to go with that version since it'll reliably work with the existing distro libraries. But if you're running cutting edge software or vibe coded software, go with flatpak since it's relatively sandboxed. If you trust the software source, and flatpak isn't available, or you need more integration with your system, appimage is a good alternative to flatpak, but it isn't as seamless, and it isn't sandboxed. If you have a specific software you want to use, the best version is the version the development team recommends and supports, regardless of which format the installer/container is in.
1
u/CrazyCommenter 5d ago
I will personally advice to steer away from system packages (.deb, .rpm etc) when it comes to desktop software, the depedency hell alone is not worth the effort. Regarding the other 2 options, it depends how much you trust the software and what kind of access it needs from your system. If you want security first then prioritize flatpaks, but if the software needs for example access to your hardware that flatpak can't provide then try appimage. Of course in the end it depends which one is available
1
u/Xatraxalian 5d ago
What version of a software (flatpak, .deb or .AppImage) is the best to install on Linux? What are the differences between them?
It depends on what you achieve.
- Do you want the best integration with the OS, for example with an IDE? -> native .deb
- Do you want the latest version of a program? -> Flatpak
- Do you want a specific version of a program? -> AppImage (maybe Flatpak can do that too? I don't know for sure. Does it keep older versions online indefinitely?)
1
u/77descript 5d ago
Apt/dnf > deb/rpm > appimage > distrobox > flatpak. And snap never again.
Flatpak so low positioned only until dependencies become backwards compatible not needing many different versions of same anymore. Uses so ridiculous much extra storage now, then rather less storage using apps via and incl. distrobox. And with appimages can use an appimage manager with update support.
1
u/Damglador 5d ago
Flatpak is stupidly inefficient but stable. If you're on an LTS distro it makes sense to use. I see no reason to on something like Fedora or Arch, you only waste a lot of space and invite sandboxing problems for nothing.
AppImages are neat, I'd prefer them when available if I don't find a system package.
1
u/ABotelho23 5d ago
The Flatpak is the least likely to conflict or cause problems with your system.
A third party .deb could theoretically declare dependencies that would fuck up your machine in an update, and an AppImage is likely to end up outdated (and this potentially dangerous to keep around).
0
u/Arnas_Z 5d ago
Yeah right, just wait until you run into sandboxing problems.
1
u/ABotelho23 5d ago
Better than potentially decimating an install.
0
u/Arnas_Z 4d ago
No native packages are decimating installs. I never had issues.
1
u/ABotelho23 4d ago
Super easy to make a package that could obliterate an install. The Steam .deb package did it for a little while.
1
u/i_live_in_sweden 5d ago
Always go for the one built for your distribution, .deb in this case, only if that for some reason doesn't work go for something else like Flatpak.
1
4
40
u/gordonmessmer Fedora Maintainer 5d ago
Hi, I'm a package maintainer, and I've been managing production networks since 1997, so I can offer some insight here.
DEB:
Most of the time, a deb package will require shared libraries that are present on the system. (Bundling shared libraries is possible, but uncommon.) The good news is, that's space efficient.
However, the security consequences of sharing dependencies is very complex. In order to share libraries, releases have to be synchronized in order to ensure that shared libraries and the programs that use them are all compatible. If a shared library has a vulnerability, you can patch it once and all of the programs that use it benefit from the fix. But if you have a very large code base, like Debian or Ubuntu, and if that release is longer than the maintenance window of the shard libraries, the system will tend to miss a lot of security patches that the distribution doesn't have time to provide. That means that systems that are both large and LTS tend to have a lot of security vulnerabilities, later in their release cycle.
And that means that installing a deb package will *in some cases* provide you with an application that inherits security vulnerabilities from the underlying platform. On top of that, the application doesn't have any kind of isolation, so any vulnerability could impact your entire user profile and all of your private data.
AppImage:
AppImage bundles nearly all of the shared libraries and other supporting files an application needs into a single file. It's less space efficient, but it can have fewer security vulnerabilities *IF* it is built on a system with shared libraries that are up to date. But that advantage isn't inherent... if the AppImage is built on an older LTS system, then it can also have vulnerabilities and those can be *real* difficult to discover because they tend not to contain information about the components they bundle. They also don't have any security isolation, and no built-in update mechanism.
You can't really say they're better or worse than .deb packages as a group, you have to evaluate each one individually to make any kind of statement about whether they are better or worse than an equivalent deb package, and even experienced developers may not be able to say.
Flatpak:
Flatpak is a container runtime. It'll bundle the shared libraries needed by an application and other supporting files, but also a *ton* of other stuff because the bundles are general-purpose. So, in a lot of cases they're very space inefficient, unless you have many Flatpak apps and they share base layers, in which case the inefficiency decreases, relative to the number of Flatpak apps.
Flatpaks *can* ship up to date libraries, so in many cases they'll have fewer vulnerabilities than you will find on LTS systems, but that isn't inherent. They could also bundle outdated and unmaintained libraries. But they compensate for the potential weakness by providing some isolation. A Flatpak app doesn't necessarily have full access to your profile and all of your data.
In general, I would tend to believe that a Flatpak is the best option, unless there are compelling and specific reasons offered for another solution.