GUI gegen TUI: Diffbar!
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.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Treibholz on :
Oh ja, vor allem mit vimdiff hat man da ein unglaublich tolles Werkzeug!
flawed on :
Das Argument übersieht wieder, dass auch GUIs ihre Konfigurationsdaten irgendwo speichern müssen, und dass man diese gespeicherten Daten dann auch vergleichen kann.
Xlf on :
Leider werden (insb. in der Windows-Welt) Konfigurationen meistens in der Registry abgespeichert und dort kann man nur mit grossen Aufwand Versionierung und Vergleichen hinbekommen.
Da wuenscht man sich oft die .ini-files zurueck oder den Syntax-Wildwuchs der .xyzrc files in der "Unix-Welt".
flawed on :
Ich habe früher mal ein automatisches Deployment von Konfigurationsänderungen in einer Windows/Netware-Umgebung gebastelt, das man heutzutage wohl mit Group Policies implementieren würde.
Registry-Zweige zu vergleichen war damals eine tägliche Übung.
Marc 'Zugschlus' Haber on :
Natürlich geht das. Es ist aber trotzdem ein dreckiger, unsupporteter Hack und wenn es Dir um die Ohren fliegt darfst Du die Scherben selbst zusammenkehren. Das ist nicht akzeptabel.
flawed on :
Was ist ein Hack? Meine Deployment-Skripte von damals? Zweifellos, deswegen hat Microsoft dann ja auch Group Policies erfunden - mit denen sowas dann übrigens wesentlich leichter geht, als zu versuchen, Konfigurationsdateien mit sed und Konsorten automatisch zu editieren. Das ist aber kein Vorteil eines GUIs, sondern ein Vorteil einer Datenbank als Konfigurationsspeicher.
Umgekehrt wird die "diffbar"-Eigenschaft von TUIs in dem Moment hinfällig, in dem deren Konfigurationsspeicher keine Textdatei in einem definierten Format ist. AIX' ODM wurde schon als Beispiel genannt, ein anderes sind SQL-Datenbanken, die ihre Konfiguration in einer Master-Datenbank haben.
Es ist nämlich keine Eigenschaft des UI, sondern des Konfigurationsspeichers.
Marc 'Zugschlus' Haber on :
Deine Argumentation setzt voraus, dass das Format, in dem das GUI seine Daten abspeichert, dokumentiert ist. Und das ist es nur in den allerseltensten Fällen. Und wenn es um kritische Applikationen geht, ist die Benutzung nicht dokumentierter Schnittstellen natürlich völlig außer Diskussion.
Über die Probleme, eine Konfigurationsdatei einmal per GUI und dann wieder per Editor zu bearbeiten (und die Vorteile eines TUI weiterhin nutzen zu wollen), habe ich noch einen Artikel in der Queue.
flawed on :
Nö, für den Vergleich von Konfigurationen ("was ist anders?") muss das Format nicht unbedingt dokumentiert sein. Die Unterschiede sieht man auch so. Im Gegenteil sind Konfigurationsvergleiche ein probates Mittel, um Format und Semantik von Konfigurationsdateien zu reverseengineeren.
Marc 'Zugschlus' Haber on :
Und warum muss man Reverse Engineeren? Weil der einzige dokumentierte Weg eben ein GUI ist. Und das ist ein Nachteil des GUIs.