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

2 Die Grundlagen aus Anwendersicht

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 <Das »Userland«, auch »Userspace«, ist die Systemumgebung aus Sicht eines Benutzers.> und den Grundlagen aus Anwendersicht beschäftigen.

Wurden 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 im Folgenden so langsam praktisch werden. Dazu setzen wir eigentlich nur voraus, dass Sie ein Linux-System egal welcher Distribution zur Hand haben – falls Sie hier noch etwas nacharbeiten müssen, finden Sie im Anhang ein ausführliches Installationskapitel. Fürs Erste könnten Sie natürlich auch das »Knoppix«-System von der dem Buch beigefügten DVD-ROM booten, ein ohne Installation komplett lauffähiges Linux.

Linux pur!

Im Großen und Ganzen werden wir dabei unserer Philosophie treu bleiben und Linux distributionsunabhängig beschreiben. Wir wollen und werden Ihnen nicht nur erklären, wie man etwas genau macht, sondern Ihnen vor allem das Warum und Wieso sowie die Zusammenhänge insgesamt erläutern. Trotzdem wollen wir darauf achten, uns nicht in Belanglosigkeiten und praxisfernen Konzepten zu verlieren, sondern hier und da auch mal ein konkretes und vor allem interessantes Beispiel zu bringen. Von Ihnen fordern wir eigentlich nur die Bereitschaft, sich auf unseren zugegeben etwas eigenwilligen Stil einzulassen.

2.1 Die Unix-Philosophie

Um die Grundlagen aus Anwendersicht ordentlich verstehen zu können, braucht man zuerst einmal ein grundlegendes Verständnis für die Philosophie hinter diesem Betriebssystem. Außerdem muss man verstehen, dass Unix und Linux eng zusammenhängen – 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 eine Gemeinsamkeit: Für Windows-Anwender wirken sie »anders« und »ungewohnt«, vielleicht sogar »umständlich«. Aber die Entwickler haben sich etwas bei der Konstruktion dieses Systems gedacht, und wir wollen Ihnen diese Gedanken nun näherbringen.

Von Programmierern für Programmierer

Zuerst einmal wurde Unix von Programmierern für Programmierer <Die Zielgruppe »Programmierer« kann jedoch insgesamt als »professionelle Benutzer« verstanden werden. In den Anfangstagen der Informatik und damit in den Anfangstagen von Unix war beides jedoch noch identisch.> 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 natürlich 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 – sollte dies aber 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.

Diese ganzen Ziele unterscheiden sich nun gewaltig von denen eines Einbenutzerbetriebssystems, das auch Anfängern erlauben 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 den Anwender ist.

2.1.1 Kleine, spezialisierte Programme

Das ganze Gegenteil ist bei Programmierern oder anderweitig erfahrenen Anwendern der Fall: Sie erwarten von einem System, dass es die ihm gestellten Aufgaben effizient löst. Das System muss sich nicht um seine Benutzer kümmern, denn die wissen in der Regel selbst, was sie wollen und wie sie es erreichen können. Das System muss dazu flexibel und mächtig sein, was Unix auf die folgende Art und Weise zu erreichen versucht:

Anstatt große und funktionsbeladene Applikationen anzubieten, werden kleine, spezialisierte Programme bereitgestellt.

Jedes Programm sollte idealerweise nur eine Aufgabe erfüllen, aber diese richtig gut. Durch vielfältige Kombinationen dieser »Spezialisten« kann ein Anwender nun flexibel alle ihm gestellten Aufgaben bewältigen.

Wenig Redundanz

Außerdem unterstützen alle Programme eine konsistente und redundanzarme Bedienung: Warum sollte man ein »remove« schreiben, wenn »rm« auch aussagekräftig genug und immer noch eindeutig ist?

Außerdem sollte sich der Befehl analog zu anderen Befehlen verhalten: Wenn ein ls -R * alle Inhalte in einem Verzeichnis rekursiv auflistet, so sollte ein rm -R * alle 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 werden. Bei knapp hundert Anschlägen pro Minute tippt sich so ein rm-Befehl viel schneller als man je

zur Maus greifen,

den Dateimanager durch Doppelklick starten,

die Dateien heraussuchen,

sie mit der Maus markieren,

das Kontextmenü durch einen Rechtsklick öffnen,

den Punkt »Löschen« auswählen

und die ganze Aktion durch das Klicken auf »Ja« in der Dialogbox bestätigen kann.

Auch kann man in der Shell Befehle einfach kombinieren und häufige oder etwas komplexere Befehle in ganze Skripts schreiben. Diese Skripts können auch zentral abgelegt und allen Benutzern eines Systems zur Verfügung gestellt werden.

Alternativ kann man diese Skripts zu bestimmten Zeitpunkten – beispielsweise jeden Tag, jede Woche, jeden ersten Sonntag im Monat um 3 Uhr oder in genau 2 Stunden – ausführen lassen.

2.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.

Sie verhalten sich nämlich so, wie ein erfahrener Benutzer es erwarten würde: Programme 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.

Parameter statt Nachfragen

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 von 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 dann keine Ausgabe erzeugen – aber gerade dann ist ja alles in Ordnung.

Diese Prinzipien sind jedoch vor allem in der Shell anzutreffen. Unter grafischen Oberflächen sind die eben genannten Prinzipien nur schwer zu realisieren und oft auch nicht sinnvoll.

2.1.3 Die Shell

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

Grafik unter Unix/Linux

Natürlich gibt es auch unter Unix und Linux eine komplette und funktionsreiche grafische Oberfläche: Das X-Window-System.

Aber viele professionelle Unix-Anwender nutzen diese Oberfläche auch nur, um viele grafische Terminals und damit viele Shells möglichst auf einen Blick zu haben. Außerdem bietet zum Beispiel das populäre KDE als grafische Oberfläche eine nahezu komplette Bedienung über Tastenkürzel und Shortcuts an. So muss man nicht mal die Hand von der Tastatur nehmen, wenn man zu einem anderen Bildschirm <X11 unterstützt das Konzept der virtuellen Bildschirme, auf denen man jeweils andere Fenster geöffnet und sogar unterschiedliche Hintergrundbilder aktiviert haben kann. Der Benutzer kann nun leicht von einem Bildschirm zu einem anderen wechseln und so die Arbeit mit vielen Fenstern besser meistern.> 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 wäre das Surfen im Web – es gibt zwar Webbrowser für eine Textoberfläche, aber eine wirkliche Alternative zu den grafischen Varianten sind sie nicht.

2.1.4 Die Administration

Ein weiterer wichtiger Bestandteil der Unix-Philosophie ist die Administration des Systems. Von vielen wird genau das 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 Hardware-Support für die allerneueste Grafikkarte und dieses oder jenes nicht unterstützte exotische Feature bei einem neuen PC.

Bastellösungen

Diese Menschen bringen nun etwas durcheinander. Ja, Unix und damit auch Linux lässt sich bis ins letzte Detail konfigurieren und personalisieren. Schließlich handelt es sich bei Unix um ein System für professionelle Anwender und weniger für absolute Computerneulinge. Und professionelle Anwender können und wollen sich – zumindest in einem gewissen Rahmen – mit ihrem System auseinandersetzen. Außerdem zieht das Argument der Bastelei heutzutage 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.

Der Schein trügt

Aber natürlich ist die Welt nicht perfekt. Alle gängigen Fertig-PCs werden mit Windows ausgeliefert, da die meisten Hersteller und Händler besondere Verträge mit Microsoft geschlossen haben. Dass der Kunde dann für Windows bis zu mehreren Hundert Euro bezahlt, auch wenn er diese Software nicht will, sei einmal dahingestellt. Auf jeden Fall erfordert ein neuer PC mit Windows keine Handarbeit – das System ist schließlich schon installiert. Ein neuer PC mit Linux dagegen will erst einmal installiert werden. Ein weiteres Problem von Linux liegt in der mangelhaften Hardware-Unterstützung, die zugegeben an einigen wenigen Stellen immer noch Bastelarbeit erfordert. Aber seien wir mal ehrlich: Wer ist für die Bereitstellung korrekter, funktionsfähiger Treiber zuständig? Freie, unbezahlte Programmierer, die Linux in ihrer Freizeit weiterentwickeln, oder doch die Hardware-Hersteller selbst, die im Übrigen auch die Windows-Treiber samt aller einfacher Installationsroutinen zur Verfügung stellen? Aber jetzt bewegen wir uns leider argumentativ im Kreis: Denn solange sich die mehrheitlich professionellen Linux/Unix-Anwender noch mit halb fertigen Bastellösungen auch seitens der Hardware-Hersteller zufriedengeben, wird sich daran so schnell nichts ändern.

Fakt ist und bleibt jedoch die Eigenschaft von Linux, dass es sich sehr gut administrieren und anpassen lässt. Im Moment versucht man hier einen dualen Ansatz: Der Anwender soll ein System möglichst benutzerfreundlich und einfach installieren und bedienen können, aber trotzdem weiterhin die bekannten mächtigen Möglichkeiten zur Personalisierung haben. Dieses Ziel ist zwar vielleicht noch nicht erreicht, aber man ist bereits auf einem guten Weg.

Trusted Computing

Leider zeichnet sich jedoch schon jetzt ab, dass dieser Weg steinig werden wird. Denn mit Trusted Computing werden bald neue Features kommen, die die traditionelle PC-Architektur verändern und dem Endbenutzer deutlich weniger Möglichkeiten geben werden. Schließlich bedeuten die in diesem Zug genannten Schlagwörter von »Sicherheit« und »Vertrauen« nicht, dass die Benutzer sicherer sein werden und ihrem PC hinsichtlich Viren, Würmern und diverser Kontodaten ausspähender Spyware besser vertrauen können. Nein, die Industrie möchte Sicherheit vor ihren eigenen Kunden, denen sie besser vertrauen können will. Diese vielleicht sogar gut gemeinte Fürsorge beißt sich natürlich mit dem Alleskönner-Prinzip des PCs, und man wird abwarten müssen, wie das freie und offene Linux auf diese neuen Entwicklungen reagieren kann. Ein mächtiges System mit nahezu unbegrenzten Möglichkeiten für den professionellen Anwender ist jedenfalls ein deutlicher Gegensatz zu den Trusted-Computing-Plänen einiger Marktführer.

2.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).

Lokaler oder netz- werkbasierter Dienst?

Bei diesem Prinzip der Systemarchitektur nutzt ein Client – meist ein direkt vom Benutzer gesteuertes Programm – die Dienste eines Servers. Ob dieser Server nun 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:

X11 – die grafische Oberfläche

Die grafische Oberfläche von Unix ist auch netzwerktransparent. Man unterscheidet hier zwischen dem X-Server, der die Darstellung auf dem Client-PC des Benutzers vornimmt, und den vom Benutzer gestarteten X-Clients, also Programmen, die eine grafische Oberfläche benötigen. Auf welchem Rechner beziehungsweise Server diese Clients nun ausgeführt werden, ist von der Darstellung durch den X-Server unabhängig – das X-Protokoll trennt die Ausführung und die Darstellung von grafischen Anwendungen.

Ein sehr wichtiges, aber leider sehr oft vernachlässiges Prinzip bei der Entwicklung sauberer Systeme ist die Orthogonalität: Halte alle Dinge auseinander, die nicht in einem unmittelbaren Zusammenhang stehen.

In unserem Beispiel sind die beiden Aspekte Ausführung und Darstellung eines grafischen Programms sauber durch die Trennung von X-Cient und X-Server modelliert.

Der Logging-Dienst<
Der syslogd
Unter Unix wird sehr viel protokolliert, wobei das »Management« der Protokoll- beziehungsweise Logdateien von einem bestimmten Dienst, dem syslogd, übernommen wird. Die Anwendungen können nun über bestimmte Aufrufe mit diesem Dienst kommunizieren, der dann die Meldungen in die Dateien schreibt. Mit wenigen Änderungen an der Systemkonfiguration ist es nun möglich, die Anwendungen nicht mehr von dem lokal laufenden syslogd, sondern von einem auf einem fremden Rechner installierten syslogd nutzen zu lassen.
Die Eigenschaft, mit steigenden Anforderungen mitwachsen zu können, nennt man Skalierbarkeit.

Dateien im Netzwerk

virtuelle Dateisystem

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

Ein Hintergrundprozess ist ein Prozess, der ohne Interaktion mit dem Benutzer seine Arbeit im Hintergrund verrichtet. Im Besonderen braucht so ein Prozess also keinen Zugang zu Tastatur oder direkt zum Bildschirm.

Spooling und das Netzwerk

Ein weiteres Prinzip, das zur Netzwerktransparenz führen kann, ist das Spooling <Eigentlich wurde Spooling zum Vermeiden von Ressourcenkonflikten konzipiert. Jedoch kann man diesen »klassischen« Fakt auch aus anderen Blickwinkeln sehen.>. Beim Spooling verwaltet ein Dienst eine Ressource und stellt diese anderen Programmen über eine bestimmte Schnittstelle zur Verfügung. Ein typisches Beispiel für Spooling ist die Verwaltung des Druckers: Ein Dienst hat exklusiven Zugriff auf das Gerät, und alle druckenden Programme greifen nicht direkt auf den Drucker zu, sondern legen die zu druckenden Dateien einfach in eine Warteschlange. Das hat den Vorteil, dass zwei gleichzeitig druckende Programme auf dem Papier keinen Mix ihrer Ausdrucke erzeugen, sondern alles nacheinander bearbeitet wird. Auch die Verwaltung der Logdateien als bestimmte Systemressourcen durch den syslogd ist eine gewisse Art des Spoolings. Schließlich können wir nun den Kreis zur Netzwerktransparenz schließen und bemerken, dass ein solcher Dienst im Prinzip natürlich auf jedem System im Netzwerk ausgeführt werden kann. <Und tatsächlich gibt es zum Beispiel mit CUPS einen sehr populären netzwerkbasierten Druckdienst.>

So viel also erst einmal zur Unix-Philosophie, der sich Linux wie auch BSD als Unix-Derivate selbstverständlich anschließen.

Vielleicht haben Ihnen die hier genannten Themen nun 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 und BSD.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.