Gut oder Schlecht... liegt bei dem der es benutzt ob Programm oder User ^_^ ...wäre zumindest eine Vereinheitlichung und ein versuch es jeden recht zum machen. Das kann zwar nie funktionieren... wünsche dem Projekt aber trotzdem viel Glück zumindest ein paar davon überzeugen zu können
Man sieht es ja bei Windows, man hat eine Registry mit Configs, man hat mehrere Configordner, das eine Programm schreibt dort rein das andere woanders. Beim Deinstallieren bleiben alte Registryeinträge erhalten und müllen die Registry zu und nachher weiß keiner was weg kann und was nicht. Warum muss man alles nachäffen, dann kann ich auch Windows installieren. Mich stört schon das man auch bei Linux die alten Configs selber löschen muss, auch da gibt es mehrere Orte wo jeder irgendwas hinschreibt. Nur her mit der Registry, eine Powershell wäre auch noch schön *kopfschüttel über die Innovationskraft von Linuxentwicklern*. Wir könnten ja Windows Reverseengineeren und dann umschreiben und Winlux nennen.
Das ist eine sehr einseitige Betrachtung. Es wunder mich immer wieder, dass manche annehmen das die 300'000'000 Linux User Weltweit das System alle genau gleich Nutzen. Linux' sträke ist seine wandelbarkeit.
Eine Registry hat viel positives. So ab 50 PC's aufwärts ist es schön für einen Administrator wenn es eine Registry gibt, auf die man von überall Zugreiffen kann. Da hat GConf einen guten Ansatz gefunden.
So ab 50 PC's aufwärts ist es schön für einen Administrator wenn es eine Registry gibt, auf die man von überall Zugreiffen kann. Da hat GConf einen guten Ansatz gefunden.
Wir haben hier mehrer tausend Clients & Server. Ich wüßte nicht wofür ich als Administrator eine Registry bräuchte.
Ausgereifter, robuster einheitlicher Parser, du sagst der Registry verarbeitenden Lib nur, welcher Key geändert werden soll und die macht das für dich. Das Auswerten, ändern und lesen von Datenwerten wird damit zum Kinderspiel. Aus der zentralisierten einfachen Verwaltung ergeben sich dann auch Synergieeffekte, weil die Programme, bei denen man sich die Arbeit fürs Parser schreiben bisher sparte, nun per einfache Codeerweiterung zentrale Datenwerte nutzen und auslesen können und nun z.B. Desktopeinstellungen berücksichtigen, die ihnen wegen des Aufwands "komplizierten aufwendigen Parser schreiben" vorher scheiß egal waren. Der Gesamteindruck das ein System vermittelt, führt damit zu einer "das wirkt alles wie aus einem Guss" Erfahrung.
Dazu braucht man keine Registry. Und um alles Zentral zu halten, reicht auch ein Verzeichnis. Und wennich die xorg Einstellungen lesen will, dann halt die xorg.conf auslesen, bzw. den aktuellen Namen. Und nein, Registry hilft auch nicht bei andernder Configbezeichnung (wie bei xorg, da gibts ja auch verschiedene Strukturen).
Von Nicht gelesen? am Di, 10. Juni 2014 um 08:52 #
dann halt die xorg.conf auslesen
Genau darum geht es doch, man möchte eben nicht die xorg.conf auslesen. Man möchte an die Werte kommen ohne einen extra Parser schreiben zu müssen. Besser noch, man möchte bei einer Änderung auch möglichst noch darüber informiert werden. Was böte sich da mehr an, als eine Art Registry. Ob das nun Registry oder Bernhard heißt und ob das intern XML, Binärgedöns oder sonstwas ist, ist völlig Wurscht.
Von Penguin Pusher am Di, 10. Juni 2014 um 14:01 #
Genau darum geht es doch, man möchte eben nicht die xorg.conf auslesen. Man möchte an die Werte kommen ohne einen extra Parser schreiben zu müssen.
Hä? Da kommst du doch problemlos heran. Wozu brauche ich dafür eine Art Registry, die mir das Ganze mit XML-Tags oder als Binarygedöns unleserlich macht?
Nur mal als Beispiel: Hast du dir schon einmal die Konfigurationsdatein xorg.conf, smb.conf und sources.list angesehen und diese verglichen?
Ich sage dir, für alle drei müsstest du schon 3 verschiedene Parser schreiben wenn du darin automatisiert oder durch GUI Tools Werte lesen und verändern möchtest, denn alle drei haben eine völlig unterschiedliche Syntax. Mit einer Registry hättest du nur eine einzige Schnittstelle mit der du die Konfigurationsdaten aller 3 Programme lesen und verändern könntest.
Desweiteren gilt, die Anzahl der Fehler in einem Programm steigt mit der Anzahl der Programmzeilen. 3 Parser bedeuten also mehr Fehler. Nicht berücksichtigt haben wir dabei noch nicht einmal die Punkte, dass niemand außer einer handvoll Leute sich deine eigenen Parser ansehen werden und jeder andere, der diese Werte auch verändern will, mit hoher Wahrscheinlichkeit sich auch seine eigenen Parser schreiben wird, so wie du selbst, denn auf ein Lib als Schnittstelle die diese Aufgabe für dich übernimmt, auch Registry genannt, willst du ja nicht zurückgreifen.
Ihr habt mehrer 1000 PC's und du bist _der_ Administrator ? Sorry da stimmt doch was ned so ganz. Schon bei einer Firma mit 30 PC's gibt es meist mehrere Arbeitsgruppen mit unterschiedlichen Softwarekonfiguratinen und Hardwaresettings. Bei grösseren Firmen potensiert sich das ganze. Dann wird es ganz nett wenn ich gewisse Registry Settings definieren kann für verschiedene Gruppen und diese dann ausrollen kann nach bedarf. Klar gibt es viele Wege nach Rom. Hier reden wir aber von einem Konzept in einem Berreich wo es bis jetzt noch keines gibt unter Linux. Eine Abstraktionschicht zur zentralen und einheitlichen Verwaltung von Softwarekonfigurationen ist ein evolutionärer Schritt.
Von Penguin Pusher am Di, 10. Juni 2014 um 14:05 #
Sorry da stimmt doch was ned so ganz.
Ja, deine Lesekompetenz. Da steht ganz eindeutig WIR in meinem vorhergehenden Post.
Dann wird es ganz nett wenn ich gewisse Registry Settings definieren kann für verschiedene Gruppen und diese dann ausrollen kann nach bedarf. ... Hier reden wir aber von einem Konzept in einem Berreich wo es bis jetzt noch keines gibt unter Linux. Eine Abstraktionschicht zur zentralen und einheitlichen Verwaltung von Softwarekonfigurationen ist ein evolutionärer Schritt.
Sowas kann nur ein Windows-Administrator behaupten der kaum bis garkeine Erfahrung mit Linux, UNIX & Co hat.
Was glaubst du dann, wie wir den unsere ganzen Maschinchen adminstrieren? Es gibt genug Lösungen dafür. Einen Binary-BLOB ala Windows Registry brauchen wir dafür jedenfalls mit Sicherheit nicht.
Was glaubst du dann, wie wir den unsere ganzen Maschinchen adminstrieren? Es gibt genug Lösungen dafür.
Ich verwaltet deutlich weniger als 1000 Maschine und habe schon einige Probleme mit den gefühlt tauschend verschiedenen Konfigurationsvarianten. Jetzt mal bitte konkret werden, was für eine Lösung habt Ihr? Diese Lösung könnte dann auch mir uns interessant sein.
Es geht um ein einheitliches Konzept für Konfigurationen, welches "einfache" Distro-Übergreifende KonfigurationsTools wie z.B. Yast ermöglichen könnten. Und das ohne für jedes noch so kleine Programm einen eigenen Parser zu bauen.
Ist ja schön und gut, aber xml ist doch einfach zum Davonlaufen. Da gab es mal einen großen Hype drum und in der Zeit ist wohl Elektra auch enstanden. Inzwischen bewegen sich die meisten zum Glück wieder davon weg.
Naja, was will man auch mit einer Dateistruktur, die weder für Menschen noch für Computer sehr gut lesbar ist...
In meinen Augen ist es auch dieses Dateiformat (bzw. die Beschränkung auf dieses), welches es verhindern wird, dass sich Elektra durchsetzt. Wenn man hier etwas mehr Vielfalt bieten würde könnte die Abwärtskompatibilität für die Programme sichergestellt werden. Für die Schnittstelle wäre es ohnehin egal.
Ich glaube, das ist im Artikel missverständlich formuliert.
Zumindest früher war Elektra so konzipiert, dass quasi jeder Konfigurationseintrag eine eigene Datei war. D.h. dass der Baum dem Verzeichnis/Dateibaum entsprach.
Grund dafür war primär die Zielsetzung schon sehr früh im Bootprozess einsatzfähig zu sein, also wenn unter Umständen noch keine Bibliotheken zum Parsen verfügbar sind.
Das ist natürlich auch nicht für alle Szenarien brauchbar, aber mein letzter Kenntnisstand war, dass verschieden Speichermethoden für unterschiedliche Szenarien möglich waren
Ist ja schön und gut, aber xml ist doch einfach zum Davonlaufen. Da gab es mal einen großen Hype drum und in der Zeit ist wohl Elektra auch enstanden. Inzwischen bewegen sich die meisten zum Glück wieder davon weg.
XML wird immer noch benutzt, teilweise wird es zwar durch JSON ersetzt, aber im großen und ganzen ist XML sehr beliebt und keineswegs tot.
Naja, was will man auch mit einer Dateistruktur, die weder für Menschen noch für Computer sehr gut lesbar ist...
Ich hoffe du weißt, dass man für so sauber geordnete strukturierte einheitliche Daten wie es mit XML möglich ist, mit wenig Aufwand ordentliche GUI Oberflächen zur Konfiguration dieser XML Keys bauen kann und der Mensch sich daher gar nicht mehr in den Tiefen einer XML Datei verstricken muss.
Und für den Computer kann man aus diesen binäre Caches bauen oder diese in eine DB laden, dann ist auch der lesende Zugriff schnell und effizient.
"Inzwischen bewegen sich die meisten zum Glück wieder davon weg."
Das mag im Hobbyumfeld so sein, in der Industrie ist XML ungebrochen beliebt. Sicherlich ist es nicht perfekt, es ist aktuell jedoch der beste Kompromiss zwischen Mensch und Maschine.
Zudem gibt es einen riesigen Park an Programmen, welche die Nutzung stark vereinfachen.
"Wenn man hier etwas mehr Vielfalt bieten würde"
Klingt nach exakt dem, was so ein Projekt auf keinen Fall gebrauchen kann
Sicherlich ist es nicht das Ziel das nach der Deinstallation eines Programms irgendwelcher Daten Müll zurück bleibt. Wirft man von Zeit zu Zeit mal einen Blick in die beiden Ordner .local und .conf wird man auch da fündig !!
Ich denke das Projekte wie Elektra durchaus ein Schritt in die richtige Richtung seitens der allgemeinen Linux Usability ist. Solange sich alles zentral im eigenen /home/username untergebracht ist, spricht doch sicherlich nichts dagegen.
Anstatt dutzende config files welche zu dem noch über das ganze System verstreut sind händisch editieren zu müssen. Dieser fast schon 30 jährige andauernde KRAMPF gehört mit verlaub ins MUSEUM. Wer auf diese alt her gebrachte weise einen Linux Server administrieren MUß darf dies gerne tun. Aber auf den DESKTOP gehört mit verlaub etwas vernünftiges ! Denn Linux kann mehr, wenn man das richtige daraus macht. Und ich bin froh das sich einige Devels deren seit Jahrzehnten bekannten Linux typischen Unzulänglichkeiten bewusst sind und sich langsam in Richtung ANWENDER FREUNDLICHKEIT mal etwas tut.
Rechenleistung und Rechenpower bekommt man im Desktop Bereich für wenig Geld nach geworfen. Jedes 0-8-15 Handy kommt heute schon mit 1,8 Ghz CPU und 1 Gig Ram. Also weshalb soll man an einer vernünfigen DESKTOP Lösung sparen ?
Und wer von den Ewig - gestrigen schon mal versucht hat ein halbwegs für den Anwender benutzbares Linux auf alt Hardware (alte xp rechner) zu installieren wird feststellen das dank *PAE kernel* dieses Recycling Vorhaben wohl ein Traum bleiben wird *fg
Ich arbeite mit Windows und Linux und glaube daher zu wissen wovon ich schreibe. Thema Windows Reverseengineeren : Reactos ist das eindeutig das bessere OS !! http://www.reactos.de/
Korrektur und Nachtrag : Linux auf alt Hardware (alte xp rechner) zu installieren.....
In meinem Fall war dies ein Mainboard mit Intel Celeron 700 Mhz CPU und eine 20 Gigabyte IDE Platte. Auf eben diesem Uralt PC war zuvor Win XP installiert.
Das Müll in der Windows-Registry bleibt und alles in einem binären Blob gespeichert wird sind konzeptuelle Fehler die in Elektra nicht gemacht werden. Elektra setzt auf die alt-hergebrachten Konfigurationsdateien und erlaubt es somit Config-Dateien zu editieren und zu löschen. Also so gesehen ist es schon eine eigene Unix (Linux)-Lösung und nicht abgekupfert
Einfacher Zugriff um Konfigurationen zu ändern. Das zählt vor allem dort wo größere Systemlandschaften gepflegt werden und also nicht irgendwelche Parser. Alternative ist natürlich ganze Konfigdateien zu verteilen oder rudimentäre sed/awk Scripte zu schreiben. Elektra ist da weitaus flexibler und funktioniert out-of-the box. "kdb get", "kdb set" feetich. Das hilft SysAdmins und Softwareherstellern, die mit Ihren Produkten die Systemkonfiguration bearbeiten möchten.
Contra: XML-Dateien XML-Dateien per vi editieren ist nicht ganz so angenehm wie herkömmliche konfigs. Da würde ich mir lieber was menschenfreundlicheres wünschen. JSON, YAML, ...
Zum Thema Registry-Bloat:
Elektra kann sich über viele Dateien erstrecken. Die Apache Config könnte dann z. B. in /etc/apache/elektra.xml liegen. Wenn ein Paket dann gepurged wird(dpkg --purge) fliegen die Configs weg und demensprechend auch die Elektra-Config Teilbäume. Also IMHO: Nix Bloat.
---
Aber einfach mal ein bisschen rumliegen lassen. Wer weiss, ob die Zeit von Elektra kommen wird und wann.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Jun 2014 um 22:47.
Inwiefern ist den gerade JSON "menschenfreundlicheres"? Da habe ich eine deutlich andere Meinung zu... diese Klammerwüste ist nun wirklich nicht besser als XML. YAML allerdings ist ein nettes Format.
JSON ist nicht menschenfreundlicher, sondern nur kürzer. Die Vereinfachungen muss ein Mensch dann allerdings verstehen und richtig lesen und verstehen. Bei XML muss man gar nicht viel nachdenken, man muss nur wissen dass es Datenwerte gibt, die von Tags eingeschlossen werden, die wiederum der Name für den Key sind, falls keine Attributnamen verwendet werden, die es ebenfalls geben kann. Im großen und ganzen lässt sich XML auf ein Key vs. Value Schema runterbrechen und das zu verstehen sollte für jeden Menschen ein Kinderspiel sein, was XML sehr menschenfreundlich macht. Wenn etwas kaputt ist, dann wurden entweder Tags nicht richtig geschlossen oder der Keyname ist falsch, das merkt man als Mensch schnell. Bleibt also nur noch die Semantik übrig, die man wirklich wissen muss, aber das gilt für jede Art von Konfigurationsdatei und ist nicht auf XML beschränkt. JSON ist da wesentlich weniger intuitiv, weil noch die Klammerung zu beachten ist. Gewinnen tut dies nur durch weniger Schreibarbeit, aufgrund der schlechteren Intuitivität und geringfügig größeren Komplexität der Syntax steigt allerdings die Fehlerrate die ein Mensch verursachen kann. Wenn ein DAU einen Wert in einer Konfigurationsdatei verändern oder einfügen soll, dann wird er es mit XML auf alle Fälle leichter haben als mit JSON.
Hallo fork, genau, der standardisierte Zugriff ist ein zentrale Aspekt von Elektra.
Das mit XML ist im Artikel aber sehr unglücklich formuliert. Es ist so, dass Elektra (immer schon) eine key/value Datenstruktur verwendet, welche in jedes Konfigurationsformat abbildbar ist. xml ist eine möglichkeit (plugin xmltool), json eine andere (implementiert im Plugin yajl seit 0.8.4), ini wieder eine andere (plugins ni und simpleini) oder auch andere configdateien wie xorg.conf (plugin augeas). Die Diskussion welches Format am besten ist, wird mit Elektra einfach überflüssig und jeder Programmierer, Maintainer und Admin kann selbst entscheiden.
Cool, Elektra gibts wirklich noch
Gut oder Schlecht... liegt bei dem der es benutzt ob Programm oder User ^_^ ...wäre zumindest eine Vereinheitlichung und ein versuch es jeden recht zum machen. Das kann zwar nie funktionieren... wünsche dem Projekt aber trotzdem viel Glück zumindest ein paar davon überzeugen zu können
Man sieht es ja bei Windows, man hat eine Registry mit Configs, man hat mehrere Configordner, das eine Programm schreibt dort rein das andere woanders. Beim Deinstallieren bleiben alte Registryeinträge erhalten und müllen die Registry zu und nachher weiß keiner was weg kann und was nicht.
Warum muss man alles nachäffen, dann kann ich auch Windows installieren. Mich stört schon das man auch bei Linux die alten Configs selber löschen muss, auch da gibt es mehrere Orte wo jeder irgendwas hinschreibt.
Nur her mit der Registry, eine Powershell wäre auch noch schön *kopfschüttel über die Innovationskraft von Linuxentwicklern*.
Wir könnten ja Windows Reverseengineeren und dann umschreiben und Winlux nennen.
Wir könnten ja Windows Reverseengineeren und dann umschreiben und Winlux nennen.
Nee, das heisst anders: Reactos
Guckst du hier:
http://www.reactos.org/
Das ist eine sehr einseitige Betrachtung. Es wunder mich immer wieder, dass manche annehmen das die 300'000'000 Linux User Weltweit das System alle genau gleich Nutzen. Linux' sträke ist seine wandelbarkeit.
Eine Registry hat viel positives. So ab 50 PC's aufwärts ist es schön für einen Administrator wenn es eine Registry gibt, auf die man von überall Zugreiffen kann. Da hat GConf einen guten Ansatz gefunden.
Bei 50 PCs sollte man sich m.E. schon überlegen, übers Netzwerk zu booten (PXE)
Das wäre?
Wir haben hier mehrer tausend Clients & Server. Ich wüßte nicht wofür ich als Administrator eine Registry bräuchte.
Ausgereifter, robuster einheitlicher Parser, du sagst der Registry verarbeitenden Lib nur, welcher Key geändert werden soll und die macht das für dich.
Das Auswerten, ändern und lesen von Datenwerten wird damit zum Kinderspiel.
Aus der zentralisierten einfachen Verwaltung ergeben sich dann auch Synergieeffekte, weil die Programme, bei denen man sich die Arbeit fürs Parser schreiben bisher sparte, nun per einfache Codeerweiterung zentrale Datenwerte nutzen und auslesen können und nun z.B. Desktopeinstellungen berücksichtigen, die ihnen wegen des Aufwands "komplizierten aufwendigen Parser schreiben" vorher scheiß egal waren.
Der Gesamteindruck das ein System vermittelt, führt damit zu einer "das wirkt alles wie aus einem Guss" Erfahrung.
Dazu braucht man keine Registry.
Und um alles Zentral zu halten, reicht auch ein Verzeichnis. Und wennich die xorg Einstellungen lesen will, dann halt die xorg.conf auslesen, bzw. den aktuellen Namen.
Und nein, Registry hilft auch nicht bei andernder Configbezeichnung (wie bei xorg, da gibts ja auch verschiedene Strukturen).
Genau darum geht es doch, man möchte eben nicht die xorg.conf auslesen. Man möchte an die Werte kommen ohne einen extra Parser schreiben zu müssen. Besser noch, man möchte bei einer Änderung auch möglichst noch darüber informiert werden. Was böte sich da mehr an, als eine Art Registry. Ob das nun Registry oder Bernhard heißt und ob das intern XML, Binärgedöns oder sonstwas ist, ist völlig Wurscht.
Hä? Da kommst du doch problemlos heran. Wozu brauche ich dafür eine Art Registry, die mir das Ganze mit XML-Tags oder als Binarygedöns unleserlich macht?
Nur mal als Beispiel:
Hast du dir schon einmal die Konfigurationsdatein xorg.conf, smb.conf und sources.list angesehen und diese verglichen?
Ich sage dir, für alle drei müsstest du schon 3 verschiedene Parser schreiben wenn du darin automatisiert oder durch GUI Tools Werte lesen und verändern möchtest, denn alle drei haben eine völlig unterschiedliche Syntax.
Mit einer Registry hättest du nur eine einzige Schnittstelle mit der du die Konfigurationsdaten aller 3 Programme lesen und verändern könntest.
Desweiteren gilt, die Anzahl der Fehler in einem Programm steigt mit der Anzahl der Programmzeilen.
3 Parser bedeuten also mehr Fehler.
Nicht berücksichtigt haben wir dabei noch nicht einmal die Punkte, dass niemand außer einer handvoll Leute sich deine eigenen Parser ansehen werden und jeder andere, der diese Werte auch verändern will, mit hoher Wahrscheinlichkeit sich auch seine eigenen Parser schreiben wird, so wie du selbst, denn auf ein Lib als Schnittstelle die diese Aufgabe für dich übernimmt, auch Registry genannt, willst du ja nicht zurückgreifen.
Ihr habt mehrer 1000 PC's und du bist _der_ Administrator ? Sorry da stimmt doch was ned so ganz. Schon bei einer Firma mit 30 PC's gibt es meist mehrere Arbeitsgruppen mit unterschiedlichen Softwarekonfiguratinen und Hardwaresettings. Bei grösseren Firmen potensiert sich das ganze. Dann wird es ganz nett wenn ich gewisse Registry Settings definieren kann für verschiedene Gruppen und diese dann ausrollen kann nach bedarf. Klar gibt es viele Wege nach Rom. Hier reden wir aber von einem Konzept in einem Berreich wo es bis jetzt noch keines gibt unter Linux. Eine Abstraktionschicht zur zentralen und einheitlichen Verwaltung von Softwarekonfigurationen ist ein evolutionärer Schritt.
Ja, deine Lesekompetenz. Da steht ganz eindeutig WIR in meinem vorhergehenden Post.
Sowas kann nur ein Windows-Administrator behaupten der kaum bis garkeine Erfahrung mit Linux, UNIX & Co hat.
Was glaubst du dann, wie wir den unsere ganzen Maschinchen adminstrieren? Es gibt genug Lösungen dafür. Einen Binary-BLOB ala Windows Registry brauchen wir dafür jedenfalls mit Sicherheit nicht.
Aus diesem Grund verwendet Elektra ja XML und das Dateisystem als Verzeichnisstruktur.
Ich verwaltet deutlich weniger als 1000 Maschine und habe schon einige Probleme mit den gefühlt tauschend verschiedenen Konfigurationsvarianten. Jetzt mal bitte konkret werden, was für eine Lösung habt Ihr? Diese Lösung könnte dann auch mir uns interessant sein.
Es geht um ein einheitliches Konzept für Konfigurationen, welches "einfache" Distro-Übergreifende KonfigurationsTools wie z.B. Yast ermöglichen könnten. Und das ohne für jedes noch so kleine Programm einen eigenen Parser zu bauen.
Ist ja schön und gut, aber xml ist doch einfach zum Davonlaufen. Da gab es mal einen großen Hype drum und in der Zeit ist wohl Elektra auch enstanden. Inzwischen bewegen sich die meisten zum Glück wieder davon weg.
Naja, was will man auch mit einer Dateistruktur, die weder für Menschen noch für Computer sehr gut lesbar ist...
In meinen Augen ist es auch dieses Dateiformat (bzw. die Beschränkung auf dieses), welches es verhindern wird, dass sich Elektra durchsetzt. Wenn man hier etwas mehr Vielfalt bieten würde könnte die Abwärtskompatibilität für die Programme sichergestellt werden. Für die Schnittstelle wäre es ohnehin egal.
Ich glaube, das ist im Artikel missverständlich formuliert.
Zumindest früher war Elektra so konzipiert, dass quasi jeder Konfigurationseintrag eine eigene Datei war.
D.h. dass der Baum dem Verzeichnis/Dateibaum entsprach.
Grund dafür war primär die Zielsetzung schon sehr früh im Bootprozess einsatzfähig zu sein, also wenn unter Umständen noch keine Bibliotheken zum Parsen verfügbar sind.
Das ist natürlich auch nicht für alle Szenarien brauchbar, aber mein letzter Kenntnisstand war, dass verschieden Speichermethoden für unterschiedliche Szenarien möglich waren
Ich hoffe du weißt, dass man für so sauber geordnete strukturierte einheitliche Daten wie es mit XML möglich ist, mit wenig Aufwand ordentliche GUI Oberflächen zur Konfiguration dieser XML Keys bauen kann und der Mensch sich daher gar nicht mehr in den Tiefen einer XML Datei verstricken muss.
Und für den Computer kann man aus diesen binäre Caches bauen oder diese in eine DB laden, dann ist auch der lesende Zugriff schnell und effizient.
"Inzwischen bewegen sich die meisten zum Glück wieder davon weg."
Das mag im Hobbyumfeld so sein, in der Industrie ist XML ungebrochen beliebt.
Sicherlich ist es nicht perfekt, es ist aktuell jedoch der beste Kompromiss zwischen Mensch und Maschine.
Zudem gibt es einen riesigen Park an Programmen, welche die Nutzung stark vereinfachen.
"Wenn man hier etwas mehr Vielfalt bieten würde"
Klingt nach exakt dem, was so ein Projekt auf keinen Fall gebrauchen kann
Sicherlich ist es nicht das Ziel das nach der Deinstallation eines Programms irgendwelcher Daten Müll zurück bleibt. Wirft man von Zeit zu Zeit mal einen
Blick in die beiden Ordner .local und .conf wird man auch da fündig !!
Ich denke das Projekte wie Elektra durchaus ein Schritt in die richtige Richtung seitens der allgemeinen Linux Usability ist. Solange sich alles zentral im eigenen /home/username untergebracht ist, spricht doch sicherlich nichts dagegen.
Anstatt dutzende config files welche zu dem noch über das ganze System verstreut sind händisch editieren zu müssen.
Dieser fast schon 30 jährige andauernde KRAMPF gehört mit verlaub ins MUSEUM. Wer auf diese alt her gebrachte weise einen Linux Server administrieren MUß darf dies gerne tun.
Aber auf den DESKTOP gehört mit verlaub etwas vernünftiges ! Denn Linux kann mehr, wenn man das richtige daraus macht.
Und ich bin froh das sich einige Devels deren seit Jahrzehnten bekannten Linux typischen Unzulänglichkeiten bewusst sind und sich langsam in Richtung ANWENDER FREUNDLICHKEIT mal etwas tut.
Rechenleistung und Rechenpower bekommt man im Desktop Bereich für wenig Geld nach geworfen. Jedes 0-8-15 Handy kommt heute schon mit 1,8 Ghz CPU
und 1 Gig Ram. Also weshalb soll man an einer vernünfigen DESKTOP Lösung sparen ?
Und wer von den Ewig - gestrigen schon mal versucht hat ein halbwegs für den Anwender benutzbares Linux auf alt Hardware (alte xp rechner) zu installieren wird feststellen das dank *PAE kernel* dieses Recycling Vorhaben wohl ein Traum bleiben wird *fg
Ich arbeite mit Windows und Linux und glaube daher zu wissen wovon ich schreibe.
Thema Windows Reverseengineeren : Reactos ist das eindeutig das bessere OS !! http://www.reactos.de/
Korrektur und Nachtrag : Linux auf alt Hardware (alte xp rechner) zu installieren.....
In meinem Fall war dies ein Mainboard mit Intel Celeron 700 Mhz CPU und eine 20 Gigabyte IDE Platte. Auf eben diesem Uralt PC war zuvor Win XP installiert.
PAE kan man recht einfach abschalten, dann läuft der Kernel auch auf älteren CPUs.
Das Müll in der Windows-Registry bleibt und alles in einem binären Blob gespeichert wird sind konzeptuelle Fehler die in Elektra nicht gemacht werden. Elektra setzt auf die alt-hergebrachten Konfigurationsdateien und erlaubt es somit Config-Dateien zu editieren und zu löschen. Also so gesehen ist es schon eine eigene Unix (Linux)-Lösung und nicht abgekupfert
Pro: Standardisierter Zugriff
Einfacher Zugriff um Konfigurationen zu ändern. Das zählt vor allem dort wo größere Systemlandschaften gepflegt werden und also nicht irgendwelche Parser. Alternative ist natürlich ganze Konfigdateien zu verteilen oder rudimentäre sed/awk Scripte zu schreiben. Elektra ist da weitaus flexibler und funktioniert out-of-the box. "kdb get", "kdb set" feetich. Das hilft SysAdmins und Softwareherstellern, die mit Ihren Produkten die Systemkonfiguration bearbeiten möchten.
Contra: XML-Dateien
XML-Dateien per vi editieren ist nicht ganz so angenehm wie herkömmliche konfigs. Da würde ich mir lieber was menschenfreundlicheres wünschen. JSON, YAML, ...
Zum Thema Registry-Bloat:
Elektra kann sich über viele Dateien
erstrecken. Die Apache Config könnte dann z. B. in /etc/apache/elektra.xml liegen. Wenn ein Paket dann gepurged wird(dpkg --purge) fliegen die Configs weg und demensprechend auch die Elektra-Config Teilbäume. Also IMHO: Nix Bloat.
---
Aber einfach mal ein bisschen rumliegen lassen. Wer weiss, ob die Zeit von Elektra kommen wird und wann.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Jun 2014 um 22:47."menschenfreundlicheres: JSON"
Inwiefern ist den gerade JSON "menschenfreundlicheres"?
Da habe ich eine deutlich andere Meinung zu... diese Klammerwüste ist nun wirklich nicht besser als XML.
YAML allerdings ist ein nettes Format.
JSON ist nicht menschenfreundlicher, sondern nur kürzer.
Die Vereinfachungen muss ein Mensch dann allerdings verstehen und richtig lesen und verstehen.
Bei XML muss man gar nicht viel nachdenken, man muss nur wissen dass es Datenwerte gibt, die von Tags eingeschlossen werden, die wiederum der Name für den Key sind, falls keine Attributnamen verwendet werden, die es ebenfalls geben kann.
Im großen und ganzen lässt sich XML auf ein Key vs. Value Schema runterbrechen und das zu verstehen sollte für jeden Menschen ein Kinderspiel sein, was XML sehr menschenfreundlich macht.
Wenn etwas kaputt ist, dann wurden entweder Tags nicht richtig geschlossen oder der Keyname ist falsch, das merkt man als Mensch schnell. Bleibt also nur noch die Semantik übrig, die man wirklich wissen muss, aber das gilt für jede Art von Konfigurationsdatei und ist nicht auf XML beschränkt.
JSON ist da wesentlich weniger intuitiv, weil noch die Klammerung zu beachten ist.
Gewinnen tut dies nur durch weniger Schreibarbeit, aufgrund der schlechteren Intuitivität und geringfügig größeren Komplexität der Syntax steigt allerdings die Fehlerrate die ein Mensch verursachen kann.
Wenn ein DAU einen Wert in einer Konfigurationsdatei verändern oder einfügen soll, dann wird er es mit XML auf alle Fälle leichter haben als mit JSON.
Hallo fork,
genau, der standardisierte Zugriff ist ein zentrale Aspekt von Elektra.
Das mit XML ist im Artikel aber sehr unglücklich formuliert. Es ist so, dass Elektra (immer schon) eine key/value Datenstruktur verwendet, welche in jedes Konfigurationsformat abbildbar ist. xml ist eine möglichkeit (plugin xmltool), json eine andere (implementiert im Plugin yajl seit 0.8.4), ini wieder eine andere (plugins ni und simpleini) oder auch andere configdateien wie xorg.conf (plugin augeas). Die Diskussion welches Format am besten ist, wird mit Elektra einfach überflüssig und jeder Programmierer, Maintainer und Admin kann selbst entscheiden.