NeXTSTEP auf dem Raspberry Pi

Previously
14. September 2026
PAP-023

Ein Raspberry Pi 5, der beim Einschalten in NeXTSTEP startet und sonst nichts zeigt. Es gibt dafür zwei Wege: einen Befehl, der alles erledigt, und die Schritte einzeln von Hand. Der erste braucht ein paar Minuten, der zweite erklärt, was dabei geschieht.

1. Was gebraucht wird

Ein Raspberry Pi 5 mit einem Netzteil, das 5 V bei 5 A liefert. Ein Datenträger ab 32 GB, wobei eine SSD am USB-Anschluss die Emulation flüssiger macht als eine SD-Karte, weil NeXTSTEP viel auf seiner Festplatte arbeitet. Dazu Tastatur, Maus und Bildschirm.

Auf der Softwareseite Raspberry Pi OS Lite in der 64-Bit-Fassung. Es bringt keinen Desktop mit, und diese Anleitung braucht auch keinen. Die Ausgabe beruht seit Oktober 2025 auf Debian 13 mit dem Namen Trixie¹, woher alle weiteren Pakete kommen.

Der Emulator ist Previous. Er bildet einen NeXTcube und eine NeXTstation nach, arbeitet mit dem Prozessorkern aus WinUAE und läuft überall dort, wo SDL3 läuft².

Dazu NeXTSTEP selbst. Das Betriebssystem wird nicht mehr verkauft und nicht mehr gepflegt, die Bezugsquellen sind Archive. Beide Wege holen es von dort.

Ein zweiter Rechner im selben Netz wird gebraucht. Sobald der Emulator den Bildschirm bekommt, ist eine Anmeldung über SSH der einzige Weg, noch etwas am System zu ändern oder nachzusehen, warum etwas nicht startet. Nebenbei lassen sich die Befehle dieser Anleitung von dort einfügen statt abtippen.

2. Das System aufsetzen

Raspberry Pi OS Lite (64 Bit) mit dem Raspberry Pi Imager auf den Datenträger schreiben. Im Imager gleich die Voreinstellungen setzen: Benutzername, Rechnername, WLAN und SSH. Der Benutzername ist frei wählbar. Er taucht später in einem Pfad auf, und die Stelle ist in Abschnitt 4.3 genannt.

SSH einzuschalten ist keine Bequemlichkeit, sondern die Rückfalltür. Ab Abschnitt 4.4 gehört der Bildschirm dem Emulator, und wenn dann etwas nicht stimmt, ist eine Anmeldung über das Netz der einzige Weg an das Gerät.

Danach den Pi starten, anmelden und das System auf Stand bringen:

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Nach dem Neustart lohnt ein Blick, ob die Voraussetzungen wirklich stimmen. Die erste Zeile muss arm64 ergeben, die zweite trixie:

dpkg --print-architecture
. /etc/os-release; echo "$VERSION_CODENAME"

Steht dort etwas anderes, hilft kein Schritt dieser Anleitung weiter, denn SDL3 gibt es in älteren Ausgaben nicht.

Ab hier entscheidet sich, welchen Weg man nimmt. Abschnitt 3 erledigt alles Weitere mit einem Befehl. Wer stattdessen sehen will, was dabei geschieht, überspringt ihn und arbeitet Abschnitt 4 durch.

3. Der schnelle Weg: ein Befehl

Auf dem Pi, gern in einer Sitzung über das Netz:

curl -fsSL https://previous.li/install.sh | bash

Aufgerufen wird der Befehl als der Benutzer, dem die Maschine später gehört, und nicht mit sudo. Das Skript legt die Konfiguration und den Startbefehl im Home-Verzeichnis an, und als root wäre das das falsche Verzeichnis. Die erhöhten Rechte holt es sich selbst an den Stellen, an denen es sie braucht, und fragt dabei einmal nach dem Passwort. Das stört die Weiterleitung nicht, weil die Passwortfrage vom Terminal liest und nicht aus dem Kanal, durch den das Skript fliesst.

Jeder Schritt meldet sich mit einer Zeile, und ein Schritt, der nichts zu tun findet, sagt das ebenfalls. Der Bezug des Plattenabbilds ist mit rund zwei Gigabyte der längste Teil und zeigt einen Fortschrittsbalken. Am Ende steht eine Zeile, die zum Prüfen auffordert. Bleibt sie aus, ist das Skript nicht durchgelaufen.

Die Änderungen an der automatischen Anmeldung und am Startvorgang greifen erst nach einem Neustart. Vorher lohnt sich der erste Start aus Abschnitt 5, denn eine Maschine zu prüfen, die noch eine Eingabeaufforderung hat, ist einfacher als eine, die den Bildschirm bereits abgegeben hat.

Das Skript setzt die Betriebsart, in der NeXTSTEP Änderungen behält. Wer das Gerät lieber am Schalter ausmachen will, stellt danach auf die andere um, die in Abschnitt 4.3 beschrieben ist.

Ein Abbruch hinterlässt nichts

Wer das Skript mit Strg+C anhält, bekommt die Maschine so zurück, wie sie vorher war. Jeder Schritt vermerkt, was genau er verändert hat, und beim Abbruch wird dieser Vermerk rückwärts abgearbeitet. Dasselbe geschieht, wenn ein Schritt scheitert, denn ein halb eingerichtetes System ist in beiden Fällen gleich unerwünscht.

Zurückgenommen wird dabei nur, was dieser Durchlauf angelegt hat. Wer ein eigenes Plattenabbild in ~/nextstep liegen hatte, behält es. Wer cage bereits installiert hatte, behält es ebenso, denn der Schritt hat es übersprungen und deshalb nichts vermerkt. Eine vorhandene Konfiguration wird nicht angerührt, und aus ~/.profile verschwindet genau der eingefügte Abschnitt und sonst keine Zeile.

Eine Sache bleibt stehen, und das mit Absicht: die Paketlisten, die dabei aufgefrischt wurden. Sie sind aktueller als vorher und schaden nicht. Das Systemupdate aus Abschnitt 2 rührt das Skript ohnehin nicht an.

Warum der Befehl so aussieht

Im Skript liest nichts aus dem Eingabekanal, denn genau dort kommt bei dieser Aufrufform das Skript selbst an. Ein Programm, das daraus läse, würde den noch ungelesenen Rest verschlucken. Aus demselben Grund laufen die Paketbefehle darin ohne Rückfragen, denn eine Nachfrage zu einer Konfigurationsdatei griffe genau dorthin.

Die gesamte Arbeit des Skripts steht ausserdem in Funktionen, und ausgeführt wird erst in der letzten Zeile. Bricht die Verbindung mitten im Herunterladen ab, kommt diese Zeile nie an, und es passiert gar nichts statt der Hälfte.

Wer nachsehen will, was der Befehl tut, bevor er ihn ausführt, ruft dieselbe Adresse im Browser auf. Das Skript ist eine Textdatei und liest sich in fünf Minuten.

Es läuft mehrfach, ohne beim zweiten Mal etwas kaputtzumachen. Wer den langen Weg für NeXTSTEP gehen will, den Emulator aber nicht von Hand einrichten mag, legt sein Plattenabbild vorher in ~/nextstep. Schritt 4 nimmt dort jede Datei mit der Endung .img, .dd oder .raw ab einer halben Gigabyte als vorhandenes Abbild an, überspringt den Bezug und schreibt die Konfiguration gegen diese Platte.

Eine bereits vorhandene previous.cfg lässt Schritt 5 dagegen unangetastet, auch dann. Wer den Emulator vorher schon einmal gestartet und beendet hat, hat eine solche Datei und trägt den Pfad zu seinem Abbild deshalb selbst ein, wie in Abschnitt 4.3 gezeigt.

4. Der lange Weg: Schritt für Schritt

Dieselbe Einrichtung von Hand, mit dem, was dabei geschieht und warum. Wer Abschnitt 3 benutzt hat, kann hier nachschlagen, braucht aber nichts davon auszuführen.

4.1 Previous installieren

Previous liegt als Paket für arm64 vor, gebaut gegen SDL3. Es kommt aus dem Paketarchiv von Window Maker Live, das eine eigene Suite für Trixie führt und signiert ist³. Über das Archiv statt über eine einzelne Datei zu gehen lohnt sich, weil spätere Fassungen dann mit dem übrigen System ankommen.

Zuerst der Schlüssel, mit dem das Archiv signiert ist:

sudo install -m 0755 -d /etc/apt/keyrings
sudo wget -qO /etc/apt/keyrings/wmlive.asc \
  https://wmlive.rumbero.org/repo/wmlive.rumbero.org.asc

Dann die Bezugsquelle:

sudo tee /etc/apt/sources.list.d/wmlive.sources > /dev/null <<'EOF'
Types: deb
URIs: https://wmlive.rumbero.org/repo
Suites: wmlive-trixie
Components: main
Signed-By: /etc/apt/keyrings/wmlive.asc
EOF

Das Archiv führt neben Previous noch andere Pakete, und ohne Weiteres dürften die auch Pakete aus Debian ersetzen. Die folgende Festlegung erlaubt von dort genau ein Paket und sperrt den Rest:

sudo tee /etc/apt/preferences.d/wmlive > /dev/null <<'EOF'
Package: *
Pin: origin wmlive.rumbero.org
Pin-Priority: -1

Package: previous
Pin: origin wmlive.rumbero.org
Pin-Priority: 500
EOF

Danach die Installation:

sudo apt update
sudo apt install -y previous

Das Paket verlangt sieben Bibliotheken, die Trixie alle mitbringt: libc6 ab 2.38, libgcc-s1, libstdc++6, libsdl3-0 ab 3.2.0, libpng16-16t64 ab 1.6.46, libpcap0.8t64 und libreadline8t64. Die knappste Forderung ist libpng, und Trixie liefert 1.6.48⁴.

Danach liegen zwei Programme unter /usr/bin/, nämlich previous und das Plattenwerkzeug ditool. Unter /usr/share/previous/ liegen die ROM-Dateien der NeXT-Maschinen, und sie müssen nicht einzeln besorgt werden. Previous wählt beim Start die zum eingestellten Maschinentyp passende, für einen Turbo Cube Rev_3.3_v74.BIN. Wer den Maschinentyp ändert, muss die ROM-Datei also nicht mit ändern.

Zwei weitere Pakete kommen gleich mit dazu. Raspberry Pi OS Lite bringt keine grafische Oberfläche mit, und Previous braucht eine, um überhaupt ein Bild zeigen zu können. Diese Rolle übernimmt cage, ein Kiosk-Compositor für Wayland, der eine einzige maximierte Anwendung zeigt und den Benutzer mit nichts anderem umgehen lässt⁵. Das zweite Paket packt das Archiv aus, in dem NeXTSTEP steckt, und heisst in Trixie 7zip⁶. Der ältere Name p7zip-full führt inzwischen nur noch dorthin:

sudo apt install -y cage 7zip

Zwei weitere braucht nur der Web-Admin, und wer ihn nicht einrichtet, braucht sie nicht. xdotool drückt die Tasten der emulierten Maschine, also den Ausschalter und die Bestätigung danach, und imagemagick liest ihren Bildschirm. Das Lesen ist die einzige Möglichkeit, eine Maschine, die hochgekommen ist, von einer zu unterscheiden, die es nicht ist: der Emulator läuft in beiden Fällen. Das Skript aus Abschnitt 3 installiert beide mit.

sudo apt install -y xdotool imagemagick

Ab hier wird Previous immer über cage gestartet, auch für einzelne Handgriffe:

cage -- previous

Beim ersten Mal meldet es sich mit seinem Einstellungsdialog, denn das ist seine Vorgabe. Der Knopf unten rechts schliesst ihn und startet die emulierte Maschine; mit F12 kommt man jederzeit wieder hinein. Beendet wird Previous mit Strg+Alt+Q, und dabei schreibt es seine Konfiguration. Tabelle 7 in Abschnitt 5 nennt die übrigen Tastenkürzel.

Dieser Aufruf gehört auf die Textkonsole des Pi, also an die Tastatur am Gerät. Eine Sitzung über das Netz hat keinen Bildschirm, auf den cage zeichnen könnte, und bricht mit einer Fehlermeldung ab, in der von einem seat die Rede ist. Damit ist ein Arbeitsplatz aus Bildschirm, Tastatur und Maus gemeint, den Linux einer Anmeldung zuordnet. Eine Anmeldung über das Netz bekommt keinen, und ohne ihn kommt der Compositor nicht an die Grafikausgabe. Abschnitt 5 beschreibt, was sich trotzdem über das Netz prüfen lässt.

4.2 NeXTSTEP bereitstellen

Es gibt zwei Wege, und man nimmt einen davon ganz. Der kurze führt in wenigen Minuten zu einem laufenden System, der lange dauert etwa eine Stunde und zeigt die Installation so, wie sie 1995 ablief.

Beide legen ihre Dateien im selben Ordner ab:

mkdir -p ~/nextstep

Ein fertiges Plattenabbild

Im Internet Archive liegt ein fertig installiertes NeXTSTEP 3.3 für Previous⁷:

cd ~/nextstep
wget -c https://archive.org/download/nextstep-3.3-hd-image-with-previous.-7z/Nextstep%203.3%20HD%20Image%20With%20Previous.7z
7z x "Nextstep 3.3 HD Image With Previous.7z"

Das -c ist gegen die zwei Gigabyte gerichtet: bricht die Verbindung ab, setzt derselbe Befehl den Bezug fort, statt eine zweite Datei danebenzulegen.

Das Archiv packt sich in einen gleichnamigen Unterordner aus. Gebraucht wird daraus eine einzige Datei:

~/nextstep/Nextstep 3.3 HD Image With Previous/NS33_2GB.dd

Der Pfad oben wird in Abschnitt 4.3 gebraucht, mitsamt den Leerzeichen darin.

Die Beilage im Archiv nennt als Maschinentyp eine NeXTstation. Auf einem NeXTcube Turbo startet dasselbe Abbild ebenfalls, wie Tabelle 3 ihn einstellt, und das ist die Maschine, um die es hier geht. Eine NeXTstation zu wählen bringt keinen Vorteil und schliesst die Erweiterung aus Abschnitt 4.6 aus.

Angemeldet wird sich in diesem NeXTSTEP als me, ohne Passwort. Ein zweites Konto heisst root und hat ebenfalls keines. Beides gehört bei Gelegenheit geändert, und für ein Gerät, das nur vorführt, ist es gleichgültig.

Installation von den Originalmedien

Die Installationsmedien von NeXTSTEP 3.3 liegen ebenfalls im Internet Archive⁸. Sie sind keine ISO-9660-Abbilder, sondern tragen ein Dateisystem aus der BSD-Welt, was für Previous keine Rolle spielt, weil der Emulator die Platte roh durchreicht und NeXTSTEP das Dateisystem selbst liest.

Gebraucht wird das Medium mit dem System. Das zweite, das dort liegt, trägt die Entwicklungswerkzeuge und kann später nachgereicht werden:

cd ~/nextstep
wget -c "https://archive.org/download/NeXTSTEP33CISC/NeXTSTEP_3.3_User_%28i386_m68k%29.iso"

Die Anführungszeichen gehören dazu, damit die Shell die Adresse als ein Stück behandelt.

Zuerst eine leere Platte anlegen. Sie bekommt keine Partitionstabelle, denn NeXTSTEP schreibt beim Initialisieren sein eigenes Disk-Label an den Anfang und überschreibt alles, was dort steht:

cd ~/nextstep
dd if=/dev/zero of=nextstep.img bs=1M count=2048

Dann werden beide Geräte in die Konfiguration eingetragen. Previous mit cage -- previous starten, worauf es sich mit seinem Einstellungsdialog meldet, weil das seine Vorgabe ist. Dort unter SCSI die Platte auf Gerät 0 und das Installationsmedium auf Gerät 1 legen, dieses als CD-Laufwerk gekennzeichnet, und unter Boot den ROM-Monitor wählen. Unter System gehört schon jetzt die Maschine eingestellt, auf der NeXTSTEP später laufen soll, denn es richtet sich bei der Installation danach; die Werte dafür stehen in Tabelle 3. Tabelle 2 nennt die übrigen Angaben so, wie sie in der Konfigurationsdatei heissen, für den Fall, dass ein Wert nachzusehen ist.

Die Reihenfolge der Geräte ist wichtig. NeXTSTEP setzt die Platte, auf die es installiert, an der niedrigeren Nummer voraus, und das Installationsmedium gehört darüber⁹. Vertauscht man beides, richtet die Installation die falsche Platte ein.

Nach einem Neustart von Previous erscheint statt eines Startvorgangs die Eingabeaufforderung des ROM-Monitors, erkennbar an einem Zeilenanfang mit NeXT>. Dort wird von der Nummer des Laufwerks gestartet, auf dem das Installationsmedium liegt⁹:

bsd(1,0,0) sdmach -s rootdev=sd1

Die erste Zahl in der Klammer ist die Nummer des Geräts, von dem gestartet wird, also die, unter der das Installationsmedium eingetragen wurde. Liegt es auf einem anderen Anschluss, ändert sich diese Zahl und die hinter rootdev=sd mit ihr. Das -s startet in den Einzelbenutzerbetrieb, von dem aus das Installationsprogramm weiterführt.

Von hier an führt NeXTSTEP durch den Rest. Es fragt nacheinander nach der Sprache, nach der Platte, die eingerichtet werden soll, und nach dem Umfang der Installation. Die Platte muss dabei zuerst initialisiert werden, was ihren bisherigen Inhalt verwirft, und genau dafür wurde sie im vorigen Schritt leer angelegt. Danach kopiert das System sich selbst hinüber, was je nach Datenträger eine halbe bis eine ganze Stunde dauert.

Beim ersten Start der fertigen Platte richtet NeXTSTEP dann das erste Konto ein und fragt dabei nach Name und Passwort. Diese Angaben sind es, mit denen man sich von da an anmeldet.

Ist das durch, wird in den Einstellungen von Previous das Startgerät von ROM-Monitor auf SCSI umgestellt, also nBootDevice auf 1. Das Installationsmedium wird aus Gerät 1 genommen, indem dort bDiskInserted1 auf FALSE geht; im Dialog ist das der Knopf zum Auswerfen. Danach startet die Maschine von der eigenen Platte.

4.3 Previous konfigurieren

Previous schreibt seine Konfiguration selbst. Beim ersten Beenden entsteht ~/.config/previous/previous.cfg mit allen Vorgaben darin. Wer den vorigen Abschnitt durchlaufen hat, hat sie also bereits. Sonst genügt ein Start und ein sofortiges Beenden:

cage -- previous

Geändert wird danach nur, was von den Vorgaben abweicht. Die Datei ist eine gewöhnliche Textdatei mit Abschnitten in eckigen Klammern und Zuweisungen mit Leerzeichen um das Gleichheitszeichen. Bearbeitet wird sie mit nano, das auf Raspberry Pi OS Lite vorhanden ist.

So sieht der Abschnitt für ein fertiges Abbild in der Datei aus, wenn der Benutzer next heisst:

[HardDisk]
szImageName0 = ~/nextstep/Nextstep 3.3 HD Image With Previous/NS33_2GB.dd
nDeviceType0 = 1
bDiskInserted0 = TRUE

Drei Dinge daran sind wichtig. Der Pfad steht vollständig ab /home da, denn eine Tilde versteht Previous nicht. Die Leerzeichen im Ordnernamen bleiben, wie sie sind, ohne Anführungszeichen und ohne Schrägstriche davor, weil hier keine Shell mitliest. Und der Benutzername ist der eigene, nicht next.

Die Schlüssel stehen schon alle in der Datei, jeder mit seinem Vorgabewert. Geändert werden also Werte, nicht Zeilen hinzugefügt.

Der Arbeitsspeicher der emulierten Maschine steht in [Memory] und ist mit vier Bänken zu je 16 MB vorbelegt, zusammen 64 MB. Für NeXTSTEP 3.3 reicht das, und der Abschnitt bleibt unangetastet.

Der Abschnitt [System] beschreibt die Maschine, und seine Angaben gehören zusammen. Wer im Einstellungsdialog den Maschinentyp wechselt, bekommt sie passend gesetzt: Prozessorstufe, Taktrate, Rechenwerk, SCSI- und Uhrenbaustein. Wer die Datei dagegen von Hand schreibt, bekommt diese Hilfe nicht. Previous prüft beim Start nur zwei Angaben nach, nämlich den NextBus, den es einer NeXTstation abspricht, und die Apple-Desktop-Bus-Tastatur, die es einer Maschine ohne Turbo nimmt. Alles andere übernimmt es so, wie es dasteht, auch wenn es nicht zur Maschine passt.

Deshalb liegen neben diesem Dokument fertige Konfigurationen, eine für jede Maschine, die NeXT gebaut hat. Sie tragen die Werte, die zusammengehören, und es bleibt nur der Pfad zum Plattenabbild einzusetzen.

Jede Datei ersetzt ~/.config/previous/previous.cfg vollständig. Vorher gehört der Emulator angehalten, sonst schreibt er beim Beenden seinen eigenen Stand darüber. In der Datei steht an einer Stelle ein Platzhalter, und der wird durch den Pfad zum eigenen Plattenabbild ersetzt:

szImageName0 = ~/nextstep/PLATTE.img

Die Spalte Start hält fest, ob NeXTSTEP mit dieser Konfiguration hochkommt. Gemessen am 12. September 2026, auf einem Gerät mit 4 GB Arbeitsspeicher, jede Konfiguration einmal gestartet, mit dem fertigen Plattenabbild aus Abschnitt 4.2. Zehn der elf starten.

Die eine Ausnahme liegt nicht an der Konfiguration, sondern am Abbild. Ein Plattenabbild gehört zu der Maschine, auf der es eingerichtet wurde, und dieses trägt ein System für den 68040. Der NeXT Computer hat einen 68030 und braucht einen anderen Systemkern, weshalb er von dieser Platte nicht startet. Wer die erste Maschine sehen will, installiert sich dafür eine eigene, wie in Abschnitt 4.2 beschrieben.

Die beiden Konfigurationen mit NeXTdimension kosten dabei deutlich mehr Rechenzeit als die übrigen, weil der Prozessor der Karte in einem zweiten Strang mitläuft. Auf dem Pi 5 fällt das nicht ins Gewicht: gemessen wurden rund 150 Prozent eines Kerns von vier, der Rest bleibt frei.

Zwei Betriebsarten, und die Wahl dazwischen

Es gibt eine Einstellung, die darüber entscheidet, ob die Maschine Änderungen behält. Sie heisst nWriteProtection und steht ebenfalls in [HardDisk].

Bei der Vorgabe 0 arbeitet die Maschine wie jeder Rechner: Was NeXTSTEP schreibt, landet im Plattenabbild und ist beim nächsten Start noch da. Das ist richtig für ein Gerät, an dem gearbeitet wird.

Bei 1 schreibt Previous nichts mehr in die Datei. Jeder geschriebene Block wandert stattdessen in einen Zwischenspeicher im Arbeitsspeicher, und jeder Lesevorgang wird zuerst dort bedient. NeXTSTEP merkt von alldem nichts: es bekommt keine Fehlermeldung, liest zurück, was es geschrieben hat, und verhält sich vollkommen normal. Nur endet dieser Zwischenspeicher mit dem Programm. Der nächste Start beginnt wieder beim selben Stand wie der vorige, und das Plattenabbild bleibt dabei Byte für Byte unverändert.

Das ist die Einstellung für ein Gerät, das im Raum steht und irgendwann am Schalter ausgeht. Es kann dann nichts kaputtgehen, weil nie etwas geschrieben wird. Der Preis ist, dass auch nichts bleibt: keine neue Datei, keine geänderte Einstellung, kein installiertes Programm übersteht den Neustart.

Der Zwischenspeicher kostet Platz im Arbeitsspeicher des Pi. Er wächst mit dem, was geschrieben wird, und sein Verzeichnis allein belegt bei einem Abbild von zwei Gigabyte rund 32 MB. Auf einem Pi 5 fällt das nicht ins Gewicht.

4.4 Den Kiosk-Betrieb einrichten

Bisher wurde Previous von Hand gestartet. Jetzt bekommt es den Bildschirm beim Einschalten, ohne dass jemand etwas tippt.

Zuerst die automatische Anmeldung auf der Textkonsole:

sudo raspi-config nonint do_boot_behaviour B2

Der Befehl sagt nichts, wenn er gewirkt hat. Nachsehen lässt es sich an der Datei, die er anlegt:

cat /etc/systemd/system/getty@tty1.service.d/autologin.conf

Dort muss agetty --autologin mit dem eigenen Benutzernamen stehen.

Zuletzt der Start. Diese Zeilen kommen ans Ende von ~/.profile und starten Previous, sobald sich der Benutzer auf der ersten Konsole anmeldet:

if [ "$XDG_VTNR" = 1 ] && [ -z "$WAYLAND_DISPLAY" ]; then
  exec cage -- /usr/bin/previous
fi

Es muss ~/.profile sein und nicht ~/.bash_profile. Bash liest von den in Frage kommenden Dateien nur die erste, die existiert, und auf Raspberry Pi OS ist das ~/.profile, das seinerseits ~/.bashrc nachzieht. Wer stattdessen eine ~/.bash_profile anlegt, schaltet beides ab, und zwar auch für jede Anmeldung über das Netz, also genau für die Rückfalltür von oben.

Die Unterscheidung leistet XDG_VTNR. Diese Angabe trägt die Nummer der Textkonsole und ist nur dort gesetzt, wo wirklich eine hinter der Anmeldung steht. Eine Sitzung über das Netz hat keine, fällt durch die Abfrage hindurch und bleibt eine gewöhnliche Eingabeaufforderung. Die zweite Bedingung fängt den Fall ab, dass in dieser Sitzung schon ein Compositor läuft.

Was beim Einschalten der Reihe nach passiert

Ein Benutzer ist dabei sehr wohl angemeldet, nur tippt niemand ein Passwort. Der Weg vom Einschalten bis zum NeXT-Bildschirm geht über fünf Stationen.

Der Kernel startet und übergibt an systemd. Systemd steuert das Ziel multi-user.target an, also den Betrieb ohne Grafik, und startet dabei die erste Textkonsole als Dienst getty@tty1. Für diesen Dienst liegt eine Ergänzung unter /etc/systemd/system/getty@tty1.service.d/autologin.conf, die der Befehl aus diesem Abschnitt angelegt hat. Sie ersetzt den gewöhnlichen Anmeldevorgang durch agetty --autologin mit dem Namen des Benutzers, sodass die Anmeldung ohne Rückfrage geschieht. Damit startet eine Anmelde-Shell, und die liest ~/.profile, wo cage und darin Previous aufgerufen werden.

Das exec vor dem Aufruf ist dabei kein Beiwerk. Es ersetzt die Shell durch den Compositor, statt ihn als Kind zu starten, sodass hinter Previous kein Prozess wartet, der nach dessen Ende eine Eingabeaufforderung anbieten würde.

Endet Previous trotzdem, etwa über Strg+Alt+Q, endet damit die ganze Sitzung. Systemd startet getty@tty1 daraufhin neu, die automatische Anmeldung greift wieder, und die Maschine ist zurück im NeXT-Bildschirm. Das ist gewollt und heilt einen einzelnen Absturz von selbst. Scheitert der Start dagegen dauerhaft, etwa weil die Konfiguration auf ein Abbild zeigt, das nicht da ist, wiederholt sich derselbe Versuch im Sekundentakt. Dann hilft die Anmeldung über SSH, die von alldem unberührt bleibt.

4.5 Den Startvorgang beruhigen

Beim Starten melden sich vier Dinge nacheinander auf dem Bildschirm: die Firmware mit ihrem farbigen Quadrat, der Kernel mit den Himbeeren und seinen Meldungen, systemd mit seiner Statusliste, und zuletzt die Textkonsole mit einem blinkenden Cursor. Ein Gerät, das einen NeXT zeigen soll, zeigt nichts davon. Jede der vier Quellen wird einzeln stillgelegt.

Zuerst die Firmware. In /boot/firmware/config.txt kommt diese Zeile ans Ende:

disable_splash=1

Der Rest steht in /boot/firmware/cmdline.txt. Diese Datei besteht aus einer einzigen langen Zeile, und daran ändert sich nichts: alles Neue kommt an ihr Ende, durch Leerzeichen getrennt.

Zuerst aber eine Ersetzung mitten in der Zeile. Dort steht bereits console=tty1, und diese Angabe wird zu console=tty3, indem die Eins zur Drei wird. Sie wird nicht doppelt eingetragen, denn zwei solche Angaben liessen den Kernel weiterhin auch auf die erste Konsole schreiben, also auf den sichtbaren Bildschirm.

Danach kommt der Rest ans Ende der Zeile:

quiet loglevel=0 logo.nologo vt.global_cursor_default=0 systemd.show_status=false

Beides greift erst beim nächsten Start. Bevor der Bildschirm stumm wird, lohnt deshalb der erste Start aus Abschnitt 5.

Danach bleibt der Bildschirm vom Einschalten bis zum NeXT-Bildschirm dunkel.

Was dabei verloren geht, sind die Meldungen. Für das System selbst ist das kein Verlust, denn journalctl -b zeigt den letzten Start vollständig, und daran sieht man etwa, ob die erste Konsole im Sekundentakt neu startet.

Was dort nicht steht, ist die Meldung von Previous selbst. Es ist kein Dienst, sondern ein Kind der Anmeldung auf der ersten Konsole, und seine Ausgabe geht genau auf den Bildschirm, den dieser Abschnitt stumm geschaltet hat. Für eine Fehlersuche wird die Stummschaltung deshalb vorübergehend zurückgenommen, indem die gesicherte Fassung der Datei zurückgeschrieben wird:

sudo cp /boot/firmware/cmdline.txt.previously.backup /boot/firmware/cmdline.txt
sudo reboot

Diese Sicherung legt auch das Skript aus Abschnitt 3 an, unter demselben Namen.

Danach schreibt Previous seine Meldung wieder sichtbar auf den Bildschirm. Ist der Fehler gefunden, werden die Angaben für cmdline.txt erneut eingetragen; disable_splash=1 in config.txt bleibt davon unberührt und muss nicht angefasst werden.

4.6 Eine NeXTdimension einbauen

Die NeXTdimension ist eine Grafikkarte für den NeXTcube, mit einem eigenen Prozessor und eigenem Speicher. In Previous ist sie keine Frage des Plattenabbilds, sondern eine Einstellung: die Karte wird gesteckt, und NeXTSTEP findet sie beim Starten. Die Treiber bringt NeXTSTEP ab Fassung 2.1 mit, ein 3.3 also ohnehin.

Sie ist ausserdem der einzige Weg zu einem farbigen Bildschirm auf einem Cube. Previous setzt für diesen Maschinentyp bColor selbst auf FALSE, weil der Cube eingebaut nur zwei Bit Graustufen hat. Farbe kam bei dieser Maschine immer über diese Karte, und in der Emulation ist das genauso.

Sie setzt einen Cube voraus. Bei einer NeXTstation schaltet Previous den NextBus ab, und ohne den gibt es keinen Steckplatz für die Karte. nMachineType bleibt deshalb auf 1.

Um szRomFileName0 muss man sich nicht kümmern, solange man es nicht anfasst. Previous trägt dafür ND_step1_v43.BIN aus seinem eigenen Verzeichnis ein, und die Datei kommt aus dem Paket.

nConsoleSlot entscheidet, welcher Steckplatz den Bildschirm bekommt, und ist damit die Angabe, an der die Farbe hängt. Die Vorgabe 0 lässt das Bild am eingebauten Anschluss, also in Graustufen, obwohl die Karte steckt. Die Steckplätze zählen in Zweierschritten ab zwei, sodass die erste Karte auf 2 sitzt, die zweite auf 4 und die dritte auf 6.

Ein Wert, der auf einen Steckplatz ohne aktive Karte zeigt, lässt den Bildschirm dunkel, während die Maschine sonst normal läuft. Wer also nConsoleSlot auf 2 stellt, muss bEnabled0 auf TRUE haben, sonst sieht er nichts.

Der Start dauert mit Karte deutlich länger, weil ihr Prozessor selbst hochkommen muss. Zwei bis drei Minuten sind normal. Wer dabei in das Protokoll aus Abschnitt 5 sieht, findet zuerst Zeilen wie [NextBus] NeXTdimension board at slot 2 und [ND] Read ROM from ..., danach Meldungen des Plattenzugriffs, und am Ende Ruhe. Diese Ruhe ist das Zeichen für einen fertigen Start und nicht für einen Hänger: ein laufendes System schreibt nichts mehr, und der Emulator liegt dabei dauerhaft bei gut 130 Prozent Prozessorlast, weil zwei Stränge rechnen.

4.7 Ton an einen Lautsprecher schicken

NeXTSTEP bringt Töne mit, und Previous gibt sie weiter. Der Pi schickt sie allerdings dorthin, wo niemand zuhört: an seinen HDMI-Anschluss, weil das die erste Soundkarte des Geräts ist und keine andere Vorgabe existiert. Ein Lautsprecher am USB-Anschluss bleibt stumm.

Dazu kommt ein zweites, das erst später auffällt. Previous wählt sein Ausgabegerät beim Starten und fragt danach nicht mehr nach. Wird der Lautsprecher im Betrieb umgesteckt, ist der Ton weg und kommt auch beim Zurückstecken nicht wieder.

Beides löst ein Tonserver. PipeWire verbindet ein Programm mit sich selbst statt mit einer Karte und kann einen Tonstrom deshalb verschieben, wenn ein Gerät kommt oder geht. Und es wählt von allein richtig: Sein Verwalter bewertet eine USB-Karte mit 1009 gegen 1000 für HDMI.

Das Skript aus Abschnitt 3 richtet das mit ein. Von Hand sind es drei Pakete:

sudo apt install pipewire wireplumber pipewire-alsa

Previous braucht dafür keine Einstellung. Sein SDL bringt einen Anschluss für PipeWire mit und nimmt ihn, sobald ein Server läuft. Nach der Installation muss der Emulator einmal neu starten, danach läuft alles über den Server.

Eine Einstellung fehlt noch, und ohne sie hört man nichts. Ein neu erkanntes Gerät startet bei 40 Prozent, und die Töne von NeXTSTEP sind selbst schwach aufgenommen. Zusammen ist das auf einem kleinen Lautsprecher unhörbar:

sudo mkdir -p /etc/wireplumber/wireplumber.conf.d
sudo tee /etc/wireplumber/wireplumber.conf.d/50-nextstep.conf >/dev/null <<'EOF'
wireplumber.settings = {
  device.routes.default-sink-volume = 0.614
}
EOF

Der Wert gilt beim ersten Erkennen eines Geräts. Danach merkt sich der Server, was eingestellt wurde. Die Zahl ist die dritte Potenz von 85 Prozent, weil die Einstellung diese Skala verwendet.

Geprüft wird in NeXTSTEP mit einem Terminal:

sndplay /NextLibrary/Sounds/Ping.snd

In diesem Verzeichnis liegen sechzehn Töne. Wer lieber klickt, öffnet Sound.app aus /NextDeveloper/Demos/. Von der Linux-Seite aus zeigt wpctl status, an welcher Senke der Emulator hängt; er erscheint dort als SDL Application.

5. Der erste Start

Jetzt wird geprüft, ob alles zusammenpasst, und zwar bevor die Maschine sich selbst überlassen wird. Das geschieht an der Tastatur des Pi, auf der Textkonsole.

Ist der Autostart aus Abschnitt 4.4 schon eingetragen, und nach dem Skript aus Abschnitt 3 ist er das, dann genügt eine Anmeldung an dieser Konsole: Previous startet von selbst, und genau das soll es ja. Wer noch keinen Autostart hat, tippt:

cage -- previous

Richtig läuft es, wenn der graue NeXT-Bildschirm erscheint und innerhalb einer halben Minute der Anmeldeschirm von NeXTSTEP folgt. Beim fertigen Abbild wird sich als me ohne Passwort angemeldet. Wer selbst installiert hat, nimmt das Konto, das er dabei angelegt hat.

Geht es schief, sagt das Bild, woran es liegt. Bleibt die Eingabeaufforderung des ROM-Monitors mit NeXT> stehen, sind zwei Ursachen möglich: entweder steht das Startgerät noch auf ROM-Monitor, was nach einer Installation von den Originalmedien der Fall ist und sich mit nBootDevice = 1 erledigt, oder die Maschine findet ihre Platte nicht, und dann stimmt der Pfad in der Konfiguration nicht.

Kommt gar kein Fenster, sondern eine Fehlermeldung über einen fehlenden Sitzplatz oder ein fehlendes Ausgabegerät, läuft der Aufruf nicht an der Tastatur des Pi, sondern über das Netz.

Beim Start kann das Fenster einen Augenblick in voller Grösse samt Statusleiste erscheinen und erst danach die richtige Grösse annehmen. Das liegt an der Reihenfolge, in der Previous den Bildschirm aufbaut.

Läuft alles, wird bVisible auf FALSE gestellt. Dann startet die Maschine ohne Textmeldungen, was zu einem Gerät passt, das einen NeXT zeigen soll und sonst nichts. Diese Umstellung gehört ans Ende, nicht an den Anfang.

Wenn die Einrichtung über SSH läuft

Die Einrichtung lässt sich vollständig von einem anderen Rechner aus erledigen. Nur der Start gehört nicht dazu: Previous zeichnet auf den Bildschirm, der am Pi hängt, und eine SSH-Sitzung erreicht ihn nicht. Der Compositor braucht dafür eine Anmeldung mit einem zugewiesenen Platz, und eine Sitzung über das Netz bekommt keinen.

Ob das Abbild richtig liegt, sagt aber auch ein Werkzeug ohne Bildschirm. Previous bringt ditool mit, das ein Plattenabbild direkt liest:

ditool -im "$HOME/nextstep/Nextstep 3.3 HD Image With Previous/NS33_2GB.dd" -lsp
ditool -im "$HOME/nextstep/Nextstep 3.3 HD Image With Previous/NS33_2GB.dd" -p a -ls

Hier gehören die Anführungszeichen dazu, anders als in der Konfigurationsdatei, denn diesen Pfad liest eine Shell und die zerlegte ihn sonst an den Leerzeichen. Wer selbst installiert hat, setzt den Pfad seiner eigenen Platte ein, also etwa ~/nextstep/nextstep.img, und braucht dann keine.

Der erste Aufruf zeigt die Aufteilung der Platte, in der Regel eine einzige Partition mit dem Buchstaben a, und der zweite listet die Dateien darin auf. Erscheinen dort Namen wie NextLibrary, NextApps und private, stimmen Pfad und Abbild, und die Platte trägt ein NeXTSTEP. Kommt stattdessen eine Fehlermeldung oder eine leere Liste, ist das Abbild unvollständig oder der Pfad falsch.

Den Start auf dem Bildschirm des Pi löst dieser Befehl aus, ohne dass neu gestartet werden muss:

sudo systemctl restart getty@tty1

Dafür muss am Pi ein Bildschirm angeschlossen sein. Ohne ihn gibt es kein Ausgabegerät, das der Compositor bespielen könnte.

6. Auf eine neuere Fassung von Previous bringen

Previous wird weiterentwickelt, und weil es aus einem Paketarchiv kommt, meldet sich eine neue Fassung von selbst. Eine Aktualisierung ist dann ein gewöhnliches Systemupdate.

Was dabei ausgetauscht wird, sind die Programme unter /usr/bin/ und die ROM-Dateien unter /usr/share/previous/. Beides gehört dem Paket. Das Plattenabbild in ~/nextstep und die Konfiguration in ~/.config/previous/ gehören dem Benutzer, und kein Paketvorgang fasst sie an.

Gefährlich ist deshalb nicht das Update, sondern der Zustand, in dem es die Maschine antrifft. Wird Previous beendet, während NeXTSTEP noch läuft, bleibt ein Dateisystem zurück, in dem Schreibvorgänge halb abgeschlossen sind. Dieser Schaden entsteht vor dem Update und zeigt sich erst danach, was ihn leicht dem Update zuschreiben lässt.

Die Reihenfolge ist darum die ganze Vorsichtsmassnahme:

1. NeXTSTEP aus NeXTSTEP heraus herunterfahren und warten, bis die Maschine steht.
2. Den Kiosk anhalten, damit Previous nicht sofort wieder startet.
3. Eine Sicherung des Plattenabbilds anlegen.
4. Das Update einspielen.
5. Den Kiosk wieder anwerfen und nachsehen, ob der Anmeldeschirm kommt.

Der zweite Schritt ist der, den man leicht übersieht. Wie Abschnitt 4.4 beschreibt, startet systemd die Konsole nach dem Ende von Previous sofort neu, und damit auch den Emulator. Wer nur Strg+Alt+Q drückt, findet Sekunden später wieder einen laufenden NeXT vor, der seine Abbilddatei offen hält. Angehalten wird deshalb der Dienst, und das geht aus einer Sitzung über das Netz:

sudo systemctl stop getty@tty1

Danach ist der Bildschirm leer und die Abbilddatei frei. Am Ende bringt sudo systemctl start getty@tty1 die Maschine zurück.

Die Sicherung ist eine Kopie und dauert bei zwei Gigabyte einen Moment. Der Pfad ist der aus der eigenen Konfiguration:

cp "$HOME/nextstep/Nextstep 3.3 HD Image With Previous/NS33_2GB.dd" \
   "$HOME/nextstep/NS33_2GB.dd.$(date +%Y-%m-%d)"

Dafür muss auf dem Datenträger Platz für eine zweite Kopie sein. Ist er knapp, gehört die Sicherung auf einen USB-Stick oder über das Netz auf einen anderen Rechner.

Das Update selbst holt nur Previous, weil die Festlegung aus Abschnitt 4.1 aus diesem Archiv nichts anderes zulässt:

sudo apt update
sudo apt install --only-upgrade previous

Danach den Kiosk wieder anwerfen und den Anmeldeschirm abwarten, bevor die Maschine wieder sich selbst überlassen wird.

Eine neuere Fassung kann Einstellungen kennen, die es vorher nicht gab. Previous ergänzt sie beim ersten Beenden mit ihren Vorgaben und lässt vorhandene Werte stehen, sodass die Angaben aus Tabelle 3 erhalten bleiben. Fällt trotzdem etwas auf, etwa eine wieder sichtbare Statusleiste, ist die Tabelle die Stelle zum Nachsehen.

Geht etwas schief, ist der Weg zurück die Sicherung. Previous beenden, die Kopie an die Stelle des Abbilds zurückschieben und die vorherige Fassung des Pakets einspielen. Das Archiv hält ältere Fassungen vor, zur Zeit 4.3 neben 4.4³:

sudo apt install previous=4.3-0wmlive1

Quellennachweis

Neun Quellen, in der Reihenfolge ihres Auftretens.

1. Raspberry Pi Ltd (2025): Trixie, the new version of Raspberry Pi OS. Volltext gelesen Quelle↩
2. Grabher, A. und Schubiger, S.: The Previous Emulator. Seite mit den Ausgaben und den Abhängigkeiten. Volltext gelesen Quelle↩
3. Window Maker Live: Package Repository. Suite wmlive-trixie, signiert, führt Previous für i386, amd64 und arm64. Paketliste gelesen Quelle↩↩
4. Debian Project: Package libpng16-16t64 in trixie. Fassung 1.6.48-1+deb13u5, verfügbar für arm64. Volltext gelesen Quelle↩
5. Debian Project: Package cage in trixie. Fassung 0.2.0-2, ein Kiosk-Compositor für Wayland, verfügbar für arm64. Volltext gelesen Quelle↩
6. Debian Project: Package 7zip in trixie. Liefert /usr/bin/7z; p7zip-full ist dort nur noch ein Übergangspaket, das hierauf zeigt. Dateiliste gelesen Quelle↩
7. NeXT Computers Inc.: Nextstep 3.3 HD Image With Previous. Internet Archive. Beschreibung gelesen Quelle↩
8. NeXT: NeXTSTEP 3.3 (m68k/i386). Internet Archive. Beschreibung gelesen Quelle↩
9. NeXT Computer Inc.: NEXTSTEP 3.3 Network and CD Boot Q&A. NeXT Answers 2662. Volltext gelesen Quelle↩↩