[linux-l] Der Wert von Handbüchern (was: Bash und History)

[Volker Grabsch]

Frank Lehmann <eggsperde at gmx.net> schrieb:
> Ich habe irgendwie das Gefühl, dass
> es einen Man-Page-Gott gibt, den alle Linux-Jünger anbeten müssen.

Da ist was dran, doch das hat auch einen sehr guten Grund. Handbücher
werden viel zu wenig genutzt, das gilt generell, nicht nur für Manpages.
Und weil sich an dieser Tatsache bis heute nichts geändert hat, hat
sich auch die "Tradition" nicht geändert, Neulinge auf die Existenz
und den Wert von Handbüchern hinzuweisen.

Wenn es die erfahrenen Leute und die Howtos nicht tun, wer dann?
Oder sollten Anfänger von Handbuch-Hinweisen "verschont" werden,
weil sie eh nichts damit anfangen werden? Das wär ja auch albern.

Gerade _weil_ Handbücher stark unterschätzt werden, kann man IMHO
gar nicht oft genug auf ihren Wert hinweisen.

> Nun, die
> meisten man-pages für grafische Benutzeroberflächen sind prinzipbedingt
> von schlechter Qualität.

Das glaube ich nicht, aber dazu muss ich weiter ausholen. Einig sind
wir uns sicher darin, dass niemand ein Handbuch braucht, in dem sowas
hier drin steht:

    In das Eingabefeld mit der Beschriftung "Datum" tragen Sie das
    Datum ein.

Das ist ähnlich absurd wie die berühmen "increment x"-Kommentare im
Programmcode:

    x++;  /* increment x */

Im Handbuch sollte eher sowas stehen:

    Das Datum muss im internationalen Format (YYYY-MM-DD) eingegeben
    werden, z.B. 2008-11-18.

Aber in einer GUI könnte man diesen Satz auch direkt rot anzeigen,
wenn der User ein ungültiges Datum eingegeben hat. Oder, in diesem
Fall noch besser, ein Datumsauswahlfeld anstelle einer Eingabezeile
nutzen.

Doch nicht alle Dinge kann man allein durch GUI-Gestaltung
offensichtlich machen, und für solche Fälle kann die GUI einen
Hilfe-Button anbieten, der direkt zum Handbuch in das richtige
Unterkapitel führt.

Etliche GUIs machen das auch, aber was findet der User dann in der
Online-Hilfe vor? Richtig, sowas hier:

    In das Eingabefeld mit der Beschriftung "Datum" tragen Sie das
    Datum ein.

Und damit wären wir wieder am Anfang. Handbücher von graphischen
Benutzeroberflächen sind eng mit der GUI verflochten. Dadurch wird
das eigentliche Handbuch kleiner, was aber ein Fortschritt ist!

Doch viele erkennen das nicht, und fühlen sich verpflichtet,
das Handbuch mit sinnlosem Text zu füllen, weil's sonst so klein
aussieht. Das ist ähnlich wie bei einem Deutsch-Aufsatz, wenn
der Lehrer eine Mindest-Wortanzahl vorgibt, aber das Thema nicht
viel her gibt. Die Schüler retten sich durch Einfügen trivialer
Sätze und duch Benutzung möglichst vieler Füllwörter. Das schadet
den Texten natürlich.

Besonders schlimm ist es, wenn der Lehrer solche Patzer nicht nur
nicht ankreidet, sondern sogar als guten Stil lobt. Sowas habe ich
in der Schule zum Glück nie erleben müssen, überhaupt wurde ich fast
nie mit unfähigen Lehrern konfrontiert, und darüber bin ich auch
recht froh. Andere haben weniger Glück.

Das Manko von GUI-Handbüchern ist daher IMHO keineswegs prinzipbedingt,
sondern die Spätauswirkung eines Schwachpunktes im Bildungssystem. Ein
Manko, von dem ich übrigens vermute, dass es sich _nicht_ auf Deutschland
beschränkt.

Im _Prinzip_ haben GUI-Handbücher sogar das Zeug dazu, wesentlich
kompakter und nützlicher als konventionelle Handbücher zu sein, wenn
sie intelligent mit der GUI kombiniert werden, und aufhören, dem
User jede Form von Intelligenz abzusprechen.

> Der Maßstab sollte doch sein, inwieweit man
> dem User das Leben leichter macht, oder? Computer für Menschen und nicht
> umgekehrt!

Dem stimme ich uneingeschränkt zu.

Wobei man, die entsprechende Erfahrung vorausgesetzt, auch ruhig
den User dahin bringen sollte, sich _langfristig_ das Leben leichter
zu machen, auch wenn es ihn kurzfristig ein wenig mehr Arbeit kostet.

Dazu gehören nicht nur Hinweise auf passende, kurze Kapitel im
Handbuch, sondern z.B. auch der Rat, regelmäßige Backups anzufertigen,
sowie der Tipp, auf ein freies System umzusteigen.

Ob der User darauf eingeht, ist natürlich seine Sache. Wenn er
es ablehnt, bedeutet das aber nicht automatisch, dass der Hinweis
unangebracht war.

> Mit folgendem Vergleich lege ich gleich noch eine Tretmine: Alle
> Linux-Distributionen die ich kenne haben hunderte man-pages. Ubuntu auch
> - was die Leute aber an dieser Distrie gut finden ist, dass es ein
> freundliches Forum gibt in dem ihre Fragen beantwortet werden UND, dass
> es soviele Howtos gibt (sagen jedenfalls diverse Polls).

Wenn die Howtos eine entsprechende Qualität haben, ist das ja auch
in Ordnung. (Konkret bei Ubuntu kann ich das leider nicht einschätzen,
da ich mit deren Howtos noch nicht gearbeitet habe)

Dennoch zeichnet sich eine gute Howto auch dadurch aus, dass sie
an entsprechenden Stellen auf das Handbuch verweist, für diejenigen,
die an der Stelle ein Problem haben. Und damit Außenstehende leichter
die Howtos überprüfen können. Die Howto sollte also das Handbuch
gewissermaßen als Quellenangabe zum Belegen ihrer "Behauptungen"
verwenden, um groben Patzern vorzubeugen.

> > Nimm mal ein spezielleres Thema wie z.B. Mailserver- und Spamscanner-
> > Konfiguration, da sieht die Welt ganz anders aus. Wenn man da nicht
> > ständig das Exim- oder Postfix-Manual neben die Howtos legt,
> > konfiguriert man sich ganz schnell ein paar Tretmienen in seine
> > Server.
>
> Allerdings kann ich das
> bestätigen, dass es gerade in diesem Bereich noch Howtos niedriger
> Qualität auf die vorderen Plätze bei Google schaffen.
> [...]
> Bei MTAs und Spamfiltern muss der Admin aber schon fast die ganze
> Funktionalität kennen.

Nein, eben nicht! Es ist zum Beispiel sehr leicht, Exim mit
Spamassassin zu verheiraten. Man braucht dazu wirklich nur
Bruchteile von Exim zu kennen - gerade mal das ACL-System.
Und eigentlich nichtmal das, wenn man gut funktionierende
ACL-Regeln von einer Howto vorgekaut bekommt.

Nur leider findet man keine Howto, die dieses kompakt zusammen-
fasst. Die Howtos, die ich fand, machten es entweder viel zu
umständlich (über Amavis), waren fehlerhaft, oder beides
zugleich. Erst die Kombination mehrerer Howtos gab mir einen
roten Faden. Und mit Konsultation des Exim-Manuals konnte ich
die Details richtig hinkriegen.

Angenommen, ich nehme mir die Zeit, mit meiner Erfahrung selbst
solch eine Howto zu schreiben. Firmenintern habe ich das eh schon.
Angenommen, sie wäre monatelang getestet und per Copy&Paste anwendbar.
Wie erfahren andere davon? Und wer weiß, vielleicht haben das auch
schon andere vor mir gemacht. Aber unter den ersten 'zig Google-
Treffern ist keine solche Howto zu finden.

Man findet fast ausschließlich den "Exim+Amavis"-Quatsch, sodass
man wirklich den Eindruck gewinnen muss, dies wäre eine vernünftige
Lösung. BTW, auch ich glaubte das anfangs. Und die vielen Leute,
die sich daraufhin solch eine Konfiguration antun, werden in ihren
Webseiten/Blogs wiederum auf "Exim+Amavis"-Howtos verlinken, wodurch
diese Howtos nochmals von Google hochgewertet werden. Eben ein Reddit-
Effekt, ein ernsthaftes Problem.

Man müsste schon einen provokanten "Don't use Exim+Amavis" - Artikel
schreiben, und verschiedene hochrangige Seiten finden, die ihn
bekannt machen. Oder an die ganzen "Exim+Amavis"-Howtos herantreten,
und sie davon überzeugen, auf die eigene Howto zu verweisen. Auf
jeden Fall wäre enorme Lobby-Arbeit nötig. Von allein, nur durch
ihre höhere Qualität, werden sich die besseren Exim-Spamscanner-
Howtos wohl nicht durchsetzen.

> Was ist mit "works for me"? Für mich ist das (in privatem Umfeld) das
> einzig wirklich wichtige Kriterium.

Wenn die meisten Howtos wenigstens _dieses_ Kriterium erfüllen
würde, wären wir weiter. Ich wage zu behaupten, dass gewisse
Howtos nicht einmal beim Autor selbst funktionieren. "works for me"
setzt nämlich voraus, dass man sein Geschriebenes wenigstens ein
einziges Mal _selbst_ ausprobiert hat. SCNR :-)


[ OT ]

> >> So lange Computer als abgeschlossenes System betrachtet werden. Aber
> >> schon wenn man sich ansieht wieviel Aufwand mit Prüfsummen und "sicheren
> >> Bereichen" auf CDs und DVDs und der Kühlung von CPUs getrieben wird, ist
> >> ersichtlich, dass es eben doch nicht sonderlich determiniert ist.
> > [...]
> > Das stimmt, aber diese nichtdeterministischen Züge sind gerade _wegen_
> > der Digitaltechnik und der Checksummen äußerst selten.
> > [...]
> [...] Ich hatte in der anderen
> Mail schon geschrieben, dass sich auch mit Computern chaotische Systeme
> simulieren lassen können, deren Ergebnisse nicht vorhersagbar sind.

Das ist richtig, aber diese chaotischen Systeme sind dennoch
deterministisch! Es ist ihre _Komplexität_, die die Vorhersagen
unmöglich macht. Mit Determinismus vs. Nichtdeterminismus hat
das nichts zu tun. (siehe andere Mail)

> Du hast mich schon mehrfach auf unterschiedliche Fehler in den
> Maileinstellungen für meinen MUA hingewiesen (meine ersten Mails waren
> in HTML, die Sache mit dem inline-PGP und noch einiges mehr),

War das immer ich? Ist mir gar nicht aufgefallen ...

> wofür ich
> dankbar war und auch immer umgesetzt habe. Ich versuche mich an die
> Regeln der Netiquette zu halten, wenig Rechtschreibfehler zu machen und
> keine Fragen zu stellen, die ich mit ein wenig Aufwand auch selber
> beantworten kann.

Das ist lobenswert.

> WEIL es um Kommunikation mit anderen Menschen geht.Was
> ich auf meinem System mache ist meine Sache. Auch, mit welchen
> Informationen ich Probleme löse (wenn ich meinen Computer nicht in eine
> Viren- uns Spamschleuder verwandele und so Andere gefährde).

Selbstverständlich ist das allein deine Sache. Aber man kann doch
über solche Methoden diskutieren. Es bleibt doch jedem selbst
überlassen, wieviel er aus einer Diskussion heraus nimmt und ob er
seine Methoden daraufhin ändert oder nicht - jenachdem, wie
überzeugend er die entsprechenden Argumente findet.

Sollte irgendeine Meinungsäußerung als Befehl bei dir angekommen
sein, dann tut es mir leid. So war es ganz sicher nicht gemeint.


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR