Bevor hier wieder als erstes ein unkonstruktiver Meckerkommentar eintrudelt, der fragt, ob man denn wirklich immer wieder über „dieses völlig unwichtige Projekt“ berichten müsse, versuche ich es mal mit konstruktiver Kritik:
Ich verfolge Elektra schon ziemlich lange, einfach weil ich die Idee gut finde und immer vorhatte, damit etwas zu spielen, wenn ich mal etwas länger Urlaub nehmen kann. Das Projekt, das ich im Kopf habe, hat sich mit der neuen Version aber möglicherweise erledigt.
Mir schwebte ein experimenteller Bastel-Fork von FreeBSD vor, dessen Basissystem ich Elektra hinzufügen und dann schauen wollte, wie man Teile des Betriebssystems dahingehend umstellt, es zu nutzen. Die Lizenz hätte ja sogar auch gepaßt, aber einen Go-Compiler gibt es natürlich nicht im Basissystem.
Wobei für diesen Anwendungszweck elektrad ja gar nicht nötig sein würde und genaugenommen hat ja auch niemand gesagt, daß alle möglichen anderen Komponenten in Zukunft auch in Go geschrieben werden. Also vielleicht einfach mal das Beste hoffen.
Du brauchst elektrad nicht unbedingt, man braucht es nur wenn man über ein Web-Interface konfigurieren will. Eine andere wichtige Info war leider auch nicht in den release notes: elektrad war vorher in nodejs geschrieben.
Wir sind sehr gespannt auf Ergebnisse von deinen Versuchen und hoffen von dir auf issues.libelektra.org zu hören
von mir auch einfach mal „Danke“ dafür, daß ihr weitermacht. Es hat mich in den letzten Jahren sogar als komplett Außenstehender doch ein wenig genervt, wie immer wieder die Miesmacher hervorgekrochen kamen, die zwar an Elektra gar nicht interessiert waren, sich aber irgendwie doch berufen fühlten, zu meckern. Vielleicht hängt irgendwie immernoch der verunglückte Name „Linux Registry“ über euch...
Ob nun Go oder Node.js ist für meine Fragestellung tatsächlich egal. Ich kann auch voll und ganz nachvollziehen, daß man einen HTTP-Server nicht unbedingt ohne Not in C schreibt. Paßt also alles. Wie gesagt kommt in meinem Szenario ja erstmal gar kein Webserver vor.
Ich kann übrigens nicht versprechen, daß das Projekt a) überhaupt jemals angegangen wird noch, daß es b) soweit kommt, mitteilenswert zu sein. Falls aber doch, werde ich es euch gerne wissen lassen.
Genau richtig erkannt: elektrad ist nicht zwingend notwendig. Der Core von Elektra und einige Plugins sind in reinem C99 geschrieben und haben keine weiteren Abhängigkeiten. Es gibt derzeit keine Pläne dieses Design zu ändern.
Je nach Einsatzzweck wird es vermutlich trotzdem praktisch sein einzelne Abhängigkeiten zu installieren, um weitere Plugins nutzen zu können.
Wir freuen uns definitiv über solche Projekte zu hören sowie über weitere konstruktive Kritik auf https://issues.libelektra.org/
C99 ist prima, damit sollte der Aufnahme des Kernprojektes in ein Basissystem wenig im Weg stehen. Für mich wird das Ganze aber ein Abenteuer mit ungewissem Ausgang sein - mal sehen, wie weit ich als Admin mit recht bescheidenen Programmierkenntnissen bei sowas komme.
Derzeit ist, wie ich sehe, Elektra noch auf keinem BSD-System einfach verfügbar, um mal etwas damit zu spielen. Vielleicht versuche ich am Wochenende mal nebenher einen Port zu schreiben. Auf den ersten Blick sieht das alles nicht so kompliziert aus, daß ich schon gleich „das wird eh nichts“ sagen müßte. Na, mal sehen.
Obwohl es nicht die selben Zwecke verfolgt wie Elektra, möchte ich an dieser Stelle libucl (UCL) zu erwähnen. Das ist ein Projekt aus dem Dunstkreis von FreeBSD (Allan Jude). Aus meiner Sicht existiert hier ein gewisse Schnittmenge bzgl. des Funktionsumfangs bzw. auch der Zielsetzung der beiden Projekte, wobei es mir so scheint, als ob libucl eher eine Teilmenge von Elektra abdeckt. Ausnahme ist evtl. die spezifische Wahl der Konfigurationsformate.
Der Vorstoß innerhalb von FreeBSD (Basissystem) begann 2015. Inwieweit dieser bisher gefruchtet hat, weiß ich nicht. Allerdings stelle ich mir eine Umsetzung der Integration äußerst kompliziert vor, da das Basissystem von FreeBSD einige nicht-triviale, extern entwickelte Komponenten enthält (z.B. OpenSSH).
Vielleicht würde es sich im Rahmen Ihres Projektes ja sogar lohnen, dort mal nachzuhaken. Wie so der Stand ist, und was noch zu tun wäre, oder was man von Elektra halten würde... oder so. Falls Sie denn überhaupt Zeit für dieses Projekt haben werden Insofern viel Erfolg!
Vielen Dank für den kleinen „Schubs“ - denn das hatte ich tatsächlich gerade gar nicht in Zusammenhang gebracht. Ich fand die Idee von UCL gut, als sie damals aufkam, aber außer daß Allan die drei Buchstaben hin und wieder im BSDNow!-Podcast erwähnte, hatte ich nicht so viel Kontakt damit. Denn gefühlt ist diesbezüglich lange nahezu nichts passiert - oder zumindest nichts Offizielles.
Die libucl ist seit FreeBSD 11.3 und 12.1 Teil des Basissystems, d.h. wir sind jetzt, 5 Jahre später, zumindest an dem Punkt, an welchem alle offiziell unterstützten Versionen die Möglichkeit bieten, sie zu nutzen. Damit könnte könnte man jetzt also beginnen, das Userland umzukrempeln und an allen möglichen Stellen UCL als Alternativparser für Konfigurationsdateien einzusetzen.
Habe gerade mal nach syslogd geschaut, da das ja Allans erstes Beispiel war - für mich sieht es so aus, als hätte sich da nichts bewegt. Der von ihm vorgeschlagene Code wurde noch nicht angenommen und ich sehe auch keine anderen Referenzen zu UCL.
Ein schnelles Experiment kam zu dürftigen Ergebnissen:
# freebsd-version 12.1-RELEASE-p5 # zgrep -i ucl /usr/share/man/man5/* /usr/share/man/man5/ctl.conf.5.gz:An equivalent configuration in UCL format, for use with /usr/share/man/man5/iovctl.conf.5.gz:file uses UCL format. /usr/share/man/man5/iovctl.conf.5.gz:UCL syntax is documented at the official UCL website: /usr/share/man/man5/iovctl.conf.5.gz:http://github.com/vstakhov/libucl.
Ich sage mal, da geht noch was. Ein paar Programme aus den Ports wie z.B. cBSD nutzen es, so weit ich weiß, aber insgesamt hält es sich noch ziemlich in Grenzen.
Vielleicht sieht das in 13 schon ganz anders aus - aus Platzmangel habe ich derzeit aber tatsächlich kein System zur Hand, auf dem -CURRENT läuft (Schande über mich). Müßte man mal versuchen, am Ball zu bleiben...
Ich kenne libucl natürlich. Die Präsentation bringt es gut auf den Punkt:
Jordan, being from Apple, suggested the binary XML plists used by launchd. I really didn’t want the “one true format” to be XML.
Hier sieht man klar, dass libucl das Problem nicht verbessern kann, sondern einfach nur ein neues Format hinzufügen wird: xkcd.com/927.
Elektra hat einen völlig anderen Ansatz auf einer anderen Abstraktionsebene: es erlaubt (mittels Spezifikationen bzw. mount) zu beschreiben wie die Konfigurationsdateien des Systems aussehen sollen. Das kann UCL sein, kann aber auch YAML, TOML, XML, .... sein. Elektra abstrahiert über das konkrete Format und bindet alles in eine hierarchische key/value "Datenbank" ein.
Wir würden es sehr begrüßen, wenn FreeBSD sich mal Elektra näher anschauen könnte, hoffentlich bringt kraileth wieder Leben in die ganze Sache. FreeBSD und Elektra sind sich auf jeden Fall nicht fremd, wir haben schon öfters mal bug reports bezüglich Feinheiten von FreeBSD bekommen.
Grundsätzlich stimme ich zu, daß xkcd schon darauf paßt - aber libucl hat gegenüber „einfach noch ein Standard“ schon einige potentielle Vorteile:
a) Es will nicht andere Standards ersetzen, sondern eine „auch-Unterstützung“, um dem Admin am Ende des Tages die Wahl zu geben, ob er eine Systemkomponente oder ein Programm klassisch oder mit UCL konfiguriert b) Im Kontext eines Projektes wie FreeBSD muß man nicht hunderte Einzelprojekte beknien, die Funktionalität einzubauen, sondern man hat die volle Verfügungsgewalt über das eigene Basissystem, das man nach einer klaren Entscheidung dafür einheitlich umbauen könnte c) Die Optionalität kann libucl eigentlich nur nützen: Der Widerstand dagegen wird bedeutend geringer ausfallen, als wenn man dem einen oder anderen Graubart androht, daß ihm sein bekanntes alteingesessenes Konfigurationsformat weggenommen wird. Gleichzeitig liegt der Vorteil auf der Hand, daß letztlich immer mehr FreeBSD-Admins die vereinheitlichte Konfigurationsweise bevorzugen werden, so daß diese mehr und mehr Gewicht bekommen dürfte d) Von FreeBSD aus könnte es sich anschließend (wahrscheinlich sehr langsam) auch auf andere Plattformen ausbreiten, da vermutlich die meisten von uns gemischte Systemlandschaften verwalten
Tatsache ist aber, daß UCL vielleicht kein zaghafter, aber doch ein kleiner Schritt ist, wenn man es mit dem Anlegen von Elektra vergleicht. Und hier schlage ich mich technisch ganz klar auf die Seite von „laßt uns das Problem gleich richtig lösen“, also den Elektra-Ansatz. Wobei ich nicht weiß, ob - und wenn ja: wie - man genügend Leute dafür gewinnen kann. UCL hat es bereits schwer genug, Fuß zu fassen, obwohl es eine viel, viel weniger radikale Änderung in unseren *nix-Systemen bedeutet.
Was aber nicht heißt, daß ich es für aussichtslos halte, Elektra einen Platz zu geben und von ihren Fähigkeiten zu profitieren. Das Projekt geht hier aus meiner Sicht sehr vernünftig vor, indem es den umgekehrten Weg zum besserwisserischen Verhalten gewisser anderer Programme einschlägt und integrativ wirkt, also eigentlich allem und jedem die Hand zu reichen bereit ist, anstatt die eine Reine Wahrheit zu verkünden, nach der sich gefälligst alle zu richten haben. Der Umbruch wird so oder so nicht über Nacht passieren. Mal sehen, wo wir diesbezüglich in ein paar Jahren stehen.
libucl hat gegenüber „einfach noch ein Standard“ schon einige potentielle Vorteile
Keine Frage, die aktuelle Situation hat so viele offensichtliche Nachteile (insbesondere die tabellarischen Konfigurationen), sodass jede Änderung verlockend klingt
Von FreeBSD aus könnte es sich anschließend (wahrscheinlich sehr langsam) auch auf andere Plattformen ausbreiten, da vermutlich die meisten von uns gemischte Systemlandschaften verwalten
Es gibt ja schon seit längerem viele solche Ansätze ähnlich zu libucl (z.b. UCI). Bis jetzt hat jede diese Lösung nur weitere Insel und Inkompatibilitäten geschaffen. Und zwar aus guten Grund: Das Format ist reine Geschmacksfrage, man wird nie alle überzeugen können sein Lieblingsformat zu verwenden.
UCL hat es bereits schwer genug, Fuß zu fassen, obwohl es eine viel, viel weniger radikale Änderung in unseren *nix-Systemen bedeutet.
Weil das Format jemanden, der nicht von der nginx Ecke kommt, einfach nicht anspricht: da kann man keine User-Base aufbauen. "Einfach" XML zu verwenden, was in den meisten Projekten als Abhängigkeit sowieso schon vorhanden ist, bzw. in der Programmiersprache integriert ist, ist viel einfacher. Das ist aber ein Desaster für schlanke Systeme wie FreeBSD da es gigantisch große XML Parser in das Basissystem ziehen würde (oder ist das sogar schon passiert?). Zur Klarstellung: ich habe nichts gegen XML, es ist aber ein komplexes Format und standard-konforme Parser sind groß. Andere XML-ähnliche Parser sind einfach nicht XML und fragmentieren die Konfigurationsformate nur noch mehr.
Das Projekt geht hier aus meiner Sicht sehr vernünftig vor, indem es den umgekehrten Weg zum besserwisserischen Verhalten gewisser anderer Programme einschlägt und integrativ wirkt, also eigentlich allem und jedem die Hand zu reichen bereit ist, anstatt die eine Reine Wahrheit zu verkünden, nach der sich gefälligst alle zu richten haben.
Danke
Der Umbruch wird so oder so nicht über Nacht passieren. Mal sehen, wo wir diesbezüglich in ein paar Jahren stehen.
Wenn ein paar Zugpferde auf die Lösung setzten, kann es auch ziemlich schnell gehen. Wir setzten jetzt mal auf KDE und GNOME. So oder so, wird es auf uns alle ankommen (inkl. dich und FreeBSD!) was passiert oder auch nicht passiert
... wird es möglich sein: Einfach Konfigurationswerte automatisiert über ein API setzen. Ohne windige Hilfskonstruktionen mit cat/grep/sed, ohne Pipe-Inception, und ohne Zusatzaufwand damit man die Originaldatei nicht einfach nullt. Idealerweise robust, so dass sich meine Skripte nicht nächste Woche schon wieder als kaputt herausstellen, weil man in der Configfile X ja im Randfall #y diesunddas noch soundso hätte escapen müssen.
Bei den unprofessionellen Spielzeugsystemen hat man sowas ja schon seit mind. einem Vierteljahrhundert. Das ist für den Turnschuhadmin. Der Unix-Techie reißt sich natürlich darum, sich nebenbei dauernd noch mit sowas auseinandersetzen zu dürfen. So kann er seine Skills in Regexps und Bash-Jongliererei ein bisschen schärfen; das kann man beim nächsten CCC-Congress dann schön seinen Buddies zeigen. Und dass man in seiner Fachdomäne nicht effizient weiterkommt, nunja, dafür findet sich dann schon immer irgendein Grund. Das ist dann die Zeit, die der Windows-Dev mit Visual Studio Updates verbrannt hätte.
Das ist eigentlich genau das, was Elektra ermöglicht. Es gibt ein C/C++ API sowie Bindings für einige andere Sprachen. Man kann Werte über ein CLI-Tool setzen oder mittels elektrad das REST HTTP API nutzen. Zudem gibt es ein QT-GUI sowie ein Webinterface um Konfigurationswerte komfortabel setzten zu können, ohne gleich selbst programmieren zu müssen.
Ja ich weiß - warten wir mal, wann sich das in der Breite durchgesetzt hat, und es einen Wert für den Admin hat. Bisher ist es eher etwas, womit der Entwickler sich ein paar Zeilen Code spart, und nicht mehr, oder? Einfach der Verbreitung wegen...
Wir arbeiten derzeit an der Verbreitung indem wir Elektra in KDE und GNOME integrieren. Diese Integrationen werden der Fokus der nächsten Versionen sein.
Es ist aber bereits jetzt möglich diverse Konfigurationsformate mit Elektra zu lesen und zu schreiben. Die erwähnten Schnittstellen stehen also zur Verfügung, auch wenn das Upstream-Projekt nicht Elektra nutzt.
Ich finde solche Ansätze wie Elektra total super. Keine Frage. Aber für mich ist der Ganze Kontext noch weit weg von Perfektion. Zuerst ist es mega cool, mal ein API zu haben, um Konfigurationsparameter zu setzen. So ein bisschen wie die "Registry" in Redmond (wenn auch backendseitig sogar imho besser organisiert).
Aber dann geht es ja weiter. Ich möchte gern automatisiert bspw. in KDE Elemente ins Panel einfügen. Das ist schon aktiver. Da gibt es dann irgendein DBUS-Interface, dem ich Javascript schicken kann. Leider alle paar Jahre mit Breaking Changes. Im Prinzip ist das aber ja auch eine Art Konfigurationsfrage.
Es wirkt auf mich vieles so, als hätte Windows uns in Sachen Automatisierungsfähigkeit schon lange abgehängt. Nur ein paar Träumer aus WinME-Zeiten sehen das noch als eine Unix-Stärke. Ich wüßte jetzt auch nicht, wie man dort die Taskbar anreichert; auch weil ich mich nicht damit befasse, weil ich kein Windows-System zu konfigurieren habe. Aber vieles geht dort heutzutage über gute alte COM-Interface, .NET Interop, usw usf. Am Ende des Tages nicht perfekt, aber okay. Der Unix-Guy fummelt sich mit sed etwas zusammen, was mit dem nächsten Release der Desktopumgebung hinüber ist. Der Linux-Guy speißt heute ein DBUS-Interface, indem es in irgendeinen String-Parameter ein Javascript reinwirft, was dann nicht funktioniert. Am Ende des Tages doch alles irgendwie eher sperrig und in die Jahre gekommen.
Konfiguration zentral in einer großen Datenbank speichern. Klingt erst mal gut, aber wenn es in der Windows-Registrierungsdatenbank zu einem kleinen Problem kommt, hat man schnell ein großes Problem mit dem gesamten Betriebssystem.
Seit spätestens Windows10 funktioniert das im "Regelfall" - sofern die Hardware-Unterstützung gegeben ist.
Dist-Upgrades seit Windows 10 ebenfalls. Selbst wenn hier etwas fehlschlägt, setzt das System den alten Zustand automatisch mit 2-3 Reboots wieder zurück. Man sollte jedoch zuvor 2-3 Monate nach einem neuen Release ins Land gehen, und zuvor seine Treiber und Applikationen auf aktuellen Stand bringen.
Seit Windows10 funktioniert das? Da schauen wir weiter wenn windows 11 rauskommt oder? Die 'upgrades' von Windows10 sind eher mit servicepacks vergleichbar.
Windows10 wurde als 'rolling-release' entworfen, im gegenteil zu den vorgaengern die als hauptversionen gesehen wurden, ess kann also sehr viel besser mit einem windowsxp sp1 bis sp2 verglichen werden wie ein win2000 zu einem xp...aber wenn man keine ahnung hat
Aber so wie es bisher aussieht wird es kein Windows 11 geben. Bei den Versionen von Win 10 soll Microsoft mal das so machen wie Apple, anders blickt da doch niemand mehr durch. Nutzes aber auch nicht mehr, also kann mir das egal sein.
Eine Registrierdatenbank im Windows-Stil wäre auch mein Alptraum. Früher oder später ist das dann eine unaufgeräumte Müllhalde voller kryptischer Schlüssel- Werte-Paare mit wenig oder gar keiner Dokumentation und jeder Menge "Leichen".
Ich administriere meine Slackware im Wesentlichen mit dem Midnight Commander plus Mcedit und finde es aus Sicht eines eher unbedarften Nutzer hilfreich, dass in den Config-Files und in den Skripten Kommentare drin sind und teils auch inaktive (auskommentierte) Varianten, die man nur zu aktivieren braucht, wenn man die Funktionalität möchte.
Das mag auch Nachteile haben und mag auch etwas weniger "performant" sein, aber das ist mir wurscht, so lange es besser bedienbar ist.
Früher oder später ist das dann eine unaufgeräumte Müllhalde voller kryptischer Schlüssel- Werte-Paare mit wenig oder gar keiner Dokumentation und jeder Menge "Leichen".
Das beschreibt ungefähr die aktuelle Situation von freier Software. Z.b. wie viele der environment variablen sind tatsächlich dokumentiert? Wenn du mehr darüber wissen willst, lies mal hier und hier.
Ich administriere meine Slackware im Wesentlichen mit dem Midnight Commander plus Mcedit und finde es aus Sicht eines eher unbedarften Nutzer hilfreich, dass in den Config-Files und in den Skripten Kommentare drin sind und teils auch inaktive (auskommentierte) Varianten, die man nur zu aktivieren braucht, wenn man die Funktionalität möchte.
Elektra unterstützt genau diese Workflows, nur dass du dir selbst aussuchen darfst welches Format die Konfigurationsdateien haben und die Konfigurationen spezifiziert werden können (welche keys gibt es, welchen Typ haben sie usw. usf.).
Hat Elektra auch die Nachteile einer Windows-Registrierungsdatenbank?
Diese Frage trifft genau auf den Punkt und ist auch der Grund warum die Entwicklung nicht 10 Wochen sondern mehr als 10 Jahre gedauert hat. Die ersten Versionen von Elektra (die auch Linux Registry hießen) haben, auch wenn es anders behauptet wurde, doch noch einige Nachteile übernommen, insbesondere das es nur ein Backend gab, d.h., keine anderen Konfigurationsquellen integriert werden können. Die Modularität, die es derzeit gibt (jedes Programm schreibt seine Konfigurationsdatei und ist komplett unabhängig), zu erhalten war genau die große Herausforderung, die erst mit der 0.8 Serie von Elektra gelöst wurde.
Details zu all den Modularitäts und Kontextprobleme die Elektra jetzt löst gibt es im Buch über Elektra: book.libelektra.org.
>> Klingt erst mal gut, aber wenn es in der Windows-Registrierungsdatenbank zu einem kleinen Problem kommt, hat man schnell ein großes Problem mit dem gesamten Betriebssystem.
Seit 20Jahren (Windows 2000) hab ich bei mir im 24/7 Betrieb und bei dutzenden betrieblich genutzten Arbeitsplatz-PCs genau _0_ Probleme mit der Registrierungsdatenbank erlebt.
Also frage ich mich wie man zu einer solchen Aussage kommt. In der Praxis kenne ich nur solche Fälle wenn man irgendwelche Pfuschtools laufen lässt, die wild meinen dadrin "rumoperieren" zu müssen. Die Registrierungsdatenbank dient im Regelfall als zentrales Speicherbackend für das Betriebssystem und deren Anwendungen, nicht zum manuellen Editieren.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 29. Mai 2020 um 14:59.
>> Das komplette KDE mittels Elektra zu konfigurieren ist ein Ziel, das bereits mit dem KDE-Projekt diskutiert wurde.
Das ich das noch auf die letzten PL-Tage erleben darf...
Vor etwa 15 Jahren als Lib-Elektra 0.1 hier noch unter anderm Namen erstmals beschrieben wurde, hatte ich genau das schon vorgeschlagen... inkl. Integration in Commandline-Tools wie vim/cat/less/grep/gawk etc pp ..
Damals wurde man dafür zerissen. Genauso wie für den Vorschlag Distroübergreifende (statische) Apps über externe Quellen per Mausklick nachinstallieren zu können... KDE/Plasma und/oder Apps via Mausklick aktualisieren zu können, anstatt auf die nächste Dist-Upgrade warten zu müssen... - inkl. Rollbacks bei Problemen.
15 Jahre später .... und es wird diskutiert das sowas kommen könnte - prima
Meinen Dank an die Elektra-Entwickler für das durchhalten gegen alle Wiedrigkeiten ! Ohne das ich das Projekt im Detail kenne - bitte haltet es im Grunde "einfach", getreu dem KISS konzept.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Mai 2020 um 01:43.
Bevor hier wieder als erstes ein unkonstruktiver Meckerkommentar eintrudelt, der fragt, ob man denn wirklich immer wieder über „dieses völlig unwichtige Projekt“ berichten müsse, versuche ich es mal mit konstruktiver Kritik:
Ich verfolge Elektra schon ziemlich lange, einfach weil ich die Idee gut finde und immer vorhatte, damit etwas zu spielen, wenn ich mal etwas länger Urlaub nehmen kann. Das Projekt, das ich im Kopf habe, hat sich mit der neuen Version aber möglicherweise erledigt.
Mir schwebte ein experimenteller Bastel-Fork von FreeBSD vor, dessen Basissystem ich Elektra hinzufügen und dann schauen wollte, wie man Teile des Betriebssystems dahingehend umstellt, es zu nutzen. Die Lizenz hätte ja sogar auch gepaßt, aber einen Go-Compiler gibt es natürlich nicht im Basissystem.
Wobei für diesen Anwendungszweck elektrad ja gar nicht nötig sein würde und genaugenommen hat ja auch niemand gesagt, daß alle möglichen anderen Komponenten in Zukunft auch in Go geschrieben werden. Also vielleicht einfach mal das Beste hoffen.
Danke für die konstruktive Meldung!
Du brauchst elektrad nicht unbedingt, man braucht es nur wenn man über ein Web-Interface konfigurieren will. Eine andere wichtige Info war leider auch nicht in den release notes: elektrad war vorher in nodejs geschrieben.
Wir sind sehr gespannt auf Ergebnisse von deinen Versuchen und hoffen von dir auf issues.libelektra.org zu hören
glg Markus
Moin Markus,
von mir auch einfach mal „Danke“ dafür, daß ihr weitermacht. Es hat mich in den letzten Jahren sogar als komplett Außenstehender doch ein wenig genervt, wie immer wieder die Miesmacher hervorgekrochen kamen, die zwar an Elektra gar nicht interessiert waren, sich aber irgendwie doch berufen fühlten, zu meckern. Vielleicht hängt irgendwie immernoch der verunglückte Name „Linux Registry“ über euch...
Ob nun Go oder Node.js ist für meine Fragestellung tatsächlich egal. Ich kann auch voll und ganz nachvollziehen, daß man einen HTTP-Server nicht unbedingt ohne Not in C schreibt. Paßt also alles. Wie gesagt kommt in meinem Szenario ja erstmal gar kein Webserver vor.
Ich kann übrigens nicht versprechen, daß das Projekt a) überhaupt jemals angegangen wird noch, daß es b) soweit kommt, mitteilenswert zu sein. Falls aber doch, werde ich es euch gerne wissen lassen.
Danke für die konstruktive Kritik!
Genau richtig erkannt: elektrad ist nicht zwingend notwendig. Der Core von Elektra und einige Plugins sind in reinem C99 geschrieben und haben keine weiteren Abhängigkeiten. Es gibt derzeit keine Pläne dieses Design zu ändern.
Je nach Einsatzzweck wird es vermutlich trotzdem praktisch sein einzelne Abhängigkeiten zu installieren, um weitere Plugins nutzen zu können.
Wir freuen uns definitiv über solche Projekte zu hören sowie über weitere konstruktive Kritik auf https://issues.libelektra.org/
Moin mpranj,
C99 ist prima, damit sollte der Aufnahme des Kernprojektes in ein Basissystem wenig im Weg stehen. Für mich wird das Ganze aber ein Abenteuer mit ungewissem Ausgang sein - mal sehen, wie weit ich als Admin mit recht bescheidenen Programmierkenntnissen bei sowas komme.
Derzeit ist, wie ich sehe, Elektra noch auf keinem BSD-System einfach verfügbar, um mal etwas damit zu spielen. Vielleicht versuche ich am Wochenende mal nebenher einen Port zu schreiben. Auf den ersten Blick sieht das alles nicht so kompliziert aus, daß ich schon gleich „das wird eh nichts“ sagen müßte. Na, mal sehen.
Euch auf jeden Fall weiterhin: Gutes Gelingen!
Eine nette Idee.
Obwohl es nicht die selben Zwecke verfolgt wie Elektra, möchte ich an dieser Stelle libucl (UCL) zu erwähnen. Das ist ein Projekt aus dem Dunstkreis von FreeBSD (Allan Jude). Aus meiner Sicht existiert hier ein gewisse Schnittmenge bzgl. des Funktionsumfangs bzw. auch der Zielsetzung der beiden Projekte, wobei es mir so scheint, als ob libucl eher eine Teilmenge von Elektra abdeckt. Ausnahme ist evtl. die spezifische Wahl der Konfigurationsformate.
Der Vorstoß innerhalb von FreeBSD (Basissystem) begann 2015. Inwieweit dieser bisher gefruchtet hat, weiß ich nicht. Allerdings stelle ich mir eine Umsetzung der Integration äußerst kompliziert vor, da das Basissystem von FreeBSD einige nicht-triviale, extern entwickelte Komponenten enthält (z.B. OpenSSH).
Vielleicht würde es sich im Rahmen Ihres Projektes ja sogar lohnen, dort mal nachzuhaken. Wie so der Stand ist, und was noch zu tun wäre, oder was man von Elektra halten würde... oder so. Falls Sie denn überhaupt Zeit für dieses Projekt haben werden
Insofern viel Erfolg!
Quellen:
UCL Präsentation 2015 (Folien + Video)
derzeitiger Upstream gemäß Ports samt kurzer Dokumentation weiterer technischer Details
Vielen Dank für den kleinen „Schubs“ - denn das hatte ich tatsächlich gerade gar nicht in Zusammenhang gebracht. Ich fand die Idee von UCL gut, als sie damals aufkam, aber außer daß Allan die drei Buchstaben hin und wieder im BSDNow!-Podcast erwähnte, hatte ich nicht so viel Kontakt damit. Denn gefühlt ist diesbezüglich lange nahezu nichts passiert - oder zumindest nichts Offizielles.
Die libucl ist seit FreeBSD 11.3 und 12.1 Teil des Basissystems, d.h. wir sind jetzt, 5 Jahre später, zumindest an dem Punkt, an welchem alle offiziell unterstützten Versionen die Möglichkeit bieten, sie zu nutzen. Damit könnte könnte man jetzt also beginnen, das Userland umzukrempeln und an allen möglichen Stellen UCL als Alternativparser für Konfigurationsdateien einzusetzen.
Habe gerade mal nach syslogd geschaut, da das ja Allans erstes Beispiel war - für mich sieht es so aus, als hätte sich da nichts bewegt. Der von ihm vorgeschlagene Code wurde noch nicht angenommen und ich sehe auch keine anderen Referenzen zu UCL.
Ein schnelles Experiment kam zu dürftigen Ergebnissen:
# freebsd-version
12.1-RELEASE-p5
# zgrep -i ucl /usr/share/man/man5/*
/usr/share/man/man5/ctl.conf.5.gz:An equivalent configuration in UCL format, for use with
/usr/share/man/man5/iovctl.conf.5.gz:file uses UCL format.
/usr/share/man/man5/iovctl.conf.5.gz:UCL syntax is documented at the official UCL website:
/usr/share/man/man5/iovctl.conf.5.gz:http://github.com/vstakhov/libucl.
Ich sage mal, da geht noch was. Ein paar Programme aus den Ports wie z.B. cBSD nutzen es, so weit ich weiß, aber insgesamt hält es sich noch ziemlich in Grenzen.
Vielleicht sieht das in 13 schon ganz anders aus - aus Platzmangel habe ich derzeit aber tatsächlich kein System zur Hand, auf dem -CURRENT läuft (Schande über mich). Müßte man mal versuchen, am Ball zu bleiben...
Ich kenne libucl natürlich. Die Präsentation bringt es gut auf den Punkt:
Hier sieht man klar, dass libucl das Problem nicht verbessern kann, sondern einfach nur ein neues Format hinzufügen wird: xkcd.com/927.
Elektra hat einen völlig anderen Ansatz auf einer anderen Abstraktionsebene: es erlaubt (mittels Spezifikationen bzw. mount) zu beschreiben wie die Konfigurationsdateien des Systems aussehen sollen. Das kann UCL sein, kann aber auch YAML, TOML, XML, .... sein. Elektra abstrahiert über das konkrete Format und bindet alles in eine hierarchische key/value "Datenbank" ein.
libucl in Elektra integrieren ist übrigens auch schon eine alte Idee: hier der bug report von 24 Dezember 2016.
Wir würden es sehr begrüßen, wenn FreeBSD sich mal Elektra näher anschauen könnte, hoffentlich bringt kraileth wieder Leben in die ganze Sache. FreeBSD und Elektra sind sich auf jeden Fall nicht fremd, wir haben schon öfters mal bug reports bezüglich Feinheiten von FreeBSD bekommen.
Grundsätzlich stimme ich zu, daß xkcd schon darauf paßt - aber libucl hat gegenüber „einfach noch ein Standard“ schon einige potentielle Vorteile:
a) Es will nicht andere Standards ersetzen, sondern eine „auch-Unterstützung“, um dem Admin am Ende des Tages die Wahl zu geben, ob er eine Systemkomponente oder ein Programm klassisch oder mit UCL konfiguriert
b) Im Kontext eines Projektes wie FreeBSD muß man nicht hunderte Einzelprojekte beknien, die Funktionalität einzubauen, sondern man hat die volle Verfügungsgewalt über das eigene Basissystem, das man nach einer klaren Entscheidung dafür einheitlich umbauen könnte
c) Die Optionalität kann libucl eigentlich nur nützen: Der Widerstand dagegen wird bedeutend geringer ausfallen, als wenn man dem einen oder anderen Graubart androht, daß ihm sein bekanntes alteingesessenes Konfigurationsformat weggenommen wird. Gleichzeitig liegt der Vorteil auf der Hand, daß letztlich immer mehr FreeBSD-Admins die vereinheitlichte Konfigurationsweise bevorzugen werden, so daß diese mehr und mehr Gewicht bekommen dürfte
d) Von FreeBSD aus könnte es sich anschließend (wahrscheinlich sehr langsam) auch auf andere Plattformen ausbreiten, da vermutlich die meisten von uns gemischte Systemlandschaften verwalten
Tatsache ist aber, daß UCL vielleicht kein zaghafter, aber doch ein kleiner Schritt ist, wenn man es mit dem Anlegen von Elektra vergleicht. Und hier schlage ich mich technisch ganz klar auf die Seite von „laßt uns das Problem gleich richtig lösen“, also den Elektra-Ansatz. Wobei ich nicht weiß, ob - und wenn ja: wie - man genügend Leute dafür gewinnen kann. UCL hat es bereits schwer genug, Fuß zu fassen, obwohl es eine viel, viel weniger radikale Änderung in unseren *nix-Systemen bedeutet.
Was aber nicht heißt, daß ich es für aussichtslos halte, Elektra einen Platz zu geben und von ihren Fähigkeiten zu profitieren. Das Projekt geht hier aus meiner Sicht sehr vernünftig vor, indem es den umgekehrten Weg zum besserwisserischen Verhalten gewisser anderer Programme einschlägt und integrativ wirkt, also eigentlich allem und jedem die Hand zu reichen bereit ist, anstatt die eine Reine Wahrheit zu verkünden, nach der sich gefälligst alle zu richten haben. Der Umbruch wird so oder so nicht über Nacht passieren. Mal sehen, wo wir diesbezüglich in ein paar Jahren stehen.
Keine Frage, die aktuelle Situation hat so viele offensichtliche Nachteile (insbesondere die tabellarischen Konfigurationen), sodass jede Änderung verlockend klingt
Es gibt ja schon seit längerem viele solche Ansätze ähnlich zu libucl (z.b. UCI). Bis jetzt hat jede diese Lösung nur weitere Insel und Inkompatibilitäten geschaffen. Und zwar aus guten Grund: Das Format ist reine Geschmacksfrage, man wird nie alle überzeugen können sein Lieblingsformat zu verwenden.
Weil das Format jemanden, der nicht von der nginx Ecke kommt, einfach nicht anspricht: da kann man keine User-Base aufbauen. "Einfach" XML zu verwenden, was in den meisten Projekten als Abhängigkeit sowieso schon vorhanden ist, bzw. in der Programmiersprache integriert ist, ist viel einfacher. Das ist aber ein Desaster für schlanke Systeme wie FreeBSD da es gigantisch große XML Parser in das Basissystem ziehen würde (oder ist das sogar schon passiert?). Zur Klarstellung: ich habe nichts gegen XML, es ist aber ein komplexes Format und standard-konforme Parser sind groß. Andere XML-ähnliche Parser sind einfach nicht XML und fragmentieren die Konfigurationsformate nur noch mehr.
Danke
Wenn ein paar Zugpferde auf die Lösung setzten, kann es auch ziemlich schnell gehen. Wir setzten jetzt mal auf KDE und GNOME. So oder so, wird es auf uns alle ankommen (inkl. dich und FreeBSD!) was passiert oder auch nicht passiert
... wird es möglich sein: Einfach Konfigurationswerte automatisiert über ein API setzen. Ohne windige Hilfskonstruktionen mit cat/grep/sed, ohne Pipe-Inception, und ohne Zusatzaufwand damit man die Originaldatei nicht einfach nullt. Idealerweise robust, so dass sich meine Skripte nicht nächste Woche schon wieder als kaputt herausstellen, weil man in der Configfile X ja im Randfall #y diesunddas noch soundso hätte escapen müssen.
Bei den unprofessionellen Spielzeugsystemen hat man sowas ja schon seit mind. einem Vierteljahrhundert. Das ist für den Turnschuhadmin. Der Unix-Techie reißt sich natürlich darum, sich nebenbei dauernd noch mit sowas auseinandersetzen zu dürfen. So kann er seine Skills in Regexps und Bash-Jongliererei ein bisschen schärfen; das kann man beim nächsten CCC-Congress dann schön seinen Buddies zeigen. Und dass man in seiner Fachdomäne nicht effizient weiterkommt, nunja, dafür findet sich dann schon immer irgendein Grund. Das ist dann die Zeit, die der Windows-Dev mit Visual Studio Updates verbrannt hätte.
Das ist eigentlich genau das, was Elektra ermöglicht. Es gibt ein C/C++ API sowie Bindings für einige andere Sprachen. Man kann Werte über ein CLI-Tool setzen oder mittels elektrad das REST HTTP API nutzen. Zudem gibt es ein QT-GUI sowie ein Webinterface um Konfigurationswerte komfortabel setzten zu können, ohne gleich selbst programmieren zu müssen.
Ja ich weiß - warten wir mal, wann sich das in der Breite durchgesetzt hat, und es einen Wert für den Admin hat. Bisher ist es eher etwas, womit der Entwickler sich ein paar Zeilen Code spart, und nicht mehr, oder? Einfach der Verbreitung wegen...
Wir arbeiten derzeit an der Verbreitung indem wir Elektra in KDE und GNOME integrieren. Diese Integrationen werden der Fokus der nächsten Versionen sein.
Es ist aber bereits jetzt möglich diverse Konfigurationsformate mit Elektra zu lesen und zu schreiben. Die erwähnten Schnittstellen stehen also zur Verfügung, auch wenn das Upstream-Projekt nicht Elektra nutzt.
Ich finde solche Ansätze wie Elektra total super. Keine Frage. Aber für mich ist der Ganze Kontext noch weit weg von Perfektion. Zuerst ist es mega cool, mal ein API zu haben, um Konfigurationsparameter zu setzen. So ein bisschen wie die "Registry" in Redmond (wenn auch backendseitig sogar imho besser organisiert).
Aber dann geht es ja weiter. Ich möchte gern automatisiert bspw. in KDE Elemente ins Panel einfügen. Das ist schon aktiver. Da gibt es dann irgendein DBUS-Interface, dem ich Javascript schicken kann. Leider alle paar Jahre mit Breaking Changes. Im Prinzip ist das aber ja auch eine Art Konfigurationsfrage.
Es wirkt auf mich vieles so, als hätte Windows uns in Sachen Automatisierungsfähigkeit schon lange abgehängt. Nur ein paar Träumer aus WinME-Zeiten sehen das noch als eine Unix-Stärke. Ich wüßte jetzt auch nicht, wie man dort die Taskbar anreichert; auch weil ich mich nicht damit befasse, weil ich kein Windows-System zu konfigurieren habe. Aber vieles geht dort heutzutage über gute alte COM-Interface, .NET Interop, usw usf. Am Ende des Tages nicht perfekt, aber okay. Der Unix-Guy fummelt sich mit sed etwas zusammen, was mit dem nächsten Release der Desktopumgebung hinüber ist. Der Linux-Guy speißt heute ein DBUS-Interface, indem es in irgendeinen String-Parameter ein Javascript reinwirft, was dann nicht funktioniert. Am Ende des Tages doch alles irgendwie eher sperrig und in die Jahre gekommen.
Konfiguration zentral in einer großen Datenbank speichern. Klingt erst mal gut, aber wenn es in der Windows-Registrierungsdatenbank zu einem kleinen Problem kommt, hat man schnell ein großes Problem mit dem gesamten Betriebssystem.
Jup und dann migrier das mal auf eine andere version, gibt schon einen grund weshalb mal windows nicht upgradet.
Seit spätestens Windows10 funktioniert das im "Regelfall" - sofern die Hardware-Unterstützung gegeben ist.
Dist-Upgrades seit Windows 10 ebenfalls. Selbst wenn hier etwas fehlschlägt, setzt das System den alten Zustand automatisch mit 2-3 Reboots wieder zurück. Man sollte jedoch zuvor 2-3 Monate nach einem neuen Release ins Land gehen, und zuvor seine Treiber und Applikationen auf aktuellen Stand bringen.
Seit Windows10 funktioniert das? Da schauen wir weiter wenn windows 11 rauskommt oder? Die 'upgrades' von Windows10 sind eher mit servicepacks vergleichbar.
>> Da schauen wir weiter wenn windows 11 rauskommt oder?
>> Die 'upgrades' von Windows10 sind eher mit servicepacks vergleichbar.
Wenn man keine Ahnung hat ...
So sag doch mal herr Microsoft insider?
Windows10 wurde als 'rolling-release' entworfen, im gegenteil zu den vorgaengern die als hauptversionen gesehen wurden, ess kann also sehr viel besser mit einem windowsxp sp1 bis sp2 verglichen werden wie ein win2000 zu einem xp...aber wenn man keine ahnung hat
Aber so wie es bisher aussieht wird es kein Windows 11 geben. Bei den Versionen von Win 10 soll Microsoft mal das so machen wie Apple, anders blickt da doch niemand mehr durch. Nutzes aber auch nicht mehr, also kann mir das egal sein.
Wieso? Hast du probleme mit buildversion 1034557? Sollen doch gleich den git-short-hash angeben
windows 10 funktionsupgrades mit service-packs vorheriger windows-versionen zu vergleichen zeugt nur von ihren unkenntnissen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Jun 2020 um 01:19.Einfach mal irgendwas zu sagen ohne fakten zu bringen zeugt von ihrem kindlichen verstand.
Eine Registrierdatenbank im Windows-Stil wäre auch mein Alptraum. Früher oder später ist das dann eine unaufgeräumte Müllhalde voller kryptischer Schlüssel- Werte-Paare mit wenig oder gar keiner Dokumentation und jeder Menge "Leichen".
Ich administriere meine Slackware im Wesentlichen mit dem Midnight Commander plus Mcedit und finde es aus Sicht eines eher unbedarften Nutzer hilfreich, dass in den Config-Files und in den Skripten Kommentare drin sind und teils auch inaktive (auskommentierte) Varianten, die man nur zu aktivieren braucht, wenn man die Funktionalität möchte.
Das mag auch Nachteile haben und mag auch etwas weniger "performant" sein, aber das ist mir wurscht, so lange es besser bedienbar ist.
Das beschreibt ungefähr die aktuelle Situation von freier Software. Z.b. wie viele der environment variablen sind tatsächlich dokumentiert? Wenn du mehr darüber wissen willst, lies mal hier und hier.
Elektra unterstützt genau diese Workflows, nur dass du dir selbst aussuchen darfst welches Format die Konfigurationsdateien haben und die Konfigurationen spezifiziert werden können (welche keys gibt es, welchen Typ haben sie usw. usf.).
Diese Frage trifft genau auf den Punkt und ist auch der Grund warum die Entwicklung nicht 10 Wochen sondern mehr als 10 Jahre gedauert hat. Die ersten Versionen von Elektra (die auch Linux Registry hießen) haben, auch wenn es anders behauptet wurde, doch noch einige Nachteile übernommen, insbesondere das es nur ein Backend gab, d.h., keine anderen Konfigurationsquellen integriert werden können. Die Modularität, die es derzeit gibt (jedes Programm schreibt seine Konfigurationsdatei und ist komplett unabhängig), zu erhalten war genau die große Herausforderung, die erst mit der 0.8 Serie von Elektra gelöst wurde.
Details zu all den Modularitäts und Kontextprobleme die Elektra jetzt löst gibt es im Buch über Elektra: book.libelektra.org.
>> Klingt erst mal gut, aber wenn es in der Windows-Registrierungsdatenbank zu einem kleinen Problem kommt, hat man schnell ein großes Problem mit dem gesamten Betriebssystem.
Seit 20Jahren (Windows 2000) hab ich bei mir im 24/7 Betrieb und bei dutzenden betrieblich genutzten Arbeitsplatz-PCs genau _0_ Probleme mit der Registrierungsdatenbank erlebt.
Also frage ich mich wie man zu einer solchen Aussage kommt. In der Praxis kenne ich nur solche Fälle wenn man irgendwelche Pfuschtools laufen lässt, die wild meinen dadrin "rumoperieren" zu müssen. Die Registrierungsdatenbank dient im Regelfall als zentrales Speicherbackend für das Betriebssystem und deren Anwendungen, nicht zum manuellen Editieren.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 29. Mai 2020 um 14:59.Naa, mit XP gab es schon manchmal noch probleme (vorallem vor sp2), aber alles in allem muss ich dir recht geben.
>> Das komplette KDE mittels Elektra zu konfigurieren ist ein Ziel, das bereits mit dem KDE-Projekt diskutiert wurde.
Das ich das noch auf die letzten PL-Tage erleben darf...
Vor etwa 15 Jahren als Lib-Elektra 0.1 hier noch unter anderm Namen erstmals beschrieben wurde, hatte ich genau das schon vorgeschlagen... inkl. Integration in Commandline-Tools wie vim/cat/less/grep/gawk etc pp ..
Damals wurde man dafür zerissen. Genauso wie für den Vorschlag Distroübergreifende (statische) Apps über externe Quellen per Mausklick nachinstallieren zu können... KDE/Plasma und/oder Apps via Mausklick aktualisieren zu können, anstatt auf die nächste Dist-Upgrade warten zu müssen... - inkl. Rollbacks bei Problemen.
15 Jahre später .... und es wird diskutiert das sowas kommen könnte - prima
Meinen Dank an die Elektra-Entwickler für das durchhalten gegen alle Wiedrigkeiten !
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 29. Mai 2020 um 01:43.Ohne das ich das Projekt im Detail kenne - bitte haltet es im Grunde "einfach", getreu dem KISS konzept.
KDE darf das gern machen, dann würde ich damit nie in Berührung kommen