Snaps again (was Re: Stop google Chrome cron job?)
Stuart McGraw
smcg4191 at mtneva.com
Fri May 12 22:04:49 UTC 2023
On 5/11/23 04:44, Colin Watson wrote:
> On Wed, May 10, 2023 at 12:43:57PM -0600, Stuart McGraw wrote:
>> It's not solely the update control issue, it's also the size of snaps (I
>> mentioned my internet connection bandwidth :-)) And the problems and
>> restrictions of snaps that come up frequently. There was discussion here
>> just recently about snapped Firefox's inability to open most file:// url's,
>> something I do frequently (e.g., I have a link on my local home page to
>> file:///usr/share/doc/.)
>
> For the record, file:///usr/share/doc/ works fine in snapped Firefox.
and
On 5/11/23 04:49, Oliver Grawert wrote:
> Am Mittwoch, dem 10.05.2023 um 12:43 -0600 schrieb Stuart McGraw:
>>>
>>> FYI it's possible to configure snapd not to automatically refresh
>>> snaps
>>> these days, so the above approach is overkill:
>>>
>>> https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--hold
>>
>> It's not solely the update control issue, it's also the size of snaps
>> (I
>> mentioned my internet connection bandwidth :-)
>> )
>
> a) snaps *exclusively* only do binary delta updates so what comes down
> the drain during an update is *significantly* smaller than any other
> update mechanism you can use (there are reasons why there are massive
> amounts of UbuntuCore (snap only) installs out there run by companies
> that can use only 3G/4G connections for their embedded devices ;) )
>
> b) snaps are compressed filesystem images, usually (again)
> *significantly* smaller than the same binaries installed via any other
> packaging system, their advantage is also that they get never unpacked
> on disk (but only loop mounted) ...
>
> ... don't believe all the myths made up in forum comments ;)
First, thanks to both of you for the corrections.
I try not to believe everything I read on the internet. But that
cuts two ways. :-)
I adopted the kill and mask treatment for snapd several years ago,
probably before the --hold forever option was added.
I don't want to reject snaps just because they're new and unfamiliar
so I tried to get some basic non-myth info about them but was not too
successful, maybe I just don't know where to look yet. I did find
and read
https://snapcraft.io/blog/a-technical-comparison-between-snaps-and-debs
and
https://snapcraft.io/docs
although I just dipped my toes in the latter.
You say in (a) above that updates are small because it sends deltas
and a quick test updating core20 (66MB) and snapd (55MB) did indeed
go very quickly.
But I wonder about (b) above. Surely even if compressed, the duplication
of libraries will, at some number of installed snaps, result in a total
greater size than installed debs that share non-duplicated libraries and
other resources? I've seen lots of mentions on the internet of very large
/var/lib/snap directories. And since snaps don't totally replace debs,
many of those deb-required shared libraries will be installed unavoidably
anyway.
As long as I'm asking questions...
- How do I learn about the access restrictions for various apps before
I have to discover them by being unable to do something? For example
where do I find the list of file:// url's that Firefox permits?
- Does (or can) snapd log all it's actions (downloads, updates, etc)?
(I enabled snapd and installed Firefox last night; there is an entry
saying the install is starting but nothing after that to tell me
when it finished, how long it took, etc.
- How do I get a list of available snaps like 'apt list \*' and details
of a particular app like 'apt show ...'? 'snap find' doesn't seem
to do it. Not interested in a GUI app/webpage.
- If I want to install a snap how do I know how big a download it is,
how much space it will require? Apt tells me, what about snap?
(Details in general seem hard to come by in snap-land.)
- Is there a way to cache snaps locally so multiple machines can be
installed/updated without a slow internet download for each?
- Snaps are (at least currently) oriented to desktop GUI apps? I
looked for some server level things I use like Dovecot (no); Postfix
(no); Postgresql (ancient versions, other programs I never heard
of and that don't appear in apt and no familiar programs that do);
Squid (version 0.3?! apt's is 5.2); is there any centralized quality
control over these? I get the same ugg feeling as when looking in
the Android Play Store.
What worries me most about snaps is the direction they seem to indicate
Canonical is moving with Ubuntu: less control for the end user over
his/her machine, less detailed information, more "sit back, relax,
we'll run everything for you". Exactly where smart phones have gone
already. That would suck.
More information about the ubuntu-users
mailing list