Focal Testing of Kubuntu 20.04 LTS

This topic is closed.

claydoh replied

Feb 13, 2020, 01:36 PM
We are beating dead horses here, and straying way more off topic than even my extremely laid back attitude towards it will allow.

Closing this.
Apologies to the OP, you can start a new topic, this was getting long all on its own.

As to the the difference of opinion, y'all can also start a new thread, disagree with each other, not change anyone's mind, and raise y'alls blood pressure over there
Top

Bottom
Leave a comment:
rec9140 replied

Feb 13, 2020, 12:50 PM
So just what are the roles of user and developer in re distribution?

Originally posted by Snowhog View Post

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.

I find the answer wholly unsatisfactory and disagree because of that dissatisfaction.

Let me give you an analogy in a part of my field... CPR.. I just tell you that you give compression's, and breathing as part of it. Leave at that. Mic drop. Class over. Now some EMT/PM|FF-EMT|PM shows up does what ever they feel like in regards to compression/breathing.. patient dies...You want to be part of that lawsuits? We already had basically something similar in re fire suppression.. with a death.

So basically I as a developer just post up the source and go have fun?

Users are left to dredge through source and make errors to find libs/dependencies?

Really thats the path to source distribution?

I'll give you an example of something of mine... it uses Python.. it requires some libs which I don't know that are distributed as the base in any distro.. I know at least in Debian/*buntu land they are not...but it seems like over time the "base" of this and some other stuff has changed and is no longer there.. How do I know... read on...

Now this really is only shared amongst some specialized users but they sill needed to know

sudo pip thislib etc.

So as I hinted at earlier how do I know the base has changed? The stuff was written for Python based on x distro.. its subsequently been used on x,y,z which are LATER versions of the Debian/*buntu based.. and some could run, some couldn't .

Why? MISSING LIBS!

So once I gave them all the readme.txt that says do: sudo pip libs

Poof errors Gone!

Lesson learned.. give users the info they need to use my stuff.

Some in y had the libs needed, z didn't.. Its sort of like ifconfig in 20.04 and even in 18.04 (I think) why in the planet would such a BASIC tool not be included?? Same with the base of an LXC container.. why would something so basic not be included? I just bang my head and scream when I run into this. Hence why we have to make an image after we do all this to install. (No I don't subscribe to the keep it small ISO collective, never have. 4GB DVD fill'r up!)

So I'd really like to get an honest answer of what the roles of users v. devs is in specifically in source based distribution models...

Cause let me tell you what I am reading..

Here is the source.. deal with it! Just figure it out.

I've gotten that on some stuff.. Not even the ./configure... or even just make and go.. just Here's the source! bye!

So users coming to the support forum of that software flooding it asking how to compile? You'd rather get that? Than take some time and look hey we installed a,b,c,1,2,3 and tell the users in the readme.txt? Thats such an onerous burden to go you need these packages?

So I have to be a C coder to use x software to figure out the make errors so I know what to install?

Well how about then we require BSEE's to use a cell phone. As that is exactly what you are advocating. Sort of do it like Amateur Radio before the Tech license change. Ask questions on the signals, draw a block diagram on the basics of the operation, maybe even for good measure we institute a 10WPM Morse requirement for a cell phone. Its not a phone its a radio which just makes convenient "autopatches."

I'll give you another example of a very sharp cookie.. this is ONE GUY developing some SDR software.. it uses java... The nightmare of getting that to run on Linux for the average user was a nightmare.. What did this ONE GUY do to cut off the support nightmare? All you have to do now is.. unzip it.. cd into a spot (clearly outlined) and then do ./sdrsoftware and it runs! Why? This sharp cookie includes the JVM needed for the software to run..

and no that is not advancing the snaps etc. plan... One guy figured out that to eliminate 99% of the install issues was a simple option to add to build in the JVM.. now all you have do is give them an archive of it.. The other part of this is clear and complete instructions. One guy doing that on something that is a hobby after a real job.

So my original question stands.. outline what role the user and the developer plays in this model?
Top

Bottom
Leave a comment:

claydoh replied

Feb 12, 2020, 12:01 PM

Originally posted by rec9140 View Post

From the initial install and the latest 400+ updates.. I get this:

Code:

essing triggers for initramfs-tools (0.133ubuntu14) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-12-generic
W: Possible missing firmware /lib/firmware/amdgpu/navi12_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/renoir_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_smc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module amdgpu

Yes, aware its alpha release.. I fully expect this to resolve itself in the near future.. but do I need to dig deeper and pull stuff out of linux-firmware.git etc.. or sit tight

??

Things seem to be working fine.. This is a Motile (Tadofung OEM for slimemart) M142 Ryzen R 3500 4 Core laptop.. it was a deal at $400 put about $100 into and it will be 32GB and 500GB as a second drive...so again. pleased with it and 20.04 as it goes... right now...

Any one else with similar setups

See this

??

Just like to prepare for further digger or if I should dig further now...

This is only a warning, and only matters if you have one of the AMD graphics cards listed in them. This new kernel probably needs some tweaks to add all the devices, or to find the modules to correct the warning. Usually it only list a small number with a new kernel (if any), but this one may have added support for a bunch of AMD cards, or something.

These only matter if you have an actual issue,

Leave a comment:

WWDERW replied

Feb 11, 2020, 07:30 PM
Originally posted by GreyGeek View Post

Does one encounter problems upgrading to new releases?

I can't speak for everyone that use that framework, but I haven't had a problem with it. I actually like it quite a bit. Some don't and I can see why they wouldn't, but I like it.

Some things I do release open source, some I keep closed. Depends on what it is.
Top

Bottom
Leave a comment:
kubicle replied

Feb 11, 2020, 06:46 PM
Originally posted by GreyGeek View Post

which costs $459/mo/seat. ($5,508/yr/seat). For the lone coder operating on a shoestring budget that Qt entry cost is a huge entry barrier.

A lone coder (or a small company) on a shoestring budget can get a commercial license for 499$/year in 2020. And Qt is also available under the LGPL, so you can use the libraries for free in proprietary software as long as you abide by the LGPL (dynamically linking to Qt is fine under the LGPL, for example)
Top

Bottom
Leave a comment:
GreyGeek replied

Feb 11, 2020, 05:55 PM
After reading some Electron info and watching some introductory tutorials the big difference I see between using Electron and the Qt API is that one can create proprietary binary applications using Electron, but to do that using Qt API one must buy a license, which costs $459/mo/seat. ($5,508/yr/seat). For the lone coder operating on a shoestring budget that Qt entry cost is a huge entry barrier. For a corporate developer, with sales in the 100K units or higher, not so much.

Before I settled on Qt I had tried several other dev tools. Those that were component based (Boa-Constructor, Eclipse, etc.) gave me problems with updating when the component versions were not synced. Electron is based on several components. Does one encounter problems upgrading to new releases?
Top

Bottom
Leave a comment:
WWDERW replied

Feb 11, 2020, 05:26 PM
Originally posted by kubicle View Post

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.

Originally posted by GreyGeek View Post

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

Last edited by WWDERW; Feb 11, 2020, 07:41 PM.
Top

Bottom
Leave a comment:
GreyGeek replied

Feb 11, 2020, 04:14 PM
Originally posted by WWDERW View Post

...

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

Bottom
Leave a comment:
kubicle replied

Feb 11, 2020, 04:08 PM
Originally posted by WWDERW View Post

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.

Last edited by kubicle; Feb 11, 2020, 04:10 PM.
Top

Bottom
Leave a comment:
WWDERW replied

Feb 11, 2020, 03:56 PM
Originally posted by kubicle View Post

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

Bottom
Leave a comment:
kubicle replied

Feb 11, 2020, 03:03 PM
Originally posted by WWDERW View Post

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.

Last edited by kubicle; Feb 11, 2020, 03:10 PM.
Top

Bottom
Leave a comment:
WWDERW replied

Feb 11, 2020, 02:45 PM
Originally posted by Snowhog View Post

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

Originally posted by kubicle View Post

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

Bottom
Leave a comment:
Snowhog replied

Feb 11, 2020, 07:56 AM
Originally posted by rec9140 View Post

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

Bottom
Leave a comment:
kubicle replied

Feb 11, 2020, 07:46 AM
Originally posted by rec9140 View Post

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.

Last edited by kubicle; Feb 11, 2020, 08:27 AM.
Top

Bottom
Leave a comment: