Dieses Buch hat mir 6 wichtige Fakten über Linux beigebracht.

Die Kunst der Unix-Programmierung (The Art of Unix Programming, TAoUP) von Eric S. Raymond ist kein Lehrbuch oder Handbuch. Vielmehr handelt es sich um ein Buch über die Geschichte und Philosophie von Unix. Doch kein anderes Buch hatte einen größeren Einfluss auf meine Herangehensweise zu Linux und macOS sowie auf meine tägliche Nutzung dieser Systeme. Hier sind nur einige der Dinge, die mir dieses Buch beigebracht hat.

Unix ist noch älter, als Sie denken.

Heutzutage müssen Sie die gesamte Geschichte von Unix nicht kennen, um es - oder Linux bzw. macOS - zu verwenden. Doch ein wenig über die Entstehung von Unix zu wissen, schadet nicht. Das Verständnis des Kontexts des Betriebssystems hilft Ihnen, die angezeigte Oberfläche zu verstehen; außerdem kann die Geschichte viele Ihrer anfänglichen Fragen beantworten - beispielsweise: „Warum sind die Befehlsnamen so kurz?“

Das zweite Kapitel - „Geschichte: Eine Geschichte zweier Kulturen“ - erklärt, wie Unix im Jahr 1969 auf Teletype-Geräten entstand, die wie hochwertige Schreibmaschinen aussahen. Es ist erstaunlich, dass diese Geräte noch immer Gemeinsamkeiten mit vielen der Server haben, die unser Online-Leben ermöglichen.

Heutzutage ist es in Ordnung, Linux als eine Art Unix-Klon zu betrachten - was es im Grunde auch ist. Doch seine Geschichte ist viel länger und reicher, als es den Anschein hat. Ich bin stolz darauf, ein System zu verwenden, das Wurzeln vor fünfzig Jahren hat - auch angesichts aller technologischen Fortschritte seither.

Ohne Linux wäre Open Source nichts.

TAoUP behandelt anschließend die Entstehung von Linux sowie die Frage, wie Linus Torvalds Ansatz ein Kompromiss zwischen proprietären, abgeschlossenen Systemen und der ideologischen Freiheit war, für die die aufkommende Open-Source-Bewegung stand.

Die Open-Source-Bewegung ist für die Geschichte von Linux so entscheidend, dass man sie leicht als identisch mit Linux betrachten könnte. Doch es ist faszinierend, mehr über die Geschichte der Open Source zu erfahren sowie zu vergleichen, wie sie zum proprietären Ansatz oder zur GNU-Alternative („freie Software“) steht.

Schon in den 1950er Jahren teilten Ingenieure Quellcode, lasen ihn und modifizierten ihn. Erst in den 1990er Jahren jedoch, als Linux auf den Markt kam, begann die weite Verbreitung von Open-Source-Software. Dies fiel mit der zunehmenden Verfügbarkeit des Internets zusammen - einem Verteilungsmechanismus, der die Entwicklung von Open-Source-Software erst richtig in Gang setzte.

Linux steht für Einfachheit (ehrlich!)

Obwohl es auf den ersten Blick kompliziert erscheinen mag, basiert Linux auf einfachen Grundprinzipien. Wenn es eine Lektion gibt, die dieses Buch mehr als jede andere vermittelt, dann ist es gerade diese. Der gesamte Design-Teil (Kapitel 4-13) erklärt, warum der grundlegende Unix-Geist so vorteilhaft ist.

Raymond untersucht dieses Konzept, indem er es in eine Reihe von „Regeln“ aufteilt, die die „Elders“ von Unix (Personen wie Rob Pike und Ken Thompson) zuvor weniger formal formuliert hatten. Zu diesen 17 Regeln gehören:

• Modularität
• Zusammensetzung
• Einfachheit
• Transparenz
• Stille

Die Regeln lassen sich im Grunde auf ein bekanntes Prinzip reduzieren: KISS (Keep it simple, stupid!). Indem kleine Programme gefördert werden, die grundlegende, konkrete Aufgaben ausführen und über ein einfaches Textprotokoll kommunizieren, entstehen gemäß der Unix-Philosophie wiederverwendbare und zuverlässige Werkzeuge.

Präzise, modulare Programme sorgen dafür, dass alles funktioniert.

Die erste der Regeln von Raymond lautet „Modularität“. Sie wird wie folgt beschrieben: „Schreiben Sie einfache Komponenten, die durch klare Schnittstellen miteinander verbunden sind.“ Wie bei vielen anderen Regeln liegt der Schwerpunkt auch hier auf der Beherrschung der Komplexität. Viele Probleme im Umgang mit Computern entstehen durch komplexe Systeme, die schwer zu verstehen sind. Indem die Einfachheit gefördert wird, soll diese Regel Fehler reduzieren und das Verständnis insgesamt verbessern.

Wenn man zum ersten Mal mit Linux-Tools wie ls oder grep in Berührung kommt, fällt es schwer, sie als vollwertige Programme an sich zu betrachten. Sie leisten bei weitem nicht so viel wie ein Webbrowser oder ein Textverarbeitungsprogramm - daher können sie trivial oder unbedeutend erscheinen. Doch dabei übersieht man die inhärente Stärke der Modularität: Kleine Programme lassen sich zu etwas Größerem kombinieren, als die Summe ihrer Einzelteile es wäre.

Eines der praktischsten Beispiele für die Macht der Modularität ist das Rohr:

ls | grep "foo"

Hier ist ein Beispiel für ein sehr häufig vorkommendes Muster, auf das ich immer wieder zurückgreife:

du -sk * | sort -rn | head

Diese Pipeline führt drei Programme aus: „du“, um die Gesamtgröße der passenden Dateien/Verzeichnisse anzuzeigen; „sort“, um sie numerisch zu sortieren; sowie „head“, um die ersten zehn Ergebnisse auszugeben. Das Ergebnis ist eine kleine Liste von Verzeichnissen, die am meisten Speicherplatz auf der Festplatte belegen - diese kann ich anschließend bereinigen.

Ohne Pipes wäre die Alternative ein einziges Programm, das so heißen könnte wie „get-biggest-ten-folders“. Ein solches Programm könnte sogar praktischer sein - doch es ist bei weitem eingeschränkter als die allgemein verfügbaren Werkzeuge. Ohne Pipes bräuchte man eine unglaubliche Anzahl an Programmen mit unhandlichen Namen; deren Komplexität wäre zweifellos schrecklich zu handhaben.

Der Text ist die Grundlage von allem.

Kapitel 5 des Buches befasst sich ausschließlich mit der Textualität - sowohl hinsichtlich der Dateiformate als auch der Art und Weise, wie Unix-Programme miteinander kommunizieren. Das war eines der Dinge, die mich an Unix am meisten beeindruckt haben - insbesondere im Zusammenhang mit der Konfiguration. Aus Windows gewöhnt, war ich an die Registrierung, jene berüchtigte, undurchsichtige und monolithische Datenbank, in der die Programmeinstellungen gespeichert werden.

Linux-Tools hingegen verwenden meist textbasierte Konfigurationsdateien, die über das Dateisystem verteilt sind (an üblichen Stellen, falls gewünscht). Diese Dateien können mit einem beliebigen Texteditor bearbeitet sowie mit gängigen Kommandozeilen-Tools ausgelesen werden. Das bedeutet, dass keine speziellen GUI-Tools erforderlich sind, um Einstellungen zu ändern - auch wenn solche Tools auf dem traditionellen Textdateiformat aufbauen können.

Diese Philosophie erstreckt sich auch auf die Kommunikation zwischen Programmen. Wenn Sie eine Pipeline verwenden, übergeben Sie Text von einem Programm an ein anderes. Zu jedem Zeitpunkt können Sie die Pipeline unterbrechen, um sie zu debuggen. Nehmen wir diese Pipeline als Beispiel:

ls | grep "txt"

Durch das Einfügen des `tee`-Befehls können Sie die Ausgabe an einer bestimmten Stelle abfangen und zur Debugging-Zwecken in eine Datei speichern:

ls | tee debug-ls-output.txt | grep "txt"

Das hängt mit Raymonds Regel der Transparenz zusammen:

„Design für bessere Sichtbarkeit, um Inspektionen und Debugging zu erleichtern.“

Die Verwendung von Text als Kommunikations- und Datenschnittstelle bedeutet, dass Programme offen arbeiten und weniger versteckte Bestandteile haben. Dadurch wird es einfacher, Programme zu reparieren, aus ihnen zu lernen und sie zu nutzen.

Linux bleibt beharrlich traditionell - zum Guten oder zum Schlechten.

Linux - und insbesondere Unix - wird oft als „altmodisch“ betrachtet, als ein System, das nur von „Oldies“ und Fanatikern geschätzt wird. Zwar mag da ein Körnchen Wahrheit dran sein, doch wird dabei übersehen, dass reife, weiterentwickelte Technologien nicht zwangsläufig schlecht sind.

In Kapitel 14 erörtert Raymond die Verwendung von C, das eine entscheidende Rolle bei der Entwicklung von Linux gespielt hat. Obwohl sich die Situation im Laufe der Zeit verändert hat, werden viele der gängigen Befehlszeilentools auch heute noch in C geschrieben. Das Buch weist darauf hin, dass C sich so weit verbreitet hat - unter anderem aufgrund der hervorragenden Werkzeugunterstützung, die der Test der Zeit bestanden hat.

Raymond ist kein Absolutist; er erklärt, warum Python, eine relativ moderne Programmiersprache, eine bessere Wahl für neue Projekte ist. Gleichzeitig beleuchtet er die Vor- und Nachteile der Shell-Programmierung und vertritt die Ansicht, dass die objektorientierte Programmierung nicht perfekt ist. Wie ein großer Teil des Buches argumentiert auch dieser Abschnitt gegen Einheitslösungen und betont, wie wichtig der Kontext stets ist.

„The Art of Unix Programming“ ist sowohl online kostenlos als auch in gedruckter Form erhältlich. Ich bin ein großer Fan beider Versionen: Die Online-Version eignet sich hervorragend als Nachschlagewerk, doch das Buch ist so gut geschrieben, dass es eine Freude ist, es von Anfang bis Ende zu lesen.