Engineering-Philosophie: Linus Torvalds, der Sonderfall, der verschwindet

Die wichtigsten Erkenntnisse

• Guter Geschmack bedeutet, dass der Sonderfall verschwindet. Formen Sie die Datenstruktur um – ein Zeiger auf einen Zeiger statt eines einzelnen Zeigers – und das if für den Randfall hat keinen Ort mehr, an dem es existieren könnte.
• „Show me the code” ist eine Erkenntnistheorie, kein Slogan. Ein Entwurf ist eine Hypothese; erst der laufende Code entscheidet die Diskussion.
• git macht Verteilung zu einer Folge seiner Datenstruktur. Inhaltsadressierte Objekte bedeuten, dass jedes Repository gleichwertig ist – „die eine wahre Kopie” existiert also nie, die man verteidigen müsste.
• Vertrauen im großen Maßstab muss strukturiert werden, nicht vorausgesetzt. Torvalds löste das Problem gleich zweimal – mit einem Maintainer-Baum für die Frage, wer verantwortlich ist, und mit einer manipulationssicheren Historie für die Frage, was geschehen ist.

Das Prinzip

„Ich möchte, dass Sie verstehen: Manchmal kann man ein Problem auf eine andere Weise sehen und es so umschreiben, dass ein Sonderfall wegfällt und zum Normalfall wird – und das ist guter Code.” – Linus Torvalds, TED, 2016¹

Torvalds stand auf einer TED-Bühne und hielt zwei C-Funktionen nebeneinander. Beide löschten einen Eintrag aus einer einfach verketteten Liste. Die erste lief mit einem prev-Zeiger durch die Liste, prüfte, ob der zu entfernende Eintrag der Kopf war, und verzweigte: Sonderfall für den Kopf, allgemeiner Fall für alles Übrige. Zehn Zeilen, ein if. Die zweite Funktion lief mit einem Zeiger auf einen Zeiger durch die Liste – **indirect – sodass der Kopf überhaupt kein besonderer Ort mehr war. Er war einfach das Erste, worauf der Zeiger-auf-Zeiger zufällig zeigte. Vier Zeilen, kein if.¹

Weniger Zeilen waren nie der Punkt. Die Bedingung in der ersten Variante existierte nur, weil der Programmierer den Kopf der Liste als etwas anderes modellierte als den Rest der Liste. Wählen Sie eine bessere Datenstruktur – einen Zeiger auf einen Zeiger statt eines einzelnen Zeigers – und der Unterschied verdampft. Der Randfall war dem Problem nie inhärent; er war ein Artefakt der Art und Weise, wie das Problem dargestellt worden war. Geschmack bedeutet in Torvalds’ Sinn genau diesen Schritt, und es ist dieselbe Überzeugung, die Geschmack zu einem technischen System macht statt zu einer ästhetischen Vorliebe: Die elegante Variante gewinnt nicht, weil sie hübscher ist, sondern weil sie korrekter ist – weil ihr weniger Stellen bleiben, an denen sie falsch sein könnte.

Dieser Instinkt – den Sonderfall beseitigen, damit der Randfall sich nirgends mehr verstecken kann – zieht sich durch alles, was Torvalds gebaut hat. Er erklärt auch, warum sich sein anderer berühmter Satz weniger wie ein Manifest liest als wie eine Anweisung: „Talk is cheap. Show me the code.”²

Probieren Sie es oben aus: Löschen Sie einen mittleren Knoten und löschen Sie dann in jedem Modus den Kopf. Bei „der naheliegenden Weise” löst der Kopf den Zweig if (!prev) aus; bei „gutem Geschmack” ist der Kopf nur eine weitere Verknüpfung, und dieselbe einzelne Zeile behandelt ihn.

Kontext

Linus Benedict Torvalds wurde 1969 in Helsinki, Finnland, in eine schwedischsprachige Familie geboren. Als Informatikstudent an der Universität Helsinki betrieb er Minix, ein kleines unixähnliches Betriebssystem, das der niederländische Professor Andrew Tanenbaum als Lehrmittel geschrieben hatte. Minix war lehrreich, aber bewusst eingeschränkt – Tanenbaum hielt es einfach, damit Studenten das Ganze lesen konnten. Torvalds wollte mehr, als ihm zugestanden wurde.

Am 25. August 1991 schrieb er in die Usenet-Newsgroup comp.os.minix: „I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.”³ Die Einschränkung in der Klammer ist die meistzitierte Fehleinschätzung der Softwaregeschichte.

Aus dem Hobby wurde nach jedem Maßstab des Einsatzes der am weitesten verbreitete Kernel der Welt – er treibt die Mehrheit der Webserver, jedes Android-Telefon und den überwältigenden Anteil der Cloud- und Supercomputing-Infrastruktur an.

Die Architektur war von Anfang an umstritten. Anfang 1992 eröffnete Tanenbaum einen Diskussionsstrang mit dem Titel „LINUX is obsolete” und argumentierte, ein monolithischer Kernel sei „ein gewaltiger Schritt zurück in die 1970er Jahre” und Microkernels – bei denen das Betriebssystem in isolierte, über Nachrichten kommunizierende Dienste zerlegt wird – seien die Zukunft.⁴ Torvalds räumte ein, dass Microkernels „aus theoretischer und ästhetischer” Sicht überlegen seien, baute dann aber den monolithischen weiter, weil er funktionierte, weil er schnell war und weil er auslieferte. Die Debatte ist als Gründungsdokument einer Geisteshaltung in Erinnerung: Die Theorie unterliegt einem System, das läuft.

Das Werk

Der Linux-Kernel (1991–): Ein Monolith, der skalierte

Linux ist ein monolithischer Kernel: Scheduler, Speicherverwaltung, Dateisysteme und Gerätetreiber laufen alle in einem einzigen privilegierten Adressraum. Tanenbaums Kritik war theoretisch nicht falsch – ein Fehler in einem monolithischen Treiber kann das System auf eine Weise lahmlegen, die ein Microkernel isolieren kann. Torvalds’ Antwort war empirisch. Der Monolith war schneller, einfacher zu schreiben und konnte von Tausenden von Beitragenden verändert werden, ohne dass jeder von ihnen zuerst ein Nachrichtenprotokoll lernen musste. Die Architektur, die das akademische Argument verlor, gewann den Einsatzkrieg, weil sie die Kosten für Beiträge senkte.

Der Kernel ist heute eines der größten kollaborativen Ingenieursartefakte, die je geschaffen wurden – Dutzende Millionen Codezeilen, Tausende Beitragende pro Release. Nichts von dieser Größenordnung wurde im Voraus entworfen. Sie wuchs an, ein eingepflegter Patch nach dem anderen, unter einem Entwicklungsmodell, das Torvalds ebenfalls erfinden musste.

Das Maintainer-Modell: Vertrauen als Baum

Torvalds liest den Großteil des Codes, der in Linux einfließt, nicht. Er kann es nicht – die Menge übersteigt bei Weitem die Möglichkeiten eines einzelnen Menschen. Stattdessen wird der Kernel durch eine Hierarchie des Vertrauens regiert. Subsystem-Maintainer verantworten ihre Bereiche. Sie überprüfen Patches, nehmen sie in ihre Bäume auf und senden Pull-Requests nach oben an Leutnants und letztlich an Torvalds, der die Bäume zusammenführt, denen er vertraut. Er ist der wohlwollende Diktator an der Wurzel, aber seine eigentliche Aufgabe besteht darin, zu kuratieren, wem er vertraut, nicht jede Zeile zu prüfen, die sie produzieren.

Der Maintainer-Baum ist eine soziale Architektur, und er steht vor demselben Problem wie jede moderne Software-Lieferkette: Man kann nicht alles persönlich überprüfen, also muss Vertrauen strukturiert statt vorausgesetzt werden. Deshalb sollte ein Repository nicht über seine eigene Vertrauenswürdigkeit abstimmen dürfen und deshalb ist Open Source keine Sicherheitsgrenze – die vielen Augenpaare helfen nur, wenn jemand für das Hinsehen verantwortlich ist. Die Mailingliste mit ihrer berüchtigt schonungslosen Durchsicht ist der Mechanismus, der den Vertrauensbaum lesbar macht: Entscheidungen und ihre Begründungen sind öffentlich, archiviert und zuordenbar.

git (2005): Verteiltes Vertrauen als Datenstruktur

Jahrelang wurde der Kernel mit BitKeeper entwickelt, einem proprietären, verteilten Versionskontrollsystem, dessen Hersteller dem Projekt die kostenlose Nutzung gewährte. 2005 brach diese Vereinbarung in einem Lizenzstreit zusammen, und Torvalds stand plötzlich ohne ein Werkzeug da, das den Arbeitsablauf des Kernels bewältigen konnte.⁵ Also schrieb er eines. Der erste Commit zu git erfolgte am 7. April 2005; innerhalb von etwa zehn Tagen verwaltete es sich selbst und den Kernel.⁶

Was git zu einem Ausdruck desselben Prinzips macht wie das Beispiel der verketteten Liste, ist seine zentrale Datenstruktur. git speichert keine Diffs und rekonstruiert daraus den Zustand. Jede Version jeder Datei, jeder Verzeichnisbaum, jeder Commit wird als Objekt gespeichert, das nach dem SHA-1-Hash seines eigenen Inhalts benannt ist – ein inhaltsadressierter Speicher. Torvalds stellt ausdrücklich klar, dass es beim Hashing „nie um die Sicherheit ging. Es ging darum, Beschädigungen zu finden.”⁶ Identität ist Inhalt: Zwei Dateien mit denselben Bytes sind automatisch dasselbe Objekt, und ein einziges gekipptes Bit erzeugt einen anderen Namen und ist erkennbar. Und weil „jedes Repository gleich und gleichwertig ist”, gibt es keinen privilegierten zentralen Server – der Sonderfall „die eine wahre Kopie” verschwindet auf dieselbe Weise wie der Sonderfall „der Kopf der Liste”.⁶ Verteilung ist keine Funktion, die git aufgesetzt wurde; sie ist eine Folge der Wahl der richtigen Datenstruktur.

Diese letzte Eigenschaft – eine manipulationssichere Kette inhaltsadressierter Commits – ist der Grund, warum der Commit-Graph über den Code hinaus Bedeutung tragen kann, und warum ich von der Sitzung als Commit-Nachricht denke: Die Historie ist das Artefakt, nicht ein Nebenprodukt davon.

Die Methode

Torvalds’ Methode ist Pragmatismus, der durch Evidenz durchgesetzt wird. „Talk is cheap. Show me the code” war eine wörtliche Antwort auf der Kernel-Mailingliste an jemanden, der beschrieb, was sein Patch tun würde.² Ein Entwurf ist eine Hypothese; der Patch ist das Experiment. Solange der Code nicht existiert und läuft, ist die Diskussion ungeklärt.

Darunter liegt seine präziseste Aussage darüber, wo das Urteilsvermögen eines Ingenieurs tatsächlich angesiedelt ist: „Schlechte Programmierer sorgen sich um den Code. Gute Programmierer sorgen sich um Datenstrukturen und ihre Beziehungen.”⁷ Das Beispiel der verketteten Liste ist dieser Satz, konkret gemacht. Ist die Datenstruktur richtig, so ist der Code, der auf ihr operiert, kurz und hat wenige Verzweigungen, weil die Struktur die Komplexität bereits aufgenommen hat. Ist die Datenstruktur falsch, zahlen Sie ewig dafür in Form von Sonderfällen – in if-Anweisungen, die nur existieren, um ein schlechtes Modell zu übertünchen. Sich um den Code zu sorgen, heißt, Symptome zu behandeln. Sich um die Datenstruktur zu sorgen, ist die Heilung.

Die Methode der Steuerung entspricht der technischen. Das Modell vom wohlwollenden Diktator und seinen Leutnants existiert weniger, um Ego zu konzentrieren, als um die Merge-Entscheidung einem einzigen Geschmack verantwortlich zu halten und zugleich die Arbeit der Durchsicht auf die Menschen zu verteilen, die jedem Subsystem am nächsten stehen. Und die Schonungslosigkeit seiner Code-Durchsicht – die nach seinem eigenen späteren Eingeständnis bisweilen in unnötige Härte übergegangen ist – entspringt derselben Wurzel: Der Code wird danach beurteilt, ob er richtig ist, nicht danach, wer ihn geschrieben hat oder wie viel Mühe er darstellt. Der Maßstab ist unpersönlich, selbst wenn die Überbringung es nicht war.

Einflusskette

Wer ihn geprägt hat

Andrew Tanenbaum und Minix. Minix war das Betriebssystem, an dem Torvalds lernte, und das, was er zu übertreffen versuchte. Tanenbaum gab ihm ein lesbares, unixähnliches System zum Studieren und – durch die Debatte „LINUX is obsolete” – ein Gegenüber, scharf genug, um genau zu klären, was Torvalds wertschätzte: ein System, das ausliefert, gegenüber einer Architektur, die befriedigt. (Prägender Einfluss)⁴

Unix und die GNU-Werkzeuge. Linux ist im Entwurfsstammbaum ein Unix – Prozesse, Dateien, Pipes, die Abstraktion „alles ist eine Datei”. Und es war nur nützlich, weil Compiler, Shell und Werkzeuge des GNU-Projekts bereits existierten, um darauf zu laufen; Torvalds portierte bash und gcc, bevor der Kernel überhaupt viel tun konnte.³ Er baute das eine fehlende Stück – den Kernel – und ließ die vorhandenen Stücke den Rest erledigen. Bauen Sie, was Sie brauchen; verwenden Sie wieder, was funktioniert. (Direkter Einfluss)

Wen er geprägt hat

Die gesamte Open-Source-Welt. Linux bewies, dass ein global verteilter Hybrid aus Freiwilligen und Unternehmen proprietäre Teams im größten Maßstab ingenieurmäßig übertreffen konnte, und das Maintainer-Modell wurde zur Vorlage dafür, wie große Open-Source-Projekte geführt werden.

Jedes verteilte Versionskontrollsystem danach. git hat nicht nur gewonnen – es wurde zum Fundament. GitHub, GitLab und der moderne Pull-Request-Arbeitsablauf bauen alle auf dem inhaltsadressierten, verteilten Modell auf, das Torvalds in jenen zehn Tagen wählte. Die Datenstruktur überlebte ihre Notlage.

Der rote Faden

John Carmack und Torvalds gelangen aus entgegengesetzten Fachgebieten an denselben Ort. Carmack presst ein Problem zusammen, bis Algorithmus und Hardware ohne jede Verschwendung ineinandergreifen; Torvalds formt ein Problem um, bis die Datenstruktur den Sonderfall verschwinden lässt. Beide behandeln Leistung und Eleganz als dieselbe Eigenschaft, von verschiedenen Seiten betrachtet, und beide weigern sich, die Theorie über etwas siegen zu lassen, das nachweislich läuft. Guter Geschmack bedeutet in dieser Reihe nie Verzierung; er bedeutet Korrektheit, die man spüren kann. (Brücke der Reihe)

Was ich daraus mitnehme

Die Lektion der verketteten Liste ist die, nach der ich am häufigsten greife. Wenn Code ein if ausbildet, um „das erste” oder „den leeren Fall” oder „den Admin-Benutzer” zu behandeln, ist dieser Zweig meist ein Geständnis, dass das Datenmodell ein wenig falsch ist. Die Lösung ist selten ein besseres if. Es ist eine bessere Darstellung, nach der der Zweig nicht mehr nötig ist, weil der Fall, gegen den er sich absicherte, nicht mehr eintreten kann. Das ist die billigstmögliche Absicherung: Ein Randfall, der nicht existieren kann, braucht keinen Code, der ihn behandelt.

Die zweite Lektion handelt von Vertrauen im großen Maßstab, und sie ist diejenige, die in der Welt, in der ich heute baue, am meisten zählt – Agentensysteme, in denen man Arbeit orchestriert, die man nicht Zeile für Zeile selbst geschrieben hat. Torvalds löste dasselbe Problem zweimal: sozial, mit einem Maintainer-Baum, der strukturiert, wer verantwortlich ist, und technisch, mit gits inhaltsadressierter Historie, die das, was geschehen ist, manipulationssicher macht. Sie können nicht alles lesen, was ein Agent produziert, ebenso wenig wie Torvalds jeden Kernel-Patch lesen kann. Also tun Sie, was er tat – Vertrauen strukturell machen und Historie überprüfbar machen –, und genau deshalb behandle ich Geschmack als Infrastruktur und die Lieferkette als Angriffsfläche. Die Disziplin, die aus einem Hobby einen Kernel baute, ist dieselbe Disziplin, die eine Codebasis beschleunigen statt verfallen lässt: Bringen Sie die Struktur in Ordnung, und die Sonderfälle hören auf, sich zu vermehren.

FAQ

Wie definiert Linus Torvalds „guten Geschmack” im Code?

In seinem TED-Interview von 2016 definierte Torvalds guten Geschmack anhand zweier Implementierungen des Löschens eines Elements aus einer verketteten Liste. Die Variante, die er geschmacklos nannte, behandelte das Entfernen des Listenkopfes mit einer if-Anweisung als Sonderfall; die Variante, die er guten Code nannte, nutzte einen Zeiger auf einen Zeiger, sodass der Kopf überhaupt kein Sonderfall mehr war. Seine Zusammenfassung: „Manchmal kann man ein Problem auf eine andere Weise sehen und es so umschreiben, dass ein Sonderfall wegfällt und zum Normalfall wird – und das ist guter Code.”¹

Was hat Linus Torvalds geschaffen?

Torvalds schuf den Linux-Kernel, den er erstmals am 25. August 1991 in der Newsgroup comp.os.minix ankündigte und der heute der am weitesten verbreitete Betriebssystem-Kernel der Welt ist. 2005 schuf er außerdem git, das verteilte Versionskontrollsystem, nachdem das Linux-Projekt den Zugang zum proprietären Werkzeug BitKeeper verloren hatte. Er ist nach wie vor der leitende Maintainer des Linux-Kernels.³⁵

Warum hat Linus Torvalds git gebaut, und wie lange dauerte es?

Das Linux-Projekt hatte BitKeeper genutzt, ein proprietäres, verteiltes Versionskontrollsystem, bis ein Lizenzstreit 2005 den kostenlosen Zugang des Projekts beendete. Torvalds schrieb git als Ersatz, mit dem ersten Commit am 7. April 2005 und dem Werkzeug, das den Kernel innerhalb von etwa zehn Tagen verwaltete – wobei er anmerkt, dass er zuvor Monate damit verbracht hatte, den Entwurf zu durchdenken.⁵⁶

Was bedeutet „Talk is cheap. Show me the code.”?

Torvalds schrieb diesen Satz am 25. August 2000 auf die Mailingliste des Linux-Kernels, als direkte Antwort auf eine Diskussion darüber, was bestimmter Code tun würde.² Er bringt seinen Pragmatismus auf den Punkt: Die Beschreibung eines Ansatzes ist nur eine Hypothese, und das Argument ist erst geklärt, wenn lauffähiger Code existiert, der ausgeführt und getestet werden kann. (Hinweis: Das verwandte „given enough eyeballs, all bugs are shallow” ist Linus’s Law in der Formulierung von Eric Raymond, kein Zitat von Torvalds selbst.⁸)

Quellen