Focal Testing of Kubuntu 20.04 LTS

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

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

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

[Don B. Cilly]

...

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

[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

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

[jglen490]

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

While I would hope not, and while I'm not a fan of snaps, it comes down to choice. If "everything" does change to snaps, I'll make my choice and be gone to some other distro or some other OS. Simple, and no regrets.

[WWDERW]

I have to wonder, if everything is migrating to snaps, does that mean that the pre-installed applications will also be converted to snaps as well (for those that have snaps available)?

[jlittle]

I am beginning to wonder about the current debate over using package management with snap.

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

[WWDERW]

I generally get .deb packages from the repository, and on increasingly more rare situations, the PPA.

If I have to get something from a PPA, I'll run a live ISO in a VM, setup the PPA, download all binaries (including the depends, even the libs that may be on my system or the system that I'm getting the binaries on) and then bundled that as an AppImage.

I can't remember exactly how many AppImages that I have, because some of my Electron apps (all of the ones that I create are) bundled as AppImages as well.

However, studies have shown that less than 3% of Linux users contribute or pay for their ISO and/or applications.

That is a significant problem. I see it all over though and it's really not good long term. Especially those that are really on par with the commercial counterparts, I mean really on par and stable.

It isn't all that sustainable and at some point, devs are going to have ask themselves is it worth supporting this program with little to no donations or is it worth supporting this program for this specific platform that people expect everything to be free? To me, if I use it to make money and it is worth being in my workflow, it is worth contributing something to it, what I can. Sometimes that's monetary, sometimes that's documentation, sometimes that's code, but something that can be measured is given back.

[GreyGeek]

I rarely go through the package manager as it is for my software (I like my AppImage and binary archives way too much). Before they started doing the snap deal, this just help cement it. I'll probably go back to Neon once it gets on the 20.04 base, I just wanted to see what it was going to be like with Kubuntu.

I generally get .deb packages from the repository, and on increasingly more rare situations, the PPA. Other than that I prefer to get apps via AppImage precisely because it doesn't put a constantly running daemon into the process stack and AppImages do not modify my installation, and some of them can automatically update. An AppImage application runs entirely within the AppImage itself, sort of like using loop on an ISO file. I am currently using 9 AppImage applications.

I thought about moving to Neon but snap is moving up the chain and when Neon stages on 20.04 they will, defacto, adopt snap, unless they deliberately make it an uninstalled option or remove it entirely from their repository. I vote the latter. Why? It is obvious that snap is Canonical's way of creating an app store to monetize access to certain (eventually all?) applications. Of course, regardless of how many people use the same ISO to install Ubuntu/Kubuntu/Neon, the snap store would mean that each would have to pay for monetized apps. This would be a more reliable source of income for Canonical than selling the ISO. I would much rather pay for the Kubuntu ISO (with all the rights the GPL gives me) than be micropaymented to death at the snap store level. Between May of 1998 and November of 2004 I paid between $20-$30 each for 25 consecutive versions of SuSE, each on a CD purchased from WindRiver. I considered it money well used. However, studies have shown that less than 3% of Linux users contribute or pay for their ISO and/or applications.

Only a two things hold me to the Ubuntu base: Kubuntu (the BEST KDE implementation on the planet), and BTRFS (the best filesystem on the planet) deployment method of @ and @home. OpenSUSE creates 16 BTRFS subvolumes during installation, along with an EXT4 for /boot and a swap partition. From my POV that many partitions would invite snapshot mixups which would break a system if incompatible snapshots were restored.

I have found a way to neutralize snapd using systemd, so as long as I am able to do that, and Canonical doesn't attempt to restore snapd with future updates or block attempts to neutralize it, I will continue to use Kubuntu 20.04 until its EOL, or mine, whichever comes first.