Is ubuntu-software going to be remove for snap:snap-store?

The recently mentioned issue happened because the stable channel used for Ubuntu expired, which made the snap fallback to the stable serie but that’s another codebase which doesn’t include the ubuntu branding and the deb support. The proper channel has been restore and things should be back to normal after the next refresh (those who switched channel to beta might want to go back to stable/ubuntu- instead)

5 Likes

Indeed it was that, the team promptly responded and both issues mentioned above (inability to install deb files and lack of source selector) are fixed now. Thanks!

1 Like

There is a difference between “not easily turned off”, and “not even providing a proper command line to turn it off”.

I switched to Ubuntu from Windows precisely BECAUSE of Microsoft paternalistic approach.
I don’t mind what the defaults are, but I want the ability to change them.
It is my computer and therefore MY decision.

I can understand that Ubuntu is trying to address the needs of the lowest common denominator, but the system is so far from being suitable for the average Windows or Mac user on so much basic stuff, that I would think alienating the core user base by taking away their control like Microsoft, Google, and Apple do - is very, very wrong.

I was initially excited about the concept of Snaps. It seemed like a more secure way to install software, and I didn’t mind the performance hit if it allowed me to sandbox third-parties with the permissions I was willing to give them. This perception has now changed by 180 degrees.

For example, I use JetBrains’ IDEs. Every single new version release causes some regressions. Because of that, I upgrade their software once in 6 to 12 months, or when there’s a new feature I actually need. It’s not an OS and not a browser. I don’t think it’s insecure for me to upgrade it pretty rarely. But with Snaps - I no longer have the option to decide. I am forced to swallow whatever regressions are presented in the new version, for the supposed “security” that I don’t need.

This is extremely disappointing to me and if Ubuntu continues with the paternal approach then I will have to look elsewhere. I have spent a lot of effort and time on migrating from Windows to Linux and it’s very frustrating to find that it may have been done in vain.

which is exactly why there are tracks and channels for snap packages:

$ snap info intellij-idea-ultimate
name:      intellij-idea-ultimate
summary:   Capable & Ergonomic Java IDE for Enterprise, Web & Mobile Development
publisher: jetbrains✓
[...]
channels:
  latest/stable:    2020.2.3   2020-10-06 (253) 755MB classic
  latest/candidate: 2020.2.3   2020-10-06 (253) 755MB classic
  latest/beta:      2020.2.3   2020-10-06 (253) 755MB classic
  latest/edge:      2020.3-EAP 2020-10-15 (255) 809MB classic
  2020.3/stable:    –                                 
  2020.3/candidate: –                                 
  2020.3/beta:      –                                 
  2020.3/edge:      2020.3-EAP 2020-10-15 (255) 809MB classic
  2020.2/stable:    2020.2.3   2020-10-06 (253) 755MB classic
  2020.2/candidate: 2020.2.3   2020-10-06 (253) 755MB classic
  2020.2/beta:      2020.2.3   2020-10-06 (253) 755MB classic
  2020.2/edge:      2020.2.3   2020-10-06 (253) 755MB classic
  2020.1/stable:    2020.1.4   2020-07-22 (240) 734MB classic
  2020.1/candidate: 2020.1.4   2020-07-22 (240) 734MB classic
  2020.1/beta:      2020.1.4   2020-07-22 (240) 734MB classic
  2020.1/edge:      2020.1.4   2020-07-22 (240) 734MB classic
  2019.3/stable:    2019.3.5   2020-05-06 (223) 763MB classic
  2019.3/candidate: 2019.3.5   2020-05-06 (223) 763MB classic
  2019.3/beta:      2019.3.5   2020-05-06 (223) 763MB classic
  2019.3/edge:      2019.3.5   2020-05-06 (223) 763MB classic
  2019.2/stable:    2019.2.4   2019-10-29 (181) 765MB classic
  2019.2/candidate: 2019.2.4   2019-10-29 (181) 765MB classic
  2019.2/beta:      2019.2.4   2019-10-29 (181) 765MB classic
  2019.2/edge:      2019.2.4   2019-10-29 (181) 765MB classic
  2019.1/stable:    2019.1.4   2019-07-30 (160) 650MB classic
  2019.1/candidate: ↑                                 
  2019.1/beta:      ↑                                 
  2019.1/edge:      ↑                                 
  2018.3/stable:    2018.3.6   2019-03-26 (132) 631MB classic
  2018.3/candidate: ↑                                 
  2018.3/beta:      ↑                                 
  2018.3/edge:      ↑                                 
  2018.2/stable:    2018.2.8   2019-04-03 (135) 598MB classic
  2018.2/candidate: ↑                                 
  2018.2/beta:      ↑                                 
  2018.2/edge:      ↑                                 
  2018.1/stable:    2018.1.8   2019-04-04 (136) 612MB classic
  2018.1/candidate: ↑                                 
  2018.1/beta:      ↑                                 
  2018.1/edge:      ↑                                 
  2017.3/stable:    2017.3.7   2019-04-10 (138) 529MB classic
  2017.3/candidate: ↑                                 
  2017.3/beta:      ↑                                 
  2017.3/edge:      ↑                                 
$

just pick the track you want here and you wont be bothered with updates unless the jetbrains guys consider they must update you to fix something really serious (like a security issue or crasher bug) …

note that this is not a “paternal approach” but a “give the update control fully to upstream developers” consequently implemented …

1 Like

Thank you for the suggestions.

However, this was just an example, and my point remains.

  1. I should not be expected to investigate the distribution channels and policies of every software of every vendor that I have in order to prevent stuff from automatically being downloaded and installed on my computer.

  2. I should not be expected to depend on a vendor’s decision on what should or should not be pushed to users’ machines in this or that channel.

Please note that I also see this forced auto-updates requirement as a security issue.
The fact that I trust a software or a vendor enough to install a program at a given point in time DOES NOT mean that I trust anything this vendor will publish from now on.

In short: any automatic installation of software on my device without my explicit consent is a violation of my trust and my rights (as I perceive them).

Especially when we’re talking about just any arbitrary software, and not specifically about browsers or OS components with relatively broad surfaces for attack.

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…

1 Like

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 ?

3 Likes

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.

5 Likes

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.

2 Likes

Very impressive: You take randomly two bug reports and know everything about the development and maintenance of a software?

1 Like

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 …

2 Likes

I tell you my own experience.

First:

  • to get the latest 78 Thunderbird version (deb version is very outdated, not even the latest 68.x subversion), I used groovy deb then (for dependencies issues that finally appeared some time ago) I decided to install the snap version; so I installed again snapd
  • I decided to keep a core/Gnome all from Ubuntu deb repository
  • I installed my favorites apps with snap versions (FF, LO, VLC, GIMP)

Results:

  • I’m quite happy
  • imho having a stable deb base system and installing snap for other softwares is a good point (maybe it recalls me some other well known OS?)
  • good point to have the ability to easily change a snap’s channel

Global issues:

  • (very) slow first start (happy to get some future compression improvements!) with my NVMe
  • confinement limitations (printers in TB, TB attachments handling, FF access to local files, …)
  • not really an issue but I miss some snap packages (SageMath, JupyterLab, TexStudio, R stack, …) to have a complete snapped environment
  • still very poor font rendering in Wayland (I use Roboto 11)
    image
  • poor Snap Store experience, clearly looks under-maintained (with respect to those who do that), e.g.:
    image
    waiting a looooong time to populate and getting a Display menu with only one item,
    numerous display issues:
    image
    still getting duplicates that make my new-in-Ubuntu friends quite skeptical:
  • Snap Store shows an update tab that is quite surprising because it includes some (buggy at the moment) firmware updates, not snap-related:
    image
  • Snap Store does not offer a “recent changes” nor displays auto-updates done (so I made some intermediate effort between Snap Store and terminal commands with the simple https://extensions.gnome.org/extension/3715/snap-manager )

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. :slight_smile:

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:


access to file denied in Firefox snap and same “issue” running Chromium snap:
image
I have to ctrl-click on localhost url to access JupLab:
image
Well, confinement is good for security but bad for (mainly beginning) user experience. Clearly imho here snaps are lot behind deb for user experience.

Well, I stop talking snaps in snap store thread. Sorry for that. :slight_smile:

That’s quite strange. In GNOME Control Center, Firefox snap permissions:

image
(access to home folder)

Apart from that, I noticed a display bug :wink: :

image

1 Like

Well, these are certainly very good news, even considering the increase in size of the package from 150MB to 250MB:

  • The use of the LZO compression offers 40-74% cold startup improvements over the XZ compression.
  • On the Kubuntu 18.04 system, which still has Chromium available as a DEB package, the LZO-compressed snap now offers near-identical startup performance!
  • On Fedora 32 Workstation, the LZO-compressed snap cold startup is faster than the RPM package by a rather respectable 33% (actual ~5.0 seconds difference).
1 Like