Focal Testing of Kubuntu 20.04 LTS

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

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]

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.

[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

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

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

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

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

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

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

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

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

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

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.

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