Nein, ich bin nicht auf die Tastatur gefallen. Ich spiele zur Zeit mit alten Versionen von Unix. Mit sehr alten Versionen…
Disclaimer: Diesen Artikel habe ich nicht mit KI geschrieben, genau wie jeder andere in diesem Blog ist er von Hand formuliert. Holprig wie immer. Nur der Codeschnipsel am Ende ist synthetisch. Ich nutze hier aber tatsächlich Ausgaben von KI-Systemen. Erst um mich darüber lustig zu machen, am Ende hat eine KI aber offenbar doch meine Frage richtig und zufriedenstellend beantwortet. Soweit ich das beurteilen kann. Urteilt selbst.
Vor mehr als zehn Jahren war ich vom PiDP-8/I fasziniert, einem Gehäuse in dem sich ein Raspberry wie eine PDP-8 bedienen lässt, also wie ein Computer aus den 1960er Jahren. Zur Zeit denke ich ernsthaft über eine PiDP-11 nach, weil ich mit der PDP-11 tatsächlich deutlich mehr verbinde — unter anderem weil das die Wiege von Unix gewesen ist. Die Software für das Ding kann man freundlicherweise auch ohne die Hardware ausprobieren, und genau das mache ich mit wachsender Begeisterung.
Wir befinden uns also in einem 1st Edition Unix, auf der Rekonstruktion eines Systems von 1972.
Vor knapp 25 Jahren war ich eine Weile beruflich irgendwo in München, in einem Projekt mit mehreren Kollegen die deutlich mehr Unix-Erfahrung hatten als ich. Einer der Kollegen hat erzählt dass er in seiner Anfangszeit Wissen aufgebaut hat indem er sich die Dateien in /bin und /usr/bin angesehen, und dann jeweils die Man-Pages studiert hat. Gute Idee für einen ersten Überblick.
Mein Oldtimer hat keine Man-Pages. Die gab es zwar schon 1971, aber hier sind keine installiert.
Die meisten Kommandos konnte ich auch so identifizieren. Am Rande: achtet mal auf die Größen der Dateien. Auf meinem Linux umfasst /bin/cat etwa 50kB, /bin/chmod etwa 70kB. 
Die 76 Bytes von /bin/chball entzogen sich aber meiner Kenntnis.
In der Maschine gibt es keine Doku. Ich habe mir diverse Handbücher aus den 1970ern angesehen. Die sind wirklich gut, aber das Kommando wurde da nicht beschrieben. Im Git-Repo gibt es eine Datei in der viele Binaries kommentiert werden, aber auch da steht zu „chball“ nur „no idea“. Auch ansonsten haben meine Web-Recherchen nicht wirklich zu Ergebnissen geführt. Bis mir DuckDuckGo irgendwelche KI-Ergebnisse gegeben hat. Verzweiflungstat, vermutlich. Ebenso verzweifelt habe ich dann versucht aus diesem Ding Infos rauszupopeln.

Ich habe Ergebnisse bekommen. Und was für welche.
Die erste Idee war, dass /bin/chball gebraucht wurde wenn der Kugelkopf im Terminal getauscht wurde. Auf dem bekannten Foto von Dennis Ritchie und Ken Thompson an einer PDP-11 sind auch zwei Teletype 33 zu sehen, und die hatten Kugelköpfe. Aber der Tausch ist eher ein mechanischer Vorgang, wozu braucht man so ein Kommando? Die KI hat mir auch Beispielaufrufe gezeigt, die haben aber nur zu einer Fehlermeldung geführt. Und zu der Zeit war ein einfaches, vorwurfsvoll-nachdrückliches „?“ offenbar eine hinreichende Fehlermeldung.
Einen Tag später habe ich nochmal mein Glück versucht. Diesmal gab es eine genauso plausible, wenn auch komplett andere Erklärung. Das Kommando stünde für „change block allocation“. Das alte Dateisystem verfügt noch nicht über Inodes, deshalb muss man mit dem Kommando Platz im Dateisystem allozieren wenn die Datei größer wird.

Nanu? OK, neues Browserfenster, noch ein Versuch. Diesmal konnte man mit dem Kommando das ball-Bit von Dateien umschalten. Spannend, davon hatte ich noch nie gehört. Sonst aber auch niemand. Weil es einfach Quatsch ist. Und genau wie die Block-Allozierung nur zur gewohnten Fehlermeldung geführt hat.
Ich hatte also drei völlig unterschiedliche Erklärungen. Alle plausibel, alle selbstsicher formuliert, alle mit Anwendungsbeispielen, und alle führten nur zu einer Fehlermeldung. Völlig wertlos, also. 
Am nächsten Tag habe ich das einem Freund und Kollegen erzählt. Mit einer Prise Sarkasmus, und das hat ihn vermutlich getriggert. Er kennt sich deutlich besser mit LLMs aus als ich, und er hat Abends ChatGPT zur Rede gestellt. Und hatte 20 Minuten später ein umfassendes Dossier.
Er hat erst allgemein nach einer Erklärung gefragt. ChatGPT hatte auch die Info dass das was mit dem Kugelkopf zu tun hat, und hat vorgeschlagen das Binary zu untersuchen. Es hat sich das Festplatten-Image hochladen lassen in dem das Binary enthalten ist, hat das Binary extrahiert und dann in PDP-11 Syntax disassembliert. Den Assembler-Code hat es dann an den verwendeten Kernel gehalten um zu sehen welche Bedeutung das gesetzte Bit hat, und hat dann lesbaren C-Pseudocode generiert:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
gtty(0, tty); if (argv[1][0] == 'e') tty[2] &= ~02000; else if (argv[1][0] == 'c') tty[2] |= 02000; else { write(1, "?\n", 2); exit(); } stty(0, tty); |
Das Kommando müsste also als Parameter ein einfaches „e“ oder ein „c“ bekommen, daraufhin die Settings des aktuellen Terminals ändern. Ähnlich wie man das unter Linux mit stty macht. Und richtig genug: wenn man es in der simulierten Maschine so aufruft gibt es keine Fehlermeldung. Heureka!
Testen kann ich die Funktion allerdings nicht, dafür fehlt mir ein mechanisches Terminal — und mehrere Kugelköpfe. 
Das LLM hat noch ein paar Hintergrundinformationen gebracht, sogar Bilder von unterschiedlichen Kugelköpfen. Ich muss zugeben: alles was da rausgekommen ist sehe ich als logisch und plausibel an. Ich bin wirklich beeindruckt. Kritisch sehe ich das ganze immer noch, aber aus anderen Gründen. Das Ergebnis überzeugt, fast alles andere an der Technik sehe ich als fragwürdig an.
Das Kommando /bin/chball wird also tatsächlich nach dem Tausch des Kugelkopfes im Teletype gebraucht. Der Parameter e wird vermutlich gebraucht wenn man eine Kugel mit EBCDIC-Zeichensatz einbaut, mit dem Parameter c schaltet man wieder auf Correspondence-Zeichensatz um.

