Focal Testing of Kubuntu 20.04 LTS

[kubicle]

When I installed the 20.04 beta ISO it included snapd by default. Maybe it will be removed by the time it goes gold.

Yes, the backend systems for both snaps and flatpaks are installed (this includes snapd), so one can install snaps or flatpaks if one wants to (like the chromium-browser). I meant that the software installed by default on kubuntu are regular debs and no snaps (and snapd can be purged without removing anything essential).

I considered this to be a realistic real world test of snap performance which was to say the least, unimpressive.

They will always be resource hogs, that's sort of built in to the design, isolated libraries and all. Slower start, bigger memory footprint, more disk space etc. But that just one of the technical problems that exist. And besides all the technical problems, it's never going to reach it's goal as an universal solution, it can't and won't happen under Canonical's CLA. Flatpak a least has a chance for that, as it's development model is more inclusive. Of course neither should IMO replace regular debs (it's not broken, despite some claims that suggest that) but there is a niche for contained software packages as an option (but only as an option).

[chimak111]

Anyone running Kubuntu 20.04 notice that the "Lock Widgets" option in the right mouse desktop context menu is missing? Oversight or permanent?

https://www.kubuntuforums.net/showth...ion-in-5-17-90 ?

[GreyGeek]

Anyone running Kubuntu 20.04 notice that the "Lock Widgets" option in the right mouse desktop context menu is missing? Oversight or permanent?

[NoWorries]

As far as the technical issues are concerned, this one sums up some of them quite nicely:
https://www.reddit.com/r/Ubuntu/comm..._increasingly/

This is a very detailed reference which was made 11 months ago and Canonical have since announced a 6 times speed up improvement at: https://www.omgubuntu.co.uk/2019/03/...een-identified.

The snapd version with the improvements is from 2.36.2. The version of snapd that I did the speed test in my post #125 was 2.43, so this is definitely the latest version which is still slow. If this is 6 time faster, the older versions must have been abominably slow.

I should mention that the file I was doing the test on was an impress odp file that had 59 slides with 3 videos. The odp file size was 146.6 MiB. I considered this to be a realistic real world test of snap performance which was to say the least, unimpressive.

[GreyGeek]

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

When I installed the 20.04 beta ISO it included snapd by default. Maybe it will be removed by the time it goes gold.
Regardless, it is an easy move to uninstall snapd & chromium-browser.

But, even after doing that I find that after rebooting mount points for chromium-browser continue to be mounted.

snap-chromium-986.mount                                       enabled        
snap-core18-1650.mount                                           enabled        
snap-gtk\x2dcommon\x2dthemes-1440.mount    enabled

so I disabled them as well:

jerry@Aspire-V3-771:~[B]$ systemctl disable snap-chromium-986.mount [/B]
Removed /etc/systemd/system/multi-user.target.wants/snap-chromium-986.mount.
jerry@Aspire-V3-771:~[B]$ systemctl disable snap-core18-1650.mount [/B]
Removed /etc/systemd/system/multi-user.target.wants/snap-core18-1650.mount.
jerry@Aspire-V3-771:~[B]$ systemctl disable snap-gtk\\x2dcommon\\x2dthemes-1440.mount[/B] 
Removed /etc/systemd/system/multi-user.target.wants/snap-gtk\x2dcommon\x2dthemes-1440.mount.
jerry@Aspire-V3-771:~$

[kubicle]

As far as the technical issues are concerned, this one sums up some of them quite nicely:
https://www.reddit.com/r/Ubuntu/comm..._increasingly/

[Don B. Cilly]

Well, if they don't splash
loop99 7:99 0 888.4M 1 loop /snap/core/7169
all over the filesystem and don't add two seconds at boot each... they're not as bad :·(

[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.

[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]

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.

[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.

[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.

[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?

[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.

[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.