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 [EMAIL PROTECTED] die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: [EMAIL PROTECTED]
-----------------------------------------------------------
837 eingetragene Mitglieder in dieser Liste.
