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?
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.
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.
I like the user experience of two clicks to install and run, it’s feels very smooth.
I had some bugs with the CLI when developing Flatpak applications, but I guess that will be resolved when it gets more refined. I also welcome a central “linux appstore” and more sandboxing features, so my view on Flatpak is that I like it more than most other solutions.
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.
I like Flatpak in general and it might be the future™ but I hate how huge the packages are
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.
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.
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.
Flatpak’s the only one I’ve had good experiences with. Tangentially related, but I especially dislike AppImages. I’m not a fan of how bulky installing various flatpaks ends up being and use native packages or the AUR usually, but beyond that they’re really convenient for non-critical applications that otherwise would mesh poorly with my distro or aren’t available there. Friend of mine tells me it’s also a nice system to package Windows applications/games with a preconfigured Wine version.
I use both on gentoo for some obscure or proprietary stuff that is not packaged in portage, like filebot, authy desktop, discord, steam and foobar2000 (including wine in 1 bundle to avoid dependencies and switching all portage packages to 32bit abi). It works well and opens me up to loads of stuff. It’s freedom in some way.
Snap or flatpak makes no difference to me, they’re just different backends for kde discover
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.
Every snap i’ve ever downloaded has been ridiculously slow
my mirst contact with snap was while trying to instal lubuntu to some old laptop, and was confused why Firefox too minutes to start.
If you want me to use something - better make it better than original thing. This was terrible experience, I needed some time to disable it and find a way to installed real package.
And don’t hide it from me. And let me choose.
So I don’t like it, I don’t care about technical advantages, if there are any, I will not use it because someone forced it upon me. o can not support such behavior.
Flatpaks are too big. And most packages I wanted have serious bugs. And I never found how to change font size in those apps.
AppImage is great, I use it for gimp, inkscape, libreoffice and some other software packages I rarely use. but they don’t have official repository, so I will not take binaries from some random people on the net. nor use google as my package manager.
I tend to use native packages. However, I find Flatpak very useful to avoid large list of dependencies, specially when Wine is involved.