Discussion:
100 Jahre IBM
(zu alt für eine Antwort)
Andreas Kohlbach
2024-02-14 05:45:58 UTC
Permalink
Heute vor 100 Jahren bekam IBM seinen Namen.
--
Andreas
F. W.
2024-02-14 06:42:02 UTC
Permalink
Post by Andreas Kohlbach
Heute vor 100 Jahren bekam IBM seinen Namen.
Heute vor 100 Jahren bekam DEHOMAG den Namen IBM. Die DEutsche HOllerith
MAschinen Gesellschaft). Es war Hermann Hollerith, der den Weg ebnete.
Die amerikanischste Firma der Erde hat deutsche Wurzeln.

Und es war ein Vorgang, der den Datenschutz begründete, für den die
DEHOMAG gegründet wurde: die Volkszählung (mit Lochkarten).

(Soviel Klugschiss muss sein :-D )

Herzlichen Glückwunsch an die vermutlich bedeutendste Computerfirma der
Welt, für die ich ein paar Jahre arbeiten durfte.

Viele Techniken, Methoden, Programme, Ideen, Techniken, die wir heute
ganz selbstverständlich benutzen, stammen aus dieser Firma (auch wenn
Microsoft und Apple heute gern ihre Schilder überall drauf kleben).

FW
p***@pocnet.net
2024-02-14 08:12:32 UTC
Permalink
Post by F. W.
Viele Techniken, Methoden, Programme, Ideen, Techniken, die wir heute
ganz selbstverständlich benutzen, stammen aus dieser Firma (auch wenn
Microsoft und Apple heute gern ihre Schilder überall drauf kleben).
Ja, das ist ein Punkt, der gerne mal unter den Tisch gekehrt wird. Ich mag IBM
als Firma nicht sonderlich. Genau genommen mag ich überhaupt keine Firma als
"Getriebe um Geld in Shareholder-Popos zu stopfen", aber das ist eine andere
Geschichte.

IBM als Sammelbecken von kreativen und fähigen Leuten, die Dinge ersonnen
haben *trotz* dem behördenähnlichen Inneren zolle ich Respekt.
--
:wq! PoC
F. W.
2024-02-14 09:48:27 UTC
Permalink
Post by p***@pocnet.net
IBM als Sammelbecken von kreativen und fähigen Leuten, die Dinge
ersonnen haben *trotz* dem behördenähnlichen Inneren zolle ich
Respekt.
Hier muss natürlich OS/2 etwas Wasser in den Wein gießen. Ich war damals
bei der IBM und wir hatten OS/2 auf dem Rechner. Wenig später erlaubte
die IBM allerdings, das Betriebssystem frei zu wählen und wenig später
flackerte Windows (3.11) wieder auf den Bildschirmen.

Ich war OS/2-Entwickler und musste OS/2 behalten. Erst als Strafe
wahrgenommen, installierte ich später auch auf meinem privaten PC OS/2.
Grund war die bessere aktualisierte Version und der 3.11-Modus, der auf
meinem privaten Rechner sehr gut lief. Und eben Borland-Pascal für OS/2
vorhanden war.

Ich war tatsächlich einer der wenigen, die um OS/2 getrauert haben. Kurz
vor dem absoluten Ende kaufte ich im Ramschladen noch "Warp" und nutzte
es, bis es keine Updates mehr gab, da ich damals schon Homebanking
machte und auf Sicherheit angewiesen war.

In einer Konferenz mit den Amerikanern sollten Ursachen ausgelotet
werden. Die herrschende Meinung war damals, dass IBM einfach nicht mit
Endkunden-Marketing Erfahrung hatte. Privatkunden funktionieren komplett
anders als Firmenkunden.

Du kaufst einen PC und siehst Windows. Das war der größte Deal seit der
Mensch die Höhle verlassen hat. Denn die meisten Menschen des Planeten
kennen anschließend nur Windows.

Und lernen ist eben auch Arbeit. ;-)

Und - nebenbei - hätte Apple IOS "freigegeben" wie weiland den Apple ][,
vielleicht hätten wir alle IOS auf den Handys. Man kann den Einfall der
Microsoft-Verkäufer gar nicht hoch genug einschätzen.

FW
p***@pocnet.net
2024-02-14 10:29:27 UTC
Permalink
Post by F. W.
In einer Konferenz mit den Amerikanern sollten Ursachen ausgelotet
werden. Die herrschende Meinung war damals, dass IBM einfach nicht mit
Endkunden-Marketing Erfahrung hatte. Privatkunden funktionieren komplett
anders als Firmenkunden.
Da ist was dran.
Post by F. W.
Du kaufst einen PC und siehst Windows. Das war der größte Deal seit der
Mensch die Höhle verlassen hat. Denn die meisten Menschen des Planeten
kennen anschließend nur Windows.
Traurig aber wahr, ja.
Post by F. W.
Und - nebenbei - hätte Apple IOS "freigegeben" wie weiland den Apple ][,
vielleicht hätten wir alle IOS auf den Handys.
iOS. IOS ist von Cisco. ;-)

(Und i5/OS von IBM, bevor sie es in IBM i umbenannt haben.)
--
:wq! PoC
Hermann Riemann
2024-02-14 12:22:02 UTC
Permalink
Post by F. W.
Ich war OS/2-Entwickler und musste OS/2 behalten. Erst als Strafe
wahrgenommen, installierte ich später auch auf meinem privaten PC OS/2.
Grund war die bessere aktualisierte Version und der 3.11-Modus, der auf
meinem privaten Rechner sehr gut lief. Und eben Borland-Pascal für OS/2
vorhanden war.
Ich hatte damals OS/2, weil ich PC mit 32 bit +
C++ von Borland haben wollte.

Mein erster Installationsversuch ist,
im Gegensatz zu DOS und Linux, gescheitert.
Statt Festplatte hatte ich Wechselplatte.
Der erste Rat der IBM help line , gleiche Speicherriegel
zu verwenden, hat nicht geholfen.
Dann bekam ich die Anleitung,
wie ich die IBM Plattenverwaltung deaktiviere,
um sie durch BIOS Zugriff zu ersetzen.
Damit ging es dann.

Einer der Testprogramme war, etwa wie viel Speicher
bekomme ich mit malloc.
Also Schleife aus malloc und free mit jeweils doppelter Länge.
Im Gegensatz zu windows95 und Linux
stürzte das Programm unter OS/2 ab.
Mit späteren updates funktionierte das Programm,
wobei ich immer nur halb soviel Speicher bekam wie unter
windows und Linux.
Ganz später musste ich wegen OS/2 Speicherverwaltung
ins BIOS eingreifen.

Immerhin der MS Flugsimulator für DOS
funktionierte unter OS/2 im Gegensatz zu windows 95.

Ich dachte, man könne während einer C++ Installation
( 3 Disketten ) schon mal editieren.
Dann tippte zwecks Zeilenwechsel RETURN
was aber vom Button "Diskette eingelegt" abgefangen wurde.

Nachdem die Unterschiede C++ Borland und OS/2 mir zu groß vorkamen,
versuchte ich das C++ von IBM.
Also if eingetippt und schon erschien so etwas wie if(){}else{}
was mich erst mal zu weg editieren brachte.
Dann versuchte ich IBM GUI IDE.
Die haben Texte generiert.
Ich habe da eigenen code eingefügt und wollte die GUI erweitern.
Das hatte zur Folge, das meine Texte überschrieben wurden.

( Danach versuchte ich Visual C++ von windows,
welches an hello world im flat modus gescheitert ist.
Danach Rückkehr zu C unter Linux. )

Hermann
sich auch noch an eine Werbe CD von IBM erinnernd,
mit halb so großem Radius, dafür aber Sägezahn Rand.
--
<http://www.hermann-riemann.de>
Marcel Mueller
2024-02-29 06:52:30 UTC
Permalink
Post by Hermann Riemann
Mein erster Installationsversuch ist,
im Gegensatz zu DOS und Linux, gescheitert.
Statt Festplatte hatte ich Wechselplatte.
Der erste Rat der IBM help line , gleiche Speicherriegel
zu verwenden, hat nicht geholfen.
Dann bekam ich die Anleitung,
 wie ich die IBM Plattenverwaltung deaktiviere,
um sie durch BIOS Zugriff zu ersetzen.
Damit ging es dann.
Den I13-Treiber wollte man aber nicht haben. Der war so lahm wie unter
Windows. Der IBM1S506 war aber manchmal zickig. Man musste passende,
unterstützte Hardware kaufen. IBM wollte halt lieber Microchannel (die
IBM2...-Treiber) verkaufen, als sich um die generischen Kernel-Treiber
kümmern, seit ihnen der IBM-PC Standard entglitten war.
Das wurde erst besser, als Dani (später) den alternativen DANIS506
entwickelte, der dann (noch später) auch in eComStation drin war.

Aber "Installation" war bei IBM schon immer eine Katastrophe. Wenn die
Kisten einmal liefen, dann dafür sehr sehr lange.
Ist wohl heute noch so. 3 Tage geplanter Aufwand für die
(verpflichtende) Installation eines IBM Lizenzservers - WTF?

Ich glaube das OS/2 2.11 von damals läuft hier immer noch irgendwo in
einer VM. Zwischendurch ein paar Hardwarewechsel, der letzte zu VM, und
ein paar Upgrades des OS über Warp 3 Connect, Warp 4 zu eCS1. Ich habe
die Kiste AFAIR nie wirklich neu aufgesetzt. Eine >30 Jahre alte
Windows-Installation, die nach so vielen Upgrades noch läuft gibt es
wohl kaum.
Post by Hermann Riemann
Einer der Testprogramme war, etwa wie viel Speicher
bekomme ich mit malloc.
Also Schleife aus malloc und free mit jeweils doppelter Länge.
Im Gegensatz zu windows95 und Linux
stürzte das Programm unter OS/2 ab.
Das dürfte aber eher auf die Rechnung von Borland gehen. Ich kenne keine
Compiler mit mehr Bugs als Borland C++ Compiler.
Post by Hermann Riemann
Mit späteren updates funktionierte das Programm,
wobei ich immer nur halb soviel Speicher bekam wie unter
windows und Linux.
Ganz später musste ich wegen OS/2 Speicherverwaltung
ins BIOS eingreifen.
Ja, es gab mal ein 16 MB-Limit im BIOS, was üblicherweise aktiv war,
weil DOS/Windows bei mehr beim Start abgestürzt sind. Windows hat dann
eine zusätzliche BIOS-Funktion bekommen, um den tatsächlichen Speicher
abzufragen, ohne dabei abzustürzen. OS/2 nutzte aber immer die alte
Funktion. Daher die BIOS Option "OS/2" vs. "Non OS/2", letztere
deaktiviert das 16 MB Limit.
Post by Hermann Riemann
Immerhin der MS Flugsimulator für DOS
funktionierte unter OS/2 im Gegensatz zu windows 95.
Die meisten DOS Spiele liefen unter OS/2.

Selbst heute kann es noch eine gute Wahl sein, statt einer direkten
Emulation für DOS, eine OS/2 VM dazwischen zu hängen. Der modifizierte
DOS-Kernel von OS/2 geht wesentlich schonender mit den CPU-Ressourcen
um, so dass nicht bei jedem DOS Programm ein CPU-Kern auf 100% Last föhnt.

Allerdings gehört die Emulation der VGA-Hardware für DOS Fullscreen bei
den Virtualisierern nicht mehr zu den gut getesteten Funktionen. Da kann
es notwendig werden, das Spiel im DOS-Fenster von OS/2 laufen zu lassen,
so dass OS/2 die Emulation übernimmt. Das geht aber nicht mit Spielen,
die direkt auf die VGA-Register gehen.
Post by Hermann Riemann
Ich dachte, man könne während einer C++ Installation
( 3 Disketten ) schon mal editieren.
Dann tippte zwecks Zeilenwechsel RETURN
was aber vom Button "Diskette eingelegt" abgefangen wurde.
Asynchrone Fokuswechsel sind auch heute noch eine Pest. Im Prinzip
Clickjacking.
Dazu gab es mal einen schönen Comic. Auf dem Bildschirm ein Dialog
"Atomsprengköpfe zünden? Ja / Nein" während die Putzfrau mit der Bürste
die Tastatur reinigte. ;-)
Post by Hermann Riemann
Nachdem die Unterschiede C++ Borland und OS/2 mir zu groß vorkamen,
versuchte ich das C++ von IBM.
Also if eingetippt und schon erschien so etwas wie if(){}else{}
was mich erst mal zu weg editieren brachte.
Dann versuchte ich IBM GUI IDE.
Die haben Texte generiert.
Ich habe da eigenen code eingefügt und wollte die GUI erweitern.
Das hatte zur Folge, das meine Texte überschrieben wurden.
Ja "Visuelle Editoren" sind heute noch hip - und ebenso nutzlos wie
damals. Muss mich immer mal beruflich mit einem herumschlagen (Designer
von einem OR-Mapper).

Der C++ Compiler von IBMVAC 3 war allerdings seiner Zeit fast 10 Jahre
voraus. Der konnte schon vieles, was andere erst viel später gelernt haben.
Die UI, nun ja, die musste man mögen, oder halt auch nicht. ;-)
Aber man konnte den Compiler auch mit anderen UIs nutzen. Nur der
Debugger muss halt zum Compiler passen. Und icsdebug, nun ja, der spröde
Charme der 80-er scheint noch durch.
Wobei, gdb will auch keiner mit Hand bedienen. Die Integration in einige
IDEs wie Eclipse CDT ist aber mittlerweile schon sehr geglückt.
Post by Hermann Riemann
( Danach  versuchte ich Visual C++ von windows,
  welches an hello world im flat modus gescheitert ist.
  Danach Rückkehr zu C unter Linux. )
MSVC war nie sonderlich gut. Aber zumindest hatten sie weniger Bugs als
Borland.


Marcel
Alexander Goetzenstein
2024-02-29 08:16:40 UTC
Permalink
Hallo,
Post by Marcel Mueller
Die meisten DOS Spiele liefen unter OS/2.
nicht nur das: in den 90ern habe ich an einem CAD-Arbeitsplatz AutoCAD
für DOS unter OS/2 genutzt. Das lief deutlich schneller, geschmeidiger
und problemloser nicht als unter DOS, sondern auch als unter Windows.
--
Gruß
Alex
Joerg Walther
2024-02-14 14:48:55 UTC
Permalink
Post by F. W.
Kurz
vor dem absoluten Ende kaufte ich im Ramschladen noch "Warp"
Das gab es quasi kostenlos auf irgendeiner Heft-CD. Ich habe das einige
Jahre sehr gern genutzt, weil es um mehrere Faktoren stabiler lief als
jedes Windows bis Windows NT/2000.

-jw-
--
And now for something completely different...
Kay Martinen
2024-02-14 17:02:55 UTC
Permalink
Post by Joerg Walther
Post by F. W.
Kurz
vor dem absoluten Ende kaufte ich im Ramschladen noch "Warp"
Das gab es quasi kostenlos auf irgendeiner Heft-CD. Ich habe das einige
Ich meine das wäre eine C't Heftbeilage gewesen, aber nur eine Zeitlich
limitierte Testversion - die man allerdings durch einen einfachen Kniff
austricksen konnte (irgendwas mit Tastaturtreiber wechseln).

Später gab's dann Warp von Tewi als Booklet für wenig Geld.

AFAIR gab es kurz davor noch diese unsäglich "Hipster" Werbung im TV -
die sich auch auf der C't CD wiederfand.
Post by Joerg Walther
Jahre sehr gern genutzt, weil es um mehrere Faktoren stabiler lief als
jedes Windows bis Windows NT/2000.
Sah hier auch so aus. Und wenn man noch Alte HW hat auf der es
spielt.... welche Schadsoftware gibt es heute die unter OS/2 unheil
anrichten könnte? Java-würmer vielleicht? ;-)

Bye/
/Kay
--
nix
Michael Noe
2024-02-14 17:42:24 UTC
Permalink
Post by F. W.
Und - nebenbei - hätte Apple IOS "freigegeben" wie weiland den Apple ][,
Der einzige legale Apple-II-Clone war AFAIK der Laser 128 von VTech,
welcher erst 1986 erschien.

Compaq ging bei ihrem ersten IBM-PC-Clone, dem Compaq Portable, welcher
1983 erschien, nach Columbia Data Products samt Clean Room
Design/Reverse Engineering recht ähnlich vor - illegale und sehr oft
nicht immer wirklich "kompatible" Nachbauten vor allem aus Taiwan gab es
natürlich schon vorher. Der Dokumentarfilm Silicon Cowboys gibt da recht
gute Einblicke. Obwohl mich IBM-PCs (oder gar deren Clones) samt PC-DOS
und später Windows eigentlich so gar nicht interessieren, fand ich den
Film durchaus interessant.

Trailer:


(Natürlich hat IBM damals massiv versucht, rechtlich gegenüber Compaq
vorzugehen.)
Post by F. W.
vielleicht hätten wir alle IOS auf den Handys.
iOS.
--
Gruß

Michael
Joerg Walther
2024-02-14 17:53:01 UTC
Permalink
Post by Michael Noe
Der Dokumentarfilm Silicon Cowboys gibt da recht
gute Einblicke. Obwohl mich IBM-PCs (oder gar deren Clones) samt PC-DOS
und später Windows eigentlich so gar nicht interessieren, fand ich den
Film durchaus interessant.
http://youtu.be/7wjJYqUkHd8
Den kannte ich noch nicht, danke für den Tipp, habe ihn gerade
heruntergeladen. :)

-jw-
--
And now for something completely different...
Andreas Kohlbach
2024-02-14 23:56:50 UTC
Permalink
Post by F. W.
Ich war tatsächlich einer der wenigen, die um OS/2 getrauert haben. Kurz
vor dem absoluten Ende kaufte ich im Ramschladen noch "Warp" und nutzte
es, bis es keine Updates mehr gab, da ich damals schon Homebanking
machte und auf Sicherheit angewiesen war.
War das 1996 oder 1997, und der Ramschladen ESCOM oder Vobis?

Denn genau dann nahm auch ich eines der weißen Pakete nebenher mit. Ich
kam eigentlich in den Laden, um Cache Bausteine zu kaufen, die gerade im
Angebot waren. OS/2 (IIRC Warp 3) Kisten waren dort auf dem Boden
aufgetürmt, und zu je (IIRC) 25 DM zu haben.
--
Andreas
F. W.
2024-02-15 07:39:59 UTC
Permalink
Post by Andreas Kohlbach
Post by F. W.
Ich war tatsächlich einer der wenigen, die um OS/2 getrauert haben.
Kurz vor dem absoluten Ende kaufte ich im Ramschladen noch "Warp"
und nutzte es, bis es keine Updates mehr gab, da ich damals schon
Homebanking machte und auf Sicherheit angewiesen war.
War das 1996 oder 1997, und der Ramschladen ESCOM oder Vobis?
Nein, das war nach dem Ende meiner IBM-Zeit, muss also früher gewesen sein.
Post by Andreas Kohlbach
Denn genau dann nahm auch ich eines der weißen Pakete nebenher mit.
Ich kam eigentlich in den Laden, um Cache Bausteine zu kaufen, die
gerade im Angebot waren. OS/2 (IIRC Warp 3) Kisten waren dort auf dem
Boden aufgetürmt, und zu je (IIRC) 25 DM zu haben.
Das war ein Computer-Ramschladen in meiner Nähe. Die gestapelten Kisten
kenne ich auch noch. IBM muss die damals LKW-weise verscherbelt haben.
Leider hat nicht einmal das geholfen.

Die letzte Anwendung, die ich für OS/2 gesehen habe, war ein Thinkpad,
das eine 390 startete. Beeindruckend, dass das System außerhalb der
Verkaufszahlen von IBM intern weiterverwendet wurde.

Aus gut unterrichteten Kreisen weiß ich übrigens, dass Microsoft intern
lange keine eigenen Produkte genutzt hat. Jemand von der IBM sagte mir,
Microsoft habe mehrere IBM AS/400 geordert. Zwecks FiBu und AnBu.

Mit NT- und SQL-Server wollten die damals dann wohl doch nicht arbeiten. ;-)

FW
p***@pocnet.net
2024-02-15 08:51:06 UTC
Permalink
Post by F. W.
Aus gut unterrichteten Kreisen weiß ich übrigens, dass Microsoft intern
lange keine eigenen Produkte genutzt hat. Jemand von der IBM sagte mir,
Microsoft habe mehrere IBM AS/400 geordert. Zwecks FiBu und AnBu.
Ja, das habe ich auch gehört. Ein besseres Argument gegen die (damaligen?)
Produkte eines Herstellers der so agiert kann man nicht bekommen.
Post by F. W.
Mit NT- und SQL-Server wollten die damals dann wohl doch nicht arbeiten. ;-)
"Die Middleware wird gerade programmiert." ;-)
--
:wq! PoC
Marcel Mueller
2024-02-29 06:06:57 UTC
Permalink
Post by F. W.
Post by p***@pocnet.net
IBM als Sammelbecken von kreativen und fähigen Leuten, die Dinge
ersonnen haben *trotz* dem behördenähnlichen Inneren zolle ich Respekt.
Hier muss natürlich OS/2 etwas Wasser in den Wein gießen. Ich war damals
bei der IBM und wir hatten OS/2 auf dem Rechner. Wenig später erlaubte
die IBM allerdings, das Betriebssystem frei zu wählen und wenig später
flackerte Windows (3.11) wieder auf den Bildschirmen.
Das nenne ich mal ein echtes Downgrade.
OS/2 war ja weitestgehend kompatibel zu Win 3.11, aber wesentlich
stabiler und auch schneller. Vor allem asynchrones I/O und eine
gescheite Speicherverwaltung trugen dazu bei.
Post by F. W.
Ich war OS/2-Entwickler und musste OS/2 behalten. Erst als Strafe
wahrgenommen, installierte ich später auch auf meinem privaten PC OS/2.
Grund war die bessere aktualisierte Version und der 3.11-Modus, der auf
meinem privaten Rechner sehr gut lief. Und eben Borland-Pascal für OS/2
vorhanden war.
Ich hatte BCOS2, was wie bei Borland üblich, eher eine kommerzielle
Sammlung von Compilerfehlern war. (Pascal hatten sie wohl besser drauf.)
Post by F. W.
Ich war tatsächlich einer der wenigen, die um OS/2 getrauert haben. Kurz
vor dem absoluten Ende kaufte ich im Ramschladen noch "Warp" und nutzte
es, bis es keine Updates mehr gab, da ich damals schon Homebanking
machte und auf Sicherheit angewiesen war.
Ja, Viren und Würmer schreiben hat sich dafür nie gelohnt. ;-)
Post by F. W.
In einer Konferenz mit den Amerikanern sollten Ursachen ausgelotet
werden. Die herrschende Meinung war damals, dass IBM einfach nicht mit
Endkunden-Marketing Erfahrung hatte. Privatkunden funktionieren komplett
anders als Firmenkunden.
Ack. Hat gar nicht funktioniert. Der IBM Wasserkopf war viel zu dick, um
damit Prozesse abzuwickeln, die jeder für sich nur geringen Ertrag
lieferten.


Marcel
Peter J. Holzer
2024-02-14 08:27:33 UTC
Permalink
Post by F. W.
Post by Andreas Kohlbach
Heute vor 100 Jahren bekam IBM seinen Namen.
Heute vor 100 Jahren bekam DEHOMAG den Namen IBM. Die DEutsche HOllerith
MAschinen Gesellschaft). Es war Hermann Hollerith, der den Weg ebnete.
Die amerikanischste Firma der Erde hat deutsche Wurzeln.
[...]
Post by F. W.
(Soviel Klugschiss muss sein :-D )
Wenn schon klugscheißen, dann richtig:

1924 wurde die amerikanische Firma "Computing-Tabulating-Recording
Company" (CTR) in IBM umbenannt. Hollerith hatte zwar deutsche Wurzeln,
wurde aber in New geboren, wuchs in den USA auf und gründete dort seine
Firmen.

Die DEHOMAG war eine deutsche Firma, die 1922 von IBM (damals noch CTR)
übernommen wurde. Diese Tochter von IBM wurde erst 1949 in
"Internationale Büro-Maschinen Gesellschaft mbH" umbenannt.

hp
Christian Corti
2024-02-14 08:09:49 UTC
Permalink
Post by F. W.
Heute vor 100 Jahren bekam DEHOMAG den Namen IBM. Die DEutsche HOllerith
MAschinen Gesellschaft). Es war Hermann Hollerith, der den Weg ebnete.
Nicht ganz, es war quasi der Zusammenschluß der unterschiedlichen Bereiche
der amerikanischen ITR (Zeiterfassungssysteme), der TMC
(Tabelliersysteme) und CSC (Meßsysteme) zur Dachorganisation, die zuerst
CTR hieß. In der Zeit der Inflation wurde die Dehomag (gehörte quasi zur
TMC) übernommen, und wenig später wurde alles zur prägnanten IBM.

Christian
Peter J. Holzer
2024-02-14 09:08:51 UTC
Permalink
Post by F. W.
Post by Andreas Kohlbach
Heute vor 100 Jahren bekam IBM seinen Namen.
Heute vor 100 Jahren bekam DEHOMAG den Namen IBM. Die DEutsche HOllerith
MAschinen Gesellschaft). Es war Hermann Hollerith, der den Weg ebnete.
Die amerikanischste Firma der Erde hat deutsche Wurzeln.
[...]
Post by F. W.
(Soviel Klugschiss muss sein :-D )
Wenn schon klugscheißen, dann richtig:

1924 wurde die amerikanische Firma "Computing-Tabulating-Recording
Company" (CTR) in IBM umbenannt. Hollerith hatte zwar deutsche Wurzeln,
wurde aber in New York geboren, wuchs in den USA auf und gründete dort
seine Firmen.

Die DEHOMAG war eine deutsche Firma, die 1922 von IBM (damals noch CTR)
übernommen wurde. Diese Tochter von IBM wurde erst 1949 in
"Internationale Büro-Maschinen Gesellschaft mbH" umbenannt.

hp
Andreas Kohlbach
2024-02-15 00:09:18 UTC
Permalink
Post by F. W.
Post by Andreas Kohlbach
Heute vor 100 Jahren bekam IBM seinen Namen.
Heute vor 100 Jahren bekam DEHOMAG den Namen IBM. Die DEutsche HOllerith
MAschinen Gesellschaft). Es war Hermann Hollerith, der den Weg ebnete.
Die amerikanischste Firma der Erde hat deutsche Wurzeln.
DEHOMAG wurde, wenn ich das richtig verstehe, *auch* zu IBM.

Der Name der Hauptgesellschaft, die am 24. 2.1924 in "IBM" umbenannt
wurde, war "Computing-Tabulating-Recording Company", und hatte kein
"Deutsche" im Namen. Die DEHOMAG war nur ein ausländischer Teil von der
Computing-Tabulating-Recording Company.
--
Andreas
Thomas Koenig
2024-02-28 10:16:43 UTC
Permalink
Post by F. W.
Herzlichen Glückwunsch an die vermutlich bedeutendste Computerfirma der
Welt, für die ich ein paar Jahre arbeiten durfte.
Viele Techniken, Methoden, Programme, Ideen, Techniken, die wir heute
ganz selbstverständlich benutzen, stammen aus dieser Firma (auch wenn
Microsoft und Apple heute gern ihre Schilder überall drauf kleben).
IBM hat bei den Computern wirklich Bahnbrechendes geleistet.

Der erste brauchbare Hochsprachen-Compiler, FORTRAN. (Wer
"Abstracting Away The Machine" nicht gelesen hat, sollte das
tun :-) Das war der m.E. der wichtigste Schritt, Programmieren
wirtschaftlich zu machen.

Das System/360 war wirklich eine Revolution. Es hat nicht nur jede
Menge Standards in der Computerarchitektur gesetzt, wie das 8-bit
Byte und viele General-Purpose-Register, sondern auch das Konzept
einer kompatiblen Rechnerreihe eingeführt, dass man Software einfach
mitnehmen kann von einem Rechner auf den anderen. Das war damals
wirklich was ganz Neues, den Einfluss kann man kaum überschätzen.
Und dann auch noch eine Maschine, die sowohl kommerzielle als auch
wissenschaftlich/technische Software laufen lassen kann - wer
kennt denn sowas?

(OK, sie haben auch jede Menge Sachen verhauen, Floating Point z.B.,
aber S/360 war trotzdem genial, wenn man bedenkt, dass es keine
Vorläufersysteme gab, aus deren Fehler man hätte lernen können).

Virtuelle Speichersysteme basierend auf Paging, inklusive TLBs. Das
durch war wohl aus der Not geboren, weil MVS zu ressourcenfressend
war und man die Maschinen sonst kaum hätte ausnützen können.
Macht heute auch jeder.

Virtualisierung: IBM hatte schon VM laufen, das wahr Jahrzehnte
vor allen anderen.

Out-of-order execution: Mit der 360/91 eingeführt, kam erst viel
später wieder.

Caches: Die 360/85 war m.W. die erste Maschine, die Caches
kommerziell in größerem Maßstab einsetzte.

Ein Knick kam mit der fehlgeleiteten Entwicklung von "Future Systems",
was eins der größten Desaster der Geschichte der Computerentwicklung
war. Was man darüber so liest, gab es unklare Anforderungen und
Definitionen (immer tödlich), aber dafür die Ansage vom Management,
dass jeder fliegt, der das nicht unterstützt. Das Ruder wurde
erst spät rumgerissen, aber noch rechtzeitig, dass die Firma nicht
Pleite ging.

Supercompouting: (Stark verkürzt) Nach dem Misserfolg mit dem
Stretch hätten sie die Chance gehabt, selber was zu machen, ließen
sich aber von Seymour Cray die Butter vom Brot nehmen. Und Gene
Amdahl ließen sie lieber ziehen, als ihn einen Supercomputer
bauen zu lassen.

RISC: IBM waren die ersten, die ein vernünfiges RISC-Konzept hatten,
deutlich vor Berkeley und Stanford, die 801. Aus internen Gründen
konnen sie es nicht ausnutzen, sonst hätte sich DEC möglicherweise
nicht so entwickelt.

Software: Die Großrechner-Betriebssysteme von IBM sind hochgradig
arkan und auch nie so richtig auf Timesharing ausgerichtet. Das war
eine große Stärke von DEC, die kamen aus dem Echtzeitbereich
und haben daher vernünftige Antwortzeiten hinbekommen, auch wenn
für jeden Tastendruck eines Benutzers ein Interrupt ausgelöst wurde.

Und dann die Minicomputer-Revoultion... IBM hat da nicht wirklich
migtespielt.

Und dann die RISC-Revolution, die die Minicomputer aufgefressen
hat, aber auch jede Menge Großrechner-Anwendungen. SAP lief halt
plötzlich auch auf RISC-Systemen, die ungemein viel billiger in Kauf
und Betrieb waren als die /360-Nachfolger.

Und dann die PCs. Von einem Skunkworks-Projekt losgetreten, um
Apple zu ärgern... und der Rest ist Geschichte und Economy of
Scale bei der Computerentwicklung und -fertigung.

Neben OS/2 war der Versuch, mit dem Microchannel die Zahnpasta
wieder zurück in die Tube zu drücken, für IBM auf dem PC-Sektor
tödlich. Der offene Standard war etabliert, und Compaq konnte
mit 386-basierten Systemen an den 286-basierten Systemen von IBM
vorbeiziehen.
p***@pocnet.net
2024-02-28 10:51:55 UTC
Permalink
Thomas Koenig <***@netcologne.de> wrote:

[eine wunderschöne Zusammenfassung]
sondern auch das Konzept einer kompatiblen Rechnerreihe eingeführt, dass man
Software einfach mitnehmen kann von einem Rechner auf den anderen. Das war
damals wirklich was ganz Neues, den Einfluss kann man kaum überschätzen.
Yap. Einen schwachen Abklatsch der Folgen von "nicht mitnehmen" gab es dann
etliche Jahre später wieder mit den untereinander inkompatiblen BASIC
Varianten der 8-Bit Plattformen.
Virtuelle Speichersysteme basierend auf Paging, inklusive TLBs.
Wobei das erst später (im Vergleich zur Plattform selbst) kam und auch nur auf
externen Druck (UMICH) hin.

<https://en.wikipedia.org/wiki/IBM_System/360_Model_67>

Die ersten mit einer Isolationsschicht zwischen echten Speicheradressen und
dem was die Applikation sah war IBM indes nicht.

<https://en.wikipedia.org/wiki/Virtual_memory>

Ich verwende hier absichtlich die Artikel aus der englischsprachigen
Wikipedia. Die deutsche WP kannst in Sachen Computerartikel im Regelfall
knicken. Da wird lieber Politik gemacht und auf Details rumgeritten als
Inhalte eingepflegt.
Das durch war wohl aus der Not geboren, weil MVS zu ressourcenfressend war
und man die Maschinen sonst kaum hätte ausnützen können.
MVS gab es damals noch nicht. Die Not war durch VM bedingt.
Ein Knick kam mit der fehlgeleiteten Entwicklung von "Future Systems",
was eins der größten Desaster der Geschichte der Computerentwicklung
war.
Ja. Wobei S/38 und die AS/400 sehr vom Scherbenhaufen FS profitierten.
Was man darüber so liest, gab es unklare Anforderungen und Definitionen
(immer tödlich), aber dafür die Ansage vom Management, dass jeder fliegt,
der das nicht unterstützt.
Das war nicht der einzige Grund. IBM wollte den ganz großen Wurf machen und
verhindern, dass nochmal so eine Katastrophe wie mit Gene Amdahl passiert.
Also gab es keinen der alles wusste und den wirklichen Überblick hatte. Jeder
Beteiligte durfte nur so viel wissen wie er für seinen zu leistenden Beitrag
unbedingt wissen musste und nicht mehr. Wie gut das funktioniert hat wissen
wir zwischenzeitlich.

<https://en.wikipedia.org/wiki/IBM_Future_Systems_project>
RISC: IBM waren die ersten, die ein vernünfiges RISC-Konzept hatten,
deutlich vor Berkeley und Stanford, die 801. Aus internen Gründen konnen
sie es nicht ausnutzen, sonst hätte sich DEC möglicherweise nicht so
entwickelt.
IBM ist einfach gigantisch groß und der von oben gewollte interne
Konkurrenzkampf sorgt(e) manchmal für sehr bizarre Entscheidungen.

Aus dem 801 ging später mehr oder weniger der PowerPC hervor.

<https://en.wikipedia.org/wiki/IBM_801>
Software: Die Großrechner-Betriebssysteme von IBM sind hochgradig arkan und
auch nie so richtig auf Timesharing ausgerichtet.
Ja, IBM war da sehr kurzsichtig und glaubte daran, dass unbeaufsichtigte
Stapelverarbeitung das Ding für die kommenden Jahre wäre.
Das war eine große Stärke von DEC, die kamen aus dem Echtzeitbereich und
haben daher vernünftige Antwortzeiten hinbekommen, auch wenn für jeden
Tastendruck eines Benutzers ein Interrupt ausgelöst wurde.
Da habe ich keine persönliche Vergleichsmöglichkeit. Aber es ist
beeindruckend, wieviele Terminals die wirklich großen Mainframe-Installationen
bei Fluglinien und Banken mit doch arg begrenzten Ressourcen bedient haben
(sollen). Ob vergleichbare Anzahlen in der VT100-Welt wirklich möglich waren?
--
:wq! PoC
Thomas Koenig
2024-02-28 12:47:03 UTC
Permalink
Post by p***@pocnet.net
Software: Die Großrechner-Betriebssysteme von IBM sind hochgradig arkan und
auch nie so richtig auf Timesharing ausgerichtet.
Ja, IBM war da sehr kurzsichtig und glaubte daran, dass unbeaufsichtigte
Stapelverarbeitung das Ding für die kommenden Jahre wäre.
TSO war ja auch etwas, was so halb zu MVS dazupasste... Mit VM/CMS haben
viele Leute gerne gearbeitet, ich hatte es nie verwendet.
Post by p***@pocnet.net
Das war eine große Stärke von DEC, die kamen aus dem Echtzeitbereich und
haben daher vernünftige Antwortzeiten hinbekommen, auch wenn für jeden
Tastendruck eines Benutzers ein Interrupt ausgelöst wurde.
Da habe ich keine persönliche Vergleichsmöglichkeit. Aber es ist
beeindruckend, wieviele Terminals die wirklich großen Mainframe-Installationen
bei Fluglinien und Banken mit doch arg begrenzten Ressourcen bedient haben
(sollen). Ob vergleichbare Anzahlen in der VT100-Welt wirklich möglich waren?
Wahrscheinlich eher nicht. Die 3270-Terminals sind/waren ja auf
Blockbetrieb ausgerichtet. Der Benutzer schreibt eine Zeile
oder einen Bildschirm voll, dann werden alle Daten auf einmal
rübergeschickt. Habe selber noch mit solchen Terminals gearbeitet :-)

Auf DEC-Maschinen hingegen wurde jeder Tastendruck einzeln geschickt
und auch quittiert, wie wir es heute kennen. Und auf deren Hardware
konnte man auf einer PDP-8, so ziemlich der schwachbrüstigsten
Maschine, die man noch als Computer bezeichnen kann, unter TSS/8
bis zu 16 Benutzer bedienen, und das anscheinend mit (damals)
akzeptablen Antwortzeiten.

Was IBM angeht: Lynn Wheeler hat unter https://www.garlic.com/~lynn/
jede Menge Beiträge aus 1. Hand zur IBM-Computergeschichte
gesammelt, er postet von Zeit zu Zeit in comp.arch oder
alt.folklore.computer . Lohnt sich, da mal rumzustöbern.
p***@pocnet.net
2024-02-28 23:58:14 UTC
Permalink
Post by Thomas Koenig
Post by p***@pocnet.net
Ja, IBM war da sehr kurzsichtig und glaubte daran, dass unbeaufsichtigte
Stapelverarbeitung das Ding für die kommenden Jahre wäre.
TSO war ja auch etwas, was so halb zu MVS dazupasste...
O für Option halt :-)
Post by Thomas Koenig
Mit VM/CMS haben viele Leute gerne gearbeitet, ich hatte es nie verwendet.
Ich wollte es mir irgendwann mal genauer ansehen. Hercules macht's möglich.
Möchte aber vorher einige andere "Baustellen" zumachen, bevor ich eine weitere
aufmache.

Mit dem alten MVS des Turnkey-Systems komme ich mittlerweile ganz gut klar,
aber mein (leider nicht emulierbarer) Favorit bleibt OS/400 ("MVS done
right"). :-)

Eine Herausforderung ist der COBOL-Compiler. Der letzte freie von IBM, stammt
noch aus prä-MVS Zeiten (MVT) und damit noch aus den 1960er Jahren. Es ist
einigermaßen schräg, darüber nachzudenken dass ich einen über 50 Jahre alten
Compiler noch heute benutzen kann. ;-)

Wer sich mal abseits von BASIC und 8-Bit Retrocomputing der ganz anderen Art
anschauen möchte: <https://wotho.pebble-beach.ch/tk4-/>

Die fünfte Inkarnation des Turnkey-Systems (diesmal von Rob Prins) ist zwar
schon draußen, aber da gibt's noch einige Problemchen die mit der Zeit behoben
werden.
Post by Thomas Koenig
Post by p***@pocnet.net
Da habe ich keine persönliche Vergleichsmöglichkeit. Aber es ist
beeindruckend, wieviele Terminals die wirklich großen
Mainframe-Installationen bei Fluglinien und Banken mit doch arg begrenzten
Ressourcen bedient haben (sollen). Ob vergleichbare Anzahlen in der
VT100-Welt wirklich möglich waren?
Wahrscheinlich eher nicht. Die 3270-Terminals sind/waren ja auf
Blockbetrieb ausgerichtet. Der Benutzer schreibt eine Zeile oder einen
Bildschirm voll, dann werden alle Daten auf einmal rübergeschickt. Habe
selber noch mit solchen Terminals gearbeitet :-)
Yap. Riecht verdächtig nach "Webformular". ;-)

Ich "arbeite" mit der 5250 Variante eines solchen Terminals ("emulator") fast
täglich, habe aber auch im Haus verteilt noch "hardware" Twinax-Terminals
verteilt. :-) Console brauch ich einmal im Monat für's Vollbackup.
Post by Thomas Koenig
Auf DEC-Maschinen hingegen wurde jeder Tastendruck einzeln geschickt
und auch quittiert, wie wir es heute kennen.
Yap. Mit den entsprechenden Wirkungen auf die CPU: Dauernd Unterbrechungen.
Post by Thomas Koenig
Und auf deren Hardware konnte man auf einer PDP-8, so ziemlich der
schwachbrüstigsten Maschine, die man noch als Computer bezeichnen kann,
unter TSS/8 bis zu 16 Benutzer bedienen, und das anscheinend mit (damals)
akzeptablen Antwortzeiten.
Was war denn "akzeptabel" aus damaliger Sicht? Und, es kommt ja auch immer
drauf an was man macht. Aus heutiger Sicht mehr als eine Sekunde auf die
Ausgabe einer Manpage warten zu müssen ist schon einigermaßen ungewohnt. Auf
dem 386 mit 20 MHz und Debian 2 gehen da doch einige Sekunden ins Land. Auf
der anderen Seite ist ein vi mit einer (üblicherweise recht kleinen)
Konfigurationsdatei zum Bearbeiten in ca. 1s geladen. Ja, IDE. ;-)

Eine AS/400 9401-P02 von 1994 mit arg knappen 8MB RAM rödelt bei jedem
Tastendruck auf den Platten rum, auch wenn man "nur" z. B. im Hilfetext einen
Screen runterscrollt. Jedesmal 2-3 Sekunden warten wird dann schnell zum
Geduldsspiel. Mit der doppelten Menge RAM ist das schon erheblich
entspannter, da ist die Geschwindigkeit von 19200 bps für die SDLC-Anbindung
der Engpass. Scrollen geht dann aber grob im Sekundentakt.

Interessante "Studie" von IBM zum Thema:
<https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html>
Post by Thomas Koenig
Was IBM angeht: Lynn Wheeler hat unter https://www.garlic.com/~lynn/ jede
Menge Beiträge aus 1. Hand zur IBM-Computergeschichte gesammelt, er postet
von Zeit zu Zeit in comp.arch oder alt.folklore.computer . Lohnt sich, da
mal rumzustöbern.
Da bin ich schonmal drübergestolpert. Sieht für mich auch heute noch wie eine
unübersichtliche Linksammlung aus, bei der ich nicht wüsste, wo ich anfangen
sollte oder was davon interessant sein könnte.
--
:wq! PoC
Thomas Koenig
2024-02-29 10:04:08 UTC
Permalink
Post by p***@pocnet.net
Eine AS/400 9401-P02 von 1994 mit arg knappen 8MB RAM rödelt bei jedem
Tastendruck auf den Platten rum, auch wenn man "nur" z. B. im Hilfetext einen
Screen runterscrollt. Jedesmal 2-3 Sekunden warten wird dann schnell zum
Geduldsspiel. Mit der doppelten Menge RAM ist das schon erheblich
entspannter, da ist die Geschwindigkeit von 19200 bps für die SDLC-Anbindung
der Engpass. Scrollen geht dann aber grob im Sekundentakt.
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.

Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.

UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken), Über 64 kb Speicherbereich
pro Prozess kamen sie auf jeden Fall nicht raus.

8 MB für einen Midrange-Rechner von 1994 reicht kaum mehr aus.

Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu
gebrauchen. Wir machen gerade massiv was falsch, glaube ich...
Post by p***@pocnet.net
<https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html>
Post by Thomas Koenig
Was IBM angeht: Lynn Wheeler hat unter https://www.garlic.com/~lynn/ jede
Menge Beiträge aus 1. Hand zur IBM-Computergeschichte gesammelt, er postet
von Zeit zu Zeit in comp.arch oder alt.folklore.computer . Lohnt sich, da
mal rumzustöbern.
Da bin ich schonmal drübergestolpert. Sieht für mich auch heute noch wie eine
unübersichtliche Linksammlung aus, bei der ich nicht wüsste, wo ich anfangen
sollte oder was davon interessant sein könnte.
Weil du dich mit MVS beschäftigst: Ein paar Bemerkungen in
https://www.garlic.com/~lynn/2024.html#50 sollten sehr interessant
sein, nimm das mal als Startpunkt. U.a. ist da ein Memo zu Future
Systems verlinkt, das wohl mitgholfen hat, dem Projekt den
Todesstoß zu geben, http://www.jfsowa.com/computer/memo125.htm .

Zitat: "In 1973, I had attended a presentation on the design of
the VANDERBILT hardware. After showing a diagram of the CPU frame,
which contained sixteen circuit boards, the presenter proudly said
"Each of these boards contains as much circuitry as a System/370,
Model 168." At that point, I asked the obvious question: "But the
expected performance is only about three times faster than a Model
168. Why don't you just build sixteen 168s?" Instead of answering,
he just glared at me."
Stefan Möding
2024-02-29 10:49:04 UTC
Permalink
Post by Thomas Koenig
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken), Über 64 kb Speicherbereich
pro Prozess kamen sie auf jeden Fall nicht raus.
BWK gibt für die PDP-7, mit der anfänglich die Entwicklung gemacht wurde,
"8K 18-bit words of memory" an.

Die später gekaufte PDP-11 hatte demnach 24K bytes: 16K für OS/Kernel und
8K für User Programme.

Ich erinnere mich noch an einen wissenschaftlichen Mitarbeiter an der Uni
(ca. 1992), der auf seiner DECstation mit 16MB unbedingt die Enterprise
als X11 Background haben wollte. Bei jedem verschieben eines Fensters gab
es mächtig I/O, um die entsprechenden Teile der Grafik wieder nachzuladen.
--
Stefan
p***@pocnet.net
2024-02-29 17:19:49 UTC
Permalink
Post by Stefan Möding
Ich erinnere mich noch an einen wissenschaftlichen Mitarbeiter an der Uni
(ca. 1992), der auf seiner DECstation mit 16MB unbedingt die Enterprise
als X11 Background haben wollte. Bei jedem verschieben eines Fensters gab
es mächtig I/O, um die entsprechenden Teile der Grafik wieder nachzuladen.
Haha! So ähnlich ging es mir mit einem Kontrollfeld zu frühen System 7 Zeiten
auf meinem SE/30. Irgendwoher hatte ich ein schickes 8-Bit Bild der Erdkugel
in 640x480. Machte sich hübsch auf dem externen Farbmonitor an der Kiste. Bis
ich bemerkte dass das OS selbst erheblich mehr Speicher brauchte...
--
:wq! PoC
Dennis Grevenstein
2024-02-29 11:52:47 UTC
Permalink
Post by Thomas Koenig
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken), Über 64 kb Speicherbereich
pro Prozess kamen sie auf jeden Fall nicht raus.
8 MB für einen Midrange-Rechner von 1994 reicht kaum mehr aus.
Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu
gebrauchen. Wir machen gerade massiv was falsch, glaube ich...
Wie kommst Du darauf, wenn Du berechnest, was Dich diese 8GB
Speicher heute kosten im Vergleich zu den 6KB der PDP-8?
Moderne Computer sind technologisch derart fortgeschritten,
dass der ganze bloat und Schrott schlicht eingepreist ist.
Ob Du den code schön findest, ist da schlicht egal ;-)
Es muss nicht mehr eine Rechenaufgabe möglichst effizient
gelöst werden, sondern man kauft für das verfügbare Geld
einfach möglichst viel Zeug. Der Entwickler, der Dir irgendwas
liebevoll handoptimiert, kostet einfach zuviel.

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Thomas Koenig
2024-02-29 12:55:47 UTC
Permalink
Post by Dennis Grevenstein
Post by Thomas Koenig
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken), Über 64 kb Speicherbereich
pro Prozess kamen sie auf jeden Fall nicht raus.
8 MB für einen Midrange-Rechner von 1994 reicht kaum mehr aus.
Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu
gebrauchen. Wir machen gerade massiv was falsch, glaube ich...
Wie kommst Du darauf, wenn Du berechnest, was Dich diese 8GB
Speicher heute kosten im Vergleich zu den 6KB der PDP-8?
Interessante Frage.

Eine heutige große Firma mit 10 000 Laptops pro Jahr, mit 100
Euro mehr pro Laptop für mehr Speicher zahlt eine Million extra
pro Jahr. Und wenn die IT Geld einsparen soll... 8GB haben's
doch mit Windows 7 auch getan, die 16 GB machen wir nur mit
Sondergenehmigung.

Die gleiche Firma hätte vielleicht füher 10 Minicomputer gehabt,
da wäre der Speicher vermutlich billiger gewesen.
Post by Dennis Grevenstein
Moderne Computer sind technologisch derart fortgeschritten,
dass der ganze bloat und Schrott schlicht eingepreist ist.
Problem ist nur, dass die Computer nur noch sehr kleine
Leistungssteigerungen haben und die Software schneller vermüllt,
als die Hardwarebranche schnellere Computer liefern kann.
Post by Dennis Grevenstein
Ob Du den code schön findest, ist da schlicht egal ;-)
Es muss nicht mehr eine Rechenaufgabe möglichst effizient
gelöst werden, sondern man kauft für das verfügbare Geld
einfach möglichst viel Zeug. Der Entwickler, der Dir irgendwas
liebevoll handoptimiert, kostet einfach zuviel.
Eher ein Problem von "Wir wollen tolle neue Features im
Katalog stehen haben, damit die Kunden kaufen. Ob die auch
wirklich dem Kunden was bringen und auch noch einigermaßen
funktionieren, das soll nicht unser Problem sein. Müll sie
voll, die Kiste!"

Und mit schlechter und schneller Software Geschäfte zu machen,
das war von Anfang an das Microsoft-Prinzip.
Dennis Grevenstein
2024-02-29 18:20:20 UTC
Permalink
Post by Thomas Koenig
Eine heutige große Firma mit 10 000 Laptops pro Jahr, mit 100
Euro mehr pro Laptop für mehr Speicher zahlt eine Million extra
pro Jahr. Und wenn die IT Geld einsparen soll... 8GB haben's
doch mit Windows 7 auch getan, die 16 GB machen wir nur mit
Sondergenehmigung.
Die gleiche Firma hätte vielleicht füher 10 Minicomputer gehabt,
da wäre der Speicher vermutlich billiger gewesen.
Da hast Du dann das Problem, dass sich die Nutzung von IT
extrem ausgeweitet hat. Die Leute machen mit den 10000 Notebooks
heute mehr bzw. anderes als damals. Wenn dann noch 10000
Kisten gekauft werden, die schon beim Kauf nicht das können,
was sie sollen, dann liegt das nicht wirklich am Preis, sondern
am Erbsenzähler, der glaubt man könnte das sparen, denn es
gibt immer irgendwo einen, der Prozesse optimieren und Geld
rauspressen will. Schau Dir die Bundeswehr an: die ist so
durchoptimiert, dass sie kaum mehr funktionsfähig ist.
Post by Thomas Koenig
Problem ist nur, dass die Computer nur noch sehr kleine
Leistungssteigerungen haben und die Software schneller vermüllt,
als die Hardwarebranche schnellere Computer liefern kann.
Ist das wirklich so? Ich glaube eher, dass die Dinger heute
mehr Leistungsreserven haben als noch vor einigen Jahren.
Zumindest aktuell hält auch Moore's law noch.
Post by Thomas Koenig
Eher ein Problem von "Wir wollen tolle neue Features im
Katalog stehen haben, damit die Kunden kaufen. Ob die auch
wirklich dem Kunden was bringen und auch noch einigermaßen
funktionieren, das soll nicht unser Problem sein. Müll sie
voll, die Kiste!"
Und mit schlechter und schneller Software Geschäfte zu machen,
das war von Anfang an das Microsoft-Prinzip.
nicht nur Microsoft, aber ja: nur mit support von altem Zeug
lässt sich wenig Geld verdienen. Die branche lebt davon,
dass die Leute regelmäßig neues Zeug kaufen.

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Stefan Möding
2024-02-29 18:48:56 UTC
Permalink
Post by Dennis Grevenstein
Ist das wirklich so? Ich glaube eher, dass die Dinger heute
mehr Leistungsreserven haben als noch vor einigen Jahren.
Zumindest aktuell hält auch Moore's law noch.
Das weckt dann neue Begehrlichkeiten...

Wenn ich zurückblicke, wie lange ein LaTeX-Lauf früher dauerte und
womöglich noch mit MetaFont neue Fonts berechnet wurden. Das geht heute
so fix, dass man per Script einfach bei jeden Speichern der Quellen neu
übersetzt und sofort anzeigt. Da wird LaTeX fast WYSIWYG.

Oder die IDEs wo nach jedem Tastendruck entweder die falsche Syntax
angezeigt wird oder ansonsten ein lauffähiges Executable raus kommt.

Da wird die "überschüssige" Leistung halt für Bequemlichkeit genutzt.
--
Stefan
Thomas Koenig
2024-03-01 08:12:11 UTC
Permalink
Post by Dennis Grevenstein
Post by Thomas Koenig
Problem ist nur, dass die Computer nur noch sehr kleine
Leistungssteigerungen haben und die Software schneller vermüllt,
als die Hardwarebranche schnellere Computer liefern kann.
Ist das wirklich so?
Ja.

Taktfrequenzen sind so ziemlich ausgereizt, die heutigen Prozessoren
takten kaum (Prozente) mehr schneller als die von vor 10 Jahren.
Das liegt an der Physik: Auch wenn man unter riesigem Aufwand
kleinere Strukturen herstellt, die man schneller schalten könnte:
kleinere Strukturen heißen auch dünnere Leitungen, und der
zusätzliche Widerstand isst die Vorteile in der Geschwindigkeit
wieder auf.

Level-1-Caches sind auch seit sehr langer Zeit bei ca. 64 kb
fest, und die Latenz beim Ansprechen geht eher hoch als runter,
ist jetzt bei ca. 5 Zyklen.

Um die Latenzen beim Ansprechen der Cache-Hierarchie abzufangen,
verwendet man seit langer Zeit Out-of-Order-Prozessoren, wo
teilweise 700 Instruktionen "in flight", also gleichzeitig aktiv
sind. Ein branch mispredict, und die müssen unauffällig entsorgt
werden (bitte ohne Rückwirkung auf den beobachtbaren Zustand des
Prozessors, was nicht funktioniert - siehe Meltdown und Spectre).
Man könnte nochmal von 700 auf 1400 Instruktionen in flight gehen,
aber bringt nur marginal was.

Und der Hauptspeicher ist mittlerweile so weit weg, dass bei einem
L3 Cache Miss der Prozessor erst mal 'ne Brieftaube losschicken
muss. Ich habe noch 150 Zyklen im Kopf, bis da was da ist, aber
das könnte mittlerweile optimistisch sein. Und bei einem TLB-miss...
Fetch predictors sind mittlerweile essenziell, und auch schon
ziemlich ausgereizt.

Das ist ja auch der Grund für Hyperthreading oder wie das jeweils
auch heisst: Während ein Thread Däumchen dreht, kann der andere ja
schon mal weiterlaufen und schauen, ob seine Brieftaube mittlerweile
schon zurückgekehrt ist.

Branch predictors: Die sind mittlerweile unglaublich gut, es gibt
da schon first und second level und... Auch da gibt es nur
noch inkrementell was rauszuholen.

Parallelle Verarbeitung auf einem core: Sechs Instruktionen
parallel anzustoßen (issue) ist mittlerweile Standard, die mad
lads von ARM haben irgendwo auch acht, aber solange die eine
Instruktion auf das Ergebnis der anderen warten muss, hilft das
irgenwann auch nicht mehr.

SIMD: Gut für spezialisierte Dinge. Mittlerweile bei Intel
so hochgezüchtet, dass sie bei AVX512 den ganzen Prozessor
runtertakten müssen, weil er sonst übrhitzt. AMD macht das
besser, die führen einfach 2*256 bits aus. Und SIMD hilft
für general purpose code nicht unbedingt viel.

Mehr Cores: Hilft, wenn auch wirklich parallele Dinge zu tun sind.
Parallel zu programmieren, ist leider nochmal viel schwieriger
als serielles, was wir eh schon kaum im Griff haben.
Post by Dennis Grevenstein
Ich glaube eher, dass die Dinger heute
mehr Leistungsreserven haben als noch vor einigen Jahren.
Zumindest aktuell hält auch Moore's law noch.
Die Transistoren werden immer noch mehr, aber die Verbesserungen,
die sie bringen, immer weniger.

Und dann kommt Microsoft um die Ecke und programmiert Teams
großtenteils in Javascript...
Dennis Grevenstein
2024-03-01 10:27:29 UTC
Permalink
Post by Thomas Koenig
Die Transistoren werden immer noch mehr, aber die Verbesserungen,
die sie bringen, immer weniger.
Da kommt dann halt grob sowas raus:
https://qph.cf2.quoracdn.net/main-qimg-0b7c85d8b43e5dfd32864aebf73563eb

Ist schon in Ordnung. Nur wurde der ganze Kram, über die Zeit immer
billiger und weiter verbreitet.
Post by Thomas Koenig
Und dann kommt Microsoft um die Ecke und programmiert Teams
großtenteils in Javascript...
Mag alles sein. Der Punkt war aber doch, dass es sich für die Firmen
noch lohnt, den Schrott so zu programmieren, weil die Kunden die Hardware
dafür haben. Es gibt wenig Anreize, haltbare, schnelle und zuverlässige
Software zu entwickeln, weil die Kunden Anreize brauchen, immer wieder
updates und support zu kaufen.

Ich persönlich meckere ja schon seit langer Zeit immer wieder über
Apples Softwarepoltik und den update-Zwang bei MacOS, weil sie alte
Versionen nicht mehr entsprechend lang mit updates versorgen und neue
Versionen immer unausgereifter released werden. Aber die Logik dahinter
ist eigentlich klar: früher konnte man noch davon ausgehen, dass die
Leute für die neue OS version upgraden, weil sich oft so viel grundsätzlich
verändert hat.
Heute kann man kaum mehr genug tolle features nachlegen, die die Kunden
zu update/upgrade motvieren. Beim Desktop ist im wesentlichen die Luft
raus. Mein Nutzungsverhalten hat sich seit über 10 Jahren nicht verändert.
Das sind nur noch einzelne Softwarepakete, wo die aktuelle Version
fundamental mehr kann als eine Version von vor 10 Jahren.
Ich würde mir das wünschen, dass die in der nächsten Version keine neuen
feature einbauen, sondern nur bugs fixen und performance verbessern.
Machen sie aber nicht, weil das der Kram ist, der Geld kostet und kaum
jemanden motiviert, das nächste Zeug zu kaufen.

Das sind eben zwei gegenläufige Prozesse: Der eine sorgt dafür, dass
hardware und software gleichmäßig schneller/langsamer werden und sich
das so weiter gegenseitig aufschaukelt. Der andere sorgt über die gesamte
Breite des Marktes dafür, dass alles insgesamt mehr kann und mittlerweile
fast jedes Kind mit einem Computer in der Hosentasche rumläuft.
Nur ist die Verbesserung der Technologie die Voraussetzung für die
weite Verbreitung, weil eine PDP-8 in der Hosentasche für Kinder nicht
soviel Anreiz hat wie eine Kombination Telefon/Spielkonsole/Kalender/
Videokonferenz/Fotoapparat/Videorecorder/Fernseher/Internet.
Da kannst Du sicher kommen und Dich beschweren, dass so ein Handyspiel
vielleicht nur ein schlechter, ineffizienter port eines alten SNES
Spiels ist und da hättest Du recht. Aber das SNES konnte man nicht
in die Hosentasche stecken und es konnte auch nicht all den anderen
Kram zusätzlich.

Insgesamt haben wir bestimmt den Punkt erreicht, an dem wir durch
optimierte Software mehr gewinnen würden als durch schnellere hardware,
aber genau das Optimieren der Software ist teurer als neue Hardware,
solange wir da nicht den menschlichen Faktor ausschalten können und
z.B. der KI sagen könnten: optimiere mal die Algorithmen und mach das
schneller.

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Enrik Berkhan
2024-03-01 11:56:33 UTC
Permalink
Post by Dennis Grevenstein
Post by Thomas Koenig
Und dann kommt Microsoft um die Ecke und programmiert Teams
großtenteils in Javascript...
Mag alles sein. Der Punkt war aber doch, dass es sich für die Firmen
noch lohnt, den Schrott so zu programmieren, weil die Kunden die Hardware
dafür haben.
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.

Gruß,
Enrik
Dennis Grevenstein
2024-03-01 13:22:20 UTC
Permalink
Post by Enrik Berkhan
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
und warum wurde dann entschieden, den Schrott zu benutzen statt
irgendwas, das besser funktioniert?
Ganz wie Du sagst: das müsste nicht sein.

Das ist wieder mal dasselbe wie:
1: Wir haben auf SAP upgegradet.
2: Ja, und?
1: Jetzt ist alles sehr langsam.
2: Ja. Das sagtest Du schon.

Jenseits davon, dass Teams vielleicht Müll ist, kann man eigentlich
heute mit jedem aktuellen Handy/tablet videokonferenz machen und
es braucht nichtmal software in liebevoll handoptimiertem Assembler
dafür oder überhaupt einen Lüfter.

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Enrik Berkhan
2024-03-01 18:13:36 UTC
Permalink
Post by Dennis Grevenstein
Post by Enrik Berkhan
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
und warum wurde dann entschieden, den Schrott zu benutzen statt
irgendwas, das besser funktioniert?
Anderes Thema, auf das ich aus gesundheitlichen Gründen nicht eingehe.

Gruß,
Enrik
Kay Martinen
2024-03-01 23:06:12 UTC
Permalink
Post by Dennis Grevenstein
Post by Enrik Berkhan
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
und warum wurde dann entschieden, den Schrott zu benutzen statt
irgendwas, das besser funktioniert?
Dumme Menschen tun dumme Dinge. Oder? ;)
Post by Dennis Grevenstein
Ganz wie Du sagst: das müsste nicht sein.
Jenseits davon, dass Teams vielleicht Müll ist, kann man eigentlich
heute mit jedem aktuellen Handy/tablet videokonferenz machen und
es braucht nichtmal software in liebevoll handoptimiertem Assembler
dafür oder überhaupt einen Lüfter.
Videokonferenzen gab es früher schon, nur mit mehr Hardware-einsatz wie
z.b. einem eigenen Videostudio, mehreren Satelliten-Links oder in
kleiner mit von der Vermittlung per ISDN geschalteten Systemen... so
weit ich erinnere das gelesen zu haben.

Dagegen sind ein paar Überzüchtete Laptops mit Schrottigster Software an
einem Mega-DSL Link die dennoch die Lüfter röhren lassen doch
"relativ"... nix! ;-)

Ist energetisch vielleicht sogar sparsamer...?

Bye/
/Kay
--
nix
p***@pocnet.net
2024-03-02 11:32:23 UTC
Permalink
Post by Kay Martinen
Post by Dennis Grevenstein
und warum wurde dann entschieden, den Schrott zu benutzen statt
irgendwas, das besser funktioniert?
Dumme Menschen tun dumme Dinge. Oder? ;)
Auch intelligente Menschen tun dumme Dinge. Frei nach dem Motto gut gemeint
ist nicht automatisch gut gemacht. Und nach dem anderen Motto es einem jeden
recht getan...
--
:wq! PoC
p***@pocnet.net
2024-03-01 16:35:54 UTC
Permalink
Post by Enrik Berkhan
Post by Dennis Grevenstein
Mag alles sein. Der Punkt war aber doch, dass es sich für die Firmen
noch lohnt, den Schrott so zu programmieren, weil die Kunden die Hardware
dafür haben.
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
Und? Rotierende Lüfter heißt ja nicht dass die Software nicht das tut für was
sie geschrieben wurde.
--
:wq! PoC
Thomas Koenig
2024-03-01 18:12:14 UTC
Permalink
Post by p***@pocnet.net
Post by Enrik Berkhan
Post by Dennis Grevenstein
Mag alles sein. Der Punkt war aber doch, dass es sich für die Firmen
noch lohnt, den Schrott so zu programmieren, weil die Kunden die Hardware
dafür haben.
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
Und? Rotierende Lüfter heißt ja nicht dass die Software nicht das tut für was
sie geschrieben wurde.
Heisst aber, dass die Software erhebliche Ressourcen zieht:
Rechenleistung (bzw. Schaltvorgänge in CMOS) resultieren halt
in dissipierter Leistung, und entsprechend kürzer halten dann
auch z.B. Akkus.
p***@pocnet.net
2024-03-01 18:31:28 UTC
Permalink
Post by p***@pocnet.net
Post by Enrik Berkhan
Mag alles sein. Der Punkt war aber doch, dass es sich für die Firmen noch
lohnt, den Schrott so zu programmieren, weil die Kunden die Hardware
dafür haben.
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
Und? Rotierende Lüfter heißt ja nicht dass die Software nicht das tut für was
sie geschrieben wurde.
Heisst aber, dass die Software erhebliche Ressourcen zieht: Rechenleistung
(bzw. Schaltvorgänge in CMOS) resultieren halt in dissipierter Leistung, und
entsprechend kürzer halten dann auch z.B. Akkus.
Schon klar. Ich weiss worauf Du raus willst, aber das ist was anderes als
"Kunden haben nicht die passende Hardware dafür", siehe Zitatbaum weiter oben.

Dass eine solche Ressourcenverschwendung nicht toll ist, sehe ich genauso.
Aber wir ändern die Welt leider nicht.
--
:wq! PoC
Kay Martinen
2024-03-02 00:05:14 UTC
Permalink
Post by p***@pocnet.net
Post by Enrik Berkhan
Post by Dennis Grevenstein
Mag alles sein. Der Punkt war aber doch, dass es sich für die Firmen
noch lohnt, den Schrott so zu programmieren, weil die Kunden die Hardware
dafür haben.
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des besten
Notebooks merklich zum Rotieren. Das müsste nicht sein.
Und? Rotierende Lüfter heißt ja nicht dass die Software nicht das tut für was
sie geschrieben wurde.
Genau. Das Bedeutet nur das es ein weiteres Stück Software ist die sich
verhält wie der Kommunismus. Der lt. einer Mär; wie ein Gas; den zur
Verfügung stehenden Raum komplett ausfüllt.

Finde den Fehler. ;)

Wenn; wie hier im Thread schon angemahnt; die Leistungsfortschritte der
Hardware stetig kleiner werden und gar stagnieren dann kann man nur
hoffen das nach einer Weile die Stagnation zu einem Umdenken zu
Ressourcensparender Programmierung führte. Denn wenn das die Einzig
verbliebene Möglichkeit wird, ist sie ja alternativlos.

Auf die dann kommenden "Geschäftsmodelle" bin ich allerdings nicht gespannt.

Bye/
/Kay
--
nix
Michael van Elst
2024-03-02 09:45:39 UTC
Permalink
Post by Kay Martinen
Wenn; wie hier im Thread schon angemahnt; die Leistungsfortschritte der
Hardware stetig kleiner werden und gar stagnieren dann kann man nur
hoffen das nach einer Weile die Stagnation zu einem Umdenken zu
Ressourcensparender Programmierung führte.
Da braucht es kein Umdenken, nur Schmerzempfinden. Auf den Reiz folgt
eine Reaktion, bis der Schmerz nachlässt.
Hermann Riemann
2024-03-02 11:05:10 UTC
Permalink
Post by Michael van Elst
Post by Kay Martinen
Wenn; wie hier im Thread schon angemahnt; die Leistungsfortschritte der
Hardware stetig kleiner werden und gar stagnieren dann kann man nur
hoffen das nach einer Weile die Stagnation zu einem Umdenken zu
Ressourcensparender Programmierung führte.
Da braucht es kein Umdenken, nur Schmerzempfinden. Auf den Reiz folgt
eine Reaktion, bis der Schmerz nachlässt.
Das kann ich bei den vielen "nur notwendige cookies zulassen"
nicht feststellen.

Hermann
der bei notwendig hier irgendwie eher an fake news denkt.
Und meint, Bürokratie gibt es nicht nur bei Behörden.
--
<http://www.hermann-riemann.de>
Arno Welzel
2024-03-02 19:33:35 UTC
Permalink
Post by Hermann Riemann
Post by Michael van Elst
Post by Kay Martinen
Wenn; wie hier im Thread schon angemahnt; die Leistungsfortschritte der
Hardware stetig kleiner werden und gar stagnieren dann kann man nur
hoffen das nach einer Weile die Stagnation zu einem Umdenken zu
Ressourcensparender Programmierung führte.
Da braucht es kein Umdenken, nur Schmerzempfinden. Auf den Reiz folgt
eine Reaktion, bis der Schmerz nachlässt.
Das kann ich bei den vielen "nur notwendige cookies zulassen"
nicht feststellen.
Die sind aber nicht da, weil die Entwickler das toll finden, sondern
weil Gesetze die Zustimmung fordern.
--
Arno Welzel
https://arnowelzel.de
Peter J. Holzer
2024-03-03 00:34:02 UTC
Permalink
Post by Arno Welzel
Post by Hermann Riemann
Post by Michael van Elst
Da braucht es kein Umdenken, nur Schmerzempfinden. Auf den Reiz folgt
eine Reaktion, bis der Schmerz nachlässt.
Das kann ich bei den vielen "nur notwendige cookies zulassen"
nicht feststellen.
Die sind aber nicht da, weil die Entwickler das toll finden, sondern
weil Gesetze die Zustimmung fordern.
Eher weil das für die Entscheider die sicherste Methode ist.

hp
Kay Martinen
2024-03-02 14:18:25 UTC
Permalink
Post by Michael van Elst
Post by Kay Martinen
Wenn; wie hier im Thread schon angemahnt; die Leistungsfortschritte der
Hardware stetig kleiner werden und gar stagnieren dann kann man nur
hoffen das nach einer Weile die Stagnation zu einem Umdenken zu
Ressourcensparender Programmierung führte.
Da braucht es kein Umdenken, nur Schmerzempfinden. Auf den Reiz folgt
eine Reaktion, bis der Schmerz nachlässt.
Physiologisch gesprochen scheint mir das gleich zu sein. Nur über die
Dauer zwischen Schmerz und Reaktion hätte ich zweifel, und ob die
ausreicht das eine Kritische Masse "reagiert". Sonst wird's nur ein
Nadelstich.

Nachhaltig ist das alles sowieso nicht.

Bye/
/Kay
--
nix
Diedrich Ehlerding
2024-03-02 09:49:01 UTC
Permalink
Post by p***@pocnet.net
Post by Enrik Berkhan
Eben nicht. Teams bringt bei ganz normaler Nutzung die Lüfter des
besten Notebooks merklich zum Rotieren. Das müsste nicht sein.
Und? Rotierende Lüfter heißt ja nicht dass die Software nicht das tut
für was sie geschrieben wurde.
Sierhe dazu auch die Einheit "saps" des Leistungsbedarfs, den die Firma
SAP für ihre Software verwendet.

Der Leistungsbedarf eines Standardusers ist immer "1 saps". Das ist
völlig konstant und gilt für jede SAP-Version.

Nur die Rechner werden in geheimisvoller Weise und schlagartig durch
ein neues Release immer langsamer - ein System, das im Jahre x bei der
Einführung der SAP-Version y die Leistung 100 saps hatte, also 100
solche Standarduser verkraftete, leistete im Jahr x+1 bei Einführung
der Version y+1 (oder auch y+0.1) vorhersagbar nur noch 75 saps.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Hermann Riemann
2024-03-01 11:05:55 UTC
Permalink
Post by Thomas Koenig
Taktfrequenzen sind so ziemlich ausgereizt, die heutigen Prozessoren
takten kaum (Prozente) mehr schneller als die von vor 10 Jahren. Das
liegt an der Physik: Auch wenn man unter riesigem Aufwand kleinere
Strukturen herstellt, die man schneller schalten könnte: kleinere
Strukturen heißen auch dünnere Leitungen, und der zusätzliche
Widerstand isst die Vorteile in der Geschwindigkeit wieder auf.
Es gibt eine weitere Grenze.
Bei jedem Schalten wird elektrische Energie in Wärme umgesetzt.
Und da gibt es u.a. Kühlprobleme.
Post by Thomas Koenig
Ich glaube eher, dass die Dinger heute mehr Leistungsreserven haben
als noch vor einigen Jahren. Zumindest aktuell hält auch Moore's
law noch.
Die Transistoren werden immer noch mehr.
Das nähert sich auch dem Ende.
Vielleicht kommt noch mal ein kleiner Sprung Silizium nach Kohlenstoff,
aber mit den gewohnten 10 Potenzen dürft es vorbei sein.

Den Ionen Rechner Gehirn bitweise auf
Elektronenrechner umzusetzen ..
--
<http://www.hermann-riemann.de
Peter J. Holzer
2024-03-01 19:45:06 UTC
Permalink
Post by Thomas Koenig
Und dann kommt Microsoft um die Ecke und programmiert Teams
großtenteils in Javascript...
Das wäre ja an sich kein Problem. Was macht Teams, das mehr Performance
brauchen sollte, als der JIT-Compiler liefern kann? (Ja, Video, aber das
läuft eh im Browser-Core oder der GPU)

Wäre kein Problem, wenn es gut geschriebenes JavaScript wäre ...

hp

Disclaimer: Ich mag JavaScript nicht. Aber Performance zählt eher nicht
zu den vielen Problemen von JavaScript.
Hermann Riemann
2024-03-02 05:41:22 UTC
Permalink
Post by Peter J. Holzer
Wäre kein Problem, wenn es gut geschriebenes JavaScript wäre ...
Disclaimer: Ich mag JavaScript nicht.
Ich auch nicht.
"Weiterbildung" in JavaScript habe ich seit über 20 Jahre eingestellt.
( VBscript schon früher dem Müll zugeordnet. )

Hermann
auf PythonScript offiziell in browser hoffend.
--
<http://www.hermann-riemann.de>
Arno Welzel
2024-03-02 19:35:20 UTC
Permalink
Post by Hermann Riemann
Post by Peter J. Holzer
Wäre kein Problem, wenn es gut geschriebenes JavaScript wäre ...
Disclaimer: Ich mag JavaScript nicht.
Ich auch nicht.
"Weiterbildung" in JavaScript habe ich seit über 20 Jahre eingestellt.
( VBscript schon früher dem Müll zugeordnet. )
Hermann
auf PythonScript offiziell in browser hoffend.
Offiziell nicht, aber möglich ist das, wenn man will:

<https://pyscript.net/>
--
Arno Welzel
https://arnowelzel.de
Kay Martinen
2024-03-01 22:48:33 UTC
Permalink
Post by Dennis Grevenstein
Post by Thomas Koenig
Problem ist nur, dass die Computer nur noch sehr kleine
Leistungssteigerungen haben und die Software schneller vermüllt,
als die Hardwarebranche schnellere Computer liefern kann.
Ist das wirklich so?
Ja.
Würde ich auch so betrachten wollen.
[Gute Hardware-zusammenfassung]
Post by Dennis Grevenstein
Ich glaube eher, dass die Dinger heute
mehr Leistungsreserven haben als noch vor einigen Jahren.
Zumindest aktuell hält auch Moore's law noch.
Aber doch nur noch mit Hängen und Würgen und etlichen Tricksereien, wie
man so liest.

Und die Leistungsreserven... kommen die wirklich nur hier raus...
Die Transistoren werden immer noch mehr, aber die Verbesserungen,
die sie bringen, immer weniger.
... und spielt der Neuste Software-trick der auf ein durch noch mehr
Transistoren implementiertes Feature basiert auch eine Rolle?

Es gab früher schon Coprozessoren-Emulationen in Software. Die allesamt
kreuzlahmer waren als die Echte HW 80387 z.b.
Und dann kommt Microsoft um die Ecke und programmiert Teams
großtenteils in Javascript...
Sei doch froh. Dann ist es wenigstens PORTABEL. ;-) Darum gehts doch
heute auch vermehrt oder?


Bye/
/Kay
--
nix
Arno Welzel
2024-03-02 12:00:19 UTC
Permalink
[...]
Post by Dennis Grevenstein
Post by Thomas Koenig
Problem ist nur, dass die Computer nur noch sehr kleine
Leistungssteigerungen haben und die Software schneller vermüllt,
als die Hardwarebranche schnellere Computer liefern kann.
Ist das wirklich so? Ich glaube eher, dass die Dinger heute
mehr Leistungsreserven haben als noch vor einigen Jahren.
Zumindest aktuell hält auch Moore's law noch.
Nein, Moore's Law kann man schon seit über 10 Jahren nicht mehr so
anwenden, wie es mal war. Die Kurve flacht immer weiter ab und man kommt
immer näher an physische Grenzen.

[...]
Post by Dennis Grevenstein
Post by Thomas Koenig
Und mit schlechter und schneller Software Geschäfte zu machen,
das war von Anfang an das Microsoft-Prinzip.
nicht nur Microsoft, aber ja: nur mit support von altem Zeug
lässt sich wenig Geld verdienen. Die branche lebt davon,
dass die Leute regelmäßig neues Zeug kaufen.
Microsoft macht schon lange kein Geschäft mehr mit Software, für die man
ständig neue Hardware braucht - auch wenn das bei Windows 11 so wirkt,
weil TPM und neue CPU-Befehle genutzt und irgendwann zwingend
vorausgesetzt werden, ohne, dass man das abschalten kann.

Das Hauptgeschäft bei Microsoft ist mittlerweile Azure mit allen
Diensten, die darüber angeboten werden, wie Azure Cloud Client für die
zentrale Verwaltung von Windows-Endgeräten, die mit Hilfe von UEFI
direkt aus Azure mit Windows versorgt werden oder Azure Virtual Desktop,
wo man dann faktisch gar keine lokale Ressourcen mehr außer Bildschirm,
Tastatur und Internetanbindung braucht.
--
Arno Welzel
https://arnowelzel.de
Hermann Riemann
2024-03-02 13:40:32 UTC
Permalink
Post by Arno Welzel
Das Hauptgeschäft bei Microsoft ist mittlerweile Azure mit allen
Diensten, die darüber angeboten werden, wie Azure Cloud Client für die
zentrale Verwaltung von Windows-Endgeräten, die mit Hilfe von UEFI
direkt aus Azure mit Windows versorgt werden oder Azure Virtual Desktop,
wo man dann faktisch gar keine lokale Ressourcen mehr außer Bildschirm,
Tastatur und Internetanbindung braucht.
Und was ist zwischen Bildschirm HDMI, Tastatur USB und Internet LAN?
Arno Welzel
2024-03-02 21:37:57 UTC
Permalink
Post by Hermann Riemann
Post by Arno Welzel
Das Hauptgeschäft bei Microsoft ist mittlerweile Azure mit allen
Diensten, die darüber angeboten werden, wie Azure Cloud Client für die
zentrale Verwaltung von Windows-Endgeräten, die mit Hilfe von UEFI
direkt aus Azure mit Windows versorgt werden oder Azure Virtual Desktop,
wo man dann faktisch gar keine lokale Ressourcen mehr außer Bildschirm,
Tastatur und Internetanbindung braucht.
Und was ist zwischen Bildschirm HDMI, Tastatur USB und Internet LAN?
Hardware. Die dient nur noch als Vehikel in's Internet. Gut möglich,
dass Microsoft da irgendwann ganz auf Linux wechselt. Mit WSL2
integrieren sie Ubuntu ja schon samt Desktop-Anwendungen als Teil von
Windows. Wäre nur konsequent, für Cloud Client und AVD gleich ganz auf
Windows als Unterbau zu verzichten oder eine abgespeckte Version zu
liefern, die nur für den Internet-Zugriff und ein bisschen lokales
Caching zuständig ist.
--
Arno Welzel
https://arnowelzel.de
Diedrich Ehlerding
2024-03-02 16:54:59 UTC
Permalink
[---] Azure Virtual Desktop,
wo man dann faktisch gar keine lokale Ressourcen mehr außer
Bildschirm, Tastatur und Internetanbindung braucht.
Und damit ist dann das Pendel zuückgeschwungen. Wir sind zurück uzu
dummen Terminals ohne lokale Intelligenz und ohne lokale Datenhaltung.
Lertztlich da, wo wir auch mit IMB 3270-Terminals in den 1970er/19809er
Jahren waren, nur dass jetzt die Daten irgendwo bei Microsoft liegen und
nicht mehr im eigenen Rechenzentrum. Nicht einmal IBM hatte früher diese
Kontrolle über die Daten ihrer Kunden ...
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Josef Möllers
2024-03-02 18:56:48 UTC
Permalink
Post by Diedrich Ehlerding
[---] Azure Virtual Desktop,
wo man dann faktisch gar keine lokale Ressourcen mehr außer
Bildschirm, Tastatur und Internetanbindung braucht.
Und damit ist dann das Pendel zuückgeschwungen. Wir sind zurück uzu
dummen Terminals ohne lokale Intelligenz und ohne lokale Datenhaltung.
Lertztlich da, wo wir auch mit IMB 3270-Terminals in den 1970er/19809er
Bzw mit X-Terminals

Josef
Diedrich Ehlerding
2024-03-02 19:18:57 UTC
Permalink
Post by Josef Möllers
Letztlich da, wo wir auch mit IBM 3270-Terminals in den
1970er/19809er
Bzw mit X-Terminals
Ja, die gabs kurzzeitig auch, aber nur in wenigen Umgebungen, letztlich
nur in lokalen Netzen, nicht standortübergreifend über mehrere
Niederlassungen einer Firma; sobald Grundstücksgrenzen im Spiel waren,
wurden die Leitungen für die nötigen Geschwindigkeitzen viel zu teuer;
und X-Terminals brauchen einen IP-Stack, der verbreitete sich erst
später als 3270-Umgebungen, und brauchten viel dünnere Leitungen;
zugegebenermaßen sind X-Terminals hübscher als Alphaterminals . Aber
das Prinzip ist das Gleiche: am Arbeitsplatz laufen keine individuellen
Programme, und da liegen keine Daten, auch keine persönlichen Daten. Zur
Hochzeit des Hypes um Client-Server-Architekturen, so ab 1985-1990,
haben die damaligen Unternehmensberater (heute würden wir wohl
"Influencer" sagen) den IT-Vorständen das Hohelied von der Verlagerung
der Intelligenz dorthin, wo sie gebraucht wird, gesungen, und den dicken
Mainframehobel verteufelt. Und nun haben wir die dicke Cloud und greifen
mit (zugegebenermaßen bunten) Terminals darauf zu.
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
p***@pocnet.net
2024-03-02 21:04:19 UTC
Permalink
Und nun haben wir die dicke Cloud und greifen mit (zugegebenermaßen bunten)
Terminals darauf zu.
Ja. Und langsam merken die Leute dass das keine gute Idee ist und das Pendel
wird wieder zurück zu lokalen Installationen schwingen.

Und jedesmal muss Geld ausgegeben werden. Das ist doch das was diesen Zirkus
letztendlich in Bewegung hält.
--
:wq! PoC
Arno Welzel
2024-03-02 21:46:47 UTC
Permalink
Post by p***@pocnet.net
Und nun haben wir die dicke Cloud und greifen mit (zugegebenermaßen bunten)
Terminals darauf zu.
Ja. Und langsam merken die Leute dass das keine gute Idee ist und das Pendel
wird wieder zurück zu lokalen Installationen schwingen.
Davon merke ich in meinem Umfeld wenig. Online-Dienste aller Art sind
eigentlich der Normalzustand und auch in Firmen wird immer mehr nur noch
online erledigt. Die lokale Installation ist vielfach nur noch die
Startplattform für Browser und Browser-artige Cross-Plattform-Kram wie
Electron.
--
Arno Welzel
https://arnowelzel.de
p***@pocnet.net
2024-03-02 22:11:02 UTC
Permalink
Post by Arno Welzel
Post by p***@pocnet.net
Ja. Und langsam merken die Leute dass das keine gute Idee ist und das
Pendel wird wieder zurück zu lokalen Installationen schwingen.
Davon merke ich in meinem Umfeld wenig.
Bis dass sich das in der Praxis vermehrt zeigt dürften noch Jahre vergehen.
Noch scheint ein Großteil der Firmen "in die Cloud" zu wollen, weil man das
jetzt eben so macht.
--
:wq! PoC
Arno Welzel
2024-03-02 21:39:58 UTC
Permalink
Post by Diedrich Ehlerding
[---] Azure Virtual Desktop,
wo man dann faktisch gar keine lokale Ressourcen mehr außer
Bildschirm, Tastatur und Internetanbindung braucht.
Und damit ist dann das Pendel zuückgeschwungen. Wir sind zurück uzu
dummen Terminals ohne lokale Intelligenz und ohne lokale Datenhaltung.
Lertztlich da, wo wir auch mit IMB 3270-Terminals in den 1970er/19809er
Jahren waren, nur dass jetzt die Daten irgendwo bei Microsoft liegen und
nicht mehr im eigenen Rechenzentrum. Nicht einmal IBM hatte früher diese
Kontrolle über die Daten ihrer Kunden ...
Ja, sehe ich auch so. Aber viele Unternehme haben zunehmend weniger
Interesse an eigenen Rechenzentren und Fachkräfte dafür zu finden, ist
auch nicht einfacher geworden. Also nutzt man lieber solche Dienste.
--
Arno Welzel
https://arnowelzel.de
Peter J. Holzer
2024-02-29 19:18:27 UTC
Permalink
Post by Thomas Koenig
Eine heutige große Firma mit 10 000 Laptops pro Jahr, mit 100
Euro mehr pro Laptop für mehr Speicher zahlt eine Million extra
pro Jahr.
Die hat dann aber auch ca. 50000 Mitarbeiter. Macht unterm Strich 20 €
pro Mitarbeiter und Jahr. Wieviel Arbeitszeit ist das?

hp
Thomas Koenig
2024-03-01 07:22:06 UTC
Permalink
Post by Peter J. Holzer
Post by Thomas Koenig
Eine heutige große Firma mit 10 000 Laptops pro Jahr, mit 100
Euro mehr pro Laptop für mehr Speicher zahlt eine Million extra
pro Jahr.
Die hat dann aber auch ca. 50000 Mitarbeiter. Macht unterm Strich 20 €
pro Mitarbeiter und Jahr. Wieviel Arbeitszeit ist das?
Auswechseln von Laptops, die ansonsten in Ordnung sind und "nur"
zu wenig Speicher haben, kostet den Mitarbeiter auch mal gerne
einen halben Tag oder mehr.

Bei einer früheren Firma hatte ich mal vorgeschlagen, IT-Probleme
als eigenes Abrechnungselemet anzulegen, damit das Management
sieht, wie die IT sich so auf die Produktivität auswirkt.

Die Reaktion war vohersehbar :-)
Peter J. Holzer
2024-03-01 19:03:31 UTC
Permalink
Post by Thomas Koenig
Post by Peter J. Holzer
Post by Thomas Koenig
Eine heutige große Firma mit 10 000 Laptops pro Jahr, mit 100
Euro mehr pro Laptop für mehr Speicher zahlt eine Million extra
pro Jahr.
Die hat dann aber auch ca. 50000 Mitarbeiter. Macht unterm Strich 20 €
pro Mitarbeiter und Jahr. Wieviel Arbeitszeit ist das?
Auswechseln von Laptops, die ansonsten in Ordnung sind und "nur"
zu wenig Speicher haben, kostet den Mitarbeiter auch mal gerne
einen halben Tag oder mehr.
Darum sollte man die Laptops gleich ausreichend ausgestattet kaufen. Das
ist sicher billiger als eine spätere Aufrüstung oder die vergeudete
Arbeitszeit.
Post by Thomas Koenig
Bei einer früheren Firma hatte ich mal vorgeschlagen, IT-Probleme
als eigenes Abrechnungselemet anzulegen, damit das Management
sieht, wie die IT sich so auf die Produktivität auswirkt.
Die Reaktion war vohersehbar :-)
Glaube ich ;-). Ich hätte da allerdings auch praktische Bedenken. Die
meisten IT-Probleme äußern sich ja eher niederschwellig: Da wartet man
hier eine Minute und dort fünf Minuten, man muss irgendwas umständlich
machen und braucht dafür 10 Minuten länger als im (hypothetischen)
Idealfall, eine Mail an Support zu schreiben reisst einen aus dem Flow
(und die Antwort zu lesen dann ebenfalls), etc. Das ist schwierig und
aufwendig zu erfassen. Dass jemand eine Stunde am Stück nicht arbeiten
kann, ist eher selten.

Das Problem habe ich ja jetzt schon. Manchmal habe ich 20 Task-Switches
an einem Tag und am Abend keine Ahnung mehr, was ich eigentlich alles
eintragen soll.

(ich hatte mal die Idee, eine Zeiterfassung zu schreiben, die in
zufälligen Abständen aufpoppt und fragt "was machst Du gerade?" Über
einen längeren Zeitraum sollte das dann ein recht realistisches Bild
geben. Aber ich fürchte, das wäre zu lästig.)

hp
Diedrich Ehlerding
2024-03-01 19:26:49 UTC
Permalink
Post by Thomas Koenig
Bei einer früheren Firma hatte ich mal vorgeschlagen, IT-Probleme
als eigenes Abrechnungselemet anzulegen, damit das Management
sieht, wie die IT sich so auf die Produktivität auswirkt.
Die Reaktion war vohersehbar :-)
Ja, das kenne ich. Ich habe mal einen ähnlichen Vorschlag gemacht: die
Zeit für das Bedienen interner Verfahren wie Zeiterfassung (und
Hinterherrennen hinter den entsprechenden Projektnummern, für die man
schon gearbeitet hat, weils ja so dringend war), die
Reisekostenabrechnung usw. einzeln auszuweisen, um die Koste4n dieser
Verfahren transparent zu machen. Aus irgendeinem Grund wollte keiner der
Betreiber dieser Verfahren das unterstützen ...
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Arno Welzel
2024-03-02 19:37:09 UTC
Permalink
Post by Thomas Koenig
Post by Peter J. Holzer
Post by Thomas Koenig
Eine heutige große Firma mit 10 000 Laptops pro Jahr, mit 100
Euro mehr pro Laptop für mehr Speicher zahlt eine Million extra
pro Jahr.
Die hat dann aber auch ca. 50000 Mitarbeiter. Macht unterm Strich 20 €
pro Mitarbeiter und Jahr. Wieviel Arbeitszeit ist das?
Auswechseln von Laptops, die ansonsten in Ordnung sind und "nur"
zu wenig Speicher haben, kostet den Mitarbeiter auch mal gerne
einen halben Tag oder mehr.
In der Firma, wo ich aktuell tätig bin, kostet ein neuer Laptop den
Mitarbeiter ca. 20 Minuten - dann ist die Umgebung wieder komplett so
da, wie er sie braucht.
--
Arno Welzel
https://arnowelzel.de
p***@pocnet.net
2024-02-29 17:20:47 UTC
Permalink
Post by Dennis Grevenstein
Wie kommst Du darauf, wenn Du berechnest, was Dich diese 8GB
Speicher heute kosten im Vergleich zu den 6KB der PDP-8?
Moderne Computer sind technologisch derart fortgeschritten,
dass der ganze bloat und Schrott schlicht eingepreist ist.
Ob Du den code schön findest, ist da schlicht egal ;-)
Es muss nicht mehr eine Rechenaufgabe möglichst effizient
gelöst werden, sondern man kauft für das verfügbare Geld
einfach möglichst viel Zeug. Der Entwickler, der Dir irgendwas
liebevoll handoptimiert, kostet einfach zuviel.
Immer diese Kaufleute. ;-)

Es fühlt sich trotzdem falsch an. :-)
--
:wq! PoC
Dennis Grevenstein
2024-02-29 18:06:43 UTC
Permalink
Post by p***@pocnet.net
Immer diese Kaufleute. ;-)
Es fühlt sich trotzdem falsch an. :-)
wie man das so sagt:
fast, good, cheap: pick any two of them.

alle drei kannst Du nur haben, wenn sich die Technologie so weiter-
entwickelt, dass alles normal wird. Beispiel: Toaster
Kannst Du jetzt irgendwo kaufen gehen, musst Du nicht bestellen
und monatelang warten. Funktioniert gut. Du kannst von einem
Toaster erwarten, dass er Deinen Toast korrekt toastet und
nicht heute verbrennt und morgen ist es noch ganz weiss.
Billig: Es ist so ein Alltagsgegenstand, dass es nicht viel
kostet.
Computer sind mittlerweile näher am Toaster dran, weil sie
zum Alltag dazugehören, aber noch nicht ganz da. Da praktisch
alles in der IT von den drei oben genannten "fast" sein muss
(denn sonst wäre es veraltet bevor es auf dem Markt ist), hat
man also in der Regel nur noch die Wahl zwischen "good" und "cheap".

gruss,
Dennis
--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."
Hermann Riemann
2024-03-01 06:16:03 UTC
Permalink
Post by p***@pocnet.net
Post by Dennis Grevenstein
Wie kommst Du darauf, wenn Du berechnest, was Dich diese 8GB
Speicher heute kosten im Vergleich zu den 6KB der PDP-8?
Moderne Computer sind technologisch derart fortgeschritten,
dass der ganze bloat und Schrott schlicht eingepreist ist.
Ob Du den code schön findest, ist da schlicht egal ;-)
Es muss nicht mehr eine Rechenaufgabe möglichst effizient
gelöst werden, sondern man kauft für das verfügbare Geld
einfach möglichst viel Zeug. Der Entwickler, der Dir irgendwas
liebevoll handoptimiert, kostet einfach zuviel.
Immer diese Kaufleute. ;-)
Es fühlt sich trotzdem falsch an. :-)
Da denke ich jetzt an den Übergang ftp nach sftp.

Bei ftp gibt es ls -lR um nachzuschauen,
welche Dateien und Verzeichnisse anzulegen zu löschen sind.
bei sftp gibt es bei rekursiv nur put -R
was einfach Verzeichnisse anlegt und alle Dateien kopiert.
Löschen würde in Handarbeit ausarten.

Und bei heutigen internet Geschwindigkeiten
sind 10 MB schneller übertragen als eine einzelne
2 k Datei vor vielen Jahren.

Hermann
des öfteren an folgenden Spruch denkend:
"Es gab noch nie soviel ungenutzten Speicherplatz wie heute".
--
<http://www.hermann-riemann.de>
Stefan Möding
2024-03-01 06:55:16 UTC
Permalink
Post by Hermann Riemann
"Es gab noch nie soviel ungenutzten Speicherplatz wie heute".
Muss das nicht

"Es gab noch nie soviel unnütz verbrauchten Speicherplatz wie heute"

heißen?
--
Stefan
Hermann Riemann
2024-03-01 10:56:00 UTC
Permalink
Post by Stefan Möding
Post by Hermann Riemann
"Es gab noch nie soviel ungenutzten Speicherplatz wie heute".
Muss das nicht
"Es gab noch nie soviel unnütz verbrauchten Speicherplatz wie heute"
heißen?
Nein, da gibt es einen wesentlichen Unterschied.

Ungenutzter Speicherplatz ist der Speicherplatz,
den man noch verwenden könnte.

Unnütz verbrauchter Speicherplatz wird z.B.
für Programme belegt, die nicht verwendet werden,
oder diverser Werbung.
--
<http://www.hermann-riemann.de>
Andreas Kohlbach
2024-03-01 19:35:20 UTC
Permalink
Post by Hermann Riemann
Da denke ich jetzt an den Übergang ftp nach sftp.
Bei ftp gibt es ls -lR um nachzuschauen,
welche Dateien und Verzeichnisse anzulegen zu löschen sind.
-lR?

lftp zumindest listet dann scheinbar alle lokalen Dateien auf.
Post by Hermann Riemann
bei sftp gibt es bei rekursiv nur put -R
was einfach Verzeichnisse anlegt und alle Dateien kopiert.
Löschen würde in Handarbeit ausarten.
Versuche vielleicht lftp. Das scheint von den Kommando-Optionen ähnlich
sftp zu sein. Es beachtet, wie ftp auch, zudem die ~/.netrc, falls Du die
nutzt.

lftp sftp://...
--
Andreas
Arno Welzel
2024-03-02 19:38:29 UTC
Permalink
Post by Hermann Riemann
Post by p***@pocnet.net
Post by Dennis Grevenstein
Wie kommst Du darauf, wenn Du berechnest, was Dich diese 8GB
Speicher heute kosten im Vergleich zu den 6KB der PDP-8?
Moderne Computer sind technologisch derart fortgeschritten,
dass der ganze bloat und Schrott schlicht eingepreist ist.
Ob Du den code schön findest, ist da schlicht egal ;-)
Es muss nicht mehr eine Rechenaufgabe möglichst effizient
gelöst werden, sondern man kauft für das verfügbare Geld
einfach möglichst viel Zeug. Der Entwickler, der Dir irgendwas
liebevoll handoptimiert, kostet einfach zuviel.
Immer diese Kaufleute. ;-)
Es fühlt sich trotzdem falsch an. :-)
Da denke ich jetzt an den Übergang ftp nach sftp.
Bei ftp gibt es ls -lR um nachzuschauen,
welche Dateien und Verzeichnisse anzulegen zu löschen sind.
bei sftp gibt es bei rekursiv nur put -R
was einfach Verzeichnisse anlegt und alle Dateien kopiert.
Löschen würde in Handarbeit ausarten.
Deswegen nimmt man halt gleich SSH und scp ;-)
--
Arno Welzel
https://arnowelzel.de
p***@pocnet.net
2024-02-29 17:16:33 UTC
Permalink
Post by Thomas Koenig
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Yap.
Post by Thomas Koenig
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb interaktiv zu
gebrauchen.
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt (wobei ich
Kernighans "History and a Memoir" gerade nicht dabei habe, um die Zahl
nochmal zu checken), Über 64 kb Speicherbereich pro Prozess kamen sie auf
jeden Fall nicht raus.
Naja, aber das war etliche Jahre früher als 1994! Und, die Frage ist auch,
wie gut die Maschine für andere Benutzer noch brauchbar war, während der
Compiler lief und auch hier sicherlich einiges an Disk I/O verursachte. OS/400
beherrscht das Kunststück, Antwortzeiten auch auf einer beschäftigten Maschine
niedrig zu halten recht gut. Solange noch "Luft" ist und die Disks noch nicht
am Anschlag sind mit Kopfschütteln.
Post by Thomas Koenig
8 MB für einen Midrange-Rechner von 1994 reicht kaum mehr aus.
Ja, wobei das schon viel besser war als zu S/38 Zeiten Ende der 1970er. Das
was Java als "läuft überall durch Zwischencode" macht, mach(t)en diese
Plattformen schon damals. Dass diese Abstraktion mehr Speicher braucht,
wundert mich nicht so sehr.
Post by Thomas Koenig
Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu gebrauchen. Wir
machen gerade massiv was falsch, glaube ich...
Das sehe ich ähnlich.
... hatte. :-) Ruht momentan, weil ein Tag dummerweise nur 24 Stunden hat.
;-)
Post by Thomas Koenig
Ein paar Bemerkungen in https://www.garlic.com/~lynn/2024.html#50 sollten
sehr interessant sein, nimm das mal als Startpunkt.
Danke, gebuchmarkt.
Post by Thomas Koenig
U.a. ist da ein Memo zu Future Systems verlinkt, das wohl mitgholfen hat,
dem Projekt den Todesstoß zu geben,
http://www.jfsowa.com/computer/memo125.htm .
Ja, das ist mir aus anderen Quellen bekannt. Ich kann mich aber nicht mehr
erinnern, wo ich das aufgeschnappt habe.
Post by Thomas Koenig
Zitat: "In 1973, I had attended a presentation on the design of the
VANDERBILT hardware. After showing a diagram of the CPU frame, which
contained sixteen circuit boards, the presenter proudly said "Each of these
boards contains as much circuitry as a System/370, Model 168." At that
point, I asked the obvious question: "But the expected performance is only
about three times faster than a Model 168. Why don't you just build sixteen
168s?" Instead of answering, he just glared at me."
An den Abschnitt kann ich mich auch erinnern. :-D
--
:wq! PoC
Hermann Riemann
2024-03-01 06:32:00 UTC
Permalink
Post by p***@pocnet.net
Naja, aber das war etliche Jahre früher als 1994! Und, die Frage ist auch,
wie gut die Maschine für andere Benutzer noch brauchbar war, während der
Compiler lief und auch hier sicherlich einiges an Disk I/O verursachte. OS/400
beherrscht das Kunststück, Antwortzeiten auch auf einer beschäftigten Maschine
niedrig zu halten recht gut. Solange noch "Luft" ist und die Disks noch nicht
am Anschlag sind mit Kopfschütteln.
Die Sinix Kiste MX2? konnte das nicht.
Die Antwortzeiten beim Editieren waren gut,
bis ein Kollege anfing, den C-Compiler zu verwenden.
Post by p***@pocnet.net
Post by Thomas Koenig
Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu gebrauchen. Wir
machen gerade massiv was falsch, glaube ich...
Das sehe ich ähnlich.
Mein erster verwendeter PC mit Fenster hatte 8 MB.
Für was werden 8 GB gebraucht?
Peter J. Holzer
2024-02-29 19:10:26 UTC
Permalink
Post by Thomas Koenig
Post by p***@pocnet.net
Eine AS/400 9401-P02 von 1994 mit arg knappen 8MB RAM rödelt bei jedem
Tastendruck auf den Platten rum, auch wenn man "nur" z. B. im Hilfetext einen
Screen runterscrollt. Jedesmal 2-3 Sekunden warten wird dann schnell zum
Geduldsspiel. Mit der doppelten Menge RAM ist das schon erheblich
entspannter, da ist die Geschwindigkeit von 19200 bps für die SDLC-Anbindung
der Engpass. Scrollen geht dann aber grob im Sekundentakt.
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.
Ja, aber wozu? Stimmt schon, dass ein Computer mit 8 GB nicht eine
Million mal nützlicher ist als damals einer mit 8 kB. Aber prinzipiell
war an viele Dinge, die wir heute machen, damals noch nicht einmal zu
denken.
Post by Thomas Koenig
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken),
Das scheint mir sehr unwahrscheinlich zu sein. Im Unix-Paper von 1974
geben sie die Hardware-Ausstattung "ihrer" PDP-11 mit 768 kB RAM und 2
200 MB Harddisks an. Als Minimalausstattung nennen sie 96 kB RAM.
Das war schon die C-Version von Unix. Möglicherweise war das nicht mehr
die ursprüngliche PDP-11 oder sie ist upgegradet worden, aber der Sprung
von 16 kB auf 768 kB erscheint mir zu groß. Vielleicht hatte die PDP-7,
auf der die erste Version von Unix gelaufen ist, 16 kWorte.
Post by Thomas Koenig
Über 64 kb Speicherbereich
pro Prozess kamen sie auf jeden Fall nicht raus.
Jein. Manche PDP-Modelle konnten Split-I&D. Man hatte also bis zu 64 kB
Programm und 64 kB Daten. Das war auch noch bei der 16-Bit-Version von
Minix ca. 1990 so. Generell waren Unix-Programme eher klein. Man konnte
ja mehrere davon mit einer Pipe verbinden ;-).

hp
Christian Corti
2024-03-01 08:20:57 UTC
Permalink
Post by Peter J. Holzer
Post by Thomas Koenig
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken),
Das scheint mir sehr unwahrscheinlich zu sein. Im Unix-Paper von 1974
geben sie die Hardware-Ausstattung "ihrer" PDP-11 mit 768 kB RAM und 2
200 MB Harddisks an. Als Minimalausstattung nennen sie 96 kB RAM.
Das war schon die C-Version von Unix. Möglicherweise war das nicht mehr
Um mehr als 256 kB (abzgl. I/O-Bereich) zu adressieren, braucht man eine
22-Bit CPU. Die gab es damals nur bei dem PDP-11/70. Und der kam erst
1975 raus. Also ist dein UNIX-Paper falsch.
Die Jungs hatten anfangs einen PDP-11/20, und obwohl für 18 Bit vorbereitet,
war die MMU hierfür (KT11-B) vermutlich nicht vorhanden. Also hatte die CPU
nur max. 56 kB (die restlichen 8 kB waren I/O-Page), und kein Separate
I/D, und keinen Speicherschutz usw. Auch lief das System mit einer
Festkopfplatte (RF11) und RK05. Wir bewegen uns hier im einstelligen
MB-Bereich.

Ich zitiere einfach mal auf dem richtigen UNIX-Paper von den Jungs, "The
UNIX Time-Sharing System" von 1974:
"
There have been three versions of UNIX. The earliest version (circa
1969-70) ran on the Digital Equipment Corporation PDP-7 and -9
computers. The second version ran on the unprotected PDP-11/20 computer.
This paper describes only the PDP-11/40 and /45 [l] system since it is
more modern and many of the differences between it and older UNIX
systems result from redesign of features found to be deficient or
lacking.
[...]
The PDP-11/45 on which our UNIX installation is implemented is a
16-bit word (8-bit byte) computer with 144K bytes of core memory; UNIX
occupies 42K bytes.
[...]
The PDP-11 has a 1M byte fixed-head disk [RF11], used for file system
storage and swapping, four moving-head disk drives which each provide
2.5M bytes [RK05] on removable disk cartridges, and a single
moving-head disk drive which uses removable 40M byte disk packs [verm. RP03]
"

Der 11/40 war eine Non-Split CPU (insg. 64 kB für Code+Daten), der
11/45 hatte Separate I/D (jeweils 64 kB für Code und Daten) sowie
Kernel und User Mode. Bei beiden war bei 248 kB RAM definitiv Schluß.

Christian
p***@pocnet.net
2024-03-01 10:01:03 UTC
Permalink
Post by Christian Corti
Um mehr als 256 kB (abzgl. I/O-Bereich) zu adressieren, braucht man eine
22-Bit CPU. Die gab es damals nur bei dem PDP-11/70. Und der kam erst
1975 raus. Also ist dein UNIX-Paper falsch.
Mutige Behauptung. Ich schmeisse mal den Begriff "Bankswitching" in den Raum,
ohne jetzt recherchiert zu haben, ob das damals schon eine bekannte oder gar
benutzte Technik war.
--
:wq! PoC
Christian Corti
2024-03-01 12:28:22 UTC
Permalink
Post by p***@pocnet.net
Post by Christian Corti
Um mehr als 256 kB (abzgl. I/O-Bereich) zu adressieren, braucht man eine
22-Bit CPU. Die gab es damals nur bei dem PDP-11/70. Und der kam erst
1975 raus. Also ist dein UNIX-Paper falsch.
Mutige Behauptung. Ich schmeisse mal den Begriff "Bankswitching" in den Raum,
ohne jetzt recherchiert zu haben, ob das damals schon eine bekannte oder gar
benutzte Technik war.
Sehr eindeutig hast du gezeigt, dass du PDP-11en nicht kennst ;-))))

Christian
p***@pocnet.net
2024-03-01 16:38:20 UTC
Permalink
Post by Christian Corti
Post by p***@pocnet.net
Mutige Behauptung. Ich schmeisse mal den Begriff "Bankswitching" in den
Raum, ohne jetzt recherchiert zu haben, ob das damals schon eine bekannte
oder gar benutzte Technik war.
Sehr eindeutig hast du gezeigt, dass du PDP-11en nicht kennst ;-))))
Da hast Du absolut recht. Das war auch nicht mein Anspruch. :-)

Mein Punkt ist: Alleine aus den vorhandenen Adressleitungen einer CPU
abzuleiten wieviel Speicher ein gegebenes System unterstützt kann zu einem
falschen Ergebnis führen.
--
:wq! PoC
Andreas Kohlbach
2024-03-01 19:49:32 UTC
Permalink
Post by p***@pocnet.net
Post by Christian Corti
Post by p***@pocnet.net
Mutige Behauptung. Ich schmeisse mal den Begriff "Bankswitching" in den
Raum, ohne jetzt recherchiert zu haben, ob das damals schon eine bekannte
oder gar benutzte Technik war.
Sehr eindeutig hast du gezeigt, dass du PDP-11en nicht kennst ;-))))
Da hast Du absolut recht. Das war auch nicht mein Anspruch. :-)
Mein Punkt ist: Alleine aus den vorhandenen Adressleitungen einer CPU
abzuleiten wieviel Speicher ein gegebenes System unterstützt kann zu einem
falschen Ergebnis führen.
Bankswitching scheint mir mehr ein Hack zu sein.

Da gab es den Memotech MTX 512
<https://de.wikipedia.org/wiki/Memotech_MTX> mit 128 KB RAM (wie auch der
Commodore 128). Sexy Rechner, aber leider ein Flop. Der konnte mit
seiner Z80 aber eben auch nur 64 KB adressieren.
--
Andreas
p***@pocnet.net
2024-03-02 11:36:14 UTC
Permalink
Post by Andreas Kohlbach
Post by p***@pocnet.net
Mein Punkt ist: Alleine aus den vorhandenen Adressleitungen einer CPU
abzuleiten wieviel Speicher ein gegebenes System unterstützt kann zu einem
falschen Ergebnis führen.
Bankswitching scheint mir mehr ein Hack zu sein.
Das spielt im Kontext IMHO keine Rolle. Wurde ja auch auf den 8-Bit BASIC
Plattformen streckenweise benutzt. Was beweist das? Dass es geht. Ob es toll
ist oder nicht steht auf einem anderen Blatt.
--
:wq! PoC
Arno Welzel
2024-03-02 19:43:54 UTC
Permalink
Post by Andreas Kohlbach
Post by p***@pocnet.net
Post by Christian Corti
Post by p***@pocnet.net
Mutige Behauptung. Ich schmeisse mal den Begriff "Bankswitching" in den
Raum, ohne jetzt recherchiert zu haben, ob das damals schon eine bekannte
oder gar benutzte Technik war.
Sehr eindeutig hast du gezeigt, dass du PDP-11en nicht kennst ;-))))
Da hast Du absolut recht. Das war auch nicht mein Anspruch. :-)
Mein Punkt ist: Alleine aus den vorhandenen Adressleitungen einer CPU
abzuleiten wieviel Speicher ein gegebenes System unterstützt kann zu einem
falschen Ergebnis führen.
Bankswitching scheint mir mehr ein Hack zu sein.
Der war aber nicht so selten. Atari 130 XE hatte auch eine 6502 mit 16
Bit Adressbus aber 128 KB RAM und zusätzlich ROM. Die CPU konnte nur 64
KB direkt adressieren, der Rest wurde mit Bankswitching gelöst.

Mein erster 6502-Assembler für 8-Bit-Ataris nutze auch das RAM hinter
dem ROM, was per Bankswitching auch bei den kleineren Maschinen (600XL,
800XL) nutzbar war ;-)
--
Arno Welzel
https://arnowelzel.de
Peter J. Holzer
2024-03-01 19:34:55 UTC
Permalink
Post by Christian Corti
Post by Peter J. Holzer
Post by Thomas Koenig
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken),
Das scheint mir sehr unwahrscheinlich zu sein. Im Unix-Paper von 1974
geben sie die Hardware-Ausstattung "ihrer" PDP-11 mit 768 kB RAM und 2
200 MB Harddisks an. Als Minimalausstattung nennen sie 96 kB RAM.
Das war schon die C-Version von Unix. Möglicherweise war das nicht mehr
Um mehr als 256 kB (abzgl. I/O-Bereich) zu adressieren, braucht man eine
22-Bit CPU. Die gab es damals nur bei dem PDP-11/70. Und der kam erst
1975 raus. Also ist dein UNIX-Paper falsch.
Das Paper ist sicher nicht falsch (es ist von Ritchie und Thompson),
aber vermutlich das Datum.
Post by Christian Corti
Die Jungs hatten anfangs einen PDP-11/20, und obwohl für 18 Bit vorbereitet,
war die MMU hierfür (KT11-B) vermutlich nicht vorhanden. Also hatte die CPU
nur max. 56 kB (die restlichen 8 kB waren I/O-Page), und kein Separate
I/D, und keinen Speicherschutz usw. Auch lief das System mit einer
Festkopfplatte (RF11) und RK05. Wir bewegen uns hier im einstelligen
MB-Bereich.
Ich zitiere einfach mal auf dem richtigen UNIX-Paper von den Jungs, "The
"
There have been three versions of UNIX.
Und in der Version des Papers, auf die ich mich bezogen habe, steht hier
"There have been four versions of the UNIX time-sharing system."

Daraus sollte man schließen können, dass sich die in CACM 17, No. 7
(July 1974) erschienene Version des Papers auf 3rd Edition Unix bezieht
und die überarbeitete Version auf 4th Edition. Das schlägt sich aber
damit, dass 4th Edition die erste in C geschriebene Version war und die
ist dieser Rewrite hat im Sommer 1973 stattgefunden und wird auch
bereits in der CACM-Version des Papers erwähnt. Offenbar zählen Ritchie
und Thompson anders als die Manual-Autoren ;-)

Bei genauerem Durchlesen des Papers würde ich sagen, dass das zumindest
1978 noch einmal überarbeitet wurde: Im Literaturverzeichnis sind
mehrere Quellen mit Erscheinungsjahr 1978 angegeben, außerdem wird
Fortran 77 erwähnt.

hp
Marcel Mueller
2024-02-29 20:53:08 UTC
Permalink
Post by Thomas Koenig
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
(wobei ich Kernighans "History and a Memoir" gerade nicht dabei
habe, um die Zahl nochmal zu checken), Über 64 kb Speicherbereich
pro Prozess kamen sie auf jeden Fall nicht raus.
Das ist so. Wir hatten damals eine 2200 SVP. Die hatte auch nur 64k. Das
hat schon für mehr als einen User (Terminal) gereicht.
Post by Thomas Koenig
8 MB für einen Midrange-Rechner von 1994 reicht kaum mehr aus.
Nicht andeutungsweise. Ich hatte im 486er Desktop schon 16 und später 32
MB. Und das war mit der wichtigste Grund, warum der regelmäßig Pentiums
rechts überholt hat.

Für Server hat man Mitte der 90-er eher mit mindestens 32-64MB
kalkuliert. Netware 3.12 ging vielleicht noch mit weniger.
Post by Thomas Koenig
Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu
gebrauchen. Wir machen gerade massiv was falsch, glaube ich...
Naja, die Anforderungen (nicht zuletzt an die Sicherheit) haben sich
auch deutlich erhöht.

Und natürlich erhöht auch der Wechsel zu 64 Bit Software den
Speicherbedarf um grob 30-50%. Bei 16->32 war das ähnlich.

Aber ja, da wird auch viel gehaust. Üblicherweise hört der Entwickler
dann auf zu optimieren, wenn seine Software den gut ausgestatteten
Entwicklungsrechner nicht mehr lahm legt. Glücklicherweise haben die
Kunden später beim Einsatz dann schon die eins schnellere
Rechnergeneration. ;-)


Marcel
Kay Martinen
2024-03-01 21:49:46 UTC
Permalink
Post by Thomas Koenig
Post by p***@pocnet.net
Eine AS/400 9401-P02 von 1994 mit arg knappen 8MB RAM rödelt bei jedem
Tastendruck auf den Platten rum, auch wenn man "nur" z. B. im Hilfetext einen
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
Wow. Wo ich das hier lese denke ich so... Ist irgendwie schade das
niemand ein Mehrbenutzer System entwickelte... für den VC-20! Der hatte
3,5kB Im Grundausbau, ich hatte mehrere 8k und ein 16k RAM Modul dafür
und sogar ein Gehäuse mit Expansion-Bus. Wo ein IEEE-488 Modul und mehr
rein passte da würde auch ein Selbst entwickeltes Multi-Seriell Modul
rein passen können. ;-) Also technisch nicht so weit voneinander
entfernt oder?
Post by Thomas Koenig
8 MB für einen Midrange-Rechner von 1994 reicht kaum mehr aus.
Ich denke zu der Zeit hätte man das schon auf PC's haben können.
Post by Thomas Koenig
Und heute ist ein Windows-10-Rechner mit 8 GB kaum mehr zu
gebrauchen. Wir machen gerade massiv was falsch, glaube ich...
Definitiv. Aber wie bekommt man es hin das alle Programmierer und ihre
Entscheider nicht mehr den "Immer schneller, Größer" Wurm füttern
sondern genau das gegenteil? Also auch die Qualität vor die Quantität zu
setzen und Eingeführtes und Funktionierendes nicht einfach deshalb nicht
mehr Patchen weil man lieber mit was neuem schnell mehr Geld verdienen
könnte oder will.

Closed Source bringt zwar eigene Pfründe, verhindert aber auch Einblick
dritter.
Open Source allein nützt auch nichts wenn nicht genug leute in den Code
schauen (Siehe Heartbleed)

Und Programmieren als Liebhaberei/Hobby hilft auch nix wenn der Hobbyist
das was eigentlich nötig wäre nicht umsetzen will. Wer könnt's ihm
verdenken.

Gibt's überhaupt so was wie Common Source? Etwas das jeder braucht,
jeder weiter entwickeln will, jeder auch Lücken finden will, diese
Schließen will und... man damit am Ende doch noch irgendwie
kostendeckend arbeiten könnte...


Bye/
/Kay
--
nix
Andreas Kohlbach
2024-03-03 02:03:42 UTC
Permalink
Post by Kay Martinen
Post by Thomas Koenig
Post by p***@pocnet.net
Eine AS/400 9401-P02 von 1994 mit arg knappen 8MB RAM rödelt bei jedem
Tastendruck auf den Platten rum, auch wenn man "nur" z. B. im Hilfetext einen
Das ist schon erstaunlich, wie wir heute Speicher verschwenden.
Die PDP-8 hatte 4 kWorte (6 kb), die erste Nova war ab 8 kb
interaktiv zu gebrauchen.
UNIX wurde anfangs auf einer PDP-11 mit 16 KB entwickelt
Wow. Wo ich das hier lese denke ich so... Ist irgendwie schade das
niemand ein Mehrbenutzer System entwickelte... für den VC-20! Der
hatte 3,5kB Im Grundausbau, ich hatte mehrere 8k und ein 16k RAM Modul
dafür und sogar ein Gehäuse mit Expansion-Bus. Wo ein IEEE-488 Modul
und mehr rein passte da würde auch ein Selbst entwickeltes
Multi-Seriell Modul rein passen können. ;-) Also technisch nicht so
weit voneinander entfernt oder?
Für den Commodore 64 gibt es ein Linux. Mit IIRC Multi-User und
(eingeschränktes) Preemptives Multitasking.

https://de.wikipedia.org/wiki/LUnix

Laut dieser Seite soll es eine umfangreichere Version für den C128 geben.

Konnte ich leider nie im Emulator zum Laufen bringen. Einen richtigen C64
besitze ich nicht mehr.
--
Andreas

https://ankman.de/
Peter J. Holzer
2024-02-29 18:41:24 UTC
Permalink
Post by p***@pocnet.net
Post by Thomas Koenig
Auf DEC-Maschinen hingegen wurde jeder Tastendruck einzeln geschickt
und auch quittiert, wie wir es heute kennen.
Yap. Mit den entsprechenden Wirkungen auf die CPU: Dauernd Unterbrechungen.
Post by Thomas Koenig
Und auf deren Hardware konnte man auf einer PDP-8, so ziemlich der
schwachbrüstigsten Maschine, die man noch als Computer bezeichnen kann,
unter TSS/8 bis zu 16 Benutzer bedienen, und das anscheinend mit (damals)
akzeptablen Antwortzeiten.
Was war denn "akzeptabel" aus damaliger Sicht?
Das vorher getippte Zeichen sollte angezeigt werden, bevor man das
nächste tippt.
Post by p***@pocnet.net
Und, es kommt ja auch immer drauf an was man macht. Aus heutiger Sicht
mehr als eine Sekunde auf die Ausgabe einer Manpage warten zu müssen
ist schon einigermaßen ungewohnt. Auf dem 386 mit 20 MHz und Debian 2
gehen da doch einige Sekunden ins Land.
Andere Baustelle. Das wird ein (relativ aufwendiges) Kommando ausgeführt
und du bekommst das Ergebnis zurück. Das wäre bei einem block-
orientierten Terminal auch so. Der Knackpunkt bei zeichen-orientierten
Terminals ist, dass sehr einfache Operationen (z.B. ein Zeichen in den
Zeilenpuffer einfügen oder - deutlich aufwendiger - im Editor in den
Text einfügen) in Bruchteilen einer Sekunde erledigt werden müssen.

Abgesehen davon: Ein 386/20 war zu der Zeit, als Debian 2 aktuell war,
schon ziemlich angejahrt. Man-Pages wurden auf Unix-Systemen, mit denen
ich Ende der 80er-Jahre zu tun hatte, gecacht, denn das Formatieren
einer Man-Page mittels nroff konnte schon einige Zeit dauern. Kann sein,
dass das in Debian 2 nicht mehr gemacht wurde, weil es auf damals
halbwegs aktueller Hardware (also was ein typischer Nerd so zuhause
hatte, wahrscheinlich ein Pentium, vielleicht schon ein Pentium II)
schnell genug war, dass man sich die Security-Probleme mit dem Cache
nicht einhandeln wollte.

hp
p***@pocnet.net
2024-02-29 21:25:47 UTC
Permalink
Post by p***@pocnet.net
Was war denn "akzeptabel" aus damaliger Sicht?
Das vorher getippte Zeichen sollte angezeigt werden, bevor man das nächste
tippt.
Ahahaha, das schafft ja manchmal nicht mal Word auf aktueller Hardware! :-D

Aber ja, guter Punkt für VT100 basierte terminals. Da "tippen" bei 3270 und
5250 aber im Regelfall lokal bleibt, fällt es mir schwer, da einen brauchbaren
Vergleich zu ziehen.
Post by p***@pocnet.net
Und, es kommt ja auch immer drauf an was man macht. Aus heutiger Sicht
mehr als eine Sekunde auf die Ausgabe einer Manpage warten zu müssen
ist schon einigermaßen ungewohnt. Auf dem 386 mit 20 MHz und Debian 2
gehen da doch einige Sekunden ins Land.
Andere Baustelle. Das wird ein (relativ aufwendiges) Kommando ausgeführt
und du bekommst das Ergebnis zurück. Das wäre bei einem block-
orientierten Terminal auch so.
Ja. Das ist aber auch der einzige Punkt wo die Plattformen annäherend
vergleichbar werden. Siehe oben.
Abgesehen davon: Ein 386/20 war zu der Zeit, als Debian 2 aktuell war, schon
ziemlich angejahrt.
So genau habe ich dann nicht recherchiert. :-) Ich wage aber zu bezweifeln,
dass ältere Kernel- und Libc-Versionen diesbezüglich viel an Performance
rausreißen.
Man-Pages wurden auf Unix-Systemen, mit denen ich Ende der 80er-Jahre zu tun
hatte, gecacht, denn das Formatieren einer Man-Page mittels nroff konnte
schon einige Zeit dauern.
Ich weiss. Das war ein Beispiel von "kann länger dauern und wird im Alltag
durchaus immer mal wieder gebraucht".
Kann sein, dass das in Debian 2 nicht mehr gemacht wurde, weil es auf damals
halbwegs aktueller Hardware (also was ein typischer Nerd so zuhause hatte,
wahrscheinlich ein Pentium, vielleicht schon ein Pentium II) schnell genug
war, dass man sich die Security-Probleme mit dem Cache nicht einhandeln
wollte.
Ganz ehrlich: Ich weiss es nicht auswendig und müsste es nachschauen. Aber so
wichtig isses mir dann doch nicht. Mir ging es eher ums Prinzip, dass es Dinge
gibt die länger dauern und andere die weniger lang dauern im Vergleich zu
ähnlich alten Maschinen in der blockorientierten Welt. Weniger um den
*genauen* Vorgang.
--
:wq! PoC
Peter J. Holzer
2024-02-29 22:54:54 UTC
Permalink
Post by p***@pocnet.net
Post by p***@pocnet.net
Was war denn "akzeptabel" aus damaliger Sicht?
Das vorher getippte Zeichen sollte angezeigt werden, bevor man das nächste
tippt.
Ahahaha, das schafft ja manchmal nicht mal Word auf aktueller Hardware! :-D
Du hast von "akzeptabel" geschrieben. Seit wann fällt Word in diese
Kategorie? ;-)
Post by p***@pocnet.net
Post by p***@pocnet.net
Und, es kommt ja auch immer drauf an was man macht. Aus heutiger Sicht
mehr als eine Sekunde auf die Ausgabe einer Manpage warten zu müssen
ist schon einigermaßen ungewohnt. Auf dem 386 mit 20 MHz und Debian 2
gehen da doch einige Sekunden ins Land.
[...]
Post by p***@pocnet.net
Man-Pages wurden auf Unix-Systemen, mit denen ich Ende der 80er-Jahre zu tun
hatte, gecacht, denn das Formatieren einer Man-Page mittels nroff konnte
schon einige Zeit dauern.
Ich weiss. Das war ein Beispiel von "kann länger dauern und wird im Alltag
durchaus immer mal wieder gebraucht".
Und eben weil man das oft braucht und sich die Man-Pages nicht so oft
ändern, wurden die gecacht. Dadurch hat es (außer beim allerersten
Aufruf einer Man-Page nach der Installation) eben nicht gedauert,
sondern die Man-Page war sofort da.

hp
p***@pocnet.net
2024-02-29 23:53:09 UTC
Permalink
Post by Peter J. Holzer
Post by p***@pocnet.net
Ahahaha, das schafft ja manchmal nicht mal Word auf aktueller Hardware! :-D
Du hast von "akzeptabel" geschrieben. Seit wann fällt Word in diese
Kategorie? ;-)
Guter Einwand. Wobei Word auf mehrere Art und Weise inakzeptabel ist. ;-)
--
:wq! PoC
Marcel Mueller
2024-02-29 05:57:29 UTC
Permalink
Post by Thomas Koenig
Post by p***@pocnet.net
Da habe ich keine persönliche Vergleichsmöglichkeit. Aber es ist
beeindruckend, wieviele Terminals die wirklich großen Mainframe-Installationen
bei Fluglinien und Banken mit doch arg begrenzten Ressourcen bedient haben
(sollen). Ob vergleichbare Anzahlen in der VT100-Welt wirklich möglich waren?
Wahrscheinlich eher nicht. Die 3270-Terminals sind/waren ja auf
Blockbetrieb ausgerichtet. Der Benutzer schreibt eine Zeile
oder einen Bildschirm voll, dann werden alle Daten auf einmal
rübergeschickt. Habe selber noch mit solchen Terminals gearbeitet :-)
Kenne nur die Emulatoren.
Aber kennt jemand noch Tandem NSK, wo man im Betrieb (unangekündigt) die
CPUs raus reißen konnte? Die bediente man auch über 3270.


Marcel
Thomas Koenig
2024-02-29 09:07:24 UTC
Permalink
Post by Marcel Mueller
Post by Thomas Koenig
Post by p***@pocnet.net
Da habe ich keine persönliche Vergleichsmöglichkeit. Aber es ist
beeindruckend, wieviele Terminals die wirklich großen Mainframe-Installationen
bei Fluglinien und Banken mit doch arg begrenzten Ressourcen bedient haben
(sollen). Ob vergleichbare Anzahlen in der VT100-Welt wirklich möglich waren?
Wahrscheinlich eher nicht. Die 3270-Terminals sind/waren ja auf
Blockbetrieb ausgerichtet. Der Benutzer schreibt eine Zeile
oder einen Bildschirm voll, dann werden alle Daten auf einmal
rübergeschickt. Habe selber noch mit solchen Terminals gearbeitet :-)
Kenne nur die Emulatoren.
Aber kennt jemand noch Tandem NSK, wo man im Betrieb (unangekündigt) die
CPUs raus reißen konnte? Die bediente man auch über 3270.
Das geht mit den heutigen IBM-Mainframes immer noch, soweit ich
gehört habe. Die machen dann RAID mit ihren Caches und
andere Dinge.

Disclaimer: Der letzte Mainframe, auf dem ich garbeitet habe,
war ein Vektorrechner in den Mitte-90ern.
Andreas Eder
2024-03-02 14:02:08 UTC
Permalink
Post by Marcel Mueller
Post by p***@pocnet.net
Da habe ich keine persönliche Vergleichsmöglichkeit. Aber es ist
beeindruckend, wieviele Terminals die wirklich großen Mainframe-Installationen
bei Fluglinien und Banken mit doch arg begrenzten Ressourcen bedient haben
(sollen). Ob vergleichbare Anzahlen in der VT100-Welt wirklich möglich waren?
Wahrscheinlich eher nicht. Die 3270-Terminals sind/waren ja auf
Blockbetrieb ausgerichtet. Der Benutzer schreibt eine Zeile
oder einen Bildschirm voll, dann werden alle Daten auf einmal
rübergeschickt. Habe selber noch mit solchen Terminals gearbeitet :-)
Kenne nur die Emulatoren.
Aber kennt jemand noch Tandem NSK, wo man im Betrieb (unangekündigt) die
CPUs raus reißen konnte? Die bediente man auch über 3270.
Ja, waren geile Maschinen.

'Andreas
--
ceterum censeo redmondinem esse delendam
Andreas Kohlbach
2024-02-29 01:32:23 UTC
Permalink
Post by p***@pocnet.net
[eine wunderschöne Zusammenfassung]
sondern auch das Konzept einer kompatiblen Rechnerreihe eingeführt, dass man
Software einfach mitnehmen kann von einem Rechner auf den anderen. Das war
damals wirklich was ganz Neues, den Einfluss kann man kaum überschätzen.
Yap. Einen schwachen Abklatsch der Folgen von "nicht mitnehmen" gab es dann
etliche Jahre später wieder mit den untereinander inkompatiblen BASIC
Varianten der 8-Bit Plattformen.
Kann man die verschiedenen BASICs nicht als Dialekte ansehen?

In den späten 70ern bis Mitte der 80er war fast alles von
Microsoft. Während der Kern (GOTO und so ;-) überall war, war eines
umfangreicher als ein anderes. So war das für den Commodore 64 kastriert,
während das für den Commodore 128 vom Umfang her ordentlich war (dafür
schnarchlangsam).

M$ brachte selbst für *einen* Computer verschiedene BASICs raus.

Gerade schaue ich durch die Osborne Software Suite. Dort finden sich
MBASIC und CBASIC. Müsste beides von M$ sein.
--
Andreas
p***@pocnet.net
2024-02-29 17:26:36 UTC
Permalink
Post by Andreas Kohlbach
Post by p***@pocnet.net
Einen schwachen Abklatsch der Folgen von "nicht mitnehmen" gab es dann
etliche Jahre später wieder mit den untereinander inkompatiblen BASIC
Varianten der 8-Bit Plattformen.
Kann man die verschiedenen BASICs nicht als Dialekte ansehen?
Spielt die genaue Definition überhaupt eine Rolle?

Unterm Strich war es ziemlich oft nicht möglich, ein gegebenes Programm von
Rechner A (in Textform!) zu Rechner B zu transferieren und einfach laufen zu
lassen.

Ich erinnere mich an ein Hilfsprogramm (in BASIC!) in älteren c't-Heften
(198x), die für alle möglichen 8-Bit-Kisten eine Kopierroutine auf Datasette
implementierten, damit man gesicherte Daten auf einer anderen Plattform
"verwenden" konnte. Da stand stets dabei, bloß weil man den rohen Text des
BASIC Programms einlesen kann heißt das noch lange nicht, dass es ohne
Nacharbeiten läuft.
--
:wq! PoC
Andreas Kohlbach
2024-03-01 01:28:56 UTC
Permalink
Post by p***@pocnet.net
Post by Andreas Kohlbach
Post by p***@pocnet.net
Einen schwachen Abklatsch der Folgen von "nicht mitnehmen" gab es dann
etliche Jahre später wieder mit den untereinander inkompatiblen BASIC
Varianten der 8-Bit Plattformen.
Kann man die verschiedenen BASICs nicht als Dialekte ansehen?
Spielt die genaue Definition überhaupt eine Rolle?
Wäre schön definieren zu können, was der "Kern" eines BASICs haben soll,
dürfte aber unmöglich sein.
Post by p***@pocnet.net
Unterm Strich war es ziemlich oft nicht möglich, ein gegebenes Programm von
Rechner A (in Textform!) zu Rechner B zu transferieren und einfach laufen zu
lassen.
Dazu hatte ich mal ein einfaches Programm mit einer verschachtelten
FOR-NEXT-Schleife, einem GOTO (muss jedes gute BASIC Programm haben ;-)
und etwas Mathe geschrieben. Das lief (im Emulator) auf dem C64, C128,
Osborne 1, CPC 646, BBC Micro und Kaypro. Wäre vermutlich auf vielen
anderen auch gelaufen.

Es waren aber eben keine POKES oder Grafikbefehle drin.

<https://de.wikipedia.org/wiki/Liste_von_BASIC-Dialekten> dürfte eher
verwirren statt helfen.
--
Andreas
Christian Corti
2024-02-14 07:49:07 UTC
Permalink
Post by Andreas Kohlbach
Heute vor 100 Jahren bekam IBM seinen Namen.
*Ihren* Namen ;-))

Christian
Loading...