Focal Testing of Kubuntu 20.04 LTS

[Don B. Cilly]

Just out of curiosity, why would you want to have Chromium even though it's snap-only?
Brave for example is basically Chromium, it's open-source and does not come as a snap.

[GreyGeek]

....
IMO the technical implementation is a mess (that can't easily be fixed) and how the whole snap infrastructure should be quickly placed to the same recycle bin where you find the rest of Canonical garbage (upstart, unity, mir) that all ended up there because Canonical stubbornly refuses to understand how the free software ecosystem works and how to work with it rather than trying to do their own thing and trying to coerce everyone else to accept their crappy excuse for software engineering.

It would be perfect if snapd were resting comfortable along side upstart, unity and mir in the trash bin. Something to hope for.

Since that may take a few months or years, my next concern is what Canonical plans to do with the repository that has accompanied Ubuntu/Kubuntu since their inception? They are redundant sources of application but will the repository contain the best and the latest, or will it shrivel on the vine and die? Discover/Muon/Synaptic have no running daemons and are not active when the user is not actually removing, installing or updating their applications. Snapd is in our face all the time. Flatpak requires that you "add remotes" (repositories) despite the fact that we have a repository already. So, in affect, it becomes just another PPA.

For years I've seen the packages in the repository grow in number from 35,000 to 85,000 and drop back to 65,000 only recently (dropping 32bit packages?). I can't imagine, at this point, that snapd or flatpak would have access to that many packages. All Canonical is doing is throwing mud into what was once a sparkling pool.

[GreyGeek]

Appimages don't really have a centralized store to find them, the format is basically meant for developer direct distribution. I'd probably use great care for picking them up on just any site that provides them en masse, the trustworthiness of such images is not easily determined, probably better to rely on appimages that are straight from the developer (this is what they are meant for).

It is obvious that AppImages don't have a "repository" in the regular sense, and the importance of site selection is also obvious.

With the discover backend installed by default, you can install them directly from Discover, not really complicated at all. Link: https://pointieststick.com/2018/01/1...t-in-discover/ (I am assuming the flatpak backend is installed by default on 20.04, but I'm not 100% sure, but in case it isn't, it's just one "apt install" away)


Due to the technical implementation of snaps, it's snapd's job to create the loop mounts (and other "plumbing") for the snap you run, so it's necessary to have the daemon running for running installed snap software (it's not just for installing, updating and removing snaps), terminology explained: https://askubuntu.com/questions/9634...nappy-refer-to


And that is a snap package, not a regular deb so it needs the snap "plumbing" to work. (https://snapcraft.io/blog/chromium-i...nap-transition)

Except that I deliberately removed snapd, and its sockets and its "plumbing" (squashfs mount points that chromium used), and chromium-browser. BTW, reinstalling snapd did not re-create the mount points. I had to do that manually. That's when I decided to forget the trench work and just roll back. Three minutes later I was running my 20200122 snapshots and 5 minutes later I had 202 updates installed.

[GreyGeek]

Then it's not 5.17.90 (which is 5.18 Beta), the lock mode is already gone in the beta.

Hmmm... could have fooled me. Here's the screen capture:

[kubicle]

kubicle, that is true. Just like any OS isn't totally without it's exploits for viruses, just some have less of a chance of getting them.

The thing that gets me is that with snaps, you have the performance hit of an Electron app (despite most snaps being written with low level languages that have direct access to hardware and this is coming from someone that not only likes Electron apps, but develops using that technology as well) without the true portability (other then the user not being bound to dep, rpm etc packages, which even that isn't all that true since deb and rpm packages are essentially compressed files and get be treated like a zip, tar, rar file) of a binary archive, .run. and/or AppImage.

So one has the hit of a containerized app, but very little benefit.

Now, my preference for portable/contained apps really isn't from the security aspect, but I don't like my production software bound to the OS system/libs to where I have to worry about updating this, that or the other breaks compatibility (and it may not be updating the snap itself, but a library that is updated breaking an extension that I use often. That type of thing). With snaps they always tough this always be up to date, but I may not want that for every piece of software as well. Some things yes, but not everything. But I certainly don't want an app that is already resource intensive (internet browsers) being even more so.

I don't disagree with you, and I'd absolutely hate it if someone feels I'm "defending" snaps here.

I've been quite vocal (even excessively so) about how IMO the technical impletentation is a mess (that can't easily be fixed) and how the whole snap infrastructure should be quickly placed to the same recycle bin where you find the rest of Canonical garbage (upstart, unity, mir) that all ended up there because Canonical stubbornly refuses to understand how the free software ecosystem works and how to work with it rather than trying to do their own thing and trying to coerce everyone else to accept their crappy excuse for software engineering.

[WWDERW]

kubicle, that is true. Just like any OS isn't totally without it's exploits for viruses, just some have less of a chance of getting them.

The thing that gets me is that with snaps, you have the performance hit of an Electron app (despite most snaps being written with low level languages that have direct access to hardware and this is coming from someone that not only likes Electron apps, but develops using that technology as well) without the true portability (other then the user not being bound to dep, rpm etc packages, which even that isn't all that true since deb and rpm packages are essentially compressed files and get be treated like a zip, tar, rar file) of a binary archive, .run. and/or AppImage.

So one has the hit of a containerized app, but very little benefit.

Now, my preference for portable/contained apps really isn't from the security aspect, but I don't like my production software bound to the OS system/libs to where I have to worry about updating this, that or the other breaks compatibility (and it may not be updating the snap itself, but a library that is updated breaking an extension that I use often. That type of thing). With snaps they always tough this always be up to date, but I may not want that for every piece of software as well. Some things yes, but not everything. But I certainly don't want an app that is already resource intensive (internet browsers) being even more so.

[oshunluvr]

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.

You have no obligation to reply, so feel free not to. I stated I was late to the thread.

[kubicle]

Doesn't Snap have some of that concern as it is up to the person uploading the snap for distribution. It doesn't have the curated aspect as it would with regard to the deb packaging.

To a degree, of course (the situation is roughly similar to the ppas, which are mostly used for similar purposes), but we can't really know for sure that everyone that has upload rights to official deb repositories is 100% trustworthy either. We generally choose to trust official repositories because we trust the maintainers of the infrastructure to care enough to remove malicious code if it's distributed through them (it's still a system of trust, and not an absolute guarantee).

Some links:
Malware in the snap store: https://snapcraft.io/blog/trust-and-...the-snap-store (could obviously happen in any application delivery format, be it the repos, ppas, snap, flatpak or appimage)
Snap containment is vulnerable under X: https://itsfoss.com/snap-package-securrity-issue/ (not specific to snaps, of course, just that the "containment' offers very little security, although this might (should) improve on wayland)

[WWDERW]

Appimages don't really have a centralized store to find them, the format is basically meant for developer direct distribution. I'd probably use great care for picking them up on just any site that provides them en masse, the trustworthiness of such images is not easily determined, probably better to rely on appimages that are straight from the developer (this is what they are meant for).

Doesn't Snap have some of that concern as it is up to the person uploading the snap for distribution. It doesn't have the curated aspect as it would with regard to the deb packaging.

And that is a snap package, not a regular deb so it needs the snap "plumbing" to work. (https://snapcraft.io/blog/chromium-i...nap-transition)

And that is why I don't consider snaps a truly portable platform. Have the performance/storage hit of a portable program, but without some of the true benefits of the program being truly portable. Due to that, I would hate to see something like Ardour as a snap.

[kubicle]

and "Unlock Widgets" shows up on the right mouse click on the panel.

Then it's not 5.17.90 (which is 5.18 Beta), the lock mode is already gone in the beta.

[GreyGeek]

...
In 5.18 there are basically two modes: "Normal mode" (You can change some things, basically replaces the old "locked" mode, but you can still perform some non-destructive edits) and "Edit mode" (You can change everything) which I think improves the workflow of interacting with your desktop (although my opinion is based only on screenshots/casts, as I have not tested/used the 5.18 yet)

To clean up my system from my messing around with snapd, flatpak and AppImages I rolled back to my 20200122 backup.
It's plasma shell is 5.17.90, and "Unlock Widgets" shows up on the right mouse click on the panel. Now to upgrade to 5.18.

[kubicle]

For AppImageHub, it didn't look good.
I did find linux-apps.com which offers around 600 AppImages

Appimages don't really have a centralized store to find them, the format is basically meant for developer direct distribution. I'd probably use great care for picking them up on just any site that provides them en masse, the trustworthiness of such images is not easily determined, probably better to rely on appimages that are straight from the developer (this is what they are meant for).

Installing flatpak was a total pain. Way too complicated.

With the discover backend installed by default, you can install them directly from Discover, not really complicated at all. Link: https://pointieststick.com/2018/01/1...t-in-discover/ (I am assuming the flatpak backend is installed by default on 20.04, but I'm not 100% sure, but in case it isn't, it's just one "apt install" away)

It made me stop and think. Why is snapd running all the time when one isn't constantly installing or removing apps all the time? Metering and monitoring. Nothing else makes sense.

Due to the technical implementation of snaps, it's snapd's job to create the loop mounts (and other "plumbing") for the snap you run, so it's necessary to have the daemon running for running installed snap software (it's not just for installing, updating and removing snaps), terminology explained: https://askubuntu.com/questions/9634...nappy-refer-to

Then I installed the repository version of chromium-browser.

And that is a snap package, not a regular deb so it needs the snap "plumbing" to work. (https://snapcraft.io/blog/chromium-i...nap-transition)

[GreyGeek]

Snapd, Flatpak and AppImage

Since I have disabled snapd and its associated services, uninstalled the chromium-browser (replacing it with a binary version from the web) and unmounted the three squashfs mount points that the chromium-browser uses (but the binary version does not), I decided to look into the state of AppImage, my favorite way to install apps, and to see what Flatpak offered.

For AppImageHub, it didn't look good. Many of the AppImage packages haven't been updated in a year or more.

I did find linux-apps.com which offers around 600 AppImages, if you set the drop down combo box to display them. Most of them are a month or two old and contain images like LBRY, FireFox, LibreOffice (6.3.4.2), and other goodies. Linux-apps.com also displays 9 Flatpak packages, a meager offering, around 80 deb packages, about 95 source-code packages, and about 70 Windows binaries.

The best way to get AppImages is to go to the developer's website and see if they offer an AppImage, like LibreOffice does. But, demonstrating the decline in AppImage's fortunes, Open Broadcaster Studio offered an AppImage in July of 2017 and hasn't updated it since.

So, I decided to look at Flatpack. It was in the Kubuntu repository for 20.04. I ran
sudo apt-cache depends snapd

and obtained the following listing of programs that depend on snapd being installed on your system:

[B]jerry@Aspire-V3-771:~$ sudo apt-cache rdepends snapd[/B]
snapd
Reverse Depends:
  snap-confine
  ubuntu-core-snapd-units
  ubuntu-snappy-cli
  ubuntu-snappy
  ubuntu-core-launcher
  snapd-xdg-open
[COLOR=#ff0000]  python3-ubuntu-image[/COLOR]
[COLOR=#ff0000]  xubuntu-desktop[/COLOR]
[COLOR=#ff0000]  xubuntu-core[/COLOR]
[COLOR=#ff0000]  vanilla-gnome-desktop[/COLOR]
  ubuntustudio-desktop-core
  ubuntustudio-desktop
  ubuntukylin-desktop
  ubuntu-unity-desktop
  ubuntu-snappy-cli
  ubuntu-snappy
  ubuntu-mate-desktop
  ubuntu-mate-core
  ubuntu-core-launcher
  ubuntu-budgie-desktop
  snapd-xdg-open
  snapcraft
  snap-confine
  qml-module-snapd
[COLOR=#ff0000][B]  plasma-discover-backend-snap[/B][/COLOR]
[COLOR=#ff0000]  lxd[/COLOR]
[COLOR=#ff0000]  lubuntu-desktop[/COLOR]
  libsnapd-qt1
[B][COLOR=#ff0000]  kubuntu-desktop[/COLOR][/B]
  cyphesis-cpp
[B]  chromium-browser[/B]
[COLOR=#ff0000]  ubuntu-server[/COLOR]
[COLOR=#ff0000]  ubuntu-desktop-minimal[/COLOR]
[COLOR=#ff0000]  ubuntu-desktop[/COLOR]
  ubuntu-core-snapd-units
  livecd-rootfs
  command-not-found
  libsnapd-glib1
  gnome-software-plugin-snap

Installing flatpak from the repository will not re-install snapd. But instead, I downloaded a tar file from the web and added a remote:
sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
I can also install flatpaks from https://flathub.org/home

Installing flatpak was a total pain. Way too complicated. AppImages does not require any process to be running in the background at all, much less 100% of the time.

It made me stop and think. Why is snapd running all the time when one isn't constantly installing or removing apps all the time? Metering and monitoring. Nothing else makes sense.

I decided that I didn't care about Google, the NSA, CIA, or Homeland security sticking their nose in my business (how could I stop them even if I wanted to? They certainly no longer honor the Bill of Rights.) So, I don't care about snap, either. I removed flatpak and its remote, and I reinstalled snapd and rebooted. Then I installed the repository version of chromium-browser.

[kubicle]

I looked in System Settings for an administrator tool to unlock or lock widgets and didn't find any. I also did "kcmshell5 --list" to see if any plasma5 dialog was available that offered that ability. No joy.

The "locked" mode is not exposed anywhere in the gui because it is not really necessary any more, it was basically there because in the first iterations of plasma it was relatively easy to accidentally delete widgets ("where in the hell did my task manager disappear from my panel?"), much harder to do accidentally in later versions...and the setting wasn't really locked anyhow, since anyone could unlock with a few clicks. As I understand, you can still set a truly "locked" mode, or immutability, in the config files, but that's sort of for the rare kiosk-mode set up (and not really useful for common use cases of plasma).

So, to me, the panel looks like it is in a continuous state of edit mode when it comes to widgets and panel settings, because "add widgets", "Edit Panel" and "Add Panel" are always active, which wasn't the case when widgets were locked. IF there is a "Lock Widgets" option available to the user the developers have done bang-up job of hiding it. One could almost say "A windowish" job.

In 5.18 there are basically two modes: "Normal mode" (You can change some things, basically replaces the old "locked" mode, but you can still perform some non-destructive edits) and "Edit mode" (You can change everything) which I think improves the workflow of interacting with your desktop (although my opinion is based only on screenshots/casts, as I have not tested/used the 5.18 yet)

[GreyGeek]

I just checked this morning. It seems to be under "customized layout". Click that, it's unlocked and ready to be customized. Get out of that and everything is locked back up. I never noticed that as it wasn't there when I first install 20.04 and I already had my layout setup. I must say, just from a cursory look, I actually like the new way. That extra step always tripped me up doing it the old way.

I saw that "Customized Layout" and looked at it but it never indicated to me that it automatically did an "Unlock WIdget" command, since I can right-mouse on the panel and a " + Add Widget" option is available without going throught the "Customize Layout".

I looked in System Settings for an administrator tool to unlock or lock widgets and didn't find any. I also did "kcmshell5 --list" to see if any plasma5 dialog was available that offered that ability. No joy.

So, to me, the panel looks like it is in a continuous state of edit mode when it comes to widgets and panel settings, because "add widgets", "Edit Panel" and "Add Panel" are always active, which wasn't the case when widgets were locked. IF there is a "Lock Widgets" option available to the user the developers have done bang-up job of hiding it. One could almost say "A windowish" job.