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

63

The latter one will eventually fall through into updating anyways, you can’t hold packages forever, since snapd will eventually force a refresh after X amount of time, whatever the latest “max delay time” has been hard-coded into the software this time.

Edit: looking at this closer, this also seems like a half-solution, I simply want to turn off automatic updates and then do a controlled and manual snap refresh/revert whenever I want, be it in a year. The current behaviour will eventually refresh anyways, which is non-deterministic for an admin workflow, and thus a non-solution.

1 Like
64

the “max delay time” is 60 days … so if you do monthly maintenance this should fit well into your window…

details at:

EDIT: also note that you can always snap revert any installed snap to the former version in case something slipped through … and that such a reverted snap will stop auto-updating

1 Like
65

This isn’t about fitting my hypothetical workflow, this is about my gripe and demand for snapd; a config value that disables updates for specific or all snaps, is that so hard?

I’m sorry if I seem flared up, but this question has been met with nothing but hacks, workarounds, and diversions to the question.

The question to allow for a complete out-of-band control flow of one of the most crucial parts of this system: updating.

66

Well Daniel, if you didn’t take time to look at another thread, where the subject is exaustivelly discussed, I suggest you do so. That might make things clear to you.

That being said, I’m off. I’m not here to endorse or go against Ubuntu and/or Snaps. Since it’s very clear the path it’ll take, I’ll do as suggested; as long as I’m ok with it, fine; when not, leave.

Edit: I wouldn’t say that understanding and embracing other point of view is anedoctal, I’d say it’s a sign of empathy and reasoning. I don’t need to be affected by an issue to pursue its dealing, but that’s me.

67

I haven’t seen any other threads than this one in the last few days/weeks. Although I am unable to monitor every thread on the forum.

I’m sorry, I appear to have upset you. That was not my intention. The anecdotal comment I made was not aimed at belittling your empathy, more an attempt to elicit further information on the scenarios that people are encountering that they desire the ability to completely disable updates.

@shadowjonathan has helpfully provided some thoughts along those lines. Their thoughts are very helpful to understand their point of view as a sysadmin that has a very rigid update cadence. Although I wonder if the Snap Store Proxy can fulfill any of those requirements. That would have to be discussed directly with a Canonical representative who can examine the requirements and advise a solution along with costing.

1 Like
68
69

My thoughts:-

Auto Updates
These absolutely should be enabled by default. I can understand the arguments for OOB updates for core system stuff and shared libraries, but the whole point of snaps is that they are self contained.

For “average Joe desktop user” there is no real compelling reason not to be getting automatic updates as long as they are safe to install - ie, I’m not going to lose unsaved changes.

For sys admins who might need to be doing more structured testing and version control, a lot can be achieved with the commands on https://snapcraft.io/docs/keeping-snaps-up-to-date. If your current update strategy can’t be completed within 60 days you should probably be more worried about your updating strategy and processes than getting a no-auto-update option added to snapd.

Can any snapd devs elaborate on what will happen if refresh.metered=hold is enabled for longer than 60 days - will it hold updates forever? (This is how I stop windows from using bandwidth when I am gaming - I just flag my ethernet connection as being metered).

Open Sourcing Snapd / Allowing 3rd Party Snap Stores
The Linux world simply does not need this! There are already too many “official” sources of software.

On the contrary, as more and more less experienced users embrace Linux the need for a single trusted source becomes more important. If there are issues with how snapcraft.io is operated, then the effort should be put into addressing them within this store and not just forking off and starting yet another store.

When we choose “distro X” or “distro Y” we are trusting that distro’s maintainers to keep our systems stable and secure. That is virtually impossible when the advice on the internet is to add this PPA or that PPA, or add a sources.list.d entry, etc, etc. If snapd gains functionality to do something like snap store add foo.example.com then the whole “improve security” argument becomes null and void.

IMO, I don’t even think any old Joe should be able to submit packages to the current store and there should be a clearly visible audit trail for packages (visible from within Ubuntu Software).

For example, what the hell is snappyatom? Who is Nitin Prabhakar? Who authorised this snap, who checked the source code hasn’t been stuffed with malware? It’s icon and description are close enough to the official atom.io site that it could easily be confused for the “proper” package.

If the original maintainer is not prepared to build the snaps and get themselves verified on the snap store, then the only other source should be Snapcrafters with a clear marker that the package is maintained by the Snapcraft team (much like the classic confinement marker/warning).

2 Likes
70

Some feedback from me, some of this will overlap with Ubuntu, so sorry about that:

I just took an audit of all the devices in my house. A grand total of 73 DHCP leases, out of all of those, only 4 devices don’t have automatic updates enabled by default. That would be my Ubuntu machines. That needs to change and I think snaps are a great way towards that direction.

Lots of people have been talking about technical solutions but I’ll give a few social ones that I think the team should consider and blog about:

  • People don’t know why zero trust systems are good. The world is being overrun by bad apps on mobile and the web, explain to them why having your operating system not trust applications by default is good for their privacy.

    • Proprietary systems are way ahead of open source here, and instead of OSS leading the way the narrative is “Hate Windows updates? Try Linux, we’ll never force you to update your computer!” This is unsustainable. This is where ChromeOS shines and is is cleaning Ubuntu’s clock here, they totally, and ruthlessly give people updates.
    • No one on the ChromeOS team is sweating how many users they’re losing to Linux Mint.

  • Use science: Here are 340 questions of users suffering with PPAs, add em up, we’re talking about millions of views of people having actual problems that can go away. That’s just one tag btw, there are tons of others. The discussion is overrun by “I hate snaps because my custom theme broke”, you have an entire decade of askubuntu data that actually tells you what problems actual users have. Add them all up and say “This is the problem we’re trying to solve.” You’re letting the theoretical problems reddit thinks are important dominate the conversation instead of using the user data that you’ve been collecting for years.

  • There’s a decade old bug I can’t seem to find right now but it’s the famous mpt bug that is “It’s unreasonable to ask people to upgrade their entire operating system for one application”. Everything in that bug is useful to explain to people why that is.

  • Just hard-break the autoupdating thing . Clear Linux draws a distinct line, they let you systemctl disable swupd.

    • You get no support if you file a bug, the documentation is very clear that you’re breaking your computer.
    • You’re either all in all or all out, no frankendebian-like systems, you’re either up to date or you’re not.
    • Just plop a fat red icon in the tray and in motd when updates are disabled. Make sure you’re reminding me that I’ve made a bad decision.
    • Just own it — no one flames CoreOS, ChromeOS, Flatcar, Android, or Clear for doing autoupdates – lots of them have the luxury of coming out after Ubuntu so they get to start fresh, spend the time to cultivate blog posts and culture around it.

Bad things that need to be fixed:

  • This is the third LTS with snapd included. Launchtime performance with desktop applications are unacceptable and have been so for way too long.
  • I don’t use server snaps but if they’re to be usable you need to enforce the use of channels. Autoupdating point releases may be fine but major releases are a no-op.

Probably Non-issues

  • Given the amount of open source projects falling over themselves to be included in the Windows winget store I would consider the license of the snap store to be a non-issue. There’s lots of loud people saying they care but the people actually maintaining the software don’t care about this.
10 Likes
71

I’d much rather get a prompt to update instead of this happening beneath my feet.

Yes, agreed, and there is a mechanism in plan to offer running applications exactly this ability. You wouldn’t want your helicopter autopilot updating during a flight, either :slight_smile:

3 Likes
72

I am a sysadmin who wants to lock down updates and get emails for potential ones, schedule maintenance windows, and then perform a controlled rolling update, and do this on a monthly basis if updates exist within that timeframe.

That is what the enterprise snap store does. It lets you control when the channel inside your network changes. So latest/stable can change for the rest of the world, but not for your network. All the devices that use your enterprise snap store see your version of the truth, not the global snap store version of the truth.

1 Like
73

This.

One of the key things that won my support for snaps was the realisation that I want to run software from people that I don’t trust.

How well do you actually know all the vendors of the apps you use? How well do you actually know the people behind all the cookies on the websites you use?

My first business was internet identity and crypto. People used so say “you are in the business of trust” and I would say “no, we are in the business of identity”, but most folks didn’t really relate to the difference. Just because I have checked paperwork to confirm that a business is who they say they are doesn’t mean I think you should trust them.

Just because I want to run that cool paper-toss app doesn’t mean I know that the people behind it are trustworthy. I want to decide what I trust them with. Having the system default to trusting them with nothing, is great.

The other key idea was the realisation that all the amazing security technology that has been put into the Linux kernel, with things like SELinux and AppArmor, wasn’t really being used to protect people. It is just too difficult, in a world where every app could in theory have a reason to be poking anywhere in the system. We needed a much more explicit model of the applications and their relationships.

So right at the heart of snaps, you have these key ideas. A very specific trust profile is designed out of relatively standard elements - the interfaces, called plugs and slots, that are connected on the snap. The result is much better security on average. Is it perfect? No. But it’s much, much better for millions of users than years and years of banging on SELinux and AppArmor profiles.

And it’s also much better for publishers. We have vastly more apps in the snap store than we have had in the prior decade of Ubuntu being the most popular Linux distro. Is it trivial to make a snap? No. Is it tractable for a serious ISV? Yes. Much more so than managing many different debs in many different distros, let alone RPMs. I watched ISVs go from being unable to publish for Linux, to publishing happily for Linux, thanks to the snap store.

When you look at the architecture of Ubuntu Core, you see this extraordinary exercise of completely rethinking how a Linux distribution puts its bits on the disk. And this is done preserving the ability to snap up almost any app from the classic distro. Are there things that can be improved? Yes, and they are well documented in this thread, and I believe the team will steadily and systematically address them as they have so many other issues.

5 Likes
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.