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
Announcement
Collapse
No announcement yet.
Focal Testing of Kubuntu 20.04 LTS
Collapse
This topic is closed.
X
X
-
So just what are the roles of user and developer in re distribution?
Originally posted by Snowhog View PostWe 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.
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:
-
Originally posted by rec9140 View PostFrom 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
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...
These only matter if you have an actual issue,
- Top
- Bottom
Leave a comment:
-
Missing Firmware error
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
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...
- Top
- Bottom
Leave a comment:
-
Originally posted by GreyGeek View PostDoes one encounter problems upgrading to new releases?
Some things I do release open source, some I keep closed. Depends on what it is.
- Top
- Bottom
Leave a comment:
-
Originally posted by GreyGeek View Postwhich 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.
- Top
- Bottom
Leave a comment:
-
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:
-
Originally posted by kubicle View PostI 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".
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 ...
Etcher, Atom, Slack, WhatsApp are well known electron apps.Last edited by WWDERW; Feb 11, 2020, 07:41 PM.
- Top
- Bottom
Leave a comment:
-
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.
**wanders off to look up the Electron framework ...
- Top
- Bottom
Leave a comment:
-
Originally posted by WWDERW View PostProviding automatic builds would, in my mind, make the need for detailed build instructions moot
"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:
-
Originally posted by kubicle View PostAbsolutely. 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.
- Top
- Bottom
Leave a comment:
-
Originally posted by WWDERW View PostEven 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).
Otherwise I do not disagree with you.Last edited by kubicle; Feb 11, 2020, 03:10 PM.
- Top
- Bottom
Leave a comment:
-
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."
"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 PostAll 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.
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:
-
Originally posted by rec9140 View PostAnd 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
- Top
- Bottom
Leave a comment:
-
Originally posted by rec9140 View Postif 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..
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:
Leave a comment: