Author Topic: Choice of update channel for eCS / OS2  (Read 17430 times)

eirik

  • Guest
Choice of update channel for eCS / OS2
« on: August 01, 2015, 04:08:22 am »
As some of the comments on Firefox 31.6 are quite distant from its headline, I have chosen to start a new tread.

Quote
P. S. The worst thing is that the very valuable OS/2 developers time is carelessly wasted on solving irrelevant problems of users failing to comprehend the readme file.

I am willing to bet $100 that Boris does not work with sales  :).  While I think it is important to have something substantial to sell, sales should not be disregarded as irrelevant.  If IBM had been better at promoting OS/2 in the 1990s, OS/2 may have been the leading operating system of today.  All our issues on missing drivers, appropriate software, way to few  development resources, etc. would have been a non-issue.  Unfortunately, these issues are real problems for OS/2 / eCS that contribute to leaving us where we currently are.

Any user, techie or non-techie, contributes to the development of OS/2 / eCS by paying for the operating system or for licensed software, and by providing feedback.  Admittedly, non-techie contributions are not as large as from those actively taking part in software development, but their contributions are not zero (or even negative) as Boris' statement above suggests.  Please, treat each other respectfully - we are too few to loose anyone.

However, Boris' remark touches upon one important issue - developers need to agree on a suitable and modern update channel.  Rpm-yum is one of those in some sense, but it has a high user threshold.  Moreover, it does not come without some effort as well. As for any update channel, developers need awareness on changes to the system.  Choosing an update channel that attracts rather than sends users away cannot be wrong?
« Last Edit: August 01, 2015, 01:54:47 pm by Eirik Romstad »

ivan

  • Hero Member
  • *****
  • Posts: 1558
  • Karma: +17/-0
    • View Profile
Re: Choice of update channel for eCS / OS2
« Reply #1 on: August 01, 2015, 10:45:43 am »
Quote
However, Boris' remark touches upon one important issue - developers need to agree on a suitable and modern update channel.

I would go further than that and say that developers and USERS need to agree on just how updates will take place.

We have WarpIn which works (yes, it does mean that the developers need to know how to write the install script) and then, out of the blue, we find that we have to use RPM/YUM, a problematic system that is being replaced by Linux because of the problems  - the least of which is that the user has to have a reliable WAN connection.  If you don't have the WAN connection you are up the proverbial creek without a paddle.

dbanet

  • Guest
Re: Choice of update channel for eCS / OS2
« Reply #2 on: August 01, 2015, 03:02:20 pm »
I am willing to bet $100 that Boris does not work with sales  :).  While I think it is important to have something substantial to sell, sales should not be disregarded as irrelevant.

Eirik, can you please clarify how do you justify your claim of logical equivalence of the following predicates?
Quote
problems of users failing to comprehend the readme file are irrelevant
and
Quote
sales are irrelevant

I can come up with an only assumption: you think bww bitwise works GmbH sells the Firefox port.

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.

I would bet you'd rather want dmik to work at porting Firefox, not as a first line support engineer.

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.



Ivan, I see you blame me in the neighbor thread I ignore your posts, but here is what.
You've also ignored a response to you regarding local repositories, and...

This debates are meaningless and are not making anyone more happy.
I am not going to heavily participate and argue with every statement I don't agree with.

I'll now better continue working on trying to solve this very exact problem.
« Last Edit: August 01, 2015, 03:32:39 pm by Boris »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Choice of update channel for eCS / OS2
« Reply #3 on: August 01, 2015, 07:21:41 pm »
Quote
However, Boris' remark touches upon one important issue - developers need to agree on a suitable and modern update channel.

I would go further than that and say that developers and USERS need to agree on just how updates will take place.

We have WarpIn which works (yes, it does mean that the developers need to know how to write the install script) and then, out of the blue, we find that we have to use RPM/YUM, a problematic system that is being replaced by Linux because of the problems  - the least of which is that the user has to have a reliable WAN connection.  If you don't have the WAN connection you are up the proverbial creek without a paddle.

I don't have a WAN connection and am managing to use RPM/YUM by using wget to fetch packages and having a local repository. It's not the best but it does work.
The real problem we have is a crappy old DLL system. We're limited to 8.3 name space, DLLs need to have the same internal name as the external name.  It is hard to version DLLs.
A package manager is one solution as it stores a database of everything installed with it. Unluckily a package manager does fail if the users are also installing software by other means, which OS/2 users are used to doing.
There's also the problem that there are only a couple of developers doing all the heavy lifting. Following Firefox development, dmik has done a lot of time consuming work to get our port working fairly well and the package manager saves him time so we're stuck with doing things the way he prefers.
Personally, if I had the bandwidth, I'd post 2 versions with one being statically linked.

eirik

  • Guest
Re: Choice of update channel for eCS / OS2
« Reply #4 on: August 01, 2015, 09:13:59 pm »
@Boris: I have never claimed that people should not try to read (and understand) the readme files.  On the contrary.  What I am saying is that some times the readme files require a level of technical knowledge that many users do not have.  Along the same lines: if it is not very time consuming to make installation of updates a bit more user friendly, why not do it.  I think it will solve a lot of problems (installs are correct and things work rather than developers having to do case-by-case explanations), and we lower the user threshold.

Regarding the second point on sales.  It was not meant literally, but like making people adopt certain perspectives.  I apologize if that was unclear.

Still, I stand by my two main claims:
  • It is important that we treat each other respectfully and to avoid driving people away - we need more OS/2 / eCS users.
  • Agreeing on a modern and user friendly way of installing updates will save many people, developers included, a lot of time and provide additional enthusiasm for OS/2 / eCS
I hope this clarifies matters.  We may still disagree on some issues, but that is healthy as long as the discourse brings us forward.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Choice of update channel for eCS / OS2
« Reply #5 on: August 02, 2015, 02:13:29 am »
...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.

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.

dbanet

  • Guest
Re: Choice of update channel for eCS / OS2
« Reply #6 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.

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?

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

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).
« Last Edit: August 02, 2015, 02:53:15 am by Boris »

dbanet

  • Guest
Re: Choice of update channel for eCS / OS2
« Reply #7 on: August 02, 2015, 02:48:19 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

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

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Choice of update channel for eCS / OS2
« Reply #8 on: August 02, 2015, 05:29:40 am »
Dariusz, I have failed to grasp the central point of your post, but here follows some of the misconceptions in it.

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

My DLL tracker is sometimes useful, but a bad, dirty hack, not a silver bullet.

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.

Dude, do you really even read the issue tickets?

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!

dbanet

  • Guest
Re: Choice of update channel for eCS / OS2
« Reply #9 on: August 02, 2015, 05:55:47 am »
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).
« Last Edit: August 02, 2015, 06:27:02 am by Boris »

dbanet

  • Guest
Re: Choice of update channel for eCS / OS2
« Reply #10 on: August 02, 2015, 06:03:52 am »
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.

It had been announced.

Still its use should be discouraged in favor of RPM as you may face an older version which will cause problems.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: Choice of update channel for eCS / OS2
« Reply #11 on: August 02, 2015, 03:33:04 pm »
Sorry, I'm tired of this meaningless debate.

You are right...this debate is meaningless, too bad, because all along I thought the subject of this thread was : "Choice of update channel for eCS / OS2", yet there you were once again preverbially stuck on RPM/YUM, while I tried to illustrate with numerous examples while RPM/YUM as an update channel may not be the best approach for everyone.

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

Sometimes it does take a little elbow grease to get to the bottom of a root cause and that statement above is sufficient for me to understand while you clearly miss the big picture.

I'm out of discussing RPM/YUM as an udpate channel with you, it is pointless, you are certainly right on that.

« Last Edit: August 02, 2015, 06:34:13 pm by Dariusz Piatkowski »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Choice of update channel for eCS / OS2
« Reply #12 on: August 02, 2015, 06:02:51 pm »

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

Probably different architectures. There are builds for i386, i686 and P4. Personally I use i686 to get a few newer instructions, better instruction ordering for my C2D. Others use the P4 for more instructions and take the hit caused by the instruction ordering unless they actually are using a P4. The i386 seems useless as I don't know of anyone using older then a PII. Firefox is built targeting the i486 instruction set, my builds target the i686 instruction set. I've tried targeting my C2D but our tool chain is buggy and doesn't align all SSE* instructions correctly.