3    Erste Schritte

»Was für eine Philosophie man wähle,
hängt davon ab,
was für ein Mensch man ist.«
– Johann Gottlieb Fichte

In diesem Kapitel erläutern wir die Grundlagen aus Anwendersicht, vom ersten Kontakt mit dem System bis hin zum Bewegen in der Shell. Viele der Themen werden im Laufe des Buches noch ausführlich behandelt, der folgende kurze Einstieg schafft jedoch eine gute Basis für spätere Kapitel.

Im letzten Kapitel haben wir uns ausführlich mit dem Kernel und den Aufgaben eines Betriebssystems wie Linux auseinandergesetzt. In diesem Kapitel wollen wir uns nun mit dem Userland und den Grundlagen aus Anwendersicht beschäftigen. Als Userland, auch Userspace, bezeichnet man die Systemumgebung aus Sicht eines Benutzers bzw. einer Benutzerin.

Haben wir im ersten Kapitel also vorrangig interessante Hintergründe vermittelt und ein grundlegendes Verständnis für das Betriebssystem als Ganzes geschaffen, so möchten wir uns im Folgenden so langsam der Praxis zuwenden. Dazu setzen wir eigentlich nur voraus, dass Sie ein Linux-System, egal welcher Distribution, zur Hand haben. Für das Erste können Sie sich beispielsweise eine Livedistribution herunterladen und sie von einem bootfähigen Medium oder auch in einer virtuellen Maschine starten.

3.1    Die Unix-Philosophie

Um die Grundlagen aus Anwendersicht zu verstehen, hilft in jedem Fall ein Verständnis für die »Philosophie« hinter diesem Betriebssystem. Außerdem muss man verstehen, dass Unix und Linux eng verwandt sind – wer einen Linux-Rechner administrieren kann, braucht nur eine sehr kurze Einarbeitungszeit, um andere Unix-Systeme wie Solaris oder BSD zu verstehen. Alle diese Systeme haben auch eine weitere Gemeinsamkeit: Für Windows-Anwenderinnen und -Anwender wirken sie zunächst »anders« und »ungewohnt«, vielleicht sogar »umständlich«. Aber die Entwicklerinnen und Entwickler haben sich etwas bei der Erstellung dieses gemeinsamen Unix-Konzepts gedacht, und wir wollen Ihnen diese Gedanken nun näherbringen.

Zuerst einmal wurde Unix von Programmierern für Programmierer[ 16 ] entwickelt. Auf einem System können mehrere Benutzer mehrere Programme gleichzeitig nutzen, zum Beispiel um Software zu entwickeln oder anderweitig zu arbeiten. Die Benutzer sowie die einzelnen Programme können Daten gemeinsam nutzen sowie diese auf eine kontrollierte Art und Weise austauschen. Das Design von Unix setzt dabei einigermaßen intelligente Benutzer voraus, die in der Regel wissen, was sie tun – und sollte dies mal nicht der Fall sein oder sind böswillige Angreifer am Werk, ist das System durch die Implementierung von unterschiedlichen Benutzerkonten mit einem konsistenten Rechtesystem gut vor Manipulationen geschützt.

All diese Ziele unterscheiden sich nun gewaltig von denen eines Einbenutzerbetriebssystems, das auch Anfängern ermöglichen will, eine Textverarbeitung zu benutzen. Dort möchte man die Benutzer führen und ein Stück weit auch bevormunden, da das System meistens besser weiß, was gut für sie ist, als sie selbst.

3.1.1    Kleine, spezialisierte Programme

Programmiererinnen, Admins oder erfahrene Anwender erwarten von einem System, dass es die ihm gestellten Aufgaben effizient löst. Das System muss sich nicht um seine Benutzer kümmern, denn diese wissen in der Regel selbst, was sie wollen und wie sie es erreichen. Das System muss dazu flexibel und mächtig sein, was Unix auf dem folgenden Weg zu erreichen versucht:

Anstatt große und funktionsbeladene Applikationen anzubieten, werden kleine, spezialisierte Programme bereitgestellt. Jedes Programm sollte idealerweise nur eine Aufgabe erfüllen, diese aber optimal. Durch vielfältige Kombinationen dieser »Spezialisten« können Anwenderinnen und Anwender flexibel die ihnen gestellten Aufgaben bewältigen.

Außerdem unterstützen alle Programme eine konsistente und redundanzarme Bedienung: Warum sollte man remove schreiben, wenn rm aussagekräftig genug und immer noch eindeutig ist? Außerdem sollte sich der Befehl analog zu anderen Befehlen verhalten: Wenn ls -R * alle Inhalte in einem Verzeichnis rekursiv auflistet, sollte rm -R * genau diese Dateien rekursiv löschen – und nicht etwa eine Datei namens * und eine Datei, deren Name aus einem Minus, gefolgt von einem großen »R« besteht.

Überhaupt wird die textuelle Eingabe über die Shell der Bedienung des Systems über eine grafische Oberfläche in vielen Fällen vorgezogen. Bei knapp hundert Anschlägen pro Minute tippt sich so ein rm-Befehl viel schneller als man je

Auch kann man in der Shell Befehle einfach kombinieren und häufig benutzte oder etwas komplexere Befehlsketten in ganze Skripte schreiben. Diese Skripte können auch zentral abgelegt und allen Benutzerinnen und Benutzern eines Systems zur Verfügung gestellt werden. Alternativ kann man diese Skripte zu bestimmten Zeitpunkten – beispielsweise jeden Tag, jede Woche, jeden ersten Sonntag im Monat um 3 Uhr oder in genau zwei Stunden – ausführen lassen.

3.1.2    Wenn du nichts zu sagen hast: Halt die Klappe

Ein weiterer wichtiger Punkt der Unix-Philosophie ist das Verhalten sowie indirekt auch die Bedienung der Programme. Programme unter Unix/Linux verhalten sich nämlich so, wie erfahrene Benutzerinnen und Benutzer es erwarten würden: Sie geben im Erfolgsfall keine Meldung aus, sondern nur im Fehlerfall oder wenn es anderweitig Ergebnisse zu präsentieren gibt. Ein »alles okay« am Ende ist schlicht unnötig und redundant, da es immerhin den Regelfall darstellen sollte.

Außerdem werden Programme zu einem großen Teil nur über Parameter mit Eingaben gefüttert: Man startet zum Beispiel einen Texteditor mit der zu bearbeitenden Datei als Argument, anstatt vom Editor nach dem Start nach der Datei gefragt zu werden. Für Neulinge ist dies zum Teil recht frustrierend, da man oft Befehle tippt, die keine Ausgabe erzeugen – aber gerade dann ist ja alles in Ordnung.

Diese Prinzipien sind jedoch vor allem in der Shell anzutreffen, also wenn Sie direkt auf der Kommandozeile arbeiten. Unter grafischen Oberflächen sind die eben genannten Prinzipien nur schwer zu realisieren und oft auch nicht sinnvoll.

3.1.3    Die Shell

Ja, die Shell – sehr viel wird von Neulingen oder Quereinsteigern über diese »anachronistische« Eingabeaufforderung geschimpft. Erfahrene Unix-Anwenderinnen und -Anwender möchten ihre Shell jedoch nicht missen und empfinden in der Regel umgekehrt ein System, das sie zur Mausbenutzung zwingt, als Zumutung.

Natürlich gibt es auch unter Unix und Linux eine komplette und funktionsreiche grafische Oberfläche. Viele professionelle Unix-Anwenderinnen und -Anwender nutzen diese Oberfläche nur, um viele grafische Terminals und damit viele Shells gleichzeitig im Blick zu haben. Außerdem bietet zum Beispiel die populäre Desktop-Umgebung Gnome als grafische Oberfläche eine nahezu komplette Bedienung über Tastenkürzel und Shortcuts an. So muss man nicht einmal die Hand von der Tastatur nehmen, wenn man zu einem anderen (virtuellen) Bildschirm oder einer anderen grafischen Shell wechseln will.

Aber natürlich gibt es auch Anwendungen, die sich in der Shell nur schlecht realisieren lassen. Ein populäres Beispiel dafür ist das Surfen im Web – es gibt zwar Webbrowser für mit einer Textoberfläche, aber eine wirkliche Alternative zu den grafischen Varianten sind sie nicht.

3.1.4    Administration

Ein weiterer wichtiger Bestandteil der Unix-Philosophie ist die Administration des Systems. Von vielen wird genau dies als Nachteil gesehen: Man beklagt sich, dass man bei Linux »basteln« muss, um zu einer vernünftigen Lösung zu kommen. Man beklagt den fehlenden Hardwaresupport für die allerneueste Grafikkarte und dieses oder jenes nicht unterstützte exotische Feature bei einem neuen PC.

Diese Klagen beruhen auf einem Missverständnis. Ja, Unix (und damit auch Linux) lässt sich bis ins letzte Detail konfigurieren und personalisieren. Schließlich handelt es sich dabei um ein System für professionelle Anwenderinnen und Anwender und weniger für absolute Computerneulinge. Und Profis können und wollen sich – zumindest in einem gewissen Rahmen – mit ihrem System auseinandersetzen. Außerdem zieht das Argument der Bastelei inzwischen nicht mehr wirklich, da heute eine frische Installation einer gängigen Linux-Distribution weitaus weniger Nacharbeit per Hand erfordert als ein frisches Windows – schließlich ist alle wichtige Software schon installiert und sinnvoll konfiguriert.

3.1.5    Netzwerktransparenz

Ein weiterer wichtiger Ansatz der Unix-Philosophie ist die Netzwerktransparenz. Bei einem durchdachten und konsistenten Mehrbenutzer- und Mehrprogrammkonzept hat man natürlich auch mit mehreren Rechnern keine Probleme. Die Netzwerktransparenz spiegelt sich schon in einem in Unix allgegenwärtigen Modell wider: dem Modell von Dienstnehmer (engl. client) und Dienstgeber (engl. server).

Bei diesem Prinzip der Systemarchitektur nutzt ein Client – meist ein direkt vom Benutzer bzw. von der Benutzerin gesteuertes Programm – die Dienste eines Servers. Ob dieser Server ein entfernter Rechner mit spezieller Software oder ein lokal im Hintergrund ablaufendes Programm ist, kann transparent geändert werden. Einige interessante Beispiele für die Netzwerktransparenz von Unix/Linux wollen wir im Folgenden aufzählen:

Diese Liste könnte man fast endlos fortsetzen. Um das Dienstgeber-Konzept zu unterstützen, bietet Unix spezielle Prozesse an: die Hintergrundprozesse.

Ein Hintergrundprozess (engl. Daemon) ist ein Prozess, der ohne Interaktion mit den Benutzerinnen und Benutzern seine Arbeit im Hintergrund verrichtet. Somit benötigt ein solcher Prozess keinen Zugang zur Tastatur oder direkt zum Bildschirm.

So viel also erst einmal zur Unix-Philosophie, der sich Linux selbstverständlich anschließt. Vielleicht haben Ihnen diese Themen schon etwas Lust auf mehr gemacht; auf jeden Fall werden wir später im Buch alles näher erläutern. Im Folgenden kommen wir nun endlich zum eigentlichen Thema des Kapitels: zu einer kurzen Einführung in Linux.