Flatpak vs Snap vs Native Packages

So I know my way around Linux pretty well. However I never really got the gist of the difference between Snap, Flatpak and Native packages.

What exactly sets them apart?

Why does everyone seem to hate snap?

I have been using all of them, simultaneously on the same system and never really noticed a difference in the way installation, updates etc are handled (syntax ofc).

I hear snap sandboxes? Is that the main reason? Thanks for your insights..

sgtnasty,
@sgtnasty@lemmy.ml avatar

Here we go!

WFH, (edited )
@WFH@lemmy.world avatar

From a technical point of view:

  • Appimages are like MacOS .app programs. You download a random executable from a random website, that contains everything it needs to run. It’s the antithesis of the Linux way. Great for portability, awful for everything else. There are no automatic updates unless the developer explicitly bothers to implement them.
  • Snaps are like docker containers. Each snap also contains everything it needs to run, but at least there is a centralized update system.
  • Flatpaks are like another package manager layered over your OS. It manages its own dependency system isolated from your main dependency management. It updates its stuff pretty much like apt/dnf/pacman.
  • Native are managed through your distro’s package manager, obviously.

From a feature/version point of view:

  • If you have a bleeding edge or quickly moving distro, native packages are fine if you want/need up to date software. Arch users shouldn’t need Flatpaks for example. The downside is that those packages are made by the distro’s maintainers so can be anywhere from untested pre-release software (happened in Manjaro) to extremely outdated (like in Debian oldstable).
  • Flatpaks/Snaps/Appimages are more and more maintained and packaged by their developers. It’s great for them as you only need to package once, all bug reports are on versions you control, and you don’t need to depend on a distro’s maintainer time and will to push updates to users. For stable distros users, this is theoretically the best of both worlds: a stable, tested OS with up to date user facing applications.

From a philosophical point of view:

  • Appimages and Flatpaks are fully FOSS. Flathub is the dominant ways of distributing Flatpaks but anyone can create a competitor.
  • Snaps are distributed through Canonical’s Snap Store, which is not FOSS and is vulnerable to Canonical’s corporate meddling.

My personal preference:

  • Flatpaks for GUI apps, native for CLI tools
  • Appimages as a last resort if it’s the only way to get a specific app.
  • Snaps never.
fruitywelsh,

Flatpaks are great for GUI apps, and have a sandboxing system that allow them to work well on any system that support flatpak. This allows devs to package once run anywhere, saving Dev time! It also has a portals system to allow for better system integration of the granular permissions needed for the app to actually work (nobody wants a truly isolated sandbox for every app).

Snap is less featureful for GUI apps, but work closer to how native packages do. The real issue is the proprietary app store required for it, making non-foss. If you want the same benefits of snap, check out Guix and NixOS both of which have a more cleaner design, and work better IMHO.

lemminer,

I personally prefer appimages. What are your thoughts about it?

mrXYZ,

@lemminer @fruitywelsh
Appimage is OK but no auto update makes it download and forget type of deal - definitely not for every app
Flatpak - best for me but permissions on some apps make it unusable e.g. gpodder - command for player as flatpak is unable to access MPV installed from repo flatpak etc. - sandboxing (couldn't fix it with flatseal mpv --profile=... not working)

  • snaps people love to hate them... no love from me :-)
    Repo if it works, is available - the best option
fruitywelsh,

Its use able. I like unified update mechanism and shared package/library/image systems

Raphael,

Companies like Red Hat, OpenSUSE and Canonical are not only trying to sell support but also convince others that they are innovating. Red Hat kickstarted Flatpak and then Canonical, who didn’t want to “lose” decided to push their own thing, Snap with the strength of ten thousand suns. Naturally, this is a simplified explanation, Snap already was in development at the time but if we truly followed the spirit of open source, Canonical would have dropped it and adopted Flatpak instead.

OpenSUSE has quite a few products in the kubernetes sector, even Oracle has its own things they can brag about. Canonical has basically nothing and this is why they’re pushing snap as if their lives depended on it.

Remember, Linus didn’t write an OS because the GNU folks were writing one, GNU didn’t write a new kernel after theirs failed, because Linus had a working one. This is the nature of free software, Canonical has completely forgotten about it. Red Hat now too.

vampatori,

I don’t think consolidation, compromise, and coming together in one common direction are the hallmarks of open source at all!

Filesystems, service management/startup, audio output, desktop environment, package formats/management/distribution, programming languages, shell, and so on, and so on - all have many, many options.

Open source is, if nothing else, fractured… it’s about choice, flexibility, and re-inventing the wheel not because it really needs to be re-invented, but because it’s fun to do so and useful to have something that perfectly fits your requirements.

We’ve made room for many package formats for decades, and will continue to do so for decades to come I’m sure.

TCB13,
@TCB13@lemmy.world avatar

Flatpak is fast, lightweight actual open-source and provides security via isolation. Snap is the usual BS Canonical tries to get people to use, has a ton of bloat.

Personally I’ve had zero issues with Flatpak under Debian for desktop usage. It integrates nicely with the GNOME Software “store” and allows you to get the latest and best of everything you might need without polluting your system. Flatpak solves the usual complaints about Debian only having “old” software - allows you to run the latest and greatest while keeping a clean and rock solid Debian system underneath.

ReakDuck,

Flatpak sandboxes too, but it at least is fully Open source, you can create your own Flatpak Repository and add it to your flatpak to grab and install new packages you made yourself. For Snap… it implements not that good into the desktop I heard but may have changed, you can’t create your own repository nor see the servers code as there is only 1 single server for Snap, and its canonicals Closed Source Snap Server. But hey, it at least got the super cool Hologram Open Source Sticker on it, because the client is at least Open Source… No thanks

I use PrismLauncher (Minecraft Launcher) inside Flatpak for example because it sandboxes the app so no stupid mod can infect me that easy now, haha! But generally its kinda comfy to use Flatpak because it has less dependency issues compared to Native Packages because Flatpak has its own Packages which Flatpak Apps can share to each other. Snap on the other hand can’t have dependencies shared between Snap Apps so they all have duplicate dependencies.

frozen,
@frozen@lemmy.frozeninferno.xyz avatar

Snaps are disliked because the store is closed-source and run by Canonical. Snaps are also disliked simply because Canonical is pushing them so hard, forcibly replacing native packages that exist and work fine. For example, there was a debacle a while back where running apt install firefox still installed the Snap version instead of the native version.

Flatpaks are disliked because they sometimes struggle to integrate into a system well. For example, Discord Rich Presence doesn’t work for the Flatpak version of Discord unless the thing you want Discord to detect is also a Flatpak, and even that detection is shaky.

Snaps and Flatpaks are both disliked because they contain frameworks and runtimes that some users consider bloat.

To further explain, when you use a native package, it and its dependencies get installed on your system. If any other package in the future requires one of those dependencies, awesome, it’s already there. But for Flatpaks and Snaps, each app has to bundle its own dependencies. Sometimes they can be shared with other Flatpaks/Snaps, depending on the dependency, but they still require at least a little extra storage space.

There are probably details I’m forgetting, but those are the main arguments. My advice is if you’re happy with the way your system is running, don’t worry about it. My personal preference is Flatpak first, native second, Snap never. I don’t have anything against native packages, but some software I use is exclusively distributed as Flatpak, so I switched most things over for consolidation.

ReakDuck,

Afaik snaps can’t share depending packages, making it store the same dependency multiple times. Flatpak can share the depending package+version, sharing it to every app it needs and store it once.

The Golden advantage I see is not having issues installing multiple versions of the same dependency, which would be kinda hard for a native system depending on the type of package an app is depending on. Like Python and Java could easy have multiple same versions on a native system, but other things may be too difficult to realize except you use Flatpak.

So the main point is comfort I guess, it just works on all distros unrelated if a dependency doesn’t exist for the distro or is too old/new.

Not sure how secure Flatpak is. But 2 serious scenarios are existing to use it: You want to isolate the app from system for security. You have an immutable read only OS and want to easily install packages.

igorlogius,
  • All
  • Subscribed
  • Moderated
  • Favorites
  • linux@lemmy.ml
  • cisconetworking
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • osvaldo12
  • everett
  • Youngstown
  • mdbf
  • slotface
  • rosin
  • GTA5RPClips
  • ngwrru68w68
  • kavyap
  • InstantRegret
  • megavids
  • cubers
  • khanakhh
  • ethstaker
  • tacticalgear
  • Durango
  • normalnudes
  • tester
  • modclub
  • provamag3
  • Leos
  • anitta
  • JUstTest
  • lostlight
  • All magazines