Author Topic: Firefox 45.5 Install issues  (Read 3451 times)

Dmitriy Kuminov

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 7
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #45 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.
« Last Edit: June 03, 2017, 03:11:59 am by Dmitriy Kuminov »
CPO of bww bitwise works GmbH

Matt Walsh

  • Newbie
  • *
  • Thank You
  • -Given: 3
  • -Receive: 0
  • Posts: 13
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #46 on: June 14, 2017, 10:37:41 pm »
Thanks Dmitry.  :)

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 659
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #47 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 ....

   

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 236
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #48 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...

Herwig Bauernfeind

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 34
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #49 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.

Andreas Kohl

  • Full Member
  • ***
  • Thank You
  • -Given: 6
  • -Receive: 9
  • Posts: 216
    • View Profile
    • warpserver.de
Re: Firefox 45.5 Install issues
« Reply #50 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.

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 659
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #51 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.

 

Dmitriy Kuminov

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 7
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #52 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.
CPO of bww bitwise works GmbH

Ian Manners

  • Global Moderator
  • Full Member
  • *****
  • Thank You
  • -Given: 31
  • -Receive: 18
  • Posts: 249
  • I am the computer, it is me.
    • View Profile
    • OS/2 Site
Re: Firefox 45.5 Install issues
« Reply #53 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.
Cheers
Ian B Manners

Holger Schuett

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 1
  • Posts: 45
    • View Profile
Re: Firefox 45.5 Install issues
« Reply #54 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