[ale] Canonical and Snaps

[DJPfulio at jdpfu.com]

On 4/25/23 13:54, Phil Turmel via Ale wrote:
>> 
> 
> The other factor I've been mulling is Ubuntu's new practice of
> holding back security updates for a bit unless you pay for Ubuntu
> Pro.

That isn't actually what Ubuntu does.  They are just advertising that the Universe Repo doesn't have support (and never has), unless you are eligible for Ubuntu Pro.  It is no cost for many people.  If you become an "Ubuntu Member", which I am not, I think they give license to 50 systems.  For individuals, 5 licenses are free.

In short, Canonical isn't taking anything away.

Snaps began in the Ubuntu Phone effort.  Then moved into the Ubuntu Core (which is for IoT devices) realm.  That's all fine.  Those are effectively single user devices with next to zero customization.

Then someone at Canonical decided to do something like flatpaks and containers ... just with snaps.  They did solve some interesting problems with their snap technology, but they introduced some. There's always a cost with trying to simplify installs.
For IoT devices, I could see where forced upgrades via snaps would be good for the company selling the device+software.  It removes the need for the vendor to have update infrastructure, since the snap-store does it automatically. There are non-default snap commands to only allow snap updates on a specific day and to reduce/increase the number of local snap versions (3 is the default), so if something bad happens, there are snap commands to revert to a prior version. Of course, the reversion doesn't remove the data changes, if there are any.

Snaps forced installs which seem modeled after Chromebook forced upgrades, cannot be prevented except by blocking access to the download infrastructure.  This is a mistake, IMHO.  Snap updates should have been merged into the same upgrade process that APT uses, even if all they did was to modify the 'apt' command to add on snap upgrade commands after the apt upgrade was completed.

As I wrote before, snaps have some interesting capabilities, but also some unwanted side effects.  Lots of Ubuntu users, mainly those that are GUI-only people, don't really know anything about snaps, which says something about the integration, at least for that group.  OTOH, snaps have nearly doubled the amount of storage needed for a typical Ubuntu Desktop install from 15G to 35+G.  In 18.04 (pre-snaps), my desktop was 15G.  In 20.04, I ran out of space after a few months even with 30G allocated. I don't keep any media files on my desktops.

Initially, snaps didn't support any nfs storage, even if it was mounted to the "approved", hard-coded, directories which are /mnt/ and /media/.  The Linux File System Hierarchy Standards wouldn't use either of those locations for permanent storage, so hard-coding them into approved extra places for snap packages to be allowed access is not sufficient. From the standards document:
     /media  Mount points for removable media such as CD-ROMs (appeared in FHS-2.3 in 2004).
     /mnt  Temporarily mounted filesystems.

And last time I checked, HOME directories weren't mandated to be under /home/, so hard coding that into the snap allowed locations is just poor engineering too.  The snap subsystem should be able to get a list of userids and HOME directories from 'getent passwd', then trust those locations. If the system can't trust the passwd DB, then it shouldn't boot at all.