Doch es ist Elektra offenbar bis heute nicht gelungen, eine größere Zahl von Projekten davon zu überzeugen, ihre bestehenden Konfigurationsmethoden zu ersetzen.
Wozu auch? Die gute alte Textdatei ist ja wohl die praktischste Konfigurationsmethode überhaupt: Mit jedem x-beliebigen Editor zu bearbeiten, einfach durchsuchbar, einfach zu sichern und wiederherzustellen, mittels Kommentaren einfach zu dokumentieren.
Dieser dconf/gconf-Mist, wo man sich irgendwelche Schlüssel zusammenreimen muss regt mich jedesmal auf, wenn ich was damit zu tun hab.
Sehe ich genauso. Ein System, mit dem sich normale Konfigurationsdateien leichter finden und ein bisschen bequemer verwalten lassen (Backup etc) wäre schon nützlich. Aber ein Ersatz für ein erstklassig funktionierendes System ist einfach Blödsinn.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Jul 2014 um 13:48.
Wozu auch? * einheitliche distro-/programm-übergreifende konfigurations-standards zur konfiguration (nicht jedes programm mit eigener config-syntax) * dadurch einfache möglichkeit zum bauen von einfachen grafischen config-tools alla yast welche distroübergreifend funktionieren. * Dadurch letztendlich mehr user-freundlichkeit auf dem Desktop und einfachere Automatisierung durch Standards.
via xml-anpassungen in cat/vim/sed/gawk ..... genauso einfache konfiguration wie heute
>> Mit jedem x-beliebigen Editor zu bearbeiten, einfach durchsuchbar, einfach zu sichern und wiederherzustellen, mittels Kommentaren einfach zu dokumentieren.
1. Uneinheitliche Syntax, jeder macht es anders 2. Vermischung von Konfiguration & Scripten 3. Schlechte Parsbarkeit, damit einhergehend schlechte Nutzungsmöglichkeit durch dritte Anwendungen und ein hoher Aufwand einen Parser zu schreiben 4. nicht intuitiv. Wer nachschauen will, welche Optionen es gibt, muss im Handbuch nachschlagen oder diese Auskennen. Sollten alle Optionen angegeben, aber auskommentiert sein, dann leidet die Übersichtlichkeit und die Geschwindigkeit beim auslesen. 5. Wegen 3 schlecht cachebar und im Betrieb aus Programmsicht schlecht verwaltbar, daher langsam beim Auslesen 6. Fehleranfällig, dies besteht sowohl in den Konfigurationsdateien selbst, wenn der Nutzer darin manuell herumeditiert, als auch durch die Parser unterschiedlicher Qualität und wenn die Syntax oder Optionen von der einen Version auf die andere geändert wird, muss oft alles neu angepasst werden, insbesondere auch schlecht geschriebene Parser.
Mit Elektra könnte man alle diese Nachteile auf einen Schlag lösen, denn:
1. Die Syntax ist einheitlich. 2. Es wird nur die Konfiguration gespeichert, dadurch sind die Scripte von der Konfiguration getrennt. Auf die Konfiguration wird einheitlich über die API von Elektra zugegriffen, braucht ein Programm also z.B. Informationen aus zwei völlig verschiedenen Orten, dann kann es einheitlich über die API auf die Informationen zugreifen und sich selbst um die Scripterrei bzw. Bedingte Ausführung kümmern. 3. Da die Syntax einheitlich ist, gibt es einen einheitlichen Parser, der direkt von Elektra zur Verfügung gestellt wird. Darüber können dann auch dritte Programme einheitlich zugreifen, sie müssen nur angeben was sie wollen, der Rest erledigt Elektra. 4. Es ist davon auszugehen, dass alle Keys gesetzt werden, damit sind alle Optionen verfügbar, was welcher Key macht, ist Aufgabe des Programms, dass sie nutzt. Da kann man das dann gut erklären. 5. Da alle Daten in einer einheitlichen Syntax vorliegen, kann man das ganze gut in einer Datenbank oder einem Cache ablegen. Der Zugriff ist dann dank Baumstrukur ebenfalls entsprechend schnell, insbesondere wenn dieser über einen organisierten Cache oder eine DBMS läuft. 6. Da die ganzen Keys per set und get Routinen einheitlich von allen Programmen gelesen werden können, sinkt die Fehleranfälligkeit deutlich.
7. Eine Fernwartung und Hilfe für DAUs ist nur schlecht durchführbar 8. Backups erfordern wesentlich mehr Pflege und Aufwand. Das gilt erst recht, wenn man sich bei einem Programm dazu entschließt die Art der Konfiguration wieder komplett umzustellen. Auch die Mischung zwischen Konfiguration & Script kann hier zum Problem werden
Mit Elektra:
7. man schickt dem DAU einfach ein Script, dass die entsprechenden get & set Aufrufe enthält und die Konfiguration richtig setzt. Der DAU führt es per einfachem Mausklick aus und schon ist die Konfiguration wieder richtig gesetzt, mehr muss er nicht tun. 8. Da alles einheitlich ist, sind auch Backups einfach.
So lange sich die Abhängigkeiten von dem Ding in grenzen halten und es sich den meisten Toolkits und Desktopumgebungen gegenüber neutral verhalt könnte ich damit leben. Und wenn es dann auch noch anständige Tools für die Administration gibt welche nicht nur im CLI Style daherkommen wäre es vermutlich gar nicht mal so schlecht.
> So lange sich die Abhängigkeiten von dem Ding in grenzen halten
Der Kern ist Ansi-C und der Kern ist die einzige Abhängigkeit mit der Applikationen leben müssen. Die ganze Funktionalität ist in den Plugins und diese sind optional.
> und es sich den meisten Toolkits und Desktopumgebungen gegenüber neutral verhalt
Ja, Elektra gehört nicht irgendeinem Toolkit oder Desktopumgebung an.
> könnte ich damit leben. Und wenn es dann auch noch anständige Tools für die Administration gibt welche nicht nur im CLI Style daherkommen wäre es vermutlich gar nicht mal so schlecht.
Eine qt-quick2 gui ist gerade in Entwicklung. Direkt Config Files bearbeiten geht natürlich auch noch.
> So lange sich die Abhängigkeiten von > dem Ding in grenzen halten
Das ist gerade ein Feature von denen. Minimierung der Anzahl der genutzten Libs, weil: Die wollen kein Bloatmonster erschaffen. Auch deswegen ist das Teil kein Deamon sondern nur eine Lib.
----
Ansonsten muss ich sagen, dass ich ja nicht so der Fan von dem XML-Schrott bin. Zu viel Metadaten aussenrum.
So ein verschachtelter Hash im LUA-Style oder auch so wie die ISC DHPCD Config, das ist für Notadministration per vi wesentlich angenehmer.
Ansonsten finde ich Elektra seit Anfang an ziehmlich cool - Ein Sysadmin muss das ja auch cool finden!
> Das ist gerade ein Feature von denen. Minimierung der Anzahl der genutzten Libs, weil: Die wollen kein Bloatmonster > erschaffen. Auch deswegen ist das Teil kein Deamon sondern nur eine Lib.
Exakt!
> Ansonsten muss ich sagen, dass ich ja nicht so der Fan von dem XML-Schrott bin. Zu viel Metadaten aussenrum.
Bei Elektra steht jedem frei XML zu nutzen oder nicht. Stattdessen kann json verwendet werden, oder eben Konfigurationsdateien wie Sie gerade sind (bzw. eines davon). Es wird bei Elektra keine Syntax aufgezwungen. (Weder bei persistenten Dateien noch bei import/export)
> So ein verschachtelter Hash im LUA-Style oder auch so wie die ISC DHPCD Config, das ist für Notadministration per vi wesentlich angenehmer.
Welchen LUA-Style meinst du? Elektra unterstützt bereits einen TCL-Stlye also { key= value { .. } } und Lua als Binding (und bald auch für Plugins).
> Ansonsten finde ich Elektra seit Anfang an ziehmlich cool - Ein Sysadmin muss das ja auch cool finden!
> Das ist gerade ein Feature von denen. Minimierung der Anzahl der genutzten Libs, weil: Die wollen kein Bloatmonster > erschaffen. Auch deswegen ist das Teil kein Deamon sondern nur eine Lib.
Exakt!
> Ansonsten muss ich sagen, dass ich ja nicht so der Fan von dem XML-Schrott bin. Zu viel Metadaten aussenrum.
Bei Elektra steht jedem frei XML zu nutzen oder nicht. Stattdessen kann json verwendet werden, oder eben Konfigurationsdateien wie Sie gerade sind (bzw. eines davon). Es wird bei Elektra keine Syntax aufgezwungen. (Weder bei persistenten Dateien noch bei import/export)
> So ein verschachtelter Hash im LUA-Style oder auch so wie die ISC DHPCD Config, das ist für Notadministration per vi wesentlich angenehmer.
Welchen LUA-Style meinst du? Elektra unterstützt bereits einen TCL-Stlye also { key= value { .. } } und Lua als Binding (und bald auch für Plugins).
> Ansonsten finde ich Elektra seit Anfang an ziehmlich cool - Ein Sysadmin muss das ja auch cool finden!
Dieser dconf/gconf-Mist, wo man sich irgendwelche Schlüssel zusammenreimen muss regt mich jedesmal auf, wenn ich was damit zu tun hab.
Sehe ich genauso.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Jul 2014 um 13:48.Ein System, mit dem sich normale Konfigurationsdateien leichter finden und ein bisschen bequemer verwalten lassen (Backup etc) wäre schon nützlich. Aber ein Ersatz für ein erstklassig funktionierendes System ist einfach Blödsinn.
Elektra verwendet ja genau konventionelle Konfigurationsdateien. Das Auffinden von Config files geht für application mit
$ kdb file user/sw/application
und backup geht mit
$ kdb export user > backup
Genau. Deine Hinweise zeigen schön die Crux: Man muss wieder irgendwelche Befehle dafür im Kopf haben, oder nachsehen.
Stimmt! vi, sed, grep, awk, tr, xmllint, usw. sind VIEL einfacher zu bedienen !!^^
> Genau. Deine Hinweise zeigen schön die Crux: Man muss wieder irgendwelche Befehle dafür im Kopf haben, oder nachsehen.
In der qt-gui ist es natürlich auch möglich zu klicken.
Und erst diese ganzen tollen Varianten, für jedes Programm eine eigene Konfigurationssprache lernen... so wird das Konfigurieren nie langweilig.
Wozu auch?
* einheitliche distro-/programm-übergreifende konfigurations-standards zur konfiguration (nicht jedes programm mit eigener config-syntax)
* dadurch einfache möglichkeit zum bauen von einfachen grafischen config-tools alla yast welche distroübergreifend funktionieren.
* Dadurch letztendlich mehr user-freundlichkeit auf dem Desktop und einfachere Automatisierung durch Standards.
via xml-anpassungen in cat/vim/sed/gawk ..... genauso einfache konfiguration wie heute
>> Mit jedem x-beliebigen Editor zu bearbeiten, einfach durchsuchbar, einfach zu sichern und wiederherzustellen, mittels Kommentaren einfach zu dokumentieren.
Daran würde sich nichts ändern (s. Dokus)
Die klassische Textdatei hat folgende Probleme:
1. Uneinheitliche Syntax, jeder macht es anders
2. Vermischung von Konfiguration & Scripten
3. Schlechte Parsbarkeit, damit einhergehend schlechte Nutzungsmöglichkeit durch dritte Anwendungen und ein hoher Aufwand einen Parser zu schreiben
4. nicht intuitiv. Wer nachschauen will, welche Optionen es gibt, muss im Handbuch nachschlagen oder diese Auskennen. Sollten alle Optionen angegeben, aber auskommentiert sein, dann leidet die Übersichtlichkeit und die Geschwindigkeit beim auslesen.
5. Wegen 3 schlecht cachebar und im Betrieb aus Programmsicht schlecht verwaltbar, daher langsam beim Auslesen
6. Fehleranfällig, dies besteht sowohl in den Konfigurationsdateien selbst, wenn der Nutzer darin manuell herumeditiert, als auch durch die Parser unterschiedlicher Qualität und wenn die Syntax oder Optionen von der einen Version auf die andere geändert wird, muss oft alles neu angepasst werden, insbesondere auch schlecht geschriebene Parser.
Mit Elektra könnte man alle diese Nachteile auf einen Schlag lösen, denn:
1. Die Syntax ist einheitlich.
2. Es wird nur die Konfiguration gespeichert, dadurch sind die Scripte von der Konfiguration getrennt. Auf die Konfiguration wird einheitlich über die API von Elektra zugegriffen, braucht ein Programm also z.B. Informationen aus zwei völlig verschiedenen Orten, dann kann es einheitlich über die API auf die Informationen zugreifen und sich selbst um die Scripterrei bzw. Bedingte Ausführung kümmern.
3. Da die Syntax einheitlich ist, gibt es einen einheitlichen Parser, der direkt von Elektra zur Verfügung gestellt wird. Darüber können dann auch dritte Programme einheitlich zugreifen, sie müssen nur angeben was sie wollen, der Rest erledigt Elektra.
4. Es ist davon auszugehen, dass alle Keys gesetzt werden, damit sind alle Optionen verfügbar, was welcher Key macht, ist Aufgabe des Programms, dass sie nutzt. Da kann man das dann gut erklären.
5. Da alle Daten in einer einheitlichen Syntax vorliegen, kann man das ganze gut in einer Datenbank oder einem Cache ablegen. Der Zugriff ist dann dank Baumstrukur ebenfalls entsprechend schnell, insbesondere wenn dieser über einen organisierten Cache oder eine DBMS läuft.
6. Da die ganzen Keys per set und get Routinen einheitlich von allen Programmen gelesen werden können, sinkt die Fehleranfälligkeit deutlich.
Ein paar Punkte habe ich noch vergessen:
Klassische Textdatei:
7. Eine Fernwartung und Hilfe für DAUs ist nur schlecht durchführbar
8. Backups erfordern wesentlich mehr Pflege und Aufwand. Das gilt erst recht, wenn man sich bei einem Programm dazu entschließt die Art der Konfiguration wieder komplett umzustellen. Auch die Mischung zwischen Konfiguration & Script kann hier zum Problem werden
Mit Elektra:
7. man schickt dem DAU einfach ein Script, dass die entsprechenden get & set Aufrufe enthält und die Konfiguration richtig setzt. Der DAU führt es per einfachem Mausklick aus und schon ist die Konfiguration wieder richtig gesetzt, mehr muss er nicht tun.
8. Da alles einheitlich ist, sind auch Backups einfach.
DAU ist kein Synonym für Anfänger/Hilfesuchender/Nicht-Voll-Super-Profi-Experte
Ja sorry, ich war schreibfaul. Aber ich denke jeder versteht es, wie das mit DAU gemeint war.
So lange sich die Abhängigkeiten von dem Ding in grenzen halten und es sich den meisten Toolkits und Desktopumgebungen gegenüber neutral verhalt könnte ich damit leben. Und wenn es dann auch noch anständige Tools für die Administration gibt welche nicht nur im CLI Style daherkommen wäre es vermutlich gar nicht mal so schlecht.
> So lange sich die Abhängigkeiten von dem Ding in grenzen halten
Der Kern ist Ansi-C und der Kern ist die einzige Abhängigkeit mit der Applikationen leben müssen. Die ganze Funktionalität ist in den Plugins und diese sind optional.
> und es sich den meisten Toolkits und Desktopumgebungen gegenüber neutral verhalt
Ja, Elektra gehört nicht irgendeinem Toolkit oder Desktopumgebung an.
> könnte ich damit leben. Und wenn es dann auch noch anständige Tools für die Administration gibt welche nicht nur im CLI Style daherkommen wäre es vermutlich gar nicht mal so schlecht.
Eine qt-quick2 gui ist gerade in Entwicklung. Direkt Config Files bearbeiten geht natürlich auch noch.
> So lange sich die Abhängigkeiten von
> dem Ding in grenzen halten
Das ist gerade ein Feature von denen. Minimierung der Anzahl der genutzten Libs, weil: Die wollen kein Bloatmonster erschaffen. Auch deswegen ist das Teil kein Deamon sondern nur eine Lib.
----
Ansonsten muss ich sagen, dass ich ja nicht so der Fan von dem XML-Schrott bin. Zu viel Metadaten aussenrum.
So ein verschachtelter Hash im LUA-Style oder auch so wie die ISC DHPCD Config, das ist für Notadministration per vi wesentlich angenehmer.
Ansonsten finde ich Elektra seit Anfang an ziehmlich cool - Ein Sysadmin muss das ja auch cool finden!
> Das ist gerade ein Feature von denen. Minimierung der Anzahl der genutzten Libs, weil: Die wollen kein Bloatmonster
> erschaffen. Auch deswegen ist das Teil kein Deamon sondern nur eine Lib.
Exakt!
> Ansonsten muss ich sagen, dass ich ja nicht so der Fan von dem XML-Schrott bin. Zu viel Metadaten aussenrum.
Bei Elektra steht jedem frei XML zu nutzen oder nicht. Stattdessen kann json verwendet werden, oder eben Konfigurationsdateien wie Sie gerade sind (bzw. eines davon). Es wird bei Elektra keine Syntax aufgezwungen. (Weder bei persistenten Dateien noch bei import/export)
> So ein verschachtelter Hash im LUA-Style oder auch so wie die ISC DHPCD Config, das ist für Notadministration per vi wesentlich angenehmer.
Welchen LUA-Style meinst du? Elektra unterstützt bereits einen TCL-Stlye also { key= value { .. } } und Lua als Binding (und bald auch für Plugins).
> Ansonsten finde ich Elektra seit Anfang an ziehmlich cool - Ein Sysadmin muss das ja auch cool finden!
Danke.
> Das ist gerade ein Feature von denen. Minimierung der Anzahl der genutzten Libs, weil: Die wollen kein Bloatmonster
> erschaffen. Auch deswegen ist das Teil kein Deamon sondern nur eine Lib.
Exakt!
> Ansonsten muss ich sagen, dass ich ja nicht so der Fan von dem XML-Schrott bin. Zu viel Metadaten aussenrum.
Bei Elektra steht jedem frei XML zu nutzen oder nicht. Stattdessen kann json verwendet werden, oder eben Konfigurationsdateien wie Sie gerade sind (bzw. eines davon). Es wird bei Elektra keine Syntax aufgezwungen. (Weder bei persistenten Dateien noch bei import/export)
> So ein verschachtelter Hash im LUA-Style oder auch so wie die ISC DHPCD Config, das ist für Notadministration per vi wesentlich angenehmer.
Welchen LUA-Style meinst du? Elektra unterstützt bereits einen TCL-Stlye also { key= value { .. } } und Lua als Binding (und bald auch für Plugins).
> Ansonsten finde ich Elektra seit Anfang an ziehmlich cool - Ein Sysadmin muss das ja auch cool finden!
Danke.