»Was für eine Philosophie man wähle,
hängt davon ab,
was für ein Mensch man ist.«
– Johann Gottlieb Fichte
6 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 [Fn. Als Userland, auch Userspace, bezeichnet man 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 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. Vielleicht haben Sie sich im vorhergehenden Teil des Buches bereits ein System installiert, ansonsten können Sie fürs Erste natürlich auch die Live-Version von openSUSE oder Fedora von der dem Buch beigefügten DVD-ROM booten. Beide Systeme sind ohne Installation direkt von der DVD benutzbar und bieten Ihnen die grafischen Oberflächen KDE (openSUSE) und GNOME (Fedora).
Linux pur!
Im Großen und Ganzen werden wir dabei unserer Philosophie treu bleiben und Linux distributionsunabhängig beschreiben. Wir 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 einmal ein konkretes und vor allem interessantes Beispiel zu bringen. Von Ihnen verlangen wir eigentlich nur die Bereitschaft, sich auf unseren zugegeben etwas eigenwilligen Stil einzulassen.
6.1 Die Unix-Philosophie
Um die Grundlagen aus Anwendersicht ordentlich verstehen zu können, braucht man zuerst einmal ein 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 zunächst »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 [Fn. 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 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 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.
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 den Anwender ist, als dieser selber.
6.1.1 Kleine, spezialisierte Programme
Das genaue 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 diese 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 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« kann ein Anwender nun flexibel die ihm gestellten Aufgaben bewältigen.
Wenig Redundanz
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 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. 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 zwei Stunden – ausführen lassen.
6.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 ein erfahrener Benutzer es erwarten würde: 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.
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 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.
6.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 umgekehrt ein System, das sie zur Mausbenutzung zwingt, als 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. Viele professionelle Unix-Anwender nutzen diese Oberfläche nur, um viele grafische Terminals und damit viele Shells gleichzeitig im 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 einmal die Hand von der Tastatur nehmen, wenn man zu einem anderen Bildschirm [Fn. 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 zum 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 ist das Surfen im Web – es gibt zwar Webbrowser für eine Textoberfläche, aber eine wirkliche Alternative zu den grafischen Varianten sind sie nicht.
6.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 Hardware-Support für die allerneueste Grafikkarte und dieses oder jenes nicht unterstützte exotische Feature bei einem neuen PC.
Bastellösungen
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 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.
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 mehrere hundert Euro bezahlt, auch wenn er diese Software nicht wünscht, sei einmal dahingestellt. Auf jeden Fall erfordert ein neuer PC mit Windows nicht allzu viel Handarbeit – das System ist schließlich schon installiert.
Ein neuer PC mit Linux dagegen muss (bis auf wenige Ausnahmen) erst einmal installiert werden. Ein weiteres Problem von Linux liegt in der mangelhaften Hardwareunterstützung, die zugegeben an einigen wenigen Stellen immer noch Bastelarbeit erfordert. Aber seien wir ehrlich: Wer ist für die Bereitstellung korrekter, funktionsfähiger Treiber zuständig? Freie, unbezahlte Programmierer, die Linux in ihrer Freizeit weiterentwickeln, oder nicht doch die Hardwarehersteller selbst, die im Übrigen auch die Windows-Treiber samt aller einfachen Installationsroutinen zur Verfügung stellen? An diesem Punkt bewegen wir uns leider argumentativ im Kreis: Denn solange sich die mehrheitlich professionellen Linux/Unix-Anwender noch mit halbfertigen Bastellösungen auch seitens der Hardwarehersteller zufriedengeben, wird sich an dieser Situation 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 gewohnten mächtigen Möglichkeiten zur Personalisierung haben. Dieses Ziel ist zwar vielleicht noch nicht in vollem Umfang erreicht, aber man ist bereits auf einem guten Weg.
6.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 netzwerkbasierter 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ässigtes 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 der Ausführung und Darstellung eines grafischen Programms sauber durch die Trennung von X-Client und X-Server modelliert.
Der syslogd
- Der Logging-Dienst
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 möglich, die Anwendungen nicht mehr den lokal laufenden syslogd nutzen zu lassen, sondern einen auf einem fremden Rechner installierten syslogd.
[»]Die Eigenschaft, mit steigenden Anforderungen mitwachsen zu können, nennt man Skalierbarkeit.
Dateien im Netzwerk
- NFS
Über das virtuelle Dateisystem (VFS) kann man unter Unix, unabhängig vom darunterliegenden Dateisystem, auf Dateien und Verzeichnisse immer auf die gleiche Art und Weise zugreifen. Der Benutzer merkt nicht, ob er gerade auf einer CD-ROM oder einer lokalen Festplatte arbeitet. Dieses Konzept lässt sich auch auf das Netzwerk ausdehnen, bei dem zum Beispiel der für Unix typische NFS-Dienst ganze Verzeichnisbäume von einem Rechner exportieren und anderen Systemen im Netzwerk zur Verfügung stellen kann. Die exportierten Verzeichnisse können von anderen Rechnern schließlich regulär gemountet und wie lokale Medien benutzt werden – für den Benutzer macht es keinen Unterschied, dass die Dateien nicht lokal, sondern auf einem anderen Rechner gespeichert sind.
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. Somit benötigt ein solcher Prozess keinen Zugang zur Tastatur oder direkt zum Bildschirm.
Spooling und das Netzwerk
Ein weiteres Prinzip, das zur Netzwerktransparenz führen kann, ist das Spooling. [Fn. Ursprünglich wurde Spooling zum Vermeiden von Ressourcenkonflikten konzipiert.] 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 druckende 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 keine Mischung ihrer Ausdrucke auf dem Papier erzeugen, sondern Druckaufträge nacheinander bearbeitet werden. Auch die Verwaltung der Logdateien als bestimmte Systemressourcen durch den syslogd ist eine Art von Spooling. Schließlich können wir nun den Kreis zur Netzwerktransparenz schließen und anmerken, dass ein solcher Dienst im Prinzip auf jedem System im Netzwerk ausgeführt werden kann. [Fn. 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 ebenso wie BSD als Unix-Derivate selbstverständlich anschließen. 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 und BSD.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
