UNIX V2 „Beta“ von 1972 wiederbelebt

 (tuhs.org)
2 Punkte von GN⁺ 2025-02-21 | 1 Kommentare | Auf WhatsApp teilen
  • Durch eine forensische Analyse von s1/s2 der DMR-Bänder wurde ein lauffähiges UNIX-System zusammengestellt; s1 ist ein UNIX INIT DECtape mit dem Kernel, s2 enthält den Großteil der Distributionsdateien
  • Der s1-Kernel ist der bislang früheste bestätigte maschinenlesbare UNIX-Kernel; er liegt zwischen V1 und V2 und kann sowohl V1- als auch V2-a.out-Dateien ausführen
  • Die Größe des User Core wurde wie bei V2 auf 16 KiB (8K words) erhöht, die syscall table entspricht jedoch V1 und dem unix-jun72-Kernel und enthält keine V2-syscalls
  • Die Boot-Bedingungen sind anspruchsvoll: Nur aaps PDP-11/20-Emulator konnte den Kernel booten; SIMH und Ersatz-11 bleiben vor dem Login-Prompt hängen
  • Das veröffentlichte RF-Disk-Image enthält nur Dateien von s1/s2, ist im aap-Emulator bootfähig, und aufgrund des Verhaltens von init(7) scheint /usr auf der RF gelegen zu haben

Aus s1/s2-Bändern wiederhergestelltes UNIX V2 „Beta“

  • Eine forensische Analyse der DMR-Bänder ergab, dass sich aus den s1/s2-Bändern ein lauffähiges System erstellen ließ
    • Die DMR tapes sind das untersuchte Bandpaket
    • Das s1 tape ist ein UNIX INIT DECtape, das den Kernel enthält
    • Das s2 tape enthält den Großteil der Distributionsdateien
  • Der s1-Kernel ist der bislang früheste bestätigte maschinenlesbare UNIX-Kernel und liegt zwischen V1 und V2
    • Der unveränderte unix-jun72-Kernel unterstützt nur V1-a.out
    • Der s1-Kernel kann standardmäßig sowohl V1- als auch V2-a.out-Dateien ausführen
    • Die Größe des User Core wurde von 8 KiB (4K words) auf 16 KiB (8K words) erhöht
  • Die syscall table entspricht V1 und dem unix-jun72-Kernel
    • V2-syscalls sind nicht enthalten
    • In Bezug auf syscalls ist er näher an V1, während Core-Größe und Ausführung von V2-Binaries V2-Eigenschaften zeigen; daher wird er als „V2 beta“ betrachtet
  • Auf dem System können ed, cc und a.out ausgeführt werden
    • In der Beispielsitzung wird ein hello world!-Programm geschrieben, kompiliert und ausgeführt

Boot-Einschränkungen und RF-Disk-Image

  • Die bootfähigen Umgebungen sind begrenzt
    • Nur aaps PDP-11/20 emulator konnte den Kernel erfolgreich booten
    • SIMH und Ersatz-11 bleiben hängen, bevor sie den Login-Prompt erreichen
  • Der ursprüngliche Installationsprozess bestand darin, von s1 zu booten und anschließend die Dateien von s2 wiederherzustellen
    • Der aap-Emulator unterstützt TC11 nicht, weshalb eine direkte Installation von den s1/s2-Bändern schwierig ist
  • Die tatsächliche Konfiguration erfolgte über den Umweg, ein RF-Disk-Image zu erstellen
    • Die Dateien des s1 tape wurden extrahiert und auf einer leeren RF-Disk platziert
    • Danach wurde der unix-jun72-Kernel installiert und in SIMH von RF gebootet
    • Die restlichen Dateien von s2 wurden extrahiert
    • Zum Schluss wurde der unix-jun72-Kernel mit einem hex editor durch den s1-Kernel ersetzt
  • Das erzeugte RF-Image enthält nur Dateien von s1/s2
  • Das Programm init(7) mountet RK nicht unter /usr
    • Dieses Verhalten deutet darauf hin, dass /usr auf der RF gespeichert war

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-21
Hacker-News-Kommentare

  • Das erinnert mich an einen Witz, den ich in einem Vortrag von Brian Kernighan gehört habe. Die Geschichte war, dass Ken Thompson in 3 Wochen einen Texteditor, einen B-Compiler und ein Grundgerüst für Ein-/Ausgabe und Dateiverwaltung gebaut hat und daraus am Ende UNIX wurde
    Die Pointe des Witzes ist, dass wir heute wohl ein wenig weniger effizient sind als damals

    • Ken ist natürlich ein Programmierer der Spitzenklasse, und wenn so jemand sich 3 Wochen lang konzentrieren kann, lässt sich wirklich eine Menge schaffen
      Soweit ich mich erinnere, war seine Frau mit den Kindern in England, sodass Ken im Grunde tun konnte, was er wollte. Natürlich hatte er auch schon sehr viel Erfahrung, bevor er das erste UNIX schrieb
      Für Programmierer, die ein Projekt im Kopf haben, wäre das einen Versuch wert. Man zieht sich für 3 Wochen in eine Hütte oder so zurück, weg von Arbeit und Familie, nimmt die nötigen Bücher und Unterlagen mit und kappt das Internet. Wenn möglich, benutzt man ein Feature-Phone und schaut, wie weit man kommt
      Es sollte allerdings ein Projekt sein, das bereits gut durchdacht ist und für das vielleicht schon etwas Code existiert. Je mehr ich darüber nachdenke, desto besser passt so ein Experiment zu Low-Level-Projekten, die kaum auf externe Bibliotheken angewiesen sind. Wenn ein Projekt auf einem Haufen Third-Party-Libraries aufbaut, bleibt man ohne Internet bei Problemen schnell stecken, und Ken hat sich offenbar genau das richtige Projekt ausgesucht
    • Das Interview gibt es hier: https://www.youtube.com/watch?v=EY6q5dv_B-o
      Es dauert eine Stunde, und Thompson erzählt viele interessante Geschichten. Kernighan macht das hervorragend und gibt Thompson den Raum, einfach zu erzählen
    • Der moderne Witz dazu ist, dass Ken Thompson zusammen mit Rob Pike und Robert Griesemer Go entworfen hat, während sie auf C-/C++-Kompilierung warteten
    • Ich frage mich, wie die frühen UNIX-Entwickler dieses Produktivitätsniveau erreichen konnten
      Ob sie eher wie von 9 bis 17 Uhr gearbeitet haben oder in den Goblin-Modus gegangen sind, alles andere im Leben beiseitegeschoben haben und nur noch fertig werden wollten
    • Die ersten 80 % der Funktionalität eines Projekts gehen manchmal wirklich schnell. Besonders dann, wenn es einen interessiert und man hoch motiviert ist
      Aber die restlichen 20 % ziehen sich wie ein langer Schwanz hin und werden meist zu einer gewaltigen Plackerei, die einem die Motivation austreibt

  • Faszinierend genug, dass selbst Spock beeindruckt wäre. Ich würde gern lernen, wie man auf dem Mac einen PDP-11-Emulator kompiliert

    • Einen Emulator zu kompilieren ist ziemlich einfach. Schau dir simh an. Es ist sehr portabel und sollte fast sofort laufen
      Danach lohnt es sich, die Installation einer 2.11BSD-Distribution zu versuchen. Sie ist gut dokumentiert und stammt aus einer Zeit, als ein Großteil der Verwirrung der frühen Unix-Ära schon vorbei war. Danach hat es auch viel Spaß gemacht, mit RT-11 zu spielen, und ich habe darauf tatsächlich ein paar kleine Apps geschrieben
    • https://opensimh.org/
      Läuft auch auf Apple Silicon gut
    • Es fühlt sich an wie der Moment, in dem man mit einem Metalldetektor ein religiöses Artefakt findet
    • Viel zu einfach! Ich baue mir direkt selbst eins aus NAND-Gattern

  • Wirklich großartig
    Ich sehe zum ersten Mal, dass Leute ed für echte Arbeit benutzen
    Und ich frage mich auch, wer sonst noch mit ed arbeiten musste. Ich musste vor Kurzem auf ein uraltes System ohne vi zugreifen und habe deshalb selbst einen Editor gebaut; falls jemand einen Editor für antike Systeme braucht, kann er sich gern melden. Sehr schick ist er nicht
    Die Arbeit der Leute, die diese Software gebaut haben, und der Forschenden ist beeindruckend, und ich habe großen Respekt vor echten Ingenieuren

    • Ich erinnere mich, in den 1960ern auf einem Honeywell-Time-Sharing-System über ein Teletype ASR-33 einen ed-ähnlichen Editor benutzt zu haben
      Ich erinnere mich nicht mehr genau, aber beim Anlegen einer neuen Datei startete man ihn mit make . Wenn man make love eingab, wurde vor dem Start des Editors not war ausgegeben
    • Nicht ed, aber eindeutig davon beeinflusst: Ich bin alt genug, um in einem Maschinenschreibkurs Prüfungen mit edlin unter MS-DOS 3.3 gemacht zu haben
      Danach habe ich es nie wieder benutzt, und auch ein paar Jahre später, als ich Xenix verwenden konnte, habe ich kein ed benutzt. vi war die deutlich vernünftigere Alternative
    • Im August habe ich mit ed in Termux auf meinem Handy http://canonical.org/~kragen/sw/dev3/justhash.c geschrieben
      Jemand meinte, er benutze auf dem Handy ed, weil die Android-Bildschirmtastatur für vi einfach zu grauenhaft sei, und das stimmte tatsächlich, also habe ich es ausprobiert. Auf dem Handy war ed etwas weniger schlimm als vi, aber beide sind auf unterschiedliche Weise schlecht
      Mit HeliBoard war es deutlich einfacher, ed-Befehle über die Tastatur einzugeben als vi-Befehle, aber ein paarmal haben mich Pufferzustände verwirrt, die unter vi wohl kein Problem gewesen wären. Vielleicht würde es mit Übung besser, aber am Ende bin ich wieder zu vi zurückgekehrt
    • Mitte der 90er hatte ich ein AT&T 3B2, auf dem es nur ed gab, und ich habe es mit einem DEC-VT-102-Terminal benutzt
      ed funktioniert schon, aber nach heutigen Maßstäben macht es keinen Spaß. Verglichen mit Fernschreiber-Ausgabe muss die Nutzung auf einem Bildschirm aber gewaltig gewesen sein
      Außerdem konnte der 3B2 mit seinen ungefähr 1 MIP etwa 20 gleichzeitige Nutzer verkraften
    • Einer meiner frühen Consulting-Jobs war es, ein ed-Tutorial für ein Coherent-System zu schreiben
      Ich benutze ed oft und habe es tatsächlich sogar gestern noch verwendet. Ich musste etwas bearbeiten, ohne den Bildschirm zu löschen
      Davor hatte ich auch schon einen Editor für auf Platte gespeicherte Kartenabbilder gebaut; der war sehr primitiv

  • Ich schaue gelegentlich gern in die tuhs-Mailingliste. Es ist großartig, dort Namen wie Ken Thompson und Rob Pike zu sehen, ebenso wie viele weniger bekannte Namen von Leuten, die an der frühen UNIX- und Computing-Szene beteiligt waren

  • Wirkt wie Software-Archäologie

    • Einer der vielen Gründe, warum ich das SaaS-Zeitalter nicht mag, ist, dass so etwas nie wieder passieren wird. Niemand wird 2075 ein altes Notion oder Figma für Forschung oder aus Nostalgie booten.
      Wie Kultur, die in sozialen Medien produziert und konsumiert wird, oder viele andere Formen der Internetkultur ist all das völlig flüchtig und Wegwerfware. Keine Geschichte und keine Zukunft.
      SaaS ist nicht nur einfach geschlossen, sondern oft faktisch und ganz wörtlich an genau eine einzelne Installation gebunden. Man könnte sie vielleicht archivieren und anderswo booten, aber das Jahre später ohne das ursprüngliche Team zu tun, wäre eine viel größere Aufgabe, als Unix von 1972 in einem Emulator auf einem modernen PC zu booten.
      Dieses Unix hatte Handbücher und wurde so entworfen, dass es in verschiedenen Umgebungen installiert und ausgeführt werden konnte. SaaS ist eher ein Gebräu, das nur seine Urheber deployen können, nicht unbedingt aus Absicht, sondern weil die evolutionären Kräfte fehlen, die dazu drängen würden, es so zu bauen.
      Oft ist es intern auch noch mit anderer SaaS verflochten, sodass man möglicherweise den gesamten Zustand der Cloud konservieren und wiederherstellen müsste, als wäre proprietäre Software ein einziger globaler Computer, der direkt an Ort und Stelle bearbeitet wird.
    • Ist nicht so cool, wie es klingt

  • Kann jemand Referenzen dazu geben, was diese Dateiberechtigungen bedeuten? Ich kann es grob erraten, aber ich finde nichts zu Unix-v2-Berechtigungen.
    Die ls-Ausgabe sieht vertraut aus, nur der Teil sdrwrw ist mir fremd.

    • In dem Mailinglisten-Thread hat jemand auf eine extrahierte Manual-Seite verlinkt.
      https://gitlab.com/segaloco/v1man/-/blob/master/man1/stat.1?...
      Bei sdrwrw ist die erste Spalte s oder l und bedeutet small bzw. large. Die zweite Spalte ist d, x, u oder - und bedeutet Verzeichnis, ausführbar, setuid bzw. nichts. Der Rest sind die Lese-/Schreib-Bits für Eigentümer und Nicht-Eigentümer.

  • Hello World ist 1328 Byte groß? Ganz schön aufgebläht!

    • Das erinnert mich an einen Compiler, der aus Spaß lange Gedichte in jedes Binary eingebaut hat. Von Magic Numbers hat man gehört, aber das hatte gewissermaßen ein magisches Sonett.
      Ich dachte, es sei ein früher Rust-Compiler gewesen, aber ich finde nichts dazu. Vielleicht war es auch Go.
      Korrektur: Gefunden. 'rust-lang/rust#13871: "hello world" contains Lovecraft quotes' https://github.com/rust-lang/rust/issues/13871
    • Mein https://github.com/pts/minilibc686 schafft auf i386 ein Hello World mit printf in unter 1 KiB. Ein Hello World mit write liegt unter 170 Byte.
    • Zeit, mein Unix zu tunen!

  • Großartig. Kann ich durch dieses Zeitportal gehen und in einer alternativen Realität leben?

    • Du meinst die Zeit, als verbleites Benzin verwendet wurde, Zigarettenrauch überall selbstverständlich war und Asbest in allem steckte, was man sich vorstellen konnte? Ein faszinierendes Jahrzehnt, aber die Lebensqualität ist seitdem vermutlich enorm gestiegen.
    • Geht tatsächlich. Man muss nur ein echtes VT-Terminal kaufen, zum Beispiel so etwas wie https://www.ebay.com/itm/176698465415?_skw=vt+terminal&itmme...
      Dann besorgt man sich einen Adapter für den Anschluss an einen Computer und lässt das gewünschte *nix in simh laufen. Als Referenz empfehle ich https://jstn.tumblr.com/post/8692501831.
      Wenn es läuft, schiebt man die Host-Maschine hinter den Schreibtisch oder an einen Ort, wo man sie nicht sieht, und kann leben, als wäre es 1980.

  • Wenn man ein RF-Band wiederherstellt, zeigt schon eine einfache Textdatei den Pufferbereich, den DOS oder .iso-Dateien nicht nutzen.
    Auch bei einer 2.11BSD-Distribution müssen grundlegendes Tiling und der Window-Manager im nativen OS installiert werden. Deshalb verwendet man dann eben KDE oder einen X11-Window-Manager.