XML dient der Strukturierung hierarchischer Daten. Von meinen Config-Files sind die wenigsten echt hierarchisch, es gibt höchstens mal einzelne Sections, ev. noch Subsections, was aber oft mehr der Übersichtlichkeit dient als einer echten Hierarchie entspricht. XML ist ausserdem nicht richtig Human-readable und v.a. nicht Human-writable, die Gefahr, dass man sich vertippt ist gross. Ausserdem muss man die jeweilige DTD des gerade zu editierenden Files kennen.

Das Windows-INI-Format hingegen hat diese Nachteile nicht, es bietet im Gegenteil alles notwendige für 99% aller Fälle:

• Strukturierung durch Sections
• Kommentare
• einfach zu parsen (sogar in PHP gibt es eine Funktion dafür)
• auch für Menschen les- und schreibbar

Hätte nie im Leben gedacht, dass ich mal für INI-Files lobbyieren würde...

Die mit C machbaren XML API sind einfach grottig. Wie bequem XML sein kann, erschliesst sich hingegen mit API wie dem von MSXML oder .NET (ja, schmäme mich schon Microsoft zu loben, aber deren XML APIs sind hervorragend):
XmlDocument xml = new XmlDocument();
xml.Load("foobar.xml");
string xpath = "//blah[@id>13][@xml:lang='de']/xyz";
foreach(XmlNode node in Xml.SelectNodes(xpath))
SomeThing(node["title"]);

Das ist doch nun wirklich einfacher, als jeder hangwichste Parser, jedes Bison-Gewusel. Über Spielchen wie XML serialization, bei dem per XML Datenstrukturen menschenlesbar! (im Vergleich zu binary serialization) gebannt werden will ich hier erst gar nicht eingehen. Nett mir, was es euch Kostet so etwas ohne XML zum implementieren. Aus meiner Erfahrung muss ich sagen: Wenn ordentliche API und moderne Programmiersprachen zum Einsatz kommen, erfüllt XML sein Versprechen als Universalparser umfassend. Ich persönlich habe mittlerweile etliche von mir genutze Dateiformate auf XML umgestellt. Lines of code sind immer drastisch gesunken (so ab Faktor fünf). Spätere Spracherweiterungen waren Kinderkram.

Tschuldigung. Dies mag jetzt arrogant klingen. Ist es vielleich auch: Aber wer noch nicht mal XML packt, sollte um Himmelswillen die Hände von Compilern und anderen Verbrechen lassen. Vor allen sollten diese Typen bitte aufhören, Ihre Unfähigkeit hinter FUD zu verstecken.

Blödsinn. XML ist auch in C einfach zu parsen. Das Problem liegt woanders:

In der UNIX-Welt ist punkto Konfiguration der Texteditoren-Ansatz verbreitet. Man hat ein Konfigfile, welches von Hand editiert wird. Mittlerweile ist auch der Doppelansatz verbreitet: Handeditierbares Konfigfile plus Konfig-GUI.

Das Problem mit XML ist, das es sehr einfach von Programmen gelesen und generiert werden kann, Das lesen und schreiben von Hand jedoch recht mühsam ist. Zum einen, weil XML prinzipiell alles hierarchisch speichert, der Mensch aber flache Strukturen gewohnt ist. Zum anderen, weil XML sehr strenge Regeln hat, von denen auch Profis nicht immer alle kennen, und die zum Teil für Konfigurationsdateien schlicht keinen Sinn machen.

Als Beispiel nenne ich mal Ogle, ein netter DVD-Player für Linux. Als ich eine Weile das DVD-Laufwerk nicht, wie üblich, auf "/dev/dvd" hatte, wollte ich das im Konfigfile entsprechend ändern. Als ich aber den Eintrag suchte, blickte ich bei der Struktur nicht durch, obwohl ich durchaus in XML bewandert bin. Schliesslich machte ich einfach ein Suchen und Ersetzen auf /dev/dvd.

--
If it's GNU/Linux, it's GNU/BSD, too ;-)

Wenn man zum Beispiel unter XFree86 das Antialiasing von Zeichensätzen mit einer Größe von mehr als 8 und weniger als 15 Punkten abschalten will, sieht das in XML so aus:

<match target="font">
 <test qual="any" name="size" compare="more">
  <int>8</int>
 </test>
 <test qual="any" name="size" compare="less">
  <int>15</int>
 </test>
 <edit name="antialias" mode="assign">
  <bool>false</bool>
 </edit>
</match>

Diese Lösung ist meiner Meinung nach ziemlich hirnrissig. Mit einer Skriptsprache könnte man das einfacher lösen:

(if (and (> font-size 8) (< font-size 15))
 (set! font-anti-alias #f))

Ich schätze es sehr, dass ich den Emacs vollkommen frei mit Emacs Lisp konfigurieren kann. Vor allem mit Blick auf Geräte, die häufig in verschiedenen Netzen betrieben werden, ist eine flexible Konfigurationsmöglichkeit sinnvoll. Mit einer vernünftigen Skriptsprache kann man zum Beispiel problemlos bildschirm- oder netzwerkabhängige Einstellungen vornehmen:

(cond
 ((< display-width 1024) ...)
 ((string=? "foo.bar.com" (system-name)) ...))

Der einzige Vorteil von XML-Dateien, den ich sehen kann, ist, dass man sie in einem speziellen Editor bearbeiten und mit Hilfe einer DTD oder eines Schemas auf Korrektheit überprüfen kann.

Falsch. Unbedarfte Benutzer können trotzdem eine Oberfläche verwenden, um ein Programm zu konfigurieren. Der Emacs speichert die über die grafische Oberfläche vorgenommenen Einstellungen zum Beispiel in einer bestimmten Sektion in der .emacs. Die vom Benutzer selbst programmierten Teile der Datei bleiben davon unberührt:

; Settings written by user
(cond
 ((string=? "foo.com" (system-name))
  (setq user-mail-address "andreas@foo.com"))
 ((string=? "bar.net" (system-name))
  (setq user-mail-address "andreas@bar.net")))

; Settings stored by Emacs
(custom-set-faces
 '(diary-face ((t :foreground "CornflowerBlue")))))

Summe: eine Konfig soll doch etwas einstellen, nämlich einen Wert für eine Funktion, [...] aber sie laufen bei den klassischen Files meist auf "key value" oder "key=value" hinaus [...]

Klassische Konfigurationsdateien muss man bei Geräten, die häufig in verschiedenen Netzwerken betrieben werden, aber ständig ändern oder umkopieren. Das kann man zwar mit einem Skript machen, aber dann muss man eine oder sogar mehrere Konfigurationsdateien und ein Skript schreiben. Ich ziehe es vor, das in einer Datei zu machen.

Klassische Konfigurationsdateien, zum Beispiel die von Gnome, haben häufig auch den Nachteil, dass Pfadnamen häufig nicht unter Verwendung von $USER und $HOME bzw. ~, sondern mit absoluten Pfadnamen wie /home/andreas/.gnome/sucks gespeichert werden, so dass man die Konfigurationsdateien nicht einfach nach /etc/skel oder in ein anderes Benutzerverzeichnis umkopieren kann. Probleme gibt es durch die absoluten Pfadnamen ausserdem, wenn man ein gewachsenes, heterogenes Netz, in dem die Heimverzeichnisse an verschiedenen Stellen liegen, betreibt. Mit einer richtigen Programmiersprache als Konfigurationssprache könnte man diese Probleme ohne größeren Aufwand lösen.

Vom Komfortaspekt mag ich dir recht geben, aber der Sicherheitsmensch in mir sagt, dass Konfiguration und Skript möglichst sauber getrennt bleiben sollten^[1]. Skriptsprachen sind für Konfigurationsarbeiten im allgemeinen "zu mächtig". Damit bieten sie die Möglichkeit, vom Nutzer unerwünschte Funktionen (Viren / Würmer / Trojaner) in Konfigurationsdateien zu verstecken. Nicht vergessen: Makroviren wurden in Word unter anderem darum zum Problem, weil die Makrosprache sehr mächtig ist. Der zweite Hauptauslöser war die Möglichkeit, beim Programmstart vom Benutzer unbemerkt ein Makro starten zu können, was mit programmierbaren Konfigurationsdateien vergleichbar ist.

Klassische Konfigurationsdateien, zum Beispiel die von Gnome, haben häufig auch den Nachteil, dass Pfadnamen häufig nicht unter Verwendung von $USER und $HOME bzw. ~, sondern mit absoluten Pfadnamen wie /home/andreas/.gnome/sucks gespeichert werden

Wie du selbst schreibst ist es ein Problem der absoluten Pfadnamen, lässt sich also in den meisten Fällen mit relativen Pfadnamen umgehen.

[1] Spezialfälle wie Init-Skripte mal aussen vor.

--
If it's GNU/Linux, it's GNU/BSD, too ;-)

Diese Möglichkeit besteht im Falle von Dateien wie .bashrc und .xsession aber sowieso schon. Wenn man dieses Konzept ausweitet, ändert sich an der (Un-)Sicherheit des Systems nichts wesentliches.

Vollkommene Sicherheit vor der von Dir beschriebenen Angriffsmöglichkeit könnte man, so wie ich das sehe, nur erreichen, wenn einem Benutzer selbst keine einzige ausführbare Datei gehören düfte; ein Angreifer also priviligierten Zugriff erhalten müsste, um ausführbare Dateien manipulieren zu können. Sinnvoller ist es wohl, dafür zu sorgen, dass Dateien die aus unsicheren Quellen kommen, "gefährliche" Kommandos nicht ausführen dürfen.

Ummm.... Das ist dieselbe Argumentation, wie sie von den als-root-arbeitern, unter-windows-keinen-virenscanner-benutern, standardpasswort-belassern usw. verwendet wird: "Das System ist eh nicht völlig sicher, warum sich also nicht?"

Nur weil eine Sicherheitsschwachstelle besteht, heisst dass noch lange nicht, dass man sie fahrlässig ausweiten muss, oder? ;-)

--
If it's GNU/Linux, it's GNU/BSD, too ;-)

Dass Benutzer ausführbare Dateien wie die .bashrc besitzen können, ist keine Schwachstelle, sondern eine notwendige Designentscheidung.

Du setzt bei der Sicherheit meiner Meinung nach an der vollkommen falschen Stelle an. Anstatt Benutzer einzuschränken, muss man dafür sorgen, dass Angriffsversuche - die sich nie vermeiden lassen - erkannt werden und die Auswirkungen auf das Gesamtsystem bei einem Einbruch gering bleiben. Ich halte es zum Beispiel für sinnvoll Download- und E-Mail-Filter, die verhindern, dass ausführbare Programme aus unsicheren Quellen auf einen Rechner gelangen können, einzusetzen.

Mir ist weiterhin kein Fall bekannt, in dem .bashrc oder .emacs Dateien manipuliert wurden. Es scheint nun mal nicht so zu sein, dass Benutzer über das Netz versandte Konfigurationsdateien ohne Begutachtung übernehmen. Du konstruierst hier ein Sicherheitsproblem, dass in der Praxis von geringer Bedeutung zu sein scheint.

Ummm.... Das ist dieselbe Argumentation, wie sie von den als-root-arbeitern, unter-windows-keinen-virenscanner-benutern, standardpasswort-belassern usw. verwendet wird: "Das System ist eh nicht völlig sicher, warum sich also nicht?"

Das ist doch Quatsch. Du scheinst davon auszugehen, dass immer und überall mit dem dümmsten anzunehmenden Benutzer zu rechnen ist, den man vor sich selbst schützen muss. Das ist aber nicht der Normalfall. Die meisten Benutzer sind sehr wohl in der Lage verantwortlich mit Ihrem Computer umzugehen.

Ich denke, dass man hier eine Analogie zum Strassenverkehr ziehen kann. Obwohl alle Verkehrsteilnehmer irgendwann gelernt haben, wie man sich im Strassenverkehr zu verhalten hat, lassen sich Unfälle nicht vermeiden, weil ein vollkommen sicheres System nicht praktikabel wäre. Durch Ausbildung und das Ansetzen an den richtigen Stellen, lässt sich das Unfallrisiko aber verringern.

.bashrc ist ein Angriffsziel erster Güte, und steht bei mir aus gutem Grund auf der Tripwire-Liste. Ebenso wie alle anderen ausführbaren Konfigrationsdateien auch.

"Auf dem Weg ist eh kein Angriff zu erwarten" und "Der Benutzer ist nicht so dumm, sich hier falsch zu verhalten" Sind zwei Sätze, die ich so oder ähnlich immer wieder mal höre. Man könnte sie auch als "berühmte letzte Worte des Sysadmins" umschreiben, denn sie sind ein klarer Verstoss gegen jeweils ein Prinzip der Sicherheitstechnik: "Angriffe sind immer da zu erwarten, wo eine Schwachstelle ist" und "Der Benutzer macht immer Fehler". Darum besteht ein wesentlicher Teil jedes Sicherheitskonzept darin, denn Benutzer zu schulen, aber auch, seinen Spielraum genau so weit zu fassen, dass er nicht behindert wird, dass aber seine Fehler gleichzeitig möglichst wenig Schaden anrichten.

PS: Die wenigsten Benützer können wirklich mit ihren Computern umgehen. Wen dem anders wäre, hätten Mailwürmer niemals die heutige Verbreitung.

PPS: Dein Vergleich mit dem Strassenverkehr zieht nicht. Anzahl und Folgen der Strassenunfälle sind IMHO inakzeptabel.

--
If it's GNU/Linux, it's GNU/BSD, too ;-)

Da ist wohl jemand frustriert darüber, dass er Emacs nicht bedienen/konfigurieren kann...

Was soll diese sinnlose Lisp, Emacs und Emacs-User "gebashe"?

Ich persönlich habe viel lieber eine Konfigdatei in Bash, Lisp oder von der Art wie sie logrotate und xinetd benutzen, als bloated XML, wie z.B. httpd.conf von Apache.