Canonical call for testing their Steam gaming Snap for Arm Linux

Quoting: StellaSnap needs to just die imo. Flatpak is the future! 😇

While I agree that Snap needs to die, it's important to mention that Flatpak is also guilty of re-inventing the wheel. AppImages existed a whole 10 years before both Flatpak and Snap. They could've contributed to AppImage rather than reinventing the wheel and fragment the ecosystem.

Snaps = non-free (proprietary) file format belonging to Canonical

=> No thanks, I don't want it on my operating systems

I don't like using AppImage either, it's too cumbersome to use for launching applications and there's no built-in application update system.

The only format of this type that I occasionally use is Flatpak, and only if the package authors are known and verified, and their packages are therefore safe and secure.

Last edited by phil995511 on 11 Jan 2026 at 12:04 pm UTC

Quoting: phil995511Snaps = non-free (proprietary) file format belonging to Canonical

=> No thanks, I don't want it on my operating systems

But... you don't have snaps on your operating system? Unless you're using Ubuntu? So it's not "no thanks", it's literally "this doesn't affect me in any way". So why the negativity?

And it's proprietary? So what? Or do you not use Steam, in which case, fine, I guess you're on Debian on the whole Richard Stallman philosophy, which is kind of admirable, but definitely not for me.

But hating on snaps because they're proprietary, and not hating on flatpaks where anyone can upload a dodgy flatpak to flathub feels really disingenuous to me. Even the fact that flatpak can be run from sources other than flathub... for 99.99% of flatpak users out there, that's irrelevant, because that's where flatpaks are hosted. It might as well be proprietary, because no-one is using it in any other way.

Quoting: scaine

Quoting: phil995511Snaps = non-free (proprietary) file format belonging to Canonical

=> No thanks, I don't want it on my operating systems

But... you don't have snaps on your operating system? Unless you're using Ubuntu? So it's not "no thanks", it's literally "this doesn't affect me in any way". So why the negativity?

I don't want to quote everything again, but it's a good comment.

I use (X)ubuntu and like the fact that I can use both Snap and Flatpak. It is also possible to switch Snap packages back to normal package management. I have already done this when there were problems with Snap packages (e.g. Firefox).

Of course, it's not the "canonical" idea to use Ubuntu and then remove Snap completely. In that case, it's better to use a different distribution.

And this freedom is what we love so much about Linux. Every person is different and has their own needs and preferences. And even as a long-time Linux user, you get a bit lazy with age. ;)

Quoting: rea987Yup, Firefox gargled by snap issue is what forced me to quit Ubuntu and migrate to Debian couple months ago. The issue might be fixed for the latest versions of Ubuntu but it still was there for 24.04 LTS release.

I didn't have problems with snap Firefox startup on 24.04 LTS and I upgraded in October to Ubuntu 25.10 and it still starts fast.

Also when I installed Strawberry music player snap and started it for the first time, there was a warning popup that it might be slow (and so on) because it is installed as a snap package. It isn't packaged as snap by the developer of the program, but I am certain that the warning is from the developer. And gues what I can't tell a difference beetween the .deb install of Strawberry and the snap one.

All that stuff about Steam and Arm got me thinking... SteamOS on rpi for light gaming and emulation purpose... Sounds like something I will be willing to try. 🤔

Quoting: phil995511Snaps = non-free (proprietary) file format belonging to Canonical

That's BS. But if it gives you the opportunity to complain about something you apparently not even use - why not? For others: Snap is ofc open source. What is proprietary is the backend for Snap distribution. But even so you could implement your very own backend.
Years ago Alan Pope explained the why:

https://www.youtube.com/watch?v=x8MgktKqjsU

Quoting: phil995511I don't like using AppImage either, it's too cumbersome to use for launching applications and there's no built-in application update system.

FALSE. Been a while since you've looked at AppImage, I'm guessing? Most modern AppImage files are shipping with built-in update support (0 A.D. For example). There are two ways that I'm aware of to get AppImage updating these days. One is the official [AppImageUpdate](https://github.com/AppImageCommunity/AppImageUpdate) (which is distributed via an AppImage and can also update itself). This is still considered to be in beta. The other is to use [AM / AppMan (AppImage Package Manager)](https://github.com/ivan-hc/AM).

AM is a command line tool that aims to be the "APT" of AppImages. This tool also offers the choice to use "AppMan", a portable version of "AM", limited to installing and managing apps only locally and without root privileges. It is quite extensive & powerful: installs, integrates, updates and uninstalls, utilizing a main database registry. The user can assign their own folders and integrate via the launch parameter.

It is even possible to sandbox your AppImages, if you crave that flatpak experience (I don't). Read [this](https://appimage.github.io/AppImageUpdate/) to update your knowledge of the state of AppImage updating and AppImages in general.

I don't get that old saw that AppImages are too cumbersome to use for launching applications. Simply right click on the file, select properties, go to the permissions tab and check the "run as executive" box. Not hard at all. If you want it integrated into the DE's menu, do it manually or install AM / AppMan, AppImagelauncher, Gear-Lever (I recommend the [unofficial AppImage version](https://github.com/pkgforge-dev/Gear-Lever-AppImage)) or even the very basic appimaged.

Last edited by Caldathras on 11 Jan 2026 at 6:45 pm UTC

Quoting: dziadulewiczWhat are you ppl up there talking about? Nothing needs to die, snap and flatpak are also very different. Both have their place and more. This is important. Everything is important to get to work correctly and well on Linux and we should support Canonical on this effort!

I'm with @dziadulewicz on this. The objections to Snap seem idealogical and polarized rather than practical. There doesn't have to be one solution to the packaging "problem". In fact, it is more resilient if there isn't. Use the solution that works best for you and leave it to others to make their own choice.

Personally, I find the design of flatpaks to be complicated and wasteful of system resources. Storage is at a premium on my systems. The sandboxing, well laudable, is quite annoying when you want to integrate the app into your system. It is like you are running two operating systems instead of one.

AppImages, on the other hand, are all contained in one file. You mark it as executable and run it. If you want to sandbox it, you can. There are several excellent tools to manage integration and updating too. Personally, I prefer to control my updating and download and replace the files by hand. You can place the AppImage file wherever you want. It doesn't have to be in the file system partition at all. AppImages are intuitive and very simple to use.

I have no experience with Snaps, as I don't use a distribution they ship with. I cannot comment, as they do not effect me (:winks: at @scaine).

Last edited by Caldathras on 11 Jan 2026 at 7:10 pm UTC

Snap? Uh, no. No thanks.

don't we want more choice in computing, whatever the platform ?