KI-Agenten: Vom Floppy-Controller zum modernen Kernel in zwei Tagen
Dieser Artikel ist eine Übersetzung. Das Original findet sich hier im Blog des Softwareentwicklers Dimitry Brant(öffnet im neuen Fenster).
Vorab etwas über mich: Eins meiner Hobbys ist es, Leuten dabei zu helfen, Daten von alten Bandkassetten wie QIC-80-Bändern wiederherzustellen. Die waren in den 1990er Jahren ein beliebtes Backup-Medium für Privatpersonen, kleine Unternehmen, BBS-Betreiber und ähnliche Nutzer.
Ich habe eine Schwäche für Magnetband. Irgendwas an dem Gefühl, es in der Hand zu spüren, macht mir sehr viel Freude – trotz der vielen Designschwächen. Mit ein bisschen Vorsicht bei der Inspektion und Überarbeitung sind die Daten auf diesen Bändern auch nach all den Jahren noch vollständig wiederherstellbar.
Auf CentOS 3.5 angewiesen
Immer, wenn ich ein QIC-80-Band zum Wiederherstellen bekomme, fahre ich einen meiner älteren PC-Arbeitsplätze hoch, an den das entsprechende Bandlaufwerk angeschlossen ist, und starte eine sehr alte Version von Linux (CentOS 3.5). Dies ist die einzige Möglichkeit, den ftape-Treiber zu verwenden, der für die Kommunikation mit diesem Bandlaufwerk erforderlich ist, und es ermöglicht, den Binärinhalt des Bandes zu sichern.
Das Laufwerk, das diese Bänder liest, ist nämlich mit dem Floppy-Controller auf der Hauptplatine verbunden. Dieser clevere Hack wurde aus Kostengründen entwickelt: Statt einen separaten SCSI-Adapter (die Standardschnittstelle für hochwertigere Bandmedien) zu kaufen, konnte man dieses Bandlaufwerk einfach an den Floppy-Controller anschließen, den die meisten PCs ohnehin hatten. Es kann sogar zusammen mit dem vorhandenen Floppy-Laufwerk über dasselbe Flachbandkabel betrieben werden.
Eine Datenrate von 500 Kbps
Der Nachteil war natürlich, dass die Datenrate durch die Geschwindigkeit des Floppy-Controllers, die bei etwa 500 Kbps (das sind Kilobit, nicht Byte) lag, begrenzt war. Ein weiterer Nachteil war, dass das Protokoll für die Kommunikation mit diesen Bandlaufwerken über den Floppy-Controller sehr unübersichtlich, nicht standardisiert und nicht besonders gut unterstützt war.
Es handelte sich in jeder Hinsicht um einen Hack: Das Bios des Motherboards wusste nichts von dem angeschlossenen Bandlaufwerk, und es lag vollständig in der Verantwortung der Endbenutzersoftware, genau zu wissen, wie die Hardware-E/A-Ports, Timings, Interrupts usw. zu manipulieren waren, um den Floppy-Controller dazu zu bringen, die entsprechenden Befehle an das Bandlaufwerk zu senden.
Es gab ein paar wenige proprietäre Tools für MS-DOS und Windows 3.x/9x für den Umgang mit diesen Laufwerken und nur eine Open-Source-Implementierung für Linux, nämlich ftape. Natürlich kann man diese ursprünglichen DOS/Windows-Tools zum Lesen der Bänder verwenden, aber nur ftape ermöglicht es, den rohen Binärinhalt des Bandes zu lesen – unabhängig davon, welche proprietäre Software ihn ursprünglich geschrieben hat.
Deshalb dumpe ich den Inhalt lieber und kümmere mich erst danach um die Dekodierung der proprietären logischen Formatierung und die anschließende Extraktion der Dateien.
Das Problem ist, dass der ftape-Treiber seit etwa 2000 nicht mehr unterstützt wird und daher aus dem Linux-Kernel entfernt wurde. Also muss ich jedes Mal, wenn ich mit einem dieser Laufwerke arbeite, eine verdammt veraltete Version von Linux ausführen. Wie cool wäre es, wenn ftape auf einer modernen Distribution funktionieren würde, mit all deren Vorteilen und Möglichkeiten.
Claude, bitte kommen!
Vor ein paar Wochen kam ich daher auf die Idee, diese einfache Aufforderung an Claude zu formulieren:
Nach mehreren Durchläufen, in denen Claude angab, es sei mit "Compobulation" und wer weiß was noch beschäftigt, hatte ich plötzlich einen Kernel-Treiber, der fehlerlos kompiliert wurde. Claude kann nämlich die Ausgabe des Compilers nehmen und wieder in sich selbst einspeisen, bis die Kompilierung korrekt funktioniert.
Eine Menge Kernel-Funktionen und -Strukturen waren in der langen Zeit zwischen Kernel-Version 2.4 und 6.8 verständlicherweise veraltet oder ersetzt worden. Erstaunlicherweise fand Claude alle veralteten Teile und ersetzte sie durch die korrekten modernen Entsprechungen, wobei nur wenige manuelle Nachbesserungen am Code erforderlich waren (dazu später mehr).
Allerdings wurde in diesem Stadium noch erwartet, dass der Kernel-Treiber als Teil eines vollständigen Kernel-Baums kompiliert wird. Ich wollte ihn aber nur als eigenständiges, ladbares Kernel-Modul haben. OK, kein Problem:
Und so war es auch, ohne weitere Aufforderung. Am Ende dieser Phase hatte ich ein ladbares Kernel-Modul (.ko), das ich nun mit echter Live-Hardware ausprobieren konnte. Wenig überraschend funktionierte das Modul noch nicht: Es wurde zwar geladen, aber irgendetwas hinderte es daran, korrekt mit dem Bandlaufwerk zu kommunizieren. Aber ich machte weiter.
Da von dort an das Laden/Entladen von Kernel-Modulen mit sudo-Rechten verbunden ist, konnte ich Claude solche heiklen Vorgänge nicht mehr selbstständig iterieren lassen. Glücklicherweise war der ftape-Treiber bereits großzügig mit Protokollmeldungen versehen (printk()-Aufrufe, die in dmesg ausgegeben werden), so dass ich das Modul selbst laden und die Ausgabe von dmesg manuell in Claude einfügen konnte, um sie mit einem "bekanntermaßen fehlerfreien" dmesg-Protokoll zu vergleichen, das ich zuvor von einem erfolgreichen Bandlesevorgang gespeichert hatte.
Nach einigen Wiederholungen dieses Vorgangs identifizierte Claude die verbleibenden Probleme, welche die Kommunikation des Moduls mit der Hardware verhinderten.
Und endlich hatte ich ein Kernel-Modul, das a) geladen werden konnte, b) das Bandlaufwerk erkannte und c) den Inhalt eines Testbandes auslesen konnte.
Die Verwendung des ftape-Treibers auf einem modernen Kernel – eine Aufgabe, die ich für unerreichbar gehalten hatte – war innerhalb von zwei Abenden möglich geworden.
Was ich aus der Arbeit mit Claude gelernt habe
Als große Einschränkung muss ich anmerken, dass ich bereits ein wenig Erfahrung mit Kernel-Modulen und insgesamt viel Erfahrung mit C habe. Deshalb sollte Claudes Erfolg in diesem Szenario nicht überbewertet werden.
Es waren nicht wirklich nur drei Eingabeaufforderungen nötig, um Claude dazu zu bringen, ein funktionierendes Kernel-Modul auszuspucken, sondern einiges Hin und Her – und, ja, mehrere manuelle Korrekturen des Codes. Ohne Grundkenntnisse über die Interna eines Kernelmoduls wäre diese Modernisierung nicht möglich gewesen.
Dies brachte mich dazu, ein paar Gedanken zur Arbeit mit solchen Codierungsagenten in der heutigen Zeit zu formulieren.
Offen sein für Zusammenarbeit
Die Interaktion mit Claude Code fühlte sich wie eine echte Zusammenarbeit mit einem Kollegen an. Sie wird oft mit der Zusammenarbeit mit einem Junior-Entwickler verglichen, und das trifft es ziemlich gut: Claude Code tut alles, was man ihm sagt, will gefallen, ist übermäßig selbstbewusst, entschuldigt sich schnell, lobt einen dafür, dass man "absolut Recht" habe, wenn man auf einen Fehler hinweist, und so weiter. Aus diesem Grund muss der Mensch immer noch die Leitplanken setzen, Produktentscheidungen treffen, Architekturrichtlinien durchsetzen und potenzielle Probleme so früh wie möglich erkennen.
So konkret wie möglich sein und spezifische Schlüsselwörter verwenden
Ich behaupte nicht, plötzlich Experte für Prompt Engineering zu sein, aber am erfolgreichsten waren für mich die Prompts, die das verbale Gerüst eines Features klar beschreiben und anschließend präzise benennen, welche Lücken dieses Gerüsts vom LLM gefüllt werden sollen. (Aus irgendeinem Grund kommt mir dabei das Bild eines biologischen Stammzellgerüsts in den Sinn, auf dem ein künstliches menschliches Ohr wächst.)
Ein Gespür dafür entwickeln, welche Aufgaben für einen Agenten geeignet sind
Agenten sind keine Zauberer und können nicht alles tun, was wir von ihnen verlangen. Wir sollten sie nicht mit einer Aufgabe betrauen, für die sie ungeeignet sind, dann frustriert sein und die Tools vorschnell ablehnen. Es ist hilfreich, sich mit der Funktionsweise von LLMs vertraut zu machen, um ein Gespür für ihre Stärken und Schwächen zu entwickeln.
Tools als Multiplikatoren für eigene Fähigkeiten nutzen
Ich bin mir sicher, dass ich die beschriebene Modernisierung auch alleine geschafft hätte, wenn ich wirklich gewollt hätte. Aber dafür hätte ich mich mit der Kernel-Entwicklung vor 25 Jahren auskennen müssen. Ich hätte wahrscheinlich wochenlang Dokumentationen gewälzt, die heute völlig nutzlos sind. Stattdessen verbrachte ich ein paar Tage damit, mit einem Agenten zu chatten und mir von ihm erklären zu lassen, was er gemacht hat.
Natürlich habe ich die vorgenommenen Änderungen überprüft und getestet – und dabei eine Menge gelernt, das mir in Zukunft nützlich sein wird, zum Beispiel moderne Kernel-Konventionen, einige interessante Details der x86-Architektur und mehrere Befehlszeilenbefehle, die ich in meinem Repertoire behalten werde.
Tools für eine schnelle Einarbeitung in neue Frameworks nutzen
Ich bin kein Kernel-Entwickler, aber die Erfahrung hat einen Funken entfacht, der zu mehr Arbeit auf Kernel-Ebene führen könnte. Und es hat sich herausgestellt, dass die Kernel-Entwicklung gar nicht so schwierig ist, wie sie vielleicht klingt.
Ich habe auch schon eine Flutter-App erstellt, ohne je zuvor mit Flutter gearbeitet zu haben. Wer wie ich am liebsten durch praktische Anwendung lernt, gewinnt durch diese Tools massiv Tempo beim Erlernen neuer Frameworks – und hat mehr Zeit für wichtige architektonische Überlegungen.
Ich freue mich jedenfalls, jetzt sagen zu können: ftape lebt weiter! 25 Jahre nach seiner letzten offiziellen Veröffentlichung lässt es sich wieder unter modernem Linux kompilieren und verwenden.
Ich arbeite noch an Optimierungen und füge neue Funktionen hinzu, aber habe bereits überprüft, dass es mit den floppybasierten Bandlaufwerken in meiner Sammlung sowie mit parallelportbasierten Laufwerken, die es ebenfalls unterstützt, funktioniert.
Das physische Set-up sieht sehr ähnlich aus, aber das Betriebssystem ist jetzt Xubuntu 24.04 statt CentOS 3.5!
Übersetzt von Juliane Gunardono mit Unterstützung von DeepL
- Anzeige Hier geht es zu Künstliche Intelligenz: Wissensverarbeitung bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.