I know snap is fairly unpopular in the Linux community, and I’ve seen mixed responses regarding Flatpak. I wanted to know, what’s the general opinion of people in this community regarding this 2 package managers?
You must log in or register to comment.
To quickly introduce myself, I’m the main author of Paperwork. I’ve packaged Paperwork in various ways, and many people have packaged it in various distributions as well.
I’m fine with Flatpak. In my opinion, it has its use cases. I find complementary to other existing methods (distribution packages, AppImage, …)
However I’m not fine with Snap. I haven’t used it much, but my understanding is that it focuses on Canonical servers. You can change its configuration to use other servers, but it defaults to Canonical servers (and we all know most users will never change default settings). To me, this is a slipping slope towards proprietary services/software.
Moreover, I’m really annoyed by Canonical pushing Snap by default in Ubuntu (Firefox, Chrome, etc are packaged only using Snap now; the APT packages install the Snap packages). It doesn’t bring anything to the users. Those packages could have been as well-packaged using APT (see the repositories *-updates in Debian for instance).
PS: nice software your Paperwork. I hope in the future you’ll add support for djvu format – most of my documents are in that format (it saves a lot of memory for scanned documents, compared to pdf).
That’s something I would like to do someday. Unfortunately, last time I checked, libraries for reading DjVu files exist and are OK, but not for writing them. Last time I checked, most programs I found that write DjVu files actually don’t use the DjVuLibre library. They actually run the DjVuLibre commands.
Great that it’s in the todo-list anyway. I usually use the Any2DjVu server for converting and OCR-ing documents in pdf format. The djvu file is typically 20% size of the original pdf, and the OCR is usually better too. I’ll check on your project regularly for updates :)
Thanks to Flatpak, I can have basically careless OS updates with Fedora Silverblue, so I’m very happy with them. I also appreciate the fact that every distro that can run Flatpak automatically has a wide range of software available to it.
I’m sure Snaps have similar advantages, but I haven’t worked with them much. I don’t really like that you can only publish Snaps through Canonical though, so in that sense I hope Flatpak wins.
First of all, I think an idea of package management separated from a system environment is generally good for desktop usage. And don’t like and the idea to place all existing application software in distro repositories. But implementations are far from ideal. So I list those bellow from worse to better.
-
AppImage. It highly relies on the environment doesn’t have native sandboxing, and promotes bad practices like building apps with old libraries.
-
Snap. Snap is mostly fine but relies only on AppArmor for confinement, has performance issues for a long time without significant progress. It promotes a proprietary app store. Relies on Ubuntu infrastructure. Good: snap store support signed packages and more friendly to developers.
-
Flatpak. App start time is near to native. It has stronger sanboxing but with many holes for compatibility. It true distro-independent as well as popular runtimes are also distro-independent. Bad: Flathub doesn’t support signed applications. Sandboxing and permissions rely on hacks and tricks which are far from good design. Development is slow but it is true for the mentioned above as well.
With that, I am more open to new alternatives, especially if started from a system point of view rather than from a position of distro-independent package managers like Google did with Android. For example, sandboxing can rely on users separation and work on various operating systems not only with Linux kernel.
-
Flatpak made my life much easier. It solves so many problems that the Linux ecosystem had. “Package once, use everywhere” is great.
Snap could have been similarly good, but I think Canonical made some mistakes.
I don’t hate Snap. I think a bit of friendly competition is good for both Snap and Flatpak.
On a distro like Fedora that doesn’t ship non-free codecs, flatpaks makes it a lot simpler. So I really like it for stuff like Firefox and media players.
It’s bloated… but at least now even my grandmother can use linux thanks to it. :^)
I’ve come around to liking Flatpak.
- I don’t have to deal with dependency hell I sometimes get with third party packages (AUR/PPA)
- I don’t have to worry about make dependencies
- I don’t have to deal with clutter in my home directory, they are mostly encapsulated in ~/.var and easy to clean, discover even asks me. Especially if I try the app for 10 minutes and device it wasn’t for me. Espexially for apps that don’t follow XDG base directory specifications (which is too many, but that’s another post)
- I get some (imperfect) sandboxing and control over what an app can access, especially with proprietary things like Discord …
Anything I need to get into a desktop environment should come from the distribution’s repositories and package manager. For user applications, Flatpak is great.
As an out-of-band software delivery method and supply chain that
- breaks single source of truth
- defeats/breaks simple enterprise-style (HOST-RESOURCES-MIB::hrSWInstalledName) inventory
- enforces/uses alternate dependencies
It has ab-sol-ute-ly no value to me, and only security risk after security risk.
Apologies to those who’ve spent time on them, but I’m happy to not see them as their value within the scope of my workday fell off a cliff in about 1996 - maybe before they even existed - with the advent of something better.
Again, sorry. I’m only speaking as someone who used to manage OS security on Unix and has spent 20 years in the leviathan-enterprise space as rehab. Your mileage with glitter may vary.
I always prefer native packages over containerized. But I’m glad they exist, because every now and then a native package won’t work. I don’t agree with most people that say Linux needs to be streamlined: less distros, less packaging systems, etc. Personally, I like when I have options. I prefer flatpak over snaps and appimages, but ideally I’d like to have all of them available just in case. When comparing snaps to flatpaks, in my personal experience, flatpaks just integrate better. But they’re not THAT much better than snaps, so I could see myself using either, it’s just that so far I haven’t run into a situation where I’d need to use a snap. There is one downside to flatpaks though, and it’s their names. As DT pointed out in his video, it can be pretty annoying to run them through terminal. But I hate the fact that Mint removed snap and Ubuntu removed flatpaks. I don’t think we’re achieving anything with this “war of formats”. Let people use both and decide for themselves.
Snaps still don’t seem to have network storage permissions when I tried ubuntu a week ago, so they suck for me. I put just about everything on my NFS.
A lot of the flatpaks for programs I actually use are third party and not maintained by the actual developer, have missing or enweirdened features because of the sandboxing, and are a removed to run from command line. So I try to avoid those too.
pretty unpopular opinion i believe, but i loathe them. they feel like installing apps from the windows store, but worse. i use them on steam deck and my laptop, but they often fail to launch with no feedback[1], won’t accept drag&dropped files, store their dotfiles in weird places, take up much more disc space (and therefore take literally almost 10x as long to download), won’t inherit the theme (i think because plasma stores the gtk theme in a non-standard place), etc. they feel like they’ve been designed to flout what os developers have built up over many decades and are just a struggle to use.
on steam deck particularly (so i know it’s not a configuration i’ve screwed up) no flatpaks will launch unless i launch them twice. even after that, there’s a long delay (~1 minute) and then two instances launch. i know this sounds like i should just wait until the first one launches, but that doesn’t work ↩︎
The Flatpak theming issue is really annoying, yeah. There’s a rather limited pool of GTK themes to choose from in Flathub, but as long as you’re running one of those themes in your DE (assuming GNOME or other GTK-based), themes will inherit. Can’t speak to KDE as I haven’t used Plasma as primary.
Other than that, Flatpak has been great. I use it reasonably heavily on a laptop that’s slower than a Steam Deck (Ryzen 5 3500u, 8GB DDR4, 1TB Samsung 970 Evo Plus) and haven’t run into performance issues on multiple distros — EndeavourOS, Pop!_OS, LMDE, Fedora, an early version of Vanilla OS, and most recently Debian 12. On my desktop I don’t feel a performance difference between Flatpak and native.
The steam deck uses KDE, so the most popular Linux desktop device is going to be showcasing what flatpak is(n’t) capable of.
This is largely a problem thanks to the GNOME developers though, refusing to play nicely with anyone else and acting like their way is THE way.
I like Flatpak in general and it might be the future™ but I hate how huge the packages are
I’m trying to use native package as much as possible, then tar.gz package, .appimage, compiling from source on that order. I only use flatpak as last resort.
My first experience with snap was rather frustrating.
The application kept failing to read the config file I provided without telling me why. After reading up it turns out snap can only read from the users home directory (and mounts, I think).
Fine, frustrating but I vaguely understand it. So I move my config to the home directory. Still the same issue with no explanation.
Finally it turns out it can’t read dot files or dot directories even inside the home directory.
Again, that’s understandable but it was an incredibly frustrating, unintuitive experience. Vastly different than the Linux experience I was accustomed to.
Don’t really like Snap since it uses my system ram whenever I boot up my os.
As for Flatpak, its been a great experience for me so far.
