Focal Testing of Kubuntu 20.04 LTS

[NoWorries]

When I installed the latest updates using the command line, I noticed Discover snap packages being installed. So I checked with Muon and found snap for Discover. This is show in the graphic below.



These packages are only 295.0 KiB and 23.0KiB. Compared with the deb files which are 1.7 MiB and 8.8 MiB. I have removed them and Discover seems to still work. I must confess that I very rarely use it and keep it for when Muon configurer software sources fails, I can restore it with Discover.

[kubicle]

When I installed the latest updates using the command line, I noticed Discover snap packages being installed. So I checked with Muon and found snap for Discover. This is show in the graphic below.

[ATTACH=CONFIG]8655[/ATTACH]

These packages are only 295.0 KiB and 23.0KiB. Compared with the deb files which are 1.7 MiB and 8.8 MiB. I have removed them and Discover seems to still work. I must confess that I very rarely use it and keep it for when Muon configurer software sources fails, I can restore it with Discover.

Which packages?

The 'plasma-discover-backend-snap' and 'plasma-discover-snap-backend' are not snap packages, they are the snap backend for discover so one can install snap packages with discover if one chooses to (they depend for obvious reasons on snapd, but are not snap packages themselves, and can be uninstalled without issues if one chooses to...you just can't install snaps with discover without the backend). The reason there are two of them is that the package name has changed from plasma-discover-snap-backend > plasma-discover-backend-snap (and the former is now a transitional package that depends on the latter for smooth upgrades). There are also similar packages for the flatpak-backend, which aren't flatpaks, but regular debs (https://packages.ubuntu.com/search?k...lasma-discover).

plasma-discover is also a regular deb in the focal repos.

[NoWorries]

Thanks VERY MUCH for the clarification. This is important for those, like me, who do not want snap packages at this stage.

As you are probably aware, I tend to take risks. However, I only take those risks with Kubuntu sources and not those new ideas being promoted by Canonical.

[jglen490]

Well, there's always good old

sudo apt autoremove --purge snapd

It's supposed to get rid of all things snap-related

[rec9140]

kmix has it's own icon in the notification area, the other is the newer "plasma-pa" volume widget. And if I wasn't clear in my previous post, you only need to unmute once with kmix, you don't need to start it automatically at startup or even have it installed after that (So you don't need to have to volume icons in the notification area...of course you can also disable the plasma volume widget if you prefer kmix). Once you've unmuted once with kmix, it will continue to work even if you don't have kmix running or uninstall it.

You can still mute/unmute and change the volume in the settings (even if you previously couldn't). Continues to work even after reboot.

I prefer KMix.. and will likely remove the other widget as I find it bland, and brain dead.

That suggests systemsettings5 doesn't respect the DISPLAY env variable for some mysterious reason, when I have some free time I'll see if I'm getting the same. EDIT: Ah yes, have to wait for Plasma 5.18 and/or Neon 20.04 to test that, works fine on Neon 18.04/Plasma 5.17.5.

I didn't play with it to see if was not respecting it or otherwise... since it comes up on the desktop you probably are right its not looking at it or ignoring it... which tells me volumes... of why I have to fight to restore XDMCP support etc...

I am an "aptitude" guy (replaced synaptic for me a few years back), I don't use any GUI installers at all (or have any installed), just apt and aptitude (when I need to do more complex package management or browse packages).

I go back and forth between synaptic and apt.. just depends on which I type first...

I also don't shy away from compiling stuff if I need to.

I don't have an issue with compiling IF IF YOU DEVELOPERS FOLLOW THE RULES. 9/10 they do not.

What rules... COMPLETE RECIPES on what is needed to compile their software!

Don't give the trite ./configure make sudo make install line..

Your README.TXT should include

sudo apt-get install libsuperduper-dev livsuperduper, etc. right on down the line to all dependencies...

Don't expect me to decode 1000 lines of make errors to figure out libs/dependencies needed.

But there are also valid use cases for contained package formats, they don't need to go away (except snaps, of course ), but should always be just options, not forced. I also think Discover is fine for new users, or users who don't like to work with cli (although I think everyone should ).

I have ONE program which comes as appimage thingy... Etcher.. which I am fine with that... I can live with it.. as it doesn't spew 50 loop or what ever things all over the place etc..

DEB is an OUTSTANDING package management system.. compared to RPM (spit! pffft! spit! blech!) I don't know that rates right up there with some other garbage.. snaps, systemurd, pulseaudio...2 of those have bled their cancer into distros... and I am not going willingly with the first.. I fought the other 2 and lost those battles. ALSA is a great thing and can do a lot.. unfortunately you have to have written it or being able to figure out its black magic to get it to do all that it can like plugins, loopback..

I have no intention of giving into the loss of DEB!

These things are appealing to new users in line with the application "stores" on certain phones... meh.. not the path to take in my view... I think DEB via synaptic can offer all that is needed... Just new users are not willing to get into learning the steps... Like the sounds setup.. I don't mind digging through some menus.. but geez people.. that stuff is not very intuitive to me where its at now... its a least 2 layers too deep.

[kubicle]

I don't have an issue with compiling IF IF YOU DEVELOPERS FOLLOW THE RULES. 9/10 they do not.
What rules... COMPLETE RECIPES on what is needed to compile their software!
Don't give the trite ./configure make sudo make install line..
Your README.TXT should include
sudo apt-get install libsuperduper-dev livsuperduper, etc. right on down the line to all dependencies...

That isn't actually a rule. And is quite a bit more labor intensive than it sounds, as all distro families package things (and the development headers/libraries) differently. Of course, some developers might provide detailed dependency instructions (usually for the distro family they are running themselves, as the list is easy enough to put together), but it is a bit out there to demand a developer that runs arch or redhat (for example) to provide complete instructions for a debian based distro (or any distro X that you happen to run) and constantly monitor all packaging changes in every distro in existence, forever, to keep all the detailed instructions up to date.

Building stuff takes some extra work, that's why we have distributions and binary packages. If you build stuff that is available in the repos, there are apt commands to get the build dependencies quite easily (https://www.guyrutenberg.com/2017/09...get-build-dep/ and https://askubuntu.com/questions/2137...s-of-a-package). Unfortunately that only works for sources in the repos (which you usually don't need to compile, but it can help if you're compiling a newer version that is available in the repos).

Don't expect me to decode 1000 lines of make errors to figure out libs/dependencies needed.

"I'd rather they did the work than I" is a valid point of view, but it is just as valid from the perspective of the developer.

---
This is actually one of the problems contained package delivery offers one solution to. A developer can make an appimage (or flatpak) available for the freshest version of their software (which should work as is in any distro), and distributions can package things in their own package formats/repos based on their own update/release schedule. Best of both worlds, kind of. One can install binary packages from the repos (or build them if they so choose), and if you really need a version that is newer or software that hasn't been packaged yet by your distribution, you can get a contained package without much hassle (that is often associated with building from source).

[rec9140]

That is... source).

I think at this point. its pretty clear we don't agree on 99% of things.

While I see you perspective and point. No. if I am the developer I KNOW WHAT libs were needed to create my superduper software...

Telling some one to

download source
untar
cd to dir
./configure, make, sudo make install

and the they get 1000's of lines of errors because this lib, that lib, some other lib, even more lib is not there...

Thats my job as a user to figure out this Really ? Thats a USER PROBLEM? Thats rich.. really rich... and thats my public snowflake version.

Thats just pointless... the DEVELOPER KNEW THIS TO START. Advise the users.. You developed this you KNOW/KNEW you installed libsuper-dev and libsuper on your distro.. That is not that hard to cross between Debian/Ubuntu land and lesser package systems like RPM etc..

And the work you are saying this is for developer.. well thats part of developing software.

I don't see this as being a leg for snaps etc. to be the route forward over DEB...

There is no point in going further this is way off Focal development...and as I started off with ... we are not in agreement and never will be. And this site is not welcoming to vociferous discussions any way.

[kubicle]

if I am the developer I KNOW WHAT libs were needed to create my superduper software...
You developed this you KNOW/KNEW you installed libsuper-dev and libsuper on your distro.. That is not that hard to cross between Debian/Ubuntu land and lesser package systems like RPM etc..

Umm...no. While you can put a list of needed headers (and the list of packages needed to build for your own distro is relatively easy to get), the packaging (and package names) are not standardized between different distros, so while the needed headers might come in package 'libsuperduper-dev" in one distro, it might come in "superxthreadheaders-2.7" in another and "somethingcompletelydiffent" in yet another, finding out these for every imaginable distro out there is rather tedious (as you commonly do not have all of them installed). The information is much easier to get if you are actually running the distro in question (like when you are building it yourself, the build process will tell you what headers/libraries you need, and you can commonly get the packages these come in with your distro tools).

There is no reason for agitation, I apologize if I come across as confrontational (not my intention), I'm just telling you how things are. You don't have to agree, I'm fine with that. And you are of course just as free to voice your opinions, but developers don't owe you anything (or have to do any of the work for you, even if you think they should, unless you are paying them to do it)...you don't want to put an effort into building stuff, use the binary packages provided by your distro.

Also, software sources aren't normally directed at regular users (users that build from source are a very small minority), but at other developers and software distributors (who usually know very well what is needed in their distro). All extra time spent on doing things that will only offer any real benefits to very few, is always time away from doing things that will benefit basically everyone, like improving features, fixing bugs etc. Telling them what you think they should do does not magically increase the resources they have available for development.

[Snowhog]

And this site is not welcoming to vociferous discussions any way.

vo·cif·er·ous

/vōˈsifərəs/

adjective
(especially of a person or speech) vehement or clamorous.
"he was a vociferous opponent of the takeover"

expressing feelings or opinions in a very loud or forceful way

We do prefer that when expressing views and opinions we aren't 'loud or forceful'. We do welcome discussions. We are tolerant of others points of view. What we find problematic is providing qualified answers to questions and then being told the answer isn't satisfactory or to ones liking. "You can please all of the people some of the time, or some of the people all of the time, but you can't please all of the people all of the time." If that isn't a core tenant of programming, it should be.

[WWDERW]

"You can please all of the people some of the time, or some of the people all of the time, but you can't please all of the people all of the time."

Maverick had a little different approach to that.

"You can fool all of the people some of the time, some of the people all the time and those are pretty good odds." - Shady Deal at Sunny Acres

I can definitely see both sides to this (and I have developed software as well, although some people would probably call it lazy developing as it is with the Electron framework and not plain jane C++ or similar). And there is for sure a difference in the naming schema of packages between distros (one package that I get for mapping my drives on ubuntu its "x"-common and on say Arch it's "x"-utils.

As to using distro repos if don't want to build from source, some software is only available with building (unless they have say github setup to compile everything and have it under releases section of the repo), no other option. No PPAs, no AURs, nothing. That will take out the "normies", if it is only available via building from source. That could also take out a pool of users that could help with bringing in bug reports and/or feature requests as well.

It's not quite as black and white as lot of people would like to think.

All extra time spent on doing things that will only offer any real benefits to very few, is always time away from doing things that will benefit basically everyone, like improving features, fixing bugs etc.

Even github can be setup for automatic building and releasing various methods of distributing (deb, rpm, appimage etc) that a particular project may need without much continued effort for the dev (there would be some as the project changes and the setup needs to be changed accordingly and the initial outlay of effort, but in between it's fairly stable and automatic). The benefit to all that may use this particular software is that they don't individually have to go through the building process themselves and just download what they need/want and test that out. Builds that are generated from pull requests would be targeted to devs and latest releases would be targeted to those that need more production ready builds. It drastically improves efficiency for all and it overall improves the software as it allows more people to participate in it's testing, bug reporting and/or feature requests.

Now, for the devs that just release a project in the hopes that it helps others, but it was mainly done due to a need that the devs themselves had and that's it, it won't matter one way or the other I would imagine. And that's fine. It is what it is. It all depends on what the end goals are for the project. Those projects that fit into this later category are probably not going to be ones that are going to see a wide adoption as it is. And that's fine, I'm not trying to say that it isn't.

[kubicle]

Even github can be setup for automatic building and releasing various methods of distributing (deb, rpm, appimage etc) that a particular project may need without much continued effort for the dev (there would be some as the project changes and the setup needs to be changed accordingly and the initial outlay of effort, but in between it's fairly stable and automatic).

Absolutely. But the issue is not really about providing (automatically or not) built binary packages (which isn't too hard to accomplish), this is not really quite the same effort as providing detailed building instructions for every distribution imaginable, finding out which packages need to be installed in every distribution, and making sure the packages in distributions are not too new or old that your software is actually able to build on these, and do this 24/7 to the end of days while constantly rewriting your readme.txt for all of the changes (and to do this for the maybe 20 users who are actually building it from source themselves is a massive waste of effort).

Otherwise I do not disagree with you.

[WWDERW]

Absolutely. But the issue is not really about providing (automatically or not) built binary packages (which isn't too hard to accomplish), this is not really quite the same effort as providing detailed building instructions for every distribution imaginable, finding out which packages need to be installed in every distribution, and making sure the packages in distributions are not too new or old that your software is actually able to build on these, and do this 24/7 to the end of days while constantly rewriting your readme.txt for all of the changes (and to do this for the maybe 20 users who are actually building it from source themselves is a massive waste of effort).

Otherwise I do not disagree with you.

Providing automatic builds would, in my mind, make the need for detailed build instructions moot. There might be some differences between master and this or that pull request, but I wouldn't consider that something worry about. Certainly not for the "normies" that might otherwise need that extra help with regard to the build instructions.

[kubicle]

Providing automatic builds would, in my mind, make the need for detailed build instructions moot

I do not disagree. But I'll remind you that the statement that started this discussion was that (paraphrasing):
"The RULE is that *All developers* should put detailed instructions (in the every piece of software they develop) *in the README.TXT* that tells me what packages I need to install on my distribution to build their software".
And all I have tried to do is explain why that isn't a rule, or at least not one that makes any sense from any productivity-perspective.

[GreyGeek]

...

I can definitely see both sides to this (and I have developed software as well, although some people would probably call it lazy developing as it is with the Electron framework and not plain jane C++ or similar). And there is for sure a difference in the naming schema of packages between distros (one package that I get for mapping my drives on ubuntu its "x"-common and on say Arch it's "x"-utils.

I haven't coded a line since I retired in 2008, but before then I was using Kate and Kdb to develop client-server applications that would eventually be compiled on a WinX box and put on a WinX server, running against an Oracle db. Since I was using the Qt API I would use the Qt Designer to build wysiwyg windows and dialogs, but everything else was written using Kate. If anyone wants to call that "lazy" programming they'll have to show me their equivalent code written in ASM, or "better" yet, machine language.

**wanders off to look up the Electron framework ...

[WWDERW]

I do not disagree. But I'll remind you that the statement that started this discussion was that (paraphrasing):
"The RULE is that *All developers* should put detailed instructions (in the every piece of software they develop) *in the README.TXT* that tells me what packages I need to install on my distribution to build their software".

No, not even all developers. I would say that if the developers meet 2 criteria they should have automatic builds available in the repo of their software:

1. They want their software to reach the widest audience. In other words, they just didn't develop the software to scratch an itch and they released it hoping that others could benefit from it. They really wanted a high adoption.

and

2. There aren't compiled versions of their software in the repos of a distro. While yes, the repos may be outdated depending on the distro, they are still there.

If both of those conditions are met, then I would say something needs to be on there. That's just me. If it's not, I just move on.

Oh, I should also mention those that want to have a commercial, but open source product, I wouldn't fault them for having a less in the build documentation and/or releases in the repo. That would defeat the purpose and I could understand why they would want to do that. While open source doesn't in of itself mean free as in cost as well. A lot of people seem to forget that as well. It all depends on what the developer is trying to accomplish with it.

**wanders off to look up the Electron framework ...

It's essentially using web technologies to create hybrid cross platform apps. Biggest downside is that it depends on Chromium (and node.js) and that adds a lot of "heaviness" to the apps, although not on par with Snaps unless some of the JS coding is wonky (typically the person depends on JS more and not using CSS as much as they could have and that adds bloat).

Etcher, Atom, Slack, WhatsApp are well known electron apps.