Login
Newsletter
Werbung

Thema: Elektra 0.9.2 erschienen

32 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
mehr Go?
0
Von kraileth am Do, 28. Mai 2020 um 09:48 #

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

[
| Versenden | Drucken ]
  • 0
    Von markus23 am Do, 28. Mai 2020 um 10:19 #

    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

    [
    | Versenden | Drucken ]
    • 0
      Von kraileth am Do, 28. Mai 2020 um 13:08 #

      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.

      [
      | Versenden | Drucken ]
    0
    Von mpranj am Do, 28. Mai 2020 um 11:33 #

    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/ :)

    [
    | Versenden | Drucken ]
    • 0
      Von kraileth am Do, 28. Mai 2020 um 13:17 #

      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!

      [
      | Versenden | Drucken ]
    1
    Von klopskind am Fr, 29. Mai 2020 um 09:08 #

    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 :P
    Insofern viel Erfolg!

    Quellen:
    UCL Präsentation 2015 (Folien + Video)
    derzeitiger Upstream gemäß Ports samt kurzer Dokumentation weiterer technischer Details

    [
    | Versenden | Drucken ]
    • 0
      Von kraileth am Fr, 29. Mai 2020 um 11:05 #

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

      [
      | Versenden | Drucken ]
      0
      Von markus23 am Fr, 29. Mai 2020 um 11:47 #

      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.

      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.

      [
      | Versenden | Drucken ]
      • 0
        Von kraileth am Fr, 29. Mai 2020 um 12:42 #

        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.

        [
        | Versenden | Drucken ]
        • 0
          Von markus23 am Fr, 29. Mai 2020 um 13:21 #

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

          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 ;)

          [
          | Versenden | Drucken ]
0
Von Josef Hahn xh am Do, 28. Mai 2020 um 12:21 #

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

[
| Versenden | Drucken ]
  • 0
    Von mpranj am Do, 28. Mai 2020 um 13:10 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von Josef Hahn xh am Do, 28. Mai 2020 um 13:27 #

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

      [
      | Versenden | Drucken ]
      • 0
        Von mpranj am Do, 28. Mai 2020 um 14:19 #

        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.

        [
        | Versenden | Drucken ]
        • 0
          Von Josef Hahn xh am Do, 28. Mai 2020 um 14:44 #

          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.

          [
          | Versenden | Drucken ]
0
Von Atalanttore am Do, 28. Mai 2020 um 22:49 #

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.

[
| Versenden | Drucken ]
  • 0
    Von yugga am Fr, 29. Mai 2020 um 00:06 #

    Jup und dann migrier das mal auf eine andere version, gibt schon einen grund weshalb mal windows nicht upgradet.

    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Fr, 29. Mai 2020 um 10:17 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von markus23 am Fr, 29. Mai 2020 um 11:34 #

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

      [
      | Versenden | Drucken ]
    0
    Von markus23 am Fr, 29. Mai 2020 um 11:26 #

    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.

    [
    | Versenden | Drucken ]
    0
    Von Andre_001 am Fr, 29. Mai 2020 um 14:53 #

    >> 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.
    [
    | Versenden | Drucken ]
0
Von Andre_001 am Fr, 29. Mai 2020 um 01:42 #

>> 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.
[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Fr, 29. Mai 2020 um 10:19 #

    KDE darf das gern machen, dann würde ich damit nie in Berührung kommen ;)

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