WebSite Information > Article Discussions
Choice of update channel for eCS / OS2
Dariusz Piatkowski:
--- Quote from: Boris on August 01, 2015, 03:02:20 pm ---...Otherwise I do not understand how spending dmik's time on solving problems of users which are caused only by their incapability to manage their system environment themselves and their blind refusal to use a tool that does just this for them....This causes pain to me. Every time I see somebody searching (in WGet distributions on Hobbes!..) a library or a dependency (I have even made this...), or somebody with a whole shitload of different versions of everything everywhere on their systems... it hurts. And then they post issues at GitHub.
--- End quote ---
Boris,
That is simply an incredible statement from someone who proclaims to want to advocate for the OS/2 platform and is interested in improving OUR lot.
Were you honestly "born to OS/2" yesterday? I'm serious...your opinion on the subject of managing DLLs seems to be not only incredibly naive but borderline derogatory. Do you honestly belive that we, the left-over OS/2 users are a bunch of amateur hacks and newbies? Please recognize that for anyone to be still a part of OS/2 community today means he/she has to be knowledgable enough about the system to be able to troubleshoot, setup, manage, maintain, upgrade their environments as needed, with very little, if any, external support. So whatever "problem" exists on anyone's machine probably has a lot to do with previous attempts to install new releases, as they become available, as many different DLLs float around, as there is no "silver bullet" to fix all these issues today, even though you apparently claim to have developed this "silver bullet" in the case of your DLL tracker.
So please, do not insult the likes of us who have been attempting to keep the OS/2 platform viable by suggesting we are our own problem due to "...their incapability to manage their system environment themselves and their blind refusal to use a tool that does just this for them....", dear sir, you could not be farther from the truth!!!
IF it bothers you that the end-users out there do NOT have the matching OS/2 configuration you do, and therefore it makes your volunteer effort to help that much more difficult, I suggest you question whether you are volunteering in the right community? Perhaps you are looking for something much easier? Where there is a lot more of black and white and a lot less gray.
Boris:
Dariusz, I have failed to grasp the central point of your post, but here follows some of the misconceptions in it.
My DLL tracker is sometimes useful, but a bad, dirty hack, not a silver bullet.
I was obviously talking about RPM.
My environment is nothing special but currently just an eCS 2.2b2 with RPM/YUM environment of Netlabs.org.
And I have never ever had problems with Firefox caused by environment!
Contrary to those refusing to follow recommendations and failing to get along their own way. (Which is possible and may be justified.)
Dude, do you really even read the issue tickets?
--- Quote from: Dariusz Piatkowski on August 02, 2015, 02:13:29 am ---for anyone to be still a part of OS/2 community today means he/she has to be knowledgable enough about the system to be able to troubleshoot, setup, manage, maintain, upgrade their environments as needed
--- End quote ---
This is highly arguable.
I recall someone sharing a story here on OS2World forums he or she has been facing people at Warpstock who were not even aware of new Firefox ports (AFAIK that was it) and suffering because of new web sites not working with the version that came with their eCS distribution (AFAIK its version neither was not cutting-edge).
Boris:
--- Quote from: Dariusz Piatkowski on August 02, 2015, 02:13:29 am ---for anyone to be still a part of OS/2 community today means he/she has to be knowledgable enough about the system to be able to troubleshoot, setup, manage, maintain, upgrade their environments as needed
--- End quote ---
This is highly arguable.
I recall someone sharing a story here on OS2World forums he or she has been facing people at Warpstock who were not even aware of new Firefox ports (AFAIK that was it) and suffering because of new web sites not working with the version that came with their eCS distribution (AFAIK its version was neither cutting-edge).
Dariusz Piatkowski:
--- Quote from: Boris on August 02, 2015, 02:39:49 am ---Dariusz, I have failed to grasp the central point of your post, but here follows some of the misconceptions in it.
--- End quote ---
...OK, here it is: given the age of OS/2 and for how long there has NOT been a real enterprise type update system available (think Fixpaks, etc) there are far too many combinations of working systems, or perhaps 99.9% working systems to expect that a single RPM/YUM based deployment methodolgy is going to work. Since I readily acknowledge and accept the small OS/2 development team limitations I am perfect happy and willing to unpack the recommended RPM archives since I am currently in the non-RPM/YUM camp...and you would do us all a favour by NOT pretending like RPM/YUM is the only NORMAL/ACCEPTABLE way to go about installing applications.
If you do not wish to help with these issues, do NOT help...but please, do not belittle folks for apparently horrific system configurations they have...tell me, are you running a multi-core setup, did you try SMP before deploying ACPI.PSD solution, do you know how the SMP mode impacts memory utilization and can you tell me what is so horribly misconfigured on my machine that my 6-core box simply will not nicely boot up? Does it have anything to do with mulit-disk and a large HPFS386 cache configuration? Do you really think there is a RPM/YUM solution for that too???
--- Quote from: Boris on August 02, 2015, 02:39:49 am ---My DLL tracker is sometimes useful, but a bad, dirty hack, not a silver bullet.
--- End quote ---
Quite frankly, your DLL tracker is a great tool...I only wish that it was more prominently "published" and/or showcased as part of releases like Firefox...because it has the potential to help that part of our community who needs it.
--- Quote from: Boris on August 02, 2015, 02:39:49 am ---Dude, do you really even read the issue tickets?
--- End quote ---
Each and every day...I'm on the FF mailing list, so yeah, sometimes tens of emails a day, I read them all...because maybe one of them may have something to do with an issue I have seen, or perhaps I can help someone on there by providing positive feedback as I first attempt to understand their challenge.
Here is an example, why is JoopN having such a strange issue with downloads??? Maybe libc DLL problem...but it sure looks like he worked through that and yet the problem persists...what now??? Are you going to write that off as a RPM/YUM problem as well, regardless of what is the actual root cause???
What about the 100% CPU utilization symptom? I've seen that for quite some time now...happens regularly here when I do not run with SET NSPR_OS2_NO_HIRES_TIMER=1 option...there was a pretty extensive debug session once, I had logged a ticket on the 24.x release for this (as well as other issues)...is that a RPM/YUM issue too???
Here is a better one: take the official stdcpp6.dll RPM release file (libstdc++6-4.9.2.1-3.oc00.i386.rpm), the recently created moz_required_dlls_v1.03.zip has a different DLL in it altogether. Which one to use now?
libstdc++6-4.9.2.1-3.oc00.i386.rpm => 02/02/2015, 410187 bytes
moz_required_dlls_v1.03.zip => 01/02/2015 14:08, 388453 bytes
So...the point being again: be helpful and therefore productive in your help, merely saying that someone is incapable of configuring their system because they are seeing a problem/symptom you do not see on your machine is very much quite the opposite of helping!
Boris:
Sorry, I'm tired of this meaningless debate.
I'm not going to argue with every single statement (you've just gone crazy at some places), which you really wrote a lot (honestly I even didn't read your post thoroughly).
You are misperceiving me.
My position is very simple and well-justified: as long as a program's misbehavior is not reproduced with Netlabs.org RPM environment, the fault is considered to be located in the user's environment, not in the program or Netlabs.org RPM environment.
If you choose the non-RPM way, that's your choice. I never claimed it is wrong. It is not supported.
This is not done to lock someone into RPM. This is done to save resources. I wholeheartedly agree with this.
Non-RPM most probably will work (worked lots of times in my case), unless you are doing it wrong.
It is not a bug, stop wasting resources. You are doing it wrong (while pretending the other, standardized environment is bad, not faulty yours).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version