Dieses Buch hat mir 6 wichtige Fakten über Linux beigebracht

Eric S. Raymonds „Die Kunst des Unix-Programmierens“ vermittelt essentielle Einblicke in die Geschichte, Philosophie und Praktiken von Unix, die Nutzererfahrung und Programmierung nachhaltig beeinflussen.

Die Kunst des Unix-Programmierens (TAoUP) von Eric S. Raymond ist kein Tutorial oder Ratgeberbuch. Stattdessen handelt es sich um ein Buch über die Geschichte und Philosophie von Unix. Kein anderes Buch hat meinen Ansatz zu Linux und macOS oder meine alltägliche Nutzung davon stärker beeinflusst. Hier sind nur einige der Dinge, die es mich gelehrt hat.

Unix ist sogar älter als Sie denken

Sie müssen die gesamte Geschichte von Unix nicht kennen, um es – oder Linux oder macOS – heute zu nutzen. Aber ein wenig über die Ursprünge von Unix zu wissen, kann nicht schaden. Das Verständnis des Kontexts des Betriebssystems hilft Ihnen, den Bildschirm zu verstehen, auf den Sie schauen, und die Geschichte kann viele Ihrer ersten Fragen beantworten, wie „Warum sind Befehlsnamen so kurz?“

Im zweiten Kapitel – „Geschichte: Ein Märchen zweier Kulturen“ – wird erklärt, wie Unix 1969 auf Teletype-Maschinen begann, die wie glorifizierte Schreibmaschinen aussahen. Es ist erstaunlich zu denken, dass diese Maschinen noch immer etwas mit vielen der Server gemeinsam haben, die unser Online-Leben antreiben.

Heutzutage ist es in Ordnung, Linux als einen Unix-Klon zu betrachten, was es im Wesentlichen ist. Aber diese Geschichte ist viel länger und reicher, als es scheinen mag, und ich bin stolz darauf, ein System mit fünfzigjährigen Wurzeln zu nutzen, selbst angesichts jedes technologischen Fortschritts seitdem.

Open Source würde nichts sein ohne Linux

TAoUP behandelt die Geburtsstunde von Linux und wie Linus Torvalds' Ansatz ein Kompromiss zwischen proprietären, geschlossenen Systemen und der ideologischen Freiheit war, für die die aufkommende Open-Source-Bewegung einstand.

Die Open-Source-Bewegung ist so entscheidend für die Geschichte von Linux, dass es leichtfällt, sie als eins und dasselbe zu betrachten. Aber es ist faszinierend, mehr über die Geschichte von Open Source herauszufinden und wie sie sich mit dem proprietären Ansatz oder der GNU-Alternative („freie Software“) vergleicht.

Sogar in den 1950er Jahren teilten Ingenieure Quellcode, lasen ihn und modifizierten ihn. Doch erst in den 1990er Jahren, als Linux auf der Bildfläche erschien, wurde Open-Source-Software weit verbreitet. Dies fiel mit der breiteren Verfügbarkeit des Internets zusammen, einem Verbreitungsmechanismus, der es ermöglichte, dass Open-Source-Entwicklung richtig Aufwind bekam.

Linux umarmt Einfachheit (ehrlich!)

Obwohl es zunächst kompliziert erscheinen mag, basiert Linux auf einfachen grundlegenden Prinzipien. Wenn es eine Lektion gibt, die das Buch mehr als jede andere vermittelt, dann ist es diese. Der gesamte Abschnitt über Design (Kapitel 4–13) erklärt, warum die grundlegende Unix-Ethische so vorteilhaft ist.

Raymond untersucht dieses Konzept, indem er es in eine Reihe von „Regeln“ aufschlüsselt, die die „Elder“ von Unix (Menschen wie Rob Pike und Ken Thompson) zuvor weniger formell formuliert hatten. Diese 17 Regeln beinhalten:

• Modularität
• Komposition
• Einfachheit
• Transparenz
• Stille

Die Regeln laufen letztlich auf ein vertrautes Prinzip hinaus: KISS (Keep it simple, stupid!) Indem kleine Programme gefördert werden, die grundlegende, konkrete Aufgaben erfüllen und über ein einfaches Textprotokoll kommunizieren, resultiert die Unix-Philosophie in wiederverwendbaren, zuverlässigen Werkzeugen.

Präzise, modulare Programme lassen alles ticken

Die erste von Raymonds Regeln lautet „Modularität“, die beschrieben wird als: „Schreiben Sie einfache Teile, die durch saubere Schnittstellen verbunden sind.“ Wie viele der anderen Regeln liegt der Fokus hier auf der Kontrolle von Komplexität. Viele Probleme bei der Nutzung von Computern ergeben sich aus komplexen Systemen, die schwer zu verstehen sind. Durch die Förderung von Einfachheit zielt diese Regel darauf ab, Ausfälle zu reduzieren und das allgemeine Verständnis zu verbessern.

Wenn Sie zum ersten Mal auf Linux-Werkzeuge wie ls oder grep stoßen, kann es schwierig sein, sie als vollwertige Programme in ihrem eigenen Recht zu betrachten. Sie leisten weit weniger als Ihr Webbrowser oder Ihr Textverarbeitungsprogramm, sodass sie trivial oder unwichtig erscheinen können. Aber das übersieht die inhärente Kraft der Modularität: die Kombination kleiner Programme, um mehr zu erreichen als die Summe ihrer Teile.

Ein praktisches Beispiel für die Kraft der Modularität ist die Pipe:

ls | grep "foo" 

Hier ist ein Beispiel für ein sehr häufiges Muster, das ich immer wieder aufgreife:

du -sk * | sort -rn | head 

Diese Pipeline führt drei Programme aus: du, um die Gesamtgröße der passenden Dateien/Verzeichnisse zu berichten, sort um sie numerisch zu ordnen, und head, um die ersten zehn Ergebnisse zurückzugeben. Das Ergebnis ist eine kleine Menge von Verzeichnissen, die den meisten Platz auf der Diskette einnehmen, was ich dann überprüfen kann, um sie zu bereinigen.

Ohne Pipes wäre die Alternative ein einziges Programm, das etwas wie „get-biggest-ten-folders“ heißt. Ein solches Programm wäre vielleicht sogar bequemer, doch es ist weit eingeschränkter als die allgemeinen Werkzeuge, die hier zur Verfügung stehen. Man bräuchte eine enorme Anzahl von umständlich benannten Programmen, um ohne Pipes auszukommen, und deren Komplexität wäre zweifellos schrecklich zu handhaben.

Text unterpins alles

Kapitel 5 des Buches dreht sich ganz um Textualität, sowohl in Bezug auf Dateiformate als auch auf die Art und Weise, wie Unix-Programme kommunizieren. Dies war eines der Dinge, die mich am meisten an Unix beeindruckt haben, insbesondere wenn es um Konfiguration geht. Vom Windows kamend, war ich das Registry gewöhnt, diese berüchtigte, opake, monolithische Datenbank, die Programmeinstellungen speichert.

Linux-Werkzeuge hingegen haben in der Regel textbasierte Konfigurationsdateien, die überall in Ihrem Dateisystem verstreut sind (an standardisierten Orten, wenn Sie so wollen). Sie können diese Dateien mit einem herkömmlichen Texteditor bearbeiten und mit allgemein verfügbaren Befehlszeilenwerkzeugen abfragen. Dies bedeutet, dass keine speziellen GUI-Werkzeuge erforderlich sind, um Einstellungen zu ändern, obwohl diese dennoch auf dem traditionellen Textdateiformat aufbauen können.

Diese Philosophie erstreckt sich auch auf die Art und Weise, wie Programme kommunizieren. Wenn Sie eine Pipeline verwenden, übergeben Sie Text von einem Programm zu einem anderen. An jedem Punkt können Sie die Pipeline unterbrechen, um sie zu debuggen. Nehmen Sie diese Pipeline als Beispiel:

ls | grep "txt"

Durch das Einfügen des tee-Befehls können Sie die Ausgabe an einem bestimmten Punkt erfassen und für Debugging-Zwecke in einer Datei speichern:

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

Dies steht im Einklang mit Raymounds Regel der Transparenz:

„Gestalten Sie für Sichtbarkeit, um Inspektion und Debugging zu erleichtern“

Die Verwendung von Text als Kommunikations- und Datenformat bedeutet, dass Programme offen arbeiten, mit weniger versteckten Teilen. Dies erleichtert es, Programme zu reparieren, aus ihnen zu lernen und sie zu nutzen.

Linux ist sturrisch traditionell, zum Besten oder Schlechtesten

Linux – und noch mehr Unix – wird oft als „altmodisch“ betrachtet, ein System, das von „grauen Bärten“ und Eiferern geliebt wird. Obwohl ein gewisser Wahrheitsgehalt darin steckt, übersieht es, dass ausgereifte, entwickelte Technologien nicht zwangsläufig schlecht sind.

In Kapitel 14 diskutiert Raymond die Verwendung von C, das für die Entwicklung von Linux von entscheidender Bedeutung war. Obwohl sich die Situation weiterentwickelt, sind viele der Standard-Befehlszeilenwerkzeuge heute immer noch in C geschrieben. Das Buch bemerkt, wie C sich ausgebreitet hat, teilweise aufgrund der hervorragenden Werkzeugeunterstützung, die die Zeit überdauert hat.

Raymond ist kein Absolutist; er erklärt, wie Python, eine relativ moderne Sprache, eine überlegene Wahl für neue Projekte ist. Aber er untersucht auch die Vor- und Nachteile von Shell-Programmierung und argumentiert, dass objektorientierte Programmierung nicht perfekt ist. Wie viel von dem Buch argumentiert auch dieser Abschnitt gegen Einheitslösungen und betont, wie wichtig der Kontext immer ist.

The Art of Unix Programming ist online kostenlos und als gedruckte Ausgabe erhältlich. Ich bin ein großer Fan von beidem, weil das erste großartig für Referenzen ist, aber das Buch ist so eine gute Lektüre, dass es schön ist, sich zurückzulehnen und von vorne bis hinten zu entdecken.

Bist du neugierig auf weitere Artikel wie Dieses Buch hat mir 6 wichtige Fakten über Linux beigebracht? Entdecke spannende Inhalte in der Kategorie Linux.