Focal Testing of Kubuntu 20.04 LTS

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

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