[quotemstr]

Moving to Snaps gets us to a world of sandboxed applications, defined permissions, and OS version independence. That's the world that exists on mobile, and it's pretty great. Shouldn't desktop learn from mobile's successful experiment in sandboxing?

[jeroenhd]

They should, that's why Flatpak is excellent for wide-spread, cross-distro software support.

Snap is a slightly worse, proprietary sandboxing mechanism pushed by Canonical, the people making money off it. It has some fundamental problems (boot being slowed down by all the snaps being mounted, for example, Firefox acting weird and sometimes not even launching until I reboot since 22.04) and some ideological problems (the fact you can't host your own snap store without paying Canonical, the fact Snap blatantly refuses to follow standards like XDG or even just folder naming in the home directories, forcing a lowercase "snap" folder on everyone).

Some people are against the appification that's taking a toll on user freedom. Some people are in favour of the excellent permission monitoring and dependency conflict resolution it allows. Both sides seem to conclude that snap isn't the right answer.

[rnk]

This thread is a perfect example of why we don't have clarity on what kind of distribution management we should have. We had:

1. Tar files of compressed binaries 2. No use your release's package manager 3. No, snaps 4. No you fool, flatpak is the superior solution. 5. I'll just finish this off by saying distributing source code is the obviously best way, you posers.

[jeroenhd]

Nobody knows what kind of management we should have. Some people prefer directly distributing executables (AppImage). Some people prefer packages like Android/iOS (Flatpak). Some people prefer compressed files with installer scripts, like Microsoft's MSI files (.deb/.rpm). Some people prefer just a flat folder with binaries they can plonk down anywhere.

I personally prefer the distro-based approach, but for tools that need to be kept up to date independently of the rest of the system I'm a Flatpak fan.

People, collectives, and companies have preferences. There is no one single way.

In a similar vein, how do I distribute Windows software? Do I put it up on the Microsoft store, do I provide a download with instructions for my msix file or is appx more suitable for my use case? Do I add a compatibility layer for .exe to sacrifice the security sandboxing brings to make the file nice and clickable? Or do I use .msi to use the system UI that's easy to set up (but impossible to navigate for computer illiterate people). Or wait, maybe Steam and Epic Launcher are a better fit? Hell, maybe I can get away with uploading the APK to the Amazon App Store so I can target Android and Windows 11 in one go!

What about macOS? Mac Store, .dmg disk image, simple .zip file, or maybe a self-extracting installer? Do I need to include one of those weird screens that tells the user to drag an icon into a picture of a folder? That's what a lot of third party software had me do when I first tried it, though it took me a while to understand what it was asking of me!

Or is it better to use Brew/WinGet? It doesn't have the GUI, but it allows serious people to set up my software exactly how they like it.

[iggldiggl]

> That's the world that exists on mobile, and it's pretty great.

No, it's not. Unless you do some weird hacks that aren't officially guaranteed to work (and now that the old READ_EXTERNAL_STORAGE permission has been fully deprecated, don't result in the most natural UX flow, either), Google's sandboxing on Android has e.g. broken the scenario of using a file manager to open a locally stored HTML file in a browser, because following the official API, the browser won't be able to resolve any relative links to other HTML documents or subresources like images/stylesheets/scripts.

Other multi-file file formats are similarly broken, and this more or less applies to all the sandboxing solutions I'm aware of, no matter whether Android, iOS, Windows, Mac or Linux. The only exception I'm aware of is that the macOS desktop sandboxing has some provisions for handling "related" files that only differ in the file extension, but even that of course doesn't handle all scenarios – the aforementioned HTML file example still wouldn't work for example.

[Tainnor]

The problems with snaps are in the execution.

The startup times are ridiculously slow (multiple seconds or even worse) at least on some machines (I've only ever experienced them to be sluggish, but some people say the opposite, so...) and this is particularly egregious for e.g. firefox or a password manager (bitwarden).

Because I just couldn't bear it anymore I uninstalled the firefox snap and installed the flatpak instead. Flatpak solves similar problems, but doesn't seem to be as sluggish, at least for the applications I've used.

[oldjavacoder]

Also multiple gigabytes of space in /snap and not knowing when or why an app is updating or what it will do to the machine.

[quotemstr]

> The startup times are ridiculously slow (multiple seconds or even worse) at least on some machines

I agree that the implementation could be much improved. In particular, I'd like to see a switch to EROFS images.

[pleb_nz]

As per other commenters, it's the execution and implementatiin of snaps that i'm not a fan of, not the idea.

[oldjavacoder]

I have no interest in snaps, flatpak or appimage. I can't stop my phone's apps from updating whenever they feel like it without breaking many of them. I can and do control software installations on my machines.

[Normille]

  >I can't stop my phone's apps from updating whenever they feel like it

If you're on Android

Play Store > Settings > Network Preferences > Auto Update Apps...

You can also set the option to not update automatically on individual apps. When they show up in the Updates Available tab, click the hamburger menu next to one and there's an option to turn off auto-updates. Handy to stop YouTube automatically updating and wiping YouTube Vanced!

[nijave]

Flatpak seems a little less finicky but slightly less user friendly (you manage your own repos/sources)