Zugschlusbeobachtungen

In einem auf Dateien basierenden TUI kann man mehrere Änderungen gleichzeitig durchführen, die dann mit der Aktivierung der neuen Konfigurationsdatei alle zusammen gleichzeitig aktiv werden. Während der Durchführung der Änderungen kann ein inkonsistenter Zustand bestehen, ohne dass er sich auf den laufenden Betrieb auswirkt.

In einem auf einer Kommandozeile basierenden TUI sind zwei Philsophien möglich: Entweder erwartet das System, dass der Administrator sicherstellt, dass die zwischendrin auftretenden Inkonsistenzen nicht fatal sind ("Du hast es so gewollt, da hast Du's"-Ansatz, siehe Cisco), oder es verhindert Inkonsistenzen durch Programmlogik ("you cannot delete option foo because it is still in use in option bar", was besonders bei mehrstufigen Abhängigkeiten der optionen untereinander bei so trivialen Dingen wie "ich möchte eine Accessliste umbenennen" zu massiver Mehrarbeit lösen kann, siehe auch Netscreen).

In einem GUI sind diese Paradigmen beide genauso möglich, wobei die meisten GUIs den zweiten, restriktiveren Ansatz verfolgen. Auch die Speicherung mehrerer Änderungen und deren gesammelte atomare Aktivierung ("Transaktionsfähigkeit") ist in GUIs möglich, aber eher selten implementiert.

Unentschieden, mit IMO leichtem Plus für das dateibasierende TUI wegen der aus dem Konzept inhärent folgenden Transaktionsfähigkeit.

In einem TUI kann man Fehler machen. Die der Texteditor nicht bemerken kann, denn für ihn ist ja alles nur Text. Was dann auch bedeutet, dass einem im schlimmsten Fall die Applikation um die Ohren fliegt oder böse Dinge mit den Datenbeständen macht, wenn man die neue Konfiguration dann letztendlich aktiviert.

In einem GUI kann man prüfen, ob die Daten korrekt sind, bevor man sie aktiviert. Und Dinge wie "Tippfehler in Optionsnamen" können prinzipbedingt nicht auftreten.

Plus fürs GUI.

Meist will man ja etwas automatisieren, damit die Dinge besser skalieren. Hier ist man mit einem TUI-konfigurierten System auch besser dran: Denn Textdateien kann man prima generieren. Ganz einfach, mit print-Statements. Die in genannten Nachteile generierter Konfiguration greifen zwar auch hier, aber hier hat man sich den Mist wenigstens selbst eingebrockt und kann die Eingabedaten so organisieren, dass man die Vorteile eines TUIs wenigstens in den Eingabedaten nutzen kann.

Beim GUI? Wenn man sich nicht mit GUI-Scripten a la "warte darauf, dass ein Fenster mit der Titelzeile foo und der Option bar gezeichnet wird, simuliere einen Mausklick auf bar und drücke OK" behelfen mag, und das GUI nicht "hintenrum" doch auf einem TUI basiert, hat man verloren.

Plus fürs TUI.

Manche Systeme haben eigentlich ein TUI, und ein darüber gestülptes GUI irgend einer Provinienz. Vielleicht noch darüber gestülpte GUIs verschiedener Provinienzen.

Aber wehe, Du möchtest in diesem Fall das TUI als TUI nutzen. Dann wird es Dir in den allermeisten Fällen weh tun, denn die meisten GUI-Aufsätze schreiben die Konfiguration neu, und zwar so, wie es ihnen passt. Damit sind alle Deine Kommentare und zusätzlichen Strukturierungshilfen futsch. Und wenn Du wirklich Pech hast, kommt der GUI-Aufsatz nur klar, wenn die zu parsende TUI-Datei genau den Vorstellungen des GUI-Aufsatzes entspricht, und macht sonst eher "interessante" Dinge. Oder, der GUI-Aufsatz macht sich gar nicht erst die Mühe, die TUI-Datei zu lesen, sondern führt eigenen State in internem Datenbestand mit und überschreibt nur die TUI-Datei. Das ist dann auch das Ende der Träume, unterschiedliche GUI-Aufsätze parallel nutzen zu können.

Da dies eher Implementierungsmacken der GUI-Aufsätze sind (die dennoch in nahezu 100 % der tatsächlich vorhandenen Implementierungen vorhanden sind): Unentschieden.

Wenn man System B genauso konfiguriert haben will wie System A, transferiert man einfach die entsprechenden Teile der Textkonfiguration von B nach A. Das kann über Dateitransfer geschehen, oder im einfacheren Fall einfach per Text-cut-and-Paste vom einen Fenster des Admins auf das andere.

Zum Vergleich das GUI: Hier muss man entweder den Umweg über Word- oder HTML-Dokumente mit Screenshots gehen, auf denen oft genau das wichtige Unterfenster der dritten Subebene fehlt, in dem die magische "mach-dass-es-funktioniert"-Option eingestellt werden kann, oder man hat zwei (auf dem Bildschirm wertvollen Platz belegende) grafische Oberflächen und man überträgt die Konfiguration manuell vom einen Fenster ins andere, ohne das Clipboard als Hilfe benutzen zu können.

Bestenfalls erzeugt das GUI letztendlich doch wieder eine Textkonfiguration, oder man darf schlecht oder gar nicht dokumentierte Registrybäume oder Datenbankdumps von einem System aufs andere schieben.

Plus fürs TUI.

Fast jedes mir bekannte Format für Konfigurationsdateien erlaubt Kommentare. Wenn man nun eine Option temporär ausschalten möchte, kommentiert man sie - zusammen mit sämtlichen dazu gehörigen Parameten - einfach aus. Damit ist sie inaktiv, man sieht aber, dass da mal was war, und die Wiederherstellung des Ursprungszustands ist trivial.

Zum Vergleich das GUI: Dort sieht man nicht, wenn eine Option abgeschaltet wurde. Und zu einer Option gehörende Parameter sind nach dem Wiederaktivieren der Option in den meisten Fällen entweder komplett weg oder auf meist unpassende Defaultwerte zurückgestellt. Oder, noch besser, Teile der Parameter sind zwar im GUI nicht mehr sichtbar, haben aber immer noch Wirkung auf das System. In den allerwenigsten Fällen bleiben die Parameterwerte zuverlässig unwirksam und trotzdem intern erhalten.

Plus fürs TUI.

Magst Du lieber Emacs oder vi? Und, sind alle Deine Kollegen derselben Meinung?

Egal. Jeder nimmt einfach das Tool, das er will.

Beim GUI? Friß das, was man Dir vorgekaut hat, oder stirb.

Plus fürs TUI, auch wenn diejenigen, die lieber klicken, sich nicht das Tool ihrer Wahl aussuchen können.

flawed schreibt in seinem Blog über Automatisierung mit GUI und Automatisierung mit TUI.

Zu dem Thema habe ich zwar was in der Pipe, aber das was flawed schreibt, ist erstens richtig und setzt sich zweitens mit der Thematik in einer höheren Tiefe auseinander.

Du willst in einem TUI-System, dass automatisch nachvollzogen werden kann, wer wann welche Änderung vorgenommen hat, und auf einen Blick sehen, was sich in der Konfiguration eines Systems geändert hat, seit die externe Dokumentation das letzte Mal angefasst wurde? Kein Problem, man werfe einfach die Konfiguration in das Versionskontrollssystem, das die Programmierabteilung ebenfalls benutzt und für das deswegen erhebliches Knowhow verfügbar ist. Mit geeigneter Einrichtung kann man auf diese Weise auch Staging realisieren und sicherstellen, dass die ins Versionskontrollsystem eingecheckte Konfiguration auch immer die ist, die wirklich in Betrieb ist.

In einfacheren Fällen dokumentiert man halt im Konfiguratonsfile selbst, wo dann die Vergleiche greifen, die im Artikel über Dokumentation direkt im Konfigurationsfile aufgeführt sind.

Im Verglich dazu wirkt das GUI geradezu archaisch: Da bist Du darauf angewiesen, dass alle Leute mit Adminrechten sauber die externe Dokumentation mitführen. Was in aller Regel nicht wirklich realistisch ist.

Plus fürs TUI.

Der Artikel war schon geschrieben, als Treibholz auch darüber schrieb.

Zwei Systeme sollten eigentlich identisch konfiguriert sein. Ja, sollten eigentlich. Trotzdem tun sie unterschiedliche Dinge, wenn man sie mit denselben Daten bewirft. Woran liegt's?

Beim TUI kopiert man die Konfigurationsdateien in unterschiedliche Verzeichnisse und macht ein diff oder gar ein wdiff, und die Unterschiede liegen sofort auf der Hand.

Beim GUI ist Handarbeit angesagt, mit entsprechender Fehlerquote.

Plus fürs TUI.

Nachdem die ersten Artikel aus der Artikelreihe nun erschienen sind, zeigt sich ein deutlicher Überhang der Artikel, die mit "Plus fürs TUI" enden. Das liegt zugegebenermaßen daran, dass ich in dieser Frage eine eindeutige Meinung vertrete.

Da ich hier aber wenigstens halbwegs unparteiisch auftreten möchte, bin ich gerne bereit, auch "Minderheitenmeinungen" hier im Blog zu veröffentlichen. Wer selbst ein Blog hat, blogged bitte selbst darüber, und ich setze dann einen Trackback. Wenn ich will, und der Autor einverstanden ist, kommt der volle Wortlaut auch in mein Blog. Wer kein eigenes Blog hat, schreibt seinen Artikel am besten als Kommentar zu einem meiner Artikel. Ich werde dann den Kommentar löschen und einen eigenen Artikel, natürlich mit Namensnennung des Autors, daraus bauen.

Natürlich hätte ich gerne, dass die Gastbeiträge sowohl von der Länge als auch vom Stil her ungefähr zu den anderen Artikeln in dieser Artikelreihe passen. Das bleibt Euch allerdings natürlich unbenommen.

Ich habe noch nie ein übersetztes Konfigurationsfile gesehen. Das ist für Administratoren, die nur wenig Englischkenntnisse haben, nicht selten ein Problem.

Ein GUI kann man übersetzen, ohne großartige Änderungen an der Programmlogik vornehmen zu können. Wobei dies auch Nachteile hat: In einem englischen TUI oder einem englischen GUI sehe ich die Suchbegriffe, die ich auf die Suchmaschine werfen muss, um auch internationale Hilfe zu finden. Wenn man mir das GUI übersetzt hat, darf ich entweder raten, wie die Option im Englischen heißt, oder ich muss mich im Internet auf Support aus dem deutschsprachigen Raum beschränken.

Ich sehe das eigentlich als "unentschieden", aber ich will mal gnädig sein: Plus fürs GUI.

Fast jedes mir bekannte Format für Konfigurationsdateien erlaubt Kommentare. Sinnvoll genutzt, kann man sich externe Dokumentation damit fast vollständig sparen: Man schreibt die Dokumentation einfach dorthin, wo derjenige, der die Konfiguration verstehen möchte, sowieso hineingucken muss. Direkt in das Konfigurationsfile.

Continue reading "GUI gegen TUI: Man kann die Dokumentation direkt zur Konfiguration schreiben"

Hast Du Dich schonmal gefragt, wo denn die eine Konfigurationsoption versteckt war, an deren Namen Du Dich noch erinnerst? Prima, dafür gibt's grep oder die Suchfunktion Deines Texteditors.

Beim GUI? Da hilft nur Intuition oder Suchen in der Doku.

Plus fürs TUI.

Mit dieser Artikelreihe erfülle ich mir einen Wunsch, den ich schon seit Jahren mit mir herumtrage: Ich möchte grafische Userinterfaces (GUIs) und auf Text basierende Userinterfaces (TUI, nicht mit dem Touristikveranstalter zu verwechseln) miteinander vergleichen. Für Popcorn in hinreichender Menge sei gesorgt; ich bemühe mich, die Artikel hinreichend provokativ zu formulieren, dass in den Kommentaren auch ein wenig Diskussion entsteht.

Ich habe hierbei einige Artikel vorgeschrieben und sie bereits schon zur zeitgesteuerten Veröffentlichung in der Blogsoftware abgelegt. Es wird also für einige Tage jeden Tag um dieselbe Zeit ein neuer Artikel erscheinen. Und gegen später werde ich dann wieder auf die "normale", aufkommensabhängige Erscheinungsweise umstellen.

Die Artikel sind mit gui-vs-tui getagged, dieser Link führt zu den gesammelten Artikeln, und hier gibt es den passend eingeschränkten RSS-Feed.