Linux Mint 20 disables deb2snap packages, and Snap's growing external adoption problem

74

It’s given that snap are a relief for dev’s.

It also should be given that UX related to snap for non-dev’s is a pain.

That does not mean snap are bad or useless for « average » desktop users. But the experience they provide to desktop users is most of the time not as good or easy as what has been provided for years through historical / legacy packages management at an average user level.

There are very simple things that lead to disappointment regarding snap from a non-IT desktop user’s point of view, still today after 4 years of pushing into Ubuntu.

[ from https://discourse.ubuntubudgie.org/t/any-warning-if-i-remove-snapd-ecosystem/833 ]
Problem here is the app-store, a.k.a. software. For years now, that thing :
⋅ shows for each app one entry per type of packaging, [ so 2 or 3 gimp, 2 or 3 Firefox… ]
⋅ without mentioning the type of packaging in this first front list, [ first pernicious trap ]
⋅ and puts snap app’s on top of the list. [ second insidious trap ]

Most users click on the first Firefox, or Gimp or whatever, hence they end up installing a snap package in total un-awareness . And then this is how users discover snap : because their app can’t access /home or /media or have wrong theming, no translations and so on.

If snap app’s pointed users towards « permission » window at first launch there would be much less disappointment.

« Advanced » users may prefer command line where they know what they’ll get - apt install or snap install . But beware as of 20.04 sudo apt install chromium-browser will actually install its snap package. No choice here. And third trap.

Theming is still a problem.
Translations are still sometimes lacking.
App’s based on plugins/extensions ecosystem may have issues ( gimp / gmic ).
Much more storage is needed.
Slowness in some situations…

All those won’t prevent from working or doing things but they do give desktop users a non-finished, not well-integrated product feeling and do not advocate well the eventual benefits of using snap.

For me as a not-so-average user ( using Ubuntu since 8.04 ) snap lack :
⋅ being self-explanatory on their requirements ( permissions )
⋅ …on their features ( saved versions, etc )
⋅ a general friendly GUI to fully manage them ( permissions, interfaces, restore, anything snap is capable of ) that should come as soon as any snap is installed, not something distro or DE dependent.

Maybe with tools like these, users may have less « bad » surprises with their snap ?

75

It s nearly 6 now … :wink: https://launchpad.net/~snappy-dev

Created on:
2014-11-20

On a 16.04 system where there is still a chromium deb:

$ ls -lh /var/lib/snapd/snaps/chromium_1182.snap 
-rw------- 1 root root 157M Jun  8 14:45 /var/lib/snapd/snaps/chromium_1182.snap
$ apt-cache show chromium-browser|grep Installed-Size
Installed-Size: 223962

(note that snaps never get unpacked on disk … )

Even though I have to admit that chromium is a very grateful target here since it always shipped all its dependencies, it is also a very good example to show the size difference (and that snaps are actually smaller … there is a lot of FUD going around out there though)…

Apps that have not formely been packaged as snaps and now ship their dependencies along indeed appear bigger than the deb without looking also at the deb dependencies that came along. But these issues have recently been resolved by things like the gnome-3-34 or the qt551 extensions that ship all shared libs in a way all snaps can make use of them. It is now a matter of developers to pick up on it for their app snaps though.

If you watch the forum (and the community hub at discourse.ubuntu.com), then you might notice that fixing theming is heavily being worked on by the desktop team …

The same goes for the startup slowness (specifically on first start of graphical apps), various teams are actively looking into imporvements … though I suspect this is actually an area where we can’t get on par with debs, simply because the confinement needs to be set up on start, so a measurable difference will always be there (but i guess we have won if it is simply not a lot noticeable anymore)

76

:thinking: Ok so you tell me where I am wrong - why not, FUD needs to be broken.

But what do you say about how « software » works regarding snap ? And how it cheats on users by not showing upfront who is a snap and who is not or who is something else.

About being more friendly, self-explanatory about permissions and features ? Like pointing users towards the permissions page ( in software or settings/applications in control-center or a dedicated app ) at first launch.

About a full featured GUI for managing anything snap-related ? Interfaces, devices, restore, theming… name all.

I did not say there are no improvements. I do say that UX about snap for average people is bad because it’s not enough desktop designed - with UI that that gives the needed trick at the right moment. I don’t know how to translate the concept of « parcours client », maybe « customer’s path », well « try walking in my noob’s shoes » and see any details that may harm the adoption process, user’s side.

On 20.04 I had to spend time to have my Chromium accordingly themed with my DE, had to come here for asking Audacity be in my language, and thumbnails for .xcf files generated by Gimp are not used outside of Gimp. I thank the enthusiast people from here and budgie and ubuntu-fr forums who helped me fix some of these.

Yes these are details but these make average Joe thinks snap is broken. Exactly like shipping a calculator that took dozens seconds to launch was the worst ambassador for snap some time ago. Or shipping snap by default in LTS Ubuntu versions, letting people imagine it’s as easy as legacy APT/.deb route. It’s still not.

Snap in themselves are not the problem. It’s more about the « selling » / marketing strategy and ease of use for normal people ( hear : non-IT, non-dev people ). Snap are certainly a relief for dev’s. Not yet for users. Hence not a surprise some distro don’t want to deal with disappointed users because of snap. As long as the « customer’s path » is not friendly addressed.

Chicken or egg first… :grin:

Now what are these, if no extra storage needed :

--- /home/django ---------------------------------------------------------------
    1,1 GiB [##########] /.cache
  713,0 MiB [######    ] /snap                                                  
  382,0 MiB [###       ] /Logiciels
  263,4 MiB [##        ] /.local
  212,3 MiB [#         ] /.icons
  161,5 MiB [#         ] /.mozilla
   84,4 MiB [          ] /.thunderbird
(…)

and

--- / --------------------------------------------------------------------------
. 486,9 GiB [##########] /media
    7,9 GiB [          ] /usr
.   5,5 GiB [          ] /home
.   3,3 GiB [          ] /snap
.   2,8 GiB [          ] /var 
(…)

It looks like an amount of 4 GiB of storage is used by snap, doesn’t it ? Given I only use Chromium, Gimp and Audacity it looks a lot. Would stop using snap free that space or not ?

77

Strangely in my version of Ubuntu Software it shows exactly this information for i.e. Inkscape (Source: “snapcraft.io”):

Bildschirmfoto%20von%202020-06-14%2002-08-53

So I dont get where anyone is “cheating” … If you refer to the transitional chromium-browser snap, I’m not sure I agree either:

$ apt-cache show chromium-browser|grep Description
Description-de: Transitional package - chromium-browser -> chromium snap

I think this is pretty clearly stating what it does … and Ubuntu has had Transitional packages since its existece this is not anything conspiratory that we make up all of a sudden, but a way to enable people upgrading to keep a working version of the software they have installed … the alternatives would be to either leave them with a rotting, never upgrading old version behind or remove it completely …

I (and most if not all of the people working on/with snaps) fully agree that the interface UX needs to be better and should operate on an ad-hoc basis, still, there is a (admittedly initial) GUI for managing them in Ubuntu Software (if you click the “Permissions” button):

I fully agree here …

Shipping the calculator was actually a probe (and IIRC also announced as such in the release notes (that admittedly nobody reads :slight_smile: )), not an ambassador. It allowed to collect a lot of data, particulary about slow app startup (and a lot could be improved due to it for 20.04) … it was necessary to collect this data and people bothered by it could always remove the snap ad re-install the deb.

Exactly our problem :wink: (but as you can see here and on the community hub, also not an unnoticed one … a lot of people work on improving the situation constantly.)

Because you look at the mountpoint of the mounted readonly filesystem :wink: … this is the representation of the uncompressed size which does physically not actually exist …

Imagine a livecd (you said you have been around since 8.04), did you ever wonder how we managed to put a 2GB rootfs onto 650MB media ? It is the same concept, the actual “physical size” is the size of the .snap files in /var/lib/snapd/snaps (like the cdrom was a plastic disc that could only store 650MB, yet, once mounted you could see the full 2GB)

3 Likes
78

I would like to add another problem to the list: drivers and hardware acceleration.

I am sorry if I am not technical enough, take this an experience from an end-user. The apps for which I choose flatpak or deb over snap are the ones that make use of OpenCl, Vulkan or (need an updated version of) OpenGL, vaapi.

I could not make to work any OpenCl acceleration in any snap app, for example: darktable.
Many Vulkan apps just refuse to work on my Intel laptop, example: vkQuake.
OpenGL works, but it is usually using a year-old version of mesa (coming from core18, for example) and not the shiny new version on my 20.04 installation (or added through kisak ppa). This is important for some software/hardware configurations. The same for vaapi.

I really, really like snaps. I would love for them to succeed. But not everyone is able to look over this teething issues.

Edit: also, another thing: snap-store is just not ready yet. Slow and inconsistent search and duplication of apps for example.

1 Like
79

I know this info is where you show, and it’s « too late ». It should be here : logiciel_package And why put the legacy package at the end of the list ??? This is totally unfair.

Or. Better in my opinion, there should be only 1 item per app and choice of packaging be given on next page, before installing. logiciel_choice ( here I put too many types of packaging on purpose ) This only to avoid people installing snap ( or else ) without knowing it.

This is what happens today : many people discover they installed a snap after when they don’t understand why their snap-app can’t access such folder or usb-thumb… just browse forums, it’s common « bad » surprise.

Hence my exaggeration with the word « cheat » : package type must be shown upfront, not on second or third page, and not at the bottom of a page. It’s basic and well-mannered UI design. Otherwise it looks like an eluding attempt.

Of course it’s stating what it does. For geek people who already know what is a snap. For average Joe, it should also mention something like : « once installed, set your needed permissions in settings/applications or software/chromium ».

Regarding permissions, I really think it would be more efficient if at first launch of a snap, the app would automatically launch the ad-hoc page from « software » or « settings/applications » in 20.04. settings_applications ( missing translations here, another harmful detail for adoption )

Good point, lol. No I never really care about it because it was actually on an external support and fully unpacked in RAM. At least it’s how I understood that process. Does it mean we could end up with « visually » 100% full partition, freezing a system, but in fact it’s not « physically » true ? Then what storage info an above-average Joe like me should trust ? Imagine a little light laptop with only one 32 or 64 GiB ssd and a dozen snap app’s → :boom: ?

See, snap brings a lot of new things to care about, even for a basic user. It’s neither good or bad but it implies new GUI tools for « surfacing » the new features. I think such a tool should be « handled » by the snapcrafter team, not by distro, and be shipped as a core tool. Then anything regarding snap could be managed from only one trusted, universal, full featured « place » ( by universal I mean not-distro-specific ). A snap-manager.

80

Make sure to file bugs for all these issues … perhaps one or the other are not known yet by the respective teams that are able to fix them …

no, this is a separately mounted filesystem that does not affect your / at all (well, beyond the actual size of the .snap file in /var/lib/snapd/snaps indeed):

$ mount |grep /core18_|head -1
/var/lib/snapd/snaps/core18_1705.snap on /snap/core18/1705 type squashfs (ro,nodev,relatime,x-gdu.hide)
$ LC_ALL=C df -h /snap/core18/1705
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop59      55M   55M     0 100% /snap/core18/1705

it is an unmodifyable compressed readonly filesystem … and hopefully you will find it always 100% full (else mksquashfs messed something up very badly) …

now, looking at the (virtual) content of this snap (like you originally did above):

$ LC_ALL=C sudo du -hcs /snap/core18/1705
168M	/snap/core18/1705
168M	total

If files are accessed on such a filesystem, they are decompressed on the fly by the kernel without you noticing … the image file (*.snap) is actually only roughly a third of the actual content here …

81

Regarding (gnome-)software in Ubuntu → https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1883445

Not sure where to report other things…

I did not worry about the /dev/loops but the size of ~/snap or /snap
So the only « weighing » parts are /var/lib/snapd/snaps and ~/snap ?

82

right, … there is one more … /var/lib/snapd/snaps carries the snap files, ~/snap carries all user data and /var/snap carries global data or data for daemons, configurations etc … any app that doesnt get run by a user (i.e. services) will use the /var/snap dir.

83

which also leads to many duplicates for years… 2017 but am pretty sure this topic surfaced before here and there.







( I even forgot I had already created one of these )

That looks like the issue is known and not considered as a bug.
Though it leads to much disappointment user’s side regarding snap.

Un-productive selling strategy…

84

As the primary bug report for your list of duplicates states, GNOME Software does have the ability to deduplicate entries from multiple sources. It does this via “appstream IDs”.

On the deb side, this is generally handled by scraping the packages in the archive for metadata installed to /usr/share/metainfo or from .desktop files, producing indexes that get downloaded to /var/lib/app-info/yaml.

On the snap side, AppStream IDs are specified by the common-id field in the snap’s meta/snap.yaml file, and also returned in search results from the store.

When things are working correctly and both packages provide the same ID, you should only see a single result in the search results. Things break down in your Audacity example because the two packages claim different IDs. The deb package doesn’t provide any native AppStream metadata, so the fallback ID audacity.desktop is reported (i.e. the filename of the desktop file it installs).

The snap instead uses the ID org.audacityteam.Audacity, which seems to be the ID made up for the flatpak version of the app. So the deb and snap versions are considered to be different applications. The same would be true for the deb and flatpak versions.

1 Like
85

So, who’s wrong here, the Debian package, or Flatpak and my Snap? Note that Audacity provides the metainfo in their repository, so I’m using that. If the Debian package isn’t using the provided metainfo then I’d suggest that’s Debian or Ubuntu’s fault

86

It looks like you and the Flatpak are correct in this case, and the appdata.xml file was omitted from the package in Ubuntu 20.04 and earlier. Looking at the diff, the package in 20.10 should correctly deduplicate against your snap:

https://launchpadlibrarian.net/478665940/audacity_2.3.3-1build1_2.3.3-2.diff.gz

This was definitely a shortcoming in the deb package rather than anywhere else.

2 Likes
87

Flagged for out-of-topic, seriously ???

(gnome-)software is the detail here, the elephant in the room is : why are snap missing adoption opportunities ? Because maybe there is nothing user’s side that brings the right info at the right moment about dealing with snaps ?

Often people install snap by accident because of ↓ how could they feel safe about them with such manners ?

Sorry @lucyllewy and @jamesh I think you both missed the point :wink:

There is no problem with metadata or audacity here.

The problem here is how surface the many packaging-types for one given app. And how it’s actually handled is not an accident, it’s just a very old, bad and misleading design choice, that’s all. Old because it’s coming from an era when only one type of packaged app’s was available, .deb.

When searching for a particular app in (gnome-)software and given you have snap-plugin + flatpak-plugin, you may see that app listed 3× It’s not because of metadata, it’s because of packaging type.

Users seeing this are meant to make a conscious and well-thought choice between let’s say 3 app’s that all look the same. How ? On that list there is nothing to differentiate one from the other. The difference is the packaging type but there is no visual clue to explain and help people chose between snap/flatpak/deb/whateverelse → this is the misleading part.

Amongst those 3 same looking items in list, one falls at bottom of the list. It suggests something like bad ranking or an attempt to hide it from people’s view. And guess what ? The last one in the list is the good old legacy .deb package, the easiest one to use, install and manage → this is the bad part, because biased instead of explanatory.

The way (gnome-)software still works today, it seems unavoidable to propose one item by packaging type ( in fact one item by plugin ) otherwise how / where people would wisely chose between them ? Look carefully at the 2 first pictures for 2 easy ways to get rid of that confusion.

The way bug reports on this topic look ignored for years suggests there are people who think the actual situation is good. It’s not. It makes users install things without knowing ( the most ) important information, packaging-type. Packaging-type dictates how an user will have to take care of his⋅her app’s and system on the long run so it must appear upfront, not be hidden at bottom of a second page, silenced nor biased.

1 Like
88

This presumes that the user knows and understands the differences between the packaging systems and I think is an unreasonable burden to place on someone who just wants to install software. The ideal situation is that from a usability standpoint the different packaging versions are the same and so it shouldn’t matter to most users of the software which one they get.

I think that adding additional information about snap vs deb vs flatpak in the default workflow will only confuse the user who doesn’t understand the distinctions. We should definitely expose this information to those who care about it and make it easy to choose something else, i.e. an advanced installation options page, but for the default flow I agree with the others in that different package types shouldn’t show up.

89

This is absolutely wrong → you don’t get the same « usage » depending of which type of package you installed. Not the same way to update them, to give permissions, etc. It’s impossible and misleading to treat those packaging as if they were « equivalent ». They’re not, each implies some specific care, even at basic level.

The actual lack of information creates confusion → user installs first item from the list → then asks in forums why this newly installed app’ can’t access this folder or that usb-thumb… because he had to set permissions. How could he know since packaging is not clearly mentioned ( in app-name or at top of a page ).

If user was right at the beginning aware of which kind of package he installed, end of problem.

If he’d been in front of a choice between [ gimp-snap | gimp-flatpak | gimp-deb ] he would had a chance to ask which one is better for him. But being in front of [ gimp | gimp | gimp ] it’s lottery, ok I take first in list, because first is probably better ???

Actual situation is intellectual dishonesty. Nothing else. Users are not that stupid if you give them the right info at the right moment. I hope (gnome-)software’s purpose is not to hide information in order to make people install snap by accident.

1 Like
90

Oh. How pointing some obvious subjects of disappointment for users facing snap in gnome-software, leading to non-adoption of snap for such users, makes me out of topic here ?

If you were looking for some place to iron out for easier snap adoption, then the « app-store » aimed at basic users is certainly one to improve. Amongst others, of course.

91

… and this is what actually needs to be fixed :wink: (in the long term)

You are implying bad intent while there are simply missing features …

1 Like
92

I hope there’s no bad intent. But those missing features ( if we look only at the default app-store in Ubuntu made by Canonical, mother-home of snap ) were very easy to guess, have been confirmed as annoyances by many users through many forums, have been reported as bugs for years and since the beginning…

…if by accident users install a snap, and later are not happy with that snap, how do you want these users to adopt snap ? I don’t know what’s the English phrase here, but it looks like feet over head, doesn’t it ?

Though, putting snap first in the list, and deb last, was an intent : I can’t see any good here.

Improvements are real, month after month, no doubt. But for being adopted snap has to be at least as good as what people used to have without or before snap. I know snap already has more interesting features than .deb but as long as users may struggle with thumbnails or themes or translations or permissions or this or that, snap will be seen as « less good » and lose.

I really think there’s a need for a better entry point into snap-ecosystem, with an one place / one app where everything regarding snap can be known and managed : (gnome-)software fails at that, and settings/applications in (gnome-)control-center is not enough - but provides at least something that should have been provided by Canonical inside Ubuntu as soon as the first snap iteration.

Integration into Desktop Environment through a specific GUI, distro-agnostic and itself provided as a core snap. Something that takes the desktop-users by the hand and teaches, explains, helps them « taming » snaps. Is such a thing on the map for non-IT-non-Dev users ?

93

It really is because of the metadata provided by the packages. In the specific case of Audacity, the Flatpak and Snap packages would be collapsed into a single entry as they both have the same AppStream ID. And if you’re on Ubuntu 20.10, the deb package would also collapse down too. I don’t think there is a situation where you’d see three entries in the search results in this particular case.

If we look at the internals of GNOME Software, there is a gs_app_list_filter_duplicates function that can deduplicate a list of apps based on AppStream ID:

https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/lib/gs-app-list.c#L777

When there are duplicates, it picks the one it considers to be “best” and discards the rest. This is determined by a priority scheme based on information provided by the plugins. In particular, the Flatpak and Snap plugins for GNOME Software state that their search results are better than those from the PackageKit plugin (which is how apt packages are plumbed in):

https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/flatpak/gs-plugin-flatpak.c#L52
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/master/plugins/snap/gs-plugin-snap.c#L131

This is down to applications from these sources generally being safer and more up to date. There’s no specific ordering imposed between Snaps and Flatpaks, so I don’t know which one would win or if the result would be stable.

1 Like