Re: [Dbian 2.2r3] System-Administration
Moin Stefan!
Stefan Nobis schrieb am Mittwoch, den 20. Juni 2001:
> 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
Warum werde ich das Gefühl nicht los, du hast noch nie etwas derartiges
zuverlässig implementiert? Was du da von dir ablässt, errinert an den
Spruch aus meiner Signatur-DB:
---
"Programmieren ist kalter Kaffee" (aus einer PC-Zeitschrift)
> 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.
Wo bist du eigentlich die letzten 10 Jahre gewesen? Abgesehen von z.B.
sendmail-Konfiguration (ohne Hilfsmittel) wirst du bei den meisten MTAs
mehr oder weniger sinnvoll organisierte Konfigurationsdateien finden,
mit recht aussagekräftigen Variablennamen. Beispiel: Exim, Debians
Default-MTA.
> Rein theoretisch wäre es völlig unproblematisch, für alle Software ein
> einheitliches Dateiformat mit einheitlicher Syntax für ihre
Aha...
> Konfigurationsdateien festzuschreiben. Gut, jede Software braucht eigene
> Befehle, aber auch hier kann man viel standardisieren, gleiche Begriffe auch
Blödsinn. Du kannst nur allgemeine Dinge standardisieren (und diese
werden durch sehr ähnliche {exim,sendmail}conf-Skripte abgefragt).
> 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.
Mag sein. Der Trend geht aber schon in diese Richtung:
gemeinsamme Konfig-Parser, Options-Parser usw. sind nicht selten.
> 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.
Nennt sich z.B. Debconf. Da werden bekannte Sachen abgefragt,
abgespeichert, und die Config-Dateien ggf. neugeneriert.
> Da wird grundsätzlich erstmal nichts abstrahiert, da wird nicht versteckt oder
> weggelassen, da wird nur übersetzt. Punkt.
Die Probleme entstehen da, wo du von dem allgemeinen Sachen in Details
gehst. Da musst du das Fein-Tunning direkt in der Konfigurationsdatei
vornehmen. Und was macht deine UI mit diesen Änderungen? Richtig, das
alte zast-Problem.
> 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.
Webmin macht das im Prinzip nicht viel anders. Das Problem muss man halt
an der Wurzel packen, nur ist es halt nicht einfach realisierbar.
Theoretisch muss man für jede einzelne, per UI und per Config-File
konfigurierbare Option eine kleine KI entwerfen, die die Funktionsweise
des Programms analysiert und guckt, welche Optionen sinnvoll sind, bzw.
welche sich mit den neuen Optionen schneiden. Und dazu noch ein
neuralles Interface, mit dem du die Wünsche direkt übermittelst. Und
dann noch mehr KI, die für dich das Denken ganz übernimmt, usw.
Man kann das natürlich anders machen, bunte und scheinbar hilfsbereite
Konfig-Frontends bauen (wie es heute oft üblich ist), Scheisse
schönreden, aber das ist keine wirkliche Lösung.
> 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
Nochmal: es geht hier nicht über braindead-designte Konfig-Syntaxen,
diese geraten schnell in Vergessenheit, oder werden mit Prä-Prozessoren
verwaltet (siehe Sendmail), sondern um die Idee an 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).
KI.
> 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.
Was hast du nur für ein Problem mit den Konfig-Dateien? Falls
orientieren sich nach dem Muster
VAR = WERT
oder
VAR WERT
und die Kommentarzeichen sind i.d.R. #, oder (selten) ;%". Ggf. kommen
noch [SEKTIONEN] dazu, aber das ist oft selbsterklärend.
> 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.
Wie funktioniert das intern? Speichert er die unbekannten Variablen, und
fügt sich dann in seine generierte Datei ein? Funktioniert das
zuverlässig? Ich glaube das nicht so ganz.
> 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.
Wenn die mögliche Variablenmenge in der Config-Datei gering ist, die
Variablen eindeutig (keine Überschneidung der Funktion u.ä.), kannst du
es im Frontend einfach so präsentieren, ein GUI-Element für jede
Variable, ggf. mit Hilfe garniert. Aber auch nur dann.
> 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.
Dann würde man sich ins eigene Fleisch schneiden, früher oder später.
> Derzeit ist das Konfigurations-UI für jedes Programm unterschiedlich. Und das
> ist völlig unnötig.
Quatsch. Willst du mit Icepref die Benutzer anlegen, oder mit dselect
Enlightement konfigurieren?
> Und komm mir jetzt nicht mit dummen Sprüchen wie "aber die Programme sind doch
> so unterschiedlich, da braucht es unterschiedliche Syntax in den
Syntax nicht, aber total unterschiedliche Konzepte.
> Es wäre grundsätzlich problemlos möglich, für all die Programme ein
> einheitliches Konfigurations-UI zu bauen.
Quatsch. Mach doch mal.
> Und ja, ein solches UI würde dann auch Einsteigern den Einstieg
> i.d.R. erleichtern.
Nimm Windows/Mac, oder wo deine Traumwelt auch sein mag, und sei
glücklich damit, und stell die Ansprüche an deren Entwickler, wenn dir
was nicht passt. Oder mach es besser, aber du weisst auch nicht wie.
> > 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
Du vergleichst schon wieder Äpfel mit Birnen.
> 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.
Dann nimm doch den Mac. Warum werden den nicht mal halb so viele Macs
verkauft wie PCs? Wieso kehren Firmen nach und nach Windows den Rücken,
und nehmen die "ach so komplizierten" Unixe? Weil Mac und Windows sich
dank Kosmetik und Täuschung gut verkauft haben, aber nicht wirklich gut
sind.
> > Welche?
>
> Angefangen bei der Treiberinstallation (hier macht sich dann doch Linus
> Beharren auf den Verzicht von Binärschnittstellen für Treiber negativ
Es gibt binäre Schnittstellen, diese sind aber nicht zwischen den
grösseren Kernel-Generationen kompatibel. Aber das ist technisch nicht
möglich, genauso wie die Windows-3.x-Treiber kaum unter neuen
Wind~1-Versionen funktionieren werden. Oder sie schrotten Wind~1
komplett, was dir mit einem falschen Modul normallerweise nicht
passieren wird (es wird abgelehnt).
> > ...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.
Es geht nicht um die pauschale Ablehnung, sondern schlicht um die
Erfüllbarkeit deiner Anforderungen. Sie ist so noch lange nicht gegeben.
MfG,
Eduard.
--
Das wahrlich arnoootische daran ist, das wahrscheinlich _alle_
Regulars diesem Thread absolut faziniert folgen, nur traut sich keiner
was zu sagen, weil man die beiden ja offiziell im Killfile hat.
Alexander Stielau in de.alt.arnooo
--
-----------------------------------------------------------
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: