WAS ??? Linux hat noch keine Registry ???. Na dann wirds aber allerhöchste Zeit, für Microsoft Windows gab es das schon für windows 95. Es ist wirklich kaum zu fassen, Linux will eine Konkurenz für Vista sein obwohl es nochnichtsmal über eine Registry verfügt???.
Das ist mal wieder der Beweis das OSS den Proprietären Produkten des Weltmarkführers um Jahrzehne hinterherhinkt, deshalb sind Linux und co ja auch nicht für den Produktiven Einsatz im harten Business geeignet.
Wenn schon was Zentrales, dann doch lieber yast, gerne überarbeitet mit einem Ort, wo alles, was mit yast zu tun hat, als menschenlesbare Datei in einem Verzeichnis liegt, aber eine "registry" halte ich für überflüssig.
also ich glaube nicht das viele auf die altbewaehrten konfigurationsdatein verzichten wollen - warum auch? das konzept ist ueber jahre hinweg erpropt und dadurch das man den zugriff auf die konfigs einschraenken kann hat es auch einen vorteil. der nachteil ist ganz klar die verschiedenen formate und damit der parseaufwand. nachteil zwei ist, das jede anwendung die auf diese "registry" zugreift gegen eine xml lib gelinkt werden muss was bei kleineren distributionen (sagen wir mal openwrt) nicht sinnvoll ist. elektra kann gern als zusaetzlich abschaltbares feature eingebaut werden oder man koennte aus elektra heraus die konfigurationsdatein fuer die einzelnen programme erzeugen. eins sollte nie passieren ... sowas wie in windows .... registry kaputt -> system im arsch. malsehen was kommt
Mit einen grafischen Frontend macht xml ja noch spaß, aber mit einen Texteditor auf der Konsole in xml-Dateien rumeditieren ist nicht mehr lustig und Fehleranfällig. Haben die daran auch gedacht?
finde die Idee garnicht so schlecht. die Struktur wird durch Verzeichnisse abgebildet. und die Werte liegen in kleinen XML Dateien welche dann in den entsprechenden Verzeichnissen liegen. Modifizieren kann man die Configs entweder mit einem Texteditor oder über eine einheitliche API welche durch eine Bibliothek bereitgestellt wird.
im endeffect unterscheidet es sich von dem bisherigen System nur dadurch das es eine einheitliche api und xml gibt. ansonsten liegen die configs bisher ja auch in textdateien in verschiedenen verzeichnissen. nur das bisher weder das verzeichnis noch der syntax der config standardisiert ist.
Mich wundert nicht, dass dieses Projekt keine Akzeptanz findet, wenn man mit dem Wort Registry daher kommt ist doch schon alles verloren, die Registry ist der größte Müll unter Windows, nicht weil das Konzept schlecht ist sondern weil dort jeder Müll gespeichert wird und sie die Registry nach längerer PC Nutzung so aufbläst, dass der Windows Start doppelt so lange dauert wie bei einer Neuinstallation.
mal testweise was geaendert werden soll fuer ein programm, kann man nicht einfach mal cp .conf .conf_old machen, wenn alles in einer datei steht. ich weiss nicht was ihr so unter /etc/"hölle" versteht. ich finde es gut so. vor allem leserlich im editor, und man brauch nicht noch extra xml syntax lernen, nur weil man mal ne aenderung vornehmen will.
Von Martin Fürstenau am Mo, 12. Juni 2006 um 10:38 #
Ich mach jetzt seit 20 Jahren Unix. Einer der Vorteile gegenüber Windows waren immer die gut lesbaren Konfigurationsdateien pro Applikation. An Config-Dateien im Flat-Ascii komm ich auch ran, wenn mal gar nichts mehr geht. Ich weiss wovon ich rede. Ich habe auch jahrelang Windows-Server administriert. Wenn man da mal mit einer geschredderten Registry steht, hat man wirklich ein Problem. WWozu soll man noch eine zusätzlich Abstraktionsebene einbauen und eine weitere Abhängigkeit? Damit all die, die keine Parser (z.B. Suse beim Yast) schreiben können es einfacher haben?
IBM hat das mal mit der ODM (Object Data Manager) bei AIX versucht. hat auch nur Stress gegeben. (und ähnlich Problem wie bei Windows.
Haben wir dann vielleicht einen Markt für Bücher wie "Undocumented Linux" oder "Lnux Registry explained"? Pfui Spinne.
...das ist alles, was ich dazu sagen kann. Nennt mich ruhig konservativ, aber wenn Elektra händische Bearbeitung von Config-Dateien auch nur ansatzweise erschwert, dann wird es kein Heim auf meinen Maschinen finden.
Die "True Facts" auf der Homepage klingen wir Marketing-Geschwätz und helfen nicht, jegliches Mißtrauen, das automatisch bei Vergleichen mit "Registry" und "GConf" auftritt, auszuräumen. Auch wenn jeder Punkt für sich gut klingt, eigentlich machen sie mich nur noch mißtrauischer. Als Debianer habe ich aber glücklicherweise noch viel Zeit, bis Elektra in einem Stable landen wird und kann mir das in aller Ruhe anschauen.
Electra stellt eine Art Intelligentstest für Linuxer dar. Ist man in der Lage, Konzepte und Ideen zu verstehen, oder bleibt man auf den Buzz-Word Bullshit-Bingo hängen und stört sich an "Registry" und "einheitlich". Die Kommentare überhalb zeigen, wie es um die Intelligenz bestellt ist.
Mögen viele Benutzer gut finden -- letzendlich denken die dann aber auch, das man einen Rechner allein durch Rumklicken administrieren könnte. Keine gute Idee, denn eine noch so gute GUI entbindet nicht von der Notwendigkeit, die Folgen bestimmter Einstellungskombinationen zu durchschauen. Letzlich muss man trotzdem die Doku lesen.
Letztlich wird durch Elektra nur eine weiter Abstraktionsebene in die Konfiguration eingezogen, die die Admins in zwei Lager teilt: Die Klickibunti-Admins, und die Leseratten-Admins. Folgen: Ein wirklicher Fork in der Benutzerbasis, und mehr totkonfigurierte Systeme.
(Und ich bin Hauptentwickler für ein größeres Projekt mit *sehr vielen* Konfigurationsoptionen -- inzwischen ist die Konfiguration größtenteils auch schon auf einen Datenbank umgestellt, die Konfiguration erfolgt per eingebautem Webserser.)
Kann mir, als noch "unbedarftem" Nutzer mal jemand erklären, was sich dahinter verbirgt? Werden da einfach alle Config Daten binär als int32 und so hintereinandergeschrieben? Wenn ja, kann ich mir vorstellen, dass das Ärger gibt. Sobald man vorne noch einen Wert einfügen möchte, ändern sich alle Offsets. *brrr*
Das das Wort 'Windows-Registry' gewisse Reaktionen auslöst, ist ja nicht unverständlich, aber was die tollen Vorteile der Uralt-Configdateien mit ihren X Varianten sein sollen, bleibt unergründlich. XML etabliert sich als Metasprache immer mehr und eignet sich auch sehr gut für Configs, schliesslich setze ich in meinen eigenen Programmen ausschliesslich XML für diesen Zweck ein. XML kann exakt so gut lesbar sein, wie eine klassische Config und nicht jede Textdatei in /etc erschliesst sich so einfach aus dem Kontext.
Mal für den simplen aber üblichen Fall einer Liste mit Schlüsseln betrachtet:
config> key1> value="ein Wert" comment="der Kommentar dazu" key1/> !-- oder ein Kommentar direkt im Text, ersetzt '#' --> key2> value="nochn Parameter" key2/> key3> value="und nocheiner" key3/> ... /config> (jetzt einfach aus den Fingern gesogen, hat nix mit dem Format von Elektra zu tun)
Ist ein kleiner Overhead zu
key1 ein Wert #ein Kommentar direkt im Text key2 nochn Parameter key3 und nocheiner
aber die Dramaturgie, die manche wegen total unleserlicher und monströser XML-Dateinen abziehen, bleibt mir unverständlich. Will man das Element der Schachtelung noch in klassische Configs reinbringen, schlägt das Pendel der Übersichtlichkeit IMHO sowieso Richtung XML aus, denn da liegt dessen Stärke.
Also warum nicht die Vorteile aus beiden Welten vereinen, ohne die jeweiligen Fehler immer wieder neu zu machen? XML kann Kommentare enthalten, als echten XML-Kommentar oder als eigenen Tag. Der Standard XML selbst überwacht die korrekte Einhaltung der Syntax, ohne dass ich als Entwickler das implementieren/dokumentieren müsste. So, jetzt noch eine systemweite Schnittstelle zu Manipulation/Einsicht/Verwaltung, und für meine nächste Eigenentwicklung sind wieder mal ein paar Arbeitstage eingespart.
Das Festhalten an den alten Configs mit den vielen Unterformaten gleicht irgendwie den Kommentaren von Officebenutzern die verzweifeln, wenn sich ein paar Menüs verschieben. Etwas mehr Offenheit gegen über Neuerungen könnte da nicht schaden, ich jedenfalls begrüsse das Projekt aus vollem Herzen.
Die Jungs (und Mädels) sollten mal an Ihrer PR arbeiten: Wie will man andere Projekte überzeugen, wenn man über deren Arbeit abfällige Bemerkungen verbreitet?
Ein Beispiel: Hier steht: "Conclusion: D-Conf is vaporware." Diese Einschätung mag durchaus richtig sein, aber ist es sinnig, das auch noch hinzuschreiben? Der Vergleich mit GConf ist noch wesentlich schlimmer: Der ist voll mit ungünstigen Formulierungen.
Soetwas mag ja auf einer Mailingliste oder einem Forum in der Hitze des Gefechts passieren. Aber das muß man nicht auch noch mit Hilfe einer Homepage in die Öffentlichkeit tragen!
Was außer einem korrekten Tonfall noch fehlt, sind Referenzen: Statt zu versuchen, einige 'großen' Projekte zu überzeugen, sollte man sich lieber an einige kleinere und jüngere halten. Falls das nicht reicht, kann man auch mal selbst Patches für eine sinnvolle Menge von 'günstigen' Projekten produzieren. Es ist schließlich Open Source: Da muß man doch nicht auf die Hauptentwickler eines Projektes warten.
Was auch noch fehlt, ist eine Demonstrationssoftware für Elektra, die sich der ganz normale Anwender im Rahmen solcher Berichterstattung runterladen und installieren kann. Diese sollte dazu dienen, daß der Nutzer die Vorteile von Elektra möglcihst leicht und genau versteht. Das erhöht die Chancen auf positive Berichterstattung ganz enorm.
Von Kai F. Lahmann am Mo, 12. Juni 2006 um 14:37 #
irgendwie war nach dem Anfang schon klar, dass das Projekt hier verrissen wird. Warum? Weil irgendwelche Pfeifen irgendwann man die Windows-Registry gesehen haben und da diese scheiße implementiert ist, muss automatisch alles scheiße sein, was auch nur irgendwie ähnlich aussieht...
Die Windows-Registry ist dabei eigentlich ein typisches MS-Projekt: tolle Idee, aber beschissen umgesetzt.
Eigentlich sollte man so eine "Registry" immer wie eine Blackbox sehen, etwas wo man manuell eher nicht ran muss. Deswegen ist es völlig egal welches Format ob binär oder ASCII. Entscheidend ist eher das es möglichst immer konsistent ist und auch ein gutes Recovery ermöglicht im Falle eine Crashs. Das geparse von Textdateien ist sowieso viel aufwendiger als jede binäre Datenbank und ausserdem ist das ganze sehr viel Fehleranfälliger da selbst in Konfigdateien rumzubasteln. Passiert schnell das man einen klitzekleinen Fehler in die fstab oder andere Systemdateien reinbastelt und nachher man nicht mal mehr das System booten kann, weil es keine Fehlerkontrolle gibt! Dafür bräuchte man jeweils ein passendes Frontend...
Ich würde die Textconfig-Dateien komplett abschaffen. Eine zentrale Datenbank für die Einstellungen und entsprechende Tools um Attribute zu setzen/lesen. Es ist schliesslich Aufgabe der Anwendung seine Daten persistent zu machen. Profis die trotzdem gerne alles manuell eintragen, können ja solchen Editoren wie das kbdedit nehmen. Für Systemeinstellungen kann man ja alles unter einem zentralen Tool zusammenfassen, da wo man halt Keyboard-Layout, Mountpounts, Zeitzone usw. komfortabel einstellen kann und das ganze dann in der Datenbank gespeichert wird.
Dieses rumgefrickel in hunderten von Textdateien, mit hunderten unterschiedlicher Formate und an dutzenden verschiedenen Stellen im System ist total Kontraproduktiv und ein wirklicher Ballast aus alten Unix-Zeiten. Solche Projekte wie Electra sind deshalb Klasse und genau der richtige Weg. Es liegt nur noch daran die verschiedenen Anwendungen auf eine API zu trimmen, sodass auch die ganzen GNU-Tools davon gebrauch machen.
Schaut Euch einfach mal Konfigurationsdateien die in XML gehalten sind in einen normalen Texteditor an und ihr werdet Eure wahre Freude daran haben. XML ist super wen es darum geht Konfigurationsdateien zu haben die nur mit Hilfe von speziellen Programmen angefasst werden. Aber sobald es darum geht das man sie direkt mit dem Texteditor bearbeiten soll sind sie nur noch nervig!
TechnoSlave
PS: Ja ich mag kein XML in Konfigurationsdateien da es die Dateien nur aufbläht und im Texteditor unübersichtlicher macht. Ich habe grundsätzlich nichts gegen eine Vereinheitlichung der Konfigurationsdateien, aber bitte so das man es auch händisch noch gut handhaben kann.
Viele scheinen sich über Elektra noch gar nicht richtig informiert zu haben.
Könntest du daher in der News einen Link zu dieser deutschsprachigen Open Office Präsentation über Elektra setzen? http://libelektra.org/elektra_de.sxi
Die Registry ist ein Filesystem. Die Konfiguration einer Applikation ist ein Subbaum dieses Filesystemes.
Ev'rything is a File? Oder wie hieß das alte Unix-Bekenntnis? Aber die Unixgemeinde alzheimert da wohl ein bissl...
Und nun setzt Euch endlich mal hin und schafft eine orthogonale Lösung!
Plan9 ist Unix da schon etwas voraus... Reiser umzingelt Linux von der anderen Seite... aber wenn der gewinnt, verkommt Linux zu Plugin für Reiser6FS...
Nein, das ist keine gute Idee. Mal abgesehen von der Gefahr der Zumüllung durch verwaiste Einträge, führt eine zentrale Registry zu unnötiger Komplexität: Copy&Go geht dann nicht mehr, denn die Configdatei des Programms gibts ja nicht mehr - am Ende muss man dann alle Programme noch mit einem Installer installieren, wie in Windows... mir graust.
der Konfigurationsdateien ersparen.
Ich werde es mir gleich einmal anschauen . . . Danke ProLinux
Es wird nur unübersichtlicher, oder?
Na dann wirds aber allerhöchste Zeit, für Microsoft Windows gab es das schon für windows 95.
Es ist wirklich kaum zu fassen, Linux will eine Konkurenz für Vista sein obwohl es nochnichtsmal über eine Registry verfügt???.
Das ist mal wieder der Beweis das OSS den Proprietären Produkten des Weltmarkführers um Jahrzehne hinterherhinkt, deshalb sind Linux und co ja auch nicht für den Produktiven Einsatz im harten Business geeignet.
elektra kann gern als zusaetzlich abschaltbares feature eingebaut werden oder man koennte aus elektra heraus die konfigurationsdatein fuer die einzelnen programme erzeugen.
eins sollte nie passieren ... sowas wie in windows .... registry kaputt -> system im arsch.
malsehen was kommt
Haben die daran auch gedacht?
im endeffect unterscheidet es sich von dem bisherigen System nur dadurch das es eine einheitliche api und xml gibt. ansonsten liegen die configs bisher ja auch in textdateien in verschiedenen verzeichnissen. nur das bisher weder das verzeichnis noch der syntax der config standardisiert ist.
IBM hat das mal mit der ODM (Object Data Manager) bei AIX versucht. hat auch nur Stress gegeben. (und ähnlich Problem wie bei Windows.
Haben wir dann vielleicht einen Markt für Bücher wie "Undocumented Linux" oder "Lnux Registry explained"? Pfui Spinne.
Die "True Facts" auf der Homepage klingen wir Marketing-Geschwätz und helfen nicht, jegliches Mißtrauen, das automatisch bei Vergleichen mit "Registry" und "GConf" auftritt, auszuräumen. Auch wenn jeder Punkt für sich gut klingt, eigentlich machen sie mich nur noch mißtrauischer. Als Debianer habe ich aber glücklicherweise noch viel Zeit, bis Elektra in einem Stable landen wird und kann mir das in aller Ruhe anschauen.
Letztlich wird durch Elektra nur eine weiter Abstraktionsebene in die Konfiguration eingezogen, die die Admins in zwei Lager teilt: Die Klickibunti-Admins, und die Leseratten-Admins. Folgen: Ein wirklicher Fork in der Benutzerbasis, und mehr totkonfigurierte Systeme.
(Und ich bin Hauptentwickler für ein größeres Projekt mit *sehr vielen* Konfigurationsoptionen -- inzwischen ist die Konfiguration größtenteils auch schon auf einen Datenbank umgestellt, die Konfiguration erfolgt per eingebautem Webserser.)
Man muss es nur in einer Übersichtliche Hierarchie bringen, dann gehts schon.
Windows macht nru den Fehler, dass es
HKEY_LOCAL_MASCHINE/clsid/{2579777a-56b7-4573-9cb0-c618eb8d813f}/Current Version/1.0/Standard/derwert heißt.
Mal für den simplen aber üblichen Fall einer Liste mit Schlüsseln betrachtet:
config>
key1> value="ein Wert" comment="der Kommentar dazu" key1/>
!-- oder ein Kommentar direkt im Text, ersetzt '#' -->
key2> value="nochn Parameter" key2/>
key3> value="und nocheiner" key3/>
...
/config>
(jetzt einfach aus den Fingern gesogen, hat nix mit dem Format von Elektra zu tun)
Ist ein kleiner Overhead zu
key1 ein Wert
#ein Kommentar direkt im Text
key2 nochn Parameter
key3 und nocheiner
aber die Dramaturgie, die manche wegen total unleserlicher und monströser XML-Dateinen abziehen, bleibt mir unverständlich. Will man das Element der Schachtelung noch in klassische Configs reinbringen, schlägt das Pendel der Übersichtlichkeit IMHO sowieso Richtung XML aus, denn da liegt dessen Stärke.
Also warum nicht die Vorteile aus beiden Welten vereinen, ohne die jeweiligen Fehler immer wieder neu zu machen? XML kann Kommentare enthalten, als echten XML-Kommentar oder als eigenen Tag. Der Standard XML selbst überwacht die korrekte Einhaltung der Syntax, ohne dass ich als Entwickler das implementieren/dokumentieren müsste. So, jetzt noch eine systemweite Schnittstelle zu Manipulation/Einsicht/Verwaltung, und für meine nächste Eigenentwicklung sind wieder mal ein paar Arbeitstage eingespart.
Das Festhalten an den alten Configs mit den vielen Unterformaten gleicht irgendwie den Kommentaren von Officebenutzern die verzweifeln, wenn sich ein paar Menüs verschieben. Etwas mehr Offenheit gegen über Neuerungen könnte da nicht schaden, ich jedenfalls begrüsse das Projekt aus vollem Herzen.
Ein Beispiel: Hier steht: "Conclusion: D-Conf is vaporware." Diese Einschätung mag durchaus richtig sein, aber ist es sinnig, das auch noch hinzuschreiben? Der Vergleich mit GConf ist noch wesentlich schlimmer: Der ist voll mit ungünstigen Formulierungen.
Soetwas mag ja auf einer Mailingliste oder einem Forum in der Hitze des Gefechts passieren. Aber das muß man nicht auch noch mit Hilfe einer Homepage in die Öffentlichkeit tragen!
Was außer einem korrekten Tonfall noch fehlt, sind Referenzen: Statt zu versuchen, einige 'großen' Projekte zu überzeugen, sollte man sich lieber an einige kleinere und jüngere halten. Falls das nicht reicht, kann man auch mal selbst Patches für eine sinnvolle Menge von 'günstigen' Projekten produzieren. Es ist schließlich Open Source: Da muß man doch nicht auf die Hauptentwickler eines Projektes warten.
Was auch noch fehlt, ist eine Demonstrationssoftware für Elektra, die sich der ganz normale Anwender im Rahmen solcher Berichterstattung runterladen und installieren kann. Diese sollte dazu dienen, daß der Nutzer die Vorteile von Elektra möglcihst leicht und genau versteht. Das erhöht die Chancen auf positive Berichterstattung ganz enorm.
Die Windows-Registry ist dabei eigentlich ein typisches MS-Projekt: tolle Idee, aber beschissen umgesetzt.
Das geparse von Textdateien ist sowieso viel aufwendiger als jede binäre Datenbank und ausserdem ist das ganze sehr viel Fehleranfälliger da selbst in Konfigdateien rumzubasteln. Passiert schnell das man einen klitzekleinen Fehler in die fstab oder andere Systemdateien reinbastelt und nachher man nicht mal mehr das System booten kann, weil es keine Fehlerkontrolle gibt! Dafür bräuchte man jeweils ein passendes Frontend...
Ich würde die Textconfig-Dateien komplett abschaffen. Eine zentrale Datenbank für die Einstellungen und entsprechende Tools um Attribute zu setzen/lesen. Es ist schliesslich Aufgabe der Anwendung seine Daten persistent zu machen. Profis die trotzdem gerne alles manuell eintragen, können ja solchen Editoren wie das kbdedit nehmen. Für Systemeinstellungen kann man ja alles unter einem zentralen Tool zusammenfassen, da wo man halt Keyboard-Layout, Mountpounts, Zeitzone usw. komfortabel einstellen kann und das ganze dann in der Datenbank gespeichert wird.
Dieses rumgefrickel in hunderten von Textdateien, mit hunderten unterschiedlicher Formate und an dutzenden verschiedenen Stellen im System ist total Kontraproduktiv und ein wirklicher Ballast aus alten Unix-Zeiten. Solche Projekte wie Electra sind deshalb Klasse und genau der richtige Weg.
Es liegt nur noch daran die verschiedenen Anwendungen auf eine API zu trimmen, sodass auch die ganzen GNU-Tools davon gebrauch machen.
TechnoSlave
PS: Ja ich mag kein XML in Konfigurationsdateien da es die Dateien nur aufbläht und im Texteditor unübersichtlicher macht. Ich habe grundsätzlich nichts gegen eine Vereinheitlichung der Konfigurationsdateien, aber bitte so das man es auch händisch noch gut handhaben kann.
Könntest du daher in der News einen Link zu dieser deutschsprachigen Open Office Präsentation über Elektra setzen?
http://libelektra.org/elektra_de.sxi
Ev'rything is a File? Oder wie hieß das alte Unix-Bekenntnis? Aber die Unixgemeinde alzheimert da wohl ein bissl...
Und nun setzt Euch endlich mal hin und schafft eine orthogonale Lösung!
Plan9 ist Unix da schon etwas voraus... Reiser umzingelt Linux von der anderen Seite... aber wenn der gewinnt, verkommt Linux zu Plugin für Reiser6FS...
Dann doch lieber Plan9!
Gut's Nächtle!