Which do you prefer: Snap, Flatpak, or AppImage, and why?

[-]

Otherwise-Listen-780@reddit

flatpak is very fast and its not propitery like snap

[-]

BrageFuglseth@reddit

Flatpak — both as a user and as an app developer. The ease of distribution and openness is unparallelled.

[-]

Core447@reddit

Yes, and the flathub webpage is simple and easy to understand making the life of new users pretty easy

[-]

I wish it universally handled permissions better though. If an Android app doesn't have access to a certain folder from which I'm trying it load something, it gives me a pop-up asking if I want to give that app access. If a flatpak app doesn't have permission to load something, it gives me a white screen in the file picker with no feedback whatsoever about why my files are missing and what I could do to fix that.

[-]

BrageFuglseth@reddit

The file picker specifically should not have that problem if the app handles it properly and uses the portal, FWIW

[-]

Xenasis@reddit

It would be a better experience if every piece of software ever made didn't need to add FlatPak specific code to it, though.

Would be great if this kind of thing was automatic like in Android (Android apps don't need to code in the permission asking).

[-]

ct_the_man_doll@reddit

Android apps don't need to code in the permission asking

But isn't Android apps already designed with with permission from the very beginning? Was it even possible for non-root Android apps to have unrestricted access to everything?

[-]

bobpaul@reddit

They've always been sandboxed, but they've definitely lost access.

But for old apps, Android intervenes. When an android app is built, it's built targeting an API level (and SDK levels map to Android OS versions, so it's targeting an android OS version, really). New versions of android handle old apps with a compatibility mode, but once an app is re-built targeting the latest Android OS, then the app has to handle things properly. And periodically Google removes old applications from the play store if they're not updated to newer SDK levels. They just did a big purge this August.

On example of loss of permission is the /sdcard folder. This used to be external storage that would disappear if the user ejected it or plugged the phone in with USB (then the SD card was given to the computer via USB-MassStorage). But while the SD card was present and available to the phone, apps had FULL access. Now by default, apps only have access to /sdcard/Android/{appname} unless they're given more permission. And /sdcard is now just a symlink somewhere else and purely exists for compatibility, since this is internal storage. Actual external SD cards are handled differently now.

[-]

Littux@reddit

/sdcard is just a convenient way to access /storage/emulated/{user-no} now. It makes using Termux easier

[-]

linmanfu@reddit

And this is one case where there's a conflict of interest between Google's own business and Google as provider of Android. Google wants people to use Drive and Photos as storage so that they are locked into its ecosystem. That's why Nexus and Pixels have traditionally had relatively little storage for the price. So they have made it more and more difficult for Android apps to use physical SD cards to add storage.

I generally think Google is by far the least worst of the tech giants, but this is a pain point.

[-]

Lexinonymous@reddit

It would be a better experience if every piece of software ever made didn't need to add Flatpak specific code to it, though.

Sandboxing doesn't really have a generic implementation on the GNU/Linux desktop in the same way that exists on Android. Flatpak has to provide it. If an app has a Flatpak but doesn't manage its permissions properly, that's a bug on the part of the app and needs to be fixed.

It reeks of either an app that was repackaged by someone else who doesn't know what they're doing, or a developer who released a Flatpak to fulfill a feature request without actually trying the resulting package in anger and seeing where the pain points are.

[-]

BrageFuglseth@reddit

I’d hardly call the file picker portal «Flatpak specific». It’s what any reasonably modern app should use no matter if it’s a Flatpak or not, and it is the equivalent to asking to see a specific file on Android.

[-]

mrtruthiness@reddit

It’s what any reasonably modern app ...

BS. It's fairly new. It's a dbus service which is the ugliest and least reliable and secure of all IPC (see any discussion of dbus on FreeBSD forums). And it's trashy the way the access to dbus in flatpak is simply controlled by a filter (and is the origin of at least one CVE because of how bad it is https://security-tracker.debian.org/tracker/CVE-2024-32462 ).

More info on portals: https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Background

[-]

Particular-Brick7750@reddit

that cve had nothing to do with dbus, literally just a input validation bug.

[-]

mrtruthiness@reddit

Not a dbus bug, but was showing how crappy the dbus interface is when arguments are passed straight through:

However it is possible to instead pass bwrap arguments to --command=, such as --bind. It's possible to pass an arbitrary commandline to the portal interface org.freedesktop.portal.Background.RequestBackground from within a Flatpak app.

[-]

Particular-Brick7750@reddit

so when you do bad input validation over dbus, dbus is insecure?

[-]

mrtruthiness@reddit

... so when you do bad input validation over dbus, dbus is insecure?

The fact that they chose to pass unvalidated string arguments over dbus indicates a problem. When it seems like every program chooses a poor and insecure interface to dbus ... you blame dbus for the problem. Go ahead and monitor dbus and see how much stuff that should be authenticated ... isn't.

[-]

Particular-Brick7750@reddit

Yeah but if someone made an unprivileged wayland protocol that runs arbitrary shell commands and sandboxed apps use that to escape the sandbox I wouldn't say that's a fault of the wayland standard. I think it's just freebsd cope.

[-]

lotanis@reddit

Android apps DO have to have some code for permission asking, even if it's to handle the two different cases (permission granted and not granted).

[-]

bighi@reddit

even if it's to handle the two different cases (permission granted and not granted).

That's different from what the person above was talking about.

Yes, apps should handle the lack of permission. But the act of asking for permission should be generic, instead of code specific for the packaging you're using.

[-]

md2074@reddit

If I ever have that issue, I use Flatseal and give it permission to use the directory.

[-]

Indolent_Bard@reddit

I hear it's MEANT to do the Android model eventually, but nobody's done this with desktop software before.

[-]

SpiritPilgrim@reddit

I like flatpak but I don't like how there are so many misleading apps that say they are by the developer but no verified check mark which leaves the user wondering if it is actually official or not.

One example is 'synology notestation'. It says it's by Synology but there's no verified check mark and synology makes no mention on their website as being the maintainer.

This should not be the case and there should be some level of regulation on flathub to prohibit using the actual developers name unless it's verified. It's very misleading and why I stay away from flatpaks for now.

AppImage on the other hand is always provided by the developers official website or their GitHub. No second guessing if it's official and to be trusted or not.

[-]

BrageFuglseth@reddit

Flathub currently shows a huge yellow «unverified» badge on apps that aren’t distributed by the owner of the app ID domain, which I think is enough personally. It just needs to be done by native app store frontends as well, such as GNOME Software.

[-]

SpiritPilgrim@reddit

You're not thinking about the average user though. Not everyone is an app developer like yourself and sees it through the same lens as you.

Most users are casual users and they are confused when the official developer's name is used beside an unverified badge.

The whole point is that flathub should put an end to allowing the official developers name to be used if it's not actually packaged and maintained by the official developer.

[-]

Imaginary-Problem914@reddit

The whole point is that flathub should put an end to allowing the official developers name to be used if it's not actually packaged and maintained by the official developer.

This has been the standard on linux since the start of time. The developers usually don't handle the packaging for all the distro repos.

[-]

SpiritPilgrim@reddit

Flatpak is not a distro repo though so this doesn't apply.

If it was a distro then I would agree with you but its not. Its an independent repo that actual developers of big corps often add their own applications to. This is why it should be a little more clear about what is and isn't actually by the developer when the name is misleadingly used.

[-]

Imaginary-Problem914@reddit

There are absolutely distros that have their own flatpak repo. Fedora is one of them.

[-]

BrageFuglseth@reddit

My issues with that wouldn’t necessarily be related to the usage of my name, as long as it’s clearly indicated as unverified.

I also don’t really see how this is a Flatpak specific issue? Distros are also mostly shipping their packages under the names of the original developers, without any way to indicate if it’s unverified, and with a much higher risk of breakage than Flatpak.

[-]

SpiritPilgrim@reddit

I think the way Flathub presents flatpak with its user interface is poorly executed is my point. All they need to do is a simple tweak to the app listing that very clearly in the face of the 'casual' user indicates something along the lines of 'developed by X but packaged by X'. Just anything that the casual, average desktop user doesn't need to do some investigative work to know for certain. A lot of Linux users hold this position.

Distro repos are usually widely understood to be packaged by the distro development team unless you download a .DEB or .RPM from the official app developer's website, similarly to AppImage's.

Anyhow, I like Flatpak, and I am a fan but just not a fan of the misleading listing interface, that's all. There's always room for improvement and further clarity with a few simple tweaks.

[-]

wiiznokes@reddit

Well, it's very easy to request the verified check. I would personally blame the developers here

[-]

SpiritPilgrim@reddit

You're missing the point, the example I gave is almost certainly not packaged by Synology. A large corp like Synology wouldn't skip such a critical step to gain user trust.

[-]

wiiznokes@reddit

Yeah that fair. But the `by Synology` in that case refer to the [developer-name](https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#developer-name), which is meant to be Synology. This is just the UI on flathub that is misleading

[-]

SpiritPilgrim@reddit

Precisely my point. Flathub needs to change this. How on earth they don't see an issue with this by now blows my mind.

[-]

RootHouston@reddit

It doesn't seem appropriate to change that. Synology still developed the app. Packaging an app is a different story. Again, you can tell if it's the same company packaging it.

[-]

SpiritPilgrim@reddit

You can't though without digging a bit

It should at the very least be very obvious beside the title.

There's also an inconsistency with this as some official apps use the official developers name below the title and some don't despite both having an unverified badge. That's ridiculous

[-]

RootHouston@reddit

You have a point about the consistency thing. All apps on Flathub should follow the same format.

[-]

great_whitehope@reddit

Yeah first thing I noticed when using snaps or flatpak was you can't tell what's genuine.

[-]

kaneua@reddit

The ease of distribution

I can't fully agree with that. There's no simple and obvious way to get the package files for applications and runtime dependencies for offline installation.

[-]

ninjadev64@reddit

.flatpak files exist, iirc, but they're not widely used

[-]

BrageFuglseth@reddit

Have you looked into flatpak create-usb? Should solve the cases where you have to transfer an app to a disconnected device.

[-]

kaneua@reddit

Yes, I looked into it. And that's why I mentioned worse user experience compared to deb and rpm (or even snap) packages. It's very far away from "download file (or a few) and open".

[-]

RoomyRoots@reddit

This.
They won the moment they made it easier to find, install and update apps for me.

[-]

WileEPyote@reddit

I just use native. Tried them all, but it's just not for me. I prefer to fine tune my most important apps myself.

[-]

Indolent_Bard@reddit

Found the Gentoo user /s

[-]

WileEPyote@reddit

Yes actually. lmao

[-]

Indolent_Bard@reddit

Do you compile them with the same optimizations that clear linux uses? I've read that the reason why it's so performant is that, depending on your CPU's architecture, they'll actually use different compiler flags for more optimization, which usually isn't something that software meant for a wide release doesn't do since it needs to run as many platforms as possible.

[-]

WileEPyote@reddit

I compile for my specific cpu (znver4), -O3, LTO, fat-lto-objects. It's all I ever really need. I tried going the full clear linux route, but it really wasn't noticeable and the compiling took a lot longer.

For apps that don't like O3, I'll use O2.

But yeah, maintainers need to compile for using a huge range of hardware. If you're just compiling for your own system and don't plan to release it, you can find some pretty noticeable gains by compiling certain things yourself. Especially the kernel.

I mostly just do the kernel, my browsers, dolphin and kate. Nothing else (so far) that I've tried was worth the hassle of compiling on Arch. If I want to dig deeper, I just switch to my Gentoo install.

[-]

Indolent_Bard@reddit

I was kind of talking about both Gentoo and Arch, but that's fascinating. Maybe that's why it's taking so long for them to release SteamOS for other devices, because they don't just want to release a generic image, they want to release something that uses the hardware to its fullest extent.

[-]

AnEagleisnotme@reddit

I suspect not, It's probably just that they don't feel like they can offer a good experience on nvidia, seeing as they use wayland only

[-]

WileEPyote@reddit

Those are my main flags for Gentoo too.

[-]

jjudeb@reddit

snap is a non-starter for many environments because it can only support user directories as /home/. The last time I tried to use snap was an abject failure, because our corporate home directories are //.

One of the first things I did when installing 24.04 was to replace the snap for firefox.

As far as I know, there is still no workaround for this "feature".

(Yes, yes, I understand the desire to sandbox applications into /home/, but the template for allowable user home directory names should be configurable. Isn't there a HOMEDIRS hook in apparmor already? Forcing /home for snap is a bug.)

[-]

epSos-DE@reddit

Appimage was popular, flatpack is getting popular

[-]

ahferroin7@reddit

As both a user and a packaging engineer, I strongly prefer Flatpak over the others.

Compared to Snap:

Flatpak has significantly less runtime overhead. No daemons you need to run, much lighter-weight (but still largely comprehensive) sandboxing, less duplication of data, etc.
Flatpak has a much easier to understand permissions model. This is really important because it means developers are more likely to get their permissions right, and because it makes it easier for users to understand what an app is actually asking for.
Flatpak does not depend on systemd. This means it will work just fine on Alpine, or Artix, or Void, or Devuan as long as the other criteria are met.

Compared to AppImage:

Flatpak provides actual sandboxing as a core part of the format. It’s possible to sandbox an AppImage, but you’re stuck using external tooling and the app itself has to support running in a sandboxed environment.
Flatpak is at the same time both more space efficient and more decoupled from the host system. Flatpak itself provides core runtime dependencies, and it shares them across the individual applications that need them, compared to AppImage needing to either bundle everything in each AppImage or rely on the host for libraries that may not be fully compatible.
Flatpak provides centralized update management as part of it’s core tooling without needing anything from the applications it’s packaging. With AppImage, update support is dependent on the person who produced the AppImage setting it up to support updates, and possibly on the application choosing to handle things.

Now, this is not to say that I would prefer Flatpak over system-native packages in most cases. But sometimes there are things I can’t get native packages for (for example, I use Tenacity with some regularity, and it’s still not packaged by most Linux distros), or cases where I really don’t want to deal with the overhead involved in using native packages (for example, Steam is a pain in the arse to get working reliably on many distros, but the Flatpak just works in a majority of cases), and in those cases I use Flatpak in preference to the other options.

[-]

deadlyrepost@reddit

I'll piggy back on this because it's pretty comprehensive. I tend to use each where they are strongest:

AppImage is good for "one-shot" installs, like a single app or CLI tool which is self contained and which I won't have to update. Maybe I'm putting it on a server where I don't have root, or maybe just as a "temporary" tool.
Snap is (currently) better for services. Basically a nicer, more packaged, docker.
Flatpak for "apps", things with a GUI.
Native for OS-specific stuff or CLI apps.

[-]

Hithaeglir@reddit

CLI tool which is self contained

To be fair, if you only need "one-shot" CLI tool, there is nothing better than just using some OCI runner like Docker or Podman. I wonder why OP did not even consider them at all. Flatpak is mostly based on OCI standard as well. That is why it is usually more efficient, because there is no emulation. Apps run on the same kernel still.

[-]

therealpxc@reddit

To be fair, if you only need "one-shot" CLI tool, there is nothing better than just using some OCI runner like Docker or Podman

No way! nix run and nix shell are definitely better than Docker or Podman for such a thing. The invocations are simpler and shorter, you don't have to think about mounting specific directories as a volume into the container, the overhead is lower, the dependencies of the tool can be pulled from a common base with your installed tools, and the caching is per-package (more fine-grained than OCI layers). Those things also work on other Unix operating systems, like macOS and FreeBSD, without virtualization.

[-]

Hithaeglir@reddit

No way! nix run and nix shell are definitely better than Docker or Podman for such a thing.

They don’t provide any sort of isolation. Otherwise I would agree.

[-]

therealpxc@reddit

Isolation is generally not desirable for command line tools. Why do you think you need it for that use case? Regardless, you can use Nix in conjunction with something like firejail or bubblewrap if you actually do need that.

[-]

deadlyrepost@reddit

Podman / Docker is honestly more of a faff for CLI than appimage. At a minimum you'd need a mini-shell script to launch the app correctly, and I've had a bunch of environment issues. It's fine to be clear, I've used it when it's the "done" thing, but appimage is usually better for me (for that use case).

[-]

Rare-Page4407@reddit

so do they for all the other formats too.

[-]

slide2k@reddit

I have containerized my entire cli tool chain. Even aliased the one liner to start it. Such a game changer!

[-]

UNF0RM4TT3D@reddit

Canonical should just focus snaps on the server space, leaving other use cases to the better alternatives.

[-]

devoopsies@reddit

I would prefer it if they didn't, thank you

[-]

zephyroths@reddit

is snap still so "locked in" to Ubuntu? last time I heard about snap needing something that's only ubuntu has the patches and setup by default

[-]

linmanfu@reddit

From a user point of view, Flatpaks just seem to update in the background like apt apps. The Firefox snap nags me to close it, apparently because it can only automatically update at certain pre-set times. So that's another disadvantage.

Reading other comments here it also says that Flatpak apps should use the KDE file picker on Kubuntu, rather than the idiotic GTK one, but I'm not certain about that.

[-]

ThingJazzlike2681@reddit

From a user point of view, Flatpaks just seem to update in the background like apt apps. The Firefox snap nags me to close it, apparently because it can only automatically update at certain pre-set times. So that's another disadvantage.

I actually miss that a bit after moving to the deb version. The constant popups were annoying, but not as annoying as Firefox breaking because the running version no longer matches the one on disk. Back in the day I sometimes had to work around this for days or weeks, figuring out which functions of the browser I could still use and which ones I couldn't. It was way more annoying than the occasional popup.

[-]

linmanfu@reddit

Do people leave their browser running that long?! I always close it at least every couple of days. I guess that makes the Snap approach a bit more comprehensible.

[-]

ThingJazzlike2681@reddit

I could certainly go a month or two, depending on whether I have to restart the computer for something else.

I have a hundred (or two, haven't counted them in a long time) tabs open across 7-10 windows in different workspaces, so starting the browser can take a long time. Often a couple of private windows as well, for stuff I think I won't want to keep open, but sometimes end up using for longer until I have time to finish what I was doing/decide which ones I want to move to a more permanent window and which one). And if I couldn't get around to doing that immediately, I'd definitely have to run on a broken browser until then. (And the broken browser made it harder to clean up the private windows, because you often couldn't open new tabs without trickery).

Now I pretty much just avoid the upgrade until i have time to do all this (or I just happen to have things in order and can restart the browser easily), which is also annoying.

[-]

TiZ_EX1@reddit

it also says that Flatpak apps should use the KDE file picker on Kubuntu

As long as the app in question uses the file chooser portal, that is indeed the case, but there are still a few that don't.

[-]

Indolent_Bard@reddit

How are flat-pack applications not native? There's no such thing as native Linux software otherwise. There's just software that's native to your distro of choice.

[-]

Imaginary-Problem914@reddit

"native" is a pretty vague term these days, but IMO as long as it isn't a web app and it isn't running in an emulator/wine, it counts as native. But you could probably argue that even electron apps could be considered just as native as a python program.

[-]

Indolent_Bard@reddit

I know nothing about Python, but I know enough about Electron to know that's probably going to step on quite a few toes. But I've heard enough references to Python that I can kind of understand that you just made a frighteningly good point.

[-]

C0rn3j@reddit

You forgot to mention that snap has a proprietary backend and thus serves as a lock-in to Canonical.

[-]

ahferroin7@reddit

No, it was intentional that I did not say that, because it’s not a technical limitation or design aspect inherent to the package format.

The protocols and other aspects required to have a custom Snap backend are all open (not always well documented, but there’s no way to hide the way they work on the client side), so it’s entirely possible to have a fully independent FOSS backend implementation. The fact that one does not exist yet is just because nobody cares enough about the format to do so, not because the format is somehow inherently restricted to only use Canonical’s proprietary backend.

[-]

ct_the_man_doll@reddit

The protocols and other aspects required to have a custom Snap backend are all open (not always well documented, but there’s no way to hide the way they work on the client side), so it’s entirely possible to have a fully independent FOSS backend implementation.

Don't you have to make a custom build of snap to support connecting to a third-party snap server? That alone turns me off from snap.

[-]

Sukrim@reddit

You can just change your local DNS resolver I guess.

[-]

ct_the_man_doll@reddit

I'm sorry, but I shouldn't have to resort to doing DNS stuff (or any other workaround) to connect to a third-party snap server.

[-]

Sukrim@reddit

The question was if you had to do a custom build or not. You either need to do a workaround like that or patch the code and recompile, whatever you're more comfortable with.

[-]

Advanced_Parfait2947@reddit

thank you for reminding people it's entirely possible to make a foss backend for snaps! People just don't care because the vast majority of distributions that are immutable will use flatpak so this is where developers are gonna put their effort.

[-]

lproven@reddit

Because that is not true.

[-]

bobpaul@reddit

Maybe this depends on how you define "lock-in to Canonical". The only snap repository (snapcraft) is run by Canonical. One can still manually download and sideload snaps, but one can't simply configure the snap daemon to look at a self-hosted repo, nor has anyone made an OSS project to replace snapcraft.

The uncontrolled, automatic updates and inability to run a self-hosted snap repository makes snap non-viable for many enterprise users.

[-]

lproven@reddit

I've talked to Canonical about this, as well as people running their own in-house snap stores to distribute snaps to their own machines.

I wrote it up, here:

https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/

Sure, the Canonical snap store is closed source, and frankly, they aren't doing a great job... and I've written about that, too.

https://www.theregister.com/2024/03/28/canonical_snap_store_scams/

But anyone can run their own. There's no lock in. All documented, all open.

15 odd years ago lots of people bitched that Launchpad was closed source. So they went to lots of effort and open sourced it. Nobody cared.

Just as most FOSS projects I've worked with in the last decade use Github (proprietary), JIRA (proprietary), Confluence (proprietary), Slack (proprietary), etc.

The snap store is closed. Don't like that? Run your own. Canonical will help.

[-]

torvatrollid@reddit

Everything you list as a plus vs appimage are reasons why I prefer appimage.

Flatpak's sandbox is a huge pain and will often put in restrictions that prevent applications from working properly. You often end up needing to move around files to different folders than where you want them just so you can open them in your flatpak app, or you'll need to use tools like flatseal. You can also completely break your flatpaks with flatseal if you're not careful. Most Linux distro's are not designed around apps being sandboxed, so unsandboxed appimages behave just like normal software for your distro.
Flatpak's space efficiency is just a straight up lie in practice. Flatpak's runtimes take up a lot of disk space. Just installing a few flatpaks will quickly eat up 20GB or more of diskspace with these massive bloated runtimes. Most apps do not need such massive runtimes and appimages only need to contain the dependencies they actually need.
I've had flatpaks randomly break on me due to flatpak's automatic updates. It was especially bad one time when the flatpak that broke was my password manager. I had to use the appimage to get access to my passwords again. Appimages being just a file without centralized update management makes it easy for me to safely handle updates and it makes it stupid easy to rollback to older versions if something breaks. I just keep the old appimage file until I'm certain the new one works.

[-]

newsflashjackass@reddit

Everything you list as a plus vs appimage are reasons why I prefer appimage.

Flatpak requires installing/running something extra (flatpak itself) beforehand; appimage does not.

That alone is enough for me to decisively prefer appimage.

[-]

sakuramiku3939@reddit

On some distros, appimages do not work out of the box; you have to install external dependencies. On nixos, appimages barely work even with those.

[-]

newsflashjackass@reddit

On some distros, appimages do not work out of the box; you have to install external dependencies. On nixos, appimages barely work even with those.

True; for certain values of "some".

Though one must shop around to find a distro on which appimages do not work out of the box.

"AppImages require a Linux technology called Filesystem in Userspace (or short FUSE). The majority of systems ships with a working FUSE setup."

https://docs.appimage.org/user-guide/troubleshooting/fuse.html

If you are using nixos presumably you know what you signed up for.

I never before heard someone complain about software barely working. "Barely broken" is a more typical plight.

[-]

ppp7032@reddit

appimages havent worked out of the box on ubuntu for a long time now, ever since fuse2 stopped being shipped by default. what distros DO they work out if the box on because all i can think of is debian (+derivatives -ubuntu derivatives)

[-]

newsflashjackass@reddit

A: "On some distros, appimages do not work out of the box"

Me: Links a source saying appimages work out of the box on a majority of systems.

C: "Name every linux distribution that ships with a working FUSE setup."

Since they made the initial claim (and so bear the philosophical burden of proof ask grandparent commenter to enumerate the distros that it doesn't work on. Then subtract their answer from the set of all existing distros.

Also I'm not saying it's necessarily malicious but both of these are true facts:

To the extent that they want people to use Snap, Canonical stands to benefit from breaking ^superior alternatives to it.
Appimages worked in Ubuntu until Canonical broke them.

[-]

ppp7032@reddit

this isnt a contest on who can name the most distros. distros are only as important as the number of users they have. appimages not working on ubuntu since 22.04 out of the box is a big deal. like it or not, ubuntu is the most popular linux distro and as such is most important. you can make your claim that (let's say) 100 distros support it but if the largest distro is not in that list then who cares?

fuse2 was deprecated in ubuntu because it is ancient and has been unmaintained for a very long time. the main appimage developer has been sitting on his arse for years now debating whether there's even a reason to update to use fuse3 meanwhile the world has moved on.

[-]

newsflashjackass@reddit

what distros DO they work out if the box on

[-]

ppp7032@reddit

"gotchas" are not helping your point, ben shapiro.

[-]

newsflashjackass@reddit

Just wanted to be sure you understood me.

[-]

piexil@reddit

install libfuse2 and fuse 2 apps will work on fuse 3 just fine

[-]

Danny_el_619@reddit

Nixos have pretty much everything you need in nix unstable repos. You'll hardly need AppImages there.

[-]

jdigi78@reddit

AppImages need FUSE in the same way. Plenty of distros include Flatpak in the same way they include FUSE.

[-]

RootHouston@reddit

Depends on your distro. It's built-in to a lot of distros.

[-]

HatBoxUnworn@reddit

I have 34 flatpaks installed. They take up 6.46 gb

[-]

Helmic@reddit

Flatpak managers have unattended updates set as an option, with tools to roll back updates. You can easily turn off updates if you wish, blaming the format for the sorts of breakages that just happen with updates normally is silly.

[-]

shroddy@reddit

I think the sandbox is a big plus (it is nowhere near where it should be yet, but it is getting there). We really should stop allowing each and every program we want to run full access to our home directory.

(And don't even start with "if you don't trust a program, don't run it...")

[-]

small_tit_girls_pmMe@reddit

Just installing a few flatpaks will quickly eat up 20GB

Uhhh... No. That's absolute bullshit.

[-]

MemoryNotSignificant@reddit

The problem with flatpak is the fact that it is community maintaind. So many packages are out of date (just look at sublime text for example). As a result, I have no idea whether I should trust this flatpak package or just go to the developer's website and download the current appimage or use apt repo. Unless there is widescale adoption, it will be a 2nd class citizen.

[-]

gplusplus314@reddit

Oh boy, you said it better than I ever could.

[-]

Majestic-Contract-42@reddit

Flathub.

Wanna just install and it's automatically keeps itself up to latest stable release. I don't want to manage that rubbish, it's a computer, it should handle all that itself.

[-]

YamiYukiSenpai@reddit

I like both Snaps and Flatpaks, & I make sure both are installed on any of my PCs. I’ve started relying less and less on PPAs unless it couldn’t be helped.

If there’s one thing I like about Flatpaks, it’s that it doesn’t care about symlinks. I play around with VMs with GPU passthrough, and my Flatpaks are stored directly in my PC, and the VMs are mounting it via NFS. So all VMs have the same Flatpaks. It helps too with one of my old MacBooks that has multi-boot. I put all of the Flatpaks in a shared Btrfs partition in a separate subvolume, and symlinked Flatpaks to it.

On my servers, I use Nextcloud Snap & my Docker is also running as a Snap, and both are working well. There aren’t any PPAs on it.

[-]

Kahless_2K@reddit

I prefer crap be properly maintained in the first party repos.

[-]

GenZ4TheWin2000@reddit

I prefer RPM or DEB. None of this sandboxed app shit. I wish it would just all go away

[-]

WasdHent@reddit

Typically I prefer system packages most of the time, flatpak only if the use case calls for it. For example, if you’re on mint flatpaks would be more up to date than the system packages. Which will either be good or bad depending on the program. Plus flatpaks have sandboxing parameters, and may or may not require additional permissions on top of the defaults. It just depends.

[-]

julianoniem@reddit

If app is missing in official repo or that native repo only has older version of app then I avoid external repo's. 1st alternative choice is flatpak with help of Flatseal for permissions. 2nd choice is appimage with help of appimage manager Gear Level. I boycot snap because of where it came from, life with Linux improved far too much after abandoning overrated ubuntu for "pure" debian, opensuse and fedora.

[-]

Crazy_Energy3735@reddit

Sorry I fell in love with apt and apt-get. So simple

[-]

myRedditX3@reddit

Not a technical argument, but Snap constantly annoys me with its limitations around NFS /home (supposedly fixed with a workaround now, but the implementation is tedious), which is enough to cause us to avoid it whenever possible. Flatpack has been a good alternative, but we are end users of it, not deploying with it.

[-]

Littux@reddit

Distro package > AUR > Manually compiling from source > Flatpak > AppImage > Not using the program > Snap

The only Flatpaks that I've installed are Citra and 3D pinball space cadet

[-]

TuxedoTechno@reddit

As a user, AppImages are great when you want to have a specific release locked in, unchanging. They are also stupid simple to manage. Flatpak is fine. As a KDE user, Flatpaks via flathub come up in Discover and ive had no issues with installing or updating them. They launch slower than natively installed apps, but otherwise the performance is equivalent.

I don't use Ubuntu, so I don't have experience with Snaps. I'm sure they're fine from a technology perspective, but from a community/political standpoint they stink of Canonical's hubris. I don't see how they are valuable at all to anyone outside of Ubuntu.

[-]

Slaykomimi@reddit

it feels like any of these is always incomplete or broken and not working with external files AT ALL so I prefer compiling it myself or installing it from a repo

[-]

AlsGeekLab@reddit

.deb packages / apt. Because the packages actually work 😂

[-]

TheGreatButz@reddit

I avoid all of them and prefer apt on my system.

[-]

eriomys@reddit

Appimage because it allows moving applications to a secondary 2 tb drive, saving space, as I only have a 128 gb ssd laptop

[-]

numblock699@reddit

None of them. They are like gluing broken shit together.

[-]

fellipec@reddit

In order of my preference

Native Packages from the distro > Native Pakages from dev repos > Flatpak > Appimage > Binary from dev > Compile from source > snaps

[-]

Indolent_Bard@reddit

Can you elaborate like some of the others in this post have?

[-]

fellipec@reddit

Native packages are better IMHO because there is no conteinerization, no overhead, no nothing, they run and work fine since the 90s and to me its good enough.

When what I want is not in the repos or the dev don't distribute a .deb, Flatpaks can be fine. Sure they waste a lot of space but even my small PC have a 120G drive from which half of it is empty, so isn't a big deal. Also they integrate into the system mostly perfectly (but sometimes I've got problems, with programs not being able to save files even with proper permissions in flatseal and also some theme problems).

Appimages always worked fine to me, but to make them easier to use and integrate in the system, I use flatpak app called Gearlever. Having to either manually puting them on the menu or having to rely on another "manager" to make it automatically is the downside of the Appimages. But on the other hand they are nice to have on USB drives, just click and run.

Sometimes the software is distributed as a binary from the developers, like ollama. Instead of running their script, as they have "manual" instructions I use that and works fine. Don't need to "install" anything, just copy a file in the /opt and set a few environment variables in the .zshrc and done.

A couple of times I compiled from sources. Not a complicated thing but a hassle to install all the dependencies needed to compile stuff. But works well and I can't imagine a more "pure" way to get some piece of software. Is just more work that usually I don't want to have.

And snaps, I just don't want to be tied to a company. I prefer community mainteined things than company owned ones when possible. Also I'm not a big fan of how Canonical try to shoehorn snaps on Ubuntu, feels like how Microsoft try to make you use Edge.

[-]

Indolent_Bard@reddit

I don't have a burden for flat pack. I have a burden to escape this hellscape of software availability being at the mercy of volunteers. See, I think stupid, And I recently read a post where someone brought up a hypothetical where they spent all that time on the distro itself rather than maintaining the repos. If I wanted to release a piece of software, the idea that your ability to install it easily is entirely dependent on volunteers appalls me. This whole need for a package to be in the repository's thing is just abhorrent. There's also no way in hell commercial software will be distributed like that, so if we want companies to port their software to Linux, we better start embracing flat pak.

I understand the format isn't perfect yet. There's some issues with permission access, and the whole model of creating software that asks you permission before it does something is kind of uncharted territory in the desktop. I know it breaks compatibility with Blackmagic products in OBS because it can't access the files and there's literally no way to download them. I couldn't change my wine prefix for Genshin impact using heroic flat pack (had some issue where it thought there was zero kilobytes of space and eventually, I couldn't even reinstall the game. Same with my bottles flatpak after trying to install it that way. So I had to download the native package of bottles and it worked.)

[-]

Anamolica@reddit

Literally same!

[-]

apathyzeal@reddit

This. Always prefer native distro packages over these.

And compile before ever using snaps.

[-]

Indolent_Bard@reddit

So releasing software that only works on one distro is best?

[-]

apathyzeal@reddit

No, that's a big leap of faith to draw that conclusion from what I said.

[-]

Indolent_Bard@reddit

Well, why is software packaged by volunteers better than releasing it universally? Always wondered why some prefer that.

[-]

fellipec@reddit

The only snap I use is the certbot from letsencrypt on my webserver.

And is is because I set it up some time ago before I know better.

[-]

ipaqmaster@reddit

I'm shocked to read certbot isn't provided by your distro's first party repo.

[-]

fellipec@reddit

Like I said, I didn't knew better at that time (snaps were a new thing to me), just followed the instructions (which where snap). Now I regret it, but is working for a couple of years now and you know what people say, if is not broken, don't fix.

Of course next time I need to reinstall or if it stop working I'll get rid of this snap bs

[-]

ipaqmaster@reddit

If it's using the host's /etc/letsencrypt path you could just install it and pretend it never happened. Otherwise if snap is storing certbot's files elsewhere I imagine it would be more annoying to rip them out.

But definitely worth checking /etc/letsencrypt to see if its just using the global path already. If that's the case switching to a package would be simple.

[-]

fellipec@reddit

Yes, I'm sure it's using the /etc/letsencrypt path.

I'll take a look on this thank you for the tip!

[-]

Indolent_Bard@reddit

Why? I'm curious.

[-]

Ezmiller_2@reddit

Yeah I put Ubuntu on my Ivy Bridge laptop and I can notice a difference with install times for Ubuntu vs Debian. Ok, so Ubuntu is on an Msata drive that runs at Sata2 speeds. But normal things I don’t notice any difference. Load times for games and apps are about the same.

[-]

Indolent_Bard@reddit

Didn't Linus himself describe native packages as a giant pain in the ass?

[-]

fellipec@reddit

Of course, he uses Fedora 🤣

[-]

Behrooz0@reddit

Native Packages from the distro > Native Pakages from dev repos > Flatpak > Appimage > Binary from dev > Compile from source > not using the app > snaps
FTFY

[-]

fellipec@reddit

Chefs' kiss

[-]

Patient_Sink@reddit

Having done packaging with flatpak, appimage and for the AUR, I very much prefer flatpak: choose a runtime that matches the dependencies you need, add any extra dependencies if they're not included in the runtime and the flatpak builder will tell you if something is missing. If it builds you know it'll build on any other system. It's a bit tricky with stuff that tries to use npm for example since the build process will normally not be able to download new stuff other than what's already included in your spec, but the packaging format is just a normal yaml or json file so it's very easy to understand.

AUR comes as a close second place, since it's also a very simple packaging format, very similar to the flatpak format, but they can break since the underlying distro is rolling, so I need to keep on top of package changes when maintaining the package.

Appimage is like a worse combination of both of them in my opinion, since changes in the host system might cause issues with the bundled stuff in the appimage, and having to keep track of the individual files to bundle (no easy way to just specify dependencies and versions, at least that I remember). There were also issues with nvidia stuff where the libraries bundled in the appimage had to match the kernel drivers for hardware acceleration to work in the game I shipped, using the standard libglvnd did not work for whatever reason, and anyone running the game with a different version of the driver from mine resulted in crashes. In the end, we only shipped hardware acceleration for intel and amd graphics, and nvidia users had to use llvmpipe. For a simple 2D game the impact is not so bad, but shipping something with more demanding graphics would've been a pain.

As a user I've pretty much settled on using everything flatpak. It works very well on my silverblue installation, and using the runtimes mean I don't have to layer stuff to my base. Anything CLI or that doesn't provide a flatpak goes into a toolbox container.

I've also started using docker/podman more for my server, super simple to keep stuff updated without risking other things breaking.

[-]

KnowZeroX@reddit

Appimage is like a worse combination of both of them in my opinion, since changes in the host system might cause issues with the bundled stuff in the appimage, and having to keep track of the individual files to bundle (no easy way to just specify dependencies and versions, at least that I remember).

You generally should be building in CI to insure host system stays consistent without being effected by any change to the host computer

[-]

Patient_Sink@reddit

Yeah sure, or just an old ubuntu LTS vm which was the previous suggestion by the appimage devs. It's still a hassle compared to the other two alternatives.

[-]

KnowZeroX@reddit

CI can be done in docker or microvm, you'd want it setup anyways for development. This way you can generate appimages not just on releases but during pull requests and etc so you don't have to waste your time compiling as each pull request would have a precompiled appimage

[-]

Patient_Sink@reddit

Or I can just use flatpak builder where I just need to write a yaml file and it'll do the rest for me, no need to set up a CI or anything else really.

[-]

NotSimSon@reddit

Flatpak: I like it, the library is very large and the packages are stable. To control the Flatpak applications, you can install Flatseal, which is very helpful.

AppImage: It works but is not great because it does not implement with user theme. I think appimagelauncher is a must have if you want to use appImages, it implements the app into your system so you can launch it from search. Unfortunately the maintainer is no longer active, but it still works even after years without updates, so I will just use it.

Snap: Havent used it much, some say its great, some hate it. The times I tried it, it worked and it has some apps that arent on other libraries (flatpak,...)

[-]

Toad_Toast@reddit

Flatpak for how good Flathub is.

[-]

Separate_Paper_1412@reddit

It's slow outside the US without a VPN.

[-]

IonianBlueWorld@reddit

I feel more comfortable with Appimage because I don't have to use root priviledges and that's quite important to me when I run something outside Debian repos.

Between flatpak and snap, my choice goes to flatpak because it is full FOSS, while the server-side of snap is proprietary; a huge disappointment from Canonical and Ubuntu.

I know that flatpak is partially "sandboxed" but since I often need to install packages as root, I remain uncomfortable and hesitant. Often, my choice is to install freely stuff within a VM but some applications work only on bare metal (e.g. music production stuff that often require a RT kernel, Jack, etc.). For those cases, I am thinking to dual boot a second "sacrificial" distro where I can do whatever I want almost risk-free. I don't like dual booting because it reminds me of the days that I was dual booting with windows about 15-20 years ago. Not the same thing of course but some problems remain (e.g. if you mess up your bootloader with one OS you mess up both).

[-]

Sarxiron@reddit

Native > Flatpak > Snap for some cli software.

I've never found a comfortable way of using appimages, not that I have looked very hard but still.

[-]

MrHighStreetRoad@reddit

Yes.

[-]

Resident-Radish-3758@reddit

Native packages where possible, flatpak for everything not available in the repos and proprietary software.

[-]

prosper_0@reddit

why is this not the top answer? Distro packages are always my preference

[-]

Sjoerd93@reddit

What about distro Flatpaks?

[-]

prosper_0@reddit

I've never seen a distro where the native package format is flatpak. I know Ubuntu hijacks the native packaging system to inject in snaps, but that's an abomination that should not be spoken of.

[-]

Imaginary-Problem914@reddit

SteamOS on the Steam Deck does this. Also Fedora Silverblue.

[-]

randylush@reddit

Yeah that is pretty whack

[-]

Sjoerd93@reddit

I was mainly reading to Fedora (not just Silverblue), which has an own Flatpak repo.

[-]

Indolent_Bard@reddit

Why? That's a pain for developers. Wouldn't it be better to release software that people actually download instead of some 3rd party packaging it?

[-]

BaseballNRockAndRoll@reddit

I use official flatpaks for "major" desktop software even when native packages are available. For example for something like LibreOffice you get the most up to date version that it is consistent across distributions.

[-]

EtyareWS@reddit

I pretty much use Flatpak as the default and Native Packages as the fallback option.

Flatpak is way saner on multiuser home environments cause every user can have it's own apps without ever requiring sudo to install a random app that only a single user wants to use. Plus, Flatpak apps all put their "trash" into predictable folders, very easy to cleanup, and because it is separate from native packages it means you can always know with certainty that removing a Flatpak will not break your system.

[-]

Patient_Sink@reddit

I kinda do wish that flatpak would still install the runtimes systemwide even when using the --user option, I don't know if deduplication works across different home dirs (or if the system is using systemd-homed I don't think it can work properly).

[-]

EtyareWS@reddit

Yeah, this is something I've wondered about but after some consideration I think it would kinda suck...?

If you are installing runtimes systemwide then you kinda need sudo, otherwise this is going to be weird. Imagine being the "Admin" and finding out there's a ton of runtimes you never agreed to, and that you can't just yank without care.

And then, --user installed apps are installed to the user's /home. You can just yank your home from one computer and put in another and all the Flatpak apps will be there (theoretically, haven't needed to try this yet). If you use systemd-homed it should be even easier. If the runtimes are systemwide then you need to fix that when changing systems.

Furthermore, what would happen if each /home is encrypted?

[-]

Patient_Sink@reddit

Yeah, it's not without drawbacks. And yeah, /home portability is a good point, especially for apps from other repos than flathub. Would it be sane for a new host to automatically download new runtimes to the system, especially from repos not already configured? That'd be weird.

The current solution is probably for the better, but it'd be nice to have the best of both worlds with user installations and deduplication for the bigger stuff. :)

[-]

EtyareWS@reddit

You could use BTRFs to use CoW on the entire disk, and it would prevent wasted space, but I THINK this stops working if you encrypt each home individually? Maybe not, honestly, not sure

[-]

Patient_Sink@reddit

I think it also doesn't work over subvolumes, so with homed using a separate subvol for each user would also not work even running it on a timer/cron. I'm not completely sure though.

[-]

lKrauzer@reddit

Flatpak, it is simpler than the other two and is more consistent through all distros

[-]

CounterUpper9834@reddit

Every appimage I've seen are already in the AUR and since snap is only for ubuntu, my only option here is flatpak.

[-]

alwyn@reddit

Arch packages, why would I have all that additional layers of crap when it works.

[-]

Due-Vegetable-1880@reddit

Native, unless not available, in which case I use Flatpaks or AppImages. No Snaps

[-]

JerryHutch@reddit

Came here to say this. Will use Windows 3.11 before snaps.

[-]

ipaqmaster@reddit

2024 toolchain for Windows 3.11 coming up

[-]

dimspace@reddit

Same, in order..

Native.
Appimage or flatpak from dev.
Flathub.
Build from source

Absolute last resort until I find an alternative

Snap.

[-]

omniuni@reddit

Actual native packages.

[-]

Indolent_Bard@reddit

Why? For some reason, none of you ever give a reason. I think that bothers me way more than the actual opinion. Because I really don't care that you prefer native, I just care about the lack of an explanation.

[-]

omniuni@reddit

Speed, size (they're much much smaller), and more predictable.

[-]

Postcard2923@reddit

Native packages are not universal, so you didn't really answer their question.

[-]

newsflashjackass@reddit

you didn't really answer their question. Like someone asking which beer you prefer, and you answered tequila.

My friend's mom's laptop required replacement. I was explaining to her how the iron triangle represented a compromise. "Fast, cheap, and good: pick any two."

Without a moment's thought, she replied: "I pick fast and good!" Which I found funny because she was spending money her husband earned.

[-]

ijzerwater@reddit

to put it in your framework. 'I don't drink beer, I drink tequila. If you don't have that, let me just be without'.

[-]

Advanced_Parfait2947@reddit

there's always that one linux dude that'S like "achtually i prefer native apps becaushe..."

[-]

GrouchyVillager@reddit

This is not about native or not.

[-]

Advanced_Parfait2947@reddit

op asked to chose between 3 formats, leaving out native apps for a specific reason. if all that dude could say is "native" then why leave a comment at all? you're not answering OP's question

[-]

CloneCl0wn@reddit

Aye, same vibes as vegan coming to bbq.

[-]

nadmaximus@reddit

αcτµαlly pδrταblε εxεcµταblε

[-]

paholg@reddit

Nix!

[-]

IamfromSpace@reddit

That’s the one!

[-]

Linux4ever_Leo@reddit

None of the above. I prefer to install packages from my distro's repositories.

[-]

erwan@reddit

What you're saying is that you want small app developers (those too small to be on the radar of the distribution) to provide packages for your distro - alongside with every single distro they want to support. So at least 3, rpm, deb, and pacman, and you multiply that by the versions of those distributions.

To which app developers say "fuck it", Linux is fragmented, I'll provide a Windows binary and those pesky Linux users can build from source if they want.

[-]

Monsieur_Moneybags@reddit

Those small app developers don't have to provide packages for every distro. For example, I've written several small apps and created RPM packages for Fedora only, since that's the distro I use (and the only one I care about). But since I made the source code available under the GPL, other distros—to my pleasant surprise—created their own packages from my code.

That's great, and how it should be. That's the division of labor in the Linux world that you don't seem to understand: distro-specific packages are the responsibility of the distro, providing the (upstream) code is the responsibility of the app developers. If a distro thinks a particular app is worthwhile, then they'll create a package for it. The distro packagers know best how to fit your app into their distro. Frankly, packages created by the app developers often get things quite wrong, which is why I almost always avoid them (except my own, of course :) ).

I have never needed a Flatpak, Snap or AppImage. Almost everything I've needed is provided by the Fedora repos. A few FOSS apps I use have no Fedora packages, but building them from source was no problem. The only real exceptions to all this are a handful of proprietary apps (e.g. MATLAB) that had their own installation method, but they're still "regular" apps, not Flatpaks or similar.

[-]

Indolent_Bard@reddit

Wouldn't it be better if all that labor division could be saved by just uploading a singular package?

That's actually really cool that several distros ended up adding your software. But you can see why from a developer perspective this is kind of silly, right? Even Linus himself called your preferred method a giant pain in the ass.

[-]

Linux4ever_Leo@reddit

I understand what you're saying in principle and I agree with you. Unfortunately none of these portable formats are perfect and they all have certain problems and annoyances, unlike Windows or macOS binaries.

[-]

MetaTrombonist@reddit

Perfection is the enemy of good.

[-]

erwan@reddit

Windows and macOS binaries aren't perfect either. The way a Windows installer puts files everywhere to the point you can never be sure it's cleanly uninstalled is problematic.

I personally believe containered apps are overall a progress over the old way of installing desktop apps, because they're self-contained and sandboxed. I think we're going to see more and more distributions like SteamOS or Fedora Sliverblue that make a clear separation between system and user apps and use flatpak as the default for user apps.

Yes they do have their annoyances at times, but (1) things are getting better and (2) it's worth it for the benefits they provide.

[-]

SileNce5k@reddit

Tbh, I'd much rather build from source than use any of the 3 choices in the title if it's a simple process.

[-]

Indolent_Bard@reddit

What is the advantage, because it means nobody is actually using your software unless it's been packaged by the distro, and Linus himself called package management on Linux a giant pain in the ass. Where is the advantage? I'm genuinely curious.

[-]

vanwaldi@reddit

Sure, BUT let me give you my example of the convenience of flatpaks.

I am using Fedora 41 pre-release right now because it comes with kernel 6.11 which fixes issues in my laptop, also to get the GNOME 47 improvements faster.

However, Fedora 41 comes with Python 3.13-rc, and QGIS 3.38.2 from Fedora repositories is linked against 3.13-rc, which breaks plenty of QGIS plugins for being a experimental version. Also, some libraries like pandas or scikit-learn are unavailable as binaries for 3.13-rc and require compilation, but I couldn't compile them as it kept throwing errors.

By installing QGIS from Flathub, I can have the latest QGIS against a older Python version with all the plugins running, and I can even enter the flatpak sandbox and pip install the remaining libraries inside there. Plus, I don't need to populate my native system with a bunch of qt dependencies.

So with Flatpak I can have my cake and eat it to.

I wish Flatpak had channel support for stable/beta releases of software like Snap does.

[-]

jeteodor@reddit

Might i ask how did you upgrade to 41? Did you do a reinstall or is there a command to upgrade

[-]

LvS@reddit

You can use dnf system-upgrade to upgrade to prereleases (or rawhide).

I've even successfully used it to downgrade distros back when the prerelease was unstable, but this is very much unsupported.

[-]

vanwaldi@reddit

I did a fresh install, grabbing the most recent daily ISO of Fedora 41 that passed the openQA checks.

The Fedora 41 beta is coming in just a couple weeks though, and the beta ISO will be present in Fedora's homepage.

[-]

Linux4ever_Leo@reddit

Flatpaks may be convenient but they're not without their problems. For example, I use a flatpak for Betterbird (an enhanced fork of Thunderbird.) It can't see my printers so I have to save e-mails to PDF and print them outside of the app and I had to jump through hoops to get it to see my full file system of folders.

[-]

Patient_Sink@reddit

If you enabled host or host-os permissions for the flatpak, that might actually cause issues. IIRC the firefox flatpak had some issues when users did that.

The only issue with printing I saw on the betterbird flatpak repo was this: https://github.com/flathub/eu.betterbird.Betterbird/issues/110 but that should've been fixed a year ago.

[-]

Patient_Sink@reddit

I wish Flatpak had channel support for stable/beta releases of software like Snap does.

You probably already know this, but you could switch between the flathub beta repo and the normal one by specifying the repo during install I think. But I think it'd be nice to also be able to roll back installations easier, rather than having to find the specific commit.

[-]

geolaw@reddit

I prefer to avoid them all like the plague and use the distro package manager

[-]

pycvalade@reddit

I’d rather apt install package over anything else really. If all distros would agree to a format then I’d vote for Flatpak

[-]

Netizen_Kain@reddit

I greatly prefer appimage cause you can just download, make executable, and run it and it will work properly and integrate pretty well with the system. No broken themes, no screwing around with Flatseal, just DL and run.

[-]

secureblueadmin@reddit

Appimages unfortunately depend on the unmaintained fuse2, and also encourage the security anti-pattern of downloading and executing executables from the browser.

[-]

MorningCareful@reddit

Native first, unless it doesn't have the features I want. Then appimage for things that aren't necessarily needed on the latest version (emulators, some apps that aren't security-critical) then flatpak for anything I need the latest version of that is not in the repos or doesn't provide the features I want as a native package.

[-]

dtfinch@reddit

As a one-time thing, AppImage is pretty convenient. Just run it like an executable.

There was an abandonware app that I wanted to keep using. Its native package was dropped from my distro, and its source would no longer compile with the library versions available. But it had an AppImage and it just worked without having to install anything else.

[-]

SalamiMan-@reddit

Flatpaks are nice but people are sleeping on nix packages and their universal package manager. Was really nice to use on Debian so I didn’t have to have tons of different repos or seperate package managers

[-]

erwan@reddit

To everyone saying "just use native packages of your distribution", check this:

https://www.youtube.com/watch?v=Pzl1B7nB9Kc

This is why we need univeral packages. The video is from 2014 and now we're in a much better position, thanks to flatpak in particular.

[-]

79215185-1feb-44c6@reddit

Have you actually ever tried to publish a flatpak to flathub? Their review process is insane.

[-]

LuisBelloR@reddit

We need? Talk by yourself.

[-]

AdPale1811@reddit

"I use arch", hahaha next.

[-]

79215185-1feb-44c6@reddit

Every single person saying flatpak distribution is easy is huffing something. Probably one of the most backwards / insane processes I've ever tried to get myself involved in. Your flatpak build steps cannot reach out to the internet to grab dependencies and god forbid you want to distribute a python-based qt application.

[-]

kido5217@reddit

None.

[-]

aparaatti@reddit

hete is my analysis: I don’t

[-]

Danny_el_619@reddit

I'd go with AppImage without a second thought.

Reason, it us simple. You download it and it is ready to use. No worries about dependencies. No linked to stuff in the system. Can have a couple in a usb as portable programs and AppImage Launcher integrate them nice with the desktop environment. Automatic updates? Not something that worries me much. I don't need to update the thing if it is not broken.

Flatpak is fine but I have two major issues with it. You need to use an absurdly long command to run stuff from the command line. I don't think that is great. The other is the sandboxing. Not an issue within itself until something that you want to have working doesn't e.g. native messaging host in a browser. For everything else (mainly gui programs) it's fine but I'd probably go with AppImage it is also available.

I have no opinions about snaps because I don't use Ubuntu and nothing else use them, so I have no experience with them.

[-]

Ok_Manufacturer_8213@reddit

I really like Flatpak. It has most applications, is on most distros I use out of the box in the software center and the applications are fast and easy to change their access rights. Not sure about the developer/packager site of things but I'll very soon try to package a gui software I'm creating so I guess I'll find out

[-]

TuxRuffian@reddit

Security --> Last I checked Flatpak was using BubbleWrap which is solid, but the defaults can break things from time to time. AppImage uses a BYO security model. This can be bad when users don’t configure anything, but i always use it with FireJail, which allows for some more fine-tuned security settings that can be highly configured via a profile. My only complaint about its’ security is that since AppImages are statically linked, there may be vulnerabilities in libraries that aren't addressed until the next image update.

Updates --> Flatpak > AppImage: It’s not that AppImage is hard to update, just that you may not know that your running outdated software depending on the image.

I’m not a fan of Snap. If I want to run OCI containers, I’ll use Docker or Podman.

[-]

FlimsyTree6474@reddit

I just call my apt boy.

[-]

unknown1234_5@reddit

I like flatpak because I find it easier to use than app image and it has more apps than snap.

[-]

petrenkdm@reddit

If there's not .deb available, I go with flatpaks

[-]

burimo@reddit

Pacman. Because you know... I use arch... Btw

[-]

d4rti@reddit

Native packages. Snaps just caused brokenness for me.

[-]

eshanatnite@reddit

Same but with Flatpak

[-]

d4rti@reddit

I don't see what was broken with native packages.

[-]

Eggroley@reddit

Definitely Flatpak. Flatpaks could definitely use some improvements but I do somewhat prefer them over native packages in a way.

After that, AppImages. Portability is nice but I wish data stayed in the AppImage file. I'd prefer it not create various folders around my system. Once I remove an AppImage, everything with it should be removed as well.

I've never used Snaps so I can't really give an opinion on them.

[-]

TheSodesa@reddit

From a normal user point of view, snaps are very similar to flatpaks, apart from certain annoyances like update notifications on the snap side of things. But what is really annoying about snaps is that each app is mounted as a "device" of its own, so the output of CLI tools that list devices gets very cluttered very quickly.

[-]

MrMeatballGuy@reddit

to me Appimage is more of a "click-to-run" format than something i'd want to actually use for most of the time, an example of what i mean would be Toolbox by Jetbrains which is basically just a launcher that makes it easy to install their other tools.

my favorite is flatpak, the reason is that i hate certain apt packages will default to snap now on ubuntu and the snap store isn't open source. i'm sure snap works fine now even though it had a reputation of being slow in the past, but it just feels anti open source and forced upon even technical users which rubs me the wrong way.

flatpak is also just easy to use most of the time, sometimes i have needed to mess with permissions but nothing too bad. it is also very clear that when i install something from apt i will not get a flatpak, which is how it should be imo. there are benefits and downsides to using a sandboxed program and as a user i should be able to install from the source i want to with no trickery.

[-]

metux-its@reddit

None at all.

[-]

ParrotRunner586@reddit

Flatpak for the obvious reasons, though I see a future where we use snap more. The sandboxing is probably the most attractive reason.

[-]

Fit-Key-8352@reddit

Yes

[-]

Alarming_Ad_9922@reddit

What the f*ck is difficult to run commands like ./configure ; make ; make install ??

[-]

Alarming_Ad_9922@reddit

Native packages or compiling from source to own target. Yep i am old - but it works ;)

[-]

ricperry1@reddit

Flatpak since I can use gnome-software to install them.

[-]

OptimalAnywhere6282@reddit

I personally love the idea of AppImages. They're one single file for the whole program, and run on many distros perfectly fine. I find using Flatpak somewhat annoying, but just because I'm not used to it; other than that it's fine. Snap, on the other hand, I don't like it, and try to avoid it as much as I can.

[-]

Zikes@reddit

As a user, I despise Snap. Multiple times a day I get a persistent system notification that pops up and says "Pending update of 'firefox snap. Close the app to avoid disruptions (13 days left)." I dismiss the notification and it comes right back an hour or two later.

So I close Firefox, open the terminal, run sudo snap refresh firefox, discover there's still a firefox process running and kill -9 it, re-run the refresh, and re-open Firefox. But Firefox has frequent rolling updates, so within a day or two it happens all over again.

AppImage is tolerable, but I dislike how I can't just right-click the app icon in the taskbar and pin it, because it unpacks into a tmp folder that disappears when the app closes. I have to manually unpack it first or do some manual taskbar editing shenanigans to get that to work right.

Flatpak isn't too bad, except it sandboxes too well for some applications. I can't drag and drop files into Flatpak apps. If the app is e.g. an image editor and I save an image to my Pictures directory, I then go and look at my Pictures directory and it's entirely missing. It turns out there's some subdirectory under a hidden folder in my user's home folder three or four levels deep that I had to Google to find.

Honestly every time I see an app that's "conveniently packaged" like this and doesn't offer an alternative distro package I'll either skip it or even see if I can just compile it myself.

[-]

sartctig@reddit

Flatpaks, why? most widely used standard, easy and convenient to use.

[-]

MardiFoufs@reddit

I don't think flatpaks are actually more used than snaps. Ubuntu basically dwarfs* any distro that has flatpaks shipped by default (fedora, etc), and by default it comes with a lot of snap packages. RHEL doesn't use flatpaks as much, and is less common in situations where distribution is actually an issue (you don't usually install a lot of stuff on a RHEL instance, as it's usually more for servers and backends). I think that's changing and flatpaks are going to be used a lot more in future RHEL versions though.

I know fedora and others get a lot of online mindshare but Ubuntu is basically the standard or one of the main options in a lot of places. It's the standard distro in most azure services, has by far the best support in most AI/ML applications, research, etc. For a lot of software vendors, it's the default happy path now in the same way that RHEL is for server hardware support for example. The same goes for universities, work provided laptops, etc.

[-]

diditforthevideocard@reddit

Massive file sizes

[-]

js3915@reddit

Flatpak mainly because snaps suck outside Ubuntu for 1. 2 I hate how it clutter your device list. 3 no sandboxing unless your on Ubuntu. They used to load slow so that was a turn-off as well but that is supposedly fixed

[-]

bryyantt@reddit

Appimage then snap/flatpak because its just a singular file. if I wuna delete it I just move it to the trash and im done. I usually avoid using the other two because the applications I use are either available in my distros repos or don't work with containerized application solutions anyway. Otherwise I'll just use what ships with the distro whether that be snap or flatpack, I relly don't care for either though.

[-]

zagafr@reddit

distrobox is better than flatpak and snaps from what I have tested

[-]

realitysurf64@reddit

AUR :p

but, as the user, probably AppImage because of convenience

[-]

RupeThereItIs@reddit

No.

[-]

faze_fazebook@reddit

One single binary with all dependencies

[-]

euclide2975@reddit

None

If I have no other choice, flatpak

[-]

ImSoCabbage@reddit

For me the order is Distro package > AUR package > Appimage > Flatpak. I find appimages much more pragmatic than flatpaks.

[-]

sep76@reddit

I prefer apt , ill use flstpak in a pinch.

[-]

Ramiro_RG@reddit

none, I prefer the AUR

[-]

unixmachine@reddit

None of these! Native Arch/ AUR packages/ compile the packages

[-]

redoubt515@reddit

Generally: Flatpak

If I'm using Ubuntu or a close derivative: Snap

Appimage isn't my preference, but I do use them.

[-]

githman@reddit

Flatpak, if a verified one is available. Sometimes even if it's not verified - there are a few unofficial flatpaks I've been using for years. Nothing horrible happened yet. (Hope it's not going to be my last post, interrupted dramatically like in a horror movie.)

AppImages are fine but do not auto-update, so I check the repos first and go for an AppImage only if the repos are hopelessly stale.

As for snaps, I spent a few years on Ubuntu and my experience with snaps was rather regrettable. Nothing wrong with the concept, but Wayland syndrome got them: developers chose to advertise them as ready for prime time long before they even got out of the alpha stage. After lots of trouble with snaps I realized that I'm no longer interested.

[-]

StinkyDogFart@reddit

Flatpak...by a country mile.

[-]

SweetBabyAlaska@reddit

Flatpak. App image basically works on the exact principle but without dedupe and all of the other nice things

[-]

ExaHamza@reddit

My primary format is the native be it .deb or .zst, appimage as backup. If the app is not available on the repo and I want to use regularly then I built a package from it.

[-]

compulov@reddit

I kinda hate all of them to be honest, but I'm a crotchety admin.

If I had to pick one, AppImage mostly because I can download a standalone file and just run it.

[-]

Maximum_Todd@reddit

Native everything flatpak can’t. Snap and app image are for people who don’t use Linux

[-]

Esamgrady@reddit

Flatpak

[-]

OwningLiberals@reddit

My order is as follows:

Native packaging (or some equivalent such as AUR/third party repos) in 99.99% of cases.
Whatever way the dev says except for snaps.
Compiling if it's possible, small enough and the above options either suck or don't exist.
Flatpaks if the other options suck or don't exist.
Appimage if the other options suck or don't exist
Snaps if it's literally the only option.

In addition, there are other use cases which kinda skip the process:

Appimage for temporary apps.
Compiling for suckless programs and other programs where I want to patch or develop them
Programming language package manager for any libraries which are not C/C++.

[-]

Eu-is-socialist@reddit

None !

[-]

genitalgore@reddit

appimages aren't even in the same category and therefore shouldn't be included in the discussion. snap and flatpak both behave like normally installed software, providing an update mechanism and integrations with your DE, while appimage provides nothing and is therefore only useful as a portable installation for some utility applications.

between flatpak and snap, well, i don't use Ubuntu so snap is already out of the question for me.

[-]

AntaBatata@reddit

Just native. I use arch, I have the power of the AUR in my possession, I never need any of the aforementioned.

[-]

highly_confusing@reddit

I like appimages that are maintained to the newest version.

I don't like using flatpaks or snaps because I don't want an addiotional layer.

If i had to use flatpak or snaps it would be flatpak all the way.

There has been software thats only offered snap packages and that pretty much meant I wasn't going to use it.

[-]

ChocolateDonut36@reddit

my personal preference goes: - Native package - Appimage - flatpak

native packages are just better integrated with the system.

appimages are better for non-common use programs and programs I would like to have on a usb like tiny games or a few tools

I don't like flatpak sandboxing, specially on older machines, but sometimes flatpak is the only way to get some programs (and every distro can install them)

No snaps, those things are just like flatpaks but slower

[-]

Irverter@reddit

AppImage. It works anywhere without needing to install anything previously.

[-]

Swimming-Disk7502@reddit

Though I don't use Linux no more, I still prefer flatpak during my time with Arch and Mint because it works pretty much like exe, simple, snappy, fast and doesn't require any additional softwares or stuffs (damn you AppImage).

[-]

nandru@reddit

Flatpak > Appimage

Snap only for those ubuntu forces upon me (firefox) and those I can't officially find elsewhere

[-]

VidaOnce@reddit

AppImage is up front about how much storage it's going to take. I like it the most coming from Rust where statically linking dependencies is common too.

In general Flatpaks have seemed to waste the most space for me. On a space constrained system I uninstall Flatpak entirely because of the base 2gb+ runtime. The permissions are often more of a hassle than a benefit at the moment.

[-]

gibarel1@reddit

Native/aur whenever possible, then flatpak > appimage. I don't use snaps.

[-]

Gamer7928@reddit

Flatpak all the way for due to software availability and enhanced security not available with Snap's. Additionally, there might be missing required runtime libraries by AppImage's I think.

[-]

no_brains101@reddit

I don't really use either because I use nix and tend to install everything through that, which works on any Linux distro that I'm allowed to install the nix package manager on.

That being said, sometimes I have to generate one of these other options from my nix expression to take configured versions of my programs somewhere that I can't use nix.

If you want your app sandboxed, flatpak.

If you don't, appimage.

Both are sliiiightly slower than any native version of the same app that I could install through nix though due to the runtime thing.

[-]

MrGOCE@reddit

NONE OF THEM, THEY'RE NOT WELL INTEGRATED WITH THE SYSTEM

[-]

fallenguru@reddit

distro native packages >>> Steam >> AppImage >>> Flatpack > Snap

[-]

OkayStory@reddit

I just liked to use 'Apt-get install' now I'm stuck using flatpak.

[-]

MasterYehuda816@reddit

I use Nix, but if the Nix project suddenly died tomorrow and i could no longer use the package manager, i'd probably go with flatpak.

[-]

planarsimplex@reddit

Flatpak for desktop applications and Snap for terminal applications.

[-]

Zafarek@reddit

People hate snap for I still don't understand what reason. I tried Ubuntu from an external SSD, and it works fine. AppImage is good for being portable.

I don't like Flatpaks, especially the ones which are not verified by the author. Also going always with bleeding edge software is not that safe.

[-]

alerikaisattera@reddit

Of these three, appimage, because it can be executed without installation

[-]

ultrasquid9@reddit

Ive never used snaps or appimage, so I can't really give any opinions on them.

Flatpak is, in theory, great - everything is up-to-date and identical everywhere. The problem is that several apps have weird permissions, so I have to regularly open up flatseal and mess with them until they work. Some notable examples I can think of off the top of my head are Steam not creating shortcuts properly and Discord not allowing you to drag-and-drop files to upload them. Additionally, Flatpak is terrible for CLI stuff.

One format I personally really like, and consider underrated for this purpose, is Distrobox. Distrobox is pretty closely integrated into the host, and allows you to download packages from pretty much any distro you can think of. I personally use Fedora Silverblue, so installing system-level packages is a big pain, but working in a distrobox Arch container feels so seamless that that hasn't been a problem since I set it up.

[-]

JBsoundCHK@reddit

Flatpak and Appimage are my go tos.

[-]

frank-sarno@reddit

Flatpaks for me also. I prefer debs and rpms for other reasons, but if forced to will choose flatpaks any day.

I find snaps annoying. I don't like seeing all the packages I've installed whenever I do a "df". I don't like the workarounds I need to do to uninstall a snap without it automatically creating a snapshot and blowing out my filesystem. I don't like that they change default apt behaviour to force snaps for specific packages (i.e., apt install should work the same for all packages and not require additional steps for specific packages if I want a deb). I don't like the amount of work needed to create a local cache; snapcraft helps, but the setup required is more complex than with flatpaks and so many workarounds needed. Building snaps also feels like building for the Apple app store but with less documentation. I just get the feeling that Canonical is more concerned about controlling the ecosystem than building a tool that solves a problem. (And yes, some of this outdated but I did give it a shot because it does solve an issue.)

Appimages introduce more pain than it solves, especially with regard to dependency management. It's up to the developer to build in libraries but the format doesn't do much to help with missing dependencies. But they are smaller than snaps or flats.

[-]

gosand@reddit

Appimage, then Flatpak. Never Snap.

I only have a couple of Appimages, and they are things that I either want to run standalone (i.e. not install) or aren't in my repos. I use them rarely.

I have a few flatpaks but I am not even sure why, I was probably just trying something out.

I can't run snaps as I don't use systemd.

[-]

FranticBronchitis@reddit

Distribution repositories

Developer release

Compiled from source

All of those alternative packaging solutions have problems I'd rather not deal with.

[-]

sensitiveCube@reddit

Snappak, it has features of both. :)

[-]

Constant-Might521@reddit

Is there any Open Source package manager that can handle modern AI tools (Automatic1111, Focus, etc.)? Or that scales for large games in the 10-100GB range?

That are two use cases where almost everything falls short. With the AI case being currently "solved" by manually checking out git repositories and setting up Python venvs and the large AAA games being handled by Steam.

[-]

CodenameDarlen@reddit

I had to use Flatpak to install a 100kb package, guess what, Flatpak installed 1GB of dependencies.

Ok, those dependencies will be shared between my next packages and won't be installed again, but I rarely needs Flatpak, now I have 1GB just to run my 100kb package.

I like things integrated with the OS, I usually use apt.

[-]

jEG550tm@reddit

"me replacing sudo with doas so i can save 2mb on a 2tb ssd"

[-]

CodenameDarlen@reddit

I can't sleep knowing I've installed 1GB to run a 100kb package.

[-]

necrophcodr@reddit

Surely hyperbole or you need actual professional help.

[-]

CodenameDarlen@reddit

both my friend... both

[-]

necrophcodr@reddit

Haha that's fair! Then I hope it gets easier over time. And also maybe it's time to rewrite all flatpaks you use so they have no dependencies, no more breakage or large installs!

[-]

Jumpy-Elderberry9370@reddit

I think a lot of people don't necessarily have that much space. I for instance still have a 120GB SSD for `/`.

Then, there is the fact that 1GB to download also takes a lot of time, and that in aggregate it becomes worse.

[-]

ZunoJ@reddit

120gb for / seems excessively small. I mean storage is dirt cheap, why not just 1tb for root and have some piece of mind for the next 5 to 10 years

[-]

jEG550tm@reddit

I'm doing just fine even with 240gb for root, but will upgrade soon since I'm starting to consolidate my 4-5 random ssds i accrued over the years.

[-]

dev-sda@reddit

Ok, those dependencies will be shared between my next packages and won't be installed again

Only if the next package uses the same runtime. Chances are you'll be getting a whole new GB of dependencies.

[-]

Patient_Sink@reddit

A lot of the runtimes overlap and are deduped. So if you need the KDE runtime and already have the freedesktop runtime installed the difference is about 350 MB on my system, even though the runtime will be listed as around 1GB. Having 3 versions of the gnome runtime, 3 versions of the KDE runtime and 2 versions of the freedesktop runtime are about 3GB total for me, and I have over 130 flatpaks installed.

[-]

dev-sda@reddit

For sure, as the number of apps goes up of course the number of runtimes and their disk usage platoes. It's when you go from 1 flatpak with 1 runtime to 2 flatpaks with 2 runtimes that things look really bad. I have 8 apps installed and my runtimes are using 3.9GB total.

My org.gnome.Platform and org.kde.Platform share 400MB out of their combined 2.1GB. That's great savings, but a hard pill to swallow if you're only using 2 apps.

[-]

Patient_Sink@reddit

Yeah, that's a fair point.

[-]

domsch1988@reddit

But, if you installed the same package from your distros Repo, it would still require those dependencies to run, wouldn't it?

[-]

CodenameDarlen@reddit

No, because in theory my distro already have those dependencias OS-side. What Flatpak does is creating a new environment with basic dependencies (much probably the same as I already have on my OS pre-installed) to run the app isolated.

If my distro doesn't have all dependencies, it's probably a matter of just installing a few others, but the main stuff it already has. While Flatpak will reinstall EVERYTHING to be able to run a given package.

[-]

domsch1988@reddit

That's a lot of "probablies". Your assumption only works if your distro put in the time to package your specific tool in the specific version that's compatible with all the exact dependencie versions in their Repos. In every other case you either don't get your package at all, because it's incompatible, or you have to install the same dependencies as the flatpak does. And they are just as useless then, ass no other package from your distro could depend on those versions.

I have currently installed 14 Flatpaks on a System Level with 4 Mesa Libraries, 4 openh264 Versions and 2 ffmpeg versions and that's all together 3,6 Gigs. Yes, each additional flatpak tends to use less and less storage overhead, but are we really still at a point where 1-5 Gigs of Storage is relevant for the benefit of getting a up-to-date, sandboxed version of Software that's available on every distro? Especially when, in many cases, before flatpaks devs wouldn't have bothered to build for anything other than ubuntu, if at all.

[-]

adamkex@reddit

Yeah the issue with Flatpak is that it get becomes more worthwhile using the more you use it

[-]

umikali@reddit

X86_64

[-]

necrophcodr@reddit

Which one?

[-]

umikali@reddit

The file extention

[-]

necrophcodr@reddit

Huh? .x86_64? Which file format is that?

[-]

umikali@reddit

The executable format

[-]

necrophcodr@reddit

.. So which one is that? If you're talking about ELF, that is shared by GNU Hurd, various BSDs, and other systems. If you're talking about glibc Linux ABI ELF executables, they also differ from distribution to distribution, and may not be portable across Linux systems. So is that what you prefer? The ELF format in general?

[-]

azharahs76@reddit

I personally prefer AppImages. AppImages are portable from system/distro to another, and generally don't require you to install anything special in advance, or tinker with permissions. The trade-off though is that they can take up more space than a Snap or Flatpak of the same program. They make great tools to put on a USB for troubleshooting multiple systems, or as someone else mentioned, for where you don't have root access to install other apps.

[-]

99thGamer@reddit

AppImage or deb, as I mostly use Linux Mint or Debian. I also don't really like sandboxing because it's always given me more trouble than convenience.

[-]

Routine_Left@reddit

lol, neither of course. damn them all.

[-]

StatementOwn4896@reddit

Podman or docker

[-]

Stunning_Speed_2627@reddit

Appimage cause its just clean

[-]

arthursucks@reddit

Flatpak is the best. Open and with a wide variety of quality apps.

Appimages are good for testing or for applications that don't have a native build.

Snaps should be avoided if possible. I'd rather compile from source than have Canonical get root access to my system.

[-]

mrtruthiness@reddit

I prefer native.

I currently run a minimal number of snaps (lxd, firefox, chromium) and will only install snaps from a trusted source (Canonical, Mozilla, Snapcrafters, ...)
If I want to try out something (to see if it's worth it) I might try a flatpak temporarily. If it's good enough I'll compile it. I don't run any flatpaks currently.
I've never run an appimage and I'm not sure why I would.

[-]

whosdr@reddit

I go Flatpak where they work well. And I've had the most success here. I manage the permissions through Flatseal, they always seem to work, and if I hop distro then I know it's just a flatpak install away.

Appimages took more effort to maintain long-term than I'd like. Having to fetch updated software, and often were packaged incorrectly and broke during major software updates. I know there's software for this out there, but I've seen a few different (and sometimes overlapping) projects. Nothing first-party for basic functionality, so that put me off.

Snaps I just don't touch. It's more a philosophical reason than a technical one. They just don't get a looking at all from me.

[-]

apollo-ftw1@reddit

Anything but snaps

[-]

KamiIsHate0@reddit

Flatpack by far, as user and dev. True sandbox, smaller, works everywhere, easy to update and cool logo.

[-]

Razangriff-Raven@reddit

I prefer appImages personally, they are daemonless, simple and to the point. It's my favorite choice for programs I don't want to have the whole runtime/building libraries for. I still use them sparingly so updating them is no hassle and is easily automated with some bash.

Flatpak would be my second choice, but it feels less like self-contained packages and more like an extra package manager, kinda like using chocolatey on Windows or something. Otherwise it's pretty good.

Snaps are my no-choice, I don't like their implementation, features and again being an extra package manager. The weird actions of Canonical like forcing "firefox as snap only" don't help. They can be useful in very very veeeeeeery specific scenarios but otherwise I avoid them like the plague.

[-]

Deathnote_Blockchain@reddit

I prefer simple distro based package managers like apt or whatever. I really have no use for a package manager to work across multiple distros, I don't like things running in containers, I don't like apps that need to be kept up to date on their own release cycle, etc. If I need an rc build of something I can compile it myself.

[-]

lproven@reddit

Appimage FTW. No framework, no libraries, no app stores. Real freedom.

[-]

lproven@reddit

Appimage FTW. No framework, no libraries, no app stores. Real freedom.

[-]

Allseeing_Argos@reddit

I usually have the least problem with appimages.

[-]

wheelful@reddit

Ceteris paribus, I prefer AppImage, but I always use whatever the developer of the application recommends or distributes. If they give me a .deb, then I use that.

[-]

EverythingsBroken82@reddit

you forgot distrobox, guix and nix and VMs.

i use all besides snap.

snap? hm, i do not know, there's nothing which is not covered by the rest and back in the day i was not overly fond of the mount issue and that there was only software from canonical which could distribute it. the idea itself was nice in theory, but there were a few issues (application need to be optimized so they are not slow)

[-]

pagefalter@reddit

None, static link things.

[-]

pacifica333@reddit

Native package > Flatpak > AppImage > Snap

[-]

BarePotato@reddit

None of the above.
If my only option to use your software is one of these, I generally won't even bother using your software.

There has been a very few rare occasions I did use an AppImage, and that's whatever.

[-]

0riginal-Syn@reddit

Out of those 3, I put them in this order...

Flatpak - Works well and is open source all the way through. People complain about the size and for a single package that can hold true; however, Flatpak can share dependencies so as you add more you are not adding as much extra space if the requirements are already there. Integrates well with the system, functionality wise. The theming could be better, but it is something being worked on.
Snap - Similar to flatpak, but too much control is put in the hands of a single corporate group. It has packages not available on Flatpak and/or other distros, so it is a good fallback for that reason alone. I only use it if FP is not available.
AppImage - Could be great and is getting better with tools like Gear Lever. However, it is just not a smooth process for integration into a system. As a standalone package, however, it is wonderful, and I use it for my portable apps. One of the other problems is how different each one handles updates, integrations, data, etc. It is inconsistent. Like the other 2, AppImage takes up a lot more space, but unlike FP it does not share resources with other AppImages, so it uses even more space.

I like and use all 3, although I prefer system packages first and foremost. Out of these 3, FP is #1 by a fairly wide margin, and Snap and AppImage are more or less tied at second.

[-]

lynn_shell@reddit

guix packages, or guix shell for containers

[-]

foxhound_75@reddit

I just hate all of them

[-]

billFoldDog@reddit

I prefer appimage as a user, but I'm very happy with flatpak.

Snap is a no from me. I don't want to support what I see as a centralized marketplace.

[-]

rafaelhlima@reddit

As a user, whatever works best... I'm on Fedora and mostly use flatpaks, but I also have some snap apps as well

[-]

xezo360hye@reddit

Nix

[-]

JudithMacTir@reddit

If I have to go with a non repo app, I always go for AppImage.

[-]

BarrierWithAshes@reddit

I prefer AppImage because I can decide where I put it. I like to have all my software where I want it and not scattered all over the place.

[-]

SuffixL@reddit

Appimage because how easy it is to use. But with the AUR I rarely need any of these

[-]

Vittulima@reddit

Flatpak all the way. Repo model + sandboxing + great app availability + it offers a nice way to separate GUI apps from the base system.

AppImages are fine for one-off uses or if there's no other options. Snaps, no thanks.

[-]

gen2brain@reddit

None of the above. Native packages, if it doesn't exist I compile whatever I need. The only flatpak app I have is my own app, so I just use it for testing. And my flatpak directory in .local/share is like 10G?! Perhaps I tested something but this is wrong. Then again, there are like 3K users of my app, I would not know that if I just release a binary on github, and again, seems like people do use the flatpak. I don't care about snaps that only work on Ubuntu.

[-]

Patient_Sink@reddit

Part of that is likely because you have the SDK platform installed, which is used by the flatpak builder to actually build the package. It contains a lot more stuff than the regular runtime.

[-]

gen2brain@reddit

That is probably it, I do have flatpak-builder installed.

[-]

DocEyss@reddit

I love AppImage One file. Just works. Never had any problem. A masterpiece of software, I am in love with it.

[-]

Aperture_Kubi@reddit

I like the idea of AppImage, they're brain-dead portable files too.

[-]

DependentOnIt@reddit

None. AUR or locally built.

[-]

zarlo5899@reddit

what ever one works

[-]

RomanOnARiver@reddit

It doesn't matter to me. I go with what the vendor recommends. Steam is a deb package, Chrome is a PPA, VLC is a snap, Audacity is an AppImage. As long as I can click a panel launcher and launch it I'm good with either or. That being said, I like how snaps and flatpaks update. AppImages don't update unless I launch them and if they have their own update thing. Then again, Steam has its own update thing, but is also a PPA. It's weird.

[-]

01111010t@reddit

Distro repo and then flatpak

[-]

vinhorr@reddit

As a NixOS user, flatpak is the best. AppImage doesnt work on NIxOS out-of-the-box and snaps... well, they aren't that good as flatpak or native applications

[-]

domsch1988@reddit

I think all three have their Place. Especially on my Work machine with debian i use all three.

Flatpak is great for User/GUI Applications that my distro doesn't provide or is out of date in. Also for things where Library Dependencies can be an issue (Steam/Lutris etc.)
AppImage Especially with AM as a Package manager, i like them for temporary Software or things where Flatpak Sandboxing can be an Issue (Fixable in most cases, but AI is less hassle). Also, some Programs don't come as Flatpak (Orcaslicer being one of those)
Snap Is like Flatpak but can actually work well for terminal applications and "Libraries". I have that to install things like NodeJS in a recent version on Debian stable. Yes there are Repos, but they don't work through our work proxy and i feel Snaps are less "hassle". Same for Neovim. That could also be an Appimage but the snap works way better when it comes to env things and Paths and such. Just less hassle to set up than an Appimage. ZelliJ is in the same boat. Terminal Application that i would otherwise have to build from source.

I know Snaps aren't that popular, but i really like them for terminal applications. Once installed they feel more "native" in their integration than Appimages or Flatpaks. Between the Rest, i usually check my Repos Version first, if that's unavailable or too old, i'll prefer the Flatpak for things i want to keep and Appimages for things i'll likely get rid of soon(ish).

[-]

marathi_manus@reddit

snap is tasteless.

[-]

bloginfo@reddit

I prefer AppImage. It doesnt depend on a package manager. I never use Flatpack. Only dnf manager on Fedora and apt manager on Ubuntu.

[-]

rileyrgham@reddit

There's also a search function in this subreddit. A lot of useful information from the other times this was asked.

[-]

Constant-Might521@reddit

None of the above. Nix Flakes are the best by a long margin, as they are the only one build with the needs of Free Software in mind. Meaning you can build straight from a git repository, have dependency management, can easily fork and edit and swap versions up and down as much as you like. And it's a fully features Linux package manager in the traditional sense, unless say Flatpak which is completely focused on packaging monolithic GUIs apps.

[-]

Fit_Flower_8982@reddit

The first option is native package except if:

It is a proprietary or low-reliability app
I know it will mess up several directories
It involves constantly downloading and running from unknown (e.g. browser), and I prefer to have an additional sandbox layer
I want it to be portable

In such exceptions, flatpak. This is also my second choice, because of its ease of installation, upgradeability, and its sandbox (for it to be valuable you must understand and control permissions).

For the third option appimage, it is not very practical, you must download everything at once each time and on your own, but it works well and there are no additional requirements or concerns.

There is a fourth option, snap can burn.

[-]

sdwvit@reddit

Appimage. Flatpak is buggy, and snap i don’t care about

[-]

DFS_0019287@reddit

I use kdenlive (a video editor) as an AppImage. I find it very convenient to just download one runnable file, and for my use-case, sandboxing is not an issue. Also, kdenlive doesn't release updates all that often, so it's no big deal to update manually.

Everything else on my system is native .deb packages plus a very few things compiled from source (mostly software I've written myself.)

[-]

Ayala472@reddit

I really like flatpak but I have no problem using Appimage, in my fedora I use both because there are some programs that the Linux version is only in Appimage, now Snap ... I won't use it in my fedora

[-]

onefish2@reddit

None of them

[-]

vanwaldi@reddit

Flatpak but I do wish they implement channels like Snap.

However, running an appimage sometimes is convenient too, all is self-bundled in a single executable, especially those that autoupdate such as Bitwarden.

[-]

KrazyKirby99999@reddit

There is a Flathub Beta repository: https://discourse.flathub.org/t/how-to-use-flathub-beta/2111

[-]

Kabopu@reddit

For my Desktop use: Flatpaks

They're loading faster than Snaps, in my experience.
The sandboxing can be useful if you actually manually check/set the access rights with a tool like Flatseal.
Automatic Updates.

[-]

Neoptolemus-Giltbert@reddit

AppImage is the only functional method, snap and flatpak come with ridiculous attempts to block me as a user from fixing software that is broken, and blocking software I chose to install from doing things I am asking from it. These constantly cause serious issues with software not working, e.g. Slack not being able to register URL handlers for their login flow. No such issues with AppImage, I get software that works, and does what I ask of it, easily integrated to my desktop, and I can download it straight from the developer.

[-]

kansetsupanikku@reddit

It depends. Unless it's a graphical application with a lot of infrastructure and dependencies, it's neither.

AppImage is the best concept, and clearly works for stuff such as Krita. Management that would include updates is kinda lacking, but that's the way to get sane amount of dependencies (only glibc version, really). The fact that X11-based AppImage in Wayland session will run via XWayland is kinda the point.

Flatpaks could have been just as good, but with dependencies from "runtimes", they are just (usually) bigger packages. The set of runtimes works as a new, "reference" distro. So I prefer AppImages. However, the big plus is that Flatpaks actually work! And they provide some security, with configurable balance between isolation and usefulness for each app.

Snaps could have been outright Flatpaks replacement for AppArmor users. But, uh, they are AppArmor-specific. And tend to kill your hard drive. Sometimes Ubuntu LTS is the default one needs to use, sometimes it sounds reasonable not to touch things that work (like, Snaps installed there by default). But more than once I have realized that, uhm, no, Snaps do not work. So an extra step to remove them is necessary. Or using Mint as base when you want Ubuntu-comatible versions.

Notably, it remains possible to just build stuff from source and install to specific prefix as user. Then just attach it or not via environment variables. Whenever I need to play with versions and patches, also those written by me ad hoc, this approach just might be the most useful.

[-]

mrlinkwii@reddit

AppImage is the best concept, and clearly works for stuff such as Krita. Management that would include updates is kinda lacking,

appimages can do self updates , but has to be implemeneted by teh dev ,( appimages such as RPCS3/PCSX2/Duckstation ect use it )

[-]

ranisalt@reddit

The “I prefer native” is the new “I use Arch”. The question was not directed at you guys, just scroll to the next post.

[-]

colorfulmoth26@reddit

I used to be a "distro package manager" purist, but nowadays I hate it. It just adds entropy to system updates and makes it so you are more likely to end up with a broken package due to a random regression. After I started using inmutable distributions and purely Flatpak it has felt as if I've never had a regression with a system update.

[-]

Separate-Solution801@reddit

Flatpak.

[-]

mrlinkwii@reddit

i perfer appimage because i can have multiple version of applications , unlike systems packages/flatpak

[-]

avjayarathne@reddit

native packges, if not flatpak of course. I won't ever go for appimage

[-]

redsteakraw@reddit

App images for complicated one off apps that don't need updates, Flatpak for dynamic apps and supported software. Flatpak also work on the steam deck so if you deploy there you have a built in userbase and it is truly distro agnostic

[-]

Advanced_Parfait2947@reddit

flatpak. They tend to shit the bed way less than snaps. example:

the steam flatpak is actually usable (not that i would use it mind you) but the snap is utterly broken

[-]

VeryNormalReaction@reddit

I like the idea of AppImage, the syntax of Snap, and the overall way Flatpak is structured.

[-]

flemtone@reddit

Native packages, appimage for newer releases and flatpak if those aren't available.

[-]

EarthyFeet@reddit

Appimage just from my experience. I had janky audio issues with flatpaks.

[-]

FryBoyter@reddit

I personally prefer the normal package management of the distribution I use.

[-]

Expo_98@reddit

pacman and the aur

[-]

wchmbo@reddit

The more I trust are my distro package maintainers. If the package is not found in repos or it depends on Qt libs (because I’m more of Gtk), then I go to AppImage: well bundled and size restrained. Ah! and only execute apps from renowned devs/companies

[-]

Mission_Horror5032@reddit

building from source is pretty neat

[-]

TheFeshy@reddit

For those few times I don't want native packages (Steam wanting to install an entire 32 bit ecosystem, Discord being discord) I use flatkpak.

[-]

Clean-Agent666@reddit

.deb or gtfo

[-]

ndr3www@reddit

AUR 😎

[-]

TheGreatButz@reddit

aptitude

[-]

VacationAromatic6899@reddit

Debs

[-]

Flench04@reddit

Flat packs and Appimages on desktop. On servers I love docker and don't mind the ocasinal snap package but only for nextcloud.

[-]

Okabe_Zero-Link@reddit

Native, flatpak if not available or have a newer version compared to the native version, appimage only if they don't have anything else, wtf is snap anyway

[-]

LuisBelloR@reddit

None, i use arch btw and dont need that shit.

AUR = LOVE

[-]

kemma_@reddit

AppImage, because I just can’t stand flatpak insane runtime overhead. Snaps should not even exist

[-]

dicksonleroy@reddit

Flatpak on the desktop. I like that the apps stay up to date.

Docker on my servers, even though they run Ubuntu. I’ve uninstalled Snap from them.

[-]

_-Kr4t0s-_@reddit

None of the above. I want native, non-containerized apps.

[-]

aksdb@reddit

AppImage for apps where I need different versions in parallel or where I want to stick to old versions (for example licensed apps where the license is bound to specific versions).

Flatpak for other things that have weird dependencies I don't want to taint my system with.

For a majority of things, I prefer packages of my distro, though.

[-]

unluckyexperiment@reddit

Snaps, because it supports cli apps and you get less problems about apps trying to access necessary system files, codecs, settings, etc.

[-]

jelloshots8607@reddit

I pretty much use what comes with the distro i use (well used to, my distro hopping days are done) for the longest time i couldn’t be damned to set up something like flatpak on ubuntu or even like discover in endeavor os. Now im super picky about it really only liking flatpaks and native packages, and only using appimages if nothing else works. (I’ll pass on snaps loll)

[-]

Mister_Magister@reddit

Actual packages

[-]

Soarin123@reddit

Flatpak first, AppImage second, Native last generally. I like things working predictably and files being contained.

[-]

lordkoba@reddit

docker

[-]

Exact-Teacher8489@reddit

Recently had a problem with nvim where i wanted a newer version (i use Debian bookworm). Since flatpak is a hassle to use in the cli snap it is. Also neat thing that i don’t need an extra command. Then i had a problem with jdownloader where the flatpak failed to comunicate with the browser addon. Using the official jar file worked. Then i had a problem with the flatpak of qownnotes where it was often not drawing the window title. The native repository works great.

For me flatpak just always caused problems.

[-]