[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Dbian 2.2r3] System-Administration



Guido Hennecke <g.hennecke@t-online.de> 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 debian-user-de-request@lehmanns.de die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@Lehmanns.de
-----------------------------------------------------------

837 eingetragene Mitglieder in dieser Liste.


Reply to: