Das Schreiben: Die Logik hinter “Unix/Linux Survival Guide”
Wer einen Roman oder eine Kurzgeschichte schreibt, hat normalerweise recht genaue Vorstellungen über den Ablauf der Handlung. Wer ein Sachbuch schreibt, versucht sich in die Leser(innen) soweit hineinzuversetzen, dass die Abfolge der Themen beim Lesen Sinn macht. In diesem Beitrag erkläre ich die Idee hinter meinem “Erstlingswerk”: “Unix/Linux Survival Guide. Profirezepte und erste Hilfe für Systemadministratoren (Open Source Library)
(Dies ist ein Beitrag, bei dem ich wirklich nicht hundertprozentig sicher bin, ob er auf die TechNovelty.de oder hierher gehört. Da das Thema aber die Art und Weise ist, wie ich das Buch strukturiert habe, passt es vermutlich eher hierher.)
[Sorry, aber der Beitrag ist für die Startseite etwas zu lang, daher folgt jetzt ein Break. Ich entschuldige mich bei allen Lesern(innen) des RSS-Feeds.]
Der Anfang
Dem Buch liegen Erfahrungen zugrunde, die ich bei meiner Tätigkeit als SysAdmin1 bei einer grossen amerikanischen Firma gemacht habe. Jetzt muss ich kurz mal sehr technisch werden: 5 bis 7 Hardware-Lieferanten, vorsichtig geschätzte 15 bis 20 unterschiedliche Releasestände / Derivate von *NIX2-Betriebssystemen, Rechner über einen grösseren Teil der Welt verstreut. Zuviel Techno-Babbel? Es war – vorsichtig ausgedrückt – unübersichtlich. Meine einzige Chance das Chaos zu beherrschen, war die Rückbesinnung auf die Gemeinsamkeiten der Systeme; die Basis für das Buch. Es ging also darum, Techniken zu benutzen, die auf allen Systemen mehr oder weniger identisch vorhanden waren. Vieles aus dem Buch funktioniert schon seit mehr als 20 Jahren auf jedem *NIX-artigen System. Ausserdem habe ich darauf Wert gelegt, dass die beschriebenen Lösungen keine zu geringe “Halbwertszeit” haben, sie sind also nach wie vor anwendbar und werden es auch noch lange Zeit sein. So bildete sich die Struktur eigentlich von selbst aus. Apropos ausbilden, ein Teil des benutzten Materials waren Spickzettel, die ich für “Neulinge” verfasst hatte. Die Zielgruppe waren also alle, die sich schon ein wenig mit *NIX auskennen und Systeme administrieren wollen / sollen.
Ich hatte schon einiges an Material gesammelt und damit begonnen das Buch auf englisch zu schreiben3. Nachdem das Projekt vom Verlag abgesegnet war, wurde es ernst. In der englischen (Probe-)Fassung hatte ich bereits eine Struktur vorbereitet, die mir der Verlag auch so genehmigt hatte. Mit dieser Struktur war ich von der üblichen Art und Weise ein Buch über Unix zu schreiben bereits abgewichen. Kein Anfangskapitel “…und am Anfang schuf Konrad Zuse den Eniac…” welches sich durch die – mittlerweile recht lange – Geschichte von *NIX hangelt.
Die Struktur
Es gibt im angelsächsischen Sprachraum eine schöne Redensart, “to hit the ground running”, etwa “direkt loslegen können”. Nach dieser Redensart habe ich das erste Kapitel geschrieben. Keine *NIX-Geschichtsstunde, sondern Hinweise wie man den aktuellen Zustand eines Systems überprüfen kann, welches man nicht selbst aufgesetzt hat. Der logische nächste Schritt ist die Arbeit mit *NIX, es geht also um ausführbare Programme und Scripts, letztere sind integraler Bestandteil eines jeden *NIX-Systems, egal ob mit schöner Oberfläche oder über die Kommandozeile. Die nächsten Rubriken waren die Wartung von Systemen und deren Sicherung. Also beschreibt das Buch bis jetzt nur Dinge, die man im täglichen Umgang wissen sollte. Erst danach folgt ein Kapitel über die Neuinstallation eines Systems, gefolgt von einem Kapitel über den Sinn von Test-Systemen. In letzterem finden sich auch Tips und Hinweise, wie man sich die Erstellung von Dokumentation über die Systeme, für die man verantwortlich ist, erleichtert. Das letzte Kapitel setzt sich mit den verschiedensten Aspekten von Computersicherheit auseinander4.
Der Aufbau
Beim didaktischen Aufbau war es mir wichtig, dass immer vollständige Sourcen zu den besprochenen Scripts vorhanden waren. Ausserdem konnte ich (danke Boris) vermeiden, zu “trocken” zu schreiben; mein Ziel war es, ein Buch zu schreiben, das eine nützliche Rolle neben der Tastatur spielt und welches man mit Spass lesen kann. Daher finden sich auch einige kurze Geschichten aus der Praxis im Buch, die den jeweiligen Sachverhalt verdeutlichen sollen. Im Computerbuch-Fachjargon “War Stories”, klingt allerdings martialischer als es ist.
Schreibtechnik
In diesem Buch habe ich eigentlich alle Schreibtechniken vereint, die auch auf Erik, Wortjongleur beschrieben sind. Ein grösserer Teil des Backup-Kapitels entstand beispielsweise in einem Münchner Cafe auf einem Schreibblock. Dabei wurde mir klar, dass es manchmal sinnvoll ist, eben nicht an einem Computer – über Computer – zu schreiben. Die Versuchung etwas “nur schnell” auszuprobieren ist einfach zu gross und unterbricht den Schreibfluss. Damals fand auch einer meiner Versuche mit Karteikarten statt – allerdings mit gemischten Ergebnissen – daher habe ich diese Technik auch wieder aufgegeben.
Letztendlich geschrieben habe ich das Buch mit GNU Emacs, direkt in XML (die DTD habe ich vom Verlag bekommen). Dieses Vorgehen kam mir aus zwei Gründen sehr entgegen, erstens hatte ich die Probekapitel auf die gleiche Weise geschrieben, allerdings in Docbook. Dies hatte den Vorteil, dass ich jederzeit aus den XML-Dateien ein PDF erzeugen konnte, das wie ein echtes Buch aussah; einschliesslich Inhaltsverzeichnis und Index. Zweitens hilft mir der Zwang in XML sauber strukturieren zu müssen, die Kapitel zu strukturieren, also ein Doppelnutzen. Die DTD vom Verlag war Docbook so ähnlich, dass diesmal ich “den Boden laufend erreichte”. (Diese Brutalübersetzung sollte allerdings nicht dem Weg von “am Ende des Tages gehen”, ich möchte sie nirgends geschrieben sehen oder hören müssen, ernsthaft!) Ein weiterer Vorteil ist die Möglichkeit sich so genannte Entities zu definieren – in diesem Fall Platzhalter – die an einer zentralen Stelle gepflegt werden können, und erst beim Umsetzen ins PDF-Format oder in die Druckvorlage mit dem hinterlegten Wert ersetzt werden. Einfaches Beispiel, ich hatte eine Entity &suse; die beim Umwandeln die Zeichenkette “SuSE Linux” ergab. Erstens spart man sich ein paar Buchstaben, und zweitens kann man die Bezeichnung einmal ändern und ändert damit alle Vorkommen im gesamten Text.
Fazit
So ist also mein erstes Buch entstanden. Ich “predige” die Schreibtechniken nicht nur, ich benutze sie auch wirklich. In einigen Situationen war es äusserst hilfreich einfach einen Block zu nehmen, und soweit wie möglich von allem wegzukommen, was eine Tastatur und einen Bildschirm hat. Beim späteren Übertragen in den Computer habe ich mir dann auch die Zeit genommen, das Geschriebene zu überprüfen; einmal auf den Ausdruck und einmal auf die Funktionalität.
- System Administrator [↩]
- *NIX? Ich benutze diesen Ausdruck durchgängig für alle Betriebssysteme die Unix-artig sind, und gehe nur auf Unterschiede zwischen den Systemen mit den eigentlichen Bezeichnungen ein. Die Ratio dahinter: Wenn ich permanent “Unix/Linux/BSD” schreibe, bekommen die Leser(innen) aufgrund des holprigen Satzbaus Kopfschmerzen, und ich eine Sehnenscheidenentzündung; beides keine erstrebenswerten Ziele. [↩]
- Lange Geschichte, Material für einen weiteren Post. [↩]
- OK, es gibt danach noch ein Kapitel, aber dabei handelt es sich um das Schlusswort. [↩]
Rubrik(en): Schreiben |
-- Werbung --
March 17th, 2008 at 1:01 am
[...] Einstellung schon voellig richtig ist, auch wenn Deine Ausdrucksweise und Deine Rechtschreibung dem Herrn ein Greuel sind, hast Du doch nicht das wahre Ausmass der Gefahr erkannt. Linux ist nicht [...]