Haushaltsarbeiten (NeXT)

[Stefan Ram]

Bei Haushaltsarbeiten versuche ich, nebenbei etwas anzuhören,
diesmal fiel meine Wahl auf ein Video von der Vorstellung des
Computermodells "NeXT" durch Steve Jobs am Mittwoch 1988-10-12.

Natürlich war ich durch die Haushaltsarbeiten abgelenkt, aber
was mir doch auffiel, war:

- Ein Programm des NeXT hieß "Browser". (Lee entwickelte das Web
wohl später auf einem NeXT-Computer.)

- Jobs sagt, "There must be a better way!". Diesen Ausdruck
verwendete Raymond Hettinger später auch oft.

- Das System enthält ein Programm, das die Gestaltung von GUIs
ohne Programmierung erlauben soll, aber solche "vereinfachten"
System erlauben meiner Meinung nach, es nur eine beschränkte
Art von GUI-Programmen damit zu entwickeln.

- Jobs legt Wert darauf, daß man auf dem System Zugriff auf
eine "digitale Bücherei" mit Wörterbüchern und den Werken
Shakespeares hat, samt Volltextsuche.

- Heute eine Selbstverständlichkeit, aber damals mit vielen
Klangbeispielen zeitaufwendig demonstriert: Das System kann
Tonaufzeichnungen wiedergeben und Instrumente synthetisieren
(so etwas wie "Midi-Dateien abspielen").

- Jobs verbringt in einem großen Theater viel Zeit damit,
aus digitalen Büchern vorzulesen und Klangproben vorzuspielen.
Heute wäre das natürlich ziemlich langweilig.

- Festplatten nennt er "Winchester". Der NeXT hatte in der
Standardausführung keine.

- Eine bestimmte SQL-Datenbank von Sybase gehörte zur Ausstattung,
damit "alle NeXT-Benutzer untereinander Daten austauschen können"
(weil sie alle /dasselbe/ Datenbanksystem verwenden).

- Das System hatte auch eine LISP-Implementation, für KI, und
überhaupt, weil "LISP die Programmiersprache der 90er werden
wird".

- Außerdem hat jedes System einen TCP/IP-Stack, den "Standard
im Bereich der Hochschulen". Hier denkt man natürlich wieder
an Lee, der auf einem NeXT sein WWW entwickelte.

Nun werde ich weiter an Haushaltsaufgaben arbeiten und mal sehen,
was ich mir dabei jetzt als nächstes anhören werde . . .

[Guido Grohmann]

Post by Stefan Ram
- Festplatten nennt er "Winchester". Der NeXT hatte in der
Standardausführung keine.

Winchesterlaufwerke dienen (wimre laut Murphy) dazu, Daten zu zerschießen.

Guido

[Kay Martinen]

Post by Guido Grohmann

   - Festplatten nennt er "Winchester". Der NeXT hatte in der
     Standardausführung keine.

Winchesterlaufwerke dienen (wimre laut Murphy) dazu, Daten zu zerschießen.

Nur wenn du genug (Daten)Patronen im magazin hast <headcrash> ähh
Hattest... Der Begriff kommt doch von den Wechselplatten.

Jempfalz passt mehr drauf als auf ein Schlappscheiben-Gerät(1). :)

Bye/
/Kay

(1) FDD

[Peter J. Holzer]

Post by Guido Grohmann

Post by Stefan Ram
- Festplatten nennt er "Winchester".

Das war in den 80er-Jahren eine übliche Bezeichnung für Festplatten.
Ursprünglich der Codename für eine bestimmte Modellreihe von IBM, wurde
der Name für alle Festplatten ähnlicher Bauart verwendet (also praktisch
alle für PCs bzw. Workstations).

Post by Guido Grohmann

Post by Stefan Ram
Der NeXT hatte in der Standardausführung keine.

Oh. Das wundert mich jetzt. Zu dem Zeitpunkt waren Festplatten bei PCs
schon sehr verbreitet und eine Unix-Workstation ohne Festplatte stelle
ich mir schon technisch schwierig vor.

Post by Guido Grohmann
Winchesterlaufwerke dienen (wimre laut Murphy) dazu, Daten zu zerschießen.

Im übertragenen Sinn ("laut Murphy's Law") stimmt das natürlich, aber da
passt "wimre" nicht in den Satz. Solltest Du meinen, dass Edward A.
Murphy Jr. das gesagt hat, dann halte ich das für unwahrscheinlich. Der
war zwar bei der Markteinführung der Winchester-Disks erst 55, aber in
einem völlig anderen Fachgebiet tätig und hatte mit Festplatten ziemlich
sicher nichts zu tun.

hp

[p***@pocnet.net]

Post by Peter J. Holzer

Post by Stefan Ram
Der NeXT hatte in der Standardausführung keine.

Oh. Das wundert mich jetzt. Zu dem Zeitpunkt waren Festplatten bei PCs
schon sehr verbreitet und eine Unix-Workstation ohne Festplatte stelle
ich mir schon technisch schwierig vor.

Nö, die Kiste wurde mit einem als fortschrittlich beworbenen aber im Vergleich
zu zeitgenössischen Festplatten bocklahmen optischen Laufwerk (R/W) verkauft.

[Dennis Grevenstein]

Post by p***@pocnet.net
Nö, die Kiste wurde mit einem als fortschrittlich beworbenen aber im Vergleich
zu zeitgenössischen Festplatten bocklahmen optischen Laufwerk (R/W) verkauft.

Da war doch damals die Idee, dass ein user sich quasi seine
Arbeitsumgebung auf der MO disk mitnehmen sollte und dann immer
seine eigene Installation hätte, wenn er von workstation zu
workstation wandert.
Ich habe mich dazu immer gefragt, was dabei insgesamt der Plan
gewesen ist, dann das oben beschriebene wäre ein klarer Alptraum
für die Administration, Sicherheit und vor allem Backup.

gruss,
Dennis

[Gerrit Heitsch]

Post by Dennis Grevenstein

Post by p***@pocnet.net
Nö, die Kiste wurde mit einem als fortschrittlich beworbenen aber im Vergleich
zu zeitgenössischen Festplatten bocklahmen optischen Laufwerk (R/W) verkauft.

Da war doch damals die Idee, dass ein user sich quasi seine
Arbeitsumgebung auf der MO disk mitnehmen sollte und dann immer
seine eigene Installation hätte, wenn er von workstation zu
workstation wandert.

SUN hat das später mit den SunRAY besser implementiert. Man steckt die
Chipkarte in die SunRAY, loggt sich ein und fertig. Will man die
Lokation wechseln zieht man die Karte, steckt sie am neuen Ort in die
dortige SunRAY und bekommt seine offene Session wieder (Password muss
man eingeben). Setzt voraus, daß ein Netz vorhanden ist und beide den
gleichen Server erreichen können.

Ich hab hier noch so ein Setup rumstehen, aber seit 2017 nicht mehr
benutzt. Allerdings nur 1 Server und 1 SunRAY 2 (kann Dual-Monitor).

Gerrit

[Dennis Grevenstein]

Post by Gerrit Heitsch
SUN hat das später mit den SunRAY besser implementiert. Man steckt die
Chipkarte in die SunRAY, loggt sich ein und fertig. Will man die
Lokation wechseln zieht man die Karte, steckt sie am neuen Ort in die
dortige SunRAY und bekommt seine offene Session wieder (Password muss
man eingeben). Setzt voraus, daß ein Netz vorhanden ist und beide den
gleichen Server erreichen können.

Genau. Dafür braucht es nichtmal SunRays. Stell Dir vor es ist 1988
und Deine workstations sind halt Sun 3/50 und 3/60 mit NFS gemounteten
home directories und alles NIS/YP verwaltet. Das performt sicher auch
besser als das ganze System von einer MO disk zu laden. Da muss man
schon harte Fälle konstruieren wie eine 3/50 ohne lokale disk, dass
die MO disk besser abschneidet.

gruss,
Dennis

[Gerrit Heitsch]

Post by Dennis Grevenstein

Post by Gerrit Heitsch
SUN hat das später mit den SunRAY besser implementiert. Man steckt die
Chipkarte in die SunRAY, loggt sich ein und fertig. Will man die
Lokation wechseln zieht man die Karte, steckt sie am neuen Ort in die
dortige SunRAY und bekommt seine offene Session wieder (Password muss
man eingeben). Setzt voraus, daß ein Netz vorhanden ist und beide den
gleichen Server erreichen können.

Genau. Dafür braucht es nichtmal SunRays. Stell Dir vor es ist 1988
und Deine workstations sind halt Sun 3/50 und 3/60 mit NFS gemounteten
home directories und alles NIS/YP verwaltet. Das performt sicher auch
besser als das ganze System von einer MO disk zu laden. Da muss man
schon harte Fälle konstruieren wie eine 3/50 ohne lokale disk, dass
die MO disk besser abschneidet.

Wobei man damals auf 10MBit Ethernet beschränkt war. Da alles drüber
ergab schon einen Flaschenhals wenn das eine größere Installation war.

Gerrit

[Dennis Grevenstein]

Post by Gerrit Heitsch
Wobei man damals auf 10MBit Ethernet beschränkt war. Da alles drüber
ergab schon einen Flaschenhals wenn das eine größere Installation war.

Ich habe das vor vielen Jahren mal ausprobiert, einfach weil ich
das cool fand. Ich hatte ein Sony MO Laufwerk bekommen und wollte
es stilecht an einer uralt SPARC benutzen mit SunOS 4. Das was
so unglaublich extrem langsam, man kann es sich kaum vorstellen.
Und dann hatte die MO disk auch noch Medienfehler. Es war nicht
mehr lustig. Am Ende habe ich den Teil des filesystems wirklich
auf ein NFS share gelegt, weil es nicht mehr zu ertragen war.

gruss,
Dennis

[Gerrit Heitsch]

Post by Dennis Grevenstein

Post by Gerrit Heitsch
Wobei man damals auf 10MBit Ethernet beschränkt war. Da alles drüber
ergab schon einen Flaschenhals wenn das eine größere Installation war.

Ich habe das vor vielen Jahren mal ausprobiert, einfach weil ich
das cool fand. Ich hatte ein Sony MO Laufwerk bekommen und wollte
es stilecht an einer uralt SPARC benutzen mit SunOS 4. Das was
so unglaublich extrem langsam, man kann es sich kaum vorstellen.

Doch, kann ich. Ich musste mich mal auf eine single-CPU SunFire V120
einloggen die einen Load von ca. 300 hatte. Das System lief (Ok,
schlich) und ich konnte das Problem ohne Reboot beheben. Aber es
dauerte. Solaris war damals sehr robust.

Gerrit

[Dennis Grevenstein]

Post by Gerrit Heitsch
Doch, kann ich. Ich musste mich mal auf eine single-CPU SunFire V120
einloggen die einen Load von ca. 300 hatte. Das System lief (Ok,
schlich) und ich konnte das Problem ohne Reboot beheben. Aber es
dauerte. Solaris war damals sehr robust.

Gut, aber das war halt eine total überlastete Kiste. Ist ja auch
schön, dass Solaris sowas gut abkonnte. Ich mochte es auch immer.
Ich hatte lange Zeit eine Netra AC200, also etwas sehr ähnliches.
Die Kiste war recht laut, aber sonst wirklich toll.

gruss,
Dennis

[Gerrit Heitsch]

Post by Dennis Grevenstein

Post by Gerrit Heitsch
Doch, kann ich. Ich musste mich mal auf eine single-CPU SunFire V120
einloggen die einen Load von ca. 300 hatte. Das System lief (Ok,
schlich) und ich konnte das Problem ohne Reboot beheben. Aber es
dauerte. Solaris war damals sehr robust.

Gut, aber das war halt eine total überlastete Kiste.

Nach der Problembehebung nicht mehr. Aber es war schön, daß man es
beheben konnte ohne einen harten Reboot zu benutzen.

Gerrit

[Michael Bäuerle]

Post by Dennis Grevenstein

Post by Gerrit Heitsch
Wobei man damals auf 10MBit Ethernet beschränkt war. Da alles drüber
ergab schon einen Flaschenhals wenn das eine größere Installation war.

Ich habe das vor vielen Jahren mal ausprobiert, einfach weil ich
das cool fand. Ich hatte ein Sony MO Laufwerk bekommen und wollte
es stilecht an einer uralt SPARC benutzen mit SunOS 4. Das was
so unglaublich extrem langsam, man kann es sich kaum vorstellen.

War das ein 5.25" Laufwerk?

Zumindest bei einem der letzten 3.5" Laufwerken von Fujitsu lesen sich
die technischen Daten ganz akzeptabel:
<https://www.fujitsu.com/downloads/COMP/fcpa/mo/dynamo-2300u2_user-manual.pdf>
(Kapitel 5 auf Seite 26)

| Data transfer rate 1.65 MB/s (128 MB)
| (Drive) 2.00 - 3.16 MB/s (230 MB)
| 3.54 - 5.94 MB/s (540 MB)
| 3.52 - 5.87 MB/s (640 MB)
| 3.92 - 6.70 MB/s (1.3 GB GIGAMO)
| 4.69 - 8.38 MB/s (2.3 GB GIGAMO)
| [...]
| Average seek time 19 ms (typ.)
|
| Average latency time 5.5 ms (ISO-standard MO disks)
| 8.2 ms (GIGAMO disks)
|
| Rotational speed 5455 rpm (ISO-standard MO disks)
| 3637 rpm (GIGAMO disks)
|
| Buffer 7.6 MB

Eine magnetische Festplatte mit vergleichbarer Kapazität hat das auch
nicht unbedingt besser hinbekommen.

Du hattest SunOS 4 verwendet, also eine BSD basierte Version.
Altes BSD hat Metadaten gerne zeitnah geschrieben, das könnte sich
hier negativ ausgewirkt haben. Ein MO (ohne "direct overwrite" Feature)
braucht 2 Umdrehungen um etwas zu schreiben. Da ist es sehr hilfreich,
wenn die Daten erst ins RAM gehen und zusammengefasst werden, statt in
kleinen Stücken geschrieben zu werden. Ich würde vermuten, dass sich
das mit Linux besser angefühlt hätte.

Post by Dennis Grevenstein
Und dann hatte die MO disk auch noch Medienfehler. Es war nicht
mehr lustig.

Auch interessant. Ich habe MOs seit >10 Jahren im Einsatz und die
Anzahl der Medien mit Fehlern ist nicht Null, aber bis heute sehr
gering.

Mein Rückblick auf die MO-Ära ist positiv. War aber alles nur 3.5",
kein 5.25".

[Dennis Grevenstein]

Post by Michael Bäuerle
War das ein 5.25" Laufwerk?

Ja, das Laufwerk war auch stilecht. Es war 5.25" disks mit
ca. 500MB Kapazität. Das dürfte auch so von ca. 1990 gewesen sein.

Post by Michael Bäuerle
Du hattest SunOS 4 verwendet, also eine BSD basierte Version.
Altes BSD hat Metadaten gerne zeitnah geschrieben, das könnte sich
hier negativ ausgewirkt haben. Ein MO (ohne "direct overwrite" Feature)
braucht 2 Umdrehungen um etwas zu schreiben. Da ist es sehr hilfreich,
wenn die Daten erst ins RAM gehen und zusammengefasst werden, statt in
kleinen Stücken geschrieben zu werden. Ich würde vermuten, dass sich
das mit Linux besser angefühlt hätte.

Keine Ahnung. Es war SunOS 4.1.4. Das Ding war langsam beim Lesen
und Schreiben. Gerade SunOS 4 hat in der default Konfiguration
immer sehr viel ge'sync't und kaum RAM zum cachen verwendet.
Es war jedenfalls nicht schön.

Post by Michael Bäuerle
Auch interessant. Ich habe MOs seit >10 Jahren im Einsatz und die
Anzahl der Medien mit Fehlern ist nicht Null, aber bis heute sehr
gering.

Ich hatte nur das eine und selbstverständlich waren die Medien
alle niemals komplett neu. Ich habe halt ein, zwei Medien ausprobiert,
einen Teil des filesystems da draufgelegt und ein bisschen gespielt.
Irgendwann kamen dann noch Lesefehler und ich habe es aufgegeben.
Ich weiss, dass Leute damals auch gerne MO benutzt haben, weil das
angelich so stabil und haltbar war. Meine Erfahrung mit dem einen
Laufwerk hat mich da nicht überzeugt. Die Kernüberlegung war eher:
Wenn da wie beim NeXT das ganze OS und alle Daten drauf liegen, wie
macht man das dann mit dem Backup? Und dann trage ich die disk mit
nach Hause? Da wird die doch nicht besser von. Wer hat sich denn
das ausgedacht...

gruss,
Dennis

[olaf]

Post by Dennis Grevenstein
Ja, das Laufwerk war auch stilecht. Es war 5.25" disks mit
ca. 500MB Kapazität. Das dürfte auch so von ca. 1990 gewesen sein.

Also ich hab hier ein Sony MO mit 2.6GB. Auch das ist kein
Geschwindigkeitswunder, war aber fuer die Zeit okay.
Ich hab da so 20-30Medien und nie ein Byte verloren.

Einziger Nachteil von dem Teil, das produziert ordentlich abwaerme im
Tower.

Ein Problem mit Linux gab es das da irgendwann die Sektorreihenfolge
geaendert wurde. ICh musste da mal einen Kernel patchen damit aelter
Medien noch lesbar waren.

Post by Dennis Grevenstein
macht man das dann mit dem Backup? Und dann trage ich die disk mit
nach Hause? Da wird die doch nicht besser von. Wer hat sich denn
das ausgedacht...

Die Scheiben sind doch in einem komplett geschlossenen Caddy.
Was soll da schon passieren?
Heute tragen die Leute ganze SSDs rum ohne ESD Schutz. :-D

Olaf

[Peter J. Holzer]

Post by Dennis Grevenstein

Post by Gerrit Heitsch
Wobei man damals auf 10MBit Ethernet beschränkt war. Da alles drüber
ergab schon einen Flaschenhals wenn das eine größere Installation war.

Ich habe das vor vielen Jahren mal ausprobiert, einfach weil ich
das cool fand. Ich hatte ein Sony MO Laufwerk bekommen und wollte
es stilecht an einer uralt SPARC benutzen mit SunOS 4. Das was
so unglaublich extrem langsam, man kann es sich kaum vorstellen.
Und dann hatte die MO disk auch noch Medienfehler.

Naja, bei Medienfehlern kann die Performance immer grottenschlecht sein,
weil entweder das Laufwerk oder das OS den Request zig-mal wiederholt.

Das würde ich jetzt nicht unbedingt als Beleg dafür werten, dass
MO-Laufwerke notwendigerweise langsam sind.

hp

[olaf]

Post by Peter J. Holzer
Das würde ich jetzt nicht unbedingt als Beleg dafür werten, dass
MO-Laufwerke notwendigerweise langsam sind.

Wenn ich das richtig erinnere machen die eine Umdrehung zum loeschen,
eine zum schreiben und eine zum verify. Also krass schnell waren die
noch nie.

DVD-Ram mit Caddy waren IMHO besser. Ich glaube die haben auf den
Verify verzichtet wenn das Caddy noch nie auf war.

Olaf

[Hermann Riemann]

Post by Gerrit Heitsch
Wobei man damals auf 10MBit Ethernet beschränkt war.

Und BNC Kabelverbindungen?
War vor IP etwas von digital research?

[Gerrit Heitsch]

Post by Hermann Riemann

Post by Gerrit Heitsch
Wobei man damals auf 10MBit Ethernet beschränkt war.

Und BNC Kabelverbindungen?

BNC war schon die Billigversion. Originales Ethernet lief über yellow
cable (10base5)

Gerrit

[p***@pocnet.net]

Da war doch damals die Idee, dass ein user sich quasi seine Arbeitsumgebung
auf der MO disk mitnehmen sollte und dann immer seine eigene Installation
hätte, wenn er von workstation zu workstation wandert.

Die Idee ist ja mal nicht verkehrt. Aber gut gemeint vs. gut gemacht galt
schon damals. :-)

Ich habe mich dazu immer gefragt, was dabei insgesamt der Plan
gewesen ist, dann das oben beschriebene wäre ein klarer Alptraum
für die Administration, Sicherheit und vor allem Backup.

Backup ist IMHO ein lösgelöstes Thema. Aber für die anderen Dinge würde ich
mal schätzen, dass Steve damals eher den Endanwender als Käufer seiner Kisten
sah als Institutionen mit ihren zentralen Administrationen und ganz eigenen
Anforderungen.

Mir ist nur in Erinnerung geblieben, dass die Lösung wohl performancetechnisch
wenig überzeugend gewesen sein soll.

[Stefan Ram]

Post by p***@pocnet.net
Backup ist IMHO ein lösgelöstes Thema. Aber für die anderen Dinge würde ich
mal schätzen, dass Steve damals eher den Endanwender als Käufer seiner Kisten
sah als Institutionen mit ihren zentralen Administrationen und ganz eigenen
Anforderungen.

Ganz im Gegenteil hat er zumindest 1988 betont, dass /nur/
die /amerikanischen Hochschulen/ seine Zielgruppe seien. Man
habe gar nicht die Kapazitaeten, um mehr zu beliefern. Auf die
Frage, wie ein normaler Mensch zu einem NeXT kommen koenne,
antwortete er, "sich einschreiben lassen" ("Enroll!", WIMRE).

Vielleicht hat sich das spaeter geaendert, als sich vielleicht
herausstellte, dass die Nachfrage doch nicht so gross war.
(Ich kann gerade nicht recherchieren oder Umlaute schreiben.)

Post by p***@pocnet.net
Mir ist nur in Erinnerung geblieben, dass die Lösung wohl performancetechnisch
wenig überzeugend gewesen sein soll.

Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Zur Auslieferung von Software sollten auch diese optischen
Datentraeger verwendet werden, die wohl jeweils einen
Materialwert von 50 Dollar darstellten.

Das Problem der Software-Auslieferung hat das Internet ja
heute fuer die Hersteller geloest. Dass sie dabei nun auch
gleich oft weitere Informationen ueber ihre Kunden erhalten,
angefangen bei der IP-Adresse und den Informationen, die ein
Browser so liefert, stoert sie sicher auch nicht weiter.
Ich vermisse die Kartonsoftware, die ich im Laden kaufen
und ohne Netz nutzen konnte.

[Guido Grohmann]

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

Guido

[Peter J. Holzer]

Post by Guido Grohmann

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

330 MB (laut Wikipedia) wundert mich nicht. Ich habe mir 1989 einen PC
gekauft, der eigentlich eine 100 MB Festplatte haben sollte[1]. Das
also damals für "Normal-User" erschwinglich. Dass es für den
Workstation-Markt Platten mit der 3-fachen Kapazität gab, erscheint mir
plausibel. 660 MB allerdings muss damals am oberen Ende der Machbarkeit
gewesen sein. Da waren die 4000 $ direkt ein Schnäppchen ;-).

Den NeXT konnte ich damals übrigens am Weg von einem TU-Gebäude zum
anderen in der Auslage eines Computer-Händlers bewundern. Aber der
Preis war deutlich über dem, was ich mir leisten konnte.

hp

[1] Die war dann gerade nicht lagernd und wurde kurzerhand durch zwei
60 MB Platten ersetzt.

[Guido Grohmann]

Post by Peter J. Holzer

Post by Guido Grohmann

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

330 MB (laut Wikipedia) wundert mich nicht.

Mich auch nicht, aber da stehen GB.

Guido

[Peter J. Holzer]

Post by Guido Grohmann

Post by Peter J. Holzer

Post by Guido Grohmann

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

330 MB (laut Wikipedia) wundert mich nicht.

Mich auch nicht, aber da stehen GB.

Oh, das hatte ich überlesen. Aber solche Fehler passieren mir auch
dauernd. Wenn man alt genug ist, um von kB über MB und GB bis TB alles
erlebt zu haben, dann tippen die Finger schon mal die falsche Abkürzung.
Tatsächlich ist mir das sogar in meinem vorigen Artikel passiert
(vielleicht durch das Zitat geprimet), aber ich habe es beim
Korrekturlesen bemerkt und ausgebessert.

hp

[Stefan Ram]

Post by Guido Grohmann

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

Danke für den Hinweis! (Ich war mir nicht sicher, aber konnte
gerade nicht auf andere System als das Usenet zugreifen, sonst
hätte ich es vor dem Absenden gleich noch einmal überprüft.)

[Dennis Grevenstein]

Post by Stefan Ram

Post by Guido Grohmann

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

Danke für den Hinweis! (Ich war mir nicht sicher, aber konnte
gerade nicht auf andere System als das Usenet zugreifen, sonst
hätte ich es vor dem Absenden gleich noch einmal überprüft.)

Man hätte da vielleicht auch einen schönen Witz über "den chatbot"
machen können, aber wenn Du jetzt den "memory parity error" schon
zugibst, ist das nicht mehr lustig ;-)

gruss,
Dennis

[Hermann Riemann]

Post by Stefan Ram

Post by Guido Grohmann

Post by Stefan Ram
Ein Chatbot hat mir erzaehlt, dass dies eines der Probleme bei
NeXT gewesen sei. Es gab uebrigens auch Festplatten, WIMRE
300 GB fuer 2000 Dollar und 600 fuer 4000.

Echt jetzt? 1988 gabs ne 300GB-Platte in so 'ner kleinen Kiste? Staun.

Danke für den Hinweis! (Ich war mir nicht sicher, aber konnte
gerade nicht auf andere System als das Usenet zugreifen, sonst
hätte ich es vor dem Absenden gleich noch einmal überprüft.)

Da G vor mag (Gewohnheits)Tippfehler gewesen sind.
1988 war Atari ST Zeit mit 10 MB Festplatte,
dann 40 MB Syquest Wechselplatte.
Danach kam PC mit 80 MB Syquest Wechselplatte
und danach 120 MB Festplatte.
1996 hatte meine größter PC mit 64 MB RAM + DX4100 CPU
u.a. 2 5 1/4" SCSI Festplatten mit jeweils 4 GB.

Und wenn schon "Bronzezeit":
Damals windows 95, OS/2 und Linux SuSE,
heute Linux ( SuSE und Debian und raspbian. )
Damals hardware zusammenstecken,
heute eher Betriebssystem Besonderheiten..

[Arno Welzel]

Post by Peter J. Holzer

Post by Stefan Ram
- Festplatten nennt er "Winchester".

Das war in den 80er-Jahren eine übliche Bezeichnung für Festplatten.
Ursprünglich der Codename für eine bestimmte Modellreihe von IBM, wurde
der Name für alle Festplatten ähnlicher Bauart verwendet (also praktisch
alle für PCs bzw. Workstations).

Post by Stefan Ram
Der NeXT hatte in der Standardausführung keine.

Oh. Das wundert mich jetzt. Zu dem Zeitpunkt waren Festplatten bei PCs
schon sehr verbreitet und eine Unix-Workstation ohne Festplatte stelle
ich mir schon technisch schwierig vor.

Statt dessen wurde ein MO-Laufwerk benutzt, also durchaus ein
beschreibbares Speichermedium.

[Peter Müller]

Winchester bringe ich auch Laufwerke in Verbindung. Ist aber
vielleicht so ca. 43 Jahre her, dass ich das gelesen habe.

[p***@pocnet.net]

Post by Stefan Ram
- Festplatten nennt er "Winchester". Der NeXT hatte in der
Standardausführung keine.

Gleiche Terminologie wie die zeitgenössische c't.

Wikipedia sagt:

One significant aspect of this product, and the reason that disk drives in
general became known as "Winchester technology", was that this head design was
very low cost and did not require the heads to be unloaded from the media.
Winchester technology allowed the head to land and take off from the disk
media as the disk spun up and down. This resulted in very significant savings
and a large reduction of complexity of the head and arm actuating mechanism.
This head design rapidly became a standard design within the disk drive
manufacturing community.
Up into the early 1990s the term Winchester or Winnie was used for hard disk
drives in general long after the introduction of the 3340, but is no longer in
common use in most parts of the world.

[Dennis Grevenstein]

Post by Stefan Ram
Bei Haushaltsarbeiten versuche ich, nebenbei etwas anzuhören,
diesmal fiel meine Wahl auf ein Video von der Vorstellung des
Computermodells "NeXT" durch Steve Jobs am Mittwoch 1988-10-12.

Ich musste bei diesen Punkten ehrlich gesagt daran denken, dass
jobs hier mehr eine Art Mac on steroids beschrieben hat. Man hat
sich damals nicht entschieden, ob man einen "personal computer"
oder eine Unix workstation verkaufen wollte und hatte am Ende
nichts passendes für beide user Gruppen. Das Konzept ging erst
mehr als 10 Jahre später auf.

gruss,
Dennis

[F. W.]

Bei Haushaltsarbeiten versuche ich, nebenbei etwas anzuhören, diesmal
fiel meine Wahl auf ein Video von der Vorstellung des Computermodells
"NeXT" durch Steve Jobs am Mittwoch 1988-10-12.

Ich bin heute noch der Meinung, dass der NeXT eine verpasste Chance war.
Der Rechner hatte so viele neue Konzepte, die heute noch Sinn machen,
dass er vermutlich als der Urvater aller PC in die Geschichte hätte
eingehen können.

Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

FW

[Dennis Grevenstein]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

Objective-C?

gruss,
Dennis

[F. W.]

Post by Dennis Grevenstein

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

Objective-C?
gruss,
Dennis

IMHO: Die Klarheit von Pascal erreicht nicht mal Modula-2.

FW

[Kay Martinen]

Post by F. W.

Post by Dennis Grevenstein

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

Objective-C?

IMHO: Die Klarheit von Pascal erreicht nicht mal Modula-2.

Und du bist sicher nicht Semikolon-Süchtig? ;)

Das hat mich damals bei Turbo Pascal 6 am meisten Genervt. Ein fehlendes
Semikolon und er meckert, verrät aber auch nicht wo genau.

Das war bei COMAL-80 besser gelöst. Dessen "IDE" hat dir auf den Punkt
gesagt wo er was erwartet. Und das Programm lief dann auch im
Interpreter, man konnte es später aber auch Kompilieren.

Bye/
/Kay

[Dennis Grevenstein]

Post by F. W.

Post by Dennis Grevenstein

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

Objective-C?

IMHO: Die Klarheit von Pascal erreicht nicht mal Modula-2.

nein, gemeint war, dass NEXTSTEP nicht in Pascal, sondern in Objective-C
geschrieben wurde.
Ich habe in der Schule mal Pascal/Delphi gecodet. An Euren Diskussionen
über die schönste Programmiersprache kann ich mich glaube ich nicht
ernsthaft beteiligen.

gruss,
Dennis

[Hermann Riemann]

Post by F. W.

Bei Haushaltsarbeiten versuche ich, nebenbei etwas anzuhören, diesmal
fiel meine Wahl auf ein Video von der Vorstellung des Computermodells
"NeXT" durch Steve Jobs am Mittwoch 1988-10-12.

Ich bin heute noch der Meinung, dass der NeXT eine verpasste Chance war.
Der Rechner hatte so viele neue Konzepte, die heute noch Sinn machen,
dass er vermutlich als der Urvater aller PC in die Geschichte hätte
eingehen können.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

In C kann man Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden, und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
pointer ohne Assemblerhilfe blockiert.

Die beste Programmiersprache für mich richtet sich nach
Anwendung:

Python für Textbearbeitung und einfache Modelle
C für Graphik, Binärdaten und Berechnungen
bash für Einzeiler im System.
JavaScript (grr) in html Dateien.
Lisp eventuell für Programmmodifkationsversuche

NeXT war ein Versuchs Rechner zu Zeiten von
Lisa ( *86 CPU ) und Macintosch ( 68* CPU ).

[F. W.]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

In C kann man  Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden,  und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
 pointer ohne Assemblerhilfe blockiert.

Wenn die Betriebssysteme damit schreiben, scheint es irgendwie zu gehen,
ohne die Dokumentationskraft von Pascal zu schmälern.

Python für Textbearbeitung und einfache Modelle

Kann nicht kompiliert werden. KnowHow nicht schützbar.

C für Graphik, Binärdaten und Berechnungen

Der C-Hype hat viele Anwendungen geboren. Die wären vielleicht billiger
und sicherer, wenn sie nicht in C geschrieben worden wären.

bash für Einzeiler im System.

Ja gut.

JavaScript (grr) in html Dateien.

Verlagert das Problemfeld "Programmfehler" wieder zurück zum Anwender.
Halte ich nicht viel von. Meine Sprache war CFML und ich war sehr
schnell darin, komplette Anwendungen für das Web zu schreiben.

Warum wechselt die IT immer wieder in Richtung "suchen Sie das größte
Problem und entwickeln Sie damit"?

FW

[Hermann Riemann]

Post by F. W.

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

In C kann man  Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden,  und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
  pointer ohne Assemblerhilfe blockiert.

Wenn die Betriebssysteme damit schreiben, scheint es irgendwie zu gehen,
ohne die Dokumentationskraft von Pascal zu schmälern.

Gehen tut es auch in Assembler,
mit Assemblerhilfe vermutlich auch in COBOL.

Post by F. W.

Python für Textbearbeitung und einfache Modelle

Kann nicht kompiliert werden. KnowHow nicht schützbar.

Maschinencode lässt sich rückübersetzen.

Post by F. W.

C für Graphik, Binärdaten und Berechnungen

Der C-Hype hat viele Anwendungen geboren. Die wären vielleicht billiger
und sicherer, wenn sie nicht in C geschrieben worden wären.

Nicht unbedingt. Viele Programmierer können C.
Programme in ungewohnte Sprachen können teurer sein.
Und für kommerzielle compiler wird Geld verlangt.

Post by F. W.

JavaScript (grr) in html Dateien.

Verlagert das Problemfeld "Programmfehler" wieder zurück zum Anwender.

Für die Kombination html JavaScript gibt es kaum Alternativen.

Post by F. W.
Halte ich nicht viel von. Meine Sprache war CFML und ich war sehr
schnell darin, komplette Anwendungen für das Web zu schreiben.

Um web Dateien zu generieren verwende ich Python

Post by F. W.
Warum wechselt die IT immer wieder in Richtung "suchen Sie das größte
Problem und entwickeln Sie damit"?

windows?
Geld und Politik.

[Josef Möllers]

Post by Hermann Riemann

Post by F. W.

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für
perfekt, aber die beste der Welt. Sie ist in meinen Augen die beste
Mischung aus Basic und C mit allen Vorteilen.

In C kann man  Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden,  und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
  pointer ohne Assemblerhilfe blockiert.

Wenn die Betriebssysteme damit schreiben, scheint es irgendwie zu
gehen, ohne die Dokumentationskraft von Pascal zu schmälern.

Gehen tut es auch in Assembler,
mit Assemblerhilfe vermutlich auch in COBOL.

Ich hab's mit variant records auf einer Pascal Microengine gemacht. Hat
funktioniert, ist aber extrem unportabel wegen der ggf unterschiedlichen
Größe der Datentypen (16 Bit INTEGER vs. 32 Bit Pointer).

Post by Hermann Riemann

Post by F. W.

Python für Textbearbeitung und einfache Modelle

Kann nicht kompiliert werden. KnowHow nicht schützbar.

Maschinencode lässt sich rückübersetzen.

Theoretisch ... ja ... praktisch seeehr schwierig (BTDT), obwohl es da
wohl $$$$$-Programmpakete gibt, die das ganz gut können.


Josef

[Peter J. Holzer]

Post by Josef Möllers

Post by Hermann Riemann

Post by F. W.

In C kann man  Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden,  und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
  pointer ohne Assemblerhilfe blockiert.

Wenn die Betriebssysteme damit schreiben, scheint es irgendwie zu gehen,

Der Compiler könnte entsprechende Extensions implementiert haben. Wer
ein Betriebssystem in Pascal schreibt, hat meistens auch die
Möglichkeit, den Compiler zu modifizieren.

Post by Josef Möllers

Post by Hermann Riemann

Post by F. W.
ohne die Dokumentationskraft von Pascal zu schmälern.

Gehen tut es auch in Assembler,
mit Assemblerhilfe vermutlich auch in COBOL.

Ich hab's mit variant records auf einer Pascal Microengine gemacht. Hat
funktioniert, ist aber extrem unportabel wegen der ggf unterschiedlichen
Größe der Datentypen (16 Bit INTEGER vs. 32 Bit Pointer).

Es ist auch deswegen unportabel, weil der Zugriff auf inaktive Varianten
verboten ist. Der Compiler könnte Code generieren, der da einen
Laufzeitfehler produziert oder immer 0xDEADBEEF zurückliefert.

(In C ist das auch verboten, aber so wie unions in C definiert sind, ist
es fast unmöglich für den Compiler, das abzufangen.)

hp

[Josef Möllers]

Post by Peter J. Holzer

Post by Josef Möllers

Post by Hermann Riemann

Post by F. W.

In C kann man  Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden,  und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
  pointer ohne Assemblerhilfe blockiert.

Wenn die Betriebssysteme damit schreiben, scheint es irgendwie zu gehen,

Der Compiler könnte entsprechende Extensions implementiert haben. Wer
ein Betriebssystem in Pascal schreibt, hat meistens auch die
Möglichkeit, den Compiler zu modifizieren.

Post by Josef Möllers

Post by Hermann Riemann

Post by F. W.
ohne die Dokumentationskraft von Pascal zu schmälern.

Gehen tut es auch in Assembler,
mit Assemblerhilfe vermutlich auch in COBOL.

Ich hab's mit variant records auf einer Pascal Microengine gemacht. Hat
funktioniert, ist aber extrem unportabel wegen der ggf unterschiedlichen
Größe der Datentypen (16 Bit INTEGER vs. 32 Bit Pointer).

Es ist auch deswegen unportabel, weil der Zugriff auf inaktive Varianten
verboten ist. Der Compiler könnte Code generieren, der da einen
Laufzeitfehler produziert oder immer 0xDEADBEEF zurückliefert.

Es mag sein, daß ich da tatsächlich die Variante explizit ausgewählt
hatte. Ist schon ein paar Jährchen her.

Josef

[Peter J. Holzer]

Post by Josef Möllers

Post by Peter J. Holzer

Post by Josef Möllers

In C kann man  Maschinencodes inkl. Adresse bzw Konstante
und mit struct abbilden,  und mit über pointer in Speicher
lesen und schreiben.
Geht mit Pascal nicht. da ist variant im Wege und
  pointer ohne Assemblerhilfe blockiert.

[...]

Post by Josef Möllers

Post by Peter J. Holzer

Post by Josef Möllers
Ich hab's mit variant records auf einer Pascal Microengine gemacht. Hat
funktioniert, ist aber extrem unportabel wegen der ggf unterschiedlichen
Größe der Datentypen (16 Bit INTEGER vs. 32 Bit Pointer).

Es ist auch deswegen unportabel, weil der Zugriff auf inaktive Varianten
verboten ist. Der Compiler könnte Code generieren, der da einen
Laufzeitfehler produziert oder immer 0xDEADBEEF zurückliefert.

Es mag sein, daß ich da tatsächlich die Variante explizit ausgewählt
hatte. Ist schon ein paar Jährchen her.

Das Auswählen der Variante nützt nichts, weil der Wert beim Wechseln
undefiniert wird.

Beispiel:

1 program variant;

2 type
3 tricky =
4 record
5 case t: boolean of
6 false: ( a: integer );
7 true: (b: real )
8 end;
9 var
10 x: tricky;

11 begin
12 x.t := true;
13 x.b := 3.1415926536;
14 x.t := false;
15 writeln(x.a)
16 end.

Durch die Zuweisung in Zeile 14 werden sowohl x.b (weil nicht mehr
aktiv) als auch x.a (weil noch nicht zugewiesen) undefiniert. Ein
Compiler könnte daher in Zeile 15 bemerken, dass der Zugriff auf x.a
nicht erlaubt ist und einen Fehler ausgeben. Oder er könnte in Zeile 14
Code generieren, der nicht nur x.t auf false setzt, sondern auch x.a/x.b
mit irgendeinem Bitmuster überschreibt. Das writeln würde dann diese
Bitmuster ausgeben und nicht ein Integeräquivalent von π.

Dass Dein Compiler das nicht gemacht hat, war Glück, nicht von der
Sprache vorgesehen.

hp

[Marco Scholz]

On 2024-05-31, F. W. <***@home.invalid> wrote:
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für

[...]

Wie bitte?

[F. W.]

Post by Marco Scholz
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für

[...]
Wie bitte?

Oder war das das der Lisa?

FW

[Marco Scholz]

Post by F. W.

Post by Marco Scholz
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für

[...]
Wie bitte?

Oder war das das der Lisa?

NeXTSTEP und die davon abstammenden macOS und iOS atmen quasi Objective-C.

LisaOS ist, wie viel Apple Zeug zu der Zeit, tatsächlich Pascal mit
etwas Assembler.

LisaOS ist übrigens seit 2023 open source:
https://info.computerhistory.org/apple-lisa-code

[Stefan Ram]

Post by Marco Scholz
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für

[...]
Wie bitte?

Ich denke, man muß hier zwischen "Pascal" und "Pascal" unterscheiden:

Das klassische Pascal nach "The Programming Language Pascal
(Revised Report)" (1972-11) von Niklaus Wirth, sowie Pascal
nach dem Jensen-/ Wirth-Bericht, DIN- und ISO-Pascal ist
so eingeschränkt, daß es nicht einmal Zeichenfolgen oder
Speicherpuffer variabler Länge hat. Damit ist die Programmierung
in vielen Fällen außerhalb eines begrenzten Bereichs schwierig.

C unterstützt zwar auch keine Zeichenfolgen, aber mit "malloc"
wenigstens Puffer mit Laufzeitlänge. In Standard-Pascal
gibt es aber keine Entsprechung für "malloc"!

Verschiedene kommerzielle "Pascal"-Implementationen verwenden ein
stark erweitertes Pascal, aber das ist eben nicht standardisiert.

In Vergleich damit gibt es heute Programmiersprache, die
leistungsfähiger als Pascal /und/ standardisiert sind (wie
ECMAScript [JavaScript], C und C++).

Jedoch ist Python nicht formal standardisiert, sondern praktisch
durch eine Implementation definiert. Es gibt allerdings
verschiedene mehr oder weniger kompatible Implementationen.

(Jetzt folgt ein etwas langer Text zu einem Editor, der gegen
Ende auf Pascal zurückkommt.)

Ich hatte mal ein kleines Beispielprogramm für einen einfachen
Texteditor nach ger.ct gepostet. Ich machte mir einen Spaß daraus,
es in verschiedenen Programmiersprachen zu schreiben. Aber ich
war nicht in der Lage, es in Standard-Pascal zu schreiben - das
wäre zu aufwendig geworden . . .

Hier ein Beispiel eines Dialogs mit dem Editor:

| |i1 insert "1"
| |+1 move cursor right
| |alpha
| |^
|>|+2
| |alpha
| | ^
|>|i__
| |al__pha
| | ^

. Der eigentliche Dialog beginnt in Spalte 4, die ersten drei
Spalten wurden nur für die obige Wiedergabe hinzugefügt,
um Benutzereingaben in Spalte 2 mit ">" zu kennzeichnet.

Der Editor gibt zunächst ein Handbuch aus: "i1" bedeutet "Einfügen
des Zeichens '1'" (i=insert) und "+1" "Gehe nach rechts" ("+"=
addiere 1 zur Schreibmarkenposition).

Dann wird der Inhalt des Puffers ausgegeben, "alpha", und die
Position der Einfügemarke, "^".

Der Benutzer geht zwei Schritte nach rechts, "+2", und fügt dann
dort "__" ein, "i__".

Hier nun der Quelltext dieses Editors in C++:

#include <iostream>
#include <ostream>
#include <istream>
#include <cstdlib>

int arg( ::std::string & s ){ return stoi( s.substr( 1 )); }

int main()
{ ::std::cout << "i1 insert \"1\"\n+1 move cursor right\n "
::std::string s{ "alpha" }, command; int pos = 0; while( 1 )
{ ::std::cout << s << '\n' << ::std::string( pos, ' ' ) << '^' << '\n';
::std::cin >> command; switch( command.at( 0 ))
{ case '+': pos += arg( command ); break;
case 'i': s.insert( pos, command.substr( 1 )); break; }}}

, in Python:

class Editor():
def __init__( self, *args, **kwargs ):
self.s = 'alpha'
self.pos = 0
def r( self, arg ):
self.pos += int( arg )
def i( self, arg ):
self.s = self.s[ :self.pos ]+ arg + self.s[ self.pos: ]
def __str__( self ):
return self.s + '\n' + ' '* self.pos + '^\n'

editor = Editor()
print( 'i1 insert "1"\nr1 move cursor right\n' )
while True:
print( editor )
command = input()
getattr( editor, command[ 0 ])( command[ 1: ])

(in einem separaten Posting wird dazu noch eine verbesserte
Python-Version kommen)

, in BASIC:

100 PRINT "i1 insert ""1""" + CHR$( 13 )+ "+1 move cursor right"
110 LET S$ = "alpha": P = 0
120 PRINT S$
130 IF P=0 GOTO 170
140 FOR I=1 TO P
150 PRINT " ";
160 NEXT I
170 PRINT "^"
180 INPUT CO$
190 LET C$ = LEFT$( CO$, 1 )
200 LET A$ = RIGHT$( CO$, LEN( CO$ )- 1 )
210 IF C$ <> "+" GOTO 240
220 LET P = P + VAL( A$ )
230 GOTO 120
240 LET S$ = LEFT$( S$, P )+ A$ + RIGHT$( S$, LEN( S$ )- P )
250 GOTO 120
260 END

, in JavaScript:

Editor.html

<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"
lang="en" xml:lang="en">
<head><meta charset="UTF-8" /><title>Editor</title>
<style>*{font-family: monospace}</style>
</head><body><div id="root"></div>
<script type="module">
function edit( buffer, pos )
{ let elem = document.createElement( "p" );
console.log( pos );
elem.className = "text";
elem.innerText =
buffer + "\n" + String.fromCharCode( 160 ).repeat( pos )+ "^"
document.getElementById( "root" ).appendChild( elem );
elem = document.createElement( "input" );
elem.setAttribute( "type", "text" );
document.getElementById( "root" ).appendChild( elem );
elem.focus();
elem.addEventListener
( "keydown",
function( e )
{ console.log( "keydown", e, e.noco );
if( e.key === "Enter" )
{ console.log( "Enter" );
const input = elem.value;
if( input[ 0 ]== "+" )
{ pos += parseInt( input.substr( 1 ), 10 );
console.log( input.substr( 1 ));
console.log( parseInt( input.substr( 1 ), 10 ));
console.log( pos ); }
else
{ buffer =
buffer.substr( 0, pos )+ input.substr( 1 )+
buffer.substr( pos ); }
setTimeout( function(){ edit( buffer, pos );}, 0 ); }}); }
function main(){ edit( "alpha", 0 ); }
main()
</script></body></html>

. Nun, ich /habe/ auch eine Pascal-Version geschrieben, aber
diese hat im Gegensatz zu den Versionen in den obigen Sprachen
nur einen /statischen/ Puffer, also einen Puffer mit einer
/fixen Größe/. Damit ist die Pascal-Version nicht gleichwertig
zu den vorigen Versionen, sondern /schlechter/.

Die Pascal-Anhänger in dieser Newsgroup können ja mal eine wirklich
gleichwertige Version dieses Editors in Pascal zu schreiben versuchen,
die nur Standard-Pascal verwendet, aber einen Text-Puffer mit
unbegrenzter Größe hat! Das geht, aber sollte ziemlich aufwendig
sein. Selbst C sollte da noch einfacher sein als Standard-Pascal.

PROGRAM EDITOR( INPUT, OUTPUT );

VAR BUFFER: PACKED ARRAY[ 1..10 ]OF CHAR;
VAR OFFSET: INTEGER;
VAR INPUT: PACKED ARRAY[ 1..10 ]OF CHAR;
VAR I: INTEGER;
VAR A: INTEGER;
VAR SELECTOR: CHAR;
VAR J: INTEGER;

BEGIN
WRITELN( 'i1 insert "1"'+ chr( 10 )+'+1 move cursor right');
BUFFER := 'alpha'; OFFSET := 0;
WHILE TRUE DO
BEGIN
WRITELN( BUFFER );
FOR I:=1 TO OFFSET DO WRITE( ' ' ); WRITELN( '^' );
READLN( INPUT );
SELECTOR := INPUT[ 1 ];
A := ORD( INPUT[ 2 ])- ORD( '0' );
IF SELECTOR = '+' THEN
BEGIN
OFFSET := OFFSET + A
END
ELSE
BEGIN
I := 2;
WHILE I < 10 DO
BEGIN
IF ORD( INPUT[ I ])<> 0 THEN
BEGIN
FOR J := 10 DOWNTO OFFSET+1 DO
BUFFER[ J ]:= BUFFER[ J-1 ];
BUFFER[ OFFSET ]:= INPUT[ I ];
IF ORD( INPUT[ I+1 ])<> 0 THEN OFFSET := OFFSET + 1
END;
I := I + 1
END
END
END
END.

[Stefan Ram]

***@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
. . .
Hier eine verbesserte Version, die ein Internet-Chatbot für
mich geschrieben hat. Sie enthält Kommentare, die das Programm
verständlicher machen.

from typing import Optional

class Editor:
def __init__(self, initial_text: str = ''):
self.text: str = initial_text
self.cursor_pos: int = 0

def move_cursor(self, offset: int) -> None:
"""
Move the cursor position by the given offset.

editor = Editor("Hello, World!")
editor.move_cursor(3)
editor.cursor_pos

3

editor.move_cursor(-5)
editor.cursor_pos

0

editor.move_cursor(20)
editor.cursor_pos

13
"""
new_pos = self.cursor_pos + offset
self.cursor_pos = max(0, min(new_pos, len(self.text)))

def insert_text(self, new_text: str) -> None:
"""
Insert the given text at the current cursor position.

editor = Editor("Hello, World!")
editor.insert_text(" Python")
editor.text

'Hello, Python World!'

editor.cursor_pos

14
"""
self.text = self.text[:self.cursor_pos] + new_text + self.text[self.cursor_pos:]
self.cursor_pos += len(new_text)

def __str__(self) -> str:
"""
Return a string representation of the text and cursor position.

editor = Editor("Hello, World!")
editor.move_cursor(5)
print(editor)

Hello, World!
^
"""
cursor_marker = ' ' * self.cursor_pos + '^'
return f"{self.text}\n{cursor_marker}"


def main() -> None:
editor: Optional[Editor] = None
print("Welcome to the text editor!")
print("Commands: i<text> (insert text), r<offset> (move cursor), q (quit)")

while True:
if editor is None:
editor = Editor( 'alpha' )

print(editor)
command = input("Enter command: ").strip()

if not command:
continue

if command == 'q':
break

if command[0] == 'i':
editor.insert_text(command[1:])
elif command[0] == 'r':
try:
offset = int(command[1:])
editor.move_cursor(offset)
except ValueError:
print("Invalid offset. Please enter an integer.")
else:
print("Invalid command. Try again.")

print("Goodbye!")

if __name__ == "__main__":
main()

[Peter J. Holzer]

Post by Stefan Ram

Post by Marco Scholz
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll.

[...]
Wie bitte?

Das klassische Pascal nach "The Programming Language Pascal
(Revised Report)" (1972-11) von Niklaus Wirth, sowie Pascal
nach dem Jensen-/ Wirth-Bericht, DIN- und ISO-Pascal ist
so eingeschränkt, daß es nicht einmal Zeichenfolgen oder
Speicherpuffer variabler Länge hat. Damit ist die Programmierung
in vielen Fällen außerhalb eines begrenzten Bereichs schwierig.
C unterstützt zwar auch keine Zeichenfolgen, aber mit "malloc"
wenigstens Puffer mit Laufzeitlänge. In Standard-Pascal
gibt es aber keine Entsprechung für "malloc"!

Es gibt keine exakte Entsprechung für malloc, aber es gibt new. Das kann
zwar nur Variablen eines vorgebenen Typs (und damit fixer Länge[1])
allozieren, aber man kann beliebig lange Strings z.B. als verkettete
Liste oder als Baumstruktur implementieren.

Post by Stefan Ram
Ich hatte mal ein kleines Beispielprogramm für einen einfachen
Texteditor nach ger.ct gepostet. Ich machte mir einen Spaß daraus,
es in verschiedenen Programmiersprachen zu schreiben. Aber ich
war nicht in der Lage, es in Standard-Pascal zu schreiben - das
wäre zu aufwendig geworden . . .

Für einen Editor wäre die einfachste Implementation, die Zeilen in einer
doppelt verketteten Liste zu speichern (damit man sowohl vorwärts als
auch rückwärts durch die Zeilen wechseln kann). Für eine einfache Demo
wäre wohl eine fixe Zeilenlänge akzeptabel, effizienter und flexibler
aber wäre es, jede Zeile wiederum als doppelt verkettete Liste von
Fragmenten (z.B. je 20 Zeichen) zu speichern.

Das ist zwar schon etwas aufwendiger als in C, aber nicht viel.

hp

[1] Also strenggenommen stimmt das nicht. Variant Records könnten nach
dem Buchstaben des Standards auch variable Länge haben. Ich weiß
aber nicht, ob das jemals so implementiert wurde. Verlassen kann man
sich sicher nicht darauf.

[Thomas Koenig]

Post by Peter J. Holzer

Post by Stefan Ram

Post by Marco Scholz
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll.

[...]
Wie bitte?

Das klassische Pascal nach "The Programming Language Pascal
(Revised Report)" (1972-11) von Niklaus Wirth, sowie Pascal
nach dem Jensen-/ Wirth-Bericht, DIN- und ISO-Pascal ist
so eingeschränkt, daß es nicht einmal Zeichenfolgen oder
Speicherpuffer variabler Länge hat. Damit ist die Programmierung
in vielen Fällen außerhalb eines begrenzten Bereichs schwierig.
C unterstützt zwar auch keine Zeichenfolgen, aber mit "malloc"
wenigstens Puffer mit Laufzeitlänge. In Standard-Pascal
gibt es aber keine Entsprechung für "malloc"!

Es gibt keine exakte Entsprechung für malloc, aber es gibt new. Das kann
zwar nur Variablen eines vorgebenen Typs (und damit fixer Länge[1])
allozieren, aber man kann beliebig lange Strings z.B. als verkettete
Liste oder als Baumstruktur implementieren.

Wenn Performance keine Rolle spielt, kann man sowas machen, sonst
eher nicht.

Aber eins der Hauptprobleme zumindest im Original-Pascal war, dass
man keine Unterprogramme für variable Arraygrößen schreiben
konnte (und das scheint in Standard-Pascal immer noch der Fall zu
sein, wenn ich das richtig lese). Das konnten schon Fortran II
und Algol 60.

[Peter J. Holzer]

Post by Thomas Koenig

Post by Peter J. Holzer

Post by Stefan Ram
Das klassische Pascal nach "The Programming Language Pascal
(Revised Report)" (1972-11) von Niklaus Wirth, sowie Pascal
nach dem Jensen-/ Wirth-Bericht, DIN- und ISO-Pascal ist
so eingeschränkt, daß es nicht einmal Zeichenfolgen oder
Speicherpuffer variabler Länge hat. Damit ist die Programmierung
in vielen Fällen außerhalb eines begrenzten Bereichs schwierig.
C unterstützt zwar auch keine Zeichenfolgen, aber mit "malloc"
wenigstens Puffer mit Laufzeitlänge. In Standard-Pascal
gibt es aber keine Entsprechung für "malloc"!

Es gibt keine exakte Entsprechung für malloc, aber es gibt new. Das kann
zwar nur Variablen eines vorgebenen Typs (und damit fixer Länge[1])
allozieren, aber man kann beliebig lange Strings z.B. als verkettete
Liste oder als Baumstruktur implementieren.

Wenn Performance keine Rolle spielt, kann man sowas machen, sonst
eher nicht.

Gerade wenn Performance eine Rolle spielt, will man das machen. Wenn
ein File 1MB lang ist und der User fügt ganz am Anfang ein Zeichen ein,
dann will man nicht 1MB kopieren müssen.

Auf entsprechend schwacher Hardware (Pascal entstand Ende der 60er-/Anfang
der 70er-Jahre) könnten schon lange Zeilen zu viel sein (Selbst auf
modernen Rechnern wird Vim z.B. bei manchen Operationen mit zunehmender
Zeilenlänge spürbar langsamer).

Da ist es besser, man zerlegt das File in viele kleine Fragmente und jede
Operation betrifft nur ein Fragment und vielleicht seine Nachbarn. Da
ist es dann weitgehend egal, wenn jedes Fragment fixe Länge hat.
Variable Länge würde zwar etwas Platz sparen und den Code etwas
einfacher machen, aber realloc ist auch nicht gratis.

Post by Thomas Koenig
Aber eins der Hauptprobleme zumindest im Original-Pascal war, dass
man keine Unterprogramme für variable Arraygrößen schreiben
konnte (und das scheint in Standard-Pascal immer noch der Fall zu
sein, wenn ich das richtig lese).

ACK. Außerdem keine Möglichkeit der Variableninitialisierung und etliche
andere Einschränkungen. Es hatte schon seine Gründe, warum ich ca. 1987
auf C umgestiegen bin (zugegeben: Einige Gründe hatten nichts mit der
Sprache an sich zu tun).

hp

[Marco Scholz]

Post by Marco Scholz
[...]

Post by F. W.
Mir persönlich gefiel am besten, dass sein Betriebssystem in Pascal
geschrieben worden sein soll. Ich halte die Sprache immer noch nicht für

[...]
Wie bitte?

Nein, muss man hier nicht.

[F. W.]

Post by Stefan Ram
Ich denke, man muß hier zwischen "Pascal" und "Pascal"

Also für C gilt auch nicht mehr der K&R 1968 Standard. Aber FreePascal
lässt sich beispielsweise in verschiedenen Modi kompilieren:
Turbo-kompatibel, ObjectPascal, FreePascal oder eben Standard.

Tatsächlich spielt das in der Praxis keine Rolle. Niemand muss mehr zu
hunderten von Systemen kompatible Programme schreiben. Schon gar nicht
im kommerziellen Bereich.

FW

[Thomas Koenig]

Post by F. W.

Post by Stefan Ram
Ich denke, man muß hier zwischen "Pascal" und "Pascal"

Also für C gilt auch nicht mehr der K&R 1968 Standard.

1968 gab's noch kein C :-)

Ich vermute mal, du meinst 1978, als der erste K&R rauskam.

[F. W.]

Post by Thomas Koenig

Post by F. W.

Post by Stefan Ram
Ich denke, man muß hier zwischen "Pascal" und "Pascal"

Also für C gilt auch nicht mehr der K&R 1968 Standard.

1968 gab's noch kein C :-)
Ich vermute mal, du meinst 1978, als der erste K&R rauskam.

1972 dachte ich.

https://de.wikipedia.org/wiki/C_(Programmiersprache)

FW

[Peter J. Holzer]

Post by F. W.

Post by Thomas Koenig

Post by F. W.

Post by Stefan Ram
Ich denke, man muß hier zwischen "Pascal" und "Pascal"

Also für C gilt auch nicht mehr der K&R 1968 Standard.

1968 gab's noch kein C :-)
Ich vermute mal, du meinst 1978, als der erste K&R rauskam.

1972 dachte ich.
https://de.wikipedia.org/wiki/C_(Programmiersprache)

Ja, aber gerade in den ersten Jahren hat sich die Sprache schon recht
rasch geändert. Wenn jemand vom "K&R Standard" spricht, dann ist
normalerweise der Stand gemeint, der in /Brian Kernighan and Dennis
Ritche: The C Programming Language/ beschrieben ist. Und dieses Buch ist
Anfang 1978 erschienen, beschreibt also wohl den Stand von 1977, nicht
den von 1972.

(Interessant ist dabei, dass z.B. die deutsche Übersetzung, die meiner
Erinnerung nach 1983 erschienen ist, bereits einige Sprachfeatures
beschreibt, die erst nach 1978 implementiert wurden und daher im
Original nicht vorkommen.)

hp

[Marco Scholz]

On 2024-05-29, Stefan Ram <***@zedat.fu-berlin.de> wrote:
[...]

Post by Stefan Ram
Computermodells "NeXT" durch Steve Jobs am Mittwoch 1988-10-12.

[...]

NeXTstep Concepts, 632p.
http://www.bitsavers.org/pdf/next/Release_1_Dec90/NEXTstep_Concepts_Dec90.pdf

[Arno Welzel]

Post by Stefan Ram
Bei Haushaltsarbeiten versuche ich, nebenbei etwas anzuhören,
diesmal fiel meine Wahl auf ein Video von der Vorstellung des
Computermodells "NeXT" durch Steve Jobs am Mittwoch 1988-10-12.
Natürlich war ich durch die Haushaltsarbeiten abgelenkt, aber
- Ein Programm des NeXT hieß "Browser". (Lee entwickelte das Web
wohl später auf einem NeXT-Computer.)

Der Mann hieß Tim Berners-Lee und er entwickelte das "World Wide Web"
auf dem NeXT, aber nicht, weil der NeXT einen Browser hatte, sondern
wegen NeXTStep und TCP/IP:

<https://home.cern/science/computing/birth-web>

[...]

Post by Stefan Ram
- Festplatten nennt er "Winchester". Der NeXT hatte in der
Standardausführung keine.

"Winchester" war ein häufig genutztes Synonym für Festplatten und geht
auf die IBM 3340 zurück:

<https://www.computerhistory.org/storageengine/winchester-pioneers-key-hdd-technology/>

Post by Stefan Ram
- Außerdem hat jedes System einen TCP/IP-Stack, den "Standard
im Bereich der Hochschulen". Hier denkt man natürlich wieder
an Lee, der auf einem NeXT sein WWW entwickelte.

"Tim Berners-Lee", nicht "Lee".

[Michael Noe]

Post by Stefan Ram
- Ein Programm des NeXT hieß "Browser". (Lee entwickelte das Web
wohl später auf einem NeXT-Computer.)

Ist hier wohl der Dateimanger von NeXTStep gemeint? Damit vor allem
"Browser View". Seit Mac OS X Cheetah - das heutige macOS, letztlich ein
umbenanntes/weiterentwickeltes NeXTStep - 2001 als Spaltendarstellung
(auf deutschen Systemen) bis heute im Finder wie unter NeXTStep
verfügbar. Nutze ich bis heute primär besonders gerne gegenüber "Listen"
und/oder "Icons".

Bei Rhapsody/Mac OS X Server 1.0 von 1999 (suche mal nach Screenshots)
sieht man den Übergang seht gut. Bundles (".app") samt Copland/Mac OS
8-Optik und allerlei offensichtliche NeXTStep-"Einflüsse". ;-)

Damalige Mac OS X-Themen wie Rhapsody/Blue Box/Yellow Bow und vor allem
auch Carbon führen hier jetzt zu weit. Habe aktuell wegen Hausbau auch
nicht wirklich die Zeit für größere Erläuterungen.

Google/Wikipedia/Seiten zur NeXTStep|macOS-History existieren. ;-)

Post by Stefan Ram
- Das System enthält ein Programm, das die Gestaltung von GUIs
ohne Programmierung erlauben soll, aber solche "vereinfachten"
System erlauben meiner Meinung nach, es nur eine beschränkte
Art von GUI-Programmen damit zu entwickeln.

WebObjects? Developer Tools? "Project Builder/Interface Builder"? ;-)

AFAIR basiert auch Apples XCode auf dem Mac genau darauf.

Ansonsten sind die Stichworte bei NeXTStep|macOS, wie bereits erwähnt,
natürlich primär Objective-C, seit zehn Jahren zunehmend auch SWIFT.
(Damit auch iOS/iPadOS/tvOS/watchOS usw., da auch all dies seinen
Ursprung in NeXTStep hat und ein Derivat davon ist.)

Sehr frühe Versionen von System 1 bis teils System 7 (klassisches Mac
OS) waren noch in Pascal geschrieben, wie hier erwähnt wurde, das ist
richtig. Auch die damaligen (Old World) ROMs aka Firmware.

Post by Stefan Ram
- Jobs legt Wert darauf, daß man auf dem System Zugriff auf
eine "digitale Bücherei" mit Wörterbüchern und den Werken
Shakespeares hat, samt Volltextsuche.

Als "Lexicon(.app)" auch unter macOS Sonoma vorinstalliert. Bundles
unter macOS sind übrigens auch so ein "Überbleibsel" von NeXTStep.

Post by Stefan Ram
- Heute eine Selbstverständlichkeit, aber damals mit vielen
Klangbeispielen zeitaufwendig demonstriert: Das System kann
Tonaufzeichnungen wiedergeben und Instrumente synthetisieren
(so etwas wie "Midi-Dateien abspielen").

Die NeXT-Rechner hatten neben dem MC68030/40 samt FPU noch einen
Motorola-DSP, welcher prädestiniert für Audio-Bearbeitung war. Das war
damals ein Novum.

Sagt mal: 90 % sind doch alles (arg) alte Säcke hier? Gingen die
NeXT-Rechner Ende der 1980er/1990er komplett an euch vorbei? Damals nie
c't oder damals andere relevante Magazine abseits von "DOS" oder Chip
gelesen? Gar noch die Byte via Bahnhofskiosk? Dagegen war damals doch
praktisch *alles* im x86-Bereich - insbesondere (!) im Zusammenhang mit
DOS oder gar noch Windows - doch allenfalls Valium/Kernschrott (meist
dazu noch ebenfalls arg überteuert), was wiederum an mir komplett vorbei
ging. Da laaangweilig... ;-)

Klar, einen NeXT konnte ich damals auch mir privat nicht leisten - die
Zielgruppe waren erstmal eh nur Kunden à la CERN -, dafür etwas später
immerhin einen Archie samt ARM-RISC-CPU. ;-)

Post by Stefan Ram
- Festplatten nennt er "Winchester". Der NeXT hatte in der
Standardausführung keine.

Allererste Geräte mit MO-Laufwerk. Damals mindestens so ein heißer
geiler Scheiß wie heute AI/KI.

(Das Gros der Privatanwender in Deutschland hatte damals - 1988 - nicht
mal eine Festplatte, man war gerade in der DOS-PC-Welt oft schon froh,
wenn man eine zweite 5,25"-Floppy hatte. Und wenigstens einen i8086,
keinen i8088.)

Immer mal daran denken, über welche Zeit wir hier sprechen.

Damals kostete auch ein brauchbarer IBM PS/2 hierzulande ganz schnell
mal (deutlich) mehr als 10000 Mark. Und da war noch nicht mal OS/2 oder
gar irgendein Unix-Derivat (sinnvoll ab i386 wegen MMU, dazu natürlich
RAM: teuer, teuer) dabei, von DEC/VAX, Sun, SGI und Co. ganz zu
schweigen...

Post by Stefan Ram
- Außerdem hat jedes System einen TCP/IP-Stack, den "Standard
im Bereich der Hochschulen". Hier denkt man natürlich wieder
an Lee, der auf einem NeXT sein WWW entwickelte.

TCP/IP per Default war der Grund. Und natürlich der NeXT-Rechner samt
seiner hohen GUI-Usability und mitgelieferten
(GUI-Rapid-)Entwicklertools für den ersten Webbrowser. Mac auf Steroiden
trifft es sehr gut. Im Vergleich war damals auch eine Sun oder gar SGI
Kernschrott, was das GUI unter Unix angeht.

Außerdem hatte er das Teil am CERN halt zur Verfügung.

[Michael Noe]

Post by Stefan Ram
- Ein Programm des NeXT hieß "Browser". (Lee entwickelte das Web
wohl später auf einem NeXT-Computer.)

Ist hier wohl der Dateimanger von NeXTStep gemeint? Damit vor allem
"Browser View". Seit Mac OS X Cheetah - das heutige macOS, letztlich ein
umbenanntes/weiterentwickeltes NeXTStep - 2001 als Spaltendarstellung
(auf deutschen Systemen) bis heute im Finder wie unter NeXTStep
verfügbar. Nutze ich bis heute primär besonders gerne gegenüber "Listen"
und/oder "Icons".

Bei Rhapsody/Mac OS X Server 1.0 von 1999 (suche mal nach Screenshots)
sieht man den Übergang seht gut. Bundles (".app") samt Copland/Mac OS
8-Optik und allerlei offensichtliche NeXTStep-"Einflüsse". ;-)

Damalige Mac OS X-Themen wie Rhapsody/Blue Box/Yellow Bow und vor allem
auch Carbon führen hier jetzt zu weit. Habe aktuell wegen Hausbau auch
nicht wirklich die Zeit für größere Erläuterungen.

Google/Wikipedia/Seiten zur NeXTStep|macOS-History existieren. ;-)

Post by Stefan Ram
- Das System enthält ein Programm, das die Gestaltung von GUIs
ohne Programmierung erlauben soll, aber solche "vereinfachten"
System erlauben meiner Meinung nach, es nur eine beschränkte
Art von GUI-Programmen damit zu entwickeln.

WebObjects? Developer Tools? "Project Builder/Interface Builder"? ;-)

AFAIR basiert auch Apples XCode auf dem Mac genau darauf.

Ansonsten sind die Stichworte bei NeXTStep|macOS, wie bereits erwähnt,
natürlich primär Objective-C, seit zehn Jahren zunehmend auch SWIFT.
(Damit auch iOS/iPadOS/tvOS/watchOS usw., da auch all dies seinen
Ursprung in NeXTStep hat und ein Derivat davon ist.)

Sehr frühe Versionen von System 1 bis teils System 7 (klassisches Mac
OS) waren noch in Pascal geschrieben, wie hier erwähnt wurde, das ist
richtig. Auch die damaligen (Old World) ROMs aka Firmware.

Post by Stefan Ram
- Jobs legt Wert darauf, daß man auf dem System Zugriff auf
eine "digitale Bücherei" mit Wörterbüchern und den Werken
Shakespeares hat, samt Volltextsuche.

Als Lexikon ("Dictionary.app") auch unter macOS Sonoma vorinstalliert.
Bundles unter macOS sind übrigens auch so ein "Überbleibsel" von
NeXTStep.

Post by Stefan Ram
- Heute eine Selbstverständlichkeit, aber damals mit vielen
Klangbeispielen zeitaufwendig demonstriert: Das System kann
Tonaufzeichnungen wiedergeben und Instrumente synthetisieren
(so etwas wie "Midi-Dateien abspielen").

Die NeXT-Rechner hatten neben dem MC68030/40 samt FPU noch einen
Motorola-DSP, welcher prädestiniert für Audio-Bearbeitung war. Das war
damals ein Novum.

Sagt mal: 90 % sind doch alles (arg) alte Säcke hier? Gingen die
NeXT-Rechner Ende der 1980er/Anfang der 1990er komplett an euch vorbei?
Damals nie c't oder damals andere relevante Magazine abseits von "DOS"
oder Chip gelesen? Gar noch die Byte via Bahnhofskiosk? Dagegen war
damals doch praktisch *alles* im x86-Bereich - insbesondere (!) im
Zusammenhang mit DOS oder gar noch Windows - doch allenfalls
Valium/Kernschrott (meist dazu noch ebenfalls arg überteuert), was
wiederum an mir komplett vorbei ging. Da laaangweilig (!), selbst damals
schon in meinem jugendlichen Alter... ;-)

Klar, einen NeXT konnte ich mir damals privat freilich nicht leisten -
die Zielgruppe waren erstmal eh nur Kunden à la CERN ;-) -, dafür etwas
später immerhin einen Archie samt ARM-RISC-CPU. :-)

Post by Stefan Ram
- Festplatten nennt er "Winchester". Der NeXT hatte in der
Standardausführung keine.

Allererste PC-Geräte mit MO-Laufwerk. Damals mindestens (!) so ein
heißer geiler Scheiß wie heute AI/KI.

(Das Gros der Privatanwender in Deutschland hatte damals - 1988 - nicht
mal eine Festplatte, man war gerade in der DOS-PC-Welt oft schon froh,
wenn man eine zweite 5,25"-Floppy hatte. Und wenigstens einen i8086,
keinen i8088. CGA, Grün, blablubb...)

Immer mal daran denken, über welche Zeit wir hier sprechen.

Damals kostete auch ein brauchbarer IBM PS/2 hierzulande ganz schnell
mal (deutlich) mehr als 10000 Mark. Und da war noch nicht mal OS/2 oder
gar irgendein Unix-Derivat (sinnvoll ab i386 wegen MMU, dazu natürlich
RAM: teuer, teuer) dabei, von DEC/VAX, Sun, SGI und Co. ganz zu
schweigen...

Post by Stefan Ram
- Außerdem hat jedes System einen TCP/IP-Stack, den "Standard
im Bereich der Hochschulen". Hier denkt man natürlich wieder
an Lee, der auf einem NeXT sein WWW entwickelte.

TCP/IP per Default war der Grund. Und natürlich der NeXT-Rechner samt
seiner hohen GUI-Usability und mitgelieferten
(GUI-Rapid-)Entwicklertools für den ersten Webbrowser. Mac auf Steroiden
trifft es sehr gut. Im Vergleich war damals auch eine Sun oder gar SGI
Kernschrott, was das GUI unter Unix angeht.

Außerdem hatte er das Teil am CERN halt zur Verfügung.

Letztendlich gerade geschrieben unter NeXTStep...

[Dennis Grevenstein]

Post by Michael Noe
Als Lexikon ("Dictionary.app") auch unter macOS Sonoma vorinstalliert.
Bundles unter macOS sind übrigens auch so ein "Überbleibsel" von
NeXTStep.

Das benutze ich übrigens seit Jahren durchaus gerne. Gerade beim
Schreiben größerer englischer Texte fand ich das Oxford dictionary
sehr hilfreich. Diese .app ist viel einfacher zu erreichen als
irgendeine webseite.

Post by Michael Noe
Sagt mal: 90 % sind doch alles (arg) alte Säcke hier? Gingen die
NeXT-Rechner Ende der 1980er/Anfang der 1990er komplett an euch vorbei?

Ja. Meine Eltern haben Atari und DOSen gekauft. In der erweiterten
Familie gab es einen Amiga.

Post by Michael Noe
Mac auf Steroiden
trifft es sehr gut. Im Vergleich war damals auch eine Sun oder gar SGI
Kernschrott, was das GUI unter Unix angeht.

Da man von Steroid (Testo)-Abusus kurzfristig dicke Muskeln und
langfristig kleine Hoden bekommt, dürfte damit das Schicksal von
NeXT durchaus gut beschrieben sein.

gruss,
Dennis

[Michael Noe]

Post by Dennis Grevenstein

Post by Michael Noe
Als Lexikon ("Dictionary.app") auch unter macOS Sonoma vorinstalliert.
Bundles unter macOS sind übrigens auch so ein "Überbleibsel" von
NeXTStep.

Das benutze ich übrigens seit Jahren durchaus gerne. Gerade beim
Schreiben größerer englischer Texte fand ich das Oxford dictionary
sehr hilfreich. Diese .app ist viel einfacher zu erreichen als
irgendeine webseite.

Dieses Programm taugt für allerlei, auch als Duden.

Post by Dennis Grevenstein

Post by Michael Noe
Sagt mal: 90 % sind doch alles (arg) alte Säcke hier? Gingen die
NeXT-Rechner Ende der 1980er/Anfang der 1990er komplett an euch vorbei?

Ja. Meine Eltern haben Atari und DOSen gekauft. In der erweiterten
Familie gab es einen Amiga.

Einen Amiga 4000 besitze ich noch immer. Kam darüber wegen ShapeShifter
zum Mac. :-)

DOSen gingen wegen massivem Desinteresse damals privat praktisch
komplett an mir vorüber. Aber so ein Atari TT oder Falcon (ebenfalls mit
DSP wie die NeXT-Rechner), die hatten schon was.

Post by Dennis Grevenstein

Post by Michael Noe
Mac auf Steroiden trifft es sehr gut. Im Vergleich war damals auch eine
Sun oder gar SGI Kernschrott, was das GUI unter Unix angeht.

Da man von Steroid (Testo)-Abusus kurzfristig dicke Muskeln und
langfristig kleine Hoden bekommt, dürfte damit das Schicksal von
NeXT durchaus gut beschrieben sein.

;-)

Naja, mit macOS als die Weiterentwicklung von NeXTStep/OPENSTEP über
Rhapsody hat es letztendlich seine heutige extrem weite Verbreitung
gefunden.

<https://de.wikipedia.org/wiki/Rhapsody_(Betriebssystem)>

Selbst watchOS basiert darauf, vom iPhone und Co. ganz zu schweigen.

Tja, und Xcode als integrierte Entwicklungsumgebung für alle aktuellen
Apple-Plattformen ist praktisch ebenenso ein direkter blutsverwandter
Nachkomme der NeXTStep-Entwicklungstools.

Übrigens war auch die Gründung von ARM Limited 1990 ein Joint Venture
von Acorn, VLSI Technology und Apple (dort früher verwendet im Newton,
seit Jahren auch im Mac).

(Meine Apple Watch hat 1 GByte RAM samt Unix-Kernel und 32 GByte
Flash-Memory, meine erste SCSI-Festplatte hatte 52 MByte, das war eine
Quantum LPS, die übrigens noch heute an einem Amiga 500 läuft. Irgendwie
pervers all dies. ;-))

[Dennis Grevenstein]

Post by Michael Noe
Naja, mit macOS als die Weiterentwicklung von NeXTStep/OPENSTEP über
Rhapsody hat es letztendlich seine heutige extrem weite Verbreitung
gefunden.

Das ist mehr wie das ehrliche, langfristig harte Training.
Dicke Muskeln, weil Du Dich lange Zeit gequält und durchgehalten hast.

Ich habe meinen ersten Mac 2002 glaube ich gekauft und das spezifisch,
weil ich OS X so gut fand. Ich bin vorher bei Gravis gewesen und die
hatten da die Macs zum ausprobieren rumstehen. Ich habe den Typ im
Geschäft gefragt, wie man da eine shell aufmacht und der hat mich
angeguckt als ob ich nach dem schnellsten Weg zum Mars frage, aber
nach ein bisschen rumspielen habe ich das dann gefunden.

Rückblickend hätte ich einen Mac mit alter NeXT Oberfläche wohl
nicht gekauft. Es war schon die moderne OS X GUI, die mir gefallen
hat. Auch Rhapsody ist für mich allenfalls "almost there".
Wirklich gekauft hätte ich es nicht, wobei ich damals als es aktuell
war gar nicht davon gewusst habe.

btw:

$ telnet splen
Trying 192.168.2.162...
Connected to splen
Escape character is '^]'.
login: root
Password:
Copyright (c) Apple Computer, Inc. 1997

Welcome to Rhapsody!

You have new mail.
tset: terminal type xterm-256color is unknown
Terminal type? xterm
splen:1# uname -a
Rhapsody splen 5.1 Rhapsody Operating System Release 5.1: Fri Apr 17 13:07:52 PDT 1998; root(rcbuilder):Objects/kernel-105.6.obj~2/RELEASE_I386 Copyright (c) 1988-1995,1997 Apple Computer, Inc. All Rights Reserved. i386
splen:2# hostinfo
Mach kernel version:
Rhapsody Operating System Release 5.1:
Fri Apr 17 13:07:52 PDT 1998; root(rcbuilder):Objects/kernel-105.6.obj~2/RELEASE_I386
Copyright (c) 1988-1995,1997 Apple Computer, Inc. All Rights Reserved.


Kernel configured for a single processor only.
1 processor is physically available.
Processor type: i586 (Intel 80586)
Processor active: 0
Primary memory available: 64.00 megabytes.
Default processor set: 35 tasks, 77 threads, 1 processors
Load average: 1.51, Mach factor: 0.16


Das ist natürlich irgendwie witzig, aber triggert mehr mein
geschichtliches Interesse. Ich hätte damit wohl nicht jeden
Tag arbeiten wollen.

gruss,
Dennis

[Başar Alabay]

Post by Michael Noe

Post by Dennis Grevenstein

Post by Michael Noe
Als Lexikon ("Dictionary.app") auch unter macOS Sonoma vorinstalliert.
Bundles unter macOS sind übrigens auch so ein "Überbleibsel" von
NeXTStep.

Das benutze ich übrigens seit Jahren durchaus gerne. Gerade beim
Schreiben größerer englischer Texte fand ich das Oxford dictionary
sehr hilfreich. Diese .app ist viel einfacher zu erreichen als
irgendeine webseite.

Dieses Programm taugt für allerlei, auch als Duden.

Vor allem als Thesaurus. Man kann sich dafür Plugins laden. Suchen und
laden. HIer derzeit aktiv: OpenThesaurus Deutsch, Wikipedia, Oxford
German Dictionary, Oxford Dictionary of English, Arabic,
Duden-Wissensnetz deutsche Sprache, Arkadaş Türkçe Sözlük.

Ah, ich sehe gerade, daß bei Tekl ein neues OpenThesaurus Deutsch
existiert.

B. Alabay