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.

Wie man zu zugeschnittenen Spanplatten kommt, wenn der Baumarkt nicht kann oder nicht will.

Für einige Projekte beim Umzug braucht es Holz. Holz in gängigen Farben (hauptsache es ist weiß oder Natur) und in rechteckig bekommt man ja prima im Baumarkt zugeschnitten, direkt zum Mitnehmen. Aber wehe, es muss eine exotischere Farbe oder eine nicht rechteckige Form sein.

Und was beim Schreiner und beim Möbelbauer für die doppelte Rückwand des Küchenrückseitenregals prima geklappt hat, ist bei den neuen Platten für Monitore, Mischpult und Plattenspieler genauso königlich in die Hose gegangen.

Continue reading "Schreiner kommt doch von Schrei"

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.

Uralt, aber lustig und lehrreich. Mal wieder gefunden bei Jan, und der hat's um ein Paar Ecken von IT-Blog.

Ohne Flash, funktionierenden Sound und Englischkenntisse wird man da übrigens eher nix.

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.

Beim Durchlesen alter eigener Blogeinträge ist mir aufgefallen, dass ich hier noch eine Unerledigte Sache herumliegen habe.

Am nächsten Tag ging es nämlich daran, nochmal vier Steckdosenlöcher in die Spanplatten zu sägen, die in Zukunft die Rückwand des obersten Fachs der Rückseite des Küchenraumteilers bilden sollen. Das ging mit der Säge, mit der ich mich am Tag vorher durch die Küche selbst gequält habe, nicht wirklich schnell.

Nur ist mir diesmal irgendwann der Kragen geplatzt und ich habe meine gute, alte, uralte Lochsäge, die ich schon vor zwei Jahren wegen "abgenutzt" wegwerfen wollte, nochmal aus den tiefsten Tiefen des Werkzeugkastens herausgekramt.

Und mit der waren die Löcher rattatazonk rasend schnell in den Spanplatten drin, und ich frage mich, warum die sauteure, nagelneue, ausdrücklich für Spanplatte freigegebene Lochsäge vom Bauhaus mich am Tag vorher so gequält hat. Hätte ich vielleicht doch nicht die günstigere Wolfcraft sondern die richtig teure von Habichmirnichtgemerkt kaufen sollen. Oder vier von den ganz billigen, die zusammen auch noch günstiger gewesen wären als die Wolfcraft.

Inzwischen sind alle zwölf Steckdosen eingebaut und zusammen Hängelampe, Unterschranklampen und die neue Arbeitsplattenbeleuchtung angeschlossen. Nur die Stromzuführung ist derzeit noch provisorisch mit einem umfunktionierten Kaltgerätekabel in der Wandsteckdose. Da muss ich nächstens noch schnellstens etwas "endgültiges" hinbauen, denn nächste Woche steht ein Racletteabend an, und bis dahin muss die Schaltung auch so sein, dass man da guten Gewissens mal ein Kilowatt rausziehen kann ohne dass man Angst haben muss dass einem die Zuführung schmilzt.