Too be exact. Snap packages are slow. I can use unstable application. But slower is a nightmare! headache.
For quick ref: vlc. I can wait for application to completely open!. But
when seeking using arrow frames are slow to render in snap. but its normal in deb. On website vlc said they don’t maintain vlc deb as snap. Snap is more likely to receive updates.
As was noted above a few times already, 95% (if not 99%) Ubuntu users never care about updates and will also not look for tracks or channels (they will just use the default and will get silently updated to not have security holes) … you as a power user can use tracks if you want though …
On whom else but the creator would you like to rely for judging if a bug or security hole in an app requires an update ?
They are the experts for this software after all…
On whom else but the creator would you like to rely for judging if a bug or security hole in an app requires an update ?
I would like to get the information from the vendor and decide for myself if the risk of an update justifies the benefit for my own use-case.
Vendors are not obligated to provide this information but ultimately it should be up to me to decide if I want to take this risk or not.
Not sure what you mean, i run the VLC snap on 4 machines here and they all are capable of playing 1080p video at 60fps, i dont even notice slowness with 4k videos on the systems that have a 4k capable display …
I have the deb installed alongside on one machine and things like right clicking in a playing video seems to bring up the context menu at the same speed in both, I do not see any slowness … did you consider filing an issue about it ?
There is some slowness in the first launch, of course, but it’s quite reasonable these days. Other than that I’ve never felt any snap as being slower than its deb counterpart. And there is little technical reason to expect that to be otherwise. “A nightmare” sounds over the top. If you have a concrete problem you should file a bug, but nightmarishly slow is not a general problem of snaps.
Judging by the maintenance snap-store has already been abandoned. These bugs are been open for months.
While I wouldn’t say it so aggressively, I believe it’s true that it has its share of apparently unattended bugs which, often unfairly, contribute in a negative way to the reputation of Snap in general (even omgubuntu has recently posted about it). I say “often unfairly” because many of these bugs are inherited from Gnome Software (again, the aforementioned post in omgubuntu is an example of this), which is not particularly known because of being bug free or very actively maintained. Moreover, I say “often unfairly” because these frontend bugs are irrationally projected to the entire Snap stack. That said, it’s the decision to fork Gnome Software that has led to this situation, so there is a grain of truth in your statements and I often feel that Snap Store should get more love or, otherwise, return to upstream.
Very impressive: You take randomly two bug reports and know everything about the development and maintenance of a software?
I don’t know much about desktop environment much. But i use a low end laptop with 4 GB of RAM.
When i click on vlc (.deb) its open in 2-3 seconds. But when i click on vlc (snap) it takes about 10-12 seconds to open. Same with inkscape and other snap apps. After opening it works upto the mark but still little slower than deb. I think on high end desktop snap packages matches the speed with deb.
Beside this rant. snap packages are good they just install and uninstall in cleaner way than deb (apt).
regarding the startup time for cold starts of snap apps:
i dont see how an app (of the exact same version and with the exact same code) that already is in ram could behave any slower at runtime than a differently packaged one though …
if there is a noticeable slowness there is likely a packaging bug that should be fixed by the packager or the versions are not identical and you see code regressions …
I tell you my own experience.
First:
Results:
Global issues:
Thanks for pointing that out. Printing isn’t working because the interface isn’t connected by default, you can do that from the snap-store (search for thunderbird and click on the permissions button) or from the GNOME settings. It would make sense to it connected by default, which is requested now
What’s the issue with attachments handling? is that the default handler choice issue which had been discussed in some other comments?
Nothing new for you, just the bug I filled some time ago (and workarounded it following the FF snap connections list), following your recommendations. 
Note that I do not experience any slowdowns running snap vs deb, except the first launch.
The user experience with snaps is not fully satisfying (let’s forget this first launch delay) mainly imho because of this confinement. Again another example, I installed JupyterLab through pipenv, created manually a terminal launcher buuuuuut:
Well, I stop talking snaps in snap store thread. Sorry for that.
That’s quite strange. In GNOME Control Center, Firefox snap permissions:
(access to home folder)
Apart from that, I noticed a display bug 
:
Well, these are certainly very good news, even considering the increase in size of the package from 150MB to 250MB:
nope, not really … but it is great to see
Increase in size doesn’t matter. If speed is good.
Hope this speed improvement works.
don’t forget that snaps were initially designed for embedded and IoT systems back in 2014 … on some hardware size does actually matter (but i heard long term the compression algorithm will be selectable)
