NeXTnet: Das Verzeichnis für NeXT-Rechner und sein Plan

NeXTnet
2. November 2026
PAP-032

NeXTnet ist ein Verzeichnis für NeXT-Rechner: Eine App auf der Maschine registriert sie und meldet Modell, Ausstattung und Laufzeit, eine Website zeigt jede registrierte Maschine mit Besitzer, Standort und Online-Zustand, und eine Weltkarte zeigt, wo sie stehen. Dieses Paper ist der Plan: NeXTSTEP 3.3 und OPENSTEP 4.2 auf schwarzer Hardware, ein Inventar aus Mach-Aufrufen und dem Start-Protokoll des Kernels, ein Protokoll mit signierten Anfragen über Klartext-HTTP, ein Rust-Backend mit PostgreSQL und eine Astro-Website als Container, die sich zwischen Hosts nur in Umgebungsvariablen unterscheiden, ein Client in Objective-C aus AppKit-App und Meldeprozess, ein Repository für alles und vier Lieferphasen.

1. Was NeXTnet ist

NeXTnet ist ein Verzeichnis für NeXT-Rechner. Ein Besitzer legt auf der Website ein Konto und darin seine Maschine an. Auf der Maschine selbst registriert die AppKit-App die NeXT mit einem Code von der Website, und ein Meldeprozess sendet von da an die Ausstattung der Maschine und alle zehn Minuten ein Lebenszeichen. Die Website zeigt jede registrierte Maschine: welches Modell es ist, wie es ausgestattet ist, wem es gehört, wo es steht, ob es online ist und wie lange es läuft. Eine Weltkarte zeigt die Standorte.

Der Client läuft unter NeXTSTEP 3.3 und OPENSTEP 4.2 auf der Hardware von NeXT. Backend und Website laufen als Container und sind so zugeschnitten, dass dieselben Dienste ohne Änderung des Codes auf jedem Host laufen, der Container ausführt.

2. Gegenstand und Grenzen

Dieses Paper plant NeXTnet. Jede Aussage über NeXTSTEP und OPENSTEP nennt ihre Quelle: die Entwicklerdokumentation von NeXTSTEP 3.3, das Support-Archiv NeXTanswers, Handbuchseiten, einen Kernel-Quelltext von NeXT oder den Quelltext des Emulators Previous. Kein Programm wurde auf einem NeXTSTEP-System ausgeführt. Was sich nur dort klären lässt, steht als offen im Text und als Prüfpunkt in Anhang B. Die Rohnotizen der Recherche liegen unter sources/ neben diesem Dokument.

3. Zielplattformen

Der Client, die AppKit-App mit ihrem Meldeprozess, unterstützt NeXTSTEP 3.3 und OPENSTEP 4.2 auf der schwarzen Hardware von NeXT, also den 68040-Maschinen NeXTcube, NeXTstation und ihren Turbo- und Color-Varianten sowie dem 68030-Cube. NeXTSTEP 3.3 wird zuerst gebaut, weil es auf jeder dieser Maschinen läuft¹ und der Stand ist, den der Emulator Previous und das Projekt Previously vorbereiten.² OPENSTEP 4.2 für Mach folgt im selben Schritt, weil es auf derselben Hardware läuft und die letzte gefundene Ausgabe für sie ist.³

Die beiden Systeme haben eine Schnittstelle gemeinsam und unterscheiden sich in einer zweiten. Foundation ist auf beiden da: in 3.3 als statische Bibliothek mit 22 Klassen, die NeXT als OpenStep-konform bezeichnet, in 4.2 als Framework nach dem Foundation-Teil der OpenStep-Spezifikation. Code gegen die 3.3-Bibliothek muss für 4.x neu übersetzt werden, läuft dann aber gegen dieselben Klassen.⁴⁵ Das Application Kit ist auf beiden ein anderes: Das von 3.3 steht auf der Wurzel Object, das von OpenStep auf NSObject mit neuen Namen, und NeXT beschreibt den Weg vom einen zum anderen als Konvertierung des Quelltexts mit tops-Skripten in sechs Stufen, nicht als Schicht, die beides ausführt.⁵

Daraus folgt der Zuschnitt. Alles, was nicht Oberfläche ist, also Protokoll, Signatur, Inventar, Dateien und die Steuerung der App, ist eine Quelle in Objective-C auf Foundation und wird zweimal übersetzt: auf dem 3.3-Abbild gegen die statische Bibliothek, auf dem 4.2-Abbild gegen das Framework. Der Meldeprozess besteht nur aus dieser Quelle. Die AppKit-App hat darüber zwei dünne Oberflächenschichten, eine gegen das Application Kit von 3.3 und eine gegen das OpenStep Application Kit, jede mit ihren Nib-Dateien aus dem Interface Builder des jeweiligen Systems. Beide rufen denselben Controller in der Bibliothek, so dass jede Entscheidung genau einmal existiert und die Schichten nichts enthalten als die Verbindung von Control und Aufruf. Das kostet zwei Entwicklungsabbilder in Previous, zwei Build-Ziele im Makefile, zwei Nib-Sätze, zwei Installer-Pakete je Ausgabe, weil die Binaries je System gegen eine andere Foundation gelinkt sind, und einen Testlauf auf jedem System vor jedem Release. Ob ein 3.3-Binary auf 4.2 unverändert läuft, ist offen (Anhang B). Läuft es, reicht für den Meldeprozess ein Build für beide Systeme, und die 4.2-Schicht der App bleibt für das native Aussehen.

NeXTSTEP 3.3 lief auch auf Intel-PCs, auf HP 9000 der Serien 712 bis 755 und auf SPARCstation 5, 10 und 20.¹ Das Verzeichnis nimmt solche Maschinen an und führt die Architektur als Feld, weil ein Besitzer sein NeXTSTEP auf einem HP 712 genauso zeigen will und der Client dafür nur ein Fat Binary mehr braucht. In der Liste und auf dem Globus sind sie standardmäßig sichtbar und als Fremdhardware gekennzeichnet, weil ein Besitzer seine Maschine anlegt, damit man sie sieht; in der Bestenliste zählen sie nicht. Emulatoren werden ebenfalls angenommen, sind genauso sichtbar und als solche gekennzeichnet, mit den Merkmalen aus Abschnitt 4, weil Previously selbst ein Emulator ist und seine Nutzer dieselben Besitzer sind. Gebaut wird der Client zuerst für m68k; die Fat Binaries für Intel, PA-RISC und SPARC stehen im Backlog, und Maschinen dieser Architekturen erscheinen, sobald es sie gibt.

4. Hardware-Inventar unter NeXTSTEP

NeXTSTEP hat kein Werkzeug, das die Hardware einer Maschine als Liste zeigt. Was ein Programm über die eigene Maschine erfährt, kommt aus Mach-Aufrufen, aus dem Kernel-Protokoll des Starts und aus wenigen Werkzeugen. Tabelle 1 ist der Plan: Welche Angabe der Client sammelt, woher, und wie sicher die Quelle ist.

Die Ethernet-Adresse ist das einzige hardwaregebundene Merkmal einer schwarzen Maschine. Sie wird darum als Fingerabdruck mitgeschickt, um dieselbe Maschine beim zweiten Registrieren zu erkennen, aber sie ist nicht die Identität. Die Identität ist das Credential aus Abschnitt 6.

Emulatoren erkennt der Server an Merkmalen, die Previous aus seiner Konfiguration baut: eine der festen Ethernet-Adressen seiner ROM-Abbilder (00:00:0f:00:30:90, 00:00:0f:00:f3:02, 00:00:0f:12:34:56), der Hersteller Previous in der SCSI-Kennung unbekannter Plattenabbilder, der Hostname previous und die Adresse 10.0.2.15 des emulierten Netzes.²¹³ Weil der Besitzer die Adresse ändern kann, bleibt die Erkennung ein Hinweis, und der Besitzer kann die Maschine auf der Website selbst als Emulator kennzeichnen.

Alles in Tabelle 1 mit dem Stand schwach rechnet mit Quellen, die aus Handbuch und Kernel-Quelltext belegt sind, aber nicht auf einem laufenden 3.3 geprüft. Die Prüfung ist der erste Schritt des ersten Builds (Anhang B).

Eine Angabe in Tabelle 1 erreicht nur ein Programm mit Verbindung zum Window Server: der Bildschirm. Grenzen und Farbtiefe jedes angeschlossenen Bildschirms liefert NXScreen, und die Liste aller Bildschirme liefert getScreens:count: der Klasse Application; beides sind Antworten des Window Servers, und ein Prozess, der aus /etc/rc.local startet, hat keine Verbindung zu ihm.¹¹ Der NetInfo-Datensatz unter /localconfig/screens ist von der Shell aus lesbar, aber der Window Server ersetzt fehlende Angaben darin durch Vorgaben, so dass der Datensatz unvollständig sein kann.¹¹ Alle anderen Angaben kommen aus Mach, aus dem Start-Protokoll und aus Werkzeugen, die ein Prozess mit und ohne Window Server gleich erreicht. Die Oberfläche hat damit beim Bildschirm einen echten Vorsprung, und Abschnitt 10 zieht daraus die Folge für die Form des Clients.

5. Werkzeugkette und Entwicklungsumgebung

Entwickelt wird mit den Werkzeugen, die NeXTSTEP 3.3 Developer mitbringt. Tabelle 2 nennt sie.

Der Client wird in Objective-C geschrieben, mit Foundation als Grundlage, weil Foundation auf 3.3 und 4.2 vorhanden ist und so Protokoll, Inventar und Zustand in beiden Builds dieselbe Quelle haben. Das Application Kit kommt nur in der AppKit-App vor. Netzcode ist BSD-Sockets in C, in eine Objective-C-Klasse gefasst.

Entwickelt wird in NeXTSTEP 3.3 und OPENSTEP 4.2 im Emulator Previous auf phrancks Mac, mit den beiden Plattenabbildern, die Previously vorbereitet. Previous teilt mit SLiRP und seinem NetInfo-Server automatisch einen Ordner des Mac unter /Net in das Gastsystem, so dass der Quelltext auf dem Mac liegt und im Gast gebaut wird.¹³ Das Gastsystem erreicht das Netz über das Gateway 10.0.2.2 und den DNS 10.0.2.3 des Emulators, der Client kann also aus Previous heraus gegen den Server getestet werden.¹³ Ob die Abbilder die Developer-Werkzeuge unter /NextDeveloper enthalten, ist der erste Prüfpunkt; falls nicht, werden sie von der Developer-CD des jeweiligen Systems nachinstalliert.

Auf eine echte NeXT-Maschine kommt das Paket über das Netz. Der Besitzer lädt den Tarball mit dem Paket auf einem heutigen Rechner herunter und kopiert ihn per FTP oder NFS auf die NeXT; beide gehören zum System, und ein HTTP-Client wie lynx ist Zusatzsoftware aus dem Peanuts-Archiv.²⁵ Dort öffnet der Besitzer das Paketsymbol, und der Installer installiert es.²²

Der erste Build soll sechs Dinge klären: ob der Compiler von 3.3 die geplante Objective-C-Form und ANSI-Prototypen so annimmt, wie der Quelltext sie schreibt; welche Werte host_info, hostinfo und das Start-Protokoll in Previous liefern und wo sie von einer echten Maschine abweichen; ob ein Prozess ohne Root /usr/adm/messages lesen darf; wie groß das gelinkte Binary ist und was es an Speicher braucht, bei 16 MB als kleinster und 24 MB als empfohlener Ausstattung der NeXT-Rechner²⁶; ob die Verbindung aus dem Gast über SLiRP den Server erreicht; und ob das 3.3-Binary auf dem 4.2-Abbild startet.

6. Protokoll und Sicherheit

Ein NeXTSTEP ohne Zusatzsoftware kann kein TLS. Die Ports von OpenSSL, die es für 3.3 und 4.2 gibt, sind Stände der Serien 0.9 und 1.0.2; bei einem Test der RSA-Prüfung auf 68k schlug die Signaturprüfung fehl, und ein weiterer Bericht nennt fehlende Zufallsquellen.³²⁷²⁸ Der Client spricht deshalb Klartext-HTTP, und die Sicherheit liegt in der Nachricht, nicht im Transport: Jede Anfrage ist mit einem Schlüssel signiert, den nur diese Maschine und der Server kennen, und der Schlüssel verlässt die Maschine nie.

Registrierung

Der Besitzer meldet sich auf der Website an, die nur über HTTPS erreichbar ist, und legt dort eine Maschine an. Die Website zeigt einen Einlösecode, zwanzig Zeichen in fünf Gruppen, mit 100 Bit Zufall, der fünfzehn Minuten gilt und genau einmal eingelöst werden kann. Auf der NeXT gibt der Besitzer den Code im Registrieren-Panel der AppKit-App ein. Der Code hat einen öffentlichen Teil, der die wartende Registrierung benennt, und einen geheimen Teil.

Der Client sendet die Registrierung mit dem öffentlichen Teil und dem Inventar und signiert sie mit dem geheimen Teil. Der geheime Teil wird nicht gesendet. Beide Seiten leiten daraus denselben Maschinenschlüssel ab, K = HMAC-SHA-256(Geheimnis, "nextnet-machine-key" || Maschinenkennung). Der Server speichert K zur Maschine, der Client legt K nach /etc/nextnet/machine.key mit Rechten nur für Root. Weil der Code nur über HTTPS angezeigt wird und nie über die Leitung geht, kann ein Mitleser der Registrierung weder den Code noch K gewinnen. Mit 100 Bit ist auch das Durchprobieren gegen eine aufgezeichnete Signatur aussichtslos. Nach fünf falschen Signaturen auf einen Code ist der Code verbrannt.

Signierte Anfragen

Jede weitere Anfrage hat vier Kopfzeilen: die Maschinenkennung, einen Zähler, eine Nonce und die Signatur HMAC-SHA-256(K, Methode || Pfad || Zähler || Nonce || SHA-256(Body)). Der Zähler steigt mit jeder Anfrage und steht auf der Maschine in /etc/nextnet/counter; der Server nimmt nur einen Zähler an, der größer ist als der letzte gesehene, und merkt sich die Nonce der letzten Stunde. Damit ist eine Wiederholung erkannt, ohne dass die Uhr der Maschine stimmen muss, und das ist wichtig, weil die Pufferbatterien dieser Maschinen oft leer sind. Die Zeit im Body ist Information, nicht Prüfmerkmal. SHA-256 und HMAC sind wenige hundert Zeilen C und laufen auf einem 68040 ohne Mühe.

Anfragen und Antworten sind JSON. Antworten sind flach und klein, damit der Client sie mit einem kleinen eigenen Parser liest. Online ist eine Maschine, deren letzter Status höchstens 25 Minuten alt ist, also zwei Meldungen plus Reserve.

Was der Server glaubt

Der Server glaubt der Signatur, dass die Anfrage von der Maschine kommt, deren Kennung sie nennt. Dem Inhalt glaubt er nicht: Jedes Feld wird auf Typ, Länge und erlaubte Zeichen geprüft, das Inventar auf höchstens 200 Einträge, der Body auf höchstens 32 KB. Der Besitzername kommt nie vom Client, sondern vom Konto auf der Website. Tabelle 4 nennt die Grenzen.

Trennung von Client-API und öffentlicher API

Der Client-Endpunkt und die Website haben zwei Hostnamen und zwei Ports im Backend. Die Website liegt hinter HTTPS und liefert unter /api/v1 die öffentliche Lese-API für Listen, Details und Karte; Anmeldung und alles, was ein Konto betrifft, gibt es nur dort. Der Client-Host antwortet ausschließlich auf die Nachrichten aus Tabelle 3 über Klartext-HTTP, ohne Zertifikat und ohne Umleitung auf HTTPS, weil die NeXT beidem nicht folgen könnte; der Reverse Proxy vor dem Backend muss diesen einen Host unverschlüsselt durchreichen. Der Client löst den Namen bei jedem Lauf auf und enthält keine feste Adresse, weil der Host hinter dem Namen wechseln kann und sich Adressen über die Lebensdauer eines Projekts ändern.

Der Client nimmt die Basisadresse des Servers aus seiner Konfigurationsdatei /etc/nextnet/nextnet.conf. Wer die Strecke aus seinem LAN zusätzlich verschlüsseln will, schreibt dort die Adresse eines Reverse Proxy im eigenen Netz hinein, der mit TLS an den Server weiterreicht; das Repository liefert dafür eine Beispielkonfiguration eines Reverse Proxy mit. Die Signaturen bleiben dieselben, der Server behandelt beide Wege gleich.

7. Datenmodell und Datenschutz

Der Standort gehört zur Maschine, nicht zum Besitzer, weil ein Besitzer Maschinen an mehreren Orten haben kann. Der Besitzer setzt ihn auf der Website durch einen Klick in die Karte oder durch Eingabe von Koordinaten. Die Vorgabe rundet auf ein Zehntelgrad, das sind rund elf Kilometer, weil diese Genauigkeit die Weltkarte füllt und die Wohnung nicht verrät; „genau“ wählt der Besitzer je Maschine. Ohne Standort erscheint die Maschine nicht auf dem Globus.

Alias, Maschinenname, Inventar und Standort sind personenbezogene Daten nach Art. 4 Nr. 1 DSGVO, sobald sie einer Person zugeordnet werden können, und die Verordnung gilt in Österreich unmittelbar, ergänzt durch das Datenschutzgesetz.²⁹³⁰ Verantwortlicher ist phranck in Bregenz. Rechtsgrundlage für die Veröffentlichung ist die Einwilligung nach Art. 6 Abs. 1 lit. a, die der Besitzer beim Anlegen des Kontos mit einem eigenen Häkchen gibt und jederzeit widerrufen kann; die Informationen nach Art. 13 stehen auf einer Datenschutzseite der Website in Deutsch und Englisch. Der Alias ist die Vorgabe für den öffentlichen Namen, weil niemand seinen Namen zeigen muss, um teilzunehmen; wer ihn zeigen will, gibt das im Konto als eigene Einwilligung frei und nimmt es jederzeit zurück, worauf die Website wieder den Alias zeigt. Der Besitzer löscht Maschinen und Konto selbst, und mit dem Konto gehen alle Proben, Inventare und Standorte (Art. 17). IP-Adressen stehen nur in den Logs des Reverse Proxy und werden nach sieben Tagen gelöscht; die Zähler gegen Missbrauch rechnen mit gesalzenen Hashes der Adresse. Aufsichtsbehörde ist die österreichische Datenschutzbehörde.³¹

8. Backend, Website und Betrieb

Das Backend wird in Rust geschrieben, das Frontend in TypeScript. Jeder Dienst ist ein Container-Image, seine Konfiguration kommt ausschließlich aus Umgebungsvariablen, und eine Beschreibung des Deployments im Ordner deploy/ legt die Dienste an. So läuft derselbe Stand auf jedem Host, der Container ausführt, und ein Wechsel des Hosts ändert nichts am Code.

axum, weil es die Bibliothek des tokio-Ökosystems ist, Middleware aus Tower übernimmt und damit Ratenbegrenzung, Logging und Zeitlimits ohne eigenen Unterbau liefert; sqlx, weil es Abfragen beim Kompilieren gegen das Schema prüft und Migrationen in das Binary einbettet, so dass der Datenbankstand mit dem Binary reist. Astro mit React-Inseln, UnoCSS, oxlint und oxfmt sind die Konventionen, die phrancks andere Web-Projekte schon verwenden; der Globus braucht WebGL und bekommt die eine React-Insel.

Die Migrationen laufen vor dem Start des Dienstes als Unterbefehl des eigenen Binarys, in das sqlx sie einbettet; der Datenbankstand reist so mit dem Binary. Vor der ersten Migration prüft das Binary die Rolle: Es liest current_user und rolsuper, bricht bei einem Superuser oder einer anderen Rolle als DB_MIGRATION_ROLE ab und läuft auf jedem Host gleich.

Ein Stand für jeden Host

Von den Ordnern des Repositorys (Abschnitt 11) zählen für die Serverseite drei: backend/ (Cargo-Projekt), web/ (Astro-Projekt, npm) und deploy/ mit der Compose-Datei für die drei Dienste, dem Schnipsel für den Reverse Proxy und je einer Beschreibung des Deployments für jeden Host, auf dem der Stand laufen soll. Zwischen den Hosts unterscheidet sich nichts im Code, nur die Umgebungsvariablen aus Tabelle 8, die jeder Host auf seine Weise setzt.

Vom Host braucht der Client-Endpunkt nur eines: einen Hostnamen, den der Reverse Proxy unverschlüsselt und ohne Umleitung an Port 3001 durchreicht. Kann ein Host das nicht, bekommt der Endpunkt einen eigenen Port, und die Basisadresse in der Konfiguration des Clients nennt ihn.

Gates vor jedem Deploy: cargo fmt --check, cargo clippy ohne Warnungen, cargo test; im Web oxlint, astro check, vitest und ein Build. Die CI des Repositorys führt sie bei jedem Pull Request aus.

9. Der Globus

Der Globus ist eine Seite der Website unter /globe, gebaut mit three-globe auf Three.js als React-Insel.³⁵ Er zeigt jede Maschine mit Standort als Marker in der Genauigkeit, die der Besitzer gewählt hat, Fremdhardware und Emulatoren eingeschlossen und mit ihrer Klasse gekennzeichnet, grün für online und grau für offline, mit Besitzername, Maschinenname und Modell beim Zeigen. Die Daten kommen aus GET /api/v1/markers, das nur die freigegebenen Felder liefert. Eine native Globus-App für NeXTSTEP steht im Backlog.

10. Der Client: AppKit-App und Meldeprozess

Der Client ist die AppKit-App, im Workspace laufend, und sie ist der einzige Client, weil sie beim Bildschirm mehr über die Hardware erfährt als ein Programm im Terminal (Abschnitt 4). Sie ist eine Neuentwicklung in Objective-C für NeXTSTEP; Namen, Protokoll, Datenformat und Paket sind eigene Entwürfe. Der Client besteht aus drei Teilen, in dieser Reihenfolge gebaut:

1. Die Bibliothek libnextnet kommt zuerst. Sie enthält das Inventar nach Tabelle 1, SHA-256 und HMAC, den JSON-Schreiber und den kleinen Leser, den HTTP-Client über BSD-Sockets, die Schlüssel- und Zählerdatei, die Konfigurationsdatei und den Controller der App. Sie ist eine Quelle auf Foundation und wird für 3.3 und 4.2 übersetzt. Sie hat keine Abhängigkeit zum Application Kit, damit sie im Meldeprozess ohne Window Server läuft.
2. Der Meldeprozess nextnetd kommt als zweites. Er hat keine Oberfläche und keine Befehle für den Besitzer, nur den Schalter -once für eine einzelne Meldung beim Testen. Er startet aus /etc/rc.local, lange vor einer Anmeldung, und läuft als Root, weil Start-Protokoll, Platten-ioctls und Schlüsseldatei Root verlangen. Er sendet den Status alle zehn Minuten, nach dem Start ein Inventar ohne Bildschirmwerte, öffnet nur ausgehende Verbindungen und schreibt seinen Zustand nach /etc/nextnet/state. Ohne Schlüsseldatei tut er nichts.
3. Die AppKit-App NeXTnet.app, im Workspace laufend, kommt als drittes. Sie zeigt im Dock-Icon den Online-Zustand, hat ein Panel zum Registrieren mit dem Code, ein Fenster mit Inventar und Zustand und ein Info-Panel. Sie liest den Zustand des Meldeprozesses, ergänzt das Inventar um die Bildschirmwerte aus dem Window Server und sendet es, stößt auf Wunsch eine Statusmeldung an, meldet aber nicht im Takt, damit es einen Melder gibt. Sie besteht aus zwei Oberflächenschichten über demselben Controller, einer gegen das Application Kit von 3.3 und einer gegen das OpenStep Application Kit von 4.2, mit je eigenen Nib-Dateien. Ihre Oberfläche folgt den Regeln der NeXTSTEP-3.3-Interface-Dokumentation, mit Verben auf den Buttons und der Return-Taste auf dem Standard-Button.

Je System ein Paket, NeXTnet-3.3.pkg und NeXTnet-4.2.pkg, installiert alle drei: die Bibliothek wird statisch gelinkt, der Meldeprozess nach /usr/local/libexec/nextnetd, die App nach /LocalApps/NeXTnet.app, und post_install legt /etc/nextnet an und schreibt die Zeile in /etc/rc.local. Der Besitzer bleibt Herr über das Melden: Er registriert mit einem Code, den nur er kennt, und ohne Schlüssel meldet nichts.

Die Aufteilung in App und Meldeprozess folgt aus zwei Grenzen. Eine App im Workspace läuft nur, solange ein Benutzer angemeldet ist und sie gestartet hat; eine NeXT, die am Anmeldefenster steht oder als Server läuft, wäre mit ihr allein nie online. Ein Prozess aus rc.local läuft immer, sieht aber den Bildschirm nicht. Darum meldet der Prozess Status und Inventar, und die App ergänzt einmal pro Sitzung, was nur sie sehen kann. Der Preis ist ein zweites Binary im Paket; der Gewinn ist, dass die Maschine unabhängig von der Anmeldung online ist und das Inventar trotzdem den Bildschirm kennt.

11. Repository und Lieferphasen

Ein Repository für alles: NeXTnet auf phrancks eigener Gitea-Instanz, mit backend/ (Rust), web/ (Astro), client/ mit libnextnet, nextnetd, NeXTnet.app und dem Paketbau, deploy/ für die Dienste und docs/ mit der Protokollbeschreibung, die Server- und Client-Seite gemeinsam lesen. Ein Repository, weil Protokoll und Datenformat an einer Stelle definiert sind und eine Änderung beide Seiten im selben Commit erreicht; der Client-Teil wird auf einer NeXTSTEP-Maschine gebaut und braucht dafür nur seinen Ordner. Issues und Projekt-Board liegen in derselben Gitea-Instanz, und die Phasen werden dort als Issues angelegt. Der Code für Papers ist NXN.

Backlog, je ein Issue, sobald die Phase davor steht: Fat Binaries für Intel, PA-RISC und SPARC, die native Globus-App, Screenshots der Maschinen.

Quellennachweis

37 Quellen, in der Reihenfolge ihres Auftretens. Die Seiten der NeXTSTEP-Dokumentation und der Archive sind an den genannten Stellen gelesen, die lokalen Dateien vollständig.

1. NeXT: NEXTSTEP 3.3 Release Notes: What’s New in Release 3.3, Abschnitte Platforms und Interface Builder. Spiegel bei nextop.de. Abschnitte gelesen Quelle↩↩↩
2. Grabher, A., Schubiger, S., Fétis, G.: Previous 4.5, readme.previous.txt und die Quelldateien src/rom.c, src/rtcnvram.c, src/sysReg.c, src/scsi.c, src/slirp/ctl.h im Quellbaum unter ~/Developer/Projects/previous. Genannte Dateien gelesen Quelle↩↩
3. Peanuts-Archiv: SSLeay Framework 0.9.0 für OPENSTEP 4.2 for Mach, README. Volltext gelesen Quelle↩↩
4. NeXT/Apple: NeXTanswers 1905, Foundation in NEXTSTEP 3.3. Volltext gelesen Quelle↩↩↩
5. NeXT/Apple: NeXTanswers 2504, Release Notes OPENSTEP 4.2: Compiler GCC 2.7.2.1, Konvertierung mit tops, Makefiles, NSFileHandle, Architekturen. Abschnitte gelesen Quelle↩↩↩↩↩↩↩
6. NeXT: Operating System Software, Teil 1 Mach, Kapitel 4: Mach Functions, Einträge host_info(), host_kernel_version(), processor_set_info(). Einträge gelesen Quelle↩↩↩↩
7. jrra: NeXTstation Color, Protokoll einer Installation von NeXTSTEP 3.3 mit der Ausgabe von hostinfo und des ROM-Monitors. Volltext gelesen Quelle↩↩
8. NeXT: NeXT Mach kernel, Quelltextstand mk-108.1 (Release 2.0), Spiegel johnsonjh/NeXTMach: next/next_init.c, next/autoconf.c, next/scr.h, mon/nvram.h, mon/global.h, nextif/if_en.c, bsd/kern_xxx.c. Älter als der 3.3-Kernel mk-171.9. Genannte Dateien gelesen Quelle↩↩
9. NeXT: NEXTSTEP 3.3 Network and System Administration, Kapitel 3 Setting Up the Network, 7 Peripherals, 9 Starting Up and Shutting Down, 15 Troubleshooting. Spiegel bei cilinder.be. Abschnitte gelesen Quelle↩↩
10. NeXT: NeXTSTEP 3.3 Manual Pages bei man.FreeBSD.org, manpath=NeXTSTEP+3.3: gethostid(2), hostinfo(1), sd(4), sg(4), scsimodes(8), w(1), if(4N), uname(2P), arch(3). Seiten gelesen Quelle↩↩↩
11. NeXT: NEXTSTEP 3.3 Developer Documentation, Release Notes Window Server, Eintrag setframebuffertransfer; Application Kit, Types and Constants, Einträge NXScreen und NXWindowDepth; Klassenübersicht des Application Kit, Abschnitt Managing Screens. Einträge gelesen Quelle↩↩↩
12. IEEE: MA-L Public Listing, Eintrag 00000F NEXT, INC. Eintrag geprüft Quelle↩
13. Grabher, A. u. a.: Previous, networking.howto.txt und filesharing.howto.txt im Quellbaum unter ~/Developer/Projects/previous. Volltext gelesen Quelle↩↩↩
14. NeXT: Development Tools, Kapitel 2: The Project Builder Application. Abschnitte gelesen Quelle↩
15. NeXT: NEXTSTEP 3.3 Release Notes: Project Builder, Projekttyp Tool. Volltext gelesen Quelle↩
16. NeXT: NEXTSTEP 3.3 Release Notes: Compiler und Fat Files. Volltext gelesen Quelle↩↩
17. NeXT: Development Tools, Kapitel 11: The GNU C Compiler. Volltext gelesen Quelle↩
18. NeXT: Object-Oriented Programming and the Objective C Language, Anhang A: Objective C Language Summary. Volltext gelesen Quelle↩
19. NeXT: Foundation Kit, Introduction. Volltext gelesen Quelle↩
20. NeXT: Foundation Kit: Living in a Hybrid World. Volltext gelesen Quelle↩
21. Marcum, A. M.: The NetInfo Lookup Server: lookupd, NEXTSTEP In Focus, Sommer 1993, im Archiv NeXTanswers als Nummer 1275. Abschnitte gelesen Quelle↩
22. NeXT: Preparing an Application for Installation by the Installer. Volltext gelesen Quelle↩↩
23. NeXT: NeXTanswers 1987, Ablauf von /etc/rc und /etc/rc.net in 3.3. Volltext gelesen Quelle↩
24. NeXT: NeXTanswers 1849, Ergänzungen in /etc/rc.local. Abschnitt gelesen Quelle↩
25. NiCE: Peanuts-Archiv, Verzeichnisse mit lynx, gnumake und gzip für NeXTSTEP, gelesen am 2. November 2026. Verzeichnisse gelesen Quelle↩
26. NeXT Computer, Inc.: NEXTSTEP, Produktdatenblatt, Spalte „NEXTSTEP for NeXT Computers“ mit CPU- und Speicherangaben, Copyright 1988 bis 1995, Spiegel bei levenez.com. Abschnitt gelesen Quelle↩
27. rjbrown99: NeXTStep Software Ports, Wiki, OpenSSL 0.9.6m und wget auf NeXTSTEP 3.3. Volltext gelesen Quelle↩
28. rooprob: OS42ssl, OpenSSL 1.0.2 auf OPENSTEP 4.2, README mit dem fehlgeschlagenen RSA-Test auf m68k. Volltext gelesen Quelle↩
29. Europäische Union: Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), Art. 4, 5, 6, 13, 17. Artikel gelesen Quelle↩
30. Republik Österreich: Datenschutzgesetz (DSG), geltende Fassung im RIS. Fassung geöffnet Quelle↩
31. Österreichische Datenschutzbehörde. Startseite geöffnet Quelle↩
32. tokio-rs: axum, Dokumentation auf docs.rs. Startseite gelesen Quelle↩
33. crates.io: Stände am 2. November 2026: axum 0.8.9, sqlx 0.9.0, tokio 1.54.1, tower-http 0.7.1, hmac 0.13.0, sha2 0.11.1, utoipa 6.0.0; Rust 1.99.1 vom 16. Oktober 2026. Versionen abgefragt Quelle↩
34. Astro: astro.build, Version 7.4.4 auf npm am 2. November 2026. Version geprüft Quelle↩
35. Turiano, V.: three-globe, Version 2.45.6 auf npm am 2. November 2026. Version geprüft Quelle↩
36. NeXT: Development Tools, Kapitel 14: Mach Object Files, CPU-Konstanten. Abschnitt gelesen Quelle
37. comp.sys.next.hardware: Attempt to setup NeXTstation Color under NS3.2, Boot-Protokoll von NeXT Mach 3.2. Thread gelesen Quelle