Is Snap really so terrible?

[Tom_ZeCat]

It seems like the various *buntu flavors have taken some heat over Canonical's embracing of Snap as its main installer (see video at end). As far as I can tell, everything I've installed via Snap runs okay. (You can list all your Snap installs on the command line with: list snap.) Some pundits sing the praises of Flatpak, but I have had at least a few problems with that technology. In at least one Flatpak install, the app didn't inherit my Kubuntu's look and feel settings. It did its own thing. It's a long story, but I have two LibreOffice installs, neither of which is the distro's original install. I had some problems with the original, and so I purged it and then reinstalled via the command line. I also have a Flatpak install of LO. I use the Flatpak one for my daily work-from-home job, and the command line one for everything else. I do notice that the Flatpak one runs more slowly.

That's the complaint by the guy in the video. He claims that all the Snap installs run slower than they should. If Snap really is so terrible, I could conceivably just get rid of it and stay with Kubuntu. I could uninstall every Snap-based install and reinstall via other means, and then uninstall Snap itself. Would it actually be worth it, however? To me it doesn't seem that Flatpak installs perform any better. Am I wrong? It's also possible to avoid both Snap and Flatpak, but that would place big limitations on your system. In some cases, Flatpak may be the only way to install something.

Some users have Snap-purged their *buntu; others have even switched distros. Do they have a point? Or is the Snap-bashing over-hyped?

I do notice that my system takes way longer to boot up than I would prefer, but up until now I've considered it a hardware problem, and that I should finally get on board with a solid state drive.

Thoughts?

https://youtu.be/pMfqCzbSmQU

Notes:
You can list all your Snap installs on the command line like this:
snap list

All the Flatpak ones can be listed like this:
flatpak list --app

Finally, list all the Apt installs like this:
apt list --installed

[MoonRise]

I'll bite.

So, here I was going down the same road of bashing it. I still really do not prefer it and all explain shortly.

As far as my boot up time I see no difference there caused by all the Loop attachments. I see those mounts more low level and systems should be able to do those mounts relatively easily and quickly. Those happen on many other system needs as well. I could be wrong, but none of my systems I've upgraded has suffered boot wise.

The arguments I've heard about introducing spyware is a non-subject to me as well. Why? Just about any software you install one way or the other can suffer from that. It would be up to the larger communities to keep all of that in check. I'm sure straight software installs, SNAP, and FlatPak are all scrutinized by someone.

Now to my main point of why I really do not prefer SNAP. On all of my machines that I have SNAP on with Firefox ALL are slow to start FireFox and even when browsing there is slowness. And it has nothing to do with the machine, my ISP or any of that. It is SNAP. How do I know? Well, I have this control PC here that runs current NEON of which has yet to move to that new base. It isn't a fantastical machine either. It boots as I would expect and is comparable to my other machines that have been updated. It is at the FireFox level that I've noticed the issues and all SNAP based installs are problematic. Anyone to argue otherwise is Head-in-the-Sand attitude. Just admit it and state "it is being worked on, we know". At least for me that is all I would need to hear IF they were actually trying to fix that issue. I've done my studies.

Though I keep hearing this is FireFox's decision to SNAP it. Not sure how much I believe that but I'll continue to study and test.

As far as other SNAP items, I cannot say. I try not to go that route due to the slowness I do see out of SNAP FireFox.

EOF

[claydoh]

It is mostly politically and ethically motivated, with legit, but probably solvable technical issues thrown in.
Canonical = bad, usually
But not without some legitimate reasons
The servers for the software packages ARE closed, and controlled by Canonical.

On the other hand, it is perfectly OK for RedHat to more or less force its desired stuff into the Linux ecosphere. Systemd, pulseaudio, etc. Wayland and Flatpak, even, if you squint a tiny bit and see Freedesktop as an extension of Red Hat/Gnome.

[MoonRise]

It is mostly politically and ethically motivated, with legit, but probably solvable technical issues thrown in.
.

Absolutely!!

[kenj70]

Late to the party......

My system with an nVME drive performs very well. I have a SNAP for Chromium and Brave and they seem to perform OK. A while back I installed a SNAP for LibreOffice and it was .dog.slow! I would click on an option or type and the response was very noticeably delayed. My preferred install is the AppImage and I was able to find an AppImage for it that was slightly older. Now ,everything is "snappy" again.

-=Ken=-

[kenj70]

Not sure where to post this. So, I'll just revive this thread again.

I just finished putting together a new backup routine and got to looking at the folder structure and file sizes/numbers. I stumbled on the fact that the snap folder contains a huge amount of folders and files! I only have Chromium and Brave installed as Snaps but each of those folders contains over a gigabyte of files and thousands of folders. What are they doing with all those hidden folders and files anyway? It doesn't look like my two snaps are installed in the snap folder but there is voluminous configuration information stored there. A casual search shows little discussion on this. Does anyone know what is going on?

[jlittle]

Most of the folders in /snap are squashfs, so the sizes you see in /snap are not the space taken up in storage. Compare:

$ sudo du -hs /snap /var/lib/snapd
5.1G /snap
2.2G /var/lib/snapd​

Still undesirably large, but comparable to flatpaks and appimages.

[kenj70]

Are you saying the linux file system doesn't report the true storage space for squashfs files?

With all that overhead code it seems like they could sneak some unwanted apps in there, especially if many people don't even know about the hidden folders/files! I always wonder if the Chromium devs are doing something sneaky.

[GreyGeek]

Questions: How often do you run muon? Once a month? A week? A day?
Would you leave muon open all the time even though you might use it once a day for 5 minutes, or less, to check for updates? Of course not. It would be a waste of CPU cycles and memory. Muon doesn't need to be open all the time.

Snapd runs all the time as a process even though you may not use Discover more than 5 minutes a day, or a week. So, what is snapd doing the other 11 hours and 55 minutes (assuming you have your computer on 12 hrs/day) when you aren't browsing Discover or using it to install or remove an app?
Nothing else? If so, why keep it running? Canonical's store is proprietary and closed source. It's what snapd communicates with. The only things it needs to know about your system is what apps you have installed, and which apps you want to install or uninstall. Muon does that without have to be running all the time. So, what else is snapd doing? You could say nothing, but you have nothing on which to base that opinion, and I can't prove that snapd is doing anything more than just talking with Canonical's store with Discover being the GUI.

However, Shuttlesworth used to call Microsoft "bug #1". Canonical has partnered with Microsoft to put Ubuntu ON TOP of the Microsoft kernel as WLS2. It's like driving your Formula One racer while it sets in the bed of a Ford pickup truck. Any experience one would get setting in the Formula One would not match what it would be if the racer were on the road under it own power, but folks giving Ubuntu a "try" in the WLS2 environment would likely pass on using Linux as their main driver.

My preference has always been to base Kubuntu/Neon on another distro, sans snapd. My suspicion is that Canonical will make snapd mandatory and unremovable, and slowly move the best apps in the repository into their store, to be offered at a price. Some developers may love that, but if that happens that is when I'll be moving on.

[kubicle]

Are you saying the linux file system doesn't report the true storage space for squashfs files?

He means that squashfs is a compressed filesystem, it takes less space on disk than the files it contains (because everything is compressed)...sort of like how zip files can "contain" more data than the space it takes on disk.

You could say nothing, but you have nothing on which to base that opinion, and I can't prove that snapd is doing anything more than just talking with Canonical's store with Discover being the GUI.

I believe I've told you this before, but snapd is open source, so you can actually go see what it does. Snapd is not just for retrieving updates from snap store (it does that, too, of course), that's more of an add-on feature. It's primary function is to manage the sandboxes, virtual filesystems and system interactions of snap apps, that's why it needs to run al the time. It's a technical requirement for snap apps to run (snapd is the reason why snap apps are system agnostic, as snapd handles the system interactions on various systems).

---

You shouldn't take this as promotion for snaps, they have their issues both on the technical and political side, and I don't use them on any of my machines. But we don't need to spread vague innuendo on them, that sort of detracts from the actual issues.

[jlittle]

Are you saying the linux file system doesn't report the true storage space for squashfs files?

Well, what is true? I think it does for the files themselves in /var/lib/snapd, but Linux lets file systems have their own rules about what they report. It's like this most notably with copy-on-write file systems; the space a file takes when it may be sharing its contents with many other files is difficult to define. The last time I ran du -s on / I eventually got about 15 TB, all on a 220 GB SSD with 60 GB free.

[kenj70]

I decided to remove the Snap apps and found a conventional install for the Brave browser which actually has cleared up a cut/paste problem with the snap version. I tried replacing Chromium with a repository I found on line, but it has not been maintained. So, I reluctantly installed a Flatpak version of Chromium and found that Google suspended support for the Sync function on anything other than Chrome! My Snap install continued working for a year and a half but once uninstalled Sync is no longer available. Oh, well. I needed an excuse to start moving away from another Google product.

I tried LibreOffice as a Flatpak about six months ago but it was so incredibly slow. I now run the AppImage and it is great. Chromium as Flatpak does not exhibit any slowness so far.

Thanks all for contributing here!

[GreyGeek]

I believe I've told you this before, ...

I don't remember but I'll take your word for it.
Failing memory is only one of the problems associated with being 81. I forget most of the others.
Anyway, perhaps its time to head out to pasture ....

[Snowhog]

Anyway, perhaps its time to head out to pasture ....

Forget about pasture grass. Yes, the grass blades may be sweet, but their roots are tenderer and there are more of them. You'll have eternity to enjoy those when you're planted beneath said pasture.