… die auf Elektra aufsetzen. Das entscheidet imho über die Verbreitung / den Erfolg. Wie stehen denn die Anwendungsentwickler oder Unternehmen wie Red Hat, Suse oder Canonical zu Elektra? Deutet sich aus dieser Richtung schon ein Einsatz von Elektra ab?
Das Projekt ist jetzt über 10 Jahre alt und hat bisher keine größere Verbreitung gefunden. In keiner aktuellen, großen Distribution ist Elektra enthalten. Für Debian gibt es z.B. nur Pakete für "Jessie" und "SID".
Auch wenn Pro-Linux und der Entwickler nicht müde werden zu betonen wie toll das Projekt ist, will es anscheinend niemand benutzen. Und nein, es hilft der Verbreitung nicht weiter, wenn ein einzelner Admin es zur Speicherung seiner Konfigurationsdateien benutzt.
früher oder später wird es sich durchsetzen, weil es schlichtweg das bessere konzept ist anstatt das jede app seinen eigenen configparser zurechtfriemelt...
auf einem der letzten kde/plasma entwickler-treffen gabs da sogar einen kleinen vortrag zu...
dann endlich wird es endlich irgendwann einheitliche distroübergreifende grafische configtools alla yast geben mit denen man von a-z alles zurechtkonfigurieren kann, ohne das man jedesmal die sorge haben muss das die halbe distro aufgrund von fehlern zerschossen wird....
Wobei es auch da ja schon die beiden Quasi-Standards XML und JSON gibt, außerdem in gefühlt jeder Programmiersprache passende Libs, um mit diesen Dateien sinnvoll umzugehen... Heutzutage braucht man wirklich keine Configparser mehr selbst schreiben, wenn man nicht gerade eine (Pseudo-)Programmiersprache entwickelt...
Ich habe nichts gegen Elektra, es fällt mir "nur" etwas schwer zu verstehen, wo genau jetzt der Vorteil (aus Sicht eines Programmierers) daran liegt, dieses Framework zu benutzen.
Ein Programmierer hat da Vorteile, wo er den Konfigurationsstatus von anderen Anwendungen abfragen muss. Für die Configs seinr eigenen Programme hat es gegenüber XML und JSON keinen Vorteil, weil alle drei recht einfach per fertigem Parser oder API abgefragt werden können.
Aus Nutzersicht bietet Elektra eine einheitliche Konfigurationsschnittstelle, d.h. alles lässt sich darüber konfigurieren was Elektra nutzt und das ist schon ein sehr großer Vorteil.
Wobei es auch da ja schon die beiden Quasi-Standards XML und JSON gibt, außerdem in gefühlt jeder Programmiersprache passende Libs, um mit diesen Dateien sinnvoll umzugehen... Heutzutage braucht man wirklich keine Configparser mehr selbst schreiben, wenn man nicht gerade eine (Pseudo-)Programmiersprache entwickelt...
Es gibt noch viel mehr "Quasi-Standards" (YAML, TOML, ...). Elektra bietet den Vorteil, dass dem Benutzer die Wahlfreiheit nicht genommen wird, bzw. dass Distributionen "im Nachhinein" vereinheitlichen können.
Ich habe nichts gegen Elektra, es fällt mir "nur" etwas schwer zu verstehen, wo genau jetzt der Vorteil (aus Sicht eines Programmierers) daran liegt, dieses Framework zu benutzen.
Programmierer nehmen natürlich meistens das was in einem bereits verwendeten Framework mitgeliefert wird. Deswegen sind die Bemühungen von Elektra auch gleich bei diesen Frameworks anzusetzen (KDE, GNOME, ...).
Verwendet man noch kein Framework, bietet Elektra auch dem Programmierer Vorteile:
Code-Generierung: der Entwickler hat Code-Autocompletion und kann sich bei Config-Keys nicht vertippen
Validierungen mit guten Fehlermeldungen: der Entwickler muss nicht mit ifs alle Randfälle der Konfiguration beschreiben, sondern sagt deklarativ was erlaubt ist
Community: der Entwickler kann für viele Features auf fertige Plugins zurückgreifen (z.B. Notification: die Applikation bekommt sofort Updates wenn sich etwas geändert hat)
Portabilität: der Entwickler muss sich nicht für verschiedene Betriebsysteme überlegen von wo die Konfigurationsdateien gelesen werden sollen
Das Projekt ist jetzt über 10 Jahre alt und hat bisher keine größere Verbreitung gefunden. In keiner aktuellen, großen Distribution ist Elektra enthalten. Für Debian gibt es z.B. nur Pakete für "Jessie" und "SID".
Ja, leider ist der Debian Maintainer inaktiv. Im allgemeinen gibt es aber schon recht viele Pakete, teilweise sogar 0.9.0 obwohl es erst gerade eben veröffentlicht wurde. Siehe https://www.libelektra.org/docgettingstarted/installation
Auch wenn Pro-Linux und der Entwickler nicht müde werden zu betonen wie toll das Projekt ist, will es anscheinend niemand benutzen. Und nein, es hilft der Verbreitung nicht weiter, wenn ein einzelner Admin es zur Speicherung seiner Konfigurationsdateien benutzt.
Liegt vielleicht an den wenig eingängigen Bezeichnungen.
Vielleicht sollten sie ihre Datenbank "registry" und den Editor "regedit" nennen; dann ahnt jeder, was ihn erwartet, und die Begeisterung wird grenzenlos sein
Tatsächlich ist es so, dass Elektra früher linux-registry hieß und alle Daten in einem Backend waren. Mittlerweile hat Elektra aber nichts mehr damit zu tun, da keine binären Datenbanken mehr unterstützt werden. Sowohl der Support für berkleydb als auch der Support für die windows-registry wurden mit Elektra 0.7 entfernt. Der Fokus ist jetzt ganz klar auf modulare Textdateien: zumindest eine Konfigurationsdatei pro Applikation.
… die auf Elektra aufsetzen. Das entscheidet imho über die Verbreitung / den Erfolg. Wie stehen denn die Anwendungsentwickler oder Unternehmen wie Red Hat, Suse oder Canonical zu Elektra? Deutet sich aus dieser Richtung schon ein Einsatz von Elektra ab?
Das Projekt ist jetzt über 10 Jahre alt und hat bisher keine größere Verbreitung gefunden. In keiner aktuellen, großen Distribution ist Elektra enthalten. Für Debian gibt es z.B. nur Pakete für "Jessie" und "SID".
Auch wenn Pro-Linux und der Entwickler nicht müde werden zu betonen wie toll das Projekt ist, will es anscheinend niemand benutzen. Und nein, es hilft der Verbreitung nicht weiter, wenn ein einzelner Admin es zur Speicherung seiner Konfigurationsdateien benutzt.
Oder als kurze Antwort:
Nein, es deutet sich kein Einsatz an.
früher oder später wird es sich durchsetzen, weil es schlichtweg das bessere konzept ist anstatt das jede app seinen eigenen configparser zurechtfriemelt...
auf einem der letzten kde/plasma entwickler-treffen gabs da sogar einen kleinen vortrag zu...
dann endlich wird es endlich irgendwann einheitliche distroübergreifende grafische configtools alla yast geben mit denen man von a-z alles zurechtkonfigurieren kann, ohne das man jedesmal die sorge haben muss das die halbe distro aufgrund von fehlern zerschossen wird....
Wobei es auch da ja schon die beiden Quasi-Standards XML und JSON gibt, außerdem in gefühlt jeder Programmiersprache passende Libs, um mit diesen Dateien sinnvoll umzugehen... Heutzutage braucht man wirklich keine Configparser mehr selbst schreiben, wenn man nicht gerade eine (Pseudo-)Programmiersprache entwickelt...
Ich habe nichts gegen Elektra, es fällt mir "nur" etwas schwer zu verstehen, wo genau jetzt der Vorteil (aus Sicht eines Programmierers) daran liegt, dieses Framework zu benutzen.
Ein Programmierer hat da Vorteile, wo er den Konfigurationsstatus von anderen Anwendungen abfragen muss.
Für die Configs seinr eigenen Programme hat es gegenüber XML und JSON keinen Vorteil, weil alle drei recht einfach per fertigem Parser oder API abgefragt werden können.
Aus Nutzersicht bietet Elektra eine einheitliche Konfigurationsschnittstelle, d.h. alles lässt sich darüber konfigurieren was Elektra nutzt und das ist schon ein sehr großer Vorteil.
Es gibt noch viel mehr "Quasi-Standards" (YAML, TOML, ...). Elektra bietet den Vorteil, dass dem Benutzer die Wahlfreiheit nicht genommen wird, bzw. dass Distributionen "im Nachhinein" vereinheitlichen können.
Programmierer nehmen natürlich meistens das was in einem bereits verwendeten Framework mitgeliefert wird. Deswegen sind die Bemühungen von Elektra auch gleich bei diesen Frameworks anzusetzen (KDE, GNOME, ...).
Verwendet man noch kein Framework, bietet Elektra auch dem Programmierer Vorteile:
Ja, leider ist der Debian Maintainer inaktiv. Im allgemeinen gibt es aber schon recht viele Pakete, teilweise sogar 0.9.0 obwohl es erst gerade eben veröffentlicht wurde. Siehe https://www.libelektra.org/docgettingstarted/installation
Es sind schon mehrere Admins und vor allem auch FIrmen, siehe https://www.libelektra.org/docgettingstarted/goals (Punkt Target)
> Sorry, we could not render this website because JavaScript is required.
Dann eben nicht, so wichtig war mir die Information nicht …
Sorry, I could not render this website because JavaScript is required which is unsafe to run on an untrusted website—bye.
Wenn man noch weiter liest steht folgendes:
Liegt vielleicht an den wenig eingängigen Bezeichnungen.
Vielleicht sollten sie ihre Datenbank "registry" und den Editor "regedit" nennen; dann ahnt jeder, was ihn erwartet, und die Begeisterung wird grenzenlos sein
Tatsächlich ist es so, dass Elektra früher linux-registry hieß und alle Daten in einem Backend waren. Mittlerweile hat Elektra aber nichts mehr damit zu tun, da keine binären Datenbanken mehr unterstützt werden. Sowohl der Support für berkleydb als auch der Support für die windows-registry wurden mit Elektra 0.7 entfernt. Der Fokus ist jetzt ganz klar auf modulare Textdateien: zumindest eine Konfigurationsdatei pro Applikation.
meines wissens wurden bei diesem projekt nie binäre datenbanken genutzt.