Das Ende von OS/2 und eCS zu Gunsten von ArcaOS rückt näher.....

[Sigurd]

Wenn ich es Recht verstehe, ist das Ende für "normale" OS/2 und EcomStation Benutzer wohl in relativ greifbare Nähe gerückt.

Es gibt ja nun diese neuen Dateien von ArcaNoae:

- Kernel 14.201
- ACPI 3.23.06
- AHCI 2.03

Alle drei bedingen sich mehr oder weniger irgendwie wechselseitig.

Auf meinem "selbstgezüchteten" OS/2 geschieht dabei folgendes:

- ACPI 3.23.06 läßt sich zwar installieren, bringt aber bei der Installation und beim Booten "Nicht Kompatibilitätshinweise" und arbeitet zudem nur auf einem Kernel

- AHCI 2.03 verweigert die Installation, wenn kein ACPI 3.23.06 installiert ist

- Den Kernel zu installieren versucht habe ich noch nicht.

In den Readme Dateien findet sich, dass diese Dateien nicht mehr OS/2 oder eCS Versionen unterstützen und damit doch nun ein guter Punkt gekommen sei, auf ArcaOS umzusteigen.

Ich finde das mehr als bedauerlich! Damit steuern wir wohl endgültig auf die "Monokultur" zu, zumindest was aktuelle Hardware angeht. Virtuell kann man ja ohnehin mit allem vorherigen ebenfalls leben.
Aber evtl. geht es dort ja auch mal weiter, wenn neuere Firefox, Samba o.ä. Versionen bestimmte ArcaOS Dateien voraus setzen.

Ich kann mich damit nicht anfreunden, so zufrieden und begrüßenswert ich den Fortschritt bei ArcaNoae auch sehe bzw. bin.

[Sepp Mayr]

Na jo, de woin hoid ihr Betriebssystem gewinnbringend unta de Leid bringn.
Und so schlecht finde i des OS gar ned.

[erdmann]

So ist es.
Irgendwie sehe ich dabei auch keinen Unterschied zu Microsoft mehr. Man nehme einen Standard und mache den dann zu etwas Propriäterem.
Es läuft halt doch alles über Zwang.

[aschn]

Bedrohlich. Jemand sollte mal die Meinung dazu von Lewis einholen. Vorher spreche ich hier keine Vermutungen aus.

[LotharS]

Es gibt ja nun diese neuen Dateien von ArcaNoae:
- Kernel 14.201
- ACPI 3.23.06
- AHCI 2.03
Alle drei bedingen sich mehr oder weniger irgendwie wechselseitig.

Wenn ich diese News richtig interpretiert habe, so bedingen diese neuen Treiber einander unter bestimmten Gegebenheiten, z.B. zu AHCI:
"In version 2.03, Added support for message interrupts. This will allow certain motherboards with nonfunctional interrupt pin hardware to run. ACPI PSD version 3.23.06 is required for message interrupts to be enabled."

In den Readme Dateien findet sich, dass diese Dateien nicht mehr OS/2 oder eCS Versionen unterstützen und damit doch nun ein guter Punkt gekommen sei, auf ArcaOS umzusteigen.

Zum Kernel 14.201 habe ich das auch gelesen (in o.a. News), aber die Treiber stehen demnach allen Usern offen, z.B. ACPI:
"This release is an update for all users and is newer than the version in ArcaOS 5.0.1." und in deren Readme.txt's finde ich nichts Gegenteiliges.
Die Treiber (nicht der Kernel) finden sich inzwischen auch in der alten OS/2-eCS-Subscription. In meiner eCS-VM sind die Treiber (nicht der neue Kernel!) jedenfalls klaglos installiert; was Deiner OS/2-Nachzucht leider nicht direkt weiterhilft, wünsche Dir auf jeden Fall aber den richtigen Trick (wenn's einen geben sollte) Häufiger Punkt: DOSCALL1.DLL?

Das Ende von OS/2 und eCS zu Gunsten von ArcaOS rückt näher.....

Die offizielle "Einladung" seitens AN ist ja schon mehrfach gesagt worden (immerhin höflicher als brute-force bei M$). Ansonsten hält meinereiner Prognosen immer für schwierig, besonders wenn sie die Zukunft betreffen... Und im Ernst: Was wissen wir, wer den Dauer-Wettlauf zwischen Hardware und Software gewinnen wird? Am Ende vielleicht doch noch Apple?

[LotharS]

Na jo, de woin hoid ihr Betriebssystem gewinnbringend unta de Leid bringn.

Dahinter steckt schließlich auch "Humankapital". Wird in der Schnäppchen-Community manchmal übersehen

[thorolf]

Dahinter steckt schließlich auch "Humankapital". Wird in der Schnäppchen-Community manchmal übersehen

ist ja OK, solange das extra Treiberpaket weiter angeboten wird ist mir das egal. Bevor ich nämlich ArcaOS installiere und alles neu einrichte, nehme ich lieber eine bestehende Installation von OS/2 oder eCS und aktualisiere ein paar Treiber.

Wirklich mehr ist in ArcaOS ja auch nicht passiert ...

[ak120]

ist ja OK, solange das extra Treiberpaket weiter angeboten wird ist mir das egal.

Ich nehme mal an, daß es Sigurd nicht darum ging. Vielmehr ist die Bezeichnung desselben durchaus etwas irreführend. Im AN-Verkauf wird es als für "eComStation & OS/2" bezeichnet. Ob die einzelnen WPI-Pakete auch wirklich noch auf realen Systemen installierbar sind, bleibt weitestgehend fraglich. Durch die Verdongelung spezifischer Versionen kann man das "OS/2" wohl vollständig streichen. Der ACPI-Treiber scheint nur mit Kernel-Versionen zusammenarbeiten zu wollen, welche bspw. für die letzten deutschen (und anderen internationalen) OS/2-Fixstände überhaupt nicht zur Verfügung stehen. Nur wer Warp Server for e-business am laufen hat, kann evtl. noch auf eine SMP-Kernelversion ausweichen, welche natürlich weder mit ACPI getestet wurde, noch als kompatibel in der entsprechenden README erwähnt wird. Für Bastelfreudige ist es u.U. kein Problem einen hinreichend aktuellen US-Kernel manuell einzubinden - für Nutzer von Anwendungen, welche nur gegen den UNI-Kernel zertifiziert bzw. lizenziert wurden, kann es schon problematisch werden. Solange keine zeitkritischen Anforderungen bestehen, bleibt fast nur noch der Umzug in eine VM.

Bevor ich nämlich ArcaOS installiere und alles neu einrichte, nehme ich lieber eine bestehende Installation von OS/2 oder eCS und aktualisiere ein paar Treiber.

Wirklich mehr ist in ArcaOS ja auch nicht passiert ...

Ein paar Fehler mehr sind logischerweise hinzugekommen. Eine Sicherung der bestehenden funktionierenden Konfiguration ist auf jeden Fall ratsam.

[aschn]

solange das extra Treiberpaket weiter angeboten wird ist mir das egal. Bevor ich nämlich ArcaOS installiere und alles neu einrichte, nehme ich lieber eine bestehende Installation von OS/2 oder eCS und aktualisiere ein paar Treiber.

So mach ich es auch. Auf meinem ursprünglichen eCS 2.0 rc4 läuft bisher noch alles, trotz fehlender \ecs\ecs_inst.flg und jetzt \sys\install\install.flg. Bis ich vollständig auf das neu installierte System wechsel, das dauert noch. Bei der Installation lief viel zu viel schief, als dass ich das zu meinem Hauptsystem machen könnte.

Wirklich mehr ist in ArcaOS ja auch nicht passiert

Die Aktivität ist schon merklich angestiegen, nur leider fehlen die letzten beiden Jahre von eCS und die ersten beiden von ArcaOS. Da ist für die Nutzer nichts bei herausgekommen, verschenkte Jahre also. Mal sehen, ob das auch langfristig gesehn die Erkenntnis wird. Natürlich hoffen wir alle das Gegenteil. ArcaOS ist nun mal die einzige und letzte Möglichkeit.

Etwas mehr Open-Source-Gedanke würde dem Gesamtsystem wirklich gut tun. Die Verschlossenheit nervt mich schon ganz ordentlich. Die lässt sich sicherlich nicht nur mit sonst erhöhtem Supportaufwand begründen und auch nicht mit zuwenig Manpower. Mit Open Source Software könnten sich wenigstens versierte Nutzer die Quellen ansehen und sich dann selbst ein Bild vom Stand machen. Das ist so nicht mal im Ansatz möglich. Auch kann ich so nichts dazu beitragen, selbst bei Teilen, wo es möglich wäre. (Bei eCS wurde das für mich etwas offener gehandhabt, weil ich Übersatzer war.)

Mich nerven:

• verschlossene Repositories auf netlabs.org (z.B. USB, gabs auch schon zu eCS-Zeiten - warum soll ich mir als zahlender OS/2-Nutzer nicht die Quellen ansehen dürfen?),
• viel zu wenig Doku über die Änderungen in Davids Paketen (wortkarger gehts nicht),
• die geheim gehaltene Kernel- und Snap-Entwicklung,
• die geheim gehaltene Entwicklung des Installationsprogramms (warum nicht OSS?),
• fehlende Update-Möglichkeit bestehender Systeme.

Das Ergebnis ist bisher gut, wird aber auf Dauer nicht alle Mittel "heiligen". Leute, Ihr setzt haufenweise OSS ein, also öffnet Euch ein bischen mehr dafür. Es geht natürlich nur um die Erweiterungen und Verbesserungen, die nicht von IBM kommen. Jedenfalls wird es keinen Nachahmer geben, der Euren Firmenkunden das Produkt dann für die Hälfte verkauft.

[aschn]

https://mantis.arcanoae.com/view.php?id=1332 klingt interessant. Dabei geht es darum, dass der Kernel nicht über die Subscription erhältlich ist.

15.08.2017: Der Fehler ist erledigt. Grund war nur das Anklicken des falschen Pakets unter Orders & Subscriptions.

[LotharS]

Alles in allem wohl ein lizenzrechtlicher Aspekt. Wie immer stecken hinter sowas kaufmännische Interessen (der Anbieter...). In unserem Fall folgere ich, dass IBM zwar nicht mehr liefert, aber immer noch kassiert (und M$ indirekt noch mit?). Soweit mein juristischer Laienverstand

Gefunden auf os2world:

Arca Noae's license, from IBM, does not allow distribution of the kernel out of the context of ArcaOS. IBM has no claim on ACPI, AHCI, or MultiMac and, hence, have no such restrictions. The new ACPI has no requirement for the new kernel, though, some hardware may not work without the new kernel due to needing over IRQ 31 (same problem exists with the older ACPI, except could result in a trap rather than just the hardware not working).

Nebenbei: VirtualBox liefert mir eine "Hardware", für die ich ArcaOS nicht bräuchte - und diese Nuller-Version auch nicht produktiv nutze. Manchmal bin ich einfach nur neugierig

[Sigurd]

Tatsächlich macht es sehr wohl einen Unterschied aus, ob man den neuen Kernel in Verbindung mit APCI 3.23.06 nutzt oder nicht - zumindest auf dem, was ich bisher getestet habe.

Entgegen den Ankündigungen ist nicht nur "Mit bestimmten Einschränkungen" zu rechnen - sondern es ist kein SMP mehr möglich. Evtl. ist das ja auch gemeint?!

Hier mal ein Screenshot aus meiner virtuellen Maschine, Warp Server for e-Business 4.52 ACP 2 mit ACPI 3.23.06 und ohne Kernel 14.201:

Eine Warnung erscheint beim Booten und nur ein Prozessor wird initialisiert:

Die VM startet trotzdem. Als weiteren Hinweis hier die gestartete VM mit dem Schalter MAXCPU=2 in der config.sys, trotzdem nur ein Kernel. Mit dem Kernel 14.112 von Holger oder dem 14.103 von Fixpac 5 laufen normalerweise 2 Kernel in der VM äußerst stabil.

Eventuell haben da andere abweichende Erfahrungen? Ansonsten würde dies eine Limitierung für OS/2 bzw. eCS in Verbindung mit ACPI 3.23.06 und ohne Kernel 14.201 auf einen Kernel bedeuten, moderne Rechner wären dann ohnehin obsolet.

Natürlich kann man den Kernel 14.201 aus der extrahierten wpi entnehmen oder aus einem installierten und upgedateten ArcaOS 5.01 und dann in die eigene Installation einkopieren, dann läuft alles wieder normal. Deshalb auch mein Hinweis, dass es technisch wohl keine Gründe geben dürfte. Aber, das würde dann die Schutzrechte verletzen und das dürfen und wollen wir ja nicht....

Aktuell habe ich mir mal den OS/4 Kernel - dessen "Legalitätsstatus" nach meinem Wissen nie endgültig geklärt wurde - heruntergeladen, an dem ja tatsächlich noch gearbeitet wird....

[LotharS]

Mit dem Kernel 14.112 von Holger oder dem 14.103 von Fixpac 5 laufen normalerweise 2 Kernel in der VM äußerst stabil.

Da ich ja auch VBox benutze, und darin sowohl eine eCS2.1-VM (alter SMP-Kernel aus 2.2b) als auch eine AOS5.0-VM (Kernel 201), und inzwischen beide mit neuem ACPI-Treiber 3.23.06, ein wenig Feedback von hier. Beide VMs booten und arbeiten klaglos!! In beiden Fällen nehme ich schon immer nur eine virtuelle CPU, sonst lief's schlechter bis gar nicht. Nur meiner Linux-VM gönne ich zwei und tut prima.

Wenn ACPI nun die Kernel-Version anmeckert, hilft dann nachstehende Info aus der Readme.txt des Treibers weiter? Mag ja sein, dass der alte Treiber nicht so pingelig prüfte und trotzdem mit Deinen Kernel-Versionen tat, vom Entwickler etwa nicht explizit getestet und dokumentiert?
Dass Deine VM ja startet, deutet vermutlich auf eine unvollständige Doku hin?

This software will run with full functionality on the following kernels:
Arca Noae 14.201 SMP Retail
Arca Noae 14.104b SMP Debug

This software will run with limited functionality on the following kernels:
Arca Noae 14.200 SMP Retail
Arca Noae 14.104a SMP Debug
Arca Noae 14.200 W4 Retail
IBM 14.104a SMP Retail
IBM 14.105 SMP Retail
IBM 14.106 SMP Retail
IBM 14.104a W4 Retail
IBM 14.105 W4 Retail
IBM 14.106 W4 Retail

[erdmann]

solange das extra Treiberpaket weiter angeboten wird ist mir das egal. Bevor ich nämlich ArcaOS installiere und alles neu einrichte, nehme ich lieber eine bestehende Installation von OS/2 oder eCS und aktualisiere ein paar Treiber.

So mach ich es auch. Auf meinem ursprünglichen eCS 2.0 rc4 läuft bisher noch alles, trotz fehlender \ecs\ecs_inst.flg und jetzt \sys\install\install.flg. Bis ich vollständig auf das neu installierte System wechsel, das dauert noch. Bei der Installation lief viel zu viel schief, als dass ich das zu meinem Hauptsystem machen könnte.

Wirklich mehr ist in ArcaOS ja auch nicht passiert

Die Aktivität ist schon merklich angestiegen, nur leider fehlen die letzten beiden Jahre von eCS und die ersten beiden von ArcaOS. Da ist für die Nutzer nichts bei herausgekommen, verschenkte Jahre also. Mal sehen, ob das auch langfristig gesehn die Erkenntnis wird. Natürlich hoffen wir alle das Gegenteil. ArcaOS ist nun mal die einzige und letzte Möglichkeit.

Etwas mehr Open-Source-Gedanke würde dem Gesamtsystem wirklich gut tun. Die Verschlossenheit nervt mich schon ganz ordentlich. Die lässt sich sicherlich nicht nur mit sonst erhöhtem Supportaufwand begründen und auch nicht mit zuwenig Manpower. Mit Open Source Software könnten sich wenigstens versierte Nutzer die Quellen ansehen und sich dann selbst ein Bild vom Stand machen. Das ist so nicht mal im Ansatz möglich. Auch kann ich so nichts dazu beitragen, selbst bei Teilen, wo es möglich wäre. (Bei eCS wurde das für mich etwas offener gehandhabt, weil ich Übersatzer war.)

Mich nerven:

• verschlossene Repositories auf netlabs.org (z.B. USB, gabs auch schon zu eCS-Zeiten - warum soll ich mir als zahlender OS/2-Nutzer nicht die Quellen ansehen dürfen?),
• viel zu wenig Doku über die Änderungen in Davids Paketen (wortkarger gehts nicht),
• die geheim gehaltene Kernel- und Snap-Entwicklung,
• die geheim gehaltene Entwicklung des Installationsprogramms (warum nicht OSS?),
• fehlende Update-Möglichkeit bestehender Systeme.

Das Ergebnis ist bisher gut, wird aber auf Dauer nicht alle Mittel "heiligen". Leute, Ihr setzt haufenweise OSS ein, also öffnet Euch ein bischen mehr dafür. Es geht natürlich nur um die Erweiterungen und Verbesserungen, die nicht von IBM kommen. Jedenfalls wird es keinen Nachahmer geben, der Euren Firmenkunden das Produkt dann für die Hälfte verkauft.

Bzgl. Netlabs repos: USB ist deshalb nicht frei zugänglich weil es auf dem DDK source code von IBM basiert und der ist eben nicht frei (ich habe eine DDK Lizenz). Aber wegen Lesezugriff könnte man ja mal anfragen. AN hat allerdings seine Version schon längst ausgelagert. Davon wirst du also nichts mehr finden.

[ThomasOF]

Etwas mehr Open-Source-Gedanke würde dem Gesamtsystem wirklich gut tun. Die Verschlossenheit nervt mich schon ganz ordentlich. Die lässt sich sicherlich nicht nur mit sonst erhöhtem Supportaufwand begründen und auch nicht mit zuwenig Manpower. Mit Open Source Software könnten sich wenigstens versierte Nutzer die Quellen ansehen und sich dann selbst ein Bild vom Stand machen. ...

Es gibt ja das osFree-Projekt, leider noch in einem recht frühen Stadium, aber open source. Vielleicht wächst es ja weiter.

Thomas

[LotharS]

Es gibt ja das osFree-Projekt, leider noch in einem recht frühen Stadium, aber open source. Vielleicht wächst es ja weiter.

Ha, das hört sich ja ziemlich viel versprechend an. Hoffentlich macht da die Hardware-Fortentwicklung mal Pause...
Mit One- oder Few-Man-Shows mit geringem Budget wird man garantiert nicht mehr als bei Serenity, Mensys, ArcaNoae usf. erreichen können.
<offtopic>
Genauso vergleichbar dieser Quiz, dabei "Getriebe" einfach durch "Betriebssystem" ersetzen...
</offtopic>

[ak120]

Tatsächlich macht es sehr wohl einen Unterschied aus, ob man den neuen Kernel in Verbindung mit APCI 3.23.06 nutzt oder nicht - zumindest auf dem, was ich bisher getestet habe.

Entgegen den Ankündigungen ist nicht nur "Mit bestimmten Einschränkungen" zu rechnen - sondern es ist kein SMP mehr möglich. Evtl. ist das ja auch gemeint?!

Kann gut sein, aber ich würde es zur Sicherheit auf einem realen MP-System gegentesten, um eine Aussage zu treffen. Manchmal hilft es in der Konfiguration der VM auf einen Prozessor zurückzustellen und das System damit einmal hochzufahren und sauber zu beenden.

Hier mal ein Screenshot aus meiner virtuellen Maschine, Warp Server for e-Business 4.52 ACP 2 mit ACPI 3.23.06 und ohne Kernel 14.201:

Eine Warnung erscheint beim Booten und nur ein Prozessor wird initialisiert:

Die VM startet trotzdem. Als weiteren Hinweis hier die gestartete VM mit dem Schalter MAXCPU=2 in der config.sys, trotzdem nur ein Kernel. Mit dem Kernel 14.112 von Holger oder dem 14.103 von Fixpac 5 laufen normalerweise 2 Kernel in der VM äußerst stabil.

Eigentlich stellt sich die Frage, wozu überhaupt ACPI für ein OS/2 innerhalb einer VM benötigt wird. Alles was nicht direkt virtualisiert werden kann, erfordert dann oftmals aufwendigere Emulation - also würde ich es einfach weglassen. WSEB sollte mit minimaler Anpassung der Installationsdiskette 1 für den HBA (BTSCSI.ADD) problemlos in VirtualBox zu installieren sein. Die SMP-Unterstützung kann im Installationsprogramm ausgewählt werden oder ist bei mehr als einem Prozessor schon vorselektiert.

Eventuell haben da andere abweichende Erfahrungen? Ansonsten würde dies eine Limitierung für OS/2 bzw. eCS in Verbindung mit ACPI 3.23.06 und ohne Kernel 14.201 auf einen Kernel bedeuten, moderne Rechner wären dann ohnehin obsolet.

Ein Kernel ohne passende Gerätetreiber bringt nicht wirklich einen Nutzen für neuere Systeme.

[aschn]

Bzgl. Netlabs repos: USB ist deshalb nicht frei zugänglich weil es auf dem DDK source code von IBM basiert und der ist eben nicht frei (ich habe eine DDK Lizenz).

Schon klar.

Aber wegen Lesezugriff könnte man ja mal anfragen.

Das würde dann doch genauso dagegen verstoßen.

Da fällt mir ein: Lars, wie handhabst Du das eigentlich mit der Integration von OSS-Code in die USB-Treiber? Oder gibt's das Problem bisher nicht?

AN hat allerdings seine Version schon längst ausgelagert. Davon wirst du also nichts mehr finden.

Das war schon bei eCS so und hat mich fast noch mehr gestört. (Bei eCS gab's das Entwickler-Repository. Bei ArcaOS ist leider noch mehr geheim.) Ich meine Quellcode, der eigentlich offen sein könnte, es aber nicht ist.

[Sigurd]

Tatsächlich macht es sehr wohl einen Unterschied aus, ob man den neuen Kernel in Verbindung mit APCI 3.23.06 nutzt oder nicht - zumindest auf dem, was ich bisher getestet habe.

Entgegen den Ankündigungen ist nicht nur "Mit bestimmten Einschränkungen" zu rechnen - sondern es ist kein SMP mehr möglich. Evtl. ist das ja auch gemeint?!

Kann gut sein, aber ich würde es zur Sicherheit auf einem realen MP-System gegentesten, um eine Aussage zu treffen. Manchmal hilft es in der Konfiguration der VM auf einen Prozessor zurückzustellen und das System damit einmal hochzufahren und sauber zu beenden.

Hier mal ein Screenshot aus meiner virtuellen Maschine, Warp Server for e-Business 4.52 ACP 2 mit ACPI 3.23.06 und ohne Kernel 14.201:

Eine Warnung erscheint beim Booten und nur ein Prozessor wird initialisiert:

Die VM startet trotzdem. Als weiteren Hinweis hier die gestartete VM mit dem Schalter MAXCPU=2 in der config.sys, trotzdem nur ein Kernel. Mit dem Kernel 14.112 von Holger oder dem 14.103 von Fixpac 5 laufen normalerweise 2 Kernel in der VM äußerst stabil.

Eigentlich stellt sich die Frage, wozu überhaupt ACPI für ein OS/2 innerhalb einer VM benötigt wird. Alles was nicht direkt virtualisiert werden kann, erfordert dann oftmals aufwendigere Emulation - also würde ich es einfach weglassen. WSEB sollte mit minimaler Anpassung der Installationsdiskette 1 für den HBA (BTSCSI.ADD) problemlos in VirtualBox zu installieren sein. Die SMP-Unterstützung kann im Installationsprogramm ausgewählt werden oder ist bei mehr als einem Prozessor schon vorselektiert.

Eventuell haben da andere abweichende Erfahrungen? Ansonsten würde dies eine Limitierung für OS/2 bzw. eCS in Verbindung mit ACPI 3.23.06 und ohne Kernel 14.201 auf einen Kernel bedeuten, moderne Rechner wären dann ohnehin obsolet.

Ein Kernel ohne passende Gerätetreiber bringt nicht wirklich einen Nutzen für neuere Systeme.

Ich glaube, dass alle hier getroffenen Aussagen richtig sind, darf als letztes ergänzen, dass ACPI zumindest in meiner VM dafür gesorgt hat, dass sich die Wärmeentwicklung im SMP Betrieb drastisch verringert bzw. geendet hat. Damit beschließe ich das Thema für mich. Vielen Dank für die vielen Anregungen und Hinweise!