Login
Newsletter
Werbung

Thema: Elektra 0.8.7 erschienen

18 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Gott Seidank am Mi, 30. Juli 2014 um 12:35 #

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.

[
| Versenden | Drucken ]
  • 0
    Von zettberlin am Mi, 30. Juli 2014 um 13:48 #

    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.
    [
    | Versenden | Drucken ]
    • 0
      Von markus2330 am Mi, 30. Juli 2014 um 17:28 #

      Elektra verwendet ja genau konventionelle Konfigurationsdateien. Das Auffinden von Config files geht für application mit

      $ kdb file user/sw/application

      [
      | Versenden | Drucken ]
      • 0
        Von markus2330 am Mi, 30. Juli 2014 um 18:20 #

        und backup geht mit

        $ kdb export user > backup

        [
        | Versenden | Drucken ]
        • 0
          Von Gott Seidank am Do, 31. Juli 2014 um 11:39 #

          Genau. Deine Hinweise zeigen schön die Crux: Man muss wieder irgendwelche Befehle dafür im Kopf haben, oder nachsehen.

          [
          | Versenden | Drucken ]
          • 0
            Von ich am Do, 31. Juli 2014 um 12:20 #

            Stimmt! vi, sed, grep, awk, tr, xmllint, usw. sind VIEL einfacher zu bedienen !!^^

            [
            | Versenden | Drucken ]
            0
            Von markus2330 am Do, 31. Juli 2014 um 13:40 #

            > 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.

            [
            | Versenden | Drucken ]
    0
    Von ich am Mi, 30. Juli 2014 um 16:53 #

    Und erst diese ganzen tollen Varianten, für jedes Programm eine eigene Konfigurationssprache lernen... so wird das Konfigurieren nie langweilig.

    [
    | Versenden | Drucken ]
    0
    Von Andre am Mi, 30. Juli 2014 um 18:51 #

    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)

    [
    | Versenden | Drucken ]
    0
    Von Herzlos am Mi, 30. Juli 2014 um 20:48 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von Herzlos am Mi, 30. Juli 2014 um 20:57 #

      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.

      [
      | Versenden | Drucken ]
      • 0
        Von kamome umidori am Do, 31. Juli 2014 um 22:18 #

        DAU ist kein Synonym für Anfänger/Hilfesuchender/Nicht-Voll-Super-Profi-Experte

        [
        | Versenden | Drucken ]
        • 0
          Von Herzlos am Fr, 1. August 2014 um 05:43 #

          Ja sorry, ich war schreibfaul. Aber ich denke jeder versteht es, wie das mit DAU gemeint war.

          [
          | Versenden | Drucken ]
0
Von schmidicom am Do, 31. Juli 2014 um 11:10 #

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.

[
| Versenden | Drucken ]
  • 1
    Von markus2330 am Do, 31. Juli 2014 um 11:55 #

    > 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.

    [
    | Versenden | Drucken ]
    • 0
      Von fx919 am Do, 31. Juli 2014 um 22:11 #

      > 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!

      [
      | Versenden | Drucken ]
      • 0
        Von markus2330 am Fr, 1. August 2014 um 10:45 #

        > 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.

        [
        | Versenden | Drucken ]
        0
        Von markus2330 am Fr, 1. August 2014 um 10:45 #

        > 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.

        [
        | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung