Focal Testing of Kubuntu 20.04 LTS

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

[WWDERW]

See, the dependency issue is exactly why I prefer portable programs over installed ones. Now, I'm not a fan of snap/flat just because there is still a curated repo of such that it depends on.

Why I much prefer AppImages, binary archives and since I develop with this, even Electron (I know, that's probably going to get the biggest grimace, some deserved some just a function of bad programming practices and over dependency on some things that some programmers have that make some people think it's bloated in some ways when not really).

There are times that I have to use older program versions along with newer versions (typically because a function that I depend on has been deprecated in a newer version) and that can cause a lot of "fun". For AppImages and binary archives (not typically an issue with Electron, at least with the games/programs that I have developed while using that framework as everything that is needed is typically already bundled with it), I would prefer everything to be included in that archive. Even if it's libs that are already installed on the main system. Because I may use it on another system to where those libs are different enough to where it can't use that particular version. That's not everyone, I know, but that's just my experience with it.

[jglen490]

I have no use for snaps, and do not install any. Ditto on flatpaks. And I'm not that fond of appimages, either. The deb packaging makes sense in terms of providing and maintaining cohesive software that, in principle, fits into the Linux code and directory structure; as well as resolving compatibility and dependency issues among user application and system software. I've been through rpm hell before.

I have also used a distro, long ago and far away, that insisted on installing user applications in /opt. There was no attempt to resolve dependencies, everything went into its own subdirectory, including various and sundry library files. It may have been an older PCLinuxOS, but don't hold me to it. It was just a freaking mess.

If Canonical offers more snaps/flats as an option, that will be fine I'll continue to ignore them. If Canonical replaces deb packaging with snaps/flats for anything that I consider important or critical, I'll be gone.

[Don B. Cilly]

That "Complete Guide for Using Snap Packages" does not tell you what they actually do to your filesystems and boot times though, does it?