Flatpack vs Appimage
Posted by N3Rumie@reddit | linux | View on Reddit | 108 comments
Hey guys i am linux newbie and on youtube i v seen that there is strong preference towards flatpack (or at least in community of "the linux experiment") and i was wondering why?
I installed appimage and flatpacks both in my system and if one of them is available i always go for it out of convenience. But when both are available i usually go for what is closer to my mouse or more exposed on the site. So is there any real difference after installing package?
probonopd@reddit
AppImages are: "1 app = 1 file". No package manager, no installation, no root needed. Just download from the application author's download page, make executable, and run. Simple!
Flatpak is: More like a package manager, with repository, installation, root needed, dependencies, and so on.
name8_t@reddit
Flatpaks are kinda like the desktop equivalent of android apps. Each is encapsulated in it's own separate space, including its config. You can export a flatpak to a USB drive or whatever amd send it to someone like you would an APK file. It has to be installed to work and if installed from an online repo, it has auto updates by default. It is guaranteed to work anywhere, since flatpak basically ships it's own OS runtimes, completely independent of your system.
Appimages are kinda like .py or .jar files. You need a special runtime/library to run them (libfuse), although it's installed on most distros already. You might need additional libraries because the authors make assumptions about your system that might not be true - I've had some appimages be completely unusable on my Fedora install because they required an old version of a specific library and didn't bundle it. Auto updates are possible, but not built in by default, author has to enable it. Also they don't get integrated into the app menu without using third party programs to do it for you.
dobbelj@reddit
Appimages are fucking garbage, running around like a caveman to different websites finding the download button.
apt/dnf/zypper > flatpak > source build > writing the software yourself. If the last step fails, I may download an AppImage, but I'm more inclined to find an alternative.
(Sidenote just to harvest some more downvotes: Fuck Krita for preferring AppImage. Fucking idiots.)
SamuelSmash@reddit
This makes no sense, appimage is just a format, same way deb and rpm packages are a format.
You would need to use a appimage manager if you don't want to manually download appimages, which there are many. But I always recommend this one (and it also works with more stuff than just appimages).
MathManrm@reddit
there is no good reason to use appimages in this way
SamuelSmash@reddit
could you explain in more detail why?
I know the creator doesn't like when people make package managers for it lol.
But I think a lot of people know that the big problem with appimages is that you have to manually hunt it (as seen by several comments here as well), having the choice of not having to do that is great.
MathManrm@reddit
there are better solutions, like formats that actually want package managers to be used for them, and appimages are generally not compatable accross all distros, and appimages won't last forever in general due to relying on system packages
SamuelSmash@reddit
The only big difference is that with a package manager you dependency management done by the package manager and hope it doesn't break
Provided you are not using a musl distro, they pretty much are.
Besides that nixos maybe that you have to launch them in a different way?
As long as your distro is equal or newer than the oldest still supported ubuntu lts release, the appimage has to work. if it doesn't it is because the appimage doesn't follow the spec. Same way you might run into a broken flatpak or native package.
And also AM has a update mechanism for appimages, so that's not a problem either way.
Particular-Brick7750@reddit
You're just spreading misinfo throughout this thread. if an appimage creator makes his package on ubuntu 20.04 and doesn't bundle a so which his binary links to and you use ubuntu 24.04 where that so has been updated to a new version, the app breaks. You also aren't accounting for literally everybody not using ubuntu. What if my distro that doesn't have packages from 5 years ago tries to run an appimage? Everything breaks.
SamuelSmash@reddit
That's not how appimages work. The creator doesn't have to be manually adding the .so file.
The appimagetool, such as linuxdeploy, linuxdeploy-qt or go-appimage already runs ldd on the binary and copies all the libraries that the application needs.
There is a list of to never be bundled libraries that are always expected to be on the host, such as glibc. glibc is made so that binary will always work with newer versions of it
Only that appimage would not run, not everything.
Do you still think that after what I've explained to you?
Particular-Brick7750@reddit
no because you're just saying exactly what I said but somehow phrasing it as not a fundamental flaw of appimages.
SamuelSmash@reddit
Okay, what if a statically link everything and release at as an appimage? will that still be fundamentally flawed?
People don't usually statically link glibc and instead prefer to statically link musl or the binary still has a dynamic link to glibc but it is a very old version of it to guarantee compatibility now and in the future with any glibc distro.
AppImage is very similar to what I just said, just that instead of doing static linking the libraries get bundled in a file and the dynamic linker in the binary gets patched to point to those libraries, the advantage it has is that it is much easier make.
And also if you still think that's fundamentally flawed. Do you think what flatpak is doing is not flawed?
If you think so and you run into an appimage that doesn't work what is stopping you from running the appimage in a distrobox container that works for it? that's essentially what flatpak is.
Particular-Brick7750@reddit
flatpak just werks and is guaranteed to work and if it doesn't its a bug, appimage doesn't work and when it doesn't it's a feature.
SamuelSmash@reddit
What kind of non-answer is that.
I asked you if you thought that static binaries were fundamentally flawed and instead you just gave a politician type response. That just tells me that you know what you tried to argue makes no sense.
I've had flatpaks break before, I've mentioned yuzu here before already, I've shown you bug report of flatpaks breaking on a certain distro, etc.
Here you have another example of flatpak breaking on a specific distro: https://discourse.flathub.org/t/problems-with-mesa-drivers/5574
Particular-Brick7750@reddit
This is kind of like complaining that you don't have a display server running and therefore flatpak apps don't always work, in this case the user had a broken mesa version installed on the host and I bet none of his apps worked.
also, what's up with linux mint? seems to be the common denominator of issues here.
SamuelSmash@reddit
What's the point of flatpak shipping its own mesa then?
linuxmint is a very popular distro that ships flatpak by default, it also is not fedora which is the distro where flatpaks are promoted.
Particular-Brick7750@reddit
Because it solves other problems. This also seems like a niche issue that only affected linux mint users with a specific old mesa version on old amd si graphics cards and probably had nothing to do with flatpak at all.
SamuelSmash@reddit
At the same time it causes problems, specially for AMD users.
Yuzu's discord was plagued with issues of people trying the flatpak and running into bugs that had been patched on mesa over a year ago, and every single one of those issues were fixed by switching to the appimage.
I have this screenshot of someone that wasn't buying what I was telling them right until they noticed that the appimage didn't have the issue lol
Particular-Brick7750@reddit
This is a flathub issue not a flatpak issue. If I was running flathub I'd have a more frequent release cycle for the runtimes but it still makes sense to have a separate mesa version bundled.
In the post you linked you can see another advantage of this system: An app developer can use super new mesa versions with their app and prevent all sorts of issues caused by old mesa versions by using a new runtime.
SamuelSmash@reddit
yeah bud, lets ignore that's how everyone is going to use flatpak.
You could have always done that with appimages with distrobox my dude. And you wouldn't have had to deal with all the other issues of flatpak.
And the amount of CLI commands would have been similar even to what golden did there.
distrobox create -i imagenamedistrobox enter imagenamepacman/apt/dnf/etc install mesa./appimagename.AppImageSo to sum it up, flatpak is guaranteed but not really guaranteed to work? if I see an issue that's a problem of linux mint, or flathub, or anything else but flatpak.
And somehow you are still saying that appimage is fundamentally broken, if there is a bug that's an issue of appimage itself and not a bug, etc. got it.
So much for calling out misinformation lmao.
Particular-Brick7750@reddit
I don't know if you realize but your logic is literally the same. Literally every fault of appimage isn't real because its the appimage creators fault (and we'll harass and belittle them on their issue tracker because of it) and you should just do sandboxing, runtimes, etc yourself but when flatpak provides all the tools to do that stuff for you its flatpaks fault that linux mint ships broken mesa implementations?
I do not like flathub. It was much, much worse a year or two ago and it seems they're making fewer mistakes now but I still would do things differently. Flatpak lets you make your own repos and runtimes and everything and makes it incredibly easy. If I am ever inconvenienced by an issue caused by flathub I'll just make my own repo since it's dead simple.
Everything appimage does flatpak does better or abstracts away for you. Deduplication, runtimes, sandboxing, distribution, flatpakbundles (basically appimages), package management. If you say "well, its not appimage's fault that the creator didn't bundle librandombullshit.so.2 and your distro isn't ubuntu lts so you have librandombullshit.so.2.1, I can say it's not flatpak's fault that linux mint shipped a broken mesa version nor that they used to have very old versions of mesa on flathub.
SamuelSmash@reddit
Nope, there have been bugs in the appimage runtime that I've reported that have been fixed.
Can you give an example of this? usually when a library is missing from the appimage that's usually because a helper tool like linuxdeployqt or linuxdeplogtk wasn't used.
At no point should the creator of an appimage manually be adding libraries because the helper tools failed to do so, that would be a bug in the tooling
So yeah, you cannot say that say it's not flatpak's fault buddy.
This has some sunk cost fallacy vibes lol
flatpak, something that was originally called xdg-app, can't even follow the XDG Base dir specification lmao.
Even with this it uses way more storage than appimages lol
1.5 GiB with 30 appimages + some other stuff
This is double edge sword, on one hand sandboxing is good, on the other hand giving sandboxing by default to new users and having them deal with is it not good.
I was recently helping someone install linux (a total new user) and when I went to sleep I told them to only use their distro package manager to install packages, nothing else.
When I woke up I have a bunch of messages on my phone about them having issues with themes with a flatpak.
I just told them:
run this
sudo pacman -Rsn flatpak && rm -rf /var/lib/flatpakand install the theme in a different way, problem solved.And somehow 3 GiB of disk space were freed by doing that, even though they had only installed one app as flatpak lmao.
Never said anything like this.
Once again, The creator doesn't have to be manually adding the .so file
even if you added mesa-git to flatpak to run yuzu it still wasn't starting vulkan. it couldn't be fixed
Particular-Brick7750@reddit
This was a really lazy wall of text full of very amazing anecdotes, old information, intentionally misunderstanding what I said by cutting my quotes short from you so I'll consider responding later and respond to each part under the influence like you probably are writing this.
SamuelSmash@reddit
How do you expect me to respond after telling me that I was spreading misinformation and then you refused to answer the simple question I asked you about static binaries? You have shown time and time again you have no idea how appimages work, said multiple times that they are broken yet you refused to answer a simple question about static linking because you know what you are talking about makes no sense.
You have also shown some blatant double standards, downplayed the issues with flatpak for some reason, tried to argue things that were never said don't think I didn't notice the nonsense you tried to argue here about the runtimes being worth it when I was responding to someone saying that flatpak uses less storage with the obvious fact that is utterly not true. And even while being self aware that flatpak will use way more storage, you mentioned deduplication here. Like what did you expect was going to happen?
Particular-Brick7750@reddit
Bro I really hate responding cus you said so much bs and I wanna respond to all of it but tf do you mean I demonstrated I don't know how appimages work I do you're just saying everything wrong with appimages are actually not real because you can use tools to half-fix the faults
SamuelSmash@reddit
inb4 passing the static ldflag to my compiler is a half-fix.
Omg this shit really made my day, thank you.
Particular-Brick7750@reddit
What the hell are you on about bro what does static linking have to do with linuxdeployqt or whatever shit?
Also how do you expect people to use those tools if the developer is such a dunning kruger lunatic that he thinks QT platform plugins are "workarounds" and intentionally blacklisted wayland support on QT? I don't understand your mindset where you think this is an acceptable experience for developers.
SamuelSmash@reddit
Omg, now you are indeed showing that you know some stuff.
Really? Even the description of linuxdeployqt mentions how to add the QT Platform plugins. https://imgur.com/SM7nuox.png
Unfortunately it has to be an extra flag because
lddcannot detect those libraries.Yeah I disagree with that.
However the fix is 2 extra lines of shell lol
Once again it is really bad that the developer has to do this manually, I 100% disagree with that decision that probono made.
However I don't agree that is an "unacceptable experience for developers", something like that would be this recent move that fedora pulled for example.
In the end something great of appimages is that you are not forced to use any of the tools that the creator made, there are other implementations of the runtime and linuxdeploy, the suyu emulator for example doesn't use linxudeploy at all, they use this simple shell script.
Meanwhile lite-xl has been trying to make a working flatpak for 3 years
Particular-Brick7750@reddit
But didn't you say earlier you weren't supposed to do that? hmmmm
SamuelSmash@reddit
Indeed. that's a bug in the tooling I 100% agree. Also recently linuxdeploy-plugin-qt had a similar fix as well.
But you were talking about the appimage failing to start due to a different lib that wasn't a wayland library. If you still think that's unacceptable that's fair.
Particular-Brick7750@reddit
And do you know what inb4 means, dumbass? maybe you meant inAfter. Which year did you drop out of high school in?
Particular-Brick7750@reddit
bad faith
MathManrm@reddit
What are you even trying to say, flatpak is better in nearly every way than appimage, appimages are good for one-off apps you're never going to use again due to how they work, flatpaks are good for apps you actually want to work long term as they don't break, or if appimages don't break, they are extremely large so one offs are all they're really good for, with flatpaks letting apps share dependencies the best it can without letting things break.
SamuelSmash@reddit
I asked two simple questions to someone that thinks that bundling libraries is fundamentally flawed or something like that lol.
flatpak uses way more storage, you might argue that it doesn't matter and that it is worth it, but you were originally saying that they are better in nearly every way.
flatpak still has issues with its sandbox on certain applications.
flatpaks can break as well the only thing you could argue here is that maybe it breaks less?
flatpak cannot easily be downgraded, and I don't know if it is even possible to keep several different versions of the same application as flatpak.
flatpaks need internet to be downloaded and installed while you can transfer appimages thru a flash drive.
flatpak has that hardcoded
~/.vardirectory that violated the XDG Base dir specification, and its developers have fucking argued that the XDG spec doesn't apply to them.flatpaks cannot be launched as if the binary was in PATH, making them near useless for CLI applications, even snap doesn't have this issue...
MathManrm@reddit
It doesn't use more storage once you install more than one thing, and this is going only be true if the appimages will break much faster and be distro dependent
most of the sandbox issues are apps not implementing things, and aren't really issues with flatpak anymore
I don't know what world you live in, but flatpaks can very easly be downgraded, I've done that several times
In what situation do I not have internet? anyhow, you still need to download the appimage, which requires internet still, and you can tranfer flatpaks as files, just no one ever does.
Ohno that standerd half of linux apps don't follow, flatpak doesn't follow it.
appimages aren't any better in this regard, and snaps have many worse issues you have to deal with if you want to use them
SamuelSmash@reddit
mmmmmm
Meanwhile here is 30 appimages + some other stuff using 1.5 GiB
Like it's not even close my dude, I can't believe how flatpak has gotten away with this.
What's funny here is that here the system's mesa somehow broke flatpak
Even though flatpak ships its own mesa to "prevent this same issue" which in reality actually causes issues as well.
flatpak was originally called xdg-app, and the way the devs argued that the spec doesn't apply to them is insane.
https://github.com/flatpak/flatpak.github.io/issues/191 https://github.com/flatpak/flatpak/issues/46 https://github.com/flatpak/flatpak/issues/1651
One of the devs even talked about changing the spec so that flatpak is exempt lmao
So yeah, they argued that the spec doesn't apply to them while at the same time mentioned changing the spec to be exempt.
You can put appimages in PATH, simply put in
~/.local/binand rename them to the name of the binary that's in PATH and that is it easy.The big problem with flatpak not doing that by default, is that very few people are going to bother to use flatpak for CLI applications, even though flatpak is fully capable for that.
It also means that flatpaks aren't compatible with applications or scripts that want to launch a certain app that is in PATH, for example I have a script in my PATH that fixes the steam screensaver bug, that script is looking for a
steam-runtime, it will not work with the flatpak steam because I would have to edit the script just for flatpak.KnowZeroX@reddit
Appimages allow portable versions which are convenient, it is also a nice way to keep multiple versions of the same software
One of the nice things I like about Krita's use of appimages is that they do daily snapshots and appimages are also automatically generated on merge requests as well. So if I really need a feature ahead of time and don't want to compile from source, I can just grab the appimage.
Krita still supports flatpaks, they just prefer appimages because it causes less issues (due to the container stuff). I don't think there is a need to go so far to insult them for preferring appimages when they offer both
SamuelSmash@reddit
GIMP is also doing this now as they needed that for testing in development.
The appimage is not being official released though as it only works on debian.
TalosMessenger01@reddit
Appimages won’t show up in your desktop environment’s app list unless you do some extra work. They also won’t update along with everything else, you have to do it manually. And you download them off of a website instead of a repo. Personally I prefer flatpaks for those reasons but I’ll use appimages if that’s the only option.
berickphilip@reddit
So I want to properly understand this..
coming from Windows:
Flatpaks are more similar to when you use the installer version of a program, and Appimages are similar to downloading, uncompressing and running the "portable version"?
CommercialPug@reddit
Not really. Flatpaks are more Windows Store apps in the sense that you open your desktop environment's software center which can download and install the app in a centralised location (CLI is also available).
But yes an app image is akin to a portable program on windows. You download the .appimage file and that's the file you always run to launch the program.
berickphilip@reddit
Thank you so much! This is really helpful.
Ironically I usually like having the portable versions of apps (on Windows) for a couple of reasons:
not cluttering or bloating the system (registry or other components), nothing loading on startup or running in background;
I am usually happy using a version of a software that works for me, and don't really feel the need to keep updating for the sake of it, or FOMO. (of course from time to time if I check and see that there is an interesting new version I skip directly to that one).
I prefer to always have local backups of small tools and scripts that I use in specific cases.
Still I do understand that linux is constantly evolving so recently to keep learning and adatping to it, I am using apps from repositories and flatpack manager (this is different from Windows constantly "changing" to fit their buusiness needs, so much so that I have to block updates and use offline portable programs).
QwertyChouskie@reddit
For what it's worth, apps on Linux almost exclusively get better with each version, vs Windows where apps generally get more enshittified with each new version.
Background_Till_9131@reddit
What an absurd statement when most people use the same things whether on Windows or Linux.
berickphilip@reddit
Exactly. At one point in long gone history, updating the system and the programs in Windows was good and positive like that..
Dring the now ancient times of Win XP, 95, 2000 etc.
Maybe even Win 7 era was good on that front.
Developers engaged the user experience as one of their priorities, not as a hurdle or an afterthought.
I feel like the current state of Linux is similar to that.
This also makes me a bit aprehensive and worried that history might repeat itself somehow and shitty people with lots of money turn things to worse again. (Hope not)
cAtloVeR9998@reddit
Quite understandable. One of the reasons that I like Flatpaks so much is that it reduces “dot file bloat”. Often packages on Linux write configuration in hidden files in your home directory which isn’t removed on uninstall (and in some cases conflict with each other. Like if you switch between two Desktop Environment, your font/gtk/icon settings may be altered by each DE). Usually Flatpaks store their dot files under ~/.var/ which gives you more control of what hard-to-remove configuration is written.
Loud_Literature_61@reddit
On the other hand I prefer the shorter directory paths of the config files in the regular user directory. They are more predictable/reproducible when I want to back up the actual config files into a subdirectory, to be used by a post-install script. For the sake of configuring other computers, complete with user preferences for the first user, after a fresh OS install.
BrokenG502@reddit
The other thing to consider is that flatpaks run inside a sandbox, so afaik they don't clutter up your computer in the same way. Ofc both have advantages and disadvantages. I'll usually try to install via my repos first, then compile and install from source. Failing that, I use flatpaks for GUI stuff (like discord or steam) and appimages/tarballs for CLI stuff, where I only care if it's on path or not.
The main thing about appimages is that they're a standalone single executables, so they don't need any extra dependencies. This makes them really good portable apps. For flatpaks I think the windows store analogy is really good. For the "downloading, uncompressing and running", the equivalent is tarballs. Which is the same as downloading everything in a .zip except it's a different file format.
doc_willis@reddit
Yes - Something like that.
But you dont need to uncompress them. They handle that if needed when ran.
Upstairs-Comb1631@reddit
Appimages are autoupdating. If a app is supporting it.
BigHeadTonyT@reddit
I think installing "appimagelauncher" is enough for the app to show up in Application Menu.
But for updating, yeah, I download the new version and double-click that.
Upstairs-Comb1631@reddit
I have Matrix Beeper client and it updates itself.
SamuelSmash@reddit
Say no more manual downloads: https://github.com/ivan-hc/AM
Shadowborn_paladin@reddit
Appimages do have the advantage of portability. You can put them on a USB and still use them whenever.
You can keep around a USB with programs that are good to have around but aren't used super often.
Unicorn_Colombo@reddit
This is not correct: https://docs.appimage.org/packaging-guide/optional/updates.html#making-appimages-self-updateable
BNerd1@reddit
like rpcs3
ArnyBradflock99@reddit
I like app images for every reason you made it sound bad with myself.....
lazycakes360@reddit
Gear Lever is pretty good at integrating appimages with the app list and adding metadata.
UptownMusic@reddit
Both work. How to deal with choices: If the program has a graphical user interface (GUI), use flatpak. If the program has a command line interfact (CLI) use Appimage.
fcrv@reddit
Similar to everyone else I generally prefer Flatpacks due to the sandbox. I feel a lot safer knowing exactly what an application can access.
However I did want to mention one aspect of AppImages that I love. It's very easy to backup a particular version of an application on an external storage device. So if you are ever in a situation where a computer doesn't have an internet connection or where an application was discontinued (Yuzu), it's very easy to just get your backup and do whatever you need to do.
Technically Flatpak allows you to do something similar with a USB drive backup... but it just feels so complicated in comparison... I really hope they develop some sort of compressed, single file, offline installer for Flatpaks in the future.
SamuelSmash@reddit
You can sandbox appimages with bubblewrap now
I actually use the suyu-emu as a sandboxed appimage.
You would get appimage 2.0.
What I personally hope is that in the future we have more tools installed by default in Distros/DE that let you automatically update and sandbox appimages, when that happens there will be no need for flatpak anymore, I can only dream about that though.
manobataibuvodu@reddit
I prefer Flatpaks
SamuelSmash@reddit
Not true, flatpaks do break as well on certain distros.
Also on some apps where udev rules are needed flatpaks can't work right for special controllers, or that's what I've seen at least. yuzu also had many problems with the flatpak as the version of mesa that was available was too old for it.
Yes by default, doesn't mean that appimage cannot be sandboxed, and as a few years ago you can even use bubblewrap sandbox with appimages.
Also I'm not very sure if using sandbox by default is a good idea, specially for new users, the amount of time I've seen people complain with the flatpak steam not being able to read external disks is insane, and yes I know it can be fixed, the problem is that it has to be fixed by the user.
That's the good thing that they don't come with a package manager, because it gives you a lot of freedoms on how you handle them, with flatpak you are forced to use flatpak, and that means deal with the issues that flatpak doesn't want to fix, example:
https://github.com/flatpak/flatpak/issues/994 https://github.com/flatpak/flatpak/issues/4187 https://github.com/flatpak/flatpak.github.io/issues/191 https://github.com/flatpak/flatpak/issues/46
Even snap iirc they actually let you run the snap without sandbox if you need to, flatpak you have to modify the source code basically.
And appimages can be updated, several do the update process themselves, like ferdium and the ps3 emulator.
And there are also plenty of appimage managers, however I only know that AM can auto update appimages. I don't know about zap and gearlever.
Try to beat this storage usage with flatpak: https://imgur.com/Xv1fF1q.png
I already tested it, when I installed libreoffice, kdenlive, brave and yuzu flatpak was using more than 3 GiB of storage (and yes I used flatpak dedupchecker), as multiple runtimes were installed which is a problem, and those runtimes each are massive as well.
More recent I saw this discussion at pwvucontrol that shows it
Just the gnome runtime alone was almost 1 GIB, while the 43 applications that I showed in the screenshot were using 1.5 GiB.
Particular-Brick7750@reddit
Is the runtime tradeoff not worth it for ensuring compatibility and preventing distro specific bugs?
The distro specific bug you linked was related to an old distribution/permission issue. You will never see libass.so.1.5.2 not found using flatpak but everytime I've been forced to use an appimage I have dependency errors since the bright definitely-not-deranged appimage creator decided dependency systems and package managers are le bad and everything should be like his fictionalized concept of macOS app distribution.
SamuelSmash@reddit
The original statement was that
"They are more efficient in how much space they take up".And now you are trying to argue that it is worth it? Okay, but that was not what was said originally lol.
And if you ask me, if all the software that I need comes as appimage (I even switched my text editor to lite-xl since it comes as appimage lol) it works on my distro, and uses way less storage than flatpak, I have no need for flatpak. as simple as that.
Never had this error in all the times that I've used appimages.
Because that's the point of appimage, no need for package manager, no need for root to install said package manager, no need to check if your has said package manager comes in your distro, etc. It should just be download and run, is it perfect? No!. But it does get very close to it.
Appimages were made to replace the tar compressed builds that developers used to release instead, and on that they are much much better.
mrlinkwii@reddit
it depends on if you need to roll-back a version , thats doable with appimages not flatpack where its the packaging that are at specific versions
in terms of usage their mostly the same , its a perfernce thing ,
i perwsonally would perfer anappaimge , becase i can roll back if needed and its bascially a portable exe
Clintre@reddit
You can roll back Flatpak to previous versions. Not as smooth, but it does work.
SamuelSmash@reddit
that's the problem
Even gimp now has an appimage that they use for internal testing, because testing multiple different versions of a flatpak is not easy.
Clintre@reddit
App images certainly have their use and I would use the for running multiple versions at a time as well. That isn't something most people are going to do.
SamuelSmash@reddit
Everyone will eventually.
I few years ago I was full on using the aur only for everything until a terrible bug hit ferdium where the zoom settings don't get saved, and it was an issue in electron not in ferdium, so the only solution was messing with downgrading electron system wide and hope that other stuff doesn't break.
I eventually just picked an older version of the appimage to use instead.
Also yuzu was another one, even though I was using the aur package as my main yuzu, I eventually had to use the appimage due to bugs.
More recently I've had had many issues with kdeconnect (the filesystem expose feature is broken in arch due to the update in openssh), so now I'm playing a cat and mouse game with downgrade everytime I update the system as the more recent version of kdeconnect broke even more lmao, I really wish it came as an appimage like kdenlive to just forget about these issues.
Clintre@reddit
Most users are not advanced users. No, most people will never use multiple versions of the same app.
SamuelSmash@reddit
But most people might try to downgrade if their application is hit by a recent bug which is what I was talking about, I've had this happen even with android applications.
With appimage is as simple as clicking to download an older version.
Clintre@reddit
Maybe, but I think most people will just come to Reddit and wonder why something isn't working. I think you and I have different views on how advanced a regular user is.
No worries though, I do respect your position. I may not agree with all of it, but that is what this is all about. Trying to get Linux as a whole to a better place. As mentioned, I use Appimages. As a developer, it works great for what I need many times.
KnowZeroX@reddit
Isn't that the point. I know a person on Reddit who came to ask for a way to do DVDs on Linux as they were forced to use windows. I could point them to an old Kden Live appimage which still had that feature before it was discontinued due to not being maintained (they only needed the basics which worked fine)
580083351@reddit
It all depends.
Using LibreOffice as an example, the flatpak uses GTK but the appimage uses QT. So if you want a more "native" experience on KDE the appimage is better.
The flatpak people are unable to build the KDE module for some reason. Too bad because it includes GTK and if they could build it, then it would be native for both desktop environments out of the box.
returnofblank@reddit
Think of appimages as portable packages - you download them on a flash drive and you can use it pretty much everywhere.
Flatpaks are more integrated with the system.
MathManrm@reddit
though that really depends on the appimage, most will stop working at some point
Clintre@reddit
Flatpaks for one simple reason, they integrate with the desktop environment out of the box. Appimages are a solid alternative, but until they work better within the desktop environment, without jumping through some hoops.
SamuelSmash@reddit
that will never happen, because gnome themselves don't want it, they are the only desktop environment where the appimage icons don't show in the active app menu, they are also make it hard to launch appimages from nautilus, etc.
This popped up in the appimage subreddit a while ago: https://old.reddit.com/r/AppImage/comments/1dhyuif/why_would_an_api_be_needed_to_display_appimage/
Also ubuntu is pulling similar moves with snap, their recent changes to apparmor broke a lot of appimages and flatpaks.
thankfully mint reverted that, and solus removed snap and apparmor all together.
So if you want to use flatpak because it is more convinient, that's ok, but be aware that's the result of the people that made flatpak forcing alternatives out of the way.
Clintre@reddit
I don't see anything about the people made or run Flatpak in either of those 2 trying to push alternatives away.
Ubuntu, it not a good example of how other distros are doing things regarding. We know they are making pretty bad moves as of late, I guess they couldn't let Red Hat/IBM corner all the bad moves.
I run plenty of Appimages and have never had any issue running them. The problem is the integration. The fact that there are ways to integrate them with a few different methods, including the installer, tells me there is a way to do so. Being that they are portable apps, of course it is hard for a distro and/or DE to integrate them. Especially since Appimages are not always built the same way. That is why it is up to those behind Appimages to make a proper and easy process to integrate them. That is not on distros or the DE to figure out.
Until then, Appimages will always be nothing more than portable and second hand apps for most people. You talk about using Flatpak because it is more convenient, well, people who are working want efficiency, so yes, that is important. If you want a system, like Appimages to be successful, then it is on you or the people to make it so, not the other way around.
SamuelSmash@reddit
I already linked the issue with gnome not displaying the icon for running appimages? every other major desktop enviroment has added that already, and iirc in mint it is a simple python script in their thumbnailer.
I think manjaro ships appimagelauncher by default in their install, not sure if they still do. That is what I was talking about.
Instead what distros are doing is shipping flatpak installed by default, which is a lot more work than a simple tool that integrates appimages into the system like appimagelauncher.
They have, there is even a daemon that checks for updates of appimages. but you likely didn't know it even existed.
Clintre@reddit
Gnome is not behind Flatpak. So, not seeing the correlation to those behind Flatpak. They were the first ones that Alexander showed it to and worked toward implementation with, but they are not behind it. Some of the original dev group also worked on Gnome projects, which is why they probably went to them first.
Yes, there are Distros that have made the effort, but usually, it is the spins/forks that are making that effort towards their user base. I applaud them for that effort. I love when distros do actually make an effort to support the newer packaging formats.
The Flatpak org literally went and worked with each of the major distros and DEs to get them put into their system. The distros did not come to them. That is my point. That was an effort put forth over several years to get it done.
As for the daemon, I have actually seen that, but admittedly not until more recent. That is what they need to work with the main distros and DEs to get integrated. Again, they are not going to come to them.
M whole point is that the group behind Appimages are the ones that have to make the effort. Groups behind the distros, DEs, etc. are focused on a ton of things beyond just app packaging. Whether it is better or not, is not always even the problem. The problem is that they have package systems that work for them right now and for the most part, no one is really complaining about it. Except for Snaps, seems many are against them. Most rarely even mention Appimages.
Anyway, going to have to agree to disagree here. As I said in my last reply on the other post, I do respect your views on it. I would love to see Appimages become first class citizens, like Flatpak has. It is a great format, it just doesn't have a seat at the table yet.
SamuelSmash@reddit
Wasn't there a recent drama it turned out that all the applications that have been featured in flathub or something like that were all gnome applications and people pointed out the obvious reference a almost all the people that worked at flatpak are gnome devs.
I'm very sorry I don't have a link about that recent drama I'm talking about, I will try to get it though.
Clintre@reddit
Yeah, I saw that drama. But as far as I know, based on a few devs I have worked with that are on the project, Gnome has no official ties. They have just decided that it is one of their packages of choice. An indirect tie would be through Fedora, as they do work with Gnome and do have a vested interest in Flatpak, but that battle has more to do with Snaps than Appimages. I don't actually think they are against Appimages, they just not made an effort to integrate it.
PJBonoVox@reddit
AppImages are great for a tool that's a PITA to get working but you only need to use it once.
Clintre@reddit
Absolutely
FryBoyter@reddit
From my point of view, neither one nor the other. I clearly prefer packages from the package sources of the distribution I use.
KrazyKirby99999@reddit
Appimages are often missing needed dependencies, while Flatpaks always contain all dependencies
QuickSilver010@reddit
depending on the distro you never have to install anything extra. ive been on kubuntu 20.04 for like the past 5 years and ive never had to get any additional deps for appimages
KrazyKirby99999@reddit
Ubuntu is the primary target distro for appimages, so that's not surprising.
I've encountered glibc version conflicts among other issues.
SamuelSmash@reddit
That's because the appimage itself broke the spec.
The appimage spec calls that the appimage needs to be build on the latests still supported ubuntu-lts release.
When probono actually tried to fix that issue, by making linuxdeployqt not work on newer distros to prevent the creation of such appimages, he caught a lot of hate for it lol.
QuickSilver010@reddit
I see. I wonder if debian also works.
FewMirror259@reddit
I use flatpak for the following reasons:
easily integrates into my system
they are isolated from my system so it won't cause problems
I can see all the flatpaks I have with one command
I can delete them with a command
I can update them with a command
SamuelSmash@reddit
flatpak is a gnome project and many distros are adopting, as the alternative is snap which is much worse.
If you ask me, appimages are better, every single thing that flatpak does can be done with appimages.
The only thing that flatpak has going is convenience as the tools usually already come preinstalled. that's all.
sdnavigator@reddit
I use whatever is officially endorsed by the creator of the software.
Some developers provide an official appimage, others official flatpak, others provide only official native package or repository.
I only avoid snap as I don't use Ubuntu.
xkcd__386@reddit
I didn't see anyone commenting on the security aspects.
I'm a bit more than normally paranoid, so I won't use either a flatpak if it was "made" by some random joe and posted on flathub. I check the tool's website to see if they have an official flatpak and use that. (As long as the ID -- e.g.,
org.gimp.GIMP-- is known I don't mind if it comes from flathub also, but I have to get the ID from the official website).AppImages are safer because if they're available they're only available from the software's own site or github repo.
You could argue that trusting
pacman -S <name of package>is just as bad but I'm going by the, probably thin, expectation that some extraneous vetting happens for people who are trusted as packagers for at least the big 3-5 distro families.AtlanticPortal@reddit
You mentioned the YouTube channel. Did you watch his videos regarding FLatpak vs AppImage? He definitely explains everything you asked.
cAtloVeR9998@reddit
Beyond all the good technical reasons to go with Flatpaks over AppImages, it is also notable that the creator of AppImage is a difficult person to deal with. To the extent of being banned from commenting on the OBS Studio Github for bad behaviour. His opinions on Wayland haven’t always been constructive.
kenbh2@reddit
I prefer appimages, they do have appimagehub[dot]com where you can find a bunch.. and you can use an app called appimagepool that makes it easier https://github.com/prateekmedia/appimagepool
Plan_9_fromouter_@reddit
I end up using native binary packages, flatpaks, snaps and appimages to get all the apps I need working on my devices.
Thetargos@reddit
Flatpaks are 'containerised' versions of the programs, they install, yes, but only to the current user's home directory. While you can install Flatpaks system wide and some components actually do, their ideal target are immutable distributions such as Fedora Silverblue (and Bazzite), SteamOS, and some others.
Appimages, as some other users have pointed out, are more akin to Windows' portable apps with a single executable, which contains everything needed for the app. You can un them from the file browser or CLI, provided you set the executable flag to the files (via the file properties). You can install them to make them appear in the menus.
The main convenience of flatpaks is that most are installed via repositories, which makes updating and managing them much easier. Appimages can also be self updated, but it requires that app providers build them in such way.
cac2573@reddit
no repository, no deal
Major_Gonzo@reddit
I haven't installed Flatpack and I use several AppImages. I use the AppimageLauncher software, and they "show up in my app list" when I search (super key plus type in app name).
doc_willis@reddit
I Go with flatpak if the package is official and is the type of program you want to be updated to the latest versions automatically. (like for a browser)
Appimages might be official, and they may or may not auto update
The only appimage i use is for my 3d Printer slicers, They do notify me of new updates (None of them i use auto update) I use Joplin appimage over the flatpack because for some odd reason, the Flatpack version constantly crashes on me.
kansetsupanikku@reddit
The right way is, of course, to follow recommendations of authors of certain software. Perhaps also not to follow youtubers.
Flatpaks provided by the authors are mostly ok, but you will find cases like Krita, where AppImages are preferred. And you will find issues with either, like Plasma integration for Firefox. But this depends on your choice on the fine-tuning vs common-experience spectrum (going from building stuff from source with personal patches, through vanilla source, distro packages and flatpaks to preconfigured vms).
paris_kalavros@reddit
Personally I use Flatpak for two simple reasons:
Appimages are great for some niche software, but they feel alien to the desktop environment and, last time I used them, there wasn’t a “store” way to search and install them.
1-05457@reddit
Don't use either, install from your distro's package manager where possible.
Clintre@reddit
In most cases, I agree. Just be check to check versions. Sometimes the distro package will be behind. Happens more with Ubuntu, but just need to check.