OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Matt Walsh on May 20, 2017, 04:46:18 pm

Title: Firefox 45.5 Install issues
Post by: Matt Walsh on May 20, 2017, 04:46:18 pm
Following directions for install I cannot find "hunspell" with the ANPM and the program won't start without it.  Also can't find libjpeg-turbo.   Any suggestions or is this a mistyping by the bitwise folks?
Matt W.
Title: Re: Firefox 45.5 Install issues
Post by: Dave Yeo on May 20, 2017, 05:29:41 pm
In the experimental repository by the looks of it.
Title: Re: Firefox 45.5 Install issues
Post by: Martin Iturbide on May 20, 2017, 07:18:15 pm
Hi Matt

Check Herwig's reply (Bitwise works) here - Firefox 45 Installation (http://www.os2world.com/forum/index.php/topic,1373.0.html). There are two libraries that are on Netlabs experimental repo. We can put that repo on RPM/YUM (http://www.os2world.com/wiki/index.php/RPM/YUM_Tips_on_OS/2-eCS#Installing_the_Netlabs_Experimental_Repository) or wait for monday or tuesday to be posted on the regular Netlabs repo.

Regards
Title: Re: Firefox 45.5 Install issues
Post by: Dave Yeo on May 21, 2017, 01:03:22 am
You can also manually download them and install directly, yum install turbojpeg-1.5.1-1.oc00.i686.rpm for example. Note that upgrading nspr with the one in the experimental repositroy might also be necessary, at least it was for building.
Title: Re: Firefox 45.5 Install issues
Post by: xynixme on May 24, 2017, 11:03:31 pm
install turbojpeg-1.5.1-1

Yet another DLL called JPEG.DLL? Or does this one replace one of the more usual JPEG v8 DLLs?
Title: Re: Firefox 45.5 Install issues
Post by: Dariusz Piatkowski on May 25, 2017, 03:18:04 am
...Yet another DLL called JPEG.DLL? Or does this one replace one of the more usual JPEG v8 DLLs?

I'm guessing that it replaces it given that it is supposed to provide the same functionality albeit at a much improved speed(s).

I installed it on my machine, given that it was a FF 45 pre-req, no complaints from ANPM/RPM/YUM (which on it's own is questionable, it really should at least give you some sort of warning and/or notification). Anyways, things still appear to work fine here...
Title: Re: Firefox 45.5 Install issues
Post by: Dave Yeo on May 25, 2017, 03:28:08 am
install turbojpeg-1.5.1-1

Yet another DLL called JPEG.DLL? Or does this one replace one of the more usual JPEG v8 DLLs?

It's a simd accelerated JPEG library, so the newer the CPU, the more simd (SSE etc) instructions it'll use. It's been in Firefox since ver 4 and is still in my builds. Bitwise seems to like seeing how many dependencies they can make Firefox require.
Title: Re: Firefox 45.5 Install issues
Post by: xynixme on May 25, 2017, 03:28:20 pm
"hunspell"

Where does hunspell look for its data files? It's FF for OS/s, so there's no UNIXROOT, but FF's non-bootdrive contains a \USR directory.
Title: Re: Firefox 45.5 Install issues
Post by: ivan on May 25, 2017, 04:01:22 pm
Unzipped firefox into a new directory, downloaded all the listed RPMs (and as zips) and added the DLLs to the DLL directory.  Tried to start firefox and it popped up a note that a DLL was missing - that DLL was NOT in the listed requirements.  I then went digging and finally found it and added it to the DLL directory.  Tried to start firefox again and get a message about another missing DLL that is not in the listed requirements.

What is going on with these ports and why won't they provide a zip file with all the required DLLs?

The only version of firefox that just works is the one that Dave produced.
Title: Re: Firefox 45.5 Install issues
Post by: Dave Yeo on May 25, 2017, 04:22:22 pm
Unzipped firefox into a new directory, downloaded all the listed RPMs (and as zips) and added the DLLs to the DLL directory.  Tried to start firefox and it popped up a note that a DLL was missing - that DLL was NOT in the listed requirements.  I then went digging and finally found it and added it to the DLL directory.  Tried to start firefox again and get a message about another missing DLL that is not in the listed requirements.

What is going on with these ports and why won't they provide a zip file with all the required DLLs?

The only version of firefox that just works is the one that Dave produced.

Unluckily, Bitwise no longer supports using zips to install the prerequisites for Firefox. Too hard?
I guess you can look in the rpms for their dependencies.
Unluckily it has become hard for me to produce a Firefox without most of these dependencies though I don't see any point in making hunspell a dependency, probably less language dictionaries available, not sure if personal dictionaries (right click and add to dictionary) survive the update.
Title: Re: Firefox 45.5 Install issues
Post by: xynixme on May 25, 2017, 07:09:52 pm
Unluckily, Bitwise no longer supports using zips to install the prerequisites for Firefox. Too hard?
I guess you can look in the rpms for their dependencies.
Unluckily it has become hard for me to produce a Firefox without most of these dependencies though I don't see any point in making hunspell a dependency, probably less language dictionaries available, not sure if personal dictionaries (right click and add to dictionary) survive the update.
So now FF + OS/2 = missing DLLs and missing requirements and missing support.

The list of packages can be used to download/update all required DLL files indeed. I guess mine's:

freetyp6.dll
hunspel0.dll
jpeg.dll
jpeg8.dll
libcx0.dll
png1616.dll
turbojp0.dll
z.dll
z1.dll
freebl3k.dll
nspr4.dll
nspr4k.dll
nss3k.dll
nssckbik.dll
nssdbm3k.dll
nssuti3k.dll
plc4.dll
plc4k.dll
plds4.dll
plds4k.dll
smime3k.dll
softok3k.dll
ssl3.dll
ssl3k.dll
libvpx4.dll

I've decided I won't install any hunspell dictionary now. There's at least one FF dictionary.
Title: Re: Firefox 45.5 Install issues
Post by: Andi B. on May 25, 2017, 08:08:27 pm
Quote
So now FF + OS/2 = missing DLLs and missing requirements and missing support.
That's not true. I've no missing dlls and I got/get a lot of support.

You probably get no support for zip installation. At least not from bww for obvious reasons.
Title: Re: Firefox 45.5 Install issues
Post by: ivan on May 25, 2017, 09:51:07 pm
Andi, I also downloaded the RPMs and unpacked them.  The DLLs that were missing were not in those packages. 

The fact that you don't have any problems implies that the missing DLLs are included in something you have installed but I haven't.  This is why I was asking for a zip with ALL the dependencies.   Assuming that some DLLs from other programs will be available is very bad practice - the only time that is workable is if those DLLs are an integral part of the OS - since they are not they should be supplied.
Title: Re: Firefox 45.5 Install issues
Post by: Andi B. on May 25, 2017, 10:07:42 pm
Quote
This is why I was asking for a zip with ALL the dependencies.
Of course it's possible for me to zip the whole usr/. dir and upload it somewhere. But it absolutely would not make any sense. You can unrpm all packages and look into them for yourself to find out all dependencies if you like. But it will take some time a fear. And for what reason? Not any good IMHO. But YMMV.
Title: Re: Firefox 45.5 Install issues
Post by: xynixme on May 25, 2017, 11:21:56 pm
The fact that you don't have any problems implies that the missing DLLs are included in something you have installed but I haven't.

A reasonable starting point of Firefox for OS/2 is OS/2, and OS/2's human package manager. The theoretical new user will experience missing DLLs which have to be downloaded "somewhere", no support because the user is not using an implied requirement, and a missing digital package manager. A reasonable starting point. Andi's starting point may be eCS or ArcaOS, and a digital package manager. It's a disadvantage of lacking competition. I'm just saying that FF for OS/2 isn't FF for OS/2, as illustrated by the formula.
Title: Re: Firefox 45.5 Install issues
Post by: Dave Yeo on May 26, 2017, 04:52:07 am
Andi, I also downloaded the RPMs and unpacked them.  The DLLs that were missing were not in those packages. 

The fact that you don't have any problems implies that the missing DLLs are included in something you have installed but I haven't.  This is why I was asking for a zip with ALL the dependencies.   Assuming that some DLLs from other programs will be available is very bad practice - the only time that is workable is if those DLLs are an integral part of the OS - since they are not they should be supplied.

The RPMs probably pull in other RPMs. Unluckily it looks like you might have to download the source RPMs and unpack them to get the list. Could try looking at the RPM with a text editor, where close to the top will be a list of DLLs (not packages), eg for hunspell,
gcc1.dll hunspel0.dll hunspell-en-US intl8.dll libc066.dll libcx0.dll ncurses5.dll readln6.dll rpmlib(CompressedFileNames) rpmlib(PayloadFilesHavePrefix) stdcpp6.dll tinfo5.dll.
Simplest would be to have a test machine with RPM and install the RPMs and copy the needed DLLs etc to your LIBPATH.
Title: Re: Firefox 45.5 Install issues
Post by: ivan on May 26, 2017, 08:01:37 am
Thanks for that information Dave.  We gave that system up as a bad job years ago when we tried using SUSE on our servers.
Title: Re: Firefox 45.5 Install issues
Post by: xynixme on May 26, 2017, 11:41:30 am
Thanks for that information Dave.  We gave that system up as a bad job years ago when we tried using SUSE on our servers.

It's still possible to obtain all DLLs without a digital package manager. This time the package manager command-line was the main clue. So were new requirements mentioned here. I do not have a list of all required DLLs and archives, because DLLs can be used by other apps too and I've never recorded all possible DLL hell requirements of all apps. I don't know if a digital package manager uses ATTRIB +R, but I do execute that command for 6 DLLs which used to have this attribute set.
Title: Re: Firefox 45.5 Install issues
Post by: Greg Pringle on May 26, 2017, 02:03:59 pm
Once I loaded the list of requirements 45 started.

Now, can anyone shed light on why when run on my system the response is very slow?
Title: Re: Firefox 45.5 Install issues
Post by: Dariusz Piatkowski on May 26, 2017, 02:31:16 pm
Hi Greg,

...Now, can anyone shed light on why when run on my system the response is very slow?

Several others have noticed this problem already...I logged a ticket with the FF folks, see => https://github.com/bitwiseworks/mozilla-os2/issues/208 (https://github.com/bitwiseworks/mozilla-os2/issues/208), sadly not much activity on that issue at the moment.

On my machine the 38 vs 45 difference is so significant that is feels like a proverbial "day & night" difference...that's how unusable 45 is. Subsequently I went backt o 38, hard to understand why 45 was deemed suitable for wider release...???

Dont' get me wrong, I sure as hell appreciate the work that goes into this, but there has to be a sort of benchmark standard, even within the OpenSource community, which must be passed before software is released. All Enterprise software enviornments I have ever been part of followed precisely that, multiple testing cycles before any end-users would be asked to try stuff out. I get that it's officially a BETA, but as advertised it is billed as BETA 8, so presumably this "ready for wider audience" benchmark was passed...again, not sure how, too many people seem to be stuck on basic usability.
Title: Re: Firefox 45.5 Install issues
Post by: Greg Pringle on May 26, 2017, 02:47:48 pm
Well, 45 is still faster than OS/2 2.1 was on my laptop.

I am also glad I am not the one to do the debugging.

There have been NSPR problems in the past that produced slow response and it was improved.
Title: Re: Firefox 45.5 Install issues
Post by: Andi B. on May 26, 2017, 02:49:47 pm
Quote
but there has to be a sort of benchmark standard, even within the OpenSource community, which must be passed before software is released.
Do you know this 'sort of benchmark standards' for OS/2 FF and compared the different versions? What are the results?
Title: Re: Firefox 45.5 Install issues
Post by: Dariusz Piatkowski on May 26, 2017, 04:02:59 pm
Hi Andi,

...Do you know this 'sort of benchmark standards' for OS/2 FF and compared the different versions? What are the results?

No, I do not know the specifics, other then knowing that there are general FF test-scripts. The Mozilla FF Developer resource site has all the pertinent detials, see => https://developer.mozilla.org/en-US/docs/Mozilla/QA (https://developer.mozilla.org/en-US/docs/Mozilla/QA). I can only guess that this BETA 8 release passed all of these. Of course I have looked through the FF Wiki (https://github.com/bitwiseworks/mozilla-os2/wiki (https://github.com/bitwiseworks/mozilla-os2/wiki)), but other than general release info found there, there are no reports to tell what tests passed and what failed. Maybe it is all locked up in the source tree somewhere. I am also on the mailing list so I certainly see the issues which are being reported and resolutions being provided, but that is all...would love to see more, maybe as an OS/2 user with significant amount of software development experience I could contribute something???

My feedback re: testing benchmarks is based on my professional experience as a database (Oracle) software developer...believe me, at the Enterprise level in particular, you dare NOT release something even to a UAT (User Acceptance Test) that is not nearly 99.9% complete. The reality of the corporate life is different then this OpenSource thing, I understand that, but underlying software engineering principles should NOT be!

Given the issues being reported on this release it begs the question whether the methodology we follow is capable of delivering?
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 28, 2017, 02:07:54 pm
I have to address some statements in this discussion:

Quote
OS/2's human package manager

Why does OS/2 rely on a human package manager? Because its architecture is from the early 1990ies. No need for automatic package managers back then.

However: It is quite arrogant to assume that all other OS maintainers (no matter whether these are the Linux, Windows, FreeBSD, whoever guys) are rather dim and incompetent to create such beasts for other OSes when in reality they were not needed. 201x software (especially bigger programs) are simply too complex for a manual approach.

Firefox 45 is a 2016 piece of software: The problems to get all DLLs together are not OS/2 specific - all the other OSes got package managers to do that job. NOBODY on other OSes asks for specific DLL requirements to be manually downloaded "somewhere" and copied into specific locations - the question for that (unless for specific research purposes) would be considered plain stupid and obsolete.

The RPM/YUM port is an attempt driven by bitwise works and Arca Noae to close this gaping hole in the OS/2 architecture.

So:

If you want to run software the 1990ies way on a 1990ies OS, please use software from the 1990ies - an automatic package manager would not really be required then.

If you want to run software from the 201x on a 1990ies OS, please do as the ones who DO THE WORK on that stuff suggest. We know what we are doing and why we are doing it the way we do it.

If you do not want to do it the suggested way - you are free to do so. You just need to do A LOT OF RTFM and use PMDLL as a tool to overcome the arising difficulties...

Maybe it is time for you to review your point of view. But please don't steal our time by asking 1990ies questions in 2017. They have been solved - use RPM/YUM - that IS the solution.

Quote
It's a disadvantage of lacking competition.

It looks like you are suffering from blatant illusions. I wish the OS/2 market and community was big enough to make competion a healthy option to get the best alternative solution for a problem. The reality is, that the main problem is, to get enough manpower to complete ONE solution for a single problem.

Discussions whether there would have been other (possibly better) solution is senseless - there is simply nobody who will create it.

Critisizing certain aspects of current software (OS and application) is absolutely valid and welcome - however make sure you got a viable alternative solution at hand, a simple rant just is not good enough.
Title: Re: Firefox 45.5 Install issues
Post by: ivan on May 28, 2017, 03:37:39 pm
Herwig, I agree with your sentiments but why the decision to use a package manager from the 1990s, one that didn't work very well then and still doesn't?

We have Warpin that is quite capable of doing the same thing, and in my opinion, much better.  Yes, I know it would take a little more work to use that but until someone gets RPM/YUM certified for use on OS/2 Warpin or manual install is what some of us have to use.

It would also help if there was some way of identifying the unix DLLs to allow regression analysis to find out which ones work in which situations and with which programs (if we use the latest vBox we have to reboot to use OpenOffice 4 and then again reboot to use firefox 38 - not the sort of thing that goes down well in business). 
Title: Re: Firefox 45.5 Install issues
Post by: Andi B. on May 28, 2017, 04:35:41 pm
It would also help if there was some way of identifying the unix DLLs to allow regression analysis to find out which ones work in which situations and with which programs (if we use the latest vBox we have to reboot to use OpenOffice 4 and then again reboot to use firefox 38 - not the sort of thing that goes down well in business).
You see how far you came with your decision not to use rpm. If even you as an experienced user end up with such an unusable system what do you think the rest of the crowd will get with your Warpin and 'copying every single dll somewhere and by hand' approach?

Btw. here runs VBOX next to FF45 and SM235 and AOO and qpdfview and Lucide and cups and ePDF and PSI and Samba and ... No need to reboot.
Title: Re: Firefox 45.5 Install issues
Post by: ak120 on May 28, 2017, 04:53:52 pm
I have to address some statements in this discussion:

Quote
OS/2's human package manager

Why does OS/2 rely on a human package manager? Because its architecture is from the early 1990ies. No need for automatic package managers back then.

However: It is quite arrogant to assume that all other OS maintainers (no matter whether these are the Linux, Windows, FreeBSD, whoever guys) are rather dim and incompetent to create such beasts for other OSes when in reality they were not needed. 201x software (especially bigger programs) are simply too complex for a manual approach.

Firefox 45 is a 2016 piece of software: The problems to get all DLLs together are not OS/2 specific - all the other OSes got package managers to do that job. NOBODY on other OSes asks for specific DLL requirements to be manually downloaded "somewhere" and copied into specific locations - the question for that (unless for specific research purposes) would be considered plain stupid and obsolete.

The RPM/YUM port is an attempt driven by bitwise works and Arca Noae to close this gaping hole in the OS/2 architecture.

Well, an (half-ported) package manager from the late 90ies and an update mechanism from early 2000 is the ultimate solution nowadays. These are completely ridiculous explanations.

Quote
So:

If you want to run software the 1990ies way on a 1990ies OS, please use software from the 1990ies - an automatic package manager would not really be required then.

If you want to run software from the 201x on a 1990ies OS, please do as the ones who DO THE WORK on that stuff suggest. We know what we are doing and why we are doing it the way we do it.

In fact on "a 1990ies OS" RPM worked and still works without contortions. I don't judge the experiments of tuppenny-ha'penny people.

Quote
If you do not want to do it the suggested way - you are free to do so. You just need to do A LOT OF RTFM and use PMDLL as a tool to overcome the arising difficulties...

It shuts here like in the circus.

Quote
Maybe it is time for you to review your point of view. But please don't steal our time by asking 1990ies questions in 2017. They have been solved - use RPM/YUM - that IS the solution.

Is this really meant still seriously?
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 28, 2017, 05:39:23 pm
Quote
Why RPM/YUM, we have beautiful WarpIN

IBM endorsed RPM/YUM on other systems and there is reason to believe that if OS/2 development had continued, there would be some sort of RPM/YUM for OS/2 from IBM.

About WarpIN: I was a WarpIN fan myself (you possibly know some of my software that came as a WarpIN package) and there were quite some discussions in bitwise, about RPM/YUM being that ugly and WarpIN is so nice anyway.

I had to learn that WarpIN simply is not good enough - it lacks several features direly needed by a modern package manager. From the architecture point of view, extending WarpIN was considered, however the design of WarpIN prevents that.

What we do these days, is to enhance our RPM/YUM to embrace WarpIN.

In addition the number of OS/2 specific features of RPM/YUM is increased and enhanced. Missing features found in WarpIN missing in RPM/YUM are added (for example install a font in OS/2, RPM/YUM cannot do this at the moment - expect to see that change soon).

Quote
if we use the latest vBox we have to reboot to use OpenOffice 4

For sure not an RPM/YUM based installation, as that definitely works. This is exactly the reason, why it does not make sense anymore to install that stuff manually. I cannot answer your question, I simply do not know your machine. If you had done it using RPM/YUM it would work.

Sorry, I understand your feelings, but doing it manually is simply wrong.
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 28, 2017, 05:51:06 pm
Quote
Well, an (half-ported) package manager from the late 90ies and an update mechanism from early 2000 is the ultimate solution nowadays.

Ultimate solution? Your words. bitwise never said that. However, the solution that made most sense. And it can't have been that wrong...
https://www.ibm.com/developerworks/library/l-lpic1-102-5/

Anyway: You are free to provide a better solution. Not just ranting, write the code, provide the packages, do the maintenance. "Hic Rhodos, hic salta!"

Quote
These are completely ridiculous explanations.

They appear ridiculous only if you missed the most important point. I bet you will not guess which one I meant. Just go through my writing once more and do a careful reading.

Hint: Conservative minds often miss that point.
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 28, 2017, 06:00:07 pm
Quote
tuppenny-ha'penny people.
Well, neither bitwise nor Arca Noae are IBM, we are much smaller, simpler, you name it. But still better than a person that only is capable of ranting....

Quote
Is this really meant still seriously?
Yes. Being eager to learn, we are waiting for your presentation of ANY better alternative.
Title: Re: Firefox 45.5 Install issues
Post by: ak120 on May 28, 2017, 08:40:51 pm
Quote
Well, an (half-ported) package manager from the late 90ies and an update mechanism from early 2000 is the ultimate solution nowadays.

Ultimate solution? Your words. bitwise never said that. However, the solution that made most sense. And it can't have been that wrong...
https://www.ibm.com/developerworks/library/l-lpic1-102-5/
It's seems you cannot read. This forum area topic is about "Applications". You have no better to do than spreading fake news here. The current situation under OS/2 is a total disaster for end users of your "ported" applications. It's a fatal mixture of breaking compatibility, introducing new unstable interfaces, slovenliness and unkindliness etc.

I will simply ignore your sophistic attempts to drive this discussion off topic. Only one point regarding AIX: Even 20 years ago it was much easier to compile a application there, than using now an application dongled with your YUM/RPM requirements.

Quote
They appear ridiculous only if you missed the most important point. I bet you will not guess which one I meant. Just go through my writing once more and do a careful reading.
It only becomes even more abstruse at every further time.

Quote
Hint: Conservative minds often miss that point.

You seem to like quotations.
"Kochajmy się jak bracia, liczmy się jak Żydzi."
Title: Re: Firefox 45.5 Install issues
Post by: Dariusz Piatkowski on May 29, 2017, 04:19:47 am
...You seem to like quotations.
"Kochajmy się jak bracia, liczmy się jak Żydzi."

LOL...that is so "fully loaded"...!!!

...to really understand one can not simply translate....
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 29, 2017, 11:55:41 am
Quote
You have no better to do than spreading fake news here.
Nonsense. A news with an example as source hardly qualifies as fake news...
Quote
The current situation under OS/2 is a total disaster for end users of your "ported" applications.
More Trump-speak. More nonsense. Simply a blatant lie.

There are 2 ways to successfully run applications on a modern OS/2 system:

1.) Go the RPM/YUM way. Stuff simply works in most cases.
2.) If there is an older version library that is required by an elder application under any circumstances - use LIBPATHSTRICT. PMDLL is your friend.

Regarding Andreas Kohl: I have been advised to ignore his niggle and utter nonsense. He constantly fails to substantiate his claims anyway.



Title: Re: Firefox 45.5 Install issues
Post by: xynixme on May 29, 2017, 12:25:09 pm
Quote
OS/2's human package manager

Why does OS/2 rely on a human package manager?

Is this really meant still seriously?

To support Andreas' case, he has one, OS/2 doesn't rely on a human package manager. Operations do. It may be hard for an engineer to understand that their Usenet trolls have to manage more than one system, while trying to avoid the DLL hell of DLLs like JPEG.DLL and Z.DLL.

Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you. That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products. If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of different products for different countries.

Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.

So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".

Hence: FF + OS/2 (and FF for eCS 1.x) = missing DLLs + missing requirements + missing support

So you're on your own then. While you're on your own, you may as well become the human package manager if the environment isn't that simple. It's easy to install an approved DLL. It's harder to uninstal the possibly destructive output of the random update policies of some random digital package manager, which works fine for "the average home user of selected products".

In the case of older hardware, the capacity of harddisks plays a role too. I'm pretty sure that a package manager isn't that aware of likely disk full-errors. If there's no eCS 1.x, eCs 2.x nor ArcaOS in the right language, then newer hardware isn't an obvious solution.

That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.

If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.

In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.

So please try to keep anyl Y2K-proof version of OS/2 Warp, settings of WPS objects and continuity of operations in mind while advocating that "one solution" (of some products) is "the solution" (of all products, languages and/or situations). Releasing qualifying updates for all OS/2-based products would help, but that won't solve all possible issues. If a new component really has to be added to ArcaOS, like a font, Unix directory structures or a package manager, then please consider releasing such a product as an update for all OS/2-based products. By default a simple install of OS/2 Warp 4 has no Unix directory structure, package manager, and so on.

So there's no such thing as a working "FF for OS/2", regardless of perfect and impressive OS/2 binaries. Install and update OS/2, install the FF package, and it won't work. The README.OS2 will result in a SYS1041 error.

OS/2 Warp (no FP for all OS languages), eCS 1.x (a few languages), eCS 2.x (fewer languages) and ArcaOS (EN only) are different products, each leaving a part of the community behind. In the case of ArcaOS EN perhaps a part of the German community too, slowly. The one and only package manager is a solution for the happy few. I guess availablity of ANPM is excellent, but that doesn't imply that everyone is willing to allow a random digital package manager, with random update policies, without detecting all possible OS/2 setups, to manage their packages.

Regarding applications, the number of quickly ported "OS/2" application which assume some eCS 2.x or ArcaOS setup is increasing. There is no "eCS 2.x setup for OS2" package, if you'd want such an environment in the first place. Or need such an environment. Often you can copy all files to one directory and keep the bootdrive clean, but not always. If not, then the required environment should have an added value for OS/2. Often it has no added value at all.

Of course the irrelevant, perfectly fine product WarpIN isn't the answer. A disadvantage of a (anything but perfect) WPI version of the FF products is that you may have to backup both the large WPI file and the large installed files. And, of course, WarpIN is a kind of package manager with its own policies. Here the human package manager typically extracts and converts the (sometimes anything but perfect) WarpIN install scripts to Rexx install scripts. If the results are identical, then managing and backing up the small Rexx install scripts is prefered above having to backup the whole original archive too. Fonts are a common exception (bootdrive files without a backup of the installed files, INSTFONT).

IIRC the game QNetwalk is an example of a Unixified app. It's improved significantly, but it uses a Unix directory structure. I guess just because Unix-based tools were used. Without any added value compared to an OS/2 or eCS 1.x x:\OS2GAMES\QNETWALK setup.
Title: Re: Firefox 45.5 Install issues
Post by: ak120 on May 29, 2017, 02:11:16 pm
There are 2 ways to successfully run applications on a modern OS/2 system:

1.) Go the RPM/YUM way. Stuff simply works in most cases.
YUM relies on IP connectivity and a quite large Python language environment. We would use here RPM, but in the current form it's not an easy process. I could not find any documentation about the installation of RPM without yum. Unfortunately your "simply works" means in real world the lack of any documentation that would help the operators.

Quote
2.) If there is an older version library that is required by an elder application under any circumstances - use LIBPATHSTRICT. PMDLL is your friend.
Quote
This advise is not totally wrong, but it cannot resolve all dependencies or compatibility issues.
Title: Re: Firefox 45.5 Install issues
Post by: Martin Iturbide on May 29, 2017, 02:36:30 pm
Hi

This is just a friendly reminder, everybody has their own opinons and their preferences of how to use or interact with a personal computer. The user is free to choose how they want to work with OS/2 and the developer is also free to select what is his best way to produce software.

We already have the discussion about RPM/YUM vs WarpIn so many times. I don't think we should start over with it, but if someone think it is needs to be discussed please open a new thread.

On the other side I always dislike how some people uses lightly phrases like "you are spreading fake news", "you are suffering from blatant illusions", "you are dreaming in technicolor", "you belive in fairytales" or the simple statement in CAPS like "YOU ARE WRONG" without explaining anything. I think there are better ways to communicate with others without labeling the other party.

If you explained your reasons politely and the other party does not understand or not share your point of view just "agree to disagree".

Regards
Title: Re: Firefox 45.5 Install issues
Post by: ak120 on May 29, 2017, 05:29:02 pm
Let's also point out that Germans aren't always that qualified to reply, because they've got eCS 2.x DE. Good for you.
Sorry, but that's a wrong assumption. My observations are made on systems that are generic IBM OS/2 Warp 4 or Warp Server for e-business installations with latest fixes applied (if required). And I'm aware of minor differences between NLS versions.

Quote
That's the environment they are often used to, exceptions excluded. OS/2, eCS and ArcaOS are different products.
The so-called ported software from RPM packages is only tested under an US OS/2 Warp 4 MCP2 environment. Most of the included localisation that got installed (without the option to disable unwanted locales) is simply not usable or unreadable on specific NLS target systems because of wrong text encodings.

Quote
If you're French, for example, then you may be forced to use OS/2 Warp 4 FR. They are lucky, because they have got a FP15. Probably often with matching old hardware. AFAIK there's no package manager update package for OS/2 Warp 4 FR. So a package manager is an assumed default solution of different products for different countries.
As I worked in the past for an account in Spain and France my experiences are different. For client stations the french MCP1 or MCP2 can be used. But I cannot remember exactly if it was only Canadian French installation media set to an European locale for France. I can a look at it soon.

Quote
Now FF requires (too) many DLLs. Some DLLs have requirements. Installing the DLLs, with support, requires some package manager. Surely this package manager has requirements too. Not if you're using different products like eCS 2.x or ArcaOS. The next requirement is that you'll have to "investigate" the random digital package manager each time, for example because it's not aware of all LIBPATH-settings of all WPS object.
There are a lot of inconsistencies in dynamic linking and it's consequences regarding the memory management. The lack of reliable development tools is only one of the reasons that leads often to strange behaviour of the generated application. The average user will only notice slower performance and faulty graphics in most cases. The biggest bottleneck with mozilla apps seems to be now I/O and not CPU performance.

Quote
So why is a package manager a bad choice for a product called "FF for OS/2"? Because there is no digital package manager update for OS/2 Warp 4 FR. It's "FF for eCS 2.x" (EN/DE only), or "FF for ArcaOS" (EN only). Of course the main reasons are that the human package manager has to manage more than one system, and that requirements of requirements of requirements are a bit over the avoided top. If anything compared to downloading one package called "FF for Windows".
In my opinion it's a misuse of the Firefox brand, but who cares? Usually beta versions should use a different branding.

Quote
That's why a human package manager used a digital package manager. To obtain the DLLs. Once, for all installs. So far we're also ignoring the fact that OS/2 and eCS 1.x have no "@UNIXROOT", and so on, and that there are no update packages to keep components of older products like OS/2 Warp or eCS 1.x up-to-date. Actually ANPM may be a rare exception. The human package manager gets it right once, and delivers the known, right solution to all qualifying systems. Just like you don't want Microsoft's update to update your browser, install irrelevant software, and so on.
I cannot follow the idea behind the @unixroot thing. It's only required by fontconfig which has hardcoded paths. I can only guess that this "feature" was only tested with JFS volumes.

Quote
If you're using eCS 2.x DE in an environment which isn't that complicated, then its digital package manager may be an excellent choice. You'll have the matching Unix-directory structures, and so on.
By only reading reports from German eCS 2 users I cannot agree with you. I have only eCS 1.2 (but not installed).

Quote
In the EU, 11% of the community speaks German. In the EU, 38% speaks English. If those statistics are true, then far less than 50% of the community (some Germans do speak English too) in the EU will understand eCS 2.x DE/EN and ArcaOS EN. Other people may not prefer a DE/EN OS, despite of understanding both languages.
I don't know where are the figures from. But it does'nt have any relevance for OS/2. Approx. 60-70% of existing installations are German NLS of different OS/2 product levels. And even communication with IBM Austin (15 years back) could be done completely in German. I agree with you that NLS should be improved. Forcing users from South Africa for instance to use an English OS/2 is not polite.

Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 30, 2017, 09:35:44 am
A few notes:

- We are testing on a mix of several language based OS/2 versions. Usually the language does not really make a difference (except SBCS vs DBCS or cyrillic issues which happen to creep in from time to time).

- A working IP connection to the internet (or any other network) is NO must have for RPM/YUM. An installed IP stack is a requirement. Python is a requirement, too.

- The DLL hell is a reality on ALL operating systems. It simply does not make sense to statically link every single requirement and thus reduce the number of required DLLs. The reason is that architectural constraints especially on our platform make that a bad idea being the source for more problems than you can imagine. We have been there. A statically linked FF does not work on OS/2 anymore. Niggling about the DLL hell and how bad it is, is as useful as niggling about the color of the sky. You don't like the DLL hell? Me neither. And I like to think about the times when "our" OS did not have it. Too bad these times are simply gone.

For those who have to operate a standalone machine that is not connected to the internet, it is possible to use RPM/YUM locally only. It is advisable to create a local RPM repo, disable the netlabs and ArcaNoae repos, copy any installation package to the local repo and let YUM install it from there.

I need to check how good and simple the docs for that scenario are, if they are not good enough, I will overhaul them.
Title: Re: Firefox 45.5 Install issues
Post by: ivan on May 30, 2017, 02:08:39 pm
Herwig, a question.  How much testing of these DLLs is done on AMD multi core processor based machines?  I ask because we don't have any Intel processor machines here, even our servers are AMD based.
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on May 31, 2017, 08:50:47 am
Ivan, currently I am not aware of any AMD based testing machine - I phased out my last SMP AMD based machine some 1,5 years ago...

However, this was only an issue when I built an AMD-optimized Samba back then (which was never officially released, but worked well, the last one was a 3.3.x one....).

Basically we build for generic i686 (PentiumPro) instruction set, so in theory it should work on everything better than a Pentium/AMD K6.

Addendum: I just learned that one tester uses an AMD based machine, so: Yes.
Title: Re: Firefox 45.5 Install issues
Post by: R.M. Klippstein on June 01, 2017, 12:26:16 am
Hi ivan, fwiw there is more than person testing on AMD machines. I know of three others who also test AMD's. I test on AMD 4 & 8 core boxes, both running ARCAOS as host. I also test on an Intel box (Lenovo) and the results are pretty much the same so far for both. Some problems, yes, but a huge improvement over eCS.

klipp
Title: Re: Firefox 45.5 Install issues
Post by: Dariusz Piatkowski on June 01, 2017, 01:59:36 am
...I test on AMD 4 & 8 core boxes, both running ARCAOS as host....Some problems, yes, but a huge improvement over eCS...

Can we have a confirmation that the dreaded WPS Blue-Screen-of-Hang is now gone with the SMP setups > 5 cores?

I ask b/c attempting to boot with my 6 cores of the AMD Phenom II x6 is simply not possible w/o a guaranteed WPS freeze just as the PM shell comes up, I would love for that issue to be behind us!
Title: Re: Firefox 45.5 Install issues
Post by: R.M. Klippstein on June 01, 2017, 04:48:56 am
Hi Dariusz, So far I have never seen this problem on either of my AMD boxes. One frustrating problem I have encountered that occurs on AMD boxes is the "age old" sagging desktop icons. This is not a problem on my Intel box.

klipp
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on June 01, 2017, 08:20:12 am
Quote
One frustrating problem I have encountered that occurs on AMD boxes is the "age old" sagging desktop icons. This is not a problem on my Intel box.

It happens here on the Intel boxes as well and is unrelated to to CPU type.
This is a WPS bug which can be worked around by using http://hobbes.nmsu.edu/download/pub/os2/util/wps/movingdesktopobjects100.zip from time to time.

The invoking of the script is a bit clumsy, but it works very well. Until it starts to happen again (which can be expected from the nature of the bug).
Title: Re: Firefox 45.5 Install issues
Post by: Doug Bissett on June 01, 2017, 04:28:12 pm
Quote
This is a WPS bug which can be worked around by using http://hobbes.nmsu.edu/download/pub/os2/util/wps/movingdesktopobjects100.zip (http://hobbes.nmsu.edu/download/pub/os2/util/wps/movingdesktopobjects100.zip) from time to time.

Apparently it is triggered by (but not caused by) using the XCenter Reduce Desktop workarea setting. The movingdesktopobjects thing does "fix" the problem, but that only works when you run it. The trick seems to be to either not use the Reduce Desktop workarea setting, or run movingdesktopobjects at every shutdown. You can do that using the XWorkplace shutdown folder. All it does, is remove the (defective) desktop settings, which are recreated  (correctly) at the next boot. The exposure is that a crash won't run the movingdesktopobjects program, but it also won't save the defective settings.
Title: Re: Firefox 45.5 Install issues
Post by: Dmitriy Kuminov on June 03, 2017, 03:00:57 am
I don't normally read forums as I prefer to spend my time developing rather than participating in hate speech (I'm a human being with limited resources, sorry). However, I've been pointed to this thread and I found some posts interesting enough to answer them in hope that my answers, as well as the answers of my fellow colleague Herwig, will eventually help people use what we (BWW) do.

First of all, Firefox install issues. The original issue of this thread's author was in fact not related to the RPM/ZIP war at all. It was just getting out of sync with announcing a new Firefox release and moving a couple of packages from the experimental repository (where all releases initially land) to the normal one. This happens sometimes and is usually fixed very quickly. Not a big deal. More over, in the future such issues will be resolved automatically (the technology we use allows to do that).

Next, about the ZIP installation of Firefox and its further support. As Dave already pointed out, we (BWW) discontinued support for ZIP installations. Back in FF Beta 7, by the way. The reasons behind this decision are described in README.OS2 (but who reads that, I know). In short, it's simply not possible any more. Some (actually pretty long) time ago we deliberately took the Linux approach of distributing software. This approach basically means that each and every 3rd party library any given software product uses is built as a DLL and distributed on its own rather than as part of that product and this distribution is then shared among all other products using the same library. The main benefit of this approach is that it greatly saves system resources (mostly in terms of occupied disk space and memory footprint) because programs share a single copy of the library code (and sometimes library data too). Another key benefit is that fixing a bug in such a library (and installing a new version of it) makes the fix instantly available to all programs using this library without a need to reinstall those programs themselves.

Saving system resources is what we need most from the new approach. While the available memory address space size is not a big issue in the 64-bit world, it is a very tight resource in the 32-bit world where OS/2 belongs (and will belong forever I suppose). I think everybody is aware about problems when several huge applications (be it FF + AOO + VBox) are runnig in parallel. You have to play with your VIRTUALADDRESSLIMIT setting in CONFIG.SYS and mark DLLs to be loaded high in order to make them work. And all these problems are about running out of address space because there are too many libraries used by these applications occupying too many memory pages and doing very similar things. Or, even worse, too many versions of the same library doing exactly the same thing but occupying as much space as there are copies of the library. And, due to technical limitations of the 32-bit world (and of the OS/2 kernel which is quite old and does not evolve) we, as developers, can't do much here. Except that we can try to eliminate similar or duplicate copies of libraries applications need at their runtime and this is what "Bitwise seems to like seeing how many dependencies they can make Firefox require" is exactly about. Reducing memory footprint. By breaking applications into as many separate and reusable pieces as possible. To let you run several modern and heavy applications in parallel. Or even simply run them at all. (It's not hard to imagine a single application that sucks in all available 32-bit address space).

Having so many dependent (and sometimes cross-dependent) moving parts, in turn, requires a decent software manager framework that can automatically resolve all these dependencies (including possible conflicts) and download proper versions of all necessary libraries — because it is simply beyond possibilities of a regular person to do it manually. For instance, Firefox currently requires about 50 external DLLs and a bunch of other stuff — this is NOT manageable by hand. DLLs required by Firefox have their own requirements, sometimes you need to take a specific version of a library and so on. And simply distributing all the required DLLs with the application inside a single ZIP is not a solution here, not at all. First, it will immediately create a well known DLL hell — the system will have many copies of the same DLL distributed with different applications which will be often conflicting with each other in many ways. Second, if you try to fix this DLL hell with LIBPATHSTRICT=T (which itself is a very dirty hack in the OS/2 kernel and doesn't always give stable results), you will completely beat the whole purpose of breaking applications into reusable pieces described above (and even the purpose of distributing libraries as DLLs at all). So the macOS-like all-in-one bundle strategy is not a way to go on OS/2. Needless to say that, having that many dependencies, even a task of bringing them all together (e.g. in order to pack in a single ZIP) or even simply mentioning them all in a readme becomes a big headache and this is why we gave up on this idea completely.

So, with the above said, we have what we have. RPM as the software manager framework, YUM as its command-line frontend and ANPM as its GUI frontend. RPM may be not the best software manager out there but it does its job (it was selected many years ago and we don't have resources to try out another one, at least not now and not in the near future). Actually, it's not that bad at all if you use it as it was designed to and not as you want it to use. This means that you should either install ArcaOS or properly install the RPM/YUM environment to your favorite OS/2 flavor and then only use YUM (or ANPM) to install all software that is being released as RPM (by BWW or any other party) even if there are alternative ZIP distributions of this software floating around. In this case, RPM will do all the dirty work for you. And it will do it right in most (if not all) cases. And if it doesn't, it's a bug that is about to be fixed. Don't get me wrong, when I said RPM is not the best package manager, I didn't mean WarpIn. Not at all. WarpIn may be younger than RPM, but it's so much behind it (or any other modern manager like DPKG) feature wise that it's simply not correct to compare them. In fact, WarpIn is essentially an installer, it has only very basic package management capabilities which don't meet the need of the real world — and this is one of the reasons RPM was ported to OS/2 in the first place. And while RPM has its flaws (e.g. some odd behaviour when resolving really complex conflicting dependency cases involving multiple indirect upgrades/downgrades), it's still much better than WarpIn and it's been serving such massive distributions as Fedora and CentOS for years which proves its stability and scalability. The mentioned flaws are rare cases that don't affect a normal user (and that are being addressed in DNF, a YUM successor that we will eventually port to OS/2, and in RPM itself). So, words like "a package manager from 90s" simply mean nothing. The whole concept of a PC from 60s and it still works pretty well.

Regarding language support and other reasons that could force you to use older OS/2 flavors instead of ArcaOS and eCS 2.x and hence have various difficulties with the RPM/YUM/UNIXROOT environment. This is an interesting point of view. But it is weak. I'm Russian. And I've been using English eCS for many years now. And I have Russian in all places I need. So I know what I'm talking about. Language support is not perfect but it's usable (and it may be improved). To put it simple, nowadays there is only ArcaOS. This is the only flavour which is alive, forget about everything else. ArcaOS is only English now, but there is nothing that would prevent it from becoming French, German or Russian — other than some reasonable amount of time and money. And you would better apply your energy in this direction instead of criticising a switch to RPM/UNIXROOT. Seriously. But even if, despite all reasons, you want to stick with some dead OS/2 flavour, there is still a solution for you: make some effort and bring RPM/UNIXROOT to your system. You may even do a package in your favourite format for that, be it ZIP or anything else, or improve the existing WPI of a standalone RPM install — as a courtesy to other folks using the same flavour. And we will even assist you, as time permits, if you file your problems in the respective tickets.

So, back to the Firefox ZIP distribution. Very soon there will be a Firefox RPM from BWW/AN that does all the dependency burden for you in one click. And there will be an automatically generated ZIP from us which is basically a repack of that RPM. There will also be an automatically generated list of required DLLs put into that ZIP, for  your convenience. (This list is what you can actually easily get yourself from any RPM file by executing `rpm -qRp PACKAGE.rpm`). But not more than that I'm afraid. Everybody is free to give us suggestions on how to improve our automatically generated ZIPs or to contribute even further and e.g. write a script that converts our RPMs/ZIPs to WarpIn archives. (Or repack our software manually if you wish so). But it's clear enough that we have very limited resources and will not provide official support for a distribution other than our own RPM and our exact reaction to your suggestions is limited by our resource availability as well. However, it's never forbidden to ask us a question if you have one. Do it and chances are high that you get an answer. And, while ranting, flaming and hate spilling also cannot be forbidden due to a free speech principle, you will surely not get any answer on that :) At least not from us. Thanks for your attention.
Title: Re: Firefox 45.5 Install issues
Post by: Matt Walsh on June 14, 2017, 10:37:41 pm
Thanks Dmitry.  :)
Title: Re: Firefox 45.5 Install issues
Post by: ivan on June 14, 2017, 11:24:29 pm
Dmitry, your explanation fills in some holes but does not explain why if our computers have been running for more that a week we can start, for example, Open office 4.12 but if after closing it we can not start vBox 5.06 and trying to restart OO throws a fault of not being able to open SC.DLL.  At that stage even EPM which we use as our standard text editor stops responding and we have to reboot.

While I appreciate the work you are doing I can't help wonder why we can no longer keep our computers up for more than a week when it used to be months before a reboot was required.  We have our WSeB SMP image that has only changed when we added new fixpaks.  It has worked for years without problems but now ....

   
Title: Re: Firefox 45.5 Install issues
Post by: xynixme on June 15, 2017, 02:34:53 am
Regarding language support and other reasons that could force you to use older OS/2 flavors instead of ArcaOS and eCS 2.x and hence have various difficulties with the RPM/YUM/UNIXROOT environment. This is an interesting point of view. But it is weak. I'm Russian.

I have no clue what language difficulties have to do with "hence have various difficulties with the RPM/YUM/UNIXROOT environment", while ignoring the fact that the package manager over here is, and will remain, a human package manager. RPM is no one-size-fits-all solution, albeit you're pretending it is. Whotevah...

If you are Russian and wouldn't be trying to advocate your own choices, then you should be able to experience and understand the effects of lacking competition. You can get away with it, so what are you advocating? You really can. You even have the freedom to not support OS/2 anymore, despite of a product called "FF for OS/2". FF + OS/2 = an excessive number of missing implied requirements + missing support. Requirements of requirements of reqiurements of requirements sounds like the Russian story of a perfectly launched Venus spacecraft, which wasn't even capable of detecting life on Earth. Hence the conclusion that the lack of competition is clearly showing. Face it, there's no such thing as FF for OS/2.

The ticket system is yours, and the human package manager even avoids WPI packages. Not because WarpIN sucks, so someone representing a WarpIN company doesn't have to try to advocate WarpIN now...
Title: Re: Firefox 45.5 Install issues
Post by: Herwig Bauernfeind on June 15, 2017, 11:44:52 am
In order not to waste Dmitries precious developer time, I will try to fill in the gaps

Quote
Dmitry, your explanation fills in some holes but does not explain why if our computers have been running for more that a week we can start, for example, Open office 4.12 but if after closing it we can not start vBox 5.06 and trying to restart OO throws a fault of not being able to open SC.DLL.  At that stage even EPM which we use as our standard text editor stops responding and we have to reboot.

The reason is quite simple, though not really obvious: Todays applications (such as OpenOffice or Vbox) are so demanding with respect of memory, address space that we are continuosly bouncing into the limits of our beloved OS/2. Just remember: Back then NO application required that much memory, address space and the like. While we are (theoretically) within the bounderies of OS/2, nobody at IBM back then tested, whether an application that huge still worked under alle circumstances - simply because there was NOT A SINGLE application that huge. The possibilities why something might fail are endless and one especially annoying issue is that the OS fails to free ALL resources these huge applications need when running. So: After a week (or earlier) some resource of the OS has been so badly eaten up, or fragmented, or.... that you have to reboot.

Software from back then never used up enough resources to even show the problem, because it simply would take too long.

Quote
It has worked for years without problems but now ....
Sure. Use the software you used back then it will still work endlessly. That is not an option? We know that is why we are here....

However, we do not have the source code to OS/2. Unfortunately.
Title: Re: Firefox 45.5 Install issues
Post by: ak120 on June 15, 2017, 01:09:13 pm
Dmitry, your explanation fills in some holes but does not explain why if our computers have been running for more that a week we can start, for example, Open office 4.12 but if after closing it we can not start vBox 5.06 and trying to restart OO throws a fault of not being able to open SC.DLL.  At that stage even EPM which we use as our standard text editor stops responding and we have to reboot.
At this stage: Are you able to start a new process of EPM from command line (start epm)?

The crazy idea of mapping shared libraries to OS/2's dynamic link libraries is simply a disaster and not a solution. It works to some degree with C code. But there are more things to consider when it comes to C++ stuff. A lot of stuff that uses this libc and the additional libcx hack violates the OS/2 ABI or has side-effects with existing programs. The biggest flaws are in process and memory management - especially shared memory usage.
Title: Re: Firefox 45.5 Install issues
Post by: ivan on June 15, 2017, 01:45:08 pm
Andreas, when I said 'stops responding' I should have said all open instances stop responding, can't save,  close them or start a new one.  In fact if we try and start a new instance, command line or otherwise, we get a total system lockup that requires a hard reset (we have had a few cases where it required a total power down of the computer before it would restart).

I can't help wondering how much the totally different types of kernel between OS/2 and Linux have it creating the problems we see.

 
Title: Re: Firefox 45.5 Install issues
Post by: Dmitriy Kuminov on June 16, 2017, 12:42:29 am
I have no clue what language difficulties have to do with "hence have various difficulties with the RPM/YUM/UNIXROOT environment", while ignoring the fact that the package manager over here is, and will remain, a human package manager. RPM is no one-size-fits-all solution, albeit you're pretending it is. Whotevah...
The clue is your old eCS or OS/2 installation which is not tested and not officially supported by us as a target for the RPM/YUM/UNIXROOT environment. If you refuse to properly install and properly use this environment then we have nothing to offer you except a raw ZIP with zero support from us. I have no clue what exactly is not clear for you here. We are not pretending and not saying that RPM fits everyone's needs — feel free to use whatever is best for you. We are only saying that if RPM doesn't fit your needs then please don't ask us for help because our only solution to help you with is RPM (reasons explained). That simple. And if you can offer OS/2 users something else — go on, do it, create competition (that you adore so much). We will be really glad to see it.

The ticket system is yours, and the human package manager even avoids WPI packages. Not because WarpIN sucks, so someone representing a WarpIN company doesn't have to try to advocate WarpIN now...
The only thing I advocated here so far is the choice we've made. And my intent has nothing to do with sucking, fucking, or such. It's clearly stated in the second sentence of my original post.
Title: Re: Firefox 45.5 Install issues
Post by: Ian Manners on June 16, 2017, 05:42:50 am
Hi Everyone,

Personally I do not use the RPM/YUM installation method, tried in the early days and it trashed my build system BUT I will defend those behind YUM/RPM for OS/2. I am happy to use the zip files from rpm.netlabs.org because I have something resembling a clue.

When someone puts a lot, or little effort into creating something for this platform they deserve to be applauded for the time and effort they have put into it. It's fine to point out bugs or problems but please do not 'trash' what others are doing. People are free to use the YUM, WarpIn, or other installable process, even a simple zipped up file of the working directory. This is called freedom of choice, which I view as a wonderful thing.

Without the work of these people many of these packages and updates would not be available in any form, so I'm just happy they are available at least in this form. It does not matter if you use YUM or not, you have access to the individual rpm or zip files.

So to everyone involved with YUM and who also is kind enough to provide the zip files as well, THANK YOU, your work is appreciated.
Title: Re: Firefox 45.5 Install issues
Post by: Holger Schuett on June 16, 2017, 08:09:19 am
I would like to join Ian Manners in saying thank you for the time invested and the efforts of the few people that make it possible (for me) to still use OS2/ECS/ArcaOS.

(For the records : I do use RPM/Yum and yes,there have been some issues, but ever since I started using OS2 there have been issues, this is why I, for example, became a member here).

Once again thank you to all involved.

Holger