Elektra - die Linux-Registry [Archiv]

BubbleBoy

2004-09-02, 14:11:07

Interview: Elektra, die Linux Registry
Von einem alten Unix-Nutzer für alte Unix-Nutzer

Auf der KDE-Konferenz stellt Avi Alkalay, Linux-Spezialist und Berater bei IBM, sein Projekt Linux Registry alias Elektra vor. Mit einem allgemeinen Backend für Text-Konfigurationsdateien will das Projekt eine einheitliche Registry für Linux etablieren. Die grundlegende Idee orientiert sich dabei zwar am Windows-Pendant, es sollen aber gezielt die Implementierungsschwächen der Windows Registry vermieden werden.

Golem.de: Worum geht es bei Linux Registry?

Avi Alkalay: Das Projekt soll eine Infrastruktur schaffen, die endlich den Albtraum der Linux-Konfiguration beseitigt. Programme sollen sich automatisch in das System integrieren, ohne dass der Nutzer eingreifen oder gar Konfigurationsdateien ändern muss.

Golem.de: Wie viele Personen sind an dem Projekt beteiligt?

Alkalay: Mehr als 30, es kommen viele Beiträge, Sprach-Bindings und andere Vorschläge.

Golem.de: Was ist denn falsch an der Art und Weise, wie Konfigurationsdateien heute gehandhabt werden? Du sagtest in deinem Vortrag, dass zur Verbesserung des Desktops die grundlegende Struktur des Betriebssystems weiterentwickelt werden muss, warum?

Alkalay: Im Desktop-Bereich ist viel passiert: ... weiter geht es hier (http://www.golem.de/0409/33343.html)

bluey

2004-09-02, 14:16:22

Jesus lass dies nicht passieren. Wo sonst können sich denn Spyware und co am besten verstecken?

Exxtreme

2004-09-02, 14:18:48

Jesus lass dies nicht passieren. Wo sonst können sich denn Spyware und co am besten verstecken?
Naja, heutzutage kann sich Spyware auch überall verstecken. Der Vorteil bei Linux ist, daß sich Spyware nicht so schnell einnisten kann. Ist sie aber einmal drin dann ist sie drin.

Gnafoo

2004-09-02, 19:39:23

Ja, kann er. Das wurde lange diskutiert und ist eine der Schwachstellen der Windows-Implementierung. Die Registry speichert ihre Informationen in einfachen Text-Dateien, die mit vi oder ed direkt bearbeitet werden können.

Das klingt doch ganz vernünftig imho. Dann ist es auch nicht so wie in Windows, dass alles in eine Mega-Datei "gepflatscht" wird :D

Im Prinzip finde ich es, wenn es richtig gemacht wird eine gute Idee. Dann sind grafische Config-Utilities etc. vernünftig möglich und alle Config-Dateien haben ein einheitliches Format. Außerdem sind die Konfigurationsdateien der einzelnen User ordentlich eingepflegt und liegen nicht im Home-Verzeichnis rum.
(imho sind diese dort etwas im Weg und passen nicht ganz dahin, weil das Home-Verzeichnis primär Daten speichert)

Wäre bloß noch zu hoffen, dass die Daten übersichtlich bleiben, etwa wie /etc im Moment und nicht in einem irrsinnig weit verzweigten Baum wie bei der Windows Registry, verloren gehen.
Nunja mal abwarten, ob es sich überhaupt etablieren kann.

Cya DerTod

Michbert

2004-09-02, 21:18:11

Für was denn eine Registry?
Das ist Sache der Distribution oder eben des Users und auch gut so das Programme da selbst nichts rumpfuschen...

Naja, heutzutage kann sich Spyware auch überall verstecken. Der Vorteil bei Linux ist, daß sich Spyware nicht so schnell einnisten kann. Ist sie aber einmal drin dann ist sie drin.Bei OpenSource-Software wird das allerdings etwas arg schwer unbemerkt Spyware reinzukriegen und einfacher rauskriegen kriegt man sie auch nirgendwo anderst, zudem oss entwickler sowieso kein Motiv und erst recht keine Gründe haben, wird das ganze noch einfacher. Ich versteh also dein letzten Satz nicht...

Nagilum

2004-09-02, 22:02:29

Für was denn eine Registry?
Den Artikel gelesen? Die Doku? Nein? Ich bin mal faul und setzt nur nen Link (http://elektra.sourceforge.net/#needs)

Das ist Sache der Distribution oder eben des Users und auch gut so das Programme da selbst nichts rumpfuschen...
Wenn Registry, dann müsste sie von allen beteiligten *Programmen* unterstützt werden. Aber schon alleine deshalb ist das Projekt wohl zum Tode verurteilt.

MadMan2k

2004-09-02, 22:50:21

find ich super die Idee mal endlich einen *einheitlichen* Standard festzulegen.
Das würde IMO auch deutlich das manual lesen einschränken, da man sich sofort in jeder Config datei zurechtfinden würde.

Eigentlich könnte man ja jetzt schon ne Registry (/etc - Explorer) schreiben, indem man einfach /etc mit rekursiv auliest und dann Baumartig darstellt - bloß bräuchte man dann für jedes PRogramm eine eigene Profil datei, damit die verschiedenen Speicherformate einheitlich dargestellt werden können...

Gast

2004-09-02, 23:37:28

Die Systemorganisation von UNIX wurde vor 30 Jahren designt. Sie hat viele Stärken, wie beispielsweise die Dateisystem-Hierarchie, für Konfigurationsdateien gibt es aber keine Festlegungen. Mit geht es dabei um ein einheitliches Format.

Exxtreme

2004-09-03, 00:29:48

Wenn Registry, dann müsste sie von allen beteiligten *Programmen* unterstützt werden. Aber schon alleine deshalb ist das Projekt wohl zum Tode verurteilt.
Naja, es reicht schon wenn die ganzen Toolkits angepasst werden. =)

Z.Zt. wird ein Mordsaufwand betrieben bezüglich Intergration. Da kapseln sich alle möglichen Toolkits gegenseitig mittels div. Bibliotheken etc.

Nagilum

2004-09-03, 00:51:55

Naja, es reicht schon wenn die ganzen Toolkits angepasst werden. =)
Welche Toolkits bitte?

Die wenigstens Programme nutzen z.Zt. überhaupt irgendwelche externen Bibliotheken zum Bearbeiten ihrer Config-Files, sondern bringen meist eigenen Lösungen mit.

Die müssten alle für Elektra angepasst werden

Exxtreme

2004-09-03, 00:58:56

Welche Toolkits bitte?

Die wenigstens Programme nutzen z.Zt. überhaupt irgendwelche externen Bibliotheken zum Bearbeiten ihrer Config-Files, sondern bringen meist eigenen Lösungen mit.

Die müssten alle für Elektra angepasst werden
Ich glaube, du hast gar nicht verstanden worauf ich hinaus wollte. ;(

Wenn du in z.B. Gnome die Schriftart änderst dann hat das keine Auswirkung auf QT-Applikationen. Ausser, du benutzt für deine QT-Anwendungen eine (wohl fiktive) Bibliothek, die QT kapselt. Das Problem ist, daß jedes Toolkit sein eigenes Süppchen kocht. Sowas würde mit einer zentralen Registry entfallen und man müsste sich nicht um solche Kleinigkeiten kümmern. Z.Zt. darfst du die Config-Tools für jedes Toolkit einzeln aufrufen und die Schriftart einstellen wenn du einen halbwegs einheitlichen Look willst.

Nagilum

2004-09-03, 01:11:21

Das Ändern der Schriftart unter Gnome würde auch mit Elektra keine Auswirkung auf deinen KDE Desktop haben.

Elektra stellt quasi nur eine Datenbank zur Verfügung in der man Schlüssel/Wert Kombinationen speichert. Sofern sich alle daran halten, eben auf einem einheitlichen Weg. Wie diese Werte dann genutzt werden, definiert Elektra NICHT.

Wenn sich also alle Entwickler auf die Verwendung von Elektra einigen könnten (was nie passieren wird), dann könnte man in einer *darüberliegenden* Schicht über eine gemeinsame Systemarchitektur nachdenken (was erst recht nicht passieren wird).

Hey, wir reden hier von Linux und OSS. Keine Chance.

Exxtreme

2004-09-03, 01:22:46

Natürlich setzt es voraus, daß sich die ganzen Programmierer einigen wie, wo, was benutzt wird. Das dürfte IMHO nicht so schwer sein. Die Distributoren dürften nämlich da ein großes Interesse haben. :) Und ich denke, daß auch die HW-Hersteller da nicht ganz unglücklich darüber wären.

Nagilum

2004-09-03, 01:26:18

Natürlich setzt es voraus, daß sich die ganzen Programmierer einigen wie, wo, was benutzt wird. Das dürfte IMHO nicht so schwer sein.
Scherzkeks. ;D

Exxtreme

2004-09-03, 01:30:39

Scherzkeks. ;D
Warum? Bisher gab es IIRC nichtmal halbherzige Versuche für sowas. Und wie gesagt, wenn sich die Coder der beiden großen Toolkits einigen dann ist schon vieles gewonnen.

Nagilum

2004-09-03, 01:38:39

Vor 2 bis 3 Jahren hatte schon einmal jemand eine Registy für Linux umgesetzt, inklusive Implementierung. Den Kerl hat man öffentlich ausgebuht. Heute kennt man nichtmal mehr den Projektnamen.

Komm, wir wissen doch beide wie das ablaufen wird:

Die Jungs von Gnome schmollen erstmal weil man nicht ihr "gconf" benutzt. Die KDE Jungs haben sowieso eine viel bessere Lösung im Ärmel. Bei Apache steht wieder eine Lizenz im Weg, und Sendmail hält sich für viel zu komplex für solch eine einfach Schlüssel/Wert Lösung.

Achja: Und deine Toolkits bringen hier doch nichts. Was soll auch ein Apache, XFree, procmail, mp3blaster, mutt, emacs bitte mit der Config-API von GTK oder Qt? Die haben alle eigene Lösungen.

Exxtreme

2004-09-03, 01:46:42

Der Typ hätte das Teil nicht "Registry" nennen sollen. :D Ausserdem wenn das Teil genauso scheisse war wie die Windows-Registry dann wundert es mich nicht wenn das nicht genommen wurde. Und ob die Standalone-Anwendungen ihre Sachen in der Registry speichern oder nicht, ist mir herzlich egal. Mir sind eher systemweite Einstellungen wichtig. Eben sowas wie Schriftarten, Netzwerkeinstellungen etc.

Gast

2004-09-03, 09:15:01

sehr gute idee die sich wohl net durchsetzen wird und gnu/linux irgendwann das genick bricht...

zentrale konfigurationsmöglichkeit in einer einheitlichen basis wär schon was feines, doch wie nagalium schon sagte...die einen schmollen, die andern ham sowieso was besseres usw.

schade drum

Ganon

2004-09-03, 09:28:29

Sorry, aber kann man /etc nicht als Registry ansehen? Statt eine Datei ist es halt ein Ordner, mit Textdateien, statt Schlüsseln. Die Werte sind die Zeilen in den Text-Dateien.

Ich seh da nicht das Problem.

Sorry, aber ich durchsuche lieber 3 Textdateien mit je 20 Zeilen, als eine Textdatei mit 60 Zeilen.

PrakashKC

2004-09-03, 09:42:07

Im aktuellen Design ist es Schwachsinn; denn alles in seperate Dateien zu stopfen macht das System sehr sehr langsam beim Zugriff auf die Schlüssel. Darauf kann ich echt verzichten. Gegen eine Vereinheitlichung hätte ich nichts, aber dann bitte etwas performantes.

Michbert

2004-09-03, 10:54:46

Den Artikel gelesen? Die Doku? Nein? Ich bin mal faul und setzt nur nen Link (http://elektra.sourceforge.net/#needs)Mhm, das hätt ich wohl mal tun sollen, kann damit aber trotzdem nicht viel anfangen und ich denke wie schon gesagt dabei wirds auch bleiben...

Gast

2004-09-03, 12:32:48

Sorry, aber kann man /etc nicht als Registry ansehen? Statt eine Datei ist es halt ein Ordner, mit Textdateien, statt Schlüsseln. Die Werte sind die Zeilen in den Text-Dateien.

Ich seh da nicht das Problem.

Sorry, aber ich durchsuche lieber 3 Textdateien mit je 20 Zeilen, als eine Textdatei mit 60 Zeilen.
nicht direkt und vorallem ist eben nichts "genormt"

Exxtreme

2004-09-03, 13:05:50

Sorry, aber kann man /etc nicht als Registry ansehen? Statt eine Datei ist es halt ein Ordner, mit Textdateien, statt Schlüsseln. Die Werte sind die Zeilen in den Text-Dateien.

Irgendwie schon. :)

Nur leider kocht da jeder Distributor ein eigenes Süppchen. Aber der Ordner /etc wäre IMHO ein optimaler Ort um so eine Registry unterzubringen. :)

Ganon

2004-09-03, 13:30:05

Naja. Die "Freiheit" die mit Linux immer genannt wird, wäre dann auch teilweise futsch.

Ich meine mir würde es nicht gerade gefallen, wenn mir einer Diktiert wie ich meine Konfigurationsdateien anzulegen habe...

Exxtreme

2004-09-03, 13:34:39

Naja. Die "Freiheit" die mit Linux immer genannt wird, wäre dann auch teilweise futsch.

Ich meine mir würde es nicht gerade gefallen, wenn mir einer Diktiert wie ich meine Konfigurationsdateien anzulegen habe...
Was du mit "deinen" Konfig-Dateien machst, ist hier egal. Wichtig sind die systemweiten Sachen. :)

Gast

2004-09-03, 13:41:40

Naja. Die "Freiheit" die mit Linux immer genannt wird, wäre dann auch teilweise futsch.

Ich meine mir würde es nicht gerade gefallen, wenn mir einer Diktiert wie ich meine Konfigurationsdateien anzulegen habe...
also wenn ich das richtig verstanden hab versteht sich die "linux regestry" nur als "frontend" bzw maske für die konfigurationsdateien, letzendlich kannst du auch mit regestry auf die eigentlich config files zugreifen wenn du willst,

c.p.d.

2004-09-03, 14:36:09

Im aktuellen Design ist es Schwachsinn; denn alles in seperate Dateien zu stopfen macht das System sehr sehr langsam beim Zugriff auf die Schlüssel. Darauf kann ich echt verzichten.

Dieser sogenannte "Schwachsinn" ist momentan Standard (jede Apps hat seine eingene config Datei). Duerfte also nicht langsamer werden.

Wenn ich den Typen im Interview richtig verstanden habe, gehts denen hauptsaechlich darum, dass nicht jedes Projekt viel Zeit fuer das Haendling von config Dateien aufwaenden muss.

Eigentlich ja eine tolle Idee, doch befuerchte ich, dass man ohne Frontend die Dateien nur schwerlich manuell editieren kann. Fertig waeren dann die Zeiten wo man mit vi und Commandozeile die confs editieren konnte. Duerfte den einten oder anderen Admin abschrecken :).

Exxtreme

2004-09-03, 15:22:39

Eigentlich ja eine tolle Idee, doch befuerchte ich, dass man ohne Frontend die Dateien nur schwerlich manuell editieren kann. Fertig waeren dann die Zeiten wo man mit vi und Commandozeile die confs editieren konnte. Duerfte den einten oder anderen Admin abschrecken :).
Doch, diese Config-Dateien sollen sich auch manuell editieren lassen mit einem Texteditor. :) Aus dem Grund gefällt mir die Idee ja auch so. Die Windows-Registry ist eine Binär-Datei. Wenn's die richtig zerschiesst und du kein Backup hast, darfst du neu installieren.

Nagilum

2004-09-03, 15:34:03

Wenn ich den Typen im Interview richtig verstanden habe, gehts denen hauptsaechlich darum, dass nicht jedes Projekt viel Zeit fuer das Haendling von config Dateien aufwaenden muss.
Nicht ganz. Es geht darum, alle Einstellungen global und einheitlich zu verwalten.

Heutzutage kann z.B. ein Programm A nur schlecht eine Einstellung von Programm B abfragen oder modifizieren. Dazu müsste es den Ort UND Aufbau der Konfigurationsdatei von B kennen und diese dann über einen eigenen Parser auswerten und möglicherweise wieder zurückschreiben. Das ist extrem aufwendig und fehleranfällig und wird deshalb auch so gut wie nie gemacht.

PrakashKC

2004-09-03, 17:24:22

@c.p.d

Jein, die Registry schlägt vor für jeden Schlüssel ne eigene Datei anzulegen, wie ich es verstanden habe. Das bigt dann Millionen von Dateien... AKtuell sind mehrer Schlüssel in einer Datei, darum ist es zur Zeit erträglich...

Gast

2006-07-15, 04:33:38

Nagilum[/POST]']Vor 2 bis 3 Jahren hatte schon einmal jemand eine Registy für Linux umgesetzt, inklusive Implementierung. Den Kerl hat man öffentlich ausgebuht. Heute kennt man nichtmal mehr den Projektnamen.

Exxtreme[/POST]']Der Typ hätte das Teil nicht "Registry" nennen sollen. :D

Dieses Projekt von diesem Typ hieß damals "Linux Registry" und
wurde später wegen dem Namen an dem sich viele störten in Elektra umbenannt.

Wir reden also heute über genau die Registry, die damals schon bekannt war. :)

Skullcleaver

2006-07-15, 08:14:24

Samba ist mittlerweile dabei. Suse und Fedora auch http://www.pro-linux.de/news/2006/9814.html

MadMan2k

2006-07-15, 10:41:09

Skullcleaver[/POST]']Suse und Fedora auch http://www.pro-linux.de/news/2006/9814.html
sie haben es bloß in die Repositories aufgenommen.

Gast

2006-07-15, 10:53:23

Habe ja nichts anders behauptet. Das ist aber sconmal ein Anfang

Lokadamus

2006-07-15, 11:10:49

Gast[/POST]']Habe ja nichts anders behauptet. Das ist aber sconmal ein Anfangmmm...

Ich hatte die Hoffnung, dass der Kram nie ein Erfolg wird. Ich weiß nicht, was daran so schwer sein soll, dass alle Configs unter /usr/etc/ abgelegt sind?

Welchen Vorteil soll ich davon haben, dass alles in einer Datei steht? Ich hab kein Bock 20 Seiten runterscrollen zu müssen, nur um zu merken, dass ich etwas neues installiert habe und jetzt noch 4 weitere Seiten scrollen darf und das alles in der Konsole ...

Gast

2006-07-15, 11:21:27

lies den Golem Artikel dazu dann wirst du verstehen wo der Unterschied liegt. Auch die nachfolgende Diskussion bei Golem durchlesen. Es ist weit mehr als einfach nur alles in eine Datei.

Gast

2006-07-15, 12:44:54

was für ein schwachsinn - gottseidank wird es aber sicher immer distros geben die das graffl ned einsetzen werden - freiheit sei dank

Lokadamus

2006-07-15, 14:20:53

Gast[/POST]']lies den Golem Artikel dazu dann wirst du verstehen wo der Unterschied liegt. Auch die nachfolgende Diskussion bei Golem durchlesen. Es ist weit mehr als einfach nur alles in eine Datei.mmm...

Den Artikel von Golem hab ich mir damals durchgelesen und heute auch wieder. Ich kann keinen Nutzen in dem Teil erkennen. Die Diskussion lese ich mir nicht durch, die ersten paar Kommentare sind mir zu bekannt und bis ich die interessanten finde, bin ich verhungert ;).

Anders gefragt, was wird dadurch besser? In der Theorie hört es sich toll an, in der Praxis gibt es längst Alternativen, die man vielleicht als Backend bezeichnen kann. Wegen KDE und Gnome sei hier mal Fluxbox reingeworfen oder wegen Samba und einigen anderen Sachen Webmin bzw. Yast.
Ich muss bei Samba schliesslich angeben, was ich wem freigeben will, aber ob der Kram jetzt in einer "Registry" oder unter /etc abgelegt wird ändert erstmal nichts daran, dass ich etwas einrichten muss. Schlimmer noch, anhand der Config- Dateien und der guten Beschreibungen kann ich immer sehen, was ich wo ändern soll. Wie sieht der Kram in der Registry aus? Genau die gleichen Bezeichnungen? Dann wurde das Rad nur neu erfunden und das kann nicht das Ziel sein ...

Ich mag FreeBSD, das hat unter /etc/ das Basissystem und unter /usr/lokal/etc/ landen die Configs für die einzelnen Programme.

Skullcleaver

2006-07-15, 18:59:03

Du meinst also durch eine einheitliche Norm die ermöglicht ohne großen aufwand die Programme untereinander kommunizieren zu lassen hat keine Vorteile?

Interessant.

Man kann sich auch alles schlecht redenw enn man will.

HellHorse

2006-07-15, 21:31:07

Skullcleaver[/POST]']Du meinst also durch eine einheitliche Norm die ermöglicht ohne großen aufwand die Programme untereinander kommunizieren zu lassen hat keine Vorteile?

Interessant.

Man kann sich auch alles schlecht redenw enn man will.
Hast du gelesen um was es geht?
Konfiguration nicht Kommunikation!

Gast

2006-07-16, 01:53:17

HellHorse[/POST]']Hast du gelesen um was es geht?
Konfiguration nicht Kommunikation!

LOL, Eigentor!!!!!!!!

Offensichtlich hast du nicht richtig verstanden.

Eine einheitliche Konfiguration ermöglicht nämlich die Kommunikation zwischen den Programmen.

Es geht im Kern also sehr wohl um die Kommunikation.

Beispiel gefällig?
Ok hier:
In Programm A kann ich die Sprache auf Deutsch umstellen.
Programm A merkt sich diese Einstellung in der eigenen Configdatei fürs nächste mal.
Bei Programm B kann ich genau das gleiche einstellen.
Auch Programm B merkt sich die Einstellung in der eigenen Configdatei.
Wenn ich jetzt aber den Desktop komplett auf Deutsch umstellen will
und das nur in Configdatei von Programm A mache,
dann hat Programm B davon keine Ahnung.

Sollte es diese Ahnung bekommen, dann müßte man für Programm B einen Parser
schreiben, der auch die Configdatei von Programm A auslesen kann.

Vereinheitlicht man die Konfiguration, dann können beide Programme auf
die Konfiguration des anderen Programmes über eine einheitliche Schnittstelle zugreifen.
Kurz gesagt, der Parser für Programm A kann auch die Konfigdatei von Programm B lesen, obwohl er dafür gar nicht gedacht war.

Geht man dann noch einen Schritt weiter, dann kann man in einem Schema festlegen,
daß es in diesem Konfigsystem einen globalen Eintrag gibt um den gesamten Desktop auf die Deutsche Sprache einzustellen.
Und solche Sachen sind wiederum bei einem einheitlichen Konfigsystem sehr einfach zu realisieren.

Fazit:
Die Kommunikation unter den Programmen wächst.
Es geht also im Kern um die Kommunikation der einzelenen Programme untereinander.

(del)

2006-07-16, 03:21:04

Der Tod[/POST]']Das klingt doch ganz vernünftig imho. Dann ist es auch nicht so wie in Windows, dass alles in eine Mega-Datei "gepflatscht" wird :D
Die Registry ist keine Megadatei. Oder wie heißt sie dann? Und sie wird mind. seit XP auch nicht komplett geladen.

Da ich aber einige Betriebssysteme im speziellen und die Registry im allgemmeinen kenne, wiederhol ich nur den Kommentar von bluey: "Jesus lass dies nicht passieren" :frown: :crazy2:

@Gast
Der Vorteil wäre also, daß ich ProgrammA auf englisch umstelle, ProgrammB auf französich und vom Desktop her kann ich sie beide - und alle anderen - mit einem Klick wieder auf deutsch umstellen. Und es wäre sogar möglich aus dem Gimp die Sofrt wieder auf deutsch umzustellen und damit automatisch auch Firefox und den Panel vom NV-Treiber. Ein Traum... :|

Skullcleaver

2006-07-16, 06:10:12

Ansich nicht mit einheitlichen Standards wäre das ohne Probleme denkbar. Es müsste sich nur jeder dran halten.

Lokadamus

2006-07-16, 07:44:02

Skullcleaver[/POST]']Du meinst also durch eine einheitliche Norm die ermöglicht ohne großen aufwand die Programme untereinander kommunizieren zu lassen hat keine Vorteile?Gast[/POST]']Beispiel gefällig?
Ok hier:
In Programm A kann ich ... dann hat Programm B davon keine Ahnung.

Sollte es diese Ahnung bekommen, dann müßte man für Programm B einen Parser schreiben, der auch die Configdatei von Programm A auslesen kann.

Vereinheitlicht man die Konfiguration, dann können beide Programme auf
die Konfiguration des anderen Programmes über eine einheitliche Schnittstelle zugreifen.
Kurz gesagt, der Parser für Programm A kann auch die Konfigdatei von Programm B lesen, obwohl er dafür gar nicht gedacht war.

Geht man dann noch einen Schritt weiter, dann kann man in einem Schema festlegen, daß es in diesem Konfigsystem einen globalen Eintrag gibt um den gesamten Desktop auf die Deutsche Sprache einzustellen.
Und solche Sachen sind wiederum bei einem einheitlichen Konfigsystem sehr einfach zu realisieren.
Fazit:
Die Kommunikation unter den Programmen wächst.
Es geht also im Kern um die Kommunikation der einzelenen Programme untereinander.mmm...

Nenn mich dumm, aber sowas ist heute auch möglich und ich wüsste nicht, das durch die Registry sich ändern würde.
Du quatscht einen Scheiß von einem Parser und denkst, durch XML wäre der Parser schon fertig :ucrazy:
Sorry, aber genauso wie bei den ach so komplizierten Textdateien muss auch dafür "der" Parser angepasst werden.
Im Nachhinnein ist die Registry nichts anderes als eine Monstrumgui, welche schon jetzt möglich wäre. Für die krumme Verzeichnisstruktur von Linux kann ich nichts, BSD hat schon seit langer Zeit gezeigt, wie man sowas gut lösen kann.
Und noch einmal: Was ist der Vorteil???
Hier werden als Beispiel nicht vorhandene Variablen gezeigt, toll. Wie ich schon gesagt habe, nenn mich dumm, aber ausser, dass die Registry bestimmte Formate vorgibt, um überhaupt zu funktionieren kann ich keinen Vorteil erkennen und das ist KEIN Vorteil, sondern ein gern gemachter Fehler ...

HellHorse

2006-07-16, 11:00:18

Gast[/POST]']LOL, Eigentor!!!!!!!!

Offensichtlich hast du nicht richtig verstanden.

Eine einheitliche Konfiguration ermöglicht nämlich die Kommunikation zwischen den Programmen.

Es geht im Kern also sehr wohl um die Kommunikation.
Typisches Gastposting. Unsinn pur, ich habe keine Ahnung warum ich auf solchen Müll überhaupt eingehe.

Gast[/POST]']
Beispiel gefällig?
Ok hier:
In Programm A kann ich die Sprache auf Deutsch umstellen.
Programm A merkt sich diese Einstellung in der eigenen Configdatei fürs nächste mal.
Bei Programm B kann ich genau das gleiche einstellen.
Auch Programm B merkt sich die Einstellung in der eigenen Configdatei.
Wenn ich jetzt aber den Desktop komplett auf Deutsch umstellen will
und das nur in Configdatei von Programm A mache,
dann hat Programm B davon keine Ahnung.

Sollte es diese Ahnung bekommen, dann müßte man für Programm B einen Parser
schreiben, der auch die Configdatei von Programm A auslesen kann.

Vereinheitlicht man die Konfiguration, dann können beide Programme auf
die Konfiguration des anderen Programmes über eine einheitliche Schnittstelle zugreifen.
Kurz gesagt, der Parser für Programm A kann auch die Konfigdatei von Programm B lesen, obwohl er dafür gar nicht gedacht war.
So ein Bullshit. Wenn schon will man das ganze systemweit festelegen.
Gast[/POST]']
Geht man dann noch einen Schritt weiter, dann kann man in einem Schema festlegen,
daß es in diesem Konfigsystem einen globalen Eintrag gibt um den gesamten Desktop auf die Deutsche Sprache einzustellen.
Und solche Sachen sind wiederum bei einem einheitlichen Konfigsystem sehr einfach zu realisieren.
Ui, lustigerweise geht das schon. Über die locale. Und das ist aber nichts, dass man parsen müsste, sondern einfach ein String. Wiedereinmal ein Gast, der von Linux nur weiss, dass es schlechter als Windows ist.
Gast[/POST]']
Fazit:
Die Kommunikation unter den Programmen wächst.
Es geht also im Kern um die Kommunikation der einzelenen Programme untereinander.
Für Komminukation unter Programmen gibt's neben den üblichen IPC Geschichten auch so Sachen wie DBUS.
Kommunikation über die Registry. Ja nee, is klar.

Gast

2006-07-16, 17:03:30

Lokadamus[/POST]']mmm...

Nenn mich dumm, aber sowas ist heute auch möglich und ich wüsste nicht, das durch die Registry sich ändern würde.
Du quatscht einen Scheiß von einem Parser und denkst, durch XML wäre der Parser schon fertig :ucrazy:

Du bist derjenige der hier einen Scheiß zusammenquatscht.
Offensichtlich hast du Elektra nichtmal begriffen.

Heute ist so etwas nur dann möglich, wenn dein Konfig Programm
sowohl die Konfigdatei von Programm A als auch von Programm B lesen
und bearbeiten kann.
Heutzutage hat nämlich jedes Programm seine eigene Configsyntax.
Dazu brauchst du in deinem Konfig Programm schonmal 2 verschiedene Parser
die natürlich den Programmcode aufblähen und die Wahrscheinlichkeit von Fehlern im Konfigprogamm ansteigen läßt (Yast läßt grüßen, da kennen wir das ja schon, man klickt auf Auflösung wechseln, Yast zeigt das dann auch so an, aber es passiert nichts)

Wenn du die Konfiguration aller Programme auf eine einheitliche Syntax abstimmst,
was bei Elektra passiert, dann brauchst du nur noch einen einzigen Parser für alle Programme um auf die Konfigurationsdaten zuzugreifen und diese zu bearbeiten.
Diese Rolle übernimmt z.B. die libelektra.so Library.

Sorry, aber genauso wie bei den ach so komplizierten Textdateien muss auch dafür "der" Parser angepasst werden.

Nein, muß er nicht.
Da die Syntax bei allen Konfigdateien dann die selbe ist.
Du mußt nur noch sagen, welchen Konfigwert du haben willst und der
Parser liest dir das dann aus.

Im Nachhinnein ist die Registry nichts anderes als eine Monstrumgui,

Falsch.
Elektra ist keine GUI.
Es ist eine einheitliche Schnittstelle um auf ein einheitliches Konfigurationssystem zuzugreifen.

welche schon jetzt möglich wäre.

Das was du meinst nennt sich Yast.

Und Yast wird mit 10000 Parsern geliefert, weil jedes Scheiß Programm
seinen eigenen Stil und seine eigene Syntax für einen Configdatei verwendet.
/etc/fstab ist anders als /etc/X11/xorg.conf.
xorg.conf ist komplett anders als host.conf
host.conf ist komplett anders als apache/httpd.conf

Was für ein Dreck!

Und wegen diesem ganzen Dreck ist Yast auch so unzuverlässig und läßt einem
genau dann im Stich wenn man es braucht.
Die Anzahl der Fehlerquellen steigt nämlich mit der Anzahl der verschiedenen Parser
die man bei dem derzeitigen Configdreck benötigt um alle Konfigurationsdateien zu bearbeiten.

Und noch einmal: Was ist der Vorteil???

Das solltest du jetzt eigentlich aus den von mir gerade oben angeführten Problemen
mit dem derzeitigen Chaoszustand entnehmen und erkennen können.

Gast

2006-07-16, 17:14:19

HellHorse[/POST]']Typisches Gastposting. Unsinn pur, ich habe keine Ahnung warum ich auf solchen Müll überhaupt eingehe.

Das ist also die Antwort auf deine Niederlage?

So ein Bullshit. Wenn schon will man das ganze systemweit festelegen.

Elektra IST systemweit.

Ui, lustigerweise geht das schon. Über die locale.

Die natürlich nicht von jedem Programm ausgelesen wird.
Komischerweise gibt es Programme in denen man explizit die Sprache
extra einstellen muß und diese Einstellung wird dann nur in der Konfigurationsdatei
dieser Anwendung gespeichert.
Änderst du dann deine Locale Variable dann ändert sich bei dieser Anwendung genau gar nichts.

Oder noch besser.
Setze mal den Defaultbrowser in Gnome auf Firefox.
Danach starte eine KDE App wie Kivio und klicke auf Bug einreichen.
Kivio wird dir versuchen den Browser Konqueror aufzurufen, dabei hätte es firefox sein sollen.
Schöner Dreck!

BTW: für den Defaultbrowser gibt es noch keinen einheitlichen Zugriffspfad
wie z.b. bei Locale und Locale selbst wird viel zu selten benutzt, siehe oben.

Und von der Programmierung her gesehen mußt du die Localvariable natürlich extra
abfragen, dazu muß Code in den Programmcode der das kann
und der ist natürlich etwas größer als nur get_locale.
Wenn eine App aber Elektra verwendet, dann reicht ein get_key(/system/locale)

ür Komminukation unter Programmen gibt's neben den üblichen IPC Geschichten auch so Sachen wie DBUS.

Lies mal die Doku zu Elektra.
DBUS steht dir viel zu spät zur Verfügung.
Da muß erstmal ein ganzer Rattenschwanz während dem Bootprozess gebootet werden.

Gast

2006-07-16, 17:19:02

Und noch etwas.

Die Probleme die Yast hat löst DBUS natürlich auch nicht.

Spearhead

2006-07-16, 17:42:37

also als ich mir die Präsentation da mal angeschaut hab, geht es mehr darum, das Programme ihre Config-Dateien zur Zeit je nach Distribution in verschiedenen Verzeichnissen haben und je nach Aufbau relativ schlecht lesbar sind.

Der Ort der Konfigurationsdaten soll über Elektra an einer zentralen Stelle sein, damit man sie leichter wiederfindet und halt auch über eine GUI zentral bearbeitbar sein.

Ob die Lesbarkeit wie in diesem einen Screenshot mit dem groß verzweigten Baum aber wirklich besser ist, na ich weiß nicht

So versteh ich das zumindest in Kurzform.

Gast

2006-07-16, 17:54:28

MadMan2k[/POST]']@Gast
du hast sowas von keine Ahnung, dass es schon nicht mehr lustig ist, sondern nur noch weh tut.
Also hör bitte auf, bevor noch wer Schmerzensgeld verlangt ;)

Du hast schiss, du befürchtest das Elektra sich durchsetzen könnte,
deswegen willst du das ich nichts mehr positives über Elektra sage.
Echte Argumente und insbesondere warum ich keine Ahnung haben sollte,
hast du bis jetzt noch nicht geliefert.

Es ist schlichweg deine Furcht vor etwas neuem.
Nimm dich in Acht, Linux (damit meine ich das das gesamte System, nicht nur den Kernel)
wird sich in den nächsten 10 Jahren noch weiter verändern.
Und Fortschritt läßt sich nicht aufhalten.

Gast

2006-07-16, 18:01:18

Spearhead[/POST]']also als ich mir die Präsentation da mal angeschaut hab, geht es mehr darum, das Programme ihre Config-Dateien zur Zeit je nach Distribution in verschiedenen Verzeichnissen haben und je nach Aufbau relativ schlecht lesbar sind.

Ja, soweit ist das richtig.

Der Ort der Konfigurationsdaten soll über Elektra an einer zentralen Stelle sein, damit man sie leichter wiederfindet und halt auch über eine GUI zentral bearbeitbar sein.

Das erste ist richtig.
Die Gui ist ein zwangsläufig folgender postiver Nebeneffekt (aber nicht unbedingt notwendig), da mit einer einheitlichen Konfigurationssysntax mit Baumstruktur sich jedes
Schlüssel-/Wertepaar über eine einzige GUI verwalten lassen läßt.
Notwendig ist die GUI aber wie schon gesagt nicht, die ist eine zusätzliche Beigabe.

Natürlich kann jedes Programm weiterhin seine eigene Oberfläche für Einstellungen haben.
Die Abfrage von global notwendigen Konfigurationsdaten wie Defaultbrowser, Defaultdrucker, Abfrage der Auslösung etc. wird aber für alle Programme einfacher.

Ob die Lesbarkeit wie in diesem einen Screenshot mit dem groß verzweigten Baum aber wirklich besser ist, na ich weiß nicht

Das spielt keine große Rolle, da wie schon gesagt diese Baumansichtgui nicht zwangsläufig notwendig ist.
Du kannst die Konfigration einer Anwendung natürlich auch in eine schöne grafische
Oberfläche oder einen Wizard packen.
Entscheident ist der drunterliegende Aufbau.

Echte Programmierer werden verstehen was ich meine und auch den Vorteil sehen.

Lokadamus

2006-07-16, 18:03:08

Gast[/POST]']1.) Offensichtlich hast du Elektra nichtmal begriffen.
2.) Heutzutage hat nämlich jedes Programm seine eigene Configsyntax.
Dazu brauchst du in deinem Konfig Programm schonmal 2 verschiedene Parser
die natürlich den Programmcode aufblähen und die Wahrscheinlichkeit von Fehlern im Konfigprogamm ansteigen läßt (Yast läßt grüßen, da kennen wir das ja schon, man klickt auf Auflösung wechseln, Yast zeigt das dann auch so an, aber es passiert nichts)

3.) Wenn du die Konfiguration aller Programme auf eine einheitliche Syntax abstimmst, ... Blablabla bis zum Ende ...mmm...

1.) Nein, ich warte immernoch auf ein schönes Beispiel. Da du Elektra schon am laufen hast, kannst du doch garantiert zeigen, wie Hosts, resolv.conf und ein paar andere Dateien bei dir abgespeichert sind ...
2.) Äh ja und? Das wird sich mit Elektra und was weiß ich nicht auch nicht ändern. Apache braucht nunmal sein eigenes Verzeichnis und das wirst du ihm mit Elektra auch nicht wegnehmen können. Schon braucht das dumme Programme wieder eine eigene Variable, so ein Dreck aber auch ;) ...
3.) Das hab ich oben schon geschrieben und man könnte auch sagen, sie sind einheitlich. Ich kenne keine Config, die ein anderes Format wie Textformat hat. Entweder sind die Sachen auskommentiert oder es sind Parameter/ Variablen, ganz einfach. Also, was ist daran "fremd"?
Das wegen der Auflösung kann ich nicht nachvollziehen. Bisher waren es dann allgemeine Config- Fehler und da liegt der Fehler nicht bei Yast, sondern der Hardwareerkennung. Liegt vielleicht auch daran, dass ich zu wenig mit Suse mache, um auf echte Probleme, die über "TFT != CRT" hinaus gehen, zu kennen ...Gast[/POST]']4.) Die natürlich nicht von jedem Programm ausgelesen wird.
Komischerweise gibt es Programme in denen man explizit die Sprache
extra einstellen muß und diese Einstellung wird dann nur in der Konfigurationsdatei
dieser Anwendung gespeichert.
Änderst du dann deine Locale Variable dann ändert sich bei dieser Anwendung genau gar nichts.

5.) Oder noch besser.
Setze mal den Defaultbrowser in Gnome auf Firefox.
Danach starte eine KDE App wie Kivio und klicke auf Bug einreichen.
Kivio wird dir versuchen den Browser Konqueror aufzurufen, dabei hätte es firefox sein sollen.
Schöner Dreck!
BTW: für den Defaultbrowser gibt es noch keinen einheitlichen Zugriffspfad
wie z.b. bei Locale und Locale selbst wird viel zu selten benutzt, siehe oben.4.) Eventuell ist es aber auch gewollt, dass sich nichts daran ändert. Mir ist zwar klar, dass das dein Paradebeispiel ist, aber gewisse Sachen überlege ich mir vorher und ändere sie danach nicht mehr. Ich weiß nichtmal, wozu MS die Funktion integriert hat, wobei mir klar ist, das Leute wie du sowas dringend brauchen. In der Realität sieht es aber eher so aus, dass einige die Sprache umgeändert haben, ohne es zu wollen, danke ...
5.) Funktioniert es oder ist es nur ein theoretisches Beispiel?

Also, das einzige, was ich bisher sehe, ist höchstens, dass du dich darüber beklagst, dass viele Programmierer nicht alles mögliche abfragen und ich denke, selbst wenn du ein Gerüst hinstellst, werden nicht alle Sachen so benutzt, wie du es dir wünscht ...

MadMan2k

2006-07-16, 18:14:36

Gast[/POST]']
Echte Argumente und insbesondere warum ich keine Ahnung haben sollte,
hast du bis jetzt noch nicht geliefert.
mit deinem locales Beispiel hast du gezeigt, dass du keine Ahnung ahst was POSIX ist.

Gast[/POST]']Du hast schiss, du befürchtest das Elektra sich durchsetzen könnte,
deswegen willst du das ich nichts mehr positives über Elektra sage.
das ist es ja, bis jetzt ahst du noch nix positives über elektra gesagt und auf das Problem, dass kleine Programme simple Konfigurationsdateien und nen simplen Parser dafür brauchen während große komplexe Konfigurationsdateien/ Parser brauchen und sich beides schelcht unter eien Hut bringen lässt bist du nicht eingegangen.
Ebensowenig darauf, dass man mit nem RDB-FS gleich namespaces für config-files haben könnte...

Lokadamus

2006-07-16, 18:18:57

Spearhead[/POST]']also als ich mir die Präsentation da mal angeschaut hab, geht es mehr darum, das Programme ihre Config-Dateien zur Zeit je nach Distribution in verschiedenen Verzeichnissen haben und je nach Aufbau relativ schlecht lesbar sind.

Der Ort der Konfigurationsdaten soll über Elektra an einer zentralen Stelle sein, damit man sie leichter wiederfindet und halt auch über eine GUI zentral bearbeitbar sein.

Ob die Lesbarkeit wie in diesem einen Screenshot mit dem groß verzweigten Baum aber wirklich besser ist, na ich weiß nicht
So versteh ich das zumindest in Kurzform.mmm...

:| ...
http://img65.imageshack.us/img65/9889/freebsdtreedi2.th.png (http://img65.imageshack.us/my.php?image=freebsdtreedi2.png)
Also, ich finde das so eigentlich sehr zentral :). Kannst du auch erraten, was ich installiert habe? ;) ...

Spearhead

2006-07-16, 18:23:13

@Lokadamus: Ja, etwas um das es eigentlich weniger geht bei Elektra, ein BSD, kein Linux :-p

Gast

2006-07-16, 18:50:21

Lokadamus[/POST]']mmm...

1.) Nein, ich warte immernoch auf ein schönes Beispiel. Da du Elektra schon am laufen hast, kannst du doch garantiert zeigen, wie Hosts, resolv.conf und ein paar andere Dateien bei dir abgespeichert sind ...

Auf der Elektra Webseite gibt es ein Beispiel zur xorg.conf Datei, wie die in Elektra umgesetzt ist.
Im Prinzip hast du ein Verzeichnis Elektra genannt,
darin liegen weitere Verzeichnisse und Dateien.
In den Dateien befindet sich dann ein Schlüssel/Werte Paar.
Schlüssel -> dns1
Wertepaar -> 80.23.45.1

Auf diesen Schlüssel greifst du dann über einen Pfad zu:
system/net/dns1

Im Programmcode kannst du also über eine Funktion von libelektra sagen welchen Key du lesen willst ,in dem du einfach den Pfad angibst.
Dann kannst du noch bestimmen was du von dem Key haben willst.
Also z.b. den Namen des Keys oder den Wert oder dessen Kommentar etc..

Konfigurationsdaten für Benutzer fritz werden dabei in
user/fritz/
abgelegt.

FÜr Benutzer roland gibt's dann
user/roland

Globale Softwarekonfigurationen landen in
system/sw/

Für xorg z.B.
system/sw/xorg

Für Firefox z.B.
system/sw/firefox

Für den Benutzer fritz würden dann eigene Einstellungen zu Firefox
in
user/fritz/sw/firefox
stehen.

Z.b.
usr/fritz/sw/firefox/javascript

Und darin steht dann der Keyname, also was, der Wert und ein Kommentar:
javascript = enabled, "This is the option to enable disable javascript"

2.) Äh ja und? Das wird sich mit Elektra und was weiß ich nicht auch nicht ändern.

Doch, die Programme werden an Elektra angepaßt werden und Elektra verwenden.
Freie Software kann man nämlich nach seinen eigenen Wünschen anpassen und
zur Not forken, falls ein Projektmaintainer keine ifdef(Elektra) Anweisungen
für eine Anpassung an eine Elektra Konfiguration in seinem Programmcode haben will.

Apache braucht nunmal sein eigenes Verzeichnis und das wirst du ihm mit Elektra auch nicht wegnehmen können.

Apache kriegt
system/sw/apache/
Darin kann es dann alle Apachespezifischen Konfigoptionen setzen,
die Apache braucht.
Daten wie HOSTNAME und Co kann Apache von einem zentralen systemweiten Ort holen,
z.b.
system/net/hostname

Schon braucht das dumme Programme wieder eine eigene Variable, so ein Dreck aber auch ;) ...

Nö.

3.) Das hab ich oben schon geschrieben und man könnte auch sagen, sie sind einheitlich. Ich kenne keine Config, die ein anderes Format wie Textformat hat. Entweder sind die Sachen auskommentiert oder es sind Parameter/ Variablen, ganz einfach. Also, was ist daran "fremd"?

Dazu muß man halt schonmal programmiert haben um das zu verstehen.

Nimm z.b. die xorg.conf.
Die ist in Sektionen eingeteilt.
In den Sektionen gibt es dann Key = Value Paare.
Das mit den Key = Value Paare ist einfach.
Die Komments auch, aber das mit den Sektionen, daß muß dein
Parser können.

Dann nimm die /etc/fstab die hat gar keine Key = Value Paare,
sondern da stehen die Einträge in Zeilen drin, welche durch
Leerzeichen getrennt sind.
Auch das muß dein Parser können und er muß erkennen,
was jetzt eine Option (z.b. users,ro,gid=323 etc.) ist und wie man die ausliest,
z.b. bei gid=323 und er muß natürlich wissen, was davon der Devicepfad ist.

Natürlich kann man jetzt hergehen und einen spezialisierten Parser schreiben,
der die fstab ausliest und auch beherrscht.
Aber jetzt nimm genau den selben Parser und bearbeitet damit die xorg.conf.
Das geht schon nichtmehr, den von Sektionen hat er keine Ahnung
und Schlüssel = Werte kennt er auch nur von Sachen wie gid=xxx.

Und da wir jetzt schon dabei sind, wollen wir mit dem gleichen Parser noch die resolv.conf auslesen.
Da man man dann zwar ein Schlüssel Werte Paar:
nameserver 133.45.2.44
, aber im Gegensat zur xorg.conf
kommt es ohne Anführungszeichen aus.
Identifier "nvidia"
DAS muß der Parser dann wieder berücksichtigen.

Das wird also so richtig schön komlex, deswegen bestet YAST aus einer Sammlung von
Parsern die meist alle jeweils auf eine ganz bestimmte Configdatei spezialisiert sind.

Tja, und dann gibt es natürlich auch wieder Configdateien, die
benutzen zur Bestimmung von Schlüssel Werte Paare weder
ein Leerzeichen noch ein Anfürhungszeichen, sondern benutzen dabei
einfach ein = Zeichen.
Schlüssel = wert
Oder = Zeichen + Anführungszeichen:
Schlüssel = "Wert"

Das wegen der Auflösung kann ich nicht nachvollziehen. Bisher waren es dann allgemeine Config- Fehler und da liegt der Fehler nicht bei Yast, sondern der Hardwareerkennung.

Es gab schon Fälle, da war das in einer Suse Version ausgelieferte Yast
beim bearbeiten der Xfree Configdatei fehlerhaft.

.4.) Eventuell ist es aber auch gewollt, dass sich nichts daran ändert.

Oft liegt es auch einfach an der Faulheit des Programmieres,
das ist jetzt nicht abwertent gemeint sondern schlichtweg eine feststellung.
Ein Programmierer hat in der Regel nämlich für sein Programm schon einen
eigenen Parser geschrieben zur Bearbeitung der Konfiguration seines Programms.
Die Locale Variable herauszufinden ist aber wieder extra Arbeit, also geht man einfach her
und legt die Sprache in der eigenen Konfigurationsdatei fest.
Das geht schneller, denn man kann schon auf den bereits geschriebenen Parser zurückgreifen.

Im Thread gab es hier weiter oben ein Dummposting, in dem einer meinte,
Programm A auf französisch und Programm B auf deutsch einstellen zu müssen.
So ein Schwachsinn macht kein Mensch.
Entweder man stellt den gesamten Desktop auf Deutsch ein, weil man Deutsch so gut kann,
oder man stellt den gesamten Desktop auf Französisch sein.
Und selbst wenn das mal bei Ausnahmen sinnvoll sein mag, z.b. Computerspiele,
können solche Anwendungen ihre Sprache immer noch in ihrem
eigenen Konfigurationpfad festlegen.
Dabei sollte natürlich so ein Computerspiel so intelligent sein, erstmal den Systemweiten Defaultwert zu übernehmen bzw. das eigene Feld leerlassen und erst bei expliziten Bedarf
das im eigenen Konfigurationspfad, auf Wunsch des Users festlegen.
Und diesen Defaultwert muß es natürlich kennen, hier hilft wiederum so etwas wie Elektra.

Mir ist zwar klar, dass das dein Paradebeispiel ist, aber gewisse Sachen überlege ich mir vorher und ändere sie danach nicht mehr.

Schön, machst du das auch beim Defaultbrowser so?
Also ich habe von Mozilla auf Firefox gewechselt, als Firefox 1.5 rauskam.

5.) Funktioniert es oder ist es nur ein theoretisches Beispiel?

Das Problem mit Kivio und Konqueror anstatt Firefox besteht wirklich.
Ich bin darauf durch Zufall gestoßen.
Im Prinzip betrifft es sogar fast jede KDE App, wenn man Gnome benutzt und
nicht extra auch noch in KDE den Defaultbrowser auf Firefox umgestellt hat.
Das müßte man nämlich machen um das Problem zu lösen.
Es gibt nämlich diese Defaultbrowsereinstellung nur innerhalb der beiden Desktops.
KDE hat ne eigene Einstellung dafür und Gnome auch.

Wer jetzt nur Gnome als Desktop nutzt und ab und zu ein KDE Protgramm aufruft hat also schonmal ein Problem, da der Defaultbrowser für KDE zu Beginn immer Konqeror ist.

Also, das einzige, was ich bisher sehe, ist höchstens, dass du dich darüber beklagst, dass viele Programmierer nicht alles mögliche abfragen und ich denke, selbst wenn du ein Gerüst hinstellst, werden nicht alle Sachen so benutzt, wie du es dir wünscht ...

Wie ich schon sagte, um loale Abfragen ist ein Mehraufwand notwendig.
Beim Defaultbrowser wir das noch extremer, erst recht, wenn man weder eine Gnome, noch eine KDE Anwendung schreibt. Man müßte nämlich die Defaultbrowserkonfiguration von Gnome UND KDE abfragen.
Das ist alles Mehrarbeit die nur die wenigsten Programmierer machen wollen.

Mit einer Systemweiten Konfig, auf man auch noch mit einer einheitlichen API zugreifen kann, wird das ganze sehr sehr viel bequemer und einfacher.
Und wenn etwas einfach, schnell und bequem ist, dann ist der Weg nicht mehr weit,
daß das Feature auch genutzt wird.

Gast

2006-07-16, 19:05:49

MadMan2k[/POST]']mit deinem locales Beispiel hast du gezeigt, dass du keine Ahnung ahst was POSIX ist.

Aha, und viele Programme nutzen trotzdem kein locale. Dummschwätzer!

das ist es ja, bis jetzt ahst du noch nix positives über elektra gesagt

Dann kannst du nicht lesen oder hast schlichweg gar nichts von meinen Postings gelesen.

und auf das Problem, dass kleine Programme simple Konfigurationsdateien und nen simplen Parser dafür brauchen während große komplexe Konfigurationsdateien/ Parser brauchen und sich beides schelcht unter eien Hut bringen lässt bist du nicht eingegangen.

Das wurde als Problem überhaupt nicht angeführt.

Und mit Elektra ist das kein Problem, weil sowohl das kleine Programm
als auch das große Programm das selbe Konfigurationsystem, also Elektra nehmen können.
Der einzige Unterschied besteht doch lediglich darin, daß das große Programm mehr
Key = Value Paare benötigt.

Ebensowenig darauf, dass man mit nem RDB-FS gleich namespaces für config-files haben könnte...
RDBs haben wieder andere zum Teil sehr schwerwiegende Probleme.
Z.b.wenn die db kaputt geht, dann wäre dein System nicht mehr benutzbar.
Und eine RDB läßt sich auch nicht mit vi bearbeiten, dies sollte aber mit Elektra immer noch möglich sein.

Elektra benutzt deswegen das Dateisystem, da dieses noch am robustesten ist.
Wenn da nur eine Datei kaputt geht, dann ist das nicht so tragisch, der Rest geht ja noch.
Und simple Dateien in denen nur key = wertepaare + Kommentar stehen lassen sich auch mit jedem beliebigen Editoren bearbeiten.
RDBs haben übrigens noch einen weiteren Nachteil, sie stehen erst zu einem sehr späten Zeitpunkt nach dem booten zur Verfügung.

Übrigens wer will kann für Elektra natürlich auch eine RDB nehmen, ein Backend ist
dafür ja in Arbeit, aber als Basis setzt man grundsätzlich erstmal nur auf das Dateisystem.

Gnafoo

2006-07-16, 19:14:02

Bleibt doch bitte erstmal bei einem weniger garstigen Diskussionston ;).

Also ich finde eigentlich, dass unser Gast vollkommen recht hat. Elektra bietet imho eine Menge Vorteile. Was mir spontan einfällt wäre:
1. Eine saubere zentrale Datenbasis für Einstellungen.
2. Ein einheitliches Datenformat.
3. Eine Library zum problemlosen Zugriff.
4. Flexibilität der tatsächlichen Datenspeicherung (Backends).
5. Plattformunabhängigkeit (Backends für Windows, welche die Win-Registry nutzen z.B.) um Programme einfach zu portieren.

Für den Endanwender mag es zur Zeit nicht viele Vorteile geben, wohl aber für einen Programmierer. Parser für die Konfigurationsdateien kann man sich damit sparen, Systemeinstellungen sind zentral ohne weiteres abzurufen, ohne dass man alle möglichen Kleinigkeiten berücksichtigen muss etc.
Aber auch für den Endanwender wird es auf längere Sicht einen Usability-Vorteil bringen, weil Tools wie Yast etc. wesentlich einfacher zu realisieren sind und auch deutlich weniger Fehleranfällig sind.

Der Grund ist eigentlich einfach: Die Konfigurationsdateien wie sie im Moment sind, sind primär für den Menschen gemacht und sie einfach zu editieren. Zur automatischen/maschinellen Verarbeitung sind sie allerdings ziemlich ungeeignet. Das ist aber für viele Dinge eine wichtige Voraussetzung. Elektra dreht das um und ermöglicht es zudem einfach Konfigurationstools zu schreiben, welche weiterhin die Möglichkeit bieten die Konfiguration manuell und einfach zu verändern. Wenn alles sauber implementiert ist, wird das auch nicht wie in Windows ablaufen, wo die Registry kaum zu durchblicken ist, sondern die Dinge vereinfachen.

Allerdings bin ich mir nicht sicher, ob sich Elektra wirklich durchsetzen kann, weil eben sehr viele Programme darauf angepasst werden müssten. Begrüßen würde ich es aber.

Lokadamus

2006-07-16, 19:24:13

Spearhead[/POST]']@Lokadamus: Ja, etwas um das es eigentlich weniger geht bei Elektra, ein BSD, kein Linux :-pmmm...

*Hmpf*, wenn man bedenkt, dass Linux ihre LBS- Irgendwas hat, um Ordnung in den Kram reinzubringen, hätten sie es auch einfach abgucken können, wie es ordentlich geht :tongue:Gast[/POST]']1.) Auf der Elektra Webseite gibt es ein Beispiel zur xorg.conf Datei, wie die in Elektra umgesetzt ist.
Im Prinzip hast du ein Verzeichnis Elektra genannt,
darin liegen weitere Verzeichnisse und Dateien.

2.) Für den Benutzer fritz würden dann eigene Einstellungen zu Firefox in
user/fritz/sw/firefox
stehen. Z.b. usr/fritz/sw/firefox/javascript
Und darin steht dann der Keyname, also was, der Wert und ein Kommentar:
javascript = enabled, "This is the option to enable disable javascript"

3.) Apache kriegt
system/sw/apache/
Darin kann es dann alle Apachespezifischen Konfigoptionen setzen,
die Apache braucht.
Daten wie HOSTNAME und Co kann Apache von einem zentralen systemweiten Ort holen, z.b. system/net/hostname
3.1) Nö.

4.) Nimm z.b. die xorg.conf.
Die ist in Sektionen ... gekürzt ... wir mit dem gleichen Parser noch die resolv.conf auslesen.
Da man man dann zwar ein Schlüssel Werte Paar:
nameserver 133.45.2.44, aber im Gegensat zur xorg.conf
kommt es ohne Anführungszeichen aus.
Identifier "nvidia"
DAS muß der Parser dann wieder berücksichtigen.

Das wird also so richtig schön komlex, deswegen bestet YAST aus einer Sammlung von Parsern die meist alle jeweils auf eine ganz bestimmte Configdatei spezialisiert sind.

5.) Oft liegt es auch einfach an der Faulheit des Programmieres,
das ist jetzt nicht abwertent gemeint sondern schlichtweg eine feststellung.
Ein Programmierer hat ... gekürzt ... auf den bereits geschriebenen Parser zurückgreifen.

6.) Im Thread gab es hier weiter oben ein Dummposting, in dem einer meinte,
Programm A auf französisch und Programm B auf deutsch einstellen zu müssen.
So ein Schwachsinn macht kein Mensch.
Entweder man stellt den gesamten Desktop auf Deutsch ein, weil man Deutsch so gut kann, oder man stellt den gesamten Desktop auf Französisch sein.
Und selbst wenn das mal bei Ausnahmen sinnvoll sein mag, z.b. Computerspiele, können solche Anwendungen ihre Sprache immer noch in ihrem eigenen Konfigurationpfad festlegen.
Dabei sollte natürlich so ein Computerspiel so intelligent sein, erstmal den Systemweiten Defaultwert zu übernehmen bzw. das eigene Feld leerlassen und erst bei expliziten Bedarf das im eigenen Konfigurationspfad, auf Wunsch des Users festlegen.
Und diesen Defaultwert muß es natürlich kennen, hier hilft wiederum so etwas wie Elektra.

7.) Mit einer Systemweiten Konfig, auf man auch noch mit einer einheitlichen API zugreifen kann, wird das ganze sehr sehr viel bequemer und einfacher.
Und wenn etwas einfach, schnell und bequem ist, dann ist der Weg nicht mehr weit, daß das Feature auch genutzt wird.mmm...

1.) Warum zeigst du dann nicht das Beispiel von der Webseite?
2.) Du willst das Homeverzeichnis verschieben?
3.) + 3.1) Äh, also bekommt es doch wieder seine eigene Value Keys und der nächste, der was von Apache will, darf sich selber wieder drum kümmern, wie er das abgefragt bekommt. Hätte mich auch gewundert, wenn Elektra von sich heraus alles erkennen würde.
4.) Mal ganz doof gesagt, wieso glaube ich dir nicht, dass selbst Elektra extra für x.org angepasst werden muss oder die config anders aufgebaut wird?
5.) Ich glaube, darauf hab ich schon ein paar Mal drauf hingewiesen.
6.) Ohne nachzulesen denke ich, ich war der Dummposter. Aber schön, wieviel du auf einmal selber von deinen Beispielen hälst ;) ... sorry, aber den Seitenhieb kann ich mir nicht verkneifen ...
7.) Ich glaube, ich hab schon ein paar Mal darauf hingewiesen, dass einiges an der Struktur von Linux geändert werden sollte. Das Elektra der richtige Weg ist, kann ich zwar immernoch nicht erkennen, aber naja. Ich hätte zwar gerne mal das Configfile für die Xorg gesehen, aber da wirst du wohl wieder keinen Screenshot von machen ...

Gast

2006-07-16, 19:58:55

1.) Warum zeigst du dann nicht das Beispiel von der Webseite?

Weil ich nicht so viel schreiben will.
Hier der Link:
http://www.libelektra.org/Xorg

2.) Du willst das Homeverzeichnis verschieben?

Wo steht das?

3.) + 3.1) Äh, also bekommt es doch wieder seine eigene Value Keys

Häh, sagt mal für wen hälst du mich?
Das Programme ihre Daten in Value = Key Paare speichern müssen ist
ja wohl klar.

und der nächste, der was von Apache will, darf sich selber wieder drum kümmern, wie er das abgefragt
bekommt.

Du hast offensichtlich keinen blassen schimmer.

Der, der was von Apache will, also das Programm macht natürlich get_key("system/sw/apache/wasweisich") und zwar ÜBER die libelektra.so Lib
bzw. über den eigenen selbst geschriebenen Elektra konformen Parser (für den, der wirklich so etwas schreiben will, anstatt die libelektra.so zu nutzen).

Hätte mich auch gewundert, wenn Elektra von sich heraus alles erkennen würde.

Nichst hast du verstanden.

4.) Mal ganz doof gesagt, wieso glaube ich dir nicht, dass selbst Elektra extra für x.org angepasst werden muss oder die config anders aufgebaut wird?

Xorg wird an Elektra angepaßt.

Ansonsten gibt es dafür ja noch Backends.

5.) Ich glaube, darauf hab ich schon ein paar Mal drauf hingewiesen.

Worauf hast du genau hingewiesen?
Auf faule Programmierer oder das was ich geschrieben habe?

7.) Ich glaube, ich hab schon ein paar Mal darauf hingewiesen, dass einiges an der Struktur von Linux geändert werden sollte. Das Elektra der richtige Weg ist, kann ich zwar immernoch nicht erkennen, aber naja..

Bis jetzt wetterst du nur gegen Elektra hast aber noch keine bessere Alternative hervorgebracht.

MadMan2k

2006-07-16, 20:09:02

Gast[/POST]']Aha, und viele Programme nutzen trotzdem kein locale. Dummschwätzer!
das ist dann aber ein Bug im Programm und kein Fehler des Systems. Ansonsten könnte ich genauso behaupten Elektra wäre Mist, weil es dieselben Programme ebensowenig benutzen.

Gast[/POST]']
Und mit Elektra ist das kein Problem, weil sowohl das kleine Programm
als auch das große Programm das selbe Konfigurationsystem, also Elektra nehmen können.

Eben. Man kann nicht einfach Sagen, dass die Schlüssel nur Bool-Werte enthalten und dahingehend optimieren oder eine Bestimmte Größe der Config-Datei annehmen, was bei performance/ speicherkritischen Bereichen nötig wäre.

Gast[/POST]']
RDBs haben wieder andere zum Teil sehr schwerwiegende Probleme.
Z.b.wenn die db kaputt geht, dann wäre dein System nicht mehr benutzbar.
Und eine RDB läßt sich auch nicht mit vi bearbeiten, dies sollte aber mit Elektra immer noch möglich sein.

ich sprach von RDB gestützten Dateisystemen. Die Daten wären also immernoch in Textform zugänglich.

Aber mal davon abgesehen:
viele der von dir angesprochenen Probleme sehe ich auch, aber diese könnten entweder durch eine simple reorganistation von /etc behoben werden, oder können auch durch elektra nicht gelöst werden.
Das von dir Angesprochenen Browserproblem würde erst dann gelöst wenn GNOME und KDE die variable /user/browser benutzen würden anstatt /user/{kde, gnome}/browser.
Aber auch dies würde auch jetzt schon ohne Elektra gehen...

also noch kürzer:
ich halte Elektra für einen unnötigen Abstraction Layer

HellHorse

2006-07-16, 20:28:29

Gast[/POST]']Das ist also die Antwort auf deine Niederlage?
Vermutlich ist es das und nicht dass ich einfach Müll nicht so stehen lassen kann.
Gast[/POST]']
Elektra IST systemweit.
Ja, das macht ja dein Beispiel noch schlechter.
Gast[/POST]']Die natürlich nicht von jedem Programm ausgelesen wird.
Komischerweise gibt es Programme in denen man explizit die Sprache
extra einstellen muß und diese Einstellung wird dann nur in der Konfigurationsdatei
dieser Anwendung gespeichert.
Änderst du dann deine Locale Variable dann ändert sich bei dieser Anwendung genau gar nichts.
Wieso sollte ein Programm, dass zu ignorant ist um locale auszulesen plötzlich die locale über Elektra abfragen?

Genausogut könnte ich gegen Elektra aufführen, dass es bloss von einer handvoll (wenn überhaupt) Programmen verwendet wird und vom Rest ignoriert wird.
Gast[/POST]']
Oder noch besser.
Setze mal den Defaultbrowser in Gnome auf Firefox.
Danach starte eine KDE App wie Kivio und klicke auf Bug einreichen.
Kivio wird dir versuchen den Browser Konqueror aufzurufen, dabei hätte es firefox sein sollen.
Schöner Dreck!
Mach deine Beispiele mit http Proxy Settings, dann funktionieren sie auch.
Gast[/POST]']
Lies mal die Doku zu Elektra.
DBUS steht dir viel zu spät zur Verfügung.
Da muß erstmal ein ganzer Rattenschwanz während dem Bootprozess gebootet werden.
Hängt immer vom Anwedungsfall ab, wann zu spät ist. Ich habe nie behauptet, dass DBUS das allein selig machende ist oder dass sich damit Konfigurationsprobleme lösen lassen. Sondern lediglich, dass Programme über DBUS komminizieren können. Daneben gibt es diverse andere Möglichkeiten unter anderem Standard POSIX IPC welches keinen Rattenschwanz beim booten benötigt. Ich habe lediglich bestritten, dass Kommunikation über Konfigurationsdateien eine kluge Idee ist.

Lokadamus

2006-07-16, 20:37:08

Gast[/POST]']1.) Weil ich nicht so viel schreiben will.Hier der Link: http://www.libelektra.org/Xorg
2.) Wo steht das?
3.) Häh, sagt mal für wen hälst du mich?
Das Programme ihre Daten in Value = Key Paare speichern müssen ist
ja wohl klar.
Du hast offensichtlich keinen blassen schimmer.
4.) Der, der was von Apache will, also das Programm macht natürlich get_key("system/sw/apache/wasweisich") und zwar ÜBER die libelektra.so Lib
bzw. über den eigenen selbst geschriebenen Elektra konformen Parser (für den, der wirklich so etwas schreiben will, anstatt die libelektra.so zu nutzen).
5.) Nichst hast du verstanden.
6.) Xorg wird an Elektra angepaßt. Ansonsten gibt es dafür ja noch Backends.
7.) Worauf hast du genau hingewiesen? Auf faule Programmierer oder das was ich geschrieben habe?
8.) Bis jetzt wetterst du nur gegen Elektra hast aber noch keine bessere Alternative hervorgebracht.mmm...

1.) Prima, endlich. Wie oft hab ich um so etwas gebeten? Egal ...
2.) Das Homeverzeichnis ist zur Zeit der Platz, wo für den User bezogene Sachen gespeichert werden. Soweit ich dich verstanden habe, wird das durch Elektra überflüssig.
3.) Du hast irgendwo einen Knoten und hast noch nicht das Problem erkannt, was ich die ganze Zeit sehe.
4.) Da ist der Knoten, den ich die ganze Zeit sehe. Also darf man sich doch wieder selber einen Parser bauen und hoffen, dass niemand was falsches in die Dinger schreibt. Ansonsten ist es egal, was für ein Parser es ist, er läuft nicht sauber ...
5.) Das bezweifle ich mal und gehe eher davon aus, dass du ein Fanatiker bist. Um so enttäuschter bin ich, dass du es bisher immer noch nicht geschafft hast, ein Screenshot von deinem System, wo Elektra drauf läuft, zu posten und so zu zeigen, wie sich die Verzeichnisstruktur effektiv ändernt.
Wie das bei BSD seit Jahren gemacht wird, hab ich schon gezeigt und jeder kann wohl schnell sehe, was ich nachträglich installiert habe (wobei einiges durch Abhängigkeiten installiert wurde).
6.) Äh, Backends? Naja, ich dachte, von sowas wie Webmin und Yast willst du weg?
7.) Auf die Tatsache, dass schon jetzt wesentlich mehr gemacht werden könnte => faule Programmier. Darauf hat MadMan2k aber auch schon hingewiesen. Nebenbei würde das eine Neustrukturierung der Verzeichnisse einiges erleichtern, aber egal, ich wiederhole mich nur noch ...
8.) Nö, wozu sollte ich darauf hinweisen, dass deine Anlaufstelle diese LBS- irgendwas ist, die die Distributionen von Linux vereinheitlichen wollen :tongue: ...

CannedCaptain

2006-07-16, 20:56:44

Ich glaube, man sollte einen Linux-weiten Standard zur Abspeicherung der Configs festlegen, ob der nun Elektra heißt oder Simple Conig File Parser, ist doch Schnuppe. Explizit spreche ich mich dagegen aus, die Configs aus den Homeverzeichnissen nach /etc zu verlegen und betrachte es als nützlicher, ein Overlay über Elektra respektive andere zu legen, wie z.B. .icons im Homeverzeichnis oder in portage overlays, die explizit eine globale Variable überschreiben. So kann zum Bsp. Quake3.bin global bei elektra/global/lang fragen, welche Sprache und sie im Nachhinein durch .elektra/sw/quake3/lang überschreiben, falls diese im homeverzeichnis liegt. Die Realisierung einer solcher Struktur wäre einfach, denn schon Java macht es uns mit den einfach zu handelnden Packages vor.

Aber mal etwas nebenbei, wenn schon Uniformitätsbestrebungen, warum kann man nicht ein latest/base /stable/base und /rockstable/base Paket definieren, welches mit ca. 150 MB eine Grundfunktionalität vorschreibt, welche durch genau solche fest definierten Variablen in beispielsweise Elektra vertreten wird. Beispiel: Systemlogger ist egal, aber alle müssen die gleichen Abfragemechanismen haben. Paketmanager ist egal, aber alle müssen simple Befehle wie "boolean isInstalled" "String installedVersion" "boolean isAvailable" usw. Auskunft über den Softwarestatus geben. Man müsste nur portage apt yum rpm und co gegen diese Schnittstelle programmieren und Softwareentwickler könnten sehr einfach, eine Auskunft geben, ob Quake3.bin auf /stable/baseAndX installierbar wäre. Ich möchte damit nicht Softwarevielfalt einschränken, sondern lediglich Standards definieren, die ein Programm zumindest erfüllen muss.

Gast

2006-07-16, 22:14:40

MadMan2k[/POST]']das ist dann aber ein Bug im Programm und kein Fehler des Systems. Ansonsten könnte ich genauso behaupten Elektra wäre Mist, weil es dieselben Programme ebensowenig benutzen.

Locale könnte vielleicht noch eine Lösung für die Sprache sein, wenn es denn von jedem
Programm benutzt werden würde, aber wieso klemmst du dich so an Local fest wenn ich
dir schon andere Beispiele gennant habe, bei denen es nichts global standardisiertes in dieser Form gibt.

Es ist also eine umfassendere Lösung notwendig die für alles einsetzbar ist.

Eben. Man kann nicht einfach Sagen, dass die Schlüssel nur Bool-Werte enthalten und dahingehend optimieren oder eine Bestimmte Größe der Config-Datei annehmen, was bei performance/ speicherkritischen Bereichen nötig wäre.

Und du meinst die bisherigen Configdateien, die für den Menschen gut und für dem Computer schlecht lesbar sind, wären performanter?

ich sprach von RDB gestützten Dateisystemen. Die Daten wären also immernoch in Textform zugänglich.

Ok.

Aber mal davon abgesehen:
viele der von dir angesprochenen Probleme sehe ich auch, aber diese könnten entweder durch eine simple reorganistation von /etc behoben werden,

Wie soll dann so ein reorganisiertes /etc aussehen?
Stellst du alle Configdateien in /etc auf xml um?

oder können auch durch elektra nicht gelöst werden.

Dann mach ein Beispiel was mit Elektra nicht gelöst werden kann.

Das von dir Angesprochenen Browserproblem würde erst dann gelöst wenn GNOME und KDE die variable /user/browser benutzen würden anstatt /user/{kde, gnome}/browser.

Ja, das wäre der nächste logische Schritt, den man bei einem Elektra System gehen würde.
Er wäre sogar leicht zu implementieren, da man nur den Pfad in den Programmen von user/kde/.../browser auf /user/browser ändern müßte.

Aber auch dies würde auch jetzt schon ohne Elektra gehen...

Nein, denn du müßtest sowohl bei KDE als auch Gnome eine Vorkehrung treffen, daß
diese so einen Wert aus der einen global festgelegten Configdatei auslesen.
Also wiedermal ein weiterer Parser, der mit Elektra unnötig wäre.

also noch kürzer:
ich halte Elektra für einen unnötigen Abstraction Layer
Weil dir es vollkommen egal ist, wenn Anwendungen ihre eigenen tausend verschiedenen Parser mitliefern.

Gast

2006-07-16, 22:46:00

HellHorse[/POST]']
Wieso sollte ein Programm, dass zu ignorant ist um locale auszulesen plötzlich die locale über Elektra abfragen?

Weil der Schritt um das zu tun schneller zu realisieren ist, wenn das Programm sowieso schon für den Rest Elektra verwendet.
Das habe ich eigentlich schon vorher gesagt.

Gast

2006-07-16, 23:16:38

Lokadamus[/POST]']
2.) Das Homeverzeichnis ist zur Zeit der Platz, wo für den User bezogene Sachen gespeichert werden. Soweit ich dich verstanden habe, wird das durch Elektra überflüssig.

Die Elektra Userdaten liegen im Homeverzeichnis.
Ein Pfad wie user/xy ist ein Pfad ausgehend vom Elektra root.
Damit ist nicht die Wurzel / des Dateisystems gemeint.
Elektra selbst fängt erst ab /etc/elektra an.
Das sind also relative Pfade, absolut sehen sie erst aus
der Elektra lib aus.
Und auf die Userdaten wird ins Homeverzeichnis verlinkt.

Es ändert sich also am Homeverzeichnis gar nichts, bis auf das die Konfigdaten der User halt in Elektraform gespeichert werden.

Gebe es zu, du hast dir die Doku zu elektra die ganze Zeit nicht ein einziges mal durchgelesen, sonst hättest du das nämlich gewußt.

4.) Da ist der Knoten, den ich die ganze Zeit sehe. Also darf man sich doch wieder selber einen Parser bauen und hoffen, dass niemand was falsches in die Dinger schreibt.

Dürfen ja, müssen aber nein, auch darf man nen Editor nehmen und von Hand editieren.
Wenn du verhindern willst, das Programmierer ihren eigenen Parser schreiben können,
dann mußt du auch verhindern, daß sie die Konfigdateien mit einem gewöhnlichen Editor editieren können.
Das ist aber überhaupt nicht gewünscht.

Wenn du das ganze also in eine Datenbank kapseln würdest, dann würde der nächste Elektra-Gegner meckern, daß er das Zeug nicht mit vi bearbeiten kann.
Irgendwo muß der Kompromiss also schon herkommen.

Und was das falsche Zeug reinschreiben betrifft.
Die Rechtetrennung bei Linux/Unix, also Admin und User lebt auch davon,
daß die Benutzer nicht mit root Rechten arbeiten. Da mußt du also genauso hoffen.
Deswegen würde ich mal sagen, ist das ein bescheuertes Argument, was du da anführst.

Klar könnte ein Admin mal unbeabsichtigt einen Fehler in die Wertepaare schreiben,
aber dann ist das sein Bier, beim jetztigen System muß er ja auch damit leben,
daß er seine Configdateien zerschiesen kann.
Und wenn nur die Syntax falsch ist, dann kann man die libelektra.so oder den Eigenbauparser immer noch so auslegen, daß er solche syntaxfalschen Einträge ignoriert.
Ich sehe da kein Problem.

Ansonsten ist es egal, was für ein Parser es ist, er läuft nicht sauber ...

Der von libelektra.so läuft sauber, wenn dann irgendwelche Programmierer meinen sie müssen einen eigenen Schreiben oder verwenden, dann sind sie selber schuld, ich würde es nicht machen auch wenn ich es dürfte/könnte.

6.) Äh, Backends? Naja, ich dachte, von sowas wie Webmin und Yast willst du weg?

Elektra kann mehr als nur Yast und Webmin.

Selbst wenn auf eine bestimmte alte Configdatei über backends zugegriffen werden würde,
könnten elektra Programme diese dennoch durch Elektra bearbeiten.
Yast und Webmin können aber nur für sich selbst in ihrem eigenen Abstraktionsbereich arbeiten.

Auch ist davon auszugehen, daß man die Backends nur für die Übergangsphase
braucht.
Z.B. gibt es ja Konfigurationdateien, die von mehreren Programmen benutzt werden.
Jetzt kann man aber nicht jedes dieser Programme sofort auf Elektra umstellen,
das braucht nämlich Zeit, also muß das nach und nach geschehen.
Als Übergangslösung muß es also die Möglichkeit geben das auch noch auf die alten Programme die noch nicht Elektraready sind auf die Konfigurationsdatei zugreifen können
und das geht am besten, in dem man die alte Configdatei noch nebenbei da läßt
und für die neuen Elektra Programme auf diese über Backends abstrahiert.
Für die Elektraready Programme sieht es dann dank Backend so aus, als wäre die Konfigdatei schon längst auf Elektra umgestellt worden.

Gast

2006-07-16, 23:21:31

CannedCaptain[/POST]']Explizit spreche ich mich dagegen aus, die Configs aus den Homeverzeichnissen nach /etc zu verlegen u

Das passiert auch nicht.
Dieses Gerücht hat nur Lokadamus in die Welt gesetzt, weil der die Dokumentation nicht gründlich gelesen hat und mein Posting nicht verstanden hat.

MadMan2k

2006-07-17, 01:06:11

Gast[/POST]']
Weil dir es vollkommen egal ist, wenn Anwendungen ihre eigenen tausend verschiedenen Parser mitliefern.
jep. irgendiwe scheint es mir, als ob du den Aufwand einen Parser zu schreiben überschätzt und damit auch den Vorteil von Elektra.
Einfache gut lesbare Dateien, wie wir sie heute haben, sind übrigens schneller parsbar als XML Dateien.

Gast

2006-07-17, 01:29:34

Gast

2006-07-17, 01:31:25

MadMan2k[/POST]']jep. irgendiwe scheint es mir, als ob du den Aufwand einen Parser zu schreiben überschätzt und damit auch den Vorteil von Elektra.
Einfache gut lesbare Dateien, wie wir sie heute haben, sind übrigens schneller parsbar als XML Dateien.
Und du unterschätzt den Aufwand einen Parser zu schreiben, der auch mit komplexeren Configdateien klarkommt und vor allem auch noch dann funktioniert,
wenn der Mensch von Hand darin herumkonfiguriert hat.

Gast

2006-07-17, 01:35:37

Das Kommando
$ kdb get system/filesystems/home/device

liefert dann bei obigem Beispiel übrigens:

/dev/hda7

Gast

2006-07-17, 01:39:03

Und wenn man die Datei
/etc/kdb/system/filesystems/home/device

mit einem Editor öffnet, sieht das darin so aus:

RG002
40
Device or Label
<DATA>
/dev/hda7

Gast

2006-07-17, 01:43:11

Man kann das ganze natürlich auch auf Verzeichnisse anwenden:
kdb ls -v system/filesystems/home

Das liefert dann:

system/filesystems/home/device=/dev/hda7
system/filesystems/home/dumpfreq=1
system/filesystems/home/mpoint=/home
system/filesystems/home/options=defaults
system/filesystems/home/passno=2
system/filesystems/home/type=ext3

Die Option -v zeigt gleich noch die values an, ohne -v werden nur die Keys,
also Verzeichnispfade+Dateiname angezeigt.

Gast

2006-07-17, 02:07:22

Wenn ich wissen will, welchen key hda6 hat, dann mache ich einfach:

kdb ls -vr system/filesystems | grep hda6

und bekomme dann das da geliefert:

system/filesystems/swap/device=/dev/hda6

Die Option r nach -v sorgt dafür, das auch die Unterverzeichnisse durchgecheckt werden.

Wenn man also mal nach irgendeinem bestimmen Wert in der komplette Konfiguration,
also alles in /etc/kdb/ suchen wollen würde, dann würde folgendes genügen:

kdb ls -vr | grep wert

Lokadamus - nixBock

2006-07-17, 07:12:03

Gast[/POST]']1.) Es ändert sich also am Homeverzeichnis gar nichts, bis auf das die Konfigdaten der User halt in Elektraform gespeichert werden.
2.) Gebe es zu, du hast dir die Doku zu elektra die ganze Zeit nicht ein einziges mal durchgelesen, sonst hättest du das nämlich gewußt.
3.) Dürfen ja, müssen aber nein, auch darf man nen Editor nehmen und von Hand editieren.
Wenn du verhindern willst, das Programmierer ihren eigenen Parser schreiben können, dann mußt du auch verhindern, daß sie die Konfigdateien mit einem gewöhnlichen Editor editieren können.
4.) Und was das falsche Zeug reinschreiben betrifft.
Die Rechtetrennung bei Linux/Unix, also Admin und User lebt auch davon,
daß die Benutzer nicht mit root Rechten arbeiten. Da mußt du also genauso hoffen. Deswegen würde ich mal sagen, ist das ein bescheuertes Argument, was du da anführst. Klar könnte ein Admin mal unbeabsichtigt einen Fehler in die Wertepaare schreiben, ... gekürzt ...
5.) Elektra kann mehr als nur Yast und Webmin.
Selbst wenn auf eine bestimmte alte Configdatei über backends zugegriffen werden würde, könnten elektra Programme diese dennoch durch Elektra bearbeiten. Yast und Webmin können aber nur für sich selbst in ihrem eigenen Abstraktionsbereich arbeiten.
6.) Als Übergangslösung muß es also die Möglichkeit geben das auch noch auf die alten Programme die noch nicht Elektraready sind auf die Konfigurationsdatei zugreifen können und das geht am besten, in dem man die alte Configdatei noch nebenbei da läßt und für die neuen Elektra Programme auf diese über Backends abstrahiert.
Für die Elektraready Programme sieht es dann dank Backend so aus, als wäre die Konfigdatei schon längst auf Elektra umgestellt worden.mmm...

1.) Im Klartext, alles doppelt gemoppelt.
2.) Stimmt, ansonsten hätte ich den Thread schon lange ignoriert.
3.) Wenn ich deine Texte vom Anfang richtig in Erinnerung habe, sagst du, dass kein Parser mehr notwendig sei. Da eigentlich irgendwoher jeder Parser kommen muss, hab ich mich gefragt, wie Elektra das machen will. Nunja, die Frage hast du mir immerhin beantwortet. Die Macher von Elektra basteln selber den Parser ...
4.) Also von so etwas intelligentem wie Elektra erwarte ich dann doch schon, dass es gegenüber Yast gewisse Sachen überprüft, ob sie überhaupt passen können. Ansonsten ist das Teil auch nicht mehr Wert als Yast.
5.) Jaja, ich merks. Es kann Config- Dateien nochmal anlegen und dadurch leichter bearbeiten.
6.) Klaro, wenn jeder so und so programmieren würde oder es gewisse Aliase in der Programmierung gäbe, dann wäre es auch einfacher, gewisse Sachen direkt abzufragen. Man könnte auch einfach eine lib basteln, wo Sachen wie locals abfragen als 1 Zeile Befehl drinne steht. Nur dann bräuchte man Elektra nicht. Wie alt ist es überhaupt? Hat mittlerweile doch einige Jahre auf dem Buckel ...Gast[/POST]']Hier ein Auschnitt davon, ich hab das mal in einer Sandkastenumgebung neu erstellt,
sonst wäre das zu lang.
Hier beschreibt es z.B. die fstab
tierisch lang, während die fstab nur ein paar Zeilen groß ist
Was du da siehst, beschreibt die fstab.Äh, naja. Etwas zu groß und wo ist die Vereinfachung?Gast[/POST]']Und wenn man die Datei
/etc/kdb/system/filesystems/home/device
mit einem Editor öffnet, sieht das darin so aus:Das ist aufjedenfall nicht die Vereinfachung, sondern nur eine neue Darstellung.

Also sorry, aber den einzigen Vorteil in Elektra sehe ich nur darin, dass es leichter sein wird, gewisse Werte abzufragen, aber dafür kann man das Arbeiten in einer Konsole vergessen => abgelehnt.
Alternativ könnte man auch eine Lib basteln, die ( siehe Bemerkung irgendwo ein paar Zeilen weiter oben) ... die von dir angepriesene Vereinfachung und das Überflüssig sein von Parsern kann ich auch nicht sehen. Ich kann nur den Ansatz einer Erleichtung dafür erkennen und wo Elektra jetzt mächtiger als Yast sein soll, erschliesst sich mir auch nicht. Mit Yast kann ich das ganze Basissystem konfigurieren, was kann Elektra ausserdem?
Gibt es überhaupt eine Distrie, die Elektra einsetzt?

Gast

2006-07-17, 16:52:18

Lokadamus - nixBock[/POST]']mmm...

1.) Im Klartext, alles doppelt gemoppelt.

Nein.

[/QUOTE]
2.) Stimmt, ansonsten hätte ich den Thread schon lange ignoriert.
[/QUOTE]
Wenn du von dem Thema keine Ahnung hast, dann brauchst du auch nicht mitreden.

3.) Wenn ich deine Texte vom Anfang richtig in Erinnerung habe, sagst du, dass kein Parser mehr notwendig sei. Da eigentlich irgendwoher jeder Parser kommen muss, hab ich mich gefragt, wie Elektra das machen will. Nunja, die Frage hast du mir immerhin beantwortet. Die Macher von Elektra basteln selber den Parser ...

Ich sagte, daß die zig verschiedenen Parser wegfallen und ein Elektra Programm, das schon
die libelektra.so nutzt nur noch diese braucht.

4.) Also von so etwas intelligentem wie Elektra erwarte ich dann doch schon, dass es gegenüber Yast gewisse Sachen überprüft, ob sie überhaupt passen können. Ansonsten ist das Teil auch nicht mehr Wert als Yast.

Es gibt nunmal Benutzer die Elektra erst dann akzeptieren werden,
wenn sie mit ihrem vi in der Elektra Konfiguation herumpfuschen können.

Und es ist nicht die Aufgabe von Elektra den Pfusch von vi-Benutzern wieder gerade zu biegen.
Die libelektra.so Lib wird jedenfalls die Syntax einhalten auf den Pfusch von vi und emacs Benutzern kann sie keine Einfluß nehmen.

Das ist genau das gleiche wie beim Root Account.
Der hat auch nicht die Aufgabe den Pfusch den ein Benutzer der sich mit root Rechten einloggt zu korrigieren.

5.) Jaja, ich merks. Es kann Config- Dateien nochmal anlegen und dadurch leichter bearbeiten.

Das nochmal anlegen ist nur notwendig, wenn die Konfiguration einiger Programme noch nicht vollständig auf Elektra umgestellt sind und daher Backends notwendig sind.

6.) Klaro, wenn jeder so und so programmieren würde oder es gewisse Aliase in der Programmierung gäbe, dann wäre es auch einfacher, gewisse Sachen direkt abzufragen. Man könnte auch einfach eine lib basteln, wo Sachen wie locals abfragen als 1 Zeile Befehl drinne steht. Nur dann bräuchte man Elektra nicht.

Wenn du mal an die Backends denkst, dann liese sich Elektra genau als solches mißbrauchen.
Auch wenn das eigentliche Ziel von Elektra doch einen Schritt weitergeht.

Wie alt ist es überhaupt? Hat mittlerweile doch einige Jahre auf dem Buckel ...

Ca. 4 Jahre.
Aber das ist ein gutes Zeichen, denn Gut Ding muß eben Weile haben, erst Recht, wenn es für so tiefe Systemänderungen geplant ist

Äh, naja. Etwas zu groß und wo ist die Vereinfachung?

Du kriegst die Gui, in der du mit der Maus schön, schnell, idiotensicher und einfach rumklicken und einstellen kannst mit extrem wenig Aufwand dazu.
Es ist nichtmal notwendig einen Parser für die fstab Daten zu schreiben.

Kurz gesagt das Schreiben von Grafischen Setuprogrammen wird so einfach, robust und
sicher, das jeder DAU ein Linux System installieren, konfigurieren und benutzen könnte.
Es wäre nicht notwendig auf die Konsole zu gehen und mit einem Editor in den Konfigurationsdaten herumzupfuschen, auch wenn das für die ewig gestrigen weiterhin möglich wäre.

Auch würde es im Gegensatz zu Yast auch funktionieren, was du da einstellst.

Das ist aufjedenfall nicht die Vereinfachung, sondern nur eine neue Darstellung.

Siehe oben.

Also sorry, aber den einzigen Vorteil in Elektra sehe ich nur darin, dass es leichter sein wird, gewisse Werte abzufragen, aber dafür kann man das Arbeiten in einer Konsole vergessen => abgelehnt.

Man kann auch Werte mit dem kbd Kommando setzen.

Und warum sollte man das Arbeiten in der Konsole deswegen vergessen?
Jeder Depp der die Konsole benutzt kann sich durch einen Verzeichnisbaum hangeln.

Das einzige was vielleicht passieren könnte ist, daß man auf die Konsole für solche Aufgaben vollständig verzichten kann, da die einfach nicht mehr notwendig wäre
wenn man sowieso alles mit der Maus einstellen kann.

Alternativ könnte man auch eine Lib basteln, die ( siehe Bemerkung irgendwo ein paar Zeilen weiter oben) ... die von dir angepriesene Vereinfachung und das Überflüssig sein von Parsern kann ich auch nicht sehen.

Warum kannst du das überflüssig sein von x verschiedenen parsern nicht sehen?

und wo Elektra jetzt mächtiger als Yast sein soll, erschliesst sich mir auch nicht.

Das habe ich eigentlich schon tausendmal gesagt.
Yast ist fehleranfällig, weil jede Konfigurationsdatei anders zu bearbeiten ist.
Weil Konfigurationsdateien nicht einem definierten Schema folgen.
Yast braucht also für jedes Scheme, für jede andere Syntax einen neuen Parser.
Das ist viel Code und die Fehleranfälligkeit von Software steigt nunmal mit der Anzahl der Codezeilen.

Vereinheitlicht man das Schema und die Syntax einer Koniguration,
dann reicht ein leichtgewichtiger Parser, der aus so wenigen Codezeilen besteht, das
er sehr leicht durchschaubar, stabil und robust ist.
Und wenn man mit diesem einen Parser wirklich alles bearbeiten kann,
dann muß man sich nur noch auf die Setup GUI Tools konzentieren und
schon läßt sich das gesamte System fehlerfrei von einem Dau per Maus konfigurieren und verwalten.

Dann ist Linux dem Massenmarkt wieder ein großes Stück näher gekommen und
mit einem großen Marktanteil gibt es dann auch mehr SW Produkte und Auswahl
für Linux. Inklusive von Computerspielen natürlich.

Mit Yast kann ich das ganze Basissystem konfigurieren, was kann Elektra ausserdem?
Gibt es überhaupt eine Distrie, die Elektra einsetzt?
Yast hat aber so viele Parser und besteht aus so vielen Zeilen Code, daß in 10 von 100 Parsern mindestens ein Fehler steckt.
D.h. klickst du dann in deiner Yast GUI auf Button XY der etwas einstellen soll,
dann passiert nichts, weil der Parser nen defekt hat.
Parser lassen sich natürlich auch nach und nach reparieren, aber in der Zwischenzeit
hat sich wieder die Konfiguration von Konfigdatei xy geändert und das ganze Spiel geht von vorne los.
Ganz abgesehen davon, daß für menschen lesbare Konfigurationsdateien,
die keinem definierten Schema folgen auch Semantisch Fehler auslösen können.

Elekta ist noch in Entwicklung. Die Version ist erst bei 0.62.
Und Anwendungen müssen noch angepaßt werden, was wohl erst im großen Stil folgt,
wenn die Version 1.0 erreicht ist. Angeblich ist das Ende des Jahres geplant.
Bis es eine Live CD gibt dauert das also noch ein bischen.

CannedCaptain

2006-07-17, 17:39:25

Lokadamus:

Du darfst natürlich gern Deine Meinung beibehalten, aber es spricht Bände, dass Du noch nie einen simplen Parser geschrieben hast. Sowas ist grausam, glaube mir. Versuche einmal allein einen Parser zu schreiben für den der Parameter -xvjpf trivial als -x -v -j -p -f erkannt wird und noch besser wenn jetzt einer der Parameter noch einen Schlüsselwert bekommt. An solcher trivialer Scheiße kann man Tage sitzen, diese Zeit könnten eher in richtig wichtige Features fließen.