Snaps Impact on Ubuntu?

[NoWorries]

No doubt many of you are grateful for the superb development effort done by all in producing Kubuntu 20.04.

You probably noticed that the downloaded iso file is 2.2GB. Well I just checked the size of Ubuntu 20.04 and it is 2.5GB.

I am wondering if this difference is due to snaps being used as this, and the Gnome desktop, are the only major differences.

If snaps is the main reason for this difference, could someone who is in the know, please either confirm or deny what I am thinking. Assuming that snaps is the reason, will we be able to avoid it for Kubuntu 20.10 as we can with Kubuntu 20.04?

[chimak111]

 $ snap list
Name                             Version             Rev   Tracking         Publisher   Notes
»core18                           20200311            1705  latest/stable    canonical✓  base
featherpad                       0.10.0+pkg-3be6     17    latest/stable    brlin       -
»gnome-3-34-1804                  0+git.2c86692       27    latest/stable/…  canonical✓  -
»gtk-common-themes                0.1-36-gc75f853     1506  latest/stable/…  canonical✓  -
kcalc                            20.04.0             65    latest/stable    kde✓        -
kde-frameworks-5-core18          5.61.0              32    latest/stable    kde✓        -
kde-frameworks-5-qt-5-14-core18  5.68.0              4     latest/stable    kde✓        -
kolourpaint                      20.04.0             56    latest/stable    kde✓        -
ksnip                            1.6.1               3     latest/stable    dporobic    -
okular                           20.04.0             98    latest/stable    kde✓        -
»snap-store                       3.36.0-74-ga164ec9  433   latest/stable/…  canonical✓  -
»snapd                            2.44.3              7264  latest/stable    canonical✓  snapd
$

This is what I have on Ubuntu 20.04. The ones marked with » came with the system. The rest were installed by me.

I don't know how to figure out the contribution of the ones marked with » to the size of the 20.04 iso or to the installed system.

[GreyGeek]

.... will we be able to avoid it for Kubuntu 20.10 as we can with Kubuntu 20.04?

More than likely. I purged snap and all of its loop and loop mount points, and chromium. I won't be using 20.10, since I'll be staying with 20.04 until the next LTS or later.

[kyonides]

Thanks for reminding me to remove snap. I had forgotten it even existed. XD

[chimak111]

I am wondering if this difference is due to snaps being used as this, and the Gnome desktop, are the only major differences.

The snap sizes can be seen by running `ls -lh /var/lib/snapd/snaps`

$ ls -lh /var/lib/snapd/snaps
total 968M
-rw------- 2 root root  55M Apr 23 13:12 core18_1705.snap
-rw------- 2 root root 241M Apr 23 13:12 gnome-3-34-1804_24.snap <<<
-rw------- 1 root root 243M Apr 27 12:03 gnome-3-34-1804_27.snap
-rw------- 2 root root  63M Apr 23 13:13 gtk-common-themes_1506.snap
-rw------- 2 root root 291M Apr 26 17:46 kde-frameworks-5-qt-5-14-core18_4.snap •••
drwxr-xr-x 2 root root 4.0K Apr 10 20:27 partial
-rw------- 2 root root  28M Apr 23 13:12 snapd_7264.snap
-rw------- 2 root root  50M Apr 23 13:13 snap-store_433.snap
$

<<< indicates a revision. A minimum of two revisions (older versions) of each snap are stored. Obviously, the Ubuntu iso won't have any revisions
••• was not part of the default iso; it was installed by me. This particular snap will be used by other qt snaps allowing these other qt snaps to be smaller.

[HatinGokbori87]

Hi, I'm new(er) on Ubuntu, and Snap had been a great help to me. Some of my favourite apps are exclusively available as Snap and many apps don't provide first-class support for Linux (either you have to compile those apps or you have to wait for them to release compatible binary or to add support for your release in their PPA. You have to repeat the process after every update). Most apps in LTS repository almost never gets updated so the traditional counterpart of an app slowly gets outdated. So the new users has to start a mission to solve this problem but often finds them too hard.
While I'm sure Linux expert programmers can easily get around these things it's an unpleasant experience for many. I hope Kubuntu will keep supporting installing Snap apps out of the box. And people who don't want them can just "not use" so I think it is removing much more pain than it creates.

[verndog]

Hi, I'm new(er) on Ubuntu, and Snap had been a great help to me...

You are just the type of person Ubuntu is aiming for. Me, on the other hand I just installed Arch KDE , along side neon, just in the case the future Ubuntu makes it impossible for me to use Ubuntu anything. Snaps will not be part of my future.

[Don B. Cilly]

Well, they might rethink the implementation of them so they don't clog up you system with loops and add unacceptable amounts of time to your boot.

[EDIT]

I just installed Arch KDE , along side neon

Not to be "tarty", but don't you find the whole pacman/AUR thing just as annoying as snaps? I do...

[claydoh]

Oh, it sure slows my boot time bu such a yuuuge amount.

Before any snaps, on 20.04

dohbuoy@dohbuoy-FLEX-15:~$ systemd-analyze 
Startup finished in 1.622s (kernel) + 7.473s (userspace) = [COLOR=#ff0000][B]9.096s [/B][/COLOR]
graphical.target reached after 7.166s in userspace

dohbuoy@dohbuoy-FLEX-15:~$ systemd-analyze -blame
systemd-analyze: invalid option -- 'b'
dohbuoy@dohbuoy-FLEX-15:~$ systemd-analyze blame 
6.075s NetworkManager-wait-online.service                   
 527ms systemd-logind.service                               
 488ms upower.service                                       
 375ms systemd-journald.service                             
 367ms dev-nvme0n1p2.device                                 
 314ms systemd-resolved.service                             
 305ms tlp.service                                          
 253ms systemd-timesyncd.service                            
 176ms systemd-udev-trigger.service                         
 165ms networkd-dispatcher.service                          
 162ms udisks2.service                                      
 157ms accounts-daemon.service                              
 142ms snapd.service                                        
 101ms avahi-daemon.service                                 
  97ms NetworkManager.service                               
  90ms polkit.service                                       
  86ms iio-sensor-proxy.service                             
  81ms user@1000.service                                    
  73ms systemd-journal-flush.service

Next, I installed a few snaps, namely Gimp and Kdenlive

dohbuoy@dohbuoy-FLEX-15:~$ snap list
Name                             Version                     Rev   Tracking       Publisher     Notes
core                             16-2.44.3                   9066  latest/stable  canonical✓    core
core18                           20200427                    1754  latest/stable  canonical✓    base
gimp                             2.10.18                     273   latest/stable  snapcrafters  -
gnome-3-28-1804                  3.28.0-16-g27c9498.27c9498  116   latest/stable  canonical✓    -
gtk-common-themes                0.1-36-gc75f853             1506  latest/stable  canonical✓    -
gtk2-common-themes               0.1                         9     latest/stable  canonical✓    -
kde-frameworks-5-qt-5-14-core18  5.68.0                      4     latest/stable  kde✓          -
kdenlive                         20.04.0                     24    latest/stable  kde✓          -
snapd                            2.44.3                      7264  latest/stable  canonical✓    snapd

Next, for the massive, impressively obvious boot slowdown:

dohbuoy@dohbuoy-FLEX-15:~$ systemd-analyze 
Startup finished in 1.607s (kernel) + 7.651s (userspace) = [COLOR=#ff0000][B]9.258s [/B][/COLOR]
graphical.target reached after 7.314s in userspace


dohbuoy@dohbuoy-FLEX-15:~$ systemd-analyze blame 
6.204s NetworkManager-wait-online.service                            
 539ms systemd-logind.service                                        
 478ms upower.service                                                
 377ms dev-nvme0n1p2.device                                          
 336ms snap-kde\x2dframeworks\x2d5\x2dqt\x2d5\x2d14\x2dcore18-4.mount
 335ms tlp.service                                                   
 332ms systemd-journald.service                                      
 329ms snap-snapd-7264.mount                                         
 303ms systemd-resolved.service                                      
 298ms systemd-timesyncd.service                                     
 296ms snapd.service                                                 
 259ms snap-kdenlive-24.mount                                        
 236ms snap-core-9066.mount                                          
 232ms snap-gnome\x2d3\x2d28\x2d1804-116.mount                       
 226ms snap-gtk2\x2dcommon\x2dthemes-9.mount                         
 222ms dev-loop1.device                                              
 205ms systemd-localed.service                                       
 199ms dev-loop2.device                                              
 199ms dev-loop3.device                                              
 197ms snap-gtk\x2dcommon\x2dthemes-1506.mount                       
 187ms systemd-udev-trigger.service

.2 seconds. I am appalled!
Actually it is .161 seconds, which IS 1.78%, an arguably large percentage, but a tiny-a***d amount of actual time.

After masking NetworkManager-wait-online.service , whiich I don't need at them moment, as this laptop has no network mounts currently:

dohbuoy@dohbuoy-FLEX-15:~$ systemd-analyze 
Startup finished in 1.598s (kernel) + 2.166s (userspace) =[COLOR=#ff0000][B] 3.765s [/B][/COLOR]
graphical.target reached after 1.587s in userspace

We also forget that things are not loaded sequentually,


Lenovo Flex 15
Processors: 4 core/8 thread Intel® Core™ i5-1035G1 CPU
Memory: 7.5 GiB of RAM
Samsung oem m.2 ssd

[claydoh]

And aren't mounts already long 'cluttered', in Linux generally speaking?

testes@testes-VirtualBox:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=4034888k,nr_inodes=1008722,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=815304k,mode=755)
/dev/sda5 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1151)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=815304k,mode=700,uid=1000,gid=1000)

[Don B. Cilly]

Well, I don't have any snaps to test it :·), but on a medium-spec machine, less than a year ago, the situation was this.

[claydoh]

No, as those mounts are not done consecutively.

I added my mounts up by ms as reported add up to 2.668 seconds but my boot time increased by .16 seconds.
your slow boot time in the link was related to to NetworkManager-wait-online.service.

[Don B. Cilly]

Pardon the ignorance.
So what does

    1.813s dev-loop10.device
    1.811s dev-loop8.device
    1.809s dev-loop9.device
    1.636s dev-loop4.device
    1.613s dev-loop5.device
    1.601s dev-loop7.device
    1.597s dev-loop6.device
    1.594s dev-loop3.device
    1.546s dev-loop2.device
    1.535s dev-loop1.device
    1.528s dev-loop0.device
    1.316s snapd.service

add up to?
Or, if it doesn't add up... could you explain what it means?

[EDIT] Oh. It adds up to 1.813s, right? I just hadn't noticed the were incremental... :·/

[claydoh]

these are not done consecutively, but in parallel, like most boot time processes.
The list in systemd-analyze lists them by time length.

[oshunluvr]

Dude, if you're into your boot time, dump NM, jus' sayin'