Eduard Bloch <[EMAIL PROTECTED]> writes:
> > 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
Sorry, du hast mich falsch verstanden. Das "runterschreiben" war bezogen auf
einen wirklich simplen MTA, ohne gro�e Extras, ohne gro�artige Fehlertoleranz
etc. Es sollte nur unterstreichen, dass sich jemand wirklich gut mit einem
Problembereich auskennt, ohne sich mit den Details z.B. der sendmail.cf
auskennen zu m�ssen. Eben weil die Arbeitsweise einer Software v�llig
unabh�ngig von der Syntax ihrer Konfigurationsdatei ist -- sonst k�nnte man ja
z.B. f�r exim nicht eine v�llig andere Syntax als f�r sendmail w�hlen.
Und wenn die Syntax und der Aufbau der Konfigurationsdatei eben nicht fest an
an ein Programm und seine Arbeitsweise gekoppelt ist, dann kann ich auch eine
andere Syntax w�hlen -- also ist es prinzipiell m�glich, allen Programmen
dieselbe Konfigurationsdatei-Syntax vorzusetzen oder eben umgekehrt einen
Adapter zu benutzen, der eine Syntax in eine andere umsetzt (und da praktisch
alle Konfigurationsdateien aus regul�ren Sprachen aufgebaut sind, kann eine
solche Umsetzung sogar effizient implementiert und in linearer Zeit
durchgef�hrt werden).
Wenn du bis hierhin zustimmen konnest, musst du auch zustimmen, dass es v�llig
egal ist, ob ich eine Konfigurations in einer Textdatei vornehme, indem ich
dort ein Wort reinschreibe, oder ob ich in einem Browser eine Checkbox
anklicke. Und das war einer der Punkte, der bestritten wurde.
> 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.
sendmail.cf diente mir ja auch nur als Extrembeispiel. Mit einem Tool wie
Webmin kann man halt auch bei Exim und Co noch einiges gewinnen.
> Mag sein. Der Trend geht aber schon in diese Richtung:
> gemeinsamme Konfig-Parser, Options-Parser usw. sind nicht selten.
Richtig, sowas meine ich. Langsam merken die Leute, dass es schlicht
hirnverbrannt ist, f�r jedes neue Programm, die Lieblingssyntax des Tages zu
benutzen. Und diesen Trend kann man durchaus noch verst�rken. Und ob man eine
Vereinheitlichung nun auf unterster Ebene durch einheitliche Konfig-Syntax
erreicht oder durch einen Adaper a la Webmin, ist doch eher nebens�chlich. Und
genau darauf wollte ich hinaus.
> > 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.
Nein, das will ich ja gerade nicht! Webmin integriert sich transparent ins
System, d.h. da werden keine Dateien generiert und damit werden auch keine von
Hand gemachten �nderungen und/oder Kommentare gel�scht. Es sollen auch nicht
ein paar Dinge abgefragt werden, sondern wirklich alle verf�gbaren
Einstellungen eines Programms sollen auch voll unterst�tzt werden. Stell dir
sowas wie (X)Emacs/AucTeX angepasst f�r jede Konfigurationsdatei vor, dann
wei�t du, was ich gerne h�tte.
> 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
Was f�r eine KI? V�lliger Unsinn. Du musst einfach nur f�r jedes Programm ein
Modul haben, dass dann halt den Aufbau der Konfigurationsdatei kennst, sie
lesen kann (daf�r nimmt man im schlimmsten Fall denselben Parser, den auch das
jeweilige Programm benutzt) und halt Kommentare nicht ersatzlos streicht,
sondern beibeh�lt. Das ist kein Kunstst�ck und nichts imens kompliziertes,
denn es wird beim Einlesen dasselbe gemacht, was auch das Programm selbst
machen w�rde -- dazu dann ein kleines Interface, um die aktuellen
Konfigurationen zu pr�sentieren und modifizierbar zu machen und alles wieder
wegschreiben. Siehe z.B. auch SWAT -- das Ding merkt sich allerdings die
urspr�nglichen Inhalte und vor allem die vorhandenen Kommentare nicht, aber
das einzubauen ist nahezu trivial.
> Was hast du nur f�r ein Problem mit den Konfig-Dateien? Falls
Was findet ihr an Textdateien so geil, dass ihr alles andere verteufelt?
> > 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.
Wieso? Was ist der Unterschied zu den Textdateien? Da kann ich mir ja auch ins
eigene Fleisch schneiden.
> > 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
Falsch! Es gibt keine bin�re Treiberschnittstelle in Linux. Ein Treiber, der
f�r Linux-2.2.1 kompliert wurde, wird nicht mit Linux-2.2.2 oder Linux-2.2.0
laufen, selbst wenn sich am entsprechenden Teil des Kernel nicht mal ein
einziges Bit ver�ndert hat. Es gibt nur reine Sourcecode-Schnittstellen f�r
Treiber, ein Treiber muss immer f�r exakt den Kernel compiliert sein, mit dem
er zusammenarbeiten soll. Selbst ein Treiber f�r 2.2.2 arbeitet unter
Umst�nden nicht mit einem Kernel 2.2.2 zusammen, selbst wenn alle n�tigen
sonstigen Optionen richtig gesetzt sind.
Und genau dieses Problem ist kein Zufall oder ein Bug, sondern ein Feature,
sprich von Linus (und vielen anderen) *gewollt*.
--
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]
-----------------------------------------------------------
832 eingetragene Mitglieder in dieser Liste.