OS2.org Forum

DonLucio hat geschrieben: Di 23. Jan 2024, 17:42Da war es für mich (und ein paar Unternehmen, die auch heute noch voller Verzweifelung AOS einsetzen) aber schon zu spät. Ich saß vor einem Haufen OS/2-spezifischen Codes, der mit nichts anderem auf der Welt kompatibel war.

ja kenne ich.

Als absehbar war, schon vor sehr, sehr vielen Jahren, dass OS/2 eine Sackgasse ist, habe ich angefangen Scripte, die mir wichtig waren nach Bash oder Python zu migrieren. Allerdings war das meiste gar nicht mehr notwendig, weil es unter MacOS X und Linux bessere Lösungen gab. Doof halt, wenn man damit nicht frühzeitig angefangen hat und auf eine "bessere" Zukunft gehofft hat.

Es gab nur die eine Option, damals, als die Situation noch nicht soooo aussichtslos war: "Keep on truckin'", weitermachen, solange es geht, immer in der Hoffnung, dass es schon irgendwie weitergehen wird.

Diese Hoffnung ist bei mir mit dem Knorz den Mensys damals mit der eCS 2.x rausgebracht hat, endgültig gestorben.

Und bisher ist diese Hoffnung ja auch immer irgendwie erfüllt worden
(obgleich ich zugeben muß, dass der Wegfall von FTP bei meinem Provider schon ein harter Schlag für mich ist, für den ich bisher noch keine Lösung habe).

Nach wie vor mein Rat:
Auf ssh bzw. scp umstellen, gab' es (jedenfalls damals) auch für OS/2, ich habe damit viele Jahre intensiv gearbeitet!

Hi
irgendwie fällt mir beim lesen der spruch.. wer zu spät kommt.......

für mich war 2012, als es immer problematischer wurde mit FF smooth zu arbeiten, und viel sachen nur durch stäniges frickeln am laufen zu halten waren.

hatte mich bis dato ab und zu schon mit linux beschäftigt, aber nie wirklich den absprung gefunden.
nach test von linux mint habe ich einen zweiten rechner damit aufgesetzt und innhalb von 2-3 monaten meinen kompletten work-flow auf linux darstellen können.
habe den schritt nie bereut.. man muss ihn nur machen
win$ war nie eine option.

ehtron hat geschrieben: Mi 24. Jan 2024, 15:55irgendwie fällt mir beim lesen der spruch.. wer zu spät kommt.......

ja, stimmt irgendwie ...

für mich war 2012, als es immer problematischer wurde mit FF smooth zu arbeiten, und viel sachen nur durch stäniges frickeln am laufen zu halten waren.

Ja, Firefox war auch eine der für mich extrem wichtigen Anwendungen, ohne die ich nicht arbeiten konnte, dazu kam MoneyPlex, mit dem Online-Banking irgendwann nicht mehr ging - das war dann das "Ende", könnte so 2006/2007 gewesen sein.

Ich weiß gar nicht mehr, wann ich selbst mit OS/2 aufgehört habe "zu arbeiten", im Büro hatte ich noch lange Zeit einen OS/2-Laptop (ThinkPad T42) mit FF, ZOC, ssh und telnet um Router und Switches zu konfigurieren, dürfte aber auch schon an die 10 Jahre her sein.
Mein letztes OS/2-Projekt hatte in 2019 final abgeschlossen.

So gesehen, alles gut, unter Linux ist es "besser" und die Nutzung von MacOS X auf ThinkPads hat sich die letzten Jahre auch bewährt, findet nun aber auch so langsam seinen "Abschluss"

thorolf hat geschrieben: So 21. Jan 2024, 22:45

Alexco hat geschrieben: So 21. Jan 2024, 22:27 Ich will ja nicht virtualisieren, sondern emulieren. Und ich hatte gedacht, dass die Emulation von Qemu bzgl. i386 etwas kompatibler ist.

wenn sich schon manche echte Virtualisierer auf Intel/AMD daran die Zähne ausbeissen, was erwartest Du dann von QEMU auf ARM?

OS/2 nutzt praktisch als einziges Betriebssystem so ziemlich alles, was die i386-Architektur zu bieten hatte. Nicht umsonst hat AMD OS/2 lange Zeit als "Kompatibilitätstest" für ihre Prozessoren genutzt. Lief OS/2 fehlerfrei, waren die CPUs kompatibel.

Ich habe mich damit weiter beschäftigt und wollte diese Aussage kurz korrigieren. Da beißt sich niemand die Zähne aus, das geht sogar sehr gut. Allerdings gibt es seit 2018 einen gemeldeten Fehler bei QEMU, der das Starten von Warp 4 ab einem gewissen Fixpack Level verhindert. Was sich dann natürlich auch auf eCS & Co auswirkt. Ein Warp 3 Connect läuft hingegen ohne Probleme.
Mehr Spaß hatte ich allerdings mit dem x86Box Emulator, mit dem ich ohne Probleme 2.11, Warp 3 und Warp 4 installieren konnte.
Und da fällt mir dann auf, wie limitiert das OS im Vergleich zu heute ist und was ich alles nicht mehr weiß , jetzt habe z.B. ein Warp 3 mit allen Fixes, inkl. MPTS, bekomme aber das TCPIP Gedöns nicht gefixt.

thorolf hat geschrieben: So 21. Jan 2024, 22:45

Alexco hat geschrieben: So 21. Jan 2024, 22:27 Wenn ich auf dem M1 virtualisiere, dann andere macOS Versionen, Windows/ARM oder Linux. Und das geht schön schnell.

Nur schränkt das "geringfügig" ein, für Windows/ARM gibt's nämlich nur einen Bruchteil an Software, als es für x86 gibt und "andere macOS Versionen" gilt dann auch nur für solche, die für den M-ARM erschienen sind und natürlich gibt's auch Probleme mit allen anderen Systemen die es nur für x86 gibt.

Ob das (für Dich) relevant ist, steht auf einem anderen Blatt - für mich ist dass nur ein weitere Grund keinen Apple zu kaufen.

Das schöne ist ja, dass Windows ARM ja auch die x86 Software ausführen kann. Für meine Zwecke reichts. Und nein, da gibt es keine Probleme, ich habe mittels QEMU schon so einiges hinbekommen, MacOS X auf PPC, Intel, openSUSE Intel und ARM, Debian Intel und ARM, soweit alles kein Problem. Natürlich ist x86 auf ARM immer langsam.
Aber ich gehe so schnell beim Laptop nicht mehr zu Intel zurück, die heißen Brötchen können sich andere auf die Oberschenkel stellen....

Alexco hat geschrieben: So 4. Feb 2024, 14:39Ich habe mich damit weiter beschäftigt und wollte diese Aussage kurz korrigieren.

na das ist doch dann in Ordnung, mein Kenntnisstand war immer, dass es mit OS/2 und QEMU nicht geht und vor MCP 4.5 habe ich das auch nie ausprobiert. Aber wenn Du schreibst, dass es bei Warp 4 ab einem bestimmten Fixlevel nicht mehr ging, kommt's ja auf's gleiche raus, irgendwo hat IBM seinerzeit was optimiert, womit QEMU nicht mehr klar kam und es offenbar auch niemanden mehr interessiert hat.

Den x86Box Emulator kenne ich nicht, hab nie was damit gemacht ...

Das schöne ist ja, dass Windows ARM ja auch die x86 Software ausführen kann. Für meine Zwecke reichts.

dann ist ja gut, was man so liest, scheint das zum Arbeiten aber nur bedingt geeignet zu sein, selbst auf hochpreisigen Windows-ARM-Laptops.

Aber ich gehe so schnell beim Laptop nicht mehr zu Intel zurück, die heißen Brötchen können sich andere auf die Oberschenkel stellen....

Heizkacheln bauen die "großen" Windows-Notebook-Hersteller schon lange nicht mehr, allenfalls muss der Lüfter ein bisschen mehr drehen.

Und leistungsmäßig sind die von Apple in einigen Bereichen vor allem deshalb besser, weil alles bestmöglich aufeinander abgestimmt ist und es viele Einschränkungen gibt. Apple hat vom Chip bis zu den Applikationen alles unter seiner Kontrolle, da kann man sehr viel besser optimieren - allerdings muss man sich dafür auch in Apple goldenen Käfig begeben, darauf kann ich dankend verzichten.

thorolf hat geschrieben: So 4. Feb 2024, 18:51

Alexco hat geschrieben: So 4. Feb 2024, 14:39Ich habe mich damit weiter beschäftigt und wollte diese Aussage kurz korrigieren.

na das ist doch dann in Ordnung, mein Kenntnisstand war immer, dass es mit OS/2 und QEMU nicht geht und vor MCP 4.5 habe ich das auch nie ausprobiert. Aber wenn Du schreibst, dass es bei Warp 4 ab einem bestimmten Fixlevel nicht mehr ging, kommt's ja auf's gleiche raus, irgendwo hat IBM seinerzeit was optimiert, womit QEMU nicht mehr klar kam und es offenbar auch niemanden mehr interessiert hat.

Ich hoffe, Ihr hattet alle ruhige und entspannte Weihnachten. Ich habe mich mal wieder mit Qemu beschäftigt, bzw. mit den UTM unter macOS. Die aktuelle Version 4.6.4 nutzt intern dann auch Qemu 9.1.2 und damit läuft dann auch ArcaOS ohne Probleme: Es scheint also zu sein, als hätte jemand bei Qemu was gefixt

Intel hat das Experiment mit x86-s gestoppt. Die haben im Moment ganz andere Probleme als diesen riesigen Umstieg. AMD sie hat mächtig unter Druck gesetzt, kaum jemand kauft noch Intel, wenn er die Wahl hat (selbst gebaute Rechner sind zu 90 % AMD). Außerdem hält Intel stur an ihrer eigenen, veralteten und nicht mehr finanzierbaren Fertigung fest, während AMD mit dem Weltmarktführer TSMC arbeitet und sich die Kosten mit anderen Kunden "teilt".

Kurzum: x86-s ist tot

ArcaOSNewcomer hat geschrieben: So 29. Dez 2024, 15:13 Intel hat das Experiment mit x86-s gestoppt. Die haben im Moment ganz andere Probleme als diesen riesigen Umstieg. AMD sie hat mächtig unter Druck gesetzt, kaum jemand kauft noch Intel, wenn er die Wahl hat (selbst gebaute Rechner sind zu 90 % AMD). Außerdem hält Intel stur an ihrer eigenen, veralteten und nicht mehr finanzierbaren Fertigung fest, während AMD mit dem Weltmarktführer TSMC arbeitet und sich die Kosten mit anderen Kunden "teilt".

naja, AMD dürfte nicht das größte Problem für Intel sein, eher nach wie vor Nadelstiche, wenngleich tiefer, da Intel nicht mehr monopolartige Preise für die größten und schnellsten CPUs aufrufen kann um sich so gesundzustoßen.

In den meisten (Business-)PCs laufen nach wie vor Intel-CPUs, inzwischen hinken die aktuellen Prozessoren denen von AMD auch nicht mehr meilenweit hinterher. Allerdings hat AMD im Servermarkt viel Boden gut gemacht und hat dort meines Wissens inzwischen einen Marktanteil von über 30%.

Probleme hat Intel, weil sie seit Jahren falsch geplant haben, ihre Fertigungstechnik lange nicht in den Griff bekommen haben, im KI-Bereich nichts wirklich brauchbares haben und jetzt auch noch Windows-Laptops mit ARM-Technik den margenstarken Markt mit teureren Laptops mit beackern.

Deshalb müssen sie sparen, keine milliarden-schwere Chipfabrik in Deutschland, deren Nutzen ob der massiven Subventionen sowieso mehr als zweifelhaft gewesen wäre und eben auch kein x86-s, der einen vereinfachten, reinen 64-bit Mode Befehlssatz mitbringen sollte und die uralten 32-bit x86-Zöpfe abschneiden sollte. Kann man sich auch fragen wozu das überhaupt, v.a. weil man dadurch die lange gepriesene Kompatibilität zu früheren Systemen aufgegeben hätte.

Im übrigen sind die aktuellen Intel-CPUs nicht mehr monolitisch, sondern auch aus Einzel-Chips zusammen gesetzt und zum anderen stellt TSMC aktuell den wesentlichen Teil der neusten Intel-CPUs her, von Intel kommt nur noch das Teil, welches alle anderen Einzel-Chips miteinander verbindet. Selbst die CPU-Kerne selbst kommen aktuell von TSMC.

Aber klar ist, das Intel das wieder zurück holen möchte, sobald die eigene Technik das wieder hergibt, verspricht das doch höhere Gewinnmargen.

Und ziemlich dämlich war es auch, Pat Gelsinger nach zwei Jahren abzusägen, weil er es in dieser Zeit nicht geschafft hat, den Bockmist, den seine Vorgänger in den Jahrzehnten davor gebaut haben, wieder gerade zu ziehen. Es ist vermessen zu glauben, dass man das in solch kurzer Zeit umkehren kann, auch das braucht 10 Jahre oder mehr.

AMD ist definitiv Intels Problem, denn ohne AMD würde Intel uns wohl heute noch mit ihrem angeblich verbesserten, aber uralten 14 nm ++++ Prozess und 4 Kernen verarschen (verzeiht, wenn ich das so "unverblümt" sage, aber wir haben 2017 und danach ja mehr als deutlich gesehen, was technisch alles möglich ist, wenn man will).

Es ist das Zusammenspiel aus der führenden Fertigung von TSMC (die erst durch AMD zum Anwender kommt) und fortschrittlicherem CPU-Design. Dass Intel jetzt ultimativ spät doch noch auf TSMC zurückgreift und seine eigene Fertigung nicht auslasten kann, ist ein Notnagel und ein Armutszeugnis.
AMD wird nur durch seine eigenen Kapazitäten gebremst, sonst hätten sie deutlich mehr Marktanteil (die Notebook-Hersteller können dir das bestätigen ).

An ARM als Haupt-Problem glaube ich nicht, da will ich erst mal überzeugende Zahlen sehen. Da reicht ja eine einzige Software (in Worten: eine), die es nicht für ARM gibt, um für Ärger im Unternehmen zu sorgen. Auch wenn wir das mal beiseite lassen, hätten Firmen dann plötzlich zwei verschiedene CPU-Architekturen, mit ihren eigenen Problemen und doppeltem (Test-) Aufwand (Beispiel: mit x86 läuft alles, mit ARM gibt es Abstürze). Solche Probleme holt man sich ja nicht freiwillig ins Haus, um auf den neuesten Hype aufzusteigen, oder eine sehr gute (im Alltag völlig problemlose) Akkulaufzeit auf "noch besser" zu steigern. In Büros und Arbeitszimmern gibt es überall Steckdosen.