Focal Testing of Kubuntu 20.04 LTS

[kubicle]

Just throwing this in: Kubuntu Focus (which ships with 18.04) has Google Chrome factory-installed. See this video at around 1min 10sec into the video.

Not an option for me, as Google Chrome's source code is not entirely free (it includes proprietary binary blobs form Google), so there is no way of telling what the hell it does. I use several browsers, but all of them are free software (that's the only thing I trust when it comes to browsers).

I am beginning to wonder about the current debate over using package management with snap. Does this debate have some parallels with the debate over the introduction of systemd?

I guess that depends on your point of view, but for the record, I have never had any objections to systemd as an idea (and definitely don't wish to steer this thread into a systemd debate). For me, the software debates come down to "Is that something I'd like to use, and do I see it improving the current situation". The one thing that linux lacked was a decent (universal) init system, which systemd provides. It had it's issues in the beginning, but all are/were solvable because there is actually solid software engirńeering behind it (even with it's issues, I embraced it from the beginning, because even with the issues, it was still clearly better than what we previously had).

Not so with snaps, which are basically just one of those "Canonical - hey we can do that, too...while we actually can't" ideas. I'm not against the idea of compartmentalized software distribution for 3rd party software, I have a few appimages installed and would not hesitate to install flatpaks if I needed to (so far I haven't had such a need). It's just that other vendors know how to code these things, Canonical doesn't (and in their typical MO they are just dividing the field and trying to control it with an in-house inferior
solution when there are actually better options already available). And obviously "forcing" them to users fits that MO perfectly, and I for one will have none of it.

Also, Canonical CLA will ensure the snap development always stays in-house (and the licensing can change on a whim), No other linux vendor will ever participate in it's development, because no linux company (or a sane individual developer) would accept that CLA. (And yes, you can install snaps on many distributions, but none aside from ubuntu actively support it). The iron rule is: "if it's development happens under Canonical CLA, it is going to die (in one way or another)"

[NoWorries]

I am beginning to wonder about the current debate over using package management with snap. Does this debate have some parallels with the debate over the introduction of systemd?

I was not familiar with the features of snap, so I decided to find out about it. For those who visit this forum and do not know about snaps, you can find a "Complete Guide for Using Snap Packages In Ubuntu and Other Linux Distributions" at: https://itsfoss.com/use-snap-packages-ubuntu-16-04/.

[chimak111]

Just throwing this in: Kubuntu Focus (which ships with 18.04) has Google Chrome factory-installed. See this video at around 1min 10sec into the video.

I don't use either browser much now, but I remember having some difficult with Google Drive on Chromium but not on Google Chrome.

[WWDERW]

I know (now), and that is what I find a bit worrying. If neon (based on 20.04) starts to push snaps instead of debs, I'll switch to something that isn't based on *buntu faster than it took me to write this.

There is no way in hell I'll ever have any snaps on any of my rigs. I can certainly get something like chromium from elsewhere, but why bother to stick with *buntu base if more-and-more things are going to replaced by craps, I mean snaps.

I would do that as well, but A. my rig is finicky when it comes to other distros and B. if it doesn't come with xsetwacom ready to go, it isn't much use to me. Only other way I know to get it is to build it ones self and I have zero success with that.

[kubicle]

The forcible change to chromium-as-snap-only came in 19.10. So neon users are unaffected (until neon moves to 20.04 as its base).

I know (now), and that is what I find a bit worrying. If neon (based on 20.04) starts to push snaps instead of debs, I'll switch to something that isn't based on *buntu faster than it took me to write this.

There is no way in hell I'll ever have any snaps on any of my rigs. I can certainly get something like chromium from elsewhere, but why bother to stick with *buntu base if more-and-more things are going to replaced by craps, I mean snaps.

[chimak111]

Thanks, I figured that one out already and edited my post (as I'm on neon I haven't been as much in touch with *buntu changes/development, but it is obviously already circling the drain)

The forcible change to chromium-as-snap-only came in 19.10. So neon users are unaffected (until neon moves to 20.04 as its base).

A "discussion" is here: https://discourse.ubuntu.com/t/call-...ansition/11179

[WWDERW]

Thanks, I figured that one out already and edited my post (as I'm on neon I haven't been as much in touch with *buntu changes/development, but it is obviously already circling the drain)

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.

[kubicle]

I believe the chromium browser does come in as a snap versus as a deb package. At least when I tried it get it on 19.10, I do not know about 20.04, I didn't bother installing it since it came in as a snap. I would prefer an AppImage over a snap, even if it is a large AppImage.

Thanks, I figured that one out already and edited my post (as I'm on neon I haven't been as much in touch with *buntu changes/development, but it is obviously already circling the drain)

[WWDERW]

Really? chromium-browser package depends on snapd on *ubuntu 20.04? (that's madness, if that's the case I'd get chromium from another source) or chromium-browser was installed as a snap package and not as a deb?

I believe the chromium browser does come in as a snap versus as a deb package. At least when I tried it get it on 19.10, I do not know about 20.04, I didn't bother installing it since it came in as a snap. I would prefer an AppImage over a snap, even if it is a large AppImage.

[kubicle]

The side effect of uninstalling (or purging) snapd is that it takes the chromium-browser with it.

Really? chromium-browser package depends on snapd on *ubuntu 20.04? (that's madness, if that's the case I'd get chromium from another source) or chromium-browser was installed as a snap package and not as a deb?

EDIT: Looks like the chromium-browser apt package actually installs the snap version in later versions of *buntu (which explains why it would depend on snapd):
https://packages.ubuntu.com/search?k...romium-browser

So your chromium-browser should actually be a snap
https://snapcraft.io/blog/chromium-i...nap-transition

[GreyGeek]

You shouldn't need to manually disable/remove anything, simple "sudo apt --purge autoremove snapd" followed by a reboot should remove it completely.
("list-units" reports units that systemd has *in memory* [not what is installed on disk] the snap units will be gone after a reboot)

The side effect of uninstalling (or purging) snapd is that it takes the chromium-browser with it. As I wrote, the easiest thing for me to do was reinstall chromium-browser, which brought along snapd with it, even though I used the "--no-install-recommends" switch, and then used systemctl to disable it, and every other service with snapd in its name. The reboot cleared everything.

I read somewhere about not having to use sudo for user service settings but habit is a habit with me. Between it and DuckDuckGo that's about the sum total of my memory.

PS - Thanks for the reminder, Kubicle. When you post I'm reminded of the EF Hutton ad, "When EF Hutton speaks people listen". You're EF Hutton on the KFN.

[kubicle]

Great recipe GreyGeek, I will at some point probably reinstall and follow your lead to purge the system of Discover and snap.

You shouldn't need to manually disable/remove anything, simple "sudo apt --purge autoremove snapd" followed by a reboot should remove it completely.
("list-units" reports units that systemd has *in memory* [not what is installed on disk] the snap units will be gone after a reboot)

[kubicle]

Quick tip. You do not need to "sudo" systemctl list-units (it'll work fine as a regular user, as do most systemctl commands...technically all of them since it uses policykit and knows when to ask for elevated privileges if necessary, but there is no harm in using sudo if you know it needs them). But for list-units, it's just "useless use of sudo™", technically you can sudo it just fine, but it's "best practice" to use sudo only when necessary than just out of habit.

[Don B. Cilly]

not@all:~$ sudo systemctl list-units | grep snapd
[sudo] password for not: 
not@all:~$

user@host says it all

[GreyGeek]

After I masked snapd.service I got to wondering if there were any other snapd artifacts hanging around. So, I did

sudo systemctl list-units | grep snapd
and found snapd.seeded.service, snap-snapd-5754.mount and snapd.socket.

I disabled them:
sudo systemctl disable snapd.seeded.service
sudo systemctl disable snap-snapd-5754.mount
sudo systemctl disable snapd.socket

and redid the listing:
sudo systemctl list-units | grep snapd

and it returned nothing. I rebooted and did not find any snapd artifact in the units listing of systemctl.

My system is now truly free of snapd and discover.