[eatonphil]

Off topic but prompted because Fedora and Ubuntu sites keep pushing in this direction... Do you use snap or flatpak? Preferring not to learn a new technology in this space, I've stuck with apt-get and dnf. I guess the dichotomy is that snap/flatpak are for (desktop) applications whereas the system package managers are more for system packages? Neither flatpak or snap seem very common outside of desktop environments (i.e. server deploys or Docker environments).

Curious to hear from others about your experience with either flatpak or snap.

[kiryin]

First off, do yourself a favor and avoid snap like plague. It's vendor lock-in and horrible.

I use flatpak precisely as you describe. It's for graphical desktop applications, "apps", basically stuff like Firefox, Libreoffice etc. Sandboxing is cool but I mostly do this because the flatpaks are always up to date with respect to upstream, instead of locked into a particular version like in the system repos. I also recently ran into a situation where a particular application wasn't feasibly packageable by the distribution because of unorthodox dependecy choices (and their own, rather strict rules related to packaging), yet they made a flatpak available.

I also like the fact that the applications and their files are isolated in their respective directories, which makes purging unused stuff easy, as opposed to traditionally packaged software pooping all over my home directory.

Running stuff from the command line is a pain, thus why, at least in my use, it's limited to graphical desktop stuff that I'd anyway run by clicking on an icon.

[ajvs]

You can only connect to one Snap repo at a time (which is by default the proprietary Snap Store), unlike Flatpak which supports multiple backends simultaneously.

Canonical is being very sneaky with their promotion of Snaps, with some packages such as Chromium when installed with `apt install` actually installs both Snap and the Snap version of Chromium.

For these reasons I avoid Snaps completely and I have no issues with Flatpak.

[galgalesh]

Note that the chromium apt package is a transitional package only meant to be used during an upgrade, to migrate existing users. The package is marked as such and the description explains this clearly. Because the package is marked as transitional, it isn't shown in GUIs, it's only installable via the CLI.

The confusion comes mostly from people running the apt command in the CLI without looking at what the package is. There isn't a good way to transition existing users from the deb to the snap during an upgrade without having a transitional package with the same name as the original deb.

[ajvs]

Users shouldn't be "transitioned" to a closed-source app store full stop, no matter how nice it would be for Canonical metrics. Only specifically typing `snap install` should work.

If they don't want to continue making auditable builds for this package then that's fine, but they should also stop knowingly making these disguised Snap installation packages which just leverage the package's popularity to increase Snap usage.

[rlpb]

> If they don't want to continue making auditable builds for this package then that's fine...

You're mistaken if you think this is what is going on. The build is as auditable as any deb. Here's the source repository:

https://code.launchpad.net/~chromium-team/chromium-browser/+...

...and here are the build logs:

https://launchpad.net/~chromium-team/+snap/chromium-snap-fro...

I found these following links from the store listing: https://snapcraft.io/chromium

Snaps are also used to ship proprietary software - just as proprietary debs also exist. You may not be able to find sources or build logs for those - for example if they are built externally and the binary snap builds uploaded to the store directly. So an individual snap maintainer has a choice on where to build a snap and whether to publish sources and build logs or not. But typically Free Software snaps are built on the same infrastructure as Ubuntu itself, and for these, the sources and build logs are available in an equivalent way.

[selivanovp]

I use both. Flatpaks usually slightly faster for desktop apps, and snaps can do what flatpaks can’t- entire stack of technologies inside a single snap (nextcloud server for example). The main benefit of both for consumers is general availability of fresh software no mater what distro you’re using and additional security for the price of slightly less performance and additional storage space.

[aj3]

From the security perspective both snaps and flatpaks are preferable to dep/rpm for browsers, email clients, office suite, document viewers and other stuff that is used to parse untrusted data often (due to [wip] sandboxing and auto update).

Snap packages are better maintained (more often with direct involvement of the app developer) and generally receive updates a bit earlier than flatpak. In both cases you need to pay attention who the app maintainer is and I'd argue that in case of unknown maintaners deb/rpm packages are safer choice.

[SahAssar]

> From the security perspective both snaps and flatpaks are preferable to dep/rpm

Most of the packages still have access to the home directory of the running user, right? The sandboxing almost always seems either configure to be as lax as possible or so strict so that it causes issues. For most desktop linux users if a app has access to their home directory and network access then it already has 99% of interesting things.

[galgalesh]

Snaps have only limited access to your home directory and you can turn it off as a user. They don't have access to hidden folders in your home directory, for example, so they can't access your ssh keys, config and keychain.

Flatpaks are more an "all-or-nothing" approach. Either the app is in a tight sandbox and uses portals to access things like the camera or it has almost complete access to your os. Since portals are a new API which requires app rewrite, most Flatpaks are not sandboxed.

[raffraffraff]

Also AppImage. I hate them all. It's just lazy developers who won't package their software for each distro. In fairness I get it - that's a lot of CD pipelines. But it really is a second rate experience for the user, compared to a properly packaged app in a repo, which you can install or update with a single command, and which properly integrates with the desktop and doesn't create a bazillion weird mounts.

[emptysongglass]

AppImages are great, I don't know what you're talking about. And they can be easily integrated into a desktop with appimaged, which is what I use to auto-integrate Mochi, Radicle and Lens.

[raffraffraff]

I disagree. Maybe it seems great if you're used to Windows or Mac, where it has always been normal to download files from 50 different websites and run them. No GPG keys, no trust, just run it. I've been using xubuntu for years, and have gotten used to having the command 'apt-get install <whatever>' install an app that integrate with the desktop by default, and a single command to upgrade all of my shit. Suddenly, because application packaging is old and boring, I have to care about some file I'm downloading and from some website. And then I have to install some other hack to properly integrate "images" into my desktop (which doesn't always work, so you create an issue on the hack project and the maintainer bitches about 'badly made AppImages') ...

Next thing you'll be telling me that I should be installing antivirus to make sure the plethora of downloaded files don't contain malware.

And if I don't bookmark all the sites where I'm supposed to get these images, I have to hunt them all down again. And if I don't bother doing that I'm running old versions of everything.

Screw all of that and give me my apt-get install / upgrade.

For the two AppImages I am forced to use, I actually ended up writing a bash script to download them, mount them and build a .deb file that does the desktop integration. Then I push the .deb to my own repo, so apt-get install/upgrade works across all my machines again.

[anuragsoni]

Snap can install non-desktop applications just fine. I've only ever seen Flatpak for desktop apps, but I use snap for installing things like docker, lxd etc.

[capableweb]

Isn't the entire point of snaps (and flatpaks?) technology that it's isolated? So the application won't be able to do whatever to your computer. But docker, lxd and similar usually requires root permissions to run, and access to bunch of sockets and what not.

[selivanovp]

Isolation is optional and you can tune it to your needs.

[simion314]

Yes, I used snap on server, I think the package was pdftk , worked great the only issue it might be is that is configured to only have access to the home folder.

Snap is a good solution if there is no alternative in the repositories or the one there is too old.

[ufo]

This is what I do for the desktop apps for my home desktop:

If a package is in the Fedora repository, I favor getting it from there. If it is not, my first choice is a flatpak from Flathub. I find it much less painful than downloading RPM packages (which aren't always provided and also don't automatically update) or adding a bunch of third party repositories like PPAs (which have a tendency to cause dependency hell if there are too many of them).

The main exception is the RPMFusion third-party repository. If something is in RPMFusion I get it from there instead of trying the flatpak. (Examples include Steam and FFmpeg)

[padraic7a]

I use Ubuntu on the desktop, have a few snaps installed and a couple if flatpaks. Both seem fine in my limited usage.

Snaps are also available for servers and IOT devices. AFAIK the popular EFF Certbot is only distributed via snap for example.

[mathfailure]

AppImage. And I aggressively cut snap away.

[rjzzleep]

I use neither, I tried to use both, but my main driver is a latop and even though I have a 1TB SSD I consider this to be eating a significant portion of my disk space. electron apps already are disk hungry enough on their own.

[galgalesh]

Note that, because snaps are stored compressed on disk, many snaps are smaller on disk than their regular package counterpart. Take the chromium package as an example.

However, a bunch of snaps are full of unused libraries because a bunch of packagers use a shotgun approach to including libraries. I've seen a bunch of snaps which contain the entire build environment for the app itself, for example. After cleanup, such snaps are often only 1/3 of the original size.

Because many snaps are created by app devs themselves, they don't all have the same quality as packages from the debian repository.

[daitangio]

No sorry, and for good reason: https://gioorgi.com/2021/ubuntu-20-failed-me/

Snap update package without control and it is not open source…