Focal Testing of Kubuntu 20.04 LTS

[WWDERW]

Do you know that "everything" is converting to snaps?

I was just wondering out loud is all.

However, since Chromium was mentioned, I know that Firefox has a snap, so if *buntu is jumping on the snap bandwagon full force and they believe that it is the best way forward, I could easily see Firefox, even when initially bundled with the OS, would also only be available as a snap as the same "benefits" would apply as well regardless if it's bundled in the ISO or installed post OS install.

[kyonides]

It's not a current debate, it's people reacting to a done deal, though they may not realize that.

APT with the occasional PPA suits me generally, and the alternative I reach for first is building from source. But I imagine that approach isn't for a lot of users. (I often encourage KFN posters to consider building from source, suspecting they think it's too difficult.)

Well, what I hate about building from source is that everything gets installed in weird places and when you find a variable to change its destination, they end up mixing stuff like crazy, creating folders where you'd never want them to be... :S

[NoWorries]

I decided to install snaps LibreOffice on my ASUS R501VN N56VM Laptop which I am prepared to "sacrifice".

Both the deb and the snap versions are now on this system.

For the deb version, a LibreOffice Impress file loads in about 3.6s and the snap version loads in about 8.4s. This makes snap 2.33 times slower!

For the deb files on my system.

The home .conf file is 7.6MiB with 4,378 files
/usr/lib/libreoffice is 278MiB and 3,466 files
/usr/share/libreoffice is 49.8MiB and 6,17 files

Now for snap file sizes.

My home directory has a /snap folder which is 2.6MiB and 125 files.
The .snap folder is 976.4MiB and 37,200 files.

This gives snap files approximately 3 times the size.

I would think that the current development of LibreOffice would be well advanced. After seeing these results, I do not hold much hope for the future of snaps.

I can't help but wonder if the development of snaps will follow the same path as Unity, ie be an expensive failure.

[Don B. Cilly]

...

[GreyGeek]

My ongoing adventure with snapd...

I discovered that one can delete snapd from his system but it will take the Chromium-browser with it. And, IF I install the Chromium-browser it brings along snapd as well. Double

I learned that I can disable the services snapd.service, snapd.socket, and Chromium will still run. It got me to thinking, "is the Chromium-browser making other snapd components run?"

[B]$ systemctl status snapd.service[/B]
● snapd.service - Snappy daemon
     Loaded: loaded (/lib/systemd/system/snapd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● snapd.socket
[B]
jerry@Aspire-V3-771:~$ systemctl status snapd.socket[/B]
● snapd.socket - Socket activation for snappy daemon
     Loaded: loaded (/lib/systemd/system/snapd.socket; disabled; vendor preset: enabled)
     Active: inactive (dead)
   Triggers: ● snapd.service
     Listen: /run/snapd.socket (Stream)
             /run/snapd-snap.socket (Stream)


[B]jerry@Aspire-V3-771:~$ systemctl list-units  | grep  snap[/B]
  run-snapd-ns-chromium.mnt.mount                                                                       loaded active     mounted   /run/snapd/ns/chromium.mnt                                                  
  run-snapd-ns.mount                                                                                    loaded active     mounted   /run/snapd/ns                                                               
  snap-chromium-986.mount                                                                               loaded active     mounted   Mount unit for chromium, revision 986                                       
  snap-core18-1650.mount                                                                                loaded active     mounted   Mount unit for core18, revision 1650                                        
  snap-gtk\x2dcommon\x2dthemes-1440.mount                                                               loaded active     mounted   Mount unit for gtk-common-themes, revision 1440    


[B]$ mount | grep snap[/B]
/var/lib/snapd/snaps/chromium_986.snap on /snap/chromium/986 type [B]squashfs[/B] (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_1650.snap on /snap/core18/1650 type [B]squashfs[/B] (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1440.snap on /snap/gtk-common-themes/1440 type [B]squashfs[/B] (ro,nodev,relatime,x-gdu.hide)
tmpfs on /run/snapd/ns type [B]tmpfs[/B] (rw,nosuid,noexec,relatime,size=1623420k,mode=755)
nsfs on /run/snapd/ns/chromium.mnt type [B]nsfs[/B] (rw)

Five file systems are used: 3 squashfs, 1 tmpfs and 1 nsfs.

[B]:~$ mount | grep snap[/B]
/var/lib/snapd/snaps/chromium_986.snap on [COLOR=#ff0000]/snap/chromium/986 [/COLOR]type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_1650.snap on /snap/core18/1650 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1440.snap on /snap/gtk-common-themes/1440 type squashfs (ro,nodev,relatime,x-gdu.hide)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,noexec,relatime,size=1623420k,mode=755)
nsfs on /run/snapd/ns/chromium.mnt type nsfs (rw)

[B]jerry@Aspire-V3-771:~$ sudo umount /snap/chromium/986 [/B]
[sudo] password for jerry: 
[B]jerry@Aspire-V3-771:~$ sudo umount /snap/core18/1650 [/B]
[B]jerry@Aspire-V3-771:~$ sudo umount /snap/gtk-common-themes/1440 
jerry@Aspire-V3-771:~$ sudo umount /run/snapd/ns[/B]
umount: /run/snapd/ns: target is busy.
[B]jerry@Aspire-V3-771:~$ sudo umount /run/snapd/ns/chromium.mnt [/B]
[B]jerry@Aspire-V3-771:~$ sudo umount /run/snapd/ns[/B]

Umount those locations and snap and snapd disappear. And, the Chromium-browser won't run.

:~$ chromium-browser
internal error, please report: running "chromium" failed: cannot find installed snap "chromium" at revision 986: missing file /snap/chromium/986/meta/snap.yaml

Logging out and then back in does not correct the error. A reboot is necessary.

So, it appears to me, that one cannot run the Chromium-browser in Kubuntu 20.04 without also triggering snap. Pulling in the source code for the Chromium-browser and compiling, a common practice 15 years ago, is something that I do not want to begin doing again. This is the 21st century, not the 20th.

The more applications that get tied this way to snap the more likely it will be that the snap store will become the main, if not only source for applications while running an Ubuntu based distro.

I thought that a snap daemon running continously as a service was a bad choice for Ubuntu. The lock-in with Google Chromium-browser gives me cause to wonder if Canonical and Google have come to some agreement.

[GreyGeek]

I looked in earnest for an executable binary of the Chromium-browser and found one.
https://download-chromium.appspot.com/

It runs when all the chromium-browser mounts are unmounted but the snaps Chromium-browser won't run.

So, all I have to do is find out where in the startup script those mount points are mounted and comment them out, or disable the service that mounts them.

[WWDERW]

Pulling in the source code for the Chromium-browser and compiling, a common practice 15 years ago, is something that I do not want to begin doing again. This is the 21st century, not the 20th.

I agree. Building from source should not be necessary for regular users as well. If one wants open source to take off even if it's just open source programs running on proprietary systems, the convenience of having pre-compiled binaries should be there. Otherwise, users won't flock to it en mass. Regardless if the build process is easy or not, a lot of people need their systems to just work to get work done out of the box. That's it. Not every user wants to tinker with the system. Unless a user is highly motivated, building from source isn't a viable option.

In all honesty, it shouldn't be needed except for devs that want bleeding edge or users that want bleeding edge that have the time and inclination to troubleshot problems that come up (which is to be expected with running bleeding edge). I may be so inclined during my free time, but if I am needing something to just work and not waste my time building, tinkering making sure everything is just so and adding tons of dev packages that I don't need the majority of the time to my system. It's just a frustrating downer.

The lock-in with Google Chromium-browser gives me cause to wonder if Canonical and Google have come to some agreement.

That may or may not be the case. Since that version of Google's browser is open source and is closely related to Chrome and as such enjoys a very popular user base on the internet, it may have just been a pragmatic choice on their part.

Now having said that, with Electron, I can understand some of the performance hit due to have that intermediate layer combined with the main programming language of Electron being higher level language (JS), unfortunately, taking programs written in a low level language and adding that extra layer really does do more harm then good.

I don't mind the size and slight ram resource ding of Electron as that brings apps that would otherwise not be apart of the Linux ecosystem. So Electron has it's place in that regard and why I like to use it for program work myself. However, adding a layer like that with snaps, to me, is just a bad idea. Plus, I don't like having the idea of bleeding edge programs, there may be a reason why I want to stay on the previous version, which is going to be harder to do.

[GreyGeek]

I looked in earnest for an executable binary of the Chromium-browser and found one.
https://download-chromium.appspot.com/

It runs when all the chromium-browser mounts are unmounted but the snaps Chromium-browser won't run.

So, all I have to do is find out where in the startup script those mount points are mounted and comment them out, or disable the service that mounts them.

Better yet, I simply uninstalled snapd and let it take the chromium-browser and its mount points with it. The binary version linked above works well. When it first appears it has a comment about "API Keys", but I simply ignored that. I imported all my info from FireFox, which I had populated with info from the original chromium-browser, and I am now back up to speed with NO trace of snapd or any mount points related to snapd or its linked chromium-browser.

In the future I will avoid ANY apps that want to suck snapd into my system along with them and resort to AppImages or other trusted binary sources.

With this problem resolved I plan to remain using Kubuntu 20.04 until its EOL.

[kubicle]

Better yet, I simply uninstalled snapd and let it take the chromium-browser and its mount points with it. The binary version linked above works well. When it first appears it has a comment about "API Keys", but I simply ignored that. I imported all my info from FireFox, which I had populated with info from the original chromium-browser, and I am now back up to speed with NO trace of snapd or any mount points related to snapd or its linked chromium-browser.

In the future I will avoid ANY apps that want to suck snapd into my system along with them and resort to AppImages or other trusted binary sources.

With this problem resolved I plan to remain using Kubuntu 20.04 until its EOL.

Like I mentioned in a post earlier on this thread, the chromium-browser you get from the repositories (via apt) is actually a snap package from *buntu 19.10 onwards, that's why the package depends on snapd (and why it starts snap services when you run it and refuses to run without them), If you want to avoid snaps, don't install chromium-browser from the repos or any other package that depends on snapd (which hints that it is actually a snap, and not a "regular" deb). Kubuntu, AFAIK, does not install snaps by default, but many gnome apps installed in ubuntu by default are already snaps.

[NoWorries]

Kubuntu, AFAIK, does not install snaps by default, but many gnome apps installed in ubuntu by default are already snaps.

In support of what you have posted, I found the current size of the Ubuntu 20.04 iso is 2.4G. Whereas the current size of the Kubuntu iso is 2.2G. So as Ubuntu increasingly converts to snap, I will be interested to see if this difference gets larger than 0.2G.

From what I have found so far, I am becoming increasingly concerned how Kubuntu 20.04, by using the Canonical and Launchpad sites, can escape the snap invasion. Will Blue Systems be able to develop their own deb repositories from Canonical?

[oshunluvr]

Interesting discussion, but I'm late in the game so I have questions: What's the existential issue everyone has with snaps? Is it the extra processes or feeling like it's not controllable or disk space or what

I have been looking at snap or flatpak or appimage as yet another way to manage applications and choice is generally good. Being able to install an application in "box' if you will, so that it's not mucking about with my OS is a good thing, right? I've been of the habit to mostly use the old-school processes to install stuff, but I'm old in the Linux world so my defaults are from the previous century. Currently I use a couple apps that are cross-platform and the linux versions are appimages. For exampe, Etcher is one that is an Appimage for Linux and also available for Windows as a "Portable" executable, which I feel like is the equivalent. Etcher looks, feels, and operates exactly the same in both OSs. I think that's a great thing.

GIMP is available as a flatpack but also something called "FINK" which I had not heard of until today.

Apps as stand-alone packages as a concept I like. It would be nice if they'd settle on one format, but I suspect there are reasons for the various options.

[Snowhog]

Only having casually observed commentary (here in KFN) about snaps, is the (sloppy) nature of how snapd handles terminated snap applications; all the mount points that get left?

If the developer(s) could work to ensure that all CRUFT is cleaned up when a snap app is terminated, then maybe those who find snap apps undesirable may think otherwise.

[WWDERW]

For exampe, Etcher is one that is an Appimage for Linux and also available for Windows as a "Portable" executable, which I feel like is the equivalent. Etcher looks, feels, and operates exactly the same in both OSs. I think that's a great thing.

Etcher is actually an Electron app which helps in going a long ways to look, feel, operates the same. There is little difference in good between Linux and Windows (unless getting into very sophisticated apps), however, when targeted Darwin (Mac), there is at least one line of code difference.

Apps as stand-alone packages as a concept I like. It would be nice if they'd settle on one format, but I suspect there are reasons for the various options.

I wholeheartedly agree. The vast majority of my production software is either Electron (as AppImages), AppImages of native apps, and/or binary archives of native apps. It, however, doesn't appear to me that snaps are portable in the same regard. They still depend on a repo/store in order to install and use for the most part. That dependency, in my mind, negates it as a portable app. Same with flatpaks.

[Don B. Cilly]

What's the existential issue everyone has with snaps? Is it the extra processes or feeling like it's not controllable or disk space or what

Ahem. I think I linked this at least three times in this tread.
With mentions of filesystem clogging and pathetic boot times.
I also guess no-one bothered to read it (the first post in the thread is enough.)

I have nothing against the idea of self-contained or portable apps. I have no problems with appimages. I have no experience of flatpaks.
The idea of snaps in fine... up to a point.
The implementation is absolutely horrible.

[WWDERW]

The implementation is absolutely horrible.

Ironically, this is the thing that can kill great ideas, is how that idea is implemented.

To my knowledge flatpaks are like snaps, just backed by different entities. There may be nuanced differences between the two, but just a cursory looksee, that's the biggest that I am getting.