Author Topic: Blue Lion Beta testing...  (Read 30395 times)

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Blue Lion Beta testing...
« Reply #30 on: February 13, 2017, 12:47:12 am »
the new installer is the number one must do upgrade
I agree. The upgrade feature will be added as more as
  • more components were packed as .rpm packages or
  • more features were added to WarpIN's wic.exe like e.g. automated uninstallation.

Sigurd Fastenrath

  • Hero Member
  • *****
  • Posts: 577
  • Karma: +27/-0
  • OS/2 Versus Hardware - Maximum Warp!
    • View Profile
Re: Blue Lion Beta testing...
« Reply #31 on: February 13, 2017, 09:21:42 am »
You can certainly ask Arca Noae if you can join the testing group.  (I don't know if more members are being solicited at this time, but asking is pretty much a free action.)  However, asking about hardware support in a particular beta release isn't really useful if you're not actually going to be using that beta.  Beta-cycle software is by definition a moving target, so predicting the state of driver versions in the final release based on the contents of a beta is not really scientific.

The drivers you mention are, TTBOMK, all in the development queue. Generally speaking, once updated versions of these (and other) drivers are considered stable to Arca Noae's satisfaction, they will be released.

Arca Noae's drivers are released through the subscription service; I would say it's safe to assume that ArcaOS 5.0 will also include the most up-to-date versions at the time of release.

Hi Alex,

thanks for your Reply, my Intention was just to ask wether or not these (updated) Drivers will be included in the GA or not. I did not know that I had to be part of a beta testing Group (I offered my help before as written) for this simple questions nor wanted to have a "principled discussion" about beta Software. I was assuming that a "beta stage" (with the GA to be expected 8 weeks later) would be complete when it comes to the question what Drivers are included. It seemed to me to be logical - if these Drivers would be ready - then those will be included in the beta stage, and if not - these are simply not included. I guessed that each of these Drivers, once ready, would need intense testing again. All the more, because these Drivers come from Arca Noae, where the ones they already made availiable have such a good Quality so far!

From all that's written here I extract that None of them are included, wich leads to a simple "No".

Of course I am looking forward to the GA and I am happy that it will take place at all!

ivan

  • Hero Member
  • *****
  • Posts: 1560
  • Karma: +17/-0
    • View Profile
Re: Blue Lion Beta testing...
« Reply #32 on: February 15, 2017, 01:22:22 pm »
Quote
more components were packed as .rpm packages

I hope not!  OS/2 is not a Unix/Linux system and should never be.

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1027
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Re: Blue Lion Beta testing...
« Reply #33 on: February 15, 2017, 05:51:24 pm »
Quote
more components were packed as .rpm packages

I hope not!  OS/2 is not a Unix/Linux system and should never be.

This seems to be Arca Noae's position. More .rpm, a few things that aren't .rpm will become so. For people on other branches, like eCS, MPC or Warp 4, .rpm capability will be an important option.
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Blue Lion Beta testing...
« Reply #34 on: February 16, 2017, 07:28:55 am »
Quote
more components were packed as .rpm packages

I hope not!  OS/2 is not a Unix/Linux system and should never be.

Well, OS/2 is not Unix/Linux, and never will be. ArcaOS, on the other hand, is going to use Arca Noae Package Manager (RPM/YUM). This really has nothing to do with turning OS/2 into a Unix/Linux system. It is simply a semi-automated method to distribute software, and make sure that all prereqs are met, with minimal user interaction. It is probably not the best way to do it, but it is the way that it is being done. The other option seems to be to simply stop updating things like Firefox, and AOO, unless you want to jump through hoops trying to sort out what you need to do to make it work (welcome to DLL H**L).

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4805
  • Karma: +99/-1
    • View Profile
Re: Blue Lion Beta testing...
« Reply #35 on: February 16, 2017, 08:44:46 am »
Firefox and probably OO could be built with way fewer dependencies and the needed dependencies such as fontconfig could be more OS/2 friendly. The problem is time. There's a shortage of developer resources with dmik for example seeming to always be working on at least half a dozen things. It's quicker and simpler to just port something once and reuse it and the more simple the port can be, the quicker.
Even the time spent compiling some of this stuff can be reduced. I just compiled SM 2.42 to the expected build break linking xul.dll and it took 256 minutes, and that's without compiling things like nspr. Now we probably have a problem with our toolchain that might be hard to fix, I know I couldn't and I'm glad that we have someone like dmik who will probably figure out a fix.
It's amazing how far this OS that was designed originally 30 years ago has done but we're a small community with limited resources which force some decisions to be made including grabbing an already package manager and using it.
Arca Noae has the same problems, shortage of resources, probably money as well and they've decided on a beta procedure that they can support. It looks like they'll be able to get ArcaOS 5.0 out the door before Apr and then they can go back to fixing and creating drivers etc.

ivan

  • Hero Member
  • *****
  • Posts: 1560
  • Karma: +17/-0
    • View Profile
Re: Blue Lion Beta testing...
« Reply #36 on: February 16, 2017, 09:36:07 am »
I know all these arguments but when a client asks 'if OS/2 is turning into Linux why don't we just dump it and use Linux?'

I find I need to say something and ask how many other organisations are wondering the same thing.  It could end up with the use of OS/2 becoming smaller not larger as we were hoping.

Dave, I can understand your point about the tools used but from my engineering viewpoint wouldn't it be better to spend the time fixing the tools first?

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: Blue Lion Beta testing...
« Reply #37 on: February 16, 2017, 11:02:26 pm »
To come back to the original question, it looks like Uniaud is being worked on again. David A is busy cleaning up the build system.

Roderick Klein

  • Hero Member
  • *****
  • Posts: 659
  • Karma: +14/-0
    • View Profile
Re: Blue Lion Beta testing...
« Reply #38 on: February 18, 2017, 08:50:17 pm »
I know all these arguments but when a client asks 'if OS/2 is turning into Linux why don't we just dump it and use Linux?'

I find I need to say something and ask how many other organisations are wondering the same thing.  It could end up with the use of OS/2 becoming smaller not larger as we were hoping.

Dave, I can understand your point about the tools used but from my engineering viewpoint wouldn't it be better to spend the time fixing the tools first?


Ivan,

If people ask if OS/2 is turning into Linux. What is the definition of "turning into Linux"  ?

I do not know who these organizations that ask these questions you raise Ivan.  I also guess you can not disclose this. What I mean is if you mean organizations these are companies you provide consultancy services for that use OS/2 ? If these organizations and people have certain exceptions they are not very well known. I know BWW is still asking for extra funding...

As for native discussion and what makes OS/2 OS/2 ?!

* For years the GCC compiler and LIBC libraries have been the life line for OS/2 to get new software (Is LIBC native !?). Years ago this was started by innotek because the old IBM compilers no longer supported the new C++ dialects used in Mozilla (any of the experts, is that correct ?). Every OS/2 users has tons of GCC compiled on OS/2 system.
Few OS/2 users asked if we could not have a "native" OS/2 browser (what ever you could call native).

* Heck the last versions of Lotus Smartsuite to a large extend used OPEN32. Is that "native" ?
(Heck it used the system.dat user.dat).  Nobody raised the point that running Lotus Smartsuite on OS/2 you could just as well run Windows.

* The Java version from Goldencode was the last Java version that was compiled for OS/2 with something like ODIN in between.  Plenty of people used the Java ODIN versions  and never asked "well is OS/2 not turning into Windows" ?

* I just do not get it why the directory structure that the RPM/GCC applications bring to OS/2 make it "more of being" a Linux distribution then when using GCC apps. Also then we do have an RPM format for packages.

I guess you get the gist of my points. What is native OS/2 ? Since 2000 the amount of resources IBM allocated to OS/2 have been reduced. And to be honest I think its miracle we still can boot OS/2 in the current shape we have it now in conjunction with all drivers we have. Considering how many contribute...

Having been to Warpstock US 2014 in Witchita Kansas. I organized most of the Warpstock Europe events in the last 5 years alone. You know what the primary reason was why people wanted to dump OS/2 ?
Because their web browser, they did not know how to update it properly.  And so websites could not load and they and had put Linux  next to OS/2 or migrated.

In the grand scheme of things I think that is what people who do not like RPM should consider. Yes its true maybe the community could have created a "native" package (and reinvent the wheel). Maybe come up with a new software update framework. But with our limited human resources, why reinvent the wheel ?

Is RPM perfect ? Well maybe its not. But for developers it reduces the time they need to spend and makes live easier for a lot of people to update software.

To be honest I think a portion of the OS/2 are just way to conservative to accept change.   And its rather fear of the unknown...
My guess is that in about 1 year RPM/YUM will be accepted by most developers and most people will find it easy to just hit the update button and download an install all packages with a push of the button...

My conclusion OS/2 being  "native OS/2" basically ended when circa 2000 when IBM stopped updating compilers.
Heck you could say we no longer have a native compiler ? I am just trying to point out this discussion about what is native and that OS/2 is no longer OS/2 etc is somewhat of strange discussion.

We now have Open Watcom compiler and the GCC compiler and I think we should count our blessings how much software and drivers we have.  The developers developing for OS/2 have to make chooses. And if people expect differently then I guess somebody should put a bag of money on the counter to develop an alternative for RPM for example.

Anyway more news will follow on Warpstock Euroep 2017 for people who are interested. See www.warpstock.eu for details.  The amount of visitors has been rising over the last 2 years so lets see what happens.

Roderick Klein

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4805
  • Karma: +99/-1
    • View Profile
Re: Blue Lion Beta testing...
« Reply #39 on: February 18, 2017, 10:22:06 pm »

As for native discussion and what makes OS/2 OS/2 ?!

* For years the GCC compiler and LIBC libraries have been the life line for OS/2 to get new software (Is LIBC native !?). Years ago this was started by innotek because the old IBM compilers no longer supported the new C++ dialects used in Mozilla (any of the experts, is that correct ?). Every OS/2 users has tons of GCC compiled on OS/2 system.
Few OS/2 users asked if we could not have a "native" OS/2 browser (what ever you could call native).

OS/2 (ver2+) had as one of its design goals to be POSIX conforming. The native toolkit included a libc and to quote the Toolkits  C Library Reference, aimed to conform to,
Quote
The American National Standards Institute C Standard and International Standards Organization, ANSI/ISO 9899-1990[1992], and the amendment ISO/IEC 9899:1990/Amendment 1:1993(E)
The ISO/IEC 9945-1:1990/IEEE POSIX 1003.1-1990 standard
The X/Open Common Applications Environment Specification, System Interfaces and Headers, Issue 4
The IBM Systems Application Architecture (SAA) C Level 2 language definition.

Linux and the other Unixes, and even Windows to a degree, on and off, all strive to be compatible to the first 3 of the above, though newer versions of the standard. So you could say that one of the native characteristics of OS/2 is being able to compile programs written for POSIX, ANSI etc. This would include GCC.
As Roderick said, our current libc was developed under contract by Innotek to support GCC in compiling Mozilla and one of the former Innotek employees, still employed by Oracle to support VirtualBox, kept on supporting our libc in his spare time and also tried to make it conform to the SUS (Single Unix Specification).  BTW, VirtualBox was written to run OS/2, so is kind of a native program that has been ported to most other systems.
Today many programs are written to be cross-platform. Mozilla doesn't really have a native base, on all systems it just pretends to be native, using XUL etc to build native looking windows and using some native widgets. QT is another cross-platform library that allows us to run all kinds of programs and have them look native. Libc is just a lower level library to allow various programs to run on OS/2.

As for fixing the tools. It's not so simple. You design a hammer to pound in the average 1-3 inch nail and one day you need to pound in a 10 inch spike. You make your hammer bigger or design a sledge hammer. The another day you're building some cabinets and need to pound in little tiny nails and now your hammer needs to be fixed again or a new light weight hammer designed.
That's just the fun of designing a hammer, most of our tools are much more complicated but still come across new or different uses. Rather then fixing the tools, it's more like evolving the tools. There's also the rare corner cases that only get fixed when something needs the corner case. That's the state of compiling Mozilla now, a corner case (using weak symbols to ignore a missing symbol) that doesn't work right, so the tool needs updating.