Firefox 38

[Marcel Mueller]

Hat jemand mal FF38 von Netlabs zum laufen bekommen?

Ich habe es hier mal versucht, aber das WPI-Paket hat Dutzende von
Dependencies, die angeblich nicht erfüllt sind. Keine Ahnung wo man
solchen Kram herbekommen soll. Ebenfalls keine Ahnung, warum er nicht in
dem Paket drin ist. Das meiste davon braucht doch außer FF sowieso niemand.


Marcel

[Andi B.]

Marcel Mueller schrieb:

> Hat jemand mal FF38 von Netlabs zum laufen bekommen?

Ja. Und zwar ganz einfach.

>
> Ich habe es hier mal versucht, aber das WPI-Paket hat Dutzende von
> Dependencies, die angeblich nicht erfüllt sind. Keine Ahnung wo man

Einfach die angegebenen yum install ... ausführen. Easy und problemlos
wenn man mal die Einstiegshürde überwunden hat und die diversen
Verzeichnisse mit dlls ausgemistet hat.

> solchen Kram herbekommen soll. Ebenfalls keine Ahnung, warum er nicht in
> dem Paket drin ist. Das meiste davon braucht doch außer FF sowieso niemand.

Das wird wohl nur mehr für sehr wenige User stimmen. Mittlerweile
benötigen viele Applikationen die ich verwende verschiedenste dieser
dlls. Es gibt diverse threads auf os2.ord und os2world.com über Probleme
die Leute beim Installieren haben. Auffällig daran, Probleme haben nur
Leute die sich vehement gegen yum/rpm/unixroot wehren. Die anderen
nicht. Klar kann jeder an seinem System basteln wie er will und rpm
ablehnen. Nur wenn man den yum/rpm Weg folgt, vereinfacht das vieles.

Andi

>
>
> Marcel

[Marcel Mueller]

On 06.05.16 20.46, Andi B. wrote:
>> Ich habe es hier mal versucht, aber das WPI-Paket hat Dutzende von
>> Dependencies, die angeblich nicht erfüllt sind. Keine Ahnung wo man
>
> Einfach die angegebenen yum install ... ausführen. Easy und problemlos

yum kenne ich nicht und habe ich nicht. Ich werde mal danach suchen...
wieder ein Installer mehr...

> wenn man mal die Einstiegshürde überwunden hat und die diversen
> Verzeichnisse mit dlls ausgemistet hat.

Da sollte eigentlich aufgeräumt sein. Außer den DLLs der verschiedenen
Firefox/Thunderbird Versionen, die mit LIBPATHSTRICT getrennt sind,
sollten sich da keine Doubletten tummeln.

>> solchen Kram herbekommen soll. Ebenfalls keine Ahnung, warum er nicht in
>> dem Paket drin ist. Das meiste davon braucht doch außer FF sowieso
>> niemand.
>
> Das wird wohl nur mehr für sehr wenige User stimmen.

Naja, von einer Lib mal nichts gehört zu haben, ist eine Sache, aber
gleich von einem Dutzend ist schon komisch. pixman10, gmod2, urpo, kai0 ...
Alles noch nie gehört, weder unter OS/2 noch unter Linux. (Naja,
wahrscheinlich heißen die in Wirklichkeit ganz anders, und haben nur
wegen des uralten Kernel-Bugs mit DLL-Namen >8 Zeichen so komischen Namen.)

> Mittlerweile
> benötigen viele Applikationen die ich verwende verschiedenste dieser
> dlls.

Ich kenne das eigentlich nur von den gcc Runtimes und von der libc in
verschiedenen Versionen. Die habe ich natürlich alle drauf.

> Es gibt diverse threads auf os2.ord und os2world.com über Probleme
> die Leute beim Installieren haben.

Threads ja, Lösungen nein.

> Auffällig daran, Probleme haben nur
> Leute die sich vehement gegen yum/rpm/unixroot wehren. Die anderen
> nicht. Klar kann jeder an seinem System basteln wie er will und rpm
> ablehnen. Nur wenn man den yum/rpm Weg folgt, vereinfacht das vieles.

Ich kommte yum bisher nicht ablehnen, da ich nichts von seiner Existenz
wusste.
Gibt es denn mittlerweile brauchbar gefüllte Paket-Repositories?

Firefox kam halt nun mal in einem WPI-Paket daher. Da habe ich mir nicht
ausgesucht. (Der WarpIn Installer löst auch nicht mehr Probleme als er
verursacht.)
Früher gab es einfach Warpzilla als ZIP-File. Da war vielleicht noch
eine readme drin. Das lief eigentlich immer auf Anhieb.
Selbst selber compilieren habe ich schon mal hinbekommen. Da gab es eine
ganz brauchbare Anleitung. (Vielleicht hätte ich das wieder tun sollen.)


Marcel

[Andi B.]

Marcel Mueller schrieb:
.....

> Naja, von einer Lib mal nichts gehört zu haben, ist eine Sache, aber
> gleich von einem Dutzend ist schon komisch. pixman10, gmod2, urpo, kai0 ...
> Alles noch nie gehört, weder unter OS/2 noch unter Linux. (Naja,
> wahrscheinlich heißen die in Wirklichkeit ganz anders, und haben nur
> wegen des uralten Kernel-Bugs mit DLL-Namen >8 Zeichen so komischen Namen.)

Ich sehe, du bist nicht so nah an den Entwicklungen der letzten Jahre
dran, sorry wußte ich nicht.

......

>
> Ich kommte yum bisher nicht ablehnen, da ich nichts von seiner Existenz
> wusste.
> Gibt es denn mittlerweile brauchbar gefüllte Paket-Repositories?
>
> Firefox kam halt nun mal in einem WPI-Paket daher. Da habe ich mir nicht

Die FF betas kommen als .zip siehe
https://github.com/bitwiseworks/mozilla-os2/releases. Die notwendigen
dlls dazu installiert man mit yum/rpm - so der Plan der Entwickler und
derer die noch maßgeblich an der Weiterentwicklung/Benutzbarkeit von
OS/2 arbeiten.

Die yum/rpm/%unixroot% Umgebung wird auch mit eCS2.2x mitinstalliert
wenn man diese nicht händisch abwählt (heutzutage auf jeden Fall
empfehlenswert). Kann natürlich auch nachträglich installiert werden -
http://trac.netlabs.org/rpm oder besser ArcaNoae Packet Manager (ANPM)
https://www.arcanoae.com/wiki/anpm (bevorzugte Variante wenn man mit rpm
anfängt). Ob der ohne Subscription verfügbar ist, weiß ich aber nicht.
Macht aber außer der graphischen Oberfläche nicht viel mehr als die
Kommandozeilenversion von netlabs.

Ja, es gibt Leute die packen FF mit einer Menge dlls in wpis. Oder
packen einen Stand von dlls und laden es hoch. Nur die dlls die gepackt
sind, können relativ schnell schon wieder alt sein :-(. Da du Linux
Erfahrung hast wirst du sicher wissen, dass ein wpi mit diversen shared
dlls keine gute Lösung sein kann im Vergleich zu einem Packet Manager.
Ob nun rpm gut ist oder es bessere Alternativen gäbe, steht für uns
nicht zur Debatte. Es gibt nur rpm. Und das meiste was heutzutage
entwickelt wird, kommt ins rpm.

Solltest du dich mit ANPM/yum/rpm anfreunden können, dann wird vorne im
LIBPATH %unixroot%\usr\lib und ein paar andere eingetragen (kann man
abwählen, finde ich aber schlecht). Leider bleibt der .\; am Anfang vom
LIBPATH - Empfehlung, diesen auch hinter die %unixroot% Verzeichnisse
schieben. Nur so bist halbwegs sicher, das die richtigen und aktuellsten
dlls aus %unixroot% verwendet werden. (Ich weiß, auch nicht 100%
garantiert, deshalb möglichst alle Dubletten suchen und löschen). Wenn
deine dlls aufgeräumt sind und du die aus dem netlaps rpm repos
verwendest, dann laufen auch die ganzen Sachen von netlabs inklusive FF.

Aber wie schon angedeutet, es gibt manche User die geradezu fanatisch
yum/rpm ablehnen. Oft sind es leider auch User die den Sinn von shared
dlls nicht verstanden haben und oft auch nicht wissen wie und wann diese
geladen, benutzt und entladen werden. Ein Grund warum die dDiskussionen
darüber so mühsam sind. Klar, der graphische Warpin Installer sieht auf
den ersten Blick besser aus als das Kommandozeilentool yum/rpm. Aber
eben nur auf den ersten Blick und mit dem ANPM sollte dies auch kein
Argument sein.

Grüße,
Andreas

[Marcel Mueller]

On 07.05.16 14.50, Andi B. wrote:
> Ich sehe, du bist nicht so nah an den Entwicklungen der letzten Jahre
> dran, sorry wußte ich nicht.

Ja, viel installiert habe ich nicht mehr. Viele täglichen Aufgaben sind
migriert. Für ein paar (z.T. erstaunlich einfache) Dinge habe ich noch
keinen adäquaten Ersatz gefunden. Eigentlich gehört surfen nicht dazu.
Aber zuweilen ist es schon praktisch, hie und da mal einen Link
anklicken zu können. Außerdem ist es eines der sichersten
Homebanking-Systeme überhaupt, da niemand so blöd ist, für die paar
Installationen Malware zu programmieren. Aber so allmählich ist FF24
doch etwas alt.

> Die FF betas kommen als .zip siehe
> https://github.com/bitwiseworks/mozilla-os2/releases. Die notwendigen
> dlls dazu installiert man mit yum/rpm - so der Plan der Entwickler und
> derer die noch maßgeblich an der Weiterentwicklung/Benutzbarkeit von
> OS/2 arbeiten.

Werde ich demnächst, wenn ich mal Zeit habe, angehen.

> Die yum/rpm/%unixroot% Umgebung wird auch mit eCS2.2x mitinstalliert
> wenn man diese nicht händisch abwählt (heutzutage auf jeden Fall
> empfehlenswert). Kann natürlich auch nachträglich installiert werden -
> http://trac.netlabs.org/rpm oder besser ArcaNoae Packet Manager (ANPM)
> https://www.arcanoae.com/wiki/anpm (bevorzugte Variante wenn man mit rpm
> anfängt). Ob der ohne Subscription verfügbar ist, weiß ich aber nicht.

Ich hänge hier auf einem eCS 1.05; allerdings durchgepatcht, bis der
Arzt kommt. Das sollte sich von der Basis her kaum von Neueren
unterscheiden. Nur die GUI Gimmicks sind natürlich nicht auf dem letzten
Stand.
Investieren werde ich in die tote Kuh aber trotz 25 Jahre wirklich
treuer Zusammenarbeit nichts mehr. Das Drops ist gelutscht.

> Ja, es gibt Leute die packen FF mit einer Menge dlls in wpis. Oder
> packen einen Stand von dlls und laden es hoch. Nur die dlls die gepackt
> sind, können relativ schnell schon wieder alt sein :-(.

Den Update-Wahn hat man unter eCS eigentlich nicht, weil es aufgrund des
Verbreitungsgrades keine ausgenutzen Sicherheitlücken gibt. AFAIK sind
in der gesamten Geschichte von OS/2 niemals Viren /in freier Wildbahn/
aufgetaucht. Angeblich gab es insgesamt ca. eine Hand voll im Labor.

> Da du Linux
> Erfahrung hast wirst du sicher wissen, dass ein wpi mit diversen shared
> dlls keine gute Lösung sein kann im Vergleich zu einem Packet Manager.

Jein. Ohne LIBPATHSTRICT geht sowieso die Hälfte nicht /gleichzeitig/
betreiben. Und mit hat man denselben Mist wie das riesige Datengrab
WinSxS bei Win.

> Ob nun rpm gut ist oder es bessere Alternativen gäbe, steht für uns
> nicht zur Debatte. Es gibt nur rpm. Und das meiste was heutzutage
> entwickelt wird, kommt ins rpm.

Wie das Ding heißt, ist am Ende egal.

> Solltest du dich mit ANPM/yum/rpm anfreunden können, dann wird vorne im
> LIBPATH %unixroot%\usr\lib und ein paar andere eingetragen (kann man
> abwählen, finde ich aber schlecht). Leider bleibt der .\; am Anfang vom
> LIBPATH - Empfehlung, diesen auch hinter die %unixroot% Verzeichnisse
> schieben.

Steht bei mir irgendwo mitten drin. Da haben sich ein paar Installer
vorgedrängelt.

> Nur so bist halbwegs sicher, das die richtigen und aktuellsten
> dlls aus %unixroot% verwendet werden. (Ich weiß, auch nicht 100%

OS/2 lädt eine DLL normalerweise nur, wenn nicht schon etwas
gleichnamiges im Speicher steht. Das gibt recht hässliche Abhängigkeiten
von der Startreihenfolge, wenn unterschiedliche Programme unter
demselben Namen unterschiedliches erwarten. Deshalb der Ärger mit
LIBPATHSTRICT.

> garantiert, deshalb möglichst alle Dubletten suchen und löschen). Wenn
> deine dlls aufgeräumt sind und du die aus dem netlaps rpm repos
> verwendest, dann laufen auch die ganzen Sachen von netlabs inklusive FF.

Dann läuft halt dafür das Zeug, was nicht von Netlabs ist, nicht mehr. ;-)

> Aber wie schon angedeutet, es gibt manche User die geradezu fanatisch
> yum/rpm ablehnen. Oft sind es leider auch User die den Sinn von shared
> dlls nicht verstanden haben und oft auch nicht wissen wie und wann diese
> geladen, benutzt und entladen werden.

Der Sinn der Shared Libs hat sich längst in Luft aufgelöst - im
besonderen unter OS/2!
LIBPATHSTRICT ist die eine Sache. Wesentlich mehr weh tut allerdings,
dass durch die exzessive Nutzung von Shared Libraries Der ganze Kram von
der private Arena in den Shared Memory wandert. Dadurch wird das System
bei vielen offenen Programmen früher oder später unbenutzbar, weil ihm
der virtuelle Speicher ausgeht. Das gibt dann alle möglichen
Ausfallerscheinungen, von fehlenden Kontextmenüs in der WPS über
nichtfunktionale Zwischenablage oder auch einfach spontane
Programmabstürze. Aufgrund der Fragmentierung der virtuellen Adressraums
erholt sich OS/2 davon auch durch Schließen einiger Anwendungen nicht mehr.
Vorwiegend statisch gelinkte Programme laufen hingegen nach wie vor.

Und last but not least ist auch noch die Wahrscheinlichkeit, dass zwei
verschiedene Programme eine DLL auch wirklich in /genau derselben
Version/ haben wollen eher gering. Folglich ist auch der Nutzen, die
Speicherersparnis, dahin.

> Ein Grund warum die dDiskussionen
> darüber so mühsam sind. Klar, der graphische Warpin Installer sieht auf
> den ersten Blick besser aus als das Kommandozeilentool yum/rpm.

WarpIn ist kein echter Mehrwert. Aber wenn ein Paket als WPI daherkommt,
braucht man ihn, Punkt.

> Aber
> eben nur auf den ersten Blick und mit dem ANPM sollte dies auch kein
> Argument sein.

Brauch' ich nicht.

Eher mache ich mir sorgen, dass mit dem ganzen Kram die Systempartition
voll läuft.


Marcel

[Andi B.]

Marcel Mueller schrieb:
....

>
> Ich hänge hier auf einem eCS 1.05; allerdings durchgepatcht, bis der
> Arzt kommt. Das sollte sich von der Basis her kaum von Neueren
> unterscheiden.

Dann ist eh alles okay. Allerdings ohne ArcaNoae subscription wirst du
das letzten JFS Paket und ACPI (wenn du es brauchst) nicht haben.

....

>
> Den Update-Wahn hat man unter eCS eigentlich nicht, weil es aufgrund des
> Verbreitungsgrades keine ausgenutzen Sicherheitlücken gibt. AFAIK sind

Sicherheitslücken sind nicht das Problem. Aber z.B. wichtige dlls wie
libc oder gcc1 haben einige fixes erhalten. Sind auch
rückwärtskompatibel mit forwarder dlls.

...

>
> Jein. Ohne LIBPATHSTRICT geht sowieso die Hälfte nicht /gleichzeitig/

LIBPATHSTRICT ist in manchen Situationen notwendig. Bei mir wenn ich
Seamonkey und FF gleichzeitig laufen lassen will weil beide eine xul.dll
brauchen, aber unterschiedliche. Ansonsten mache ich einen Bogen um
LIBPATHSTRICT. Das geht nämlich nicht wirklich gut. Versuche mal
mehrmals BEGINLIBPATH oder ENDLIBPATH und LIBPATHSTRICT zu verwenden und
die Kiste steht schneller als ein heutiges Win abstürzen kann :-( Du
füllst dir dadurch auch den Speicher mit diversen eventuell
gleichen/kompatiblen dlls an und das shared mem Problem kennst du ja.

...

>
> Steht bei mir irgendwo mitten drin. Da haben sich ein paar Installer
> vorgedrängelt.

Denen muß man das abgewöhnen. Sprich nicht erlauben bzw. die config.sys
selbst reparieren wenn der Installer so blöd ist.

....

>
> Dann läuft halt dafür das Zeug, was nicht von Netlabs ist, nicht mehr. ;-)

Mir ist nicht viel altes Zeug bekannt welches dann Probleme macht. Ja
manche EMX Programme. Aber ich finde für diese paar alten Sachen, so man
sie wirklich nutzt, ist es am Besten, diese mit LIBPATHSTRICT zu
starten. Hängt natürlich davon ab wieviel "altes" Zeug man im Vergleich
zu "neuem" Zeug laufen lassen will.

...

> Der Sinn der Shared Libs hat sich längst in Luft aufgelöst - im
> besonderen unter OS/2!

Nicht bei den portierten Sachen. Und die werden immer mehr und sie sind
mittlerweile essentiell wenn man noch komplett mit OS/2 arbeiten will.

> LIBPATHSTRICT ist die eine Sache. Wesentlich mehr weh tut allerdings,
> dass durch die exzessive Nutzung von Shared Libraries Der ganze Kram von
> der private Arena in den Shared Memory wandert. Dadurch wird das System
> bei vielen offenen Programmen früher oder später unbenutzbar, weil ihm
> der virtuelle Speicher ausgeht. Das gibt dann alle möglichen
> Ausfallerscheinungen, von fehlenden Kontextmenüs in der WPS über
> nichtfunktionale Zwischenablage oder auch einfach spontane
> Programmabstürze. Aufgrund der Fragmentierung der virtuellen Adressraums
> erholt sich OS/2 davon auch durch Schließen einiger Anwendungen nicht mehr.
> Vorwiegend statisch gelinkte Programme laufen hingegen nach wie vor.

Darum ist es unumgänglich, dass die ganzen portierten Sachen wie SM, FF,
AOO, QT4, Java... die dlls shared verwenden. Anderen Ausweg haben wir
wegen der Speicherbegrenzungen nicht.

>
> Und last but not least ist auch noch die Wahrscheinlichkeit, dass zwei
> verschiedene Programme eine DLL auch wirklich in /genau derselben
> Version/ haben wollen eher gering. Folglich ist auch der Nutzen, die
> Speicherersparnis, dahin.

Nun die libc und gcc sind ein schönes Beispiel dafür, dass es eben doch
funktioniert. Mit der kleinen forwarder dlls z.B. für libc61, läuft ein
solches Program nun mit der gefixten libc66.

...

>> Aber
>> eben nur auf den ersten Blick und mit dem ANPM sollte dies auch kein
>> Argument sein.
>
> Brauch' ich nicht.
>
> Eher mache ich mir sorgen, dass mit dem ganzen Kram die Systempartition
> voll läuft.

Mein %unixroot% und (fast) alle meine Programme sind auf der
Programmpartition P:. Die Systempartitions (M:, D:, ...) werden damit
nicht belastet.

Andi

[T.]

Hallo Marcel,

> yum kenne ich nicht und habe ich nicht. Ich werde mal danach suchen...
> wieder ein Installer mehr...

hier wird Dir geholfen:

<http://www.os2.org/viewtopic.php?f=6&t=893&start=25#p5626>
--

Gruesse,

Thorolf

[Marcel Mueller]

On 07.05.16 22.20, Andi B. wrote:
> Marcel Mueller schrieb:
> ....
>>
>> Ich hänge hier auf einem eCS 1.05; allerdings durchgepatcht, bis der
>> Arzt kommt. Das sollte sich von der Basis her kaum von Neueren
>> unterscheiden.
> Dann ist eh alles okay. Allerdings ohne ArcaNoae subscription wirst du
> das letzten JFS Paket und ACPI (wenn du es brauchst) nicht haben.

Nutze ich beides nicht mehr, da OS/2 nur noch in VMs existiert. Und da
liegen die Daten auf dem Fileserver. Da ist lediglich noch eine
Systempartition mit ein paar GB lokal. Und die läuft mit dem alten
HPFS386-Treiber wunderbar.

>> Den Update-Wahn hat man unter eCS eigentlich nicht, weil es aufgrund des
>> Verbreitungsgrades keine ausgenutzen Sicherheitlücken gibt. AFAIK sind
> Sicherheitslücken sind nicht das Problem. Aber z.B. wichtige dlls wie
> libc oder gcc1 haben einige fixes erhalten. Sind auch
> rückwärtskompatibel mit forwarder dlls.

Bei gcc und libc ja. Bei allem anderen eher nicht.
Aber die gcc DLLs bekommt man an jeder Ecke, und die habe ich auch alle
drauf. (Hie und da compiliere ich selber mal was mit gcc 4.8.x, da
brauche ich die sowieso.)

>> Jein. Ohne LIBPATHSTRICT geht sowieso die Hälfte nicht /gleichzeitig/
> LIBPATHSTRICT ist in manchen Situationen notwendig. Bei mir wenn ich
> Seamonkey und FF gleichzeitig laufen lassen will weil beide eine xul.dll
> brauchen, aber unterschiedliche.

Exakt. Thunderbird und Kompozer gehören auch noch in die Schublade. Im
Prinzip alle Forks der Mozilla Codebase.
Das sind die Punkte, wo die DLLs keinen Meter Sinn ergeben und nur
Shared Memory kosten. Und XUL.DLL ist nicht klein.

> Ansonsten mache ich einen Bogen um
> LIBPATHSTRICT. Das geht nämlich nicht wirklich gut. Versuche mal
> mehrmals BEGINLIBPATH oder ENDLIBPATH und LIBPATHSTRICT zu verwenden und

? - Hatte noch keine Probleme damit. Aber ich nutze es auch nicht soo
exzessiv. Wobei TB und FF laufen eigentlich immer parallel mit
LIBPATHSTRICT.

> die Kiste steht schneller als ein heutiges Win abstürzen kann :-(

Da wäre ich vorsichtig. Win überrundet OS/2 schon lange in der Uptime,
und zwar mehrfach. Auch wenn man das hier vllt. nicht hören will.

Ich meine, es gibt noch andere Faktoren, die die Uptime beeinflussen. So
überleben z.B. Desktop-Rechner in der Praxis länger als Notebooks. Und
VMs leben wiederum länger als Desktops. Das gilt nach meinen Erfahrungen
erst mal unabhängig vom OS, natürlich skaliert es mit insgesamt mit der
Systemstabilität des jeweiligen OS. Und dadurch trägt es sich sogar zu,
dass ein Win auf dem Notebook ein OS/2 in der VM durchaus überrundet,
was den Klassen-Unterschied mehr als verdeutlicht.

Win ist bei mir aus ganz anderen Gründen raus. Ab XP haben mir die
Lizenzbedingungen für den Privatmann nicht mehr gefallen. Und ab 10
verbietet der Datenschutz den Zugang zum Hausnetz. Da kann von mir aus
kommen, wer will.

> Du
> füllst dir dadurch auch den Speicher mit diversen eventuell
> gleichen/kompatiblen dlls an

Wenn man sie vorher dedupliziert hat, geht es eigentlich.

>> Steht bei mir irgendwo mitten drin. Da haben sich ein paar Installer
>> vorgedrängelt.
> Denen muß man das abgewöhnen. Sprich nicht erlauben bzw. die config.sys
> selbst reparieren wenn der Installer so blöd ist.

Keine Ahnung. Ist schon lange so. War irgendwelches IBM-Zeug. Solange es
funktioniert, spiele ich da nicht gerne dran rum.

>> Dann läuft halt dafür das Zeug, was nicht von Netlabs ist, nicht mehr.
>> ;-)
> Mir ist nicht viel altes Zeug bekannt welches dann Probleme macht. Ja
> manche EMX Programme. Aber ich finde für diese paar alten Sachen, so man
> sie wirklich nutzt, ist es am Besten, diese mit LIBPATHSTRICT zu
> starten. Hängt natürlich davon ab wieviel "altes" Zeug man im Vergleich
> zu "neuem" Zeug laufen lassen will.

Da habe ich ehrlich gesagt keinen Überblick, was da genau mit welchem
Framework compiliert wurde.

> ...
>> Der Sinn der Shared Libs hat sich längst in Luft aufgelöst - im
>> besonderen unter OS/2!
> Nicht bei den portierten Sachen. Und die werden immer mehr und sie sind
> mittlerweile essentiell wenn man noch komplett mit OS/2 arbeiten will.

Dass diese Programme sie verwenden, bedeutet noch lange nicht, dass es
Sinn ergibt, siehe XUL.DLL.
Auf einem 64 Bit System mag das mit den Ressourcen egal sein. Unter OS/2
nicht. Noch dazu, da es noch jede Menge Programme gibt, die auf die 16
Bit Kompatibilität nicht verzichten können, also auf 512MB beschränkt
sind. Eigentlich alles, was mit der WPS interagiert.

>> Vorwiegend statisch gelinkte Programme laufen hingegen nach wie vor.
> Darum ist es unumgänglich, dass die ganzen portierten Sachen wie SM, FF,
> AOO, QT4, Java... die dlls shared verwenden. Anderen Ausweg haben wir
> wegen der Speicherbegrenzungen nicht.

Das Gegenteil ist der Fall! Würden die zumindest ihren eigenen Kram
statisch linken, würde das Fragmentierungsproblem beim Adressraum gar
nicht existieren. In dem Fall würde nämlich jedes Programm beim Start
2GB komplett leeren (privaten) Adressraum sehen. Das tut es so auch, nur
wird er eben nicht für das Programm selbst benutzt, sondern nur für die
Daten. Und der Shared Memory wird mit ständigen Allokationen und
Deallokationen von eigentlich privaten DLLs zu Hackfleisch gemacht.

>> Und last but not least ist auch noch die Wahrscheinlichkeit, dass zwei
>> verschiedene Programme eine DLL auch wirklich in /genau derselben
>> Version/ haben wollen eher gering. Folglich ist auch der Nutzen, die
>> Speicherersparnis, dahin.
> Nun die libc und gcc sind ein schönes Beispiel dafür, dass es eben doch
> funktioniert. Mit der kleinen forwarder dlls z.B. für libc61, läuft ein
> solches Program nun mit der gefixten libc66.

Ja, und das /einzige/ Beispiel auch.

Bleibt nur noch eine Frage im Raum stehen: was stört mich mehr:
- 29k gcc1.dll,
- 1,3MB libcxx.dll oder
- 30 MB xul.dll?
Die Ersparnis selbst durch libc ist gegen letztere vollkommen
vernachlässigbar.

Es gibt genau einen einzigen Punkt, wo die Shared Libraries in dieser
Nutzungsform wirklich helfen: beim Patchen von Sicherheitslöchern. Man
muss einfach nicht jede Anwendung durchkompilieren und aktualisieren,
was in der Praxis sowieso nicht funktioniert. Und der Sicherheitsaspekt
ist unter OS/2 wiederum in der Praxis weitgehend irrelevant.

>> Eher mache ich mir sorgen, dass mit dem ganzen Kram die Systempartition
>> voll läuft.
> Mein %unixroot% und (fast) alle meine Programme sind auf der
> Programmpartition P:. Die Systempartitions (M:, D:, ...) werden damit
> nicht belastet.

Ich habe nur ein kleines Systemvolume Lokal. Der Rest liegt auf dem
Server. Die Anbindung ist zwar gut, aber es gibt einige Programme, die
von dort aufgrund von Bugs oder Work-Arounds in der gcc-Runtime nicht
funktionieren oder zumindest nicht benutzbar sind. Thunderbird z.B.
stürzt nach wenigen Sekunden ab. (Vermutlich ein Samba-Bug.) Als er mit
älteren Samba-Server-Versionen noch lief, war er unbenutzbar langsam.
Bei Netzwerktraces erfolgten exzessiv viele Zugriffe auf immer dieselben
Daten. Auch make-Utilities oder gcc zeigen dieselben vielen
Netzwerk-Zugriffe und sind dann Faktor 5-10 langsamer. Ich gehe daher
von einem Bug in der Runtime aus. Das kam glaube ich mit dem
missglückten Versuch, Unix-Rechte in EAs abzubilden.

Faktisch muss also alles auf die 5GB Systemplatte, wenn es laufen soll.
Nur die Userdaten liegen auf dem Server.


Marcel

[Andreas Kohl]

Marcel Mueller schrieb:

> Hat jemand mal FF38 von Netlabs zum laufen bekommen?
>
> Ich habe es hier mal versucht, aber das WPI-Paket hat Dutzende von
> Dependencies, die angeblich nicht erfüllt sind. Keine Ahnung wo man
> solchen Kram herbekommen soll.

Da bei Dir WPI schon vorhanden ist, würde ich die Seite
<http://os2news.warpstock.org/Warpzilla.html> empfehlen.

Es werden benötigt:
<http://os2news.warpstock.org/mozsupport-2016-04-29.zip>
<http://rpm.netlabs.org/release/00/zip/fontconfig-2_11_95-1_oc00.zip>

> Ebenfalls keine Ahnung, warum er nicht in
> dem Paket drin ist. Das meiste davon braucht doch außer FF sowieso niemand.

Deshalb würde ich die DLL-Dateien sicherheitshalber auch nur in das
Programmverzeichnis kopieren, da sonst eventuell bestehende Programme in
Mitleidenschaft gezogen werden können.

--
Andreas