Der folgende Text ist eine Übersetzung des Essays The Luxury of Ignorance: An Open-Source Horror Story von Eric S. Raymond. Sie wurde am 2004-04-04 von Gregor Ottmann übersetzt. Gregor hat mir die Datei dankenswerterweise am 2006-04-07 zur Verfügung gestellt und ich werde diese nun hier weiter pflegen. Jeder Entwickler von Freier Software bzw. von Software im allgemeinen sollte diese Zeilen einmal gelesen haben.
Ich habe den Versuch hinter mir, CUPS, zu konfigurieren. Dies war eine Erfahrung wie aus dem Lehrbuch und zeigt, warum Nichttechniker schreiend vor Unix zu flüchten pflegen. Das Ganze ist um so frustrierender, weil die CUPS-Entwickler offensichtlich wirklich versucht haben, ein zugängliches System zu entwickeln. Ihre guten Absichten und Mühen haben jedoch zu einem System geführt, das trotz seiner Pseudo-Benutzerfreundlichkeit so unverständlich ist, dass es genausogut in Sanskrit geschrieben worden sein könnte.
GUI-Tools und umfangreiche Handbücher sind nicht genug. Man muss sich Gedanken darüber machen, was dem tatsächlichen Benutzer widerfährt, wenn er (oder sie) sich an den Rechner setzt, um tatsächlich etwas zu tun - und man muss die Sache vom Standpunkt des Benutzers aus betrachten. Die CUPS-Leute haben dabei, trotz guter Absichten, vollständig versagt. Ich werde dieses Versagen im Detail auseinandernehmen, weil es hier Lektionen gibt, aus denen auch andere Open-Source-Projekte etwas lernen könnten. Das Ziel dieses Essays ist es also nicht, auf die CUPS-Leute einzuprügeln - es soll auch auf jeden anderen Open-Source-Entwickler eingeprügelt werden, der vergleichbar gedankenlos handelt, weil er der kühnen Illusion verfallen ist, dass ein schickes Oberflächendesign automatisch ein gutes Oberflächendesign ist. Lest und lernt ...
Die Aufgabenstellung ist einfach. Ich habe einen Desktoprechner namens "snark", dieser ist über das Netzwerk zuhause mit dem Rechner von Cathy (meiner Frau), verbunden, der "minx" heißt. An Minx' Parallelport hängt ein Laserjet 6MP. Auf beiden Rechnern ist Fedora Core 1 installiert, und Cathy kann mit dem Drucker an minx problemlos drucken. Ich kann minx von snark aus per ssh erreichen, also ist das Netz offensichtlich in Ordnung.
Das sollte kein Problem sein, oder? Selten so gelacht. Berühmte letzte Worte ...
Zunächst tue ich, was jeder Nichttechniker tun würde: Ich gehe ins Startmenü und klicke auf "System Settings → Printing" und gebe das Rootpasswort im daraufhin erscheinenden Dialog ein. Ein "Printer Configuration"-Popup geht auf und ich klicke auf "New". Schon erscheint ein Assistent mit dem Titel "Add a new print queue" in großen, freundlichen Buchstaben. So weit, so gut - ich klicke auf "Forward".
Nun, diejenigen unter euch, die mit CUPS vertraut sind, wissen, dass ich bereits einen grundlegenden Fehler begangen habe. Ich sollte gar nicht erst probieren, eine neue Druckerwarteschlange auf snark zu erstellen und sie dann mit dem Server auf Minx zu verdrahten. Wenn ich Druckaufträge an minx weiterleiten will, sollte ich stattdessen im Konfigurationsassistenten die Warteschlange auf minx angeboten bekommen und sie als Standardwarteschlange für snark auswählen. Es weist aber nichts in diesem Assistenten auf so etwas hin! Außerdem wird die Warteschlange von minx gar nicht angezeigt - aus Gründen, die wir später in dieser traurigen Geschichte kennenlernen werden.
Der nächste Abschnitt des Assistenten trägt, in vergleichbar großen und freundlichen Lettern, den Titel "Queue name". Er bietet mir den Vorschlag "printer" an, den ich in "laserjet" ändere, weil ich vielleicht irgendwann einmal dieses Nadeldrucker-Teil anschließen will, das ich noch rumliegen habe. Ich gebe auch noch die optionale Kurzbeschreibung an: "the laser printer". Bisher ist alles in Ordnung, Tante Tillie würde mit sowas wunderbar zurechtkommen. Nächster Schritt ...
"Queue type" ist der Titel des nächsten Abschnitts. Hier gibt es ein Dropdown-Menü mit der vorbelegten Einstellung "Locally connected", was an sich recht sinnvoll ist. Nach einem Klick auf das Dropdown-Feld bekomme ich die folgenden Auswahlmöglichkeiten angeboten:
Hier haben wir es mit der ersten Andeutung von Schwierigkeiten zu tun. Angenommen ich wäre Tante Tillie, das Musterbeispiel eines nicht technisch begeisterten Benutzers - dann würde ich jetzt wohl sowas denken wie "Was zum verdammten Geier soll das denn jetzt bedeuten? Und, noch wichtiger, warum muss ich so eine Frage beantworten?". Immerhin habe ich überhaupt keine Windows-Rechner in meinem Netz. Auch keine Netware-Kisten. Und ich habe ganz sicher keine "Networked JetDirect", was auch immer das jetzt schon wieder sein soll.
Wenn die Designer halbwegs fähig hinsichtlich Fragen der Benutzeroberfläche wären (etwa so wie, nunja, Windows-Entwickler), würden sie die Netzwerkumgebung absuchen und die mit Sicherheit überflüssigen Optionen einfach weglassen. Wenn sie so richtig fit in derlei Dingen wären (etwa so wie, nunja, Mac-Entwickler), würden sie die überflüssigen Optionen anzeigen, sie jedoch ausgrauen - um so zu zeigen, dass man tatsächlich auch über eine Windows-Kiste drucken könnte, wenn das System etwas anders konfiguriert wäre und man in der unglücklichen Lage wäre, eine solche zu besitzen.
Aber nein. Stattdessen gewinnt Tante Tillie langsam den Eindruck, dass diese Software von planlosen Freaks entworfen wurde.
Aber halt, wartet! Hallelujah! Es gibt einen Hilfe-Button! Ich klicke ihn an, und es wird eine hübsche Seite aus der Onlinehilfe angezeigt. Statt jedoch die Frage in meinem Kopf, die "Wie wähle ich den richtigen Warteschlangentyp aus?" lautet, zu beantworten, geht es auf dieser Seite darum, wie man einen lokal angeschlossenen Drucker hinzufügt. Offensichtlich bezieht die Hilfe sich also um den derzeit ausgewählten Warteschlangentypen, nicht auf die Auswahl der richtigen Art von Warteschlange. Die Hilfe ist also nicht besonders hilfreich.
An diesem Punkt gibt sich Tante Tillie entweder einer weiteren Runde Folterung durch die armseligen Designentscheidungen wohlmeinender Idioten hin oder entscheidet sich dazu, diesen ganzen Linux-Krempel einfach hinzuschmeißen und wieder zur alten Windows-Kiste zurückzukehren. Die hat zwar oft blaue Bildschirme angezeigt, aber zumindest hat sie ihr den Luxus der Unwissenheit zugestanden - sie musste nicht wissen oder auch nur im geringsten daran interessiert sein, was ein JetDirect oder CUPS wohl sein mögen.
Ich bin nicht unwissend, aber ich habe mein ganz persönliches Äquivalent von Tante Tillies Problem. Ich weiß, dass ich eine der beiden ersten Optionen in der Liste haben will, aber ich weiß nicht, welche. Genaugenommen will auch ich nicht wissen oder mich dafür interessieren, was der Unterschied zwischen beiden ist. Ich kann mir bessere Dinge vorstellen, die ich mit meinem Hirn tun könnte, als es mit Systemadminitrationsdetails vollzustopfen. Wenn das Tool dazu in der Lage ist, herauszufinden, dass eine oder beide Methoden im Netz verfügbar sind (was nicht allzu schwer sein sollte, da die Ports wohlbekannt sind), sollte es einfach "empfohlen" neben eine der Optionen schreiben, damit ich diese anklicken und weitermachen kann.
Aber, neeeeein. Stattdessen darf ich die Onlinehilfe anstarren und mir die Frage "Wo kann ich wohl eine Anleitung finden, und warum zum Teufel dauert das ganze schon viel zu lang?" stellen. Ich wende mein berüchtigtes Hacker-Kung-Fu an und probiere es einmal mit einem Klick auf "Prev". Ich bekomme eine Seite über die Druckerkonfiguration angezeigt, die zwar die Warteschlangentypen beschreibt aber mir immer noch keinen Hinweis darauf gibt, ob ich mich für CUPS oder LPD entscheiden soll.
Offensichtlich ist es den Entwicklern von CUPS nie in den Sinn gekommen, dass dies für irgendwen ein Problem darstellen könnte, weder für Tante Tille noch für technisch versiertere Anwender. Es gibt keinen großen, freundlichen Button neben "Select a queue type" mit der Beschriftung "Wie man den richtigen Typen auswählt". Dies ist ein schwerer Fehler im Design der Benutzersschnittstelle, der die oberflächliche Schnittigkeit des Konfigurationsassistenten zu einer Farce werden lässt und den Benutzer verspottet.
In einer weiteren Anwendung meines berüchtigten Hacker-Kung-Fus rate ich einfach und wähle "CUPS (IPP)". Jetzt erscheint eine neue Eingabemaske, durch die die Benutzerschnittstelle von einer Verhöhnung zu etwas noch viel Schlimmeren wird. Sie enthält zwei Eingabefelder. Das eine ist mit "Server" beschriftet und leer, das andere hat die Beschriftung "Path:" und enthält den Text "/printers/queue1".
Falls Tante Tillie zu diesem Zeitpunkt noch dabei ist, dürfte sie jetzt wohl einige nicht sehr damenhafte Ausdrücke verwenden. Zu Recht, denn das ist jetzt eine klare Bauchlandung, eine absolute Katastrophe. Um das zu verstehen, muss man für einen Moment aufhören, wie ein Hacker zu denken. Man muss sich in die Denkweise eines völlig planlosen Anwenders versetzen, sofern man sich dazu befähigt fühlt. In die Denkweise einer Person, die nicht nur keine Ahnung hat, was ein Text wie "/printers/queue1" bedeuten könnte, sondern es auch gar nicht wissen will und nicht der Ansicht ist, dass er oder sie es lernen müssen sollte.
Von Tante Tillies Standpunkt aus betrachtet, macht es durchaus Sinn, dass das Feld für den Server leer ist, immerhin hat sie ja keinen angegeben. Die Vorbelegung des Felds für den Pfad ist jedoch schlimmer als nutzlos, sie ist tatsächlich schädlich - weil sie nicht weiß, was der Wert bedeutet und keine Möglichkeit hat, um herauszufinden, ob diese Vorgabe sinnvoll wäre, wenn sie tatsächlich einen Server angeben würde. Sie läuft hier also voll gegen die Wand.
Eigentlich hätte hier eine von zwei alternativen Anzeigen angeboten werden müssen: entweder eine Liste der CUPS-Druckwarteschlangen im lokalen Netz oder eine große Anzeige in Fettschrift, die ihr mitteilt, dass es keine lokalen Warteschlangen gibt und sie möglicherweise einen Druckserver aufsetzen muss. Die Aufforderung, hier den Server und Pfad manuell einzugeben, ist wie eine Steinmauer - nicht nur Tante Tillie wird hier ohne eine Idee, was zu tun ist, alleingelassen, die Sache ist auch für einen erfahrenen Hacker wie mich völlig undurchsichtig.
Das übergeordnete Problem hier ist, dass der Assistent zwar die ganzen üblichen Rituale durchführt (Benutzeroberfläche mit schnuckeligen Buttons, Hilfeseiten im Browser etc. etc.), dabei aber den eigentlichen Sinn dieser Rituale völlig außer Acht lässt: Zugänglichkeit, d.h. die Eigenschaft, dass die Benutzerschnittstelle an jedem Punkt die Möglichkeit bietet, herauszufinden, wie es weitergehen soll. Hat dein Projekt diese Eigenschaft?
Tatsächlich ist die "Queue type"-Eingabemaske eine absolut unzugängliche Schnittstelle: Sie führt einen in die Sackgasse des Versuchs, eine lokale Warteschlange für einen Rechner im Netz einzurichten, von dem man weiß, dass er drucken kann - wie der Rechner meiner Frau Cathy - um einem dann wüste Flüche zu entlocken, wenn der Versuch eines Testausdrucks fehlschlägt. Genaugenommen ist das genau das, was mir als nächstes passiert ist.
Ich habe im Server-Eingabefeld "minx.thyrsus.com" eingetragen, in der Annahme, dass "/printers/queue1" eine sinnvolle Voreinstellung sein müsste, die bei anderen CUPS-Installationen genauso verwendet wird. Dann habe ich mich durch die Abfragen für Druckerhersteller und -modell geklickt und die Erzeugung der Warteschlange bestätigt. Der Assistent hat daraufhin ein Fenster geöffnet und mir angeboten, eine Testseite zu drucken. Ich sagte ihm, dass er das tun soll und nichts passierte. Tatsächlich passierte etwas Schlimmeres als gar nichts: Im Konfiguratorfenster wurde eine Nachricht mit dem Text 'Network host "minx.thyrsus.com" is busy, will retry in 30 seconds' ausgegeben, und der Konfigurator hat sich aufgehängt, soweit ich das erkennen konnte.
Wir befinden uns jetzt tief in den nicht kartographierten Sumpfgebieten, welche von gedanken- und folglich nutzlosen Schnittstellendesign geschaffen wurden - Glitzerei und Grafik ohne Bedeutung und Nutzwert. Genau dies war der Punkt, an dem ich mich entschieden habe, diesen Artikel zu schreiben und ein paar Notizen zu machen.
Der "Queue type"-Dialog hatte mir keinerlei Aufschluss über die Existenz, die Nichtexistenz oder die Möglichkeit der gemeinsamen Nutzung irgendwelcher Druckwarteschlangen im Netz gegeben. Ich habe zwei Rechner im Haus, auf denen Vollinstallationen von Fedora Core laufen und die im Netz hängen; das wirklich richtige Systemverhalten wäre es gewesen, mir eine Ausgabe in der Art von "ich sehe CUPS-Demons auf minx, golux und grelber, aber es existieren keine nutzbaren Druckerwarteschlangen" anzuzeigen und einen Hinweis auf die passende Stelle in der Dokumentation von CUPS mitzuliefern.
Die Hilfe war an dieser Stelle allerdings einmal mehr nicht hilfreich. Auf der Seite über "Networked CUPS (IPP) Printer" steht in etwa Folgendes: "Alle IPP-Netzwerkdrucker, die über das CUPS gefunden werden konnten, erscheinen im Haupfenster unter der Kategorie Browsed queues." Ach, wirklich? Und welches "Hauptfenster" soll das bitte sein? Abgesehen davon kriege ich hier nicht den geringsten Hinweis darauf, was ich tun soll, wenn ich keine Kategorie namens Browsed queues finden kann, was ganz besonders schwachsinnig ist, weil das der ganz normale Standardfall bei einer frischen Installation ist!
Nichts von alldem ist besonders kompliziert. Das Problem ist nicht, dass es von einem technischen Standpunkt aus gesehen besonders schwierig wäre, das Richtige zu tun: CUPS sollte die Fähigkeit zur Erkennung der aktiven Drucker im Netz theoretisch sowieso haben. Das eigentliche Problem ist, dass die Einstellung der Designer von CUPS falsch ist. Sie haben sich nie von ihren Annahmen und ihrem Spezialwissen gelöst. Sie haben sich niemals die Mühe gegeben, zu vergessen, was sie wissen, und das System so zu betrachten wie es ein dummer User tun würde, der es noch nie zuvor gesehen hat - und sie haben nie einen solchen dummen User dabei beobachtet, wie er genau das tut.
CUPS ist keine Ausnahmeerscheinung. Diese Art von Nutzlosigkeit grafischer Oberflächen ist ziemlich verbreitet in der Open-Source-Welt, und genau das zementiert die Position von Microsoft. Es mag ja sein, dass sie gammelige, unsichere, überteuerte und schäbige Software produzieren, aber in diesem einen Bereich sind deren halbhirnige, halbkompententen Anstrengungen dem, was wir normalerweise hinkriegen, immer noch um Größenordnungen überlegen.
Jetzt reicht es aber erstmal wieder mit der Nölerei. Ich will nun lieber über meine Forschungen, die mich aus dieser Sackgasse führen sollten, berichten, denn auch dabei gibt es etwas zu lernen. Zunächst habe ich nach der Dokumentation gesucht, was ich so getan habe, wie es ein Unix-Hacker nunmal tut: Durch das Anstarren der Ergebnisse von locate printers und der Jagd nach irgendetwas in /usr/share/doc, das mit CUPS in Verbindung stehen könnte. Tatsächlich habe ich die Datei /usr/share/doc/cups-1.1.19/printers/index.html gefunden und gleich einen Browser darauf angesetzt - ich wurde sofort auf http://localhost:631/ weitergeleitet, was völlig OK war, obwohl die Umleitung vielleicht etwas arg schnell vorbeigerauscht ist.
Nun betrachtete ich also eine Webseite, die keineswegs offensichtlich nützlich für die Behebung meines Problems war. Ich habe dann einfach mal versucht, auf den Button "Administration" zu klicken, in der Hoffnung, dass sich dahinter ein etwas zugänglicheres Werkzeug verbergen könnte, als es der Konfigurationsassistent war. Das System fragt mich nach einem Passwort.
Hallo? Woher soll ich denn jetzt bitte wissen, was ich mit diesem Teil anfangen soll? Das einzige, was es mir zu verraten gewillt ist, ist dass es einen "CUPS login" von mir haben will. Ist das jetzt das selbe wie der Login für root, oder gibt es vielleicht ein besonders ausgefallenes CUPS-Benutzerkonto, von dem ich auf telepathischem Wege etwas erfahren haben sollte? Die Meldung bei diesen Passwortabfragen lässt sich leicht anpassen; diese hätte mir also einen Hinweis oder zumindest einen Verweis auf die Stelle in der Dokumentation anbieten können, an der ich einen solchen Hinweis hätte bekommen können. Sie tat es nicht.
Wieder einmal sind wir beim Thema des Fehlens von Zugänglichkeit. Diese Passwortabfrage war wieder kein Wegweiser zum tieferen Verständnis des Systems, sondern eine massive Mauer.
Wenn alle Stricke reißen, gibt es ja immer noch Google. Ich suchte also nach "CUPS printing HOWTO" und fand einen Link zu "The Linux Printing HOWTO" - bei dessen Verfolgung ich dann einen 404 bekommen habe. Nun gut, dafür können die Entwickler von CUPS wohl eher nichts, ich wollte es nur einwerfen, um zu zeigen, dass ich zu diesem Zeitpunkt das Gefühl hatte, verprügelt, misshandelt und mit Acryllack bemalt worden zu sein. ([Anm. des Übersetzers: "I was feeling screwed, blued, and tatooed" lässt sich absolut schlecht übersetzen. Genießt die hier eingeworfene Originalfassung.]) So wie es aussieht, hatte die undurchsichtige Spiegeloberfläche von CUPS es tatsächlich geschafft, mich bei einer Aufgabe zu überfordern, die eigentlich in maximal 30 Sekunden hätte erledigt sein müssen.
Ich blieb jedoch standhaft. Mein nächster Schritt war es, mich per ssh auf minx anzumelden und mal zu sehen, ob ich vielleicht irgendwie den Namen der aktiven CUPS-Warteschlange herausfinden könnte. Ich dachte, dass ich diesen Namen dann vielleicht einfach in den Assistenten auf snark klatschen und damit doch noch alles zum Laufen bringen könnte. Es hat nicht sollen sein. Die zwei Befehle, die danach aussahen, als ob sie etwas mit der Sache zu tun haben könnten, waren lpinfo(8) und lpadmin - und eine Liste der Warteschlange gibt keiner von beiden aus. Die Ausgabe von lpinfo -v sah zwar irgendwie so aus, als ob sie von Nutzen sein könnte, aber ich hatte keine Ahnung, wie ich diese Geräte-URLs in Warteschlangennamen übersetzen sollte.
Wir sind jetzt in Echtzeit unterwegs. Ich schreibe diese Zeilen während ich versuche, herauszukriegen, wie ich wieder aus diesem Labyrinth entkommen kann. Ich lese gerade das Administratorhandbuch von CUPS, und da steht Folgendes: "CUPS unterstützt die automatische Konfiguration von Druckern an Arbeitsstationen im selben Subnetz. Um Drucker im gleichen Subnetz zu konfigurieren, tun Sie einfach gar nichts. Jede Arbeitsstation sollte die verfügbaren Drucker innerhalb von 30 Sekunden automatisch finden. Die Drucker- und Klassenlisten werden automatisch aktualisiert, wenn Drucker oder Server zum Netz hinzugefügt werden." Nun, das ist ja wirklich ganz toll, aber auch das flockige Selbstvertrauen dieser Ausführungen hinterlässt mich immer noch planlos, wenn die automatische Konfiguration schlichtweg nicht funktioniert!
Ich lese also das Handbuch, und ich finde einen Hinweis auf BrowseAddress und /etc/cups/cupsd.conf, wodurch sich langsam die Nebelschleier um das Geheimnis der Funktionsweise der Autokonfiguration lichten. Es sieht so aus, als würden die CUPS-Installationen regelmäßig Broadcasts verschicken, um ihren Status und die verfügbaren Drucker anderen Installationen bekanntzugeben. Schlaues Design! Nur ist es nunmal leider so, dass der Broadcast-Mechanismus standardmäßig abgeschaltet ist und davon nichts in der Dokumentation steht!
Wir rekapitulieren: Damit die tolle, benutzerfreundliche Autokonfiguration funktioniert, muss man erst eine Datei unter /etc editieren, und zwar auf einem anderen Rechner als dem, den man gerade einzurichten versucht. Abgesehen davon muss man die Kommentare in genau dieser Datei gelesen haben, um überhaupt zu wissen, dass das so ist.
Was für ein klassisches Totalversagen das doch ist. Dass die Autokonfiguration standardmäßig deaktiviert wurde, ist vom Sicherheitsaspekt her absolut nachvollziehbar. Dass so etwas allerdings im Administratorhandbuch nicht erwähnt wird und der Anwender im Konfigurationsassistenten ebenfalls nicht darauf hingewiesen wird, dass die Drucker nicht verfügbar sein werden, solange der Systemadministrator nicht die entsprechenden Rituale auf den Printservern durchgeführt hat, ist vollständig hirn- und gedankenlos.
Genau diese Scheiße ist der Grund, warum Linux es so schwer hat, Nichttechniker zu begeistern - und die Angelegeneheit wird nicht besser, sondern schlimmer, wenn man die Fallstricke in einen Haufen GUI-Zuckerwatte verpackt, die zusätzliche Komplexität einführt, ohne dem Benutzer das Leben im Gegenzug tatsächlich irgendwie zu erleichtern.
Ich trage eine korrekte Broadcast-Adresse für mein Netz in
/etc/cups/cupsd.conf auf minx ein. Ich bin mittlerweile nur bedingt
überrascht davon, dass in der Manpage zu cupsd(8) nicht steht, ob das
normale kill -HUP
den cupsd dazu bringen wird, diese Datei neu auszuwerten, da ich
inzwischen damit rechne, dass die Dokumentation keine große Hilfe ist.
Ich starte CUPS also mit einem beherzten /etc/init.d/cups restart
neu.
Ich schreibe den vorigen Absatz, dann wende ich mich erneut dem Konfigurationsassistenten zu. Mit etwas Rumprobiererei kann ich ihm einen Punkt "Action → Sharing" entlocken. Als ich auf OK klicke, erscheint "Browsed queues" im Fenster des Assistenten. Hurra! Es sieht ganz so aus, als würde snark jetzt die Konfigurationsdaten von minx per Broadcast empfangen. Und tatsächlich: Als ich auf "Browse queues" klicke, erscheint ein LaserJet 6 als angeschlossenes Gerät. Merkwürdigerweise ist er allerdings mit lp0 beschriftet, ohne jeglichen Hinweis darauf, dass es sich nicht um ein lokal angeschlossenes Gerät handelt.
Ich fahre das Webinterface hoch. Der LaserJet 6 auf minx wird tatsächlich gefunden, aber es ist nicht alles in Butter. Als ich versuche, eine Testseite auszudrucken, wird mir ein Popup angezeigt: The connection was refused when attempting to contact minx.thyrsus.com:631.
Wieder einmal bin ich nicht davon überrascht, dass weder das Benutzer- noch das Administratorhandbuch irgendwelche Tipps zur Fehlerbehebung enthält. Die lpr(1)-Schnittstelle ist jedenfalls wenig hilfreich; wenn ich Druckaufträge von snark losschicke, werden sie von einem schwarzen Loch geschluckt.
Zufällig fällt mir die "Listen"-Direktive in der Datei /etc/cups/cupsd.conf auf. "Aha!" sage ich mir, "Vielleicht ist das ja wie bei sendmail, dem man explizit mitteilen muss, auf welchen IP-Adressen es horchen soll." Ich füge also die Zeile Listen 192.168.1.21 in die Datei ein, wobei die Adresse die IP von minx ist, starte cupsd neu und... unglaublicherweise flutscht meine Testseite aus dem Drucker.
Man sollte jetzt wirklich einmal beachten, wie weit wir Tante Tilie hinter uns gelassen haben. Die erste Regel für das Schreiben von Software für normale Anwender lautet wie folgt: Wenn sie das Handbuch lesen müssen, um das Programm zu benutzen, wurde es falsch konzipiert. Die Benutzerschnittstelle sollte alles sein, was der User an Dokumentation benötigt. Man dürfte den Normalanwender wahrscheinlich verloren haben, bevor der Punkt der Fehlerbehebungs-Rituale erreicht ist, an dem ein Hacker wie ich überhaupt erst richtig warm wird.
In diesem Fall war die Dokumentation zwar passiv, aber dennoch massiv irreführend, in einem Bereich und schadensprovozierend schweigsam in anderen. Zu einem gewissen Zeitpunkt musste ich tatsächliche meine im Kampf mit sendmail erworbenen 1337 h4x0r skillz einsetzen, um ein Problem zu lösen, das in der CUPS-Dokumentation mit keinem Wort erwähnt wurde.
Wie schon gesagt: Es geht hier nicht darum, die CUPS-Leute anzumachen. Sie sind auch nicht schlimmer als tausende anderer Projektteams da draußen, und genau das ist es, worum es hier geht. Wir reden von der Weltherrschaft, aber wir werden sie weder erlangen noch verdient haben, solange wir nicht lernen, solche Dinge besser in den Griff zu kriegen. Viel besser.
Es ist ja nicht so, als ob es besonders schwer wäre, es besser zu machen. Keine der Änderungen am Verhalten oder der Dokumentation von CUPS, die ich hier beschrieben habe, wären technisch gesehen sonderlich schwer umzusetzen. Das Problem ist, dass diese einfachen Sachen den Entwicklern nie in den Sinn gekommen sind, welche riesige Mengen von Vorkenntnissen mitbringen, sobald sie einen Blick auf die von ihnen entworfenen Benutzerschnittstellen werfen.
Wenn Ihr da draußen also grafische Anwendungen für Linux, BSD oder was auch immer schreibt, habe ich hier ein paar Fragen für euch, die Ihr euch unbedingt einmal stellen solltet:
Postscriptum, 26. Februar 2004: Ich habe die neue fünfte Frage aufgrund eines exzellenten Hinweises in den Kommentaren zur Story bei LWN hinzugefügt.
Hier noch ein paar weitere Entwurfsregeln von Nico Kadel-Garcia:
PPS, 27. Februar: Habe sehr positive Rückmeldungen von den CUPS-Leuten bekommen. Zumindest einige dieser Dinge werden wohl in Ordnung gebracht werden.
PPPS, 29. Februar: Ich habe einen Nachfolger für den Luxus der Unwissenheit geschrieben.
Es gibt jetzt eine spezielle Website für Projektteams, die Rat bezüglich Fragen der Benutzerfreundlichkeit suchen, und Spezialisten, die Helfen wollen. Es handelt sich um OpenUsability.
Anmerkung des Übersetzers: Eric S. Raymond hat in seinem Manuskript oft das Wort "discoverability" verwendet, für das ich keine geeignete Übersetzung gefunden habe. Je nach Kontext bin ich hier auf "Zugänglichkeit" bzw. "Intuitivität" ausgewichen, was in ungefähr den Kern der Aussage treffen sollte. Auch an manchen anderen Stellen war es nicht ganz leicht, den Stil des Originals halbwegs über die Übersetzungsschwelle zu tragen, aber ich hoffe, es einigermaßen hingekriegt zu haben.