Guido Hennecke <[EMAIL PROTECTED]> writes:
> > aber es ist v�llig �berfl�ssig, sich mit nebens�chlich Syntaxdetails
> > irgendwelcher Konfigurationsdateien und Programmparameter rumzu�rgern.
>
> Anstatt sich also mit der Software, die man letztendlich einsetzen und
> demnach genau kennen muss, auseinander zu setzen, soll man sich also mit
Moment! Ich sehe schon einen gewaltigen Unterschied zwischen der Arbeits- und
Funktionsweise z.B. eines MTAs und den Details seiner Konfigurationsdatei. Ich
kann die grundlegende Arbeitsweise von MTAs inkl. aller RFCs und der typischen
Probleme ausw�ndig kennen und mal eben einen simplen MTA an einem Nachmittag
runterschreiben k�nnen und ebenso die genauen Probleme, Schwierigkeiten und
St�rken eines ganz speziellen MTAs den ich einsetze bis ins letzte Detail
kennen, ohne dass ich mich zwangsl�ufig mit den Details der
Konfigurationsdatei und ihrer Syntax auseinandersetzen muss. Die Arbeitsweise
eines Programms ist doch v�llig unabh�ngig von der Art und Weise, wie ich
diese Arbeitsweise mittels Konfigurations beeinflusse. Schlie�lich gibt es
sehr viele verschiedene MTAs und die haben alle v�llig unterschiedliche
Konfigurationsdateien, die v�llig unterschiedliche Syntax haben, also ist eben
Arbeitsweise und Konfigurationsdatei unabh�ngig voneinander.
Was ich nun will, ist ein einheitliches UI zur Konfiguration, damit Herr Admin
sich eben auf das eigentliche Problem, n�mlich die Arbeitsweise der Programme
und deren Steuerung/Festlegung, konzentrieren kann und sich eben nicht mit
irgendwelchen v�llig unwichtigen und l�sten Syntaxproblemen einzelner
Konfigurationsdateien rumschlagen muss.
Rein theoretisch w�re es v�llig unproblematisch, f�r alle Software ein
einheitliches Dateiformat mit einheitlicher Syntax f�r ihre
Konfigurationsdateien festzuschreiben. Gut, jede Software braucht eigene
Befehle, aber auch hier kann man viel standardisieren, gleiche Begriffe auch
gleich nennen, Schreibweisen und vieles mehr vereinheitlichen. Praktisch
scheitert dies daran, dass jeder Programmierer sich eine neue Coolheits-Syntax
der Stunde ausdenkt und die dann bei Bedarf auch noch von Programmversion zu
Programmversion �ndert, weil er halt gerade eine andere Konfigurationssyntax
f�r obercool h�lt. Genau das unterstreicht doch die Beliebigkeit der Syntax
einer Konfigurationsdatei. Und genau das nervt mich.
Ich will also nichts anderes, als eine Adaptionsschicht, so dass mir f�r meine
Arbeit eine koh�rente und �bersichtiche Syntax bzw. ein �bersichtliches UI
geboten wird, die dann von der Adaptionsschicht in die konkrete Syntax der
Wahl der jeweiligen Programme umgesetzt wird.
Da wird grunds�tzlich erstmal nichts abstrahiert, da wird nicht versteckt oder
weggelassen, da wird nur �bersetzt. Punkt.
Ein Tool, dass diesen Anspr�chen voll gerecht wird, gibt es zur Zeit noch
nicht. Aber es gibt Ans�tze und die sind durchaus vielversprechend und gehen
zumindest grob in die oben von mir skizzierte Richtung, wie z.B. Webmin.
Und eine solche Adaptionsschicht, sollte es sie denn mal wirklich vollst�ndig
geben, w�re ganz sicher eine Hilfe und ein Effizienzgewinn, da man sich eben
nicht mehr mit den unterschiedlichsten Syntaxen rumschlagen muss, sondern sich
auf die eigentliche Aufgabe, der Besch�ftigung mit den Programmen selbst und
ihrer Kontrolle, konzentrieren kann und weniger im Grunde unwichtiges
Nebenwissen ben�tigt (Syntax der Konfigdateien).
> den Eigenheiten, Fehlern und Sonderregeln eines Tools auseinander
> setzen, welches mit der eigentlichen Aufgabe der Software garnichts zu
> tun hat?
Toll -- stattdessen schlage ich mich bei jedem einzelnen Programm mit den
Fehler und Sonderregeln der jeweiligen Konfigurationsdatei rum, die f�r jedes
Programm anders ist und ebenfalls nichts mit der eigentlichen Aufgabe der
Software zu tun hat.
> an Windows. Genau das will _ich_ jedenfalls nicht. Genau das kotzt mich
> an YaST an! Enweder Du machst alles mit YaST oder _garnichts_ (oder Du
Yast ist hier kein Ma�stab. Webmin z.B. st�rt es nicht im geringsten, wenn man
auch mal von Hand in den Dateien st�bert, dann wieder mit Webmin was
einstellt, dann wieder von Hand per Texteditor usw.
Ich sehe es als selbstverst�ndlich an, dass sich ein solches Tool, wie ich es
beschreibe, sich v�llig transparent ins System einf�gt. Genauso sollte es
keine Kommentare l�schen etc.
[Vorkonfiguration mit Tool]
> Damit erhalte ich ein Geruest und mache den Rest dann per Hand und mit
> Hilfe der Doku und netten Menschen, die mir bei verstaendnisproblemen
> immer wieder auf die Spruenge geholfen haben.
Ja aber das ist doch gar nicht der Punkt. Worauf ich hinauswill, ist, dass es
v�llig schei�egal ist, ob ich f�r eine gew�nschte Einstellung in Webmin eine
Checkbox anklicke oder ob ich in eine Textdatei "blafasel" reinschreibe.
Ich will keine Abstraktion, kein Tool, dass mich einschr�nkt und nur einen
Teil von Einstellungen erm�glicht, ich will nicht wie eximconfig, dass mir ein
paar Fragen stellt und daraus eine Standardkonfiguration erzeugt. Ich will
vollen Zugriff auf alle Einstellm�glichkeiten.
Nur will ich diesen Zugriff so, dass ich micht nicht mit den unterschiedlichen
Details der jeweiligen Konfigurationsdateien rumschlagen muss. Bei cron muss
ich die Zeiten in der /etc/crontab recht eigenwillig eingeben -- mit einem
guten UI m�sste ich mich nicht mit diesen Syntaxdetails abplagen, ich k�nnte
die Zeiten spielend z.B. in einem Kalender und einer Uhr anklicken. Bei diesem
Beispiel ist der Gewinn sicher klein, aber durchaus erkennbar -- kaum ein
Unix-Admin hat wirklich Probleme mit der crontab-Syntax, das ist richtig. Aber
warum? Er hat sich diese krude Syntax seit Jahren eingebl�ut. Und das m�sste
halt nicht sein.
Derzeit ist das Konfigurations-UI f�r jedes Programm unterschiedlich. Und das
ist v�llig unn�tig.
Und komm mir jetzt nicht mit dummen Spr�chen wie "aber die Programme sind doch
so unterschiedlich, da braucht es unterschiedliche Syntax in den
Konfig-Dateien". Wenn das so stimmen w�rde, wieso kann man dann ach so
unterschiedliche Programme alle in einer Programmiersprache schreiben?
Es w�re grunds�tzlich problemlos m�glich, f�r all die Programme ein
einheitliches Konfigurations-UI zu bauen.
Und ja, ein solches UI w�rde dann auch Einsteigern den Einstieg
i.d.R. erleichtern.
> Aber ich halte eben nichts davon, allem und jedem eine GUI oder ein
> unnoetiges Frontend aufzudruecken, welches nur den Eindruck erweckt,
> etwas zu erleichtern und in Wahrheit dieses Versprechen nicht halten
> kann.
>
> Sie dir SuSE an, sieh dir YaST und SuSEConfig an!
Tooles Argument. Sieh dir OE an. Und weil OE schlecht ist, sind dann alle
Mailprogramme schlecht? Nein? Also sind nicht alle Admin-Tools schlecht, nur
weil der Schrott, den SuSE hier verbrochen hat, schlecht ist.
> Du kannst nicht eine UI bauen, die einheitlich ist und fuer voellig
> unterschiedliche Aufgaben brauchbar und effizient nutzbar ist.
Doch. Siehe real existierende GUIs. Da hat man sehr einheitliche UIs,
teilweise (vor allem Mac) sehr umfassende Style-Guides und dennoch werden
damit h�chst unterschiedliche Anwendungen umgesetzt, von Textverarbeitung �ber
Interneteinwahl bis CAD. Und die Vorteile, die solche Style-Guide bieten,
k�nnen dir etliche Firmen sicher sogar in DM und Pf ausrechnen.
Das hei�t nat�rlich nicht, das GUIs alle Probleme l�sen oder es nicht
verbesserungsw�rdige Bereiche gibt, um mal so den gr�bsten Platit�den
vorzugreifen.
> > wenn man
> > �ber verschiedene Programme hinweg dieselben Dinge dieselben Namen bekommen
> > und dieselben Funktionen auch auf dieselbe Weise ausgel�st werden (Speichern,
> > �ffnen, Fachbegriffe,...).
>
> Das ist doch der Fall. Was meinst Du denn blos?
Das ist in den Konfigurationsdateien der unterschiedlichen Programme eben
gerade nicht der Fall. Siehe allein die Unterschiede innerhalb ein und
derselben Programmkategorie MTA, ganz zu schweigen von unterschiedlichen
Programmkategorien. DAS ist das Problem, das mich so sehr st�rt.
> > Es gibt Bereiche, da ist die Bedienung
> > grausig und sehr umst�ndlich (ich mal unter NT einen DHCP-Server eingerichtet,
> > mit festen, an die MAC gebundenen IPs -- das war grauenvoll). Aber genauso
> > gibt es Bereiche, in denen die Bedienung wirklich einfacher ist.
>
> Welche?
Angefangen bei der Treiberinstallation (hier macht sich dann doch Linus
Beharren auf den Verzicht von Bin�rschnittstellen f�r Treiber negativ
bemerkbar) �ber die Benutzerrechte (OK, bei NT noch nicht der Renner, 2000
kenne ich nicht so gut, aber daf�r Novells NDS) bis hin zu einigen Details,
die mir jetzt leider nicht mehr einfallen (sorry, ich sitze halt nur sehr,
sehr selten vor einem NT-Rechner).
> > Genauso wie Mausbedienung durchaus auch mal Vorteile gegen�ber reiner
> > Tastaturbedienung hat.
>
> Bei einer Grafischen Anwendung, ja (damit meine ich nicht, dass man fuer
> eine Textbasierte Anwendung wie Email oder Konfiguration, eine GUI
> baut!).
Mal abgesehen davon, dass (G)UIs auch bei Textverarbeitung Vorteile bieten
(ich greife bei LaTeX-Texten -- und ich mache praktisch alles mit LaTeX --
regelm��ig zum Men� von XEmacs/AucTeX, weil ich zwar wei�, welchen Befehl ich
haben will, mir aber gerade der genaue Name oder die exakte Schreibweise nicht
mehr einf�llt und hier ist der Weg zum Men� schneller, als das Nachlesen in
einer Online- oder Offline-Doku), kann man auch andere Dinge wie
z.B. Dateiverwaltung in Bereichen durchaus schneller mit der Maus bzw. einem
guten Text-UI wie bei mc erledigen als per Kommandozeile, z.B. wenn du viele
einzelne Dateien l�schen willst, deren Namen sich eben nicht durch RegExps
ausdr�cken lassen. Mit etwas gutem Willen und Phantasie lassen sich problemlos
weitere Beispiele finden. Das hei�t nat�rlich nicht, dass man alles mit
Maus/GUI besser erledigen kann, sondern nur, dass es eben auch Arbeiten gibt,
die man halt tats�chlich besser mit Maus/GUI erledigen kann.
> Da finde ich eine Plain Text Datei, in der ich eine Suche machen kann
> und dann an _genau die richtige Stelle_ zu kommen, irgendwie leichter.
Man kann nat�rlich immer Einzelbeispiele konstruieren, in der die eine oder
andere Arbeitsweise ineffizienter ist als eine andere. Deshalb soll sich das
Tool ja auch transparent ins System einbetten, dann kann man n�mlich w�hlen
und im Einzefall den Weg nehmen, der am schnellsten zum Ziel zu f�hren
verspricht.
> > Die Bedienung eines Autos ist auch
> > ziemlich simpel
>
> Dann frage ich mich, warum so viele Unfaelle passieren, warum die
> Ausbildung so lange dauert. Warum sagen die nicht einfach, wo Gas und
> Bremse sind und erklaeren kurz mal eben die Verkehrsregeln?
Dann schau die Unf�lle mal an. Da haben Leute Situationen falsch
eingesch�tzt. Fehlbedienungen des Autos (Verwechseln von Bremse und Gas z.B.)
sind so gut wie nie Ausl�ser oder Ursache von Unf�llen. Eher Ablenkung, zu
riskante Fahrweise, �berh�hte Geschwindigkeit etc. -- das sind aber keine
Bedienungsfehler.
Du setzt hier Bedienung und Situationseinsch�tzung/Hintergrundwissen/Umsicht
gleich.
> > -- trotzdem brauche ich einen F�hrerschein, um mit dem Auto
> > keine Schei�e im Stra�enverkehr zu bauen.
>
> Und um mit dem Auto _umgehen_ zu koennen.
Richtig. Aber das hat nichts mit den Bedienelementen des Autos zu tun. Gas
geben, anfahren ist nicht ganz simpel, aber nach sehr kurzer Zeit erlernt. Das
ist die grundlegende Bedienung. Das dauert vielleicht 1-2 Fahrstunden. Danach
kommt das richtige Verhalten im Stra�enverkehr, das hat mit der Bedienung des
Autos an sich nichts mehr zu tun. Das ist der Unterschied.
Und bei der Konfiguration von Programmen ist das genauso. Nat�rlich muss ich
Arbeits- und Funktionsweise der Programme kennen, aber das ist unabh�ngig von
der Bedienung sprich Syntax der Konfigurationsdateien.
> > Hingegen ist die Bedienung von Sendmail mittels sendmail.cf nicht sonderlich
> > einfach,
>
> Bringe bitte nicht staendig Admin und User durcheinander.
Ich spreche hier immer nur von der Adminstrationsseite. Funktionsweise von
Sendmail ist eine Sache, die f�r den Admin wichtig ist, Konfiguration eine
andere. Und die Konfiguration ist bei einigen Programmen unn�tig kryptisch und
kompliziert, Beispiel sendmail.cf. Und das st�rt mich gewaltig. Und da k�nnen
Tools wie Webmin helfen. Man kann n�mlich sendmail genauso detailiert wie
durch die sendmail.cf konfigurieren, ohne die unn�tig komplizierte und
kryptische Syntax der sendmail.cf benutzen zu m�ssen -- das meine ich mit der
Bedienung von sendmail (durch den Administrator).
> > und genau hier ist NT in *einigen* (nicht allen) Bereichen
> > durchaus besser,
> ...genau da bin ich voellig anderer Meinung und ich halte es fuer
> gefaehrlich und suboptimal, hier nach Anregungen zu suchen.
Ich halte f�r ignorant und gef�hrlich, irgendetwas pauschal abzulehnen. Von
Vorurteilen und Engstrinigkeit mal ganz abgesehen.
--
Until the next mail...,
Stefan.
--
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an [EMAIL PROTECTED] die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: [EMAIL PROTECTED]
-----------------------------------------------------------
837 eingetragene Mitglieder in dieser Liste.
