Wie findet ihr eine gemeinsame Registry wie Elektra?
-
gasomat schrieb:
Das liegt schlichweg daran, das die Leute sich nicht gründlich genug mit Elektra auseinandergesetzt haben und dann Begründungen als Contra anführen, die einfach nicht stimmen bzw, nicht auf Elektra zutreffen.
Gut, dann gebe ich Dir ein paar Begründungen, die ich für besser halte.
Dieses "iiih, Registry, das muß wie bei Windows sein" sitzt dummerweise
viel zu tief in den meisten Köpfen.Dass Registry-Konzepte nur selten so mies sind, wie das bei Windows der Fall ist, ist allen klar, aber sie bergen letztlich auch viele der Gefahren, die es unter Windows dabei auch gibt.
Die Entwickler von Elektra sind nicht in diesem Forum anwesend
und waren es höchstwahrscheinlich auch nie.Es sah einfach so aus, als sei Elektra Dein Projekt; Du hast es so vehement verteidigt, dass sich einem dieser Gedanke förmlich aufdrängte.
Aber zu meiner Liste:
- Gängige Registry-Konzepte bringen einiges an Komplexität mit sich. Zu viel für einige Anwendungszwecke.
- Registry-Konzepte können sich als nützlich erweisen, wenn es darum geht, Konfigurationsdaten für viele zusammengehörige Programme eines großen Environments zu speichern. Solche Systeme einem gesamten System überzustülpen wäre nur mäßig sinnvoll.
- Egal, wie gut die Verwaltungs-Tools für ein Registry-System sind, Config-Dateien sind oftmals bequemer handhabbar. Jeder kann sie mit seinem Lieblings-Editor bearbeiten, man kann sie herumpipen, durchgreppen, diffen etc. Und das alles, ohne vorher irgendeinen Konverter zu bemühen und zu XML vergewaltigt zu werden.
- Registry-Systeme sind sehr GUI-zentriert. Auch wenn es CLI-Tools gibt, so können diese konzeptbedingt nur einen Bruchteil dessen leisten, was normale Konfigurationsdateien können. (siehe oben)
- Sämtliche Konfigurationen aller Programme eines Systems einem einzigen Tool zu überlassen wäre einfach nicht sehr unixy. Es gibt einfach zu viele Programme, die zu wenig gemeinsam haben, als dass sowas Sinn machen würde.
Als Ersatz für KConfig und GConf wäre etwas Elektra-mäßiges durchaus ganz brauchbar, aber als Ersatz für sämtliche gängigen Konfigurations-Management-Paradigmen ist es definitiv nicht geeignet. (Und dass so eine Universal-Hammer, mit dem man alle Probleme zu erschlagen versucht, überhaupt Sinn macht, darf bezweifelt werden.)
-
daHa schrieb:
ironie
darf ich dir deine backends rausloeschen
weil du sie nicht siehst brauchst du sie anscheinend auch nicht
/ironie hahadie erklaehrung warum das so ist findest du in der praesentation
Die Backends brauchst du doch höchstens für eine Übergangszeit.
Sobald aber alle Programme Elektra beherrschen und direkt nutzen
brauchst du die nicht mehr.
-
nman schrieb:
Dieses "iiih, Registry, das muß wie bei Windows sein" sitzt dummerweise
viel zu tief in den meisten Köpfen.Dass Registry-Konzepte nur selten so mies sind, wie das bei Windows der Fall ist, ist allen klar, aber sie bergen letztlich auch viele der Gefahren, die es unter Windows dabei auch gibt.
Ok, dann zähle bitte einige der Gefahren auf, die auch wirlich auf Elektra zutreffen könnten.
EDIT: OK, ich geh mal eine Liste durch, hab die gerade entdeckt.
Die Entwickler von Elektra sind nicht in diesem Forum anwesend
und waren es höchstwahrscheinlich auch nie.Es sah einfach so aus, als sei Elektra Dein Projekt; Du hast es so vehement verteidigt, dass sich einem dieser Gedanke förmlich aufdrängte.
Ich habe es verteidigt weil ich es gut finde und denke, daß
Linux dadurch etwas gewinnen würde.
Es würde Mainstream tauglicher werden.
Der Support und das Schreiben von Produkten die auf allen Distris laufen sollen wird einfacher und Firmen würden sich dann auch eher trauen ihre propritäre Software auch für Linux anzubieten.Wenn ein Hersteller z.b. nur den Defaultbrowser für seine Anwendung herausfinden
wollen würde, dann würde allein dies schon ein nicht unerheblicher Programmieraufwand darstellen, schließlich soll das unter Gnome, Kde und X funktionieren.
Da ist es dann kein Wunder, wenn SW Firmen von Linux als Desktop OS abgeschreckt
werden oder ihre Anwendungen nur ein Bruchteil von dessen können, was ihre Windows Pendants können.Aber zu meiner Liste:
- Gängige Registry-Konzepte bringen einiges an Komplexität mit sich. Zu viel für einige Anwendungszwecke.
Bitte erläutere das genauer, am besten anhand eines kleinen Beispiels.
Was soll z.B. daran so falsch sein, wenn unser Simple-Programm nur 3 Key Value Paare in Elektra abspeichert und dazu Elektra nutzt?
Gut, das kann man natürlich auch schnell mit einer eigenen Configdatei realisieren, aber was spricht dagegen auch genausogut einfach Elektra dafür zu nutzen?- Registry-Konzepte können sich als nützlich erweisen, wenn es darum geht, Konfigurationsdaten für viele zusammengehörige Programme eines großen Environments zu speichern. Solche Systeme einem gesamten System überzustülpen wäre nur mäßig sinnvoll.
Und das ist auch der Grund warum zur Zeit nur KDE mit KDE kann und Gnome nur mit Gnome.
Der Defaultbrowser muß z.B. bei beiden Desktopenvironments nämlich separat eingestellt werden.Das schreit förmlich nach einem gesamten System, das Systemweit schon in den untersten Ebenen gilt. Daher verstehe ich dein Einwand nicht,
warum das nur mäßig sinnvoll sein soll.Selbst wenn Gnome KDE kann und KDE Gnome, was ist dann mit anderen Umgebungen
oder Umgebungen die direkt nur auf X setzen?- Egal, wie gut die Verwaltungs-Tools für ein Registry-System sind, Config-Dateien sind oftmals bequemer handhabbar. Jeder kann sie mit seinem Lieblings-Editor bearbeiten, man kann sie herumpipen, durchgreppen, diffen etc. Und das alles, ohne vorher irgendeinen Konverter zu bemühen und zu XML vergewaltigt zu werden.
Das trifft nicht auf Elektra zu.
Elektrakonfigurationsdateien sind peer Hand mit jedem beliebigen Editor
bearbeitbar.
Schließich sind das nur Dateien mit Key = Wertepaaren + Kommentar.- Registry-Systeme sind sehr GUI-zentriert. Auch wenn es CLI-Tools gibt, so können diese konzeptbedingt nur einen Bruchteil dessen leisten, was normale Konfigurationsdateien können. (siehe oben)
Edikga ist Scriptingfähig.
Und Scripte die mit Werten umgehen gehören meiner Meinung nach nicht in eine Konfigurationsdatei sondern in einen separate Datei die die Daten aus einer Konfigdatei abrufen.
Das sollte man trennen und wird, wie man sieht bei vielen Linux Distributionen inzwischen auch so gemacht.Das habe ich Z.b. erst wieder bei Slackware gesehen.
/etc/rc.d/rc.inet1.conf
Ist die Konfigurationsdatei
und
/etc/rc.d/rc.inet1
ist das Script.- Sämtliche Konfigurationen aller Programme eines Systems einem einzigen Tool zu überlassen wäre einfach nicht sehr unixy. Es gibt einfach zu viele Programme, die zu wenig gemeinsam haben, als dass sowas Sinn machen würde.
Wie schon gesagt, man muß die libelektra.so ja nicht nehmen.
Man darf auch gerne sein eigenes Ding schreiben und die Konfigurationsdaten das Elektra Systems bearbeiten.
Warum aber die Konfigurationsdaten nicht unter einer einheitlichen Konfigurationbasis gestellt werden sollen, wie du anführst, wird mir nicht ganz klar.unixy ist doch nur ein Vorwand nichts ändern zu wollen.
Und es gibt zwar Programme, deren Konfiguration erstmal von keinem einzigen Programm als dem eigenen gelesen werden, aber so etwas kann sich
auch mal ändern und ist oft zu Beginn nicht absehbar, das das passieren wird.Als Ersatz für KConfig und GConf wäre etwas Elektra-mäßiges durchaus ganz brauchbar, aber als Ersatz für sämtliche gängigen Konfigurations-Management-Paradigmen ist es definitiv nicht geeignet. (Und dass so eine Universal-Hammer, mit dem man alle Probleme zu erschlagen versucht, überhaupt Sinn macht, darf bezweifelt werden.)
Ok, das ist jetzt eine Befürchtung, aber das muß sich in der Praxis auch erstmal bewahrheiten.
Es sei denn, du kannst jetzt schon theoretisch ein Beispiel nennen
das sich auch wirlich so zutragen könnte.
-
Gasomat schrieb:
Supertux befürchtet, daß kein Programm mehr funktioniert,
wenn man die libelektra.so Lib löscht.
Das ist aber nur dann der Fall, wenn ein Programm diese libelektra.so Lib auch nutzt und ansonsten keine anderweitige Umgehung z.b. durch einen direkten Zugriff der Elektra Configdateien bietet.Dafür müsste aber die libelektra.so per dlopen geladen werden, weil das Programm sonst ja nicht startet.
Ich empfand die Furcht, das die libekektra.so Lib gelöscht werden könnte
ein bischen extrem übertrieben und irgendwie auch als Dumpfbackengeschwätz.
Und Dumpfbackengeschwätz beantwortet man eben auf die gleiche Methode."Hui, die QT Lib ist weg, mein KDE bricht zusammen.... Fazit: KDE ist höchst unsicher, daher besser nicht benutzen! Me <- Angst hab"
Wenn /usr auf einer anderen Partition liegt und nicht gemountet werden kann, kann das passieren. Dann starten nur Programme, die sich mit /bin und /lib zufrieden geben. Wenn man dann nicht mehr die fstab ändern kann, ist das schon schlecht, weil man dann sein System nicht mehr in einen brauchbaren zustand bekommt.
-
gasomat schrieb:
Es würde Mainstream tauglicher werden.
Der Support und das Schreiben von Produkten die auf allen Distris laufen sollen wird einfacher und Firmen würden sich dann auch eher trauen ihre propritäre Software auch für Linux anzubieten.Darüber lässt sich streiten. Viele sind der Meinung (ich auch), dass das Ziel von GNU/Linux nicht "Mainstream werden" ist. Außerdem haben die meisten Distribution unabhängige Projekte keine Projekte in die Distributionen eingebaut zu werden. Wenn du YaST in Debian laufen willst oder apt-get in SuSe, dann ist es schwer, dann bräuchte man schon ein System wie Elektra. Aber wenn ich z.B. an xorg denke, was ist an xorg so Distribution abhängig? Ich hab schon mal geschafft mit der selben xorg.conf (kleine Anpassungen an den Treiber Namen) den X Server unter Gentoo, Debian und SuSE zum Laufen zum bringen, ohne viel Aufwand. Also sehe ich kein Hindernis für propritäre Software ihre Produkte unter GNU/Linux anzubieten.
gasomat schrieb:
Wenn ein Hersteller z.b. nur den Defaultbrowser für seine Anwendung herausfinden
wollen würde, dann würde allein dies schon ein nicht unerheblicher Programmieraufwand darstellen, schließlich soll das unter Gnome, Kde und X funktionieren.Dein Problem ist, du denkst zu sehr ans Windows Verhalten. Unix kennt *kein* Defaultbrowser oder sowas. Defaultbrowser sind Sachen von den Desktop Environments wie KDE, Gnome, XFce, usw, aber keineswegs eine OS Angelegenheit. Ich habe auf meinen Rechner xorg 7 und fluxbox (kein KDE, kein GNOME,kein xfce), mein Rechner kennt kein Defaultbrowser. Wenn ein Programm, wie Gimp etwas in einem Browser starten will, fragt er was er nutzen soll oder unter Einstellungen kann ich sagen, was er nutzen soll. Wozu soll ich irgendwo eine unsinnige Konfiguration eines Defaultbrowsers haben, die keinen Sinn macht?
gasomat schrieb:
Da ist es dann kein Wunder, wenn SW Firmen von Linux als Desktop OS abgeschreckt
werden oder ihre Anwendungen nur ein Bruchteil von dessen können, was ihre Windows Pendants können.ich würde eher sagen, das leigt mehr an den Leuten, die an den Projekten arbeiten, als an Gnu/Linux. Sonst wäre KDE unmöglich zu programmieren, und die Tatsache, dass KDE existiert, ist Beweis, dass es möglich ist, sich ans System anzupassen.
gasomat schrieb:
Was soll z.B. daran so falsch sein, wenn unser Simple-Programm nur 3 Key Value Paare in Elektra abspeichert und dazu Elektra nutzt?
dass nicht jede Config Datei sich so beschreiben lässt. Hast du schon mal cfengine, nagios, inetd, cups, syslog usw. koniguriert? Dann wirst du merken, dass diese Konfigurationen sich wohl kaum in 3 Key Value Paare schreiben lassen (wenn das mit cfengine möglich wäre
)gasomat schrieb:
[*]Registry-Konzepte können sich als nützlich erweisen, ...
Und das ist auch der Grund warum zur Zeit nur KDE mit KDE kann und Gnome nur mit Gnome.
Der Defaultbrowser muß z.B. bei beiden Desktopenvironments nämlich separat eingestellt werden.weil GNU/Linux kein Windows ist. Unter Windows bist du gezwungen die graphische Oberfläche zu benutzen, die das OS mitbringt, während du bei GNU/Linux die Wahl hast. Und dass KDE nur mit KDE geht, ist auch nicht wahr. KDE ist eben KDE, was soll KDE mit Gnome anfangen? Wie gesagt, solche Argumente wie DefaultBrowser finde ich nicht so gut, weil es keine OS Angelegenheit ist sondern ein Feature eines bestimmtes Paketes ist, welches nicht global unterstützt werden soll.
gasomat schrieb:
Selbst wenn Gnome KDE kann und KDE Gnome, was ist dann mit anderen Umgebungen
oder Umgebungen die direkt nur auf X setzen?du sagst es, du kannst nicht erwarten, dass Fluxbox die KDE Konfiguration liest, wozu? Fluxbox ist eben Fluxbox und kein KDE. Und (am Beispiel des DefaultBrowsers) eine Anwendung sollte fragen, was sie benutzen sollte, statt dir etwas zu öffnen, was du gar nicht hast/willst/konfiguriert hast. Dieses Windows Verhalten sollte nicht in Unix Desktops übernommen werden.
gasomat schrieb:
Schließich sind das nur Dateien mit Key = Wertepaaren + Kommentar.
Wenn da so ist, dann wozu Elektra? Ein bash Skript mit sed+awk löst das auch.
gasomat schrieb:
Und Scripte die mit Werten umgehen
Und was genau bedeutet denn das?
gasomat schrieb:
Und Scripte die mit Werten umgehen gehören meiner Meinung nach nicht in eine Konfigurationsdatei sondern in einen separate Datei die die Daten aus einer Konfigdatei abrufen.
Das sollte man trennen und wird, wie man sieht bei vielen Linux Distributionen inzwischen auch so gemacht.Das verstehe ich gar nicht, ich verstehe nicht, worauf du hinaus willst. Nenn doch ein Beispiel.
Das habe ich Z.b. erst wieder bei Slackware gesehen.
/etc/rc.d/rc.inet1.conf
Ist die Konfigurationsdatei
und
/etc/rc.d/rc.inet1
ist das Script.Die Art und Weise, wie Distributionen ihre init.d Skripte schreiben, verwalten, konfigurieren ist eben unterschiedlich. Unter Gentoo hab ich nicht einmal ein /etc/rc.d Verzeichnis. Oder worauf willst du damit hinaus?
gasomat schrieb:
Warum aber die Konfigurationsdaten nicht unter einer einheitlichen Konfigurationbasis gestellt werden sollen, wie du anführst, wird mir nicht ganz klar.
siehe oben am bsp cfeninge
Außerdem sehe ich das ganze sehr skeptisch, weil ich das nur als GNU/Linux tauglich sehe. Was ist mit BSD oder Solaris der Mac oder Winodws selbst? Es gibt Software, die unter all diese Systeme kompiliert werden kann (z.b. Firefox). Soll eine zweite Registry unter Windows geben? Und was ist, wenn BSD und Solaris Entwickler Elektra ablehnen? Soll man in Zukunft nur für die Linux Versionen Elektra benutzen aber für die anderen Systeme eigene Parser?
-
ProgChild schrieb:
Wenn /usr auf einer anderen Partition liegt und nicht gemountet werden kann, kann das passieren. Dann starten nur Programme, die sich mit /bin und /lib zufrieden geben. Wenn man dann nicht mehr die fstab ändern kann, ist das schon schlecht, weil man dann sein System nicht mehr in einen brauchbaren zustand bekommt.
libelektra.so liegt in /lib
-
supertux schrieb:
Darüber lässt sich streiten. Viele sind der Meinung (ich auch), dass das Ziel von GNU/Linux nicht "Mainstream werden" ist.
"Mainstream werden" kann man ziemlich weit definieren.
Ich definiere "Mainstream werden" als:
Ein System ist so leicht zu benutzen,
daß ein Dau damit zurecht kommt.Andere definieren "Mainstream werden" als:
Ein System muß alles vor dem User verbergen und verstecken.
Oder aus einer festdefinierten Auswahl von Programmen bestehen. Der Desktop ist vorgeschrieben (z.b. KDE) etc..Wenn viele unter Mainstream werden das letztere verstehen, dann ist es kein Wunder, daß viele denken, daß dies nicht das Ziel ist.
Versteht man aber unter "Mainstream werden" das erste
und schaut sich dann noch die Entwicklung der letzten 5 Jahre an, dann
kann man mit ziemlicher Sicherheit sagen, das Linux in die Richtung "Mainstream werden" geht.Aber wenn ich z.B. an xorg denke, was ist an xorg so Distribution abhängig? Ich hab schon mal geschafft mit der selben xorg.conf (kleine Anpassungen an den Treiber Namen) den X Server unter Gentoo, Debian und SuSE zum Laufen zum bringen, ohne viel Aufwand. Also sehe ich kein Hindernis für propritäre Software ihre Produkte unter GNU/Linux anzubieten.
Stellt dir vor, eine Firma will propritäre Software schreiben, die alles verwalten kann, was in /etc steht.
Gut das wäre ein Extremfall.Machen wir es einfacher.
Wie wäre es mit einem Programm das ohne KDE oder Gnome läuft aber
dessen Konfigurationsdaten auslesen kann, um z.b. den Defaulteditor, Defaultbrowser, Defaultbildprogramm für JPEG Dateien etc. zu finden.
Das ist nicht wenig Aufwand so etwas zu implementieren.gasomat schrieb:
Wenn ein Hersteller z.b. nur den Defaultbrowser für seine Anwendung herausfinden
wollen würde, dann würde allein dies schon ein nicht unerheblicher Programmieraufwand darstellen, schließlich soll das unter Gnome, Kde und X funktionieren.Dein Problem ist, du denkst zu sehr ans Windows Verhalten. Unix kennt *kein* Defaultbrowser oder sowas. Defaultbrowser sind Sachen von den Desktop Environments wie KDE, Gnome, XFce, usw, aber keineswegs eine OS Angelegenheit.
Falsch, Defaultbrowser ist das, was der Benutzer standardmäig benutzen möchte!
Wenn er sich für Opera entscheidet, dann sollten alle Programme (z.b. beim Hilfesystem) auch nur Opera aufrufen und nicht Konqueror, oder Firefox oder sonstwas.
Gleiches gilt für den Defaulteditor.
Das ist der Editor, den der Benutzer immer benutzen möchte.
Wenn er also nano will, dann gib ihm kein vi oder emacs.Unter MacOS X, ein Unix, gibt es so etwas übrigens, das hat mit Windows oder
Windows Denken also nichts zu tun, das ist einfach eine Selbstverständlichkeit.Ich habe auf meinen Rechner xorg 7 und fluxbox (kein KDE, kein GNOME,kein xfce), mein Rechner kennt kein Defaultbrowser.
Also haben wir schon ein Problem.
Von wo soll ein Programm wissen, welchen Browser du am liebsten benutzen möchtest?Übrigens meldet dir ein KDE Programm, das die Hilfe aufruft einen Fehlermeldung, wenn du Konqueror nicht installiert hast und normalerweise Gnome als Desktop Env. + z.B. Firefox als Browser nutzt.
Und schon hast du einen Fehler der den User vom Arbeiten ablenkt.
Es ist also keineswegs die Aufgabe von den Desktop Environments dies festzulegen, sondern eine Aufgabe die nur systemweit gelöst werden kann.Wenn ein Programm, wie Gimp etwas in einem Browser starten will, fragt er was er nutzen soll oder unter Einstellungen kann ich sagen, was er nutzen soll.
Geile Lösung und ich als Benutzer darf das dann bei jedem Programm so einstellen, nicht nur Gimp, ich habe hunderte.
Mit einem globalen Konfigurationsort wäre das viel einfacher zu realisieren
und der Benutzer könnte sich auf die Arbeit konzentieren anstatt bei
hunderten von Programmen so etwas einstellen zu müssen.Es geht also auch um mehr Konsistenz.
Wozu soll ich irgendwo eine unsinnige Konfiguration eines Defaultbrowsers haben, die keinen Sinn macht?
Sie macht aber Sinn.
gasomat schrieb:
Da ist es dann kein Wunder, wenn SW Firmen von Linux als Desktop OS abgeschreckt
werden oder ihre Anwendungen nur ein Bruchteil von dessen können, was ihre Windows Pendants können.ich würde eher sagen, das leigt mehr an den Leuten, die an den Projekten arbeiten, als an Gnu/Linux. Sonst wäre KDE unmöglich zu programmieren, und die Tatsache, dass KDE existiert, ist Beweis, dass es möglich ist, sich ans System anzupassen.
KDE ist in sich geschlossen.
Das obige Beispiel mit der Hilfe zeigt es schon.Ein kommerzielles Programm muß aber auch Problemlos von einem Gnome oder Fluxbox oder sonstwas Desktop aus funktionieren und wenn ein Browser schon installiert ist, dann kann das Programm nicht verlangen nachträglich noch Konqueror zu installieren.
[quote="gasomat"]
Was soll z.B. daran so falsch sein, wenn unser Simple-Programm nur 3 Key Value Paare in Elektra abspeichert und dazu Elektra nutzt?dass nicht jede Config Datei sich so beschreiben lässt. Hast du schon mal cfengine, nagios, inetd, cups, syslog usw. koniguriert? Dann wirst du merken, dass diese Konfigurationen sich wohl kaum in 3 Key Value Paare schreiben lassen (wenn das mit cfengine möglich wäre
)In 3 nicht, aber in mehreren.
Hier mal init als Beispiel:
http://puzzle.dl.sourceforge.net/sourceforge/elektra/README.sysvinit.Elektra.txtAußerdem kann man sich das ganz einfach überlegen,
denn alle Konfigurationsdateien, die mit XML realisierbar wären,
kriegt man auch mit key value Paare in Elektra hin.XML ist nämlich nichts anderes als:
<key>value</key>Also muß man sich nur fragen:
Ist inetd, cups, syslog usw mit xml realisierbar?
Wenn die Antwort ja ist, dann geht das auch mit Elektra und dessen Key=value Paaren.Nagios, cfengine kenne ich nicht.
gasomat schrieb:
[*]Registry-Konzepte können sich als nützlich erweisen, ...
Und das ist auch der Grund warum zur Zeit nur KDE mit KDE kann und Gnome nur mit Gnome.
Der Defaultbrowser muß z.B. bei beiden Desktopenvironments nämlich separat eingestellt werden.weil GNU/Linux kein Windows ist. Unter Windows bist du gezwungen die graphische Oberfläche zu benutzen, die das OS mitbringt, während du bei GNU/Linux die Wahl hast.
Schau dir Mac OS X an, ein Unix!
Und dass KDE nur mit KDE geht, ist auch nicht wahr.
Das ist wahr.
KDE öffnet nämlich Konqueror wenn man auf Hilfe drückt, obwohl man gerade Gnome benutzt und nur ne KDE Anwendung gestartet hat in der man die Hilfe aufruft.
Dabei wäre vielleicht Firefox sinnvoler gewesen, weil Konqueror gar nicht installiert ist. (z.b. bei Ubuntu 6.10 in der Defaultinstallation der Fall)KDE ist eben KDE, was soll KDE mit Gnome anfangen? Wie gesagt, solche Argumente wie DefaultBrowser finde ich nicht so gut, weil es keine OS Angelegenheit ist sondern ein Feature eines bestimmtes Paketes ist, welches nicht global unterstützt werden soll.
Das sehe ich anders. Siehe oben.
Ein heutiger Desktop besteht in der Regel aus einem Mischbetrieb,
also sollten Anwendungen von KDE auch auf einen Gnome Desktop
einen Browser starten können und umgekehrt.Und Mischbetrieb deswegen, weil der User in der Regel das will,
was für ihn am besten funktioniert und kein Desktopsystem mit seinen Desktopenvironment spezifischen Anwendungen alle Wünsche des Users abdecken kann.Ich habe z.B. schonmal versucht nur KDE Anwendungen zu benutzen.
Aber das ging nicht. Ich brauche nämlich Gimp (gtk 2.0 Anwendung) und bevorzuge Totem anstatt Noatun. Und geh weg mit xine, totem finde ich handlicher.Dann habe ich den umgekehrten Weg versucht, also nur Gnome und GTK Apps zu verwenden.
Aber das ging auch nicht, ich brauche nämlich qjackctl und Rosegarden.
Und ich bevorzuge k3b gegenüber gnome-baker.Kurz gesagt es ist ein Mischmasch aus allem und dann ist es halt schon wichtig,
daß alle Anwendungen den gleichen Browser aufrufen wenn ich auf Hilfe drücke.gasomat schrieb:
du sagst es, du kannst nicht erwarten, dass Fluxbox die KDE Konfiguration liest, wozu?
Eben und das wird auch nie der Fall sein, das Flugbox die KDE Konfiguration liest und Blackbox die Gnome Konfiguration.
Deswegen muß man die Konfiguration eine Ebene weiter unten ansetzen und Systemweit machen, für alle.Fluxbox ist eben Fluxbox und kein KDE. Und (am Beispiel des DefaultBrowsers) eine Anwendung sollte fragen, was sie benutzen sollte, statt dir etwas zu öffnen, was du gar nicht hast/willst/konfiguriert hast.
Ich kann unter Gnome oder in KDE einen Defaulbrowser festlegen.
Nur wenn ich das unter einem KDE Desktop mache, dann sollte auch automatisch
die Gnome Anwendungen darin in Kenntnis gesetz werden, bzw. dies wissen.Ich will das also nur einmal machen müssen und nicht zig mal.
Dieses Windows Verhalten sollte nicht in Unix Desktops übernommen werden.
Wie ich schon sagte, das ist Mac OS X Verhalten, es ist sogar "Selbstverständlich Verhalten".
gasomat schrieb:
Schließich sind das nur Dateien mit Key = Wertepaaren + Kommentar.
Wenn da so ist, dann wozu Elektra? Ein bash Skript mit sed+awk löst das auch.
Die Konfiguration sind letzten endes zwar nur Key = Wertepaare,
aber Elektra ist mehr als nur eine Key + Wertpaare, das ist nur eine Teilmenge davon.
Es liefert auch eine libelektra.so Datei + Kommandozeilentools.
Sowieso Backends und Alternative Speicehrungsmöglichen -> RDB.Die Wikipedia beschreibt das besser.
http://de.wikipedia.org/wiki/Elektra_InitiativeEs ist eine Initiative.
Ich würde es als systemweite Lösung für die Konfiguration von Anwendungsdateien sehen.MySQL ist z.b. auch nicht nur eine Datenbank, sondern ein Datenbankmanagementsystem besteht aus dem DBMS und den Datenbankdateien.
Es beschreibt also etwas größeres bestehend aus mehreren Teilmengen.[quote="gasomat"]
Und Scripte die mit Werten umgehenUnd was genau bedeutet denn das?
Werte sind das, mit denen ein Script arbeitet.
Ein Script für eine iptables Firewall hat z.b. als Wert
den Devicenamen (z.B. eth0) auf welche die Firewall wirken soll.In der Regel benutzen Scripte zur Realisierung dieses ganzen Variablen.
Variablen behinhalten dann den Inhalt, der Inhalt ist ein Wert.gasomat schrieb:
Und Scripte die mit Werten umgehen gehören meiner Meinung nach nicht in eine Konfigurationsdatei sondern in einen separate Datei die die Daten aus einer Konfigdatei abrufen.
Das sollte man trennen und wird, wie man sieht bei vielen Linux Distributionen inzwischen auch so gemacht.Das verstehe ich gar nicht, ich verstehe nicht, worauf du hinaus willst. Nenn doch ein Beispiel.
Siehe oben das iptables Firewallscript Beispiel.
Die Art und Weise, wie Distributionen ihre init.d Skripte schreiben, verwalten, konfigurieren ist eben unterschiedlich. Unter Gentoo hab ich nicht einmal ein /etc/rc.d Verzeichnis. Oder worauf willst du damit hinaus?
Das die eigentliche Konfiguration, welche immer aus Werten besteht
von Scripten, also einem Algorithmus getrennt werden soll.gasomat schrieb:
Warum aber die Konfigurationsdaten nicht unter einer einheitlichen Konfigurationbasis gestellt werden sollen, wie du anführst, wird mir nicht ganz klar.
siehe oben am bsp cfeninge
Tut mir leid, aber cfengine kenne ich nicht und habe
das auch nicht auf meinen System.Ich kann mir darunter also nichts vorstellen.
Aber ich würde mal vom Namen ausgehen, daß cfengine ein Script ist.
Schließlich bedeutet Engine = Motor bzw. kenne ich so etwas wie Spieleengines
die mit 3d Daten umgehen.Wenn das der Fall ist, dann sehe ich da kein Problem, denn cfengine ist ja dann ein Scipt.
Sollte cfengine Daten benötigen mit denen es Arbeitet, also Werte, dann kann man die in Elektra speichern und bei Bedarf mit dem Script cfengine abrufen und benutzen.Außerdem sehe ich das ganze sehr skeptisch, weil ich das nur als GNU/Linux tauglich sehe. Was ist mit BSD oder Solaris der Mac oder Winodws selbst?
Elektra soll auch unter Windows und anderen Betriebsystemen funktionieren.
Selbstverständlich wäre dann Elektra im Falle von Windows eine Abstraktionsschicht zwischen Elektraanwendung und Windows Registry, da das Elektra Projekt auf Windows selbst ja keinen Einfluß hat.Siehe dazu auch die Elektra Doku für weiteres.
Elektra wäre somit auch ein Plattformunabhängiges Konfigurationssystem.
Es gibt Software, die unter all diese Systeme kompiliert werden kann (z.b. Firefox). Soll eine zweite Registry unter Windows geben?
Siehe oben.
Es gibt nun zwei Lösungsmöglichkeiten.
Entweder man macht Firefox zu einer Elektra Anwendung
oder man liest die Firefoxkonfiguration aus der Windows Registry in das Elektrasystem ein, so daß andere Elektra Anwendungen auf diese Konfiguration über das Elektrasystem zugreifen können.Und was ist, wenn BSD und Solaris Entwickler Elektra ablehnen? Soll man in Zukunft nur für die Linux Versionen Elektra benutzen aber für die anderen Systeme eigene Parser?
Ablehnen können Elektra doch nur diejenigen, die die Programme schreiben,
deren Konfiguration plötzlich auf Elektrakonfiguration umgestellt werden sollen.D.h. wenn ich mich als Entwickler dazu entschließe, bei meinem Programm zur Speicherung der Konfiguration Elektra zu benutzen, dann werden die anderen,
die mein Programm nutzen das fressen müssen.Das tun sie ja schließlich heute bei den normalen Configfiles ja auch.
Wenn ich ein Programm schreibe das eine Eigenbau Superkompliziert Configdatei
ähnlich wie sendmail verwendet, dann werden die Distributoren, FreeBSD etc. das halt so hinnehmen müssen oder mein Programm draußen lassen.
Genau so läuft es doch bei den Tausend unteschiedlichen Configfiles heute so ab.Oberflächlich betrachtet, ist Elektra also nur eine weitere Form von unterschiedlichen Konfigurationssyntaxarten, mit dem Unterschied, das
diese halt auch eine einheitliche Konfiguration für alle werden könnte bzw. das potential dazu hätte, während die sendmail Konfiguration halt nur für Sendmail gut ist (wenn überhaupt).
-
Diese Diskussion wird mir langsam zu blöd, denn dieser Thread hat meiner Meinung nach nicht mehr mit Elektra zu tun als mit mit einem Flameware GNOME vs. KDE vs. alles andere und drehen wir uns nur im Kreis.
Wenn du dich so stur verhälst, ist deine Sache. Ich persönlich sehe keine Zukunft für dieses Projekt, welches zwar interessant ist, aber nicht so implementiert, um die gesamte Unix Comunit davn zu überzeugen, und ich werde versuche zu erleutern, was ich z.b. an deiner Argumentation schlecht finde.
1. Es gibt keinen DefaultBrowser, es gibt niergends eine Datei in /etc (oder bash.profile, oder was auch immer), der auf einen DefaultBrowser hinweist. DefaultBrowser ist eine Erfindung von den Desktop Environments. Ich habe keinen und ich hab auch kein Programm, was mir etwas öffnet, was ich nicht will.
2. Ich bin der Meinung, dass alle Programme fragen sollen (oder sich konfigurieren lassen sollen), welchen Browser sie öffnen sollen. Sie müssen nicht raten, sie müssen fragen. An dem Punkt bin ich nicht mit dir einverstanden, und viele Leute werden wahrscheinlich auch meine Meinung teilen.
3. Default editor: In /etc/profile definiert (in den meisten Distros) und kann mit man: getenv(3) gelesen werden.
4.Stellt dir vor, eine Firma will propritäre Software schreiben, die alles verwalten kann, was in /etc steht.
Gut das wäre ein Extremfall.Will ich nicht, und kann ich nicht, und hoffentlich wird es sowas nie geben. Außerdem muss ein Programm nicht zwangsläufig seine Config unter /etc speichern.
5.dessen Konfigurationsdaten auslesen kann, um z.b. den Defaulteditor, Defaultbrowser, Defaultbildprogramm für JPEG Dateien
Nochmal, sowas gibt es standardmäßig nicht. Ich hab auf meinen Rechner keine dieser Einstellungen und komme sehr gut zurecht. Was soll es mir bei Fluxbox bringen, wenn ich sowieso mit einer Konsole meine Programme starte? Das ist wie gesagt eine reine Desktop Envoironment Sache, keine OS Sache.
Also haben wir schon ein Problem.
Von wo soll ein Programm wissen, welchen Browser du am liebsten benutzen möchtest?Sie sollen nicht raten, sie sollen mich fragen. Ich will mein System sagen, was es tun soll.
Und ich sehe auch keinen Sinn, warum mein Fluxbox irgendwelche KDE Konfigurationen lesen sollte. Angenommen KDe lässt sich per Elektra konfigurieren und dadurch kann mein Fluxbox die KDE Konfiguration lesen: Welchen Vorteil habe ich als Fluxbox Benutzer? Ich sehe keinen, das macht keinen Sinn, weil Fluxbox kein KDE ist und kein KDE braucht, um seine Arbeit zu verrichten.
Das sehe ich anders. Siehe oben.
Ein heutiger Desktop besteht in der Regel aus einem Mischbetrieb,
also sollten Anwendungen von KDE auch auf einen Gnome Desktop
einen Browser starten können und umgekehrt.Und da haben wir wieder einen großen Unterschied. Ich brauche keinen Desktop wie du, also sind all deine Argumente diesbzgl. für mich irrelevant. Wie gesagt, das ist nur eine Desktop Env. Sache, keine OS Sache. Was man da machen kann, ist eine gemeinsame Konfig Plattform für Desktop Environments zu schaffen, aber nicht für das gesamte System, welches nichts mit dem Desktop zu tun hat.
Tut mir leid, aber cfengine kenne ich nicht und habe
das auch nicht auf meinen System.Ich kann mir darunter also nichts vorstellen.
Aber ich würde mal vom Namen ausgehen, daß cfengine ein Script ist.
Schließlich bedeutet Engine = Motor bzw. kenne ich so etwas wie Spieleengines
die mit 3d Daten umgehen.Wenn das der Fall ist, dann sehe ich da kein Problem, denn cfengine ist ja dann ein Scipt.
Sollte cfengine Daten benötigen mit denen es Arbeitet, also Werte, dann kann man die in Elektra speichern und bei Bedarf mit dem Script cfengine abrufen und benutzen.Wenn du es nicht weißt, dann informiere dich, bevor du Unsinn redest.
Ich sehe generell, dass du nur Arguemnte im Desktop Bereich hast. Ok, da kann ich dir vielleicht Recht geben, dass man sich selbst als Benutzer eine bessere Interaktion der Desktop Environments miteinander wünschen kann, aber das ist wie gesagt, eine Desktop Sache, die mit dem gesamten System nichts zu tun hat. Und deswegen finde ich nicht ok, dass das ganze System mit Elektra konfiguriert werden soll. Wozu mein braucht apache auf meinen Server zu wissen, welcher mein "DeafultBrowser" für KDE und Gnome ist, wenn ich nicht mal einen X Server am Laufen habe?
Mach was du willst, benutze Elektra, wenn du es willst, aber ich sehe keine ernshafte Zukunft in diesem Projekt, kaum ein Team wird seine Arbeit Elektra tauglich zu machen, dazu ist das meiner Meinung nach zu spät.
PS: Ich kenne wegen der Uni viele propietäre Software, die unter Solaris läuft, und bisher habe keine deiner Argumente als Problem gesehen.
-
supertux schrieb:
1. Es gibt keinen DefaultBrowser, es gibt niergends eine Datei in /etc (oder bash.profile, oder was auch immer), der auf einen DefaultBrowser hinweist. DefaultBrowser ist eine Erfindung von den Desktop Environments. Ich habe keinen und ich hab auch kein Programm, was mir etwas öffnet, was ich nicht will.
Da man den DefaultBrowser aber selber festlegt, kann man davon ausgehen,
daß man das will.
Es wird erst dann gefragt, wenn noch kein DefaultBrowser festgelegt wurde.2. Ich bin der Meinung, dass alle Programme fragen sollen (oder sich konfigurieren lassen sollen), welchen Browser sie öffnen sollen. Sie müssen nicht raten, sie müssen fragen. An dem Punkt bin ich nicht mit dir einverstanden, und viele Leute werden wahrscheinlich auch meine Meinung teilen.
Jetzt sag bloß, daß du bei der Gnome Hilfe "Konqueror", bei Kedit "Opera"
und bei Konqueror "Firefox" geöffnet haben willst.
Das glaube ich dir nämlich nicht.Fakt ist, das das aus Usability Gesichtspunkten Unsinn ist, denn Benutzer jedesmal aufs neue nach dem zu verwendenden Browser zu fragen.
Wenn du so etwas spezielles, also für jede App einen anderen Browserm, haben willst, dann kann man so etwas auch separat in den Optionen der Anwendung
festlegen.
Aber danach zu fragen ist schlecht, weil das vom Arbeiten abhält.
Der Benutzer soll seine Arbeit machen können und nicht mit herumkonfiguriererei belästigt werden.3. Default editor: In /etc/profile definiert (in den meisten Distros) und kann mit man: getenv(3) gelesen werden.
Wenn du diese Abfragefunktion in ein Programm einbaust,
dann muß sie nicht nur eine Environmentvariable abfragen können,
sondern auch noch die eigene Konfigurationsdaten lesen können.
Ich finde das könnte man vereinheitlichen, dann braucht man für alle Abfragen nur noch eine einzige Generalfunktion.
Das ist viel eleganter.Stellt dir vor, eine Firma will propritäre Software schreiben, die alles verwalten kann, was in /etc steht.
Gut das wäre ein Extremfall.Will ich nicht, und kann ich nicht,
Willst du nicht, kannst du nicht, andere wollens, andere könnens.
Außerdem muss ein Programm nicht zwangsläufig seine Config unter /etc speichern.
Womit dann der Beweis erbracht wurde, das das noch viel komplexer wird, wenn jetzt auch noch /usr/share/appname & Co abgefragt werden können soll.
Bei Elektra wäre alles unter einem Dach.
dessen Konfigurationsdaten auslesen kann, um z.b. den Defaulteditor, Defaultbrowser, Defaultbildprogramm für JPEG Dateien
Nochmal, sowas gibt es standardmäßig nicht. Ich hab auf meinen Rechner keine dieser Einstellungen und komme sehr gut zurecht. Was soll es mir bei Fluxbox bringen, wenn ich sowieso mit einer Konsole meine Programme starte?
Aha, und wenn du in eines deiner gestarteten Programme auf Hilfe klickst,
öffnet sich die Konsole in der du dann den zu startenden Browser eingeben kannst.
Das ist wie gesagt eine reine Desktop Envoironment Sache, keine OS Sache.
Das Ziel von GNU/Linux ist World Domination und dazu muß es auch den Desktop erreichen.
Also haben wir schon ein Problem.
Von wo soll ein Programm wissen, welchen Browser du am liebsten benutzen möchtest?Sie sollen nicht raten, sie sollen mich fragen. Ich will mein System sagen, was es tun soll.
Das kannst du doch in dem du den Defaultbrowser auf deinen dir gewünschten Browser setzt.
Aber ja, ich vergaß, du bentutz ja für jede App einen anderen Browser.
Du mußt nen PC mit viel RAM haben.Und ich sehe auch keinen Sinn, warum mein Fluxbox irgendwelche KDE Konfigurationen lesen sollte. Angenommen KDe lässt sich per Elektra konfigurieren und dadurch kann mein Fluxbox die KDE Konfiguration lesen: Welchen Vorteil habe ich als Fluxbox Benutzer? Ich sehe keinen, das macht keinen Sinn, weil Fluxbox kein KDE ist und kein KDE braucht, um seine Arbeit zu verrichten.
Nun, z.b. möchtest du eine KDE Anwendung verwenden, hast jetzt aber kein KControl-Center installiert, willst das auch nicht installieren da es ja Platz braucht, tja und jetzt möchtest du die Schriftart in dieser KDE Anwendung verändern.
Da die Schriftart für eine KDE Anwendung in der Regel global für alle KDE Anwendungen von KDE's KControl-center eingestellt wird, hättest du jetzt Pech
oder im Fall von Elektra Glück, da man ja auch eine Defaultschriftart Systemweit einführen könnte die nur noch über ein Elektra fähiges Program, das dafür zuständig ist (nennen wir es mal Defaultsetter), eingestellt werden müßte.
Oder, da du das Default zeug nichts magst, benutzt du einfach auf Hardcore das Elektra Kommandozeilentool um die Schriftart für alle KDE Anwendungen festzulegen, ganz ohne das KControl-Center.Ich wette du bist in einem von dir bekannten und regelmäßig benutzen Elektra
Konfigurationsbaum schneller am Ziel, als wenn du erst die Konfigurationsdateien und deren Syntax von KDE Konfigurationen kennenlernst.Das sehe ich anders. Siehe oben.
Ein heutiger Desktop besteht in der Regel aus einem Mischbetrieb,
also sollten Anwendungen von KDE auch auf einen Gnome Desktop
einen Browser starten können und umgekehrt.Und da haben wir wieder einen großen Unterschied. Ich brauche keinen Desktop wie du, also sind all deine Argumente diesbzgl. für mich irrelevant.
Es aber nicht um dich, sondern um den Mainstreammarkt und der kann so etwas gut gebrauchen.
Wie gesagt, das ist nur eine Desktop Env. Sache, keine OS Sache.
Ja, wir drehen uns im Kreis.
Ich sehe diesen Punkt nämlich anders als du.Was man da machen kann, ist eine gemeinsame Konfig Plattform für Desktop Environments zu schaffen, aber nicht für das gesamte System, welches nichts mit dem Desktop zu tun hat.
Ok, jetzt kommen wir einen Schritt weiter.
Aber jetzt gibt es auch Dinge die nicht in erster Linie nur von Desktopumgebungen betroffen sind sondern auch gut von der Konsole aus brauchbar wären.
Z.B. den Defaultprinter
Also warum sollte man eine gemeinsame Konfig Platform für DesktopEnv. schaffen,
wenn man auch eine Ebene tiefer gehen könnte.Oder anders gesagt, was spricht dagegen, so eine gemeinsame Konfigplattform weiter unten auf einer tieferen Systemebene anzulegen?
Mir fällt da nichts ein, bin aber gespannt was du dazu sagst.
Wenn du es nicht weißt, dann informiere dich, bevor du Unsinn redest.
Dazu müßte ich es installieren um es wirklich kennenzulernen.
Ich sehe generell, dass du nur Arguemnte im Desktop Bereich hast. Ok, da kann ich dir vielleicht Recht geben, dass man sich selbst als Benutzer eine bessere Interaktion der Desktop Environments miteinander wünschen kann, aber das ist wie gesagt, eine Desktop Sache, die mit dem gesamten System nichts zu tun hat. Und deswegen finde ich nicht ok, dass das ganze System mit Elektra konfiguriert werden soll. Wozu mein braucht apache auf meinen Server zu wissen, welcher mein "DeafultBrowser" für KDE und Gnome ist, wenn ich nicht mal einen X Server am Laufen habe?
Weil du z.b. ein Setuptool hast, mit dem man Apache und noch zig andere Programme, Dienste, Server etc. konfigurieren kann, welches jetzt aber nicht extra Apache Configsyntax kennenlernen soll.
Das letztere kannst du dir nämlich ersparen, wenn du
Apache beibringt, das einheitliche Konfigsystem namens elektra zu lernen.
Und genau das trifft auf so jede Anwendung, Dienst, Server etc. zu.Das Samba Team hat ürbigens an Elektra schon interesse gezeigt, siehe die Newspage auf der Elektra Homepage.
http://www.libelektra.org/News#04.2F24.2F06_-_Samba.2C_Google.27s_Summer_of_CodeMach was du willst, benutze Elektra, wenn du es willst, aber ich sehe keine ernshafte Zukunft in diesem Projekt, kaum ein Team wird seine Arbeit Elektra tauglich zu machen, dazu ist das meiner Meinung nach zu spät.
Abwarten.
Es wurden schon ganze Programme neu geschrieben um ein neues Ziel zu ereichen
an das man früher gar nicht gedacht hat.PS: Ich kenne wegen der Uni viele propietäre Software, die unter Solaris läuft, und bisher habe keine deiner Argumente als Problem gesehen.
Naja, ich habe dir schon eines der stärkste Argumente genannt.
Für den Normal Dau wird es einfacher werden ein Linux System zu installieren, konfigurieren und zu benutzen, da es einfacher wird GUI Setup Programme zu
schreiben die auch funktionieren und nicht nur nett aussehen, weil die dahinterliegende Konfiguration vereinheitlicht ist und somit das Gui Programm robuster und einfacher aus Programmierersicht zu realisieren ist.Wir beide wissen wie fehlerträchtig Yast manchmal sein kann und
warum die meisten Linux Gurus immer noch über nen Editor und ne Konsole
konfigurieren.
Der Hauptgrund ist der, daß die Guis meist nicht das machen was man will.
Und die Ursache ist die, das Gui Setup Programme ziemliche Schwierigkeiten mit
den derzeitigen Konfigurationsdateien haben.
-
Ich habe es verteidigt weil ich es gut finde und denke, daß
Linux dadurch etwas gewinnen würde.
Es würde Mainstream tauglicher werden.Die Mainstream-Tauglichkeit eines Betriebssystems kann man nicht daran messen, ob es eine Registry hat, oder nicht. Gerade im Serverbereich _ist_ GNU/Linux Mainstream und im Corporate-Desktop-Bereich wird es das langsam auch.
Der Support und das Schreiben von Produkten die auf allen Distris laufen sollen wird einfacher und Firmen würden sich dann auch eher trauen ihre propritäre Software auch für Linux anzubieten.
Und das würde der FOSS-Community was genau bringen? Dass proprietäre Anwendungen etwas positives sind, musst Du mir erst näher bringen.
Wenn ein Hersteller z.b. nur den Defaultbrowser für seine Anwendung herausfinden wollen würde, dann würde allein dies schon ein nicht unerheblicher Programmieraufwand darstellen, schließlich soll das unter Gnome, Kde und X funktionieren.
Nein, man schreibt Programme ohnehin nur für KDE, Gnome _oder_ Plain-X. Für mehr reicht normalerweise die Entwicklerzeit einfach nicht aus.
Da ist es dann kein Wunder, wenn SW Firmen von Linux als Desktop OS abgeschreckt werden oder ihre Anwendungen nur ein Bruchteil von dessen können, was ihre Windows Pendants können.
Das stimmt so einfach nicht. Kann OpenOffice unter GNU/Linux weniger als unter Windows? Brauchst Du mehr Funktionalität unter k3b? Ist Dein Windows-XChat schöner als die GNU/Linux-Version?
Du verwendest offensichtlich das falsche Betriebssystem. GNU/Linux ist nicht Windows. Wenn Du ein freies Windwos suchst, dann schau Dir ReactOS an.
Bitte erläutere das genauer, am besten anhand eines kleinen Beispiels.
Was soll z.B. daran so falsch sein, wenn unser Simple-Programm nur 3 Key Value Paare in Elektra abspeichert und dazu Elektra nutzt?
Mein Simple-Programm ist ein kleines Shell-Script, das einfach nur eine ~/.kleinesshellscriptrc sourcen müsste, was hat denn da Elektra für Vorteile?
Und das ist auch der Grund warum zur Zeit nur KDE mit KDE kann und Gnome nur mit Gnome. Der Defaultbrowser muß z.B. bei beiden Desktopenvironments nämlich separat eingestellt werden.
KDE und Gnome arbeiten derzeit gemeinsam, um sowas zu verbessern. Die Browsersache wäre übrigens ganz einfach, man müsste nur die $BROWSER-Umgebungsvariable beachten.
Selbst wenn Gnome KDE kann und KDE Gnome, was ist dann mit anderen Umgebungen oder Umgebungen die direkt nur auf X setzen?
Es soll auch GUI-lose Programme geben.
Das trifft nicht auf Elektra zu.
Elektrakonfigurationsdateien sind peer Hand mit jedem beliebigen Editor
bearbeitbar.
Schließich sind das nur Dateien mit Key = Wertepaaren + Kommentar.Oh, stimmt. Trotzdem kann man sowas nicht vernünftig mit den Unix-Texttools durchforsten, weil so viel Müll drinsteht.
Edikga ist Scriptingfähig.
Und Scripte die mit Werten umgehen gehören meiner Meinung nach nicht in eine Konfigurationsdatei sondern in einen separate Datei die die Daten aus einer Konfigdatei abrufen.Soll das jetzt eine Antwort auf meinen Text sein? Ich glaube, Du hast da einfach etwas missverstanden.
Das sollte man trennen und wird, wie man sieht bei vielen Linux Distributionen inzwischen auch so gemacht.
Das habe ich Z.b. erst wieder bei Slackware gesehen.
/etc/rc.d/rc.inet1.conf
Ist die Konfigurationsdatei
und
/etc/rc.d/rc.inet1
ist das Script.Das ist schwach. Debian hat dafür /etc/default, Gentoo /etc/conf.d, ... Das ist wesentlich sauberer.
Wie schon gesagt, man muß die libelektra.so ja nicht nehmen.
Man darf auch gerne sein eigenes Ding schreiben und die Konfigurationsdaten das Elektra Systems bearbeiten.Du hast die Aussage nicht verstanden. Es macht einfach keinen Sinn, dass Apache, Bind, xscreensaver und TuxRacer sich ein Konfigurationsschmea teilen.
Wenn KMail, KWrite, Kopete und Co. das tun, dann ist das schön, immerhin gehören sie zu einem gemeinsamen Desktop Environment. Darüber hinaus ist das nicht erstrebenswert. (Und wenn ich die libeleketra.so nicht verwende, dann macht Elektra erst überhaupt keinen Sinn.)
unixy ist doch nur ein Vorwand nichts ändern zu wollen.
"Wenn es nichts bringt nichts ändern zu wollen." um genau zu sein.
Und es gibt zwar Programme, deren Konfiguration erstmal von keinem einzigen Programm als dem eigenen gelesen werden, aber so etwas kann sich
auch mal ändern und ist oft zu Beginn nicht absehbar, das das passieren wird.Wenn man sich für ein einigermaßen gängiges Config-File-Format entschieden hat, dann ist so eine Erweiterung aber völlig trivial.
Ok, das ist jetzt eine Befürchtung, aber das muß sich in der Praxis auch erstmal bewahrheiten.
Es sei denn, du kannst jetzt schon theoretisch ein Beispiel nennen
das sich auch wirlich so zutragen könnte.Ich muss hier überhaupt nichts nennen. Du bist derjenige, der uns einreden will, dass es eine einzige Lösung auf all unsere Config-Probleme gibt, die keine Nachteile hat und den Weltfrieden bringen wird. Bei sowas müssen gute Entwickler einfach misstrauisch sein, hat es schon viel zu oft gegeben.
-
Gasomat schrieb:
Das Ziel von GNU/Linux ist World Domination und dazu muß es auch den Desktop erreichen.
Brr, was für ein Riesen-Blödsinn.
Wie gesagt, das ist nur eine Desktop Env. Sache, keine OS Sache.
Ja, wir drehen uns im Kreis.
Ich sehe diesen Punkt nämlich anders als du.Tja, leider hat er Recht und Du nicht. Mein OS hat nichts damit zu tun, womit ich in meinem Windowmanager am liebsten JPEGs aufmache oä.
Ok, jetzt kommen wir einen Schritt weiter.
Aber jetzt gibt es auch Dinge die nicht in erster Linie nur von Desktopumgebungen betroffen sind sondern auch gut von der Konsole aus brauchbar wären.
Z.B. den DefaultprinterAutsch. Hierfür bekommst Du die goldene DAU-Nadel ausgehändigt. Hast Du schon mal was von Cups gehört? Von LPR? Von irgendwas was sich Drucksystem-mäßig in den letzten dreißig Jahren auf Unix-Systemen so getan hat?
Also warum sollte man eine gemeinsame Konfig Platform für DesktopEnv. schaffen, wenn man auch eine Ebene tiefer gehen könnte.
Weil die Ebene darunter möglichst unangetastet bleiben soll und es keinen Vorteil bringt, diese auch noch miteinzubeziehen.
Der Hauptgrund ist der, daß die Guis meist nicht das machen was man will.
Und die Ursache ist die, das Gui Setup Programme ziemliche Schwierigkeiten mit
den derzeitigen Konfigurationsdateien haben.So ein Schwachsinn. GUI-Konfigurationstools müssen entweder genau gleich aussehen wie Configdateien, oder zusätzliche Abstraktionsebenen einführen. Und sobald diese da sind, hat man keine 100%ige Kontrolle mehr über die Konfiguration. Das ist von gewissen Benutzerkreisen erwünscht und von manchen nicht, das ist das Problem.
-
nman schrieb:
Ich habe es verteidigt weil ich es gut finde und denke, daß
Linux dadurch etwas gewinnen würde.
Es würde Mainstream tauglicher werden.Die Mainstream-Tauglichkeit eines Betriebssystems kann man nicht daran messen, ob es eine Registry hat, oder nicht. Gerade im Serverbereich _ist_ GNU/Linux Mainstream und im Corporate-Desktop-Bereich wird es das langsam auch.
Eine Registry hat Gui Setup Programme zur Folge und die sind so Intuitiv
das dadurch das OS Mainstream tauglich wird.Der Support und das Schreiben von Produkten die auf allen Distris laufen sollen wird einfacher und Firmen würden sich dann auch eher trauen ihre propritäre Software auch für Linux anzubieten.
Und das würde der FOSS-Community was genau bringen? Dass proprietäre Anwendungen etwas positives sind, musst Du mir erst näher bringen.
Wer sagt hier, daß es um die FOSS COmmunity geht, bzw. der FOSS Community etwas bringen soll.
Tatsache ist das vielen Leuten die Linux benutzen Photoshop und massig professioneller Spiele fehlen, die kommen aber nur, wenn der Marktanteil von Linux größer wird und das geht nur wenn Linux so einfach zu konfigurieren wird,
das auch jeder Dau zu Linux wechselt.
Und das einfache Konfigurieren kommt von ...siehe oben.[QUOTE}
Wenn ein Hersteller z.b. nur den Defaultbrowser für seine Anwendung herausfinden wollen würde, dann würde allein dies schon ein nicht unerheblicher Programmieraufwand darstellen, schließlich soll das unter Gnome, Kde und X funktionieren.
Nein, man schreibt Programme ohnehin nur für KDE, Gnome _oder_ Plain-X. Für mehr reicht normalerweise die Entwicklerzeit einfach nicht aus.
[/QUOTE]Es geht hier nicht um die Wahl des verwendeten Toolskits (nehmen wir mal für unser Beispiel Qt), sonern um die Tatsache, daß eine Firma dafür sorgen muß,
das der Benuzter bei deren Programm auch dann die Hilfe benutzen kann,
wenn kein Konqueror installiert ist.Und das man MOMENTAN Programme nur für KDE oder Gnome oder Plain-X schreibt
liegt genau daran, daß man nicht jedes Desktopenvironment nach dem dort eingestellten Defaultbrowser abfragen will, das bedeutet nämlich Entwicklungsaufwand.Da ist es dann kein Wunder, wenn SW Firmen von Linux als Desktop OS abgeschreckt werden oder ihre Anwendungen nur ein Bruchteil von dessen können, was ihre Windows Pendants können.
Das stimmt so einfach nicht. Kann OpenOffice unter GNU/Linux weniger als unter Windows? Brauchst Du mehr Funktionalität unter k3b? Ist Dein Windows-XChat schöner als die GNU/Linux-Version?
Schau dir mal nvidia-settings an und vergleiche es mit dem Pendant von Windows.
Oder den Adobe Reader.
Oder wie wäre es mit Nero, davon soll es ja inzwischen auch eine Linux Version geben.Fakten nicht wahrhaben wollen und der Mangel an Selbstkritik ist leider
ein großes Problem im Linux Umfeld.
Ich benutze selber Linux, ich kenne Linux aber ich weiß auch wo die Schwächen
liegen und ich mache mir da durch ideologische Verblendung und ähnliches auch nichts vor.Du verwendest offensichtlich das falsche Betriebssystem. GNU/Linux ist nicht Windows. Wenn Du ein freies Windwos suchst, dann schau Dir ReactOS an.
Siehst du, das meinte ich mit ideologischer Verblendung.
Was nicht sein darf, das kann nicht sein.Bitte erläutere das genauer, am besten anhand eines kleinen Beispiels.
Was soll z.B. daran so falsch sein, wenn unser Simple-Programm nur 3 Key Value Paare in Elektra abspeichert und dazu Elektra nutzt?
Mein Simple-Programm ist ein kleines Shell-Script, das einfach nur eine ~/.kleinesshellscriptrc sourcen müsste, was hat denn da Elektra für Vorteile?
Du willst sourcen? Was soll das sein?
Was Eltra betrifft kannst du dir es z.B. mit Elektra sparen,
in deinem Script eine Textconfigdatei zu parsen, Elektra bietet
für so etwas schon das kbd Kommandozeilentool, das dir genau das liefert
was du haben willst.
Siehe die Doku zu kbd.Und das ist auch der Grund warum zur Zeit nur KDE mit KDE kann und Gnome nur mit Gnome. Der Defaultbrowser muß z.B. bei beiden Desktopenvironments nämlich separat eingestellt werden.
KDE und Gnome arbeiten derzeit gemeinsam, um sowas zu verbessern. Die Browsersache wäre übrigens ganz einfach, man müsste nur die $BROWSER-Umgebungsvariable beachten.
Das KDE und Gnome daran arbeiten weiß ich, aber es werden nur symptome zwischen den beiden Desktops behoben, man sollte das eine Ebene tiefer auf Systemebene angehen.
Selbst wenn Gnome KDE kann und KDE Gnome, was ist dann mit anderen Umgebungen oder Umgebungen die direkt nur auf X setzen?
Es soll auch GUI-lose Programme geben.
Womit dann erst recht so etwas wie Elektra sinnvoll ist, weil das
halt schon auf Systemebene wirkt.Das trifft nicht auf Elektra zu.
Elektrakonfigurationsdateien sind peer Hand mit jedem beliebigen Editor
bearbeitbar.
Schließich sind das nur Dateien mit Key = Wertepaaren + Kommentar.Oh, stimmt. Trotzdem kann man sowas nicht vernünftig mit den Unix-Texttools durchforsten, weil so viel Müll drinsteht.
Ich habe Elektra schon auf meinem Rechner installiert und
in den Konfigdateien steht keineswegs viel Müll drin.
Schau dir das mal an bevor du irgendwelche Behauptungen aufstellst die nicht einmal stimmen.
Überprüft hast du das nämlih definitiv nicht, das erkenne ich schon an deiner Behauptung. Man könnte das nicht einmal Halbwissen bezeichnen, sondern höchstens als dazugedichtetes etwas.Edikga ist Scriptingfähig.
Und Scripte die mit Werten umgehen gehören meiner Meinung nach nicht in eine Konfigurationsdatei sondern in einen separate Datei die die Daten aus einer Konfigdatei abrufen.Soll das jetzt eine Antwort auf meinen Text sein? Ich glaube, Du hast da einfach etwas missverstanden.
Ja, deine Befürchtung war nämlich das du mit Elektra nicht alles realisieren kannst was die Configdateien bieten.
Ich bin der Meinung, daß man jede Form von Konfiguration in Schlüssel-Werte Paare abbilden kann und was dann aus dem ganzen /etc/ Verzeichnis noch übrigbleibt, sind die Scriptanteile in einigen Configdateien.
Scripte kann man aber auslagern, womit damit nichts der Einführung von Elektra im Wege stehen sollte, das meinte ich damit.Das ist schwach. Debian hat dafür /etc/default, Gentoo /etc/conf.d, ... Das ist wesentlich sauberer.
Ich glaube nicht, das wir jetzt hier auch noch einen Flamewar über die Distributionen, Slackware vs. Debian vs. Gentoo anfangen sollten.
Das mit Slackware war nur ein Beispiel um zu zeigen wie das mit der Trennung
von Konfiguration und Script realisiert werden kann.Wie schon gesagt, man muß die libelektra.so ja nicht nehmen.
Man darf auch gerne sein eigenes Ding schreiben und die Konfigurationsdaten das Elektra Systems bearbeiten.Du hast die Aussage nicht verstanden. Es macht einfach keinen Sinn, dass Apache, Bind, xscreensaver und TuxRacer sich ein Konfigurationsschmea teilen.
Doch, weil wie schon gesagt zu Beginn oft nicht absehbar ist,
ob ein Programm Informationen aus Programm B gebrauchen könnte.
Tuxracer könnte z.B. als Voreinstellung die Auflösung des Desktops verwenden
ohne erst den User danach zu fragen. Und die Auflösung steht momentan in /etc/X11/xorg.conf, ein parser wäre fällig.
Um dem gleich vorwegzunehmen, bevor wir tuxracer gestartet haben, haben wir mit der Tastenkombination strg+alt++ die Auflösung geändert, die aktuelle Auflösung ist also nicht die Defaultauflösing.
Spaß muß sein.Auch wäre es mal schön, wenn man den Highscore ausdrucken könnte.
Man braucht also nen Printer.KDE will ein Setuptool für Apache und Bind liefern, gut das wir schon alles auf
Elektra umgestellt haben, und die bestehende Infrastruktur (libelektra.so) nutzen können um Apache und Bind mal schnell zu bearbeiten, ganz ohne neuem Parser.Das entscheidene ist also dieses "nicht absehbar" was man damit alles machen könnte, wenn so eine Infrastruktur ersteinmal liegt.
Das ist also wie in der Physik mit der Grundlagenforschung, da wird auch rumgemault das die nen Haufen Steuergelder verheizt obwohl noch gar nicht klar ist, was am Ende da raus kommt.
Wenn KMail, KWrite, Kopete und Co. das tun, dann ist das schön, immerhin gehören sie zu einem gemeinsamen Desktop Environment. Darüber hinaus ist das nicht erstrebenswert. (Und wenn ich die libeleketra.so nicht verwende, dann macht Elektra erst überhaupt keinen Sinn.)
Wie schon gesagt gibt es schon Versuche Apache, Bind, usw. aus der KDE Umgebung
zu konfigurieren. -> KControl-Center -> Systemverwaltung
Und gerade früher gab es zuhauf diese Versuche, bis man herausgefunden hat,
daß dies gar nicht so einfach unter den Hut zu bringen ist.
Deswegen gibt es zur Zeit nur dafür KDE Setup Tools was auch gut zu realisieren ist. Z.b. die Cups Konfiguration von KDE aus.unixy ist doch nur ein Vorwand nichts ändern zu wollen.
"Wenn es nichts bringt nichts ändern zu wollen." um genau zu sein.
Siehe oben, du kannst gar nicht absehen was es noch bringt.
Und das es etwas sehr wohl etwas bringt habe ich ja schon anhand von genug Beispielen gezeigt. Selbst Supertux hat das teilweise eingeräumt, wenn auch nur im Rahmen von Desktopenvironments.Wenn man sich für ein einigermaßen gängiges Config-File-Format entschieden hat, dann ist so eine Erweiterung aber völlig trivial.
Gerade eben versuchst du Elektra zu verhindern und eine andere Initiative ein gängies Config-File-Format einzuführen ist nicht in Sicht.
Und eines ist schon jetzt klar. XML wird das definitiv nicht sein.
-
nman schrieb:
Gasomat schrieb:
Das Ziel von GNU/Linux ist World Domination und dazu muß es auch den Desktop erreichen.
Brr, was für ein Riesen-Blödsinn.
Ich habe lediglich Linus Torvalds zitiert.
Wie gesagt, das ist nur eine Desktop Env. Sache, keine OS Sache.
Ja, wir drehen uns im Kreis.
Ich sehe diesen Punkt nämlich anders als du.Tja, leider hat er Recht und Du nicht.
Nein, ihr seid nur lediglich beide der selben Meinung.
Mac OS X User lieben so ein Feature und die sind ein paar Millionen mehr User als ihr beiden Einzelpersonen.
Autsch. Hierfür bekommst Du die goldene DAU-Nadel ausgehändigt. Hast Du schon mal was von Cups gehört? Von LPR? Von irgendwas was sich Drucksystem-mäßig in den letzten dreißig Jahren auf Unix-Systemen so getan hat?
Ich kenne Cups, aber du kennst ncurses Anwendungen nicht.
Also warum sollte man eine gemeinsame Konfig Platform für DesktopEnv. schaffen, wenn man auch eine Ebene tiefer gehen könnte.
Weil die Ebene darunter möglichst unangetastet bleiben soll und es keinen Vorteil bringt, diese auch noch miteinzubeziehen.
Wenn du aber nicht eine Ebene weitere teifer gehen willst, dann müssen Konfigurationsprogramme für KDE oder Gnome halt wieder doch
die Konfigurationseigenheiten von Samba, Apache, Bind und Co kennenlernen.Das selbe gilt natürlich auch für ncurses basierte Konsolensetupanwendungen.
Der Hauptgrund ist der, daß die Guis meist nicht das machen was man will.
Und die Ursache ist die, das Gui Setup Programme ziemliche Schwierigkeiten mit
den derzeitigen Konfigurationsdateien haben.So ein Schwachsinn. GUI-Konfigurationstools müssen entweder genau gleich aussehen wie Configdateien,
Der Schwachsinn kommt eher von dir.
Warum sollte eine GUI wie /etc/inittab in Textform aussehen?oder zusätzliche Abstraktionsebenen einführen.
Aha und mehr Code macht das Programm natürlich gleich wieder stabiler
und zuverlässiger.Du hast definitiv nicht den Vorteil von GUI+Elektra verstanden.
Ganz davon zu schweigen das du Yast nicht kennst.Und sobald diese da sind, hat man keine 100%ige Kontrolle mehr über die Konfiguration.
Wenn man die Syntax einer Konfiguration in definierte Schranken weißt, (mit Elektra geht das) dann löst sich das Problem von ganz alleine.
-
Das Posting weiter oben "Elektra" ist von mir.
Da vergißt man der hitzigen Diskussion den eigene Namen.
-
Da man den DefaultBrowser aber selber festlegt, kann man davon ausgehen,
daß man das will.
Es wird erst dann gefragt, wenn noch kein DefaultBrowser festgelegt wurde.Nochmal, das hat aber nur etwas mit einem Desktop Environment zu tun, nicht mit dem OS an sich, verwechsle beide Sachen nicht: Desktop != OS
Jetzt sag bloß, daß du bei der Gnome Hilfe "Konqueror", bei Kedit "Opera"
und bei Konqueror "Firefox" geöffnet haben willst.
Das glaube ich dir nämlich nicht.dann bist du blind oder du kannst nicht lesen: Ich hab weder gnome noch kde --> ich benutze kein kedit noch konqueror.
Wenn du diese Abfragefunktion in ein Programm einbaust,
dann muß sie nicht nur eine Environmentvariable abfragen können,
sondern auch noch die eigene Konfigurationsdaten lesen können. ??? hast du eine Ahnung, was getenv macht? Die Environmentvariablen sind genau dafür da. Einfach eine BROWSER Variable in /etc/profile setzen und fertig, dann kann jedes Programm mittels getenv an die Informatin kommen und da braucht man sowas wie Elektra oder überhaupt Config Dateien nicht. 
Willst du nicht, kannst du nicht, andere wollens, andere könnens.
Ich will nicht, kann mir auch nicht vorstellen, dass es lila Kühe gibt, die fliegen. Andere wollen, andere können, aber Fakt ist, es gibt keine lila Kühe, die fliegen
Womit dann der Beweis erbracht wurde, das das noch viel komplexer wird, wenn jetzt auch noch /usr/share/appname & Co abgefragt werden können soll.
was hat das mit Elektra zu tun? Seit wann befindet sich Konfiguration in /usr/share?
Aha, und wenn du in eines deiner gestarteten Programme auf Hilfe klickst,
öffnet sich die Konsole in der du dann den zu startenden Browser eingeben kannst.Hää? was für Programme nutzt du denn? Also, ich keine Programme, die sowas machen. Außerdem ziehe ich 90% der Hilfe von google oder man pages.
Das Ziel von GNU/Linux ist World Domination und dazu muß es auch den Desktop erreichen.
Tut mir leid für meine Worte, aber das ist das größte Schwachsinn, was ich in diesem Thread gelesen habe:
http://www.felix-schwarz.name/files/opensource/articles/Linux_ist_nicht_Windows/
dieses Artikel ist ziemlich gut (hat vielleicht paar kleine Fehler), unbedingt lesen.Nun, z.b. möchtest du eine KDE Anwendung verwenden, hast jetzt aber kein KControl-Center installiert, willst das auch nicht installieren da es ja Platz braucht, tja und jetzt möchtest du die Schriftart in dieser KDE Anwendung verändern.
Sowas habe ich: kein kde aber k3b. Und das Problem mit den Fonts kann ich mit einem QT Theme lösen.
Ich wette du bist in einem von dir bekannten und regelmäßig benutzen Elektra
Konfigurationsbaum schneller am Ziel, als wenn du erst die Konfigurationsdateien und deren Syntax von KDE Konfigurationen kennenlernst.Sicher, aber das ist wieder nur ein Argument für den Einsatz von Elektra mit Desktop Environments, keins für den globalen Einsatz von Elektra für das gesamte System. Das willst du irgendwie nicht verstehen.
Ok, jetzt kommen wir einen Schritt weiter.
Aber jetzt gibt es auch Dinge die nicht in erster Linie nur von Desktopumgebungen betroffen sind sondern auch gut von der Konsole aus brauchbar wären.
Z.B. den DefaultprinterStichwörter: cups, lpr, lprng ...
Weil du z.b. ein Setuptool hast, mit dem man Apache und noch zig andere Programme, Dienste, Server etc. konfigurieren kann,
was genua verstehst du unter Setup Tool? Sowas wie bei Windows? Wenn du drauf nicht verzichten kannst, dann nutze Windows, denn sowas wird sicherlich nie unter GNU/Linux geben (im allgemeinen meine ich). Ansonsten, was ist denn schwer an `make install`?
Das Samba Team hat ürbigens an Elektra schon interesse gezeigt, siehe die Newspage auf der Elektra Homepage.
http://www.libelektra.org/News#04.2F24.2F06_-_Samba.2C_Google.27s_Summer_of_CodeIch denke, für ein System wie Samba würde durchaus Sinn machen, aber da steht nicht, dass sie komplett umsteigen, sondern als "Alternative configuration backends"
Für den Normal Dau wird es einfacher werden ein Linux System zu installieren, konfigurieren und zu benutzen, da es einfacher wird GUI Setup Programme
Ich würde es lieber haben, wenn normale Daus bei Windows bleiben
Wir beide wissen wie fehlerträchtig Yast manchmal sein kann und
warum die meisten Linux Gurus immer noch über nen Editor und ne Konsole
konfigurieren.ja, weil es deutlich schneller, verständlicher und angenehmer ist, eine kleiner Änderung an der Config Datei zu machen, als Hand von der Tatstur wegnehmen, Maus in die Hand nehmen, Mauszeiger platzieren, Doppelklick machen, warten bis der KDE Gedöns startet, root Passwort eingeben, 300 Klicks betätigen, bis man die richtige Stelle hat, wieder Hand von der Maus entfernen und ab in die Tatstatur, eintippen, wieder Hand an die Maus, auf Fertig klicken ....... ufff... das ist umständlich. Ich mache meisten: sudo vim /etc/... irgendwas <esc>:wq --> fertig
Ich kann mich nur an nmans Worte anschließen: "Du verwendest offensichtlich das falsche Betriebssystem. GNU/Linux ist nicht Windows. Wenn Du ein freies Windwos suchst, dann schau Dir ReactOS an."
-
Ich habe lediglich Linus Torvalds zitiert.
Linus ist nur Kernel Entwickler und er redet auch viel Mühl, wenn er Zeit hat.
Nein, ihr seid nur lediglich beide der selben Meinung.
Mac OS X User lieben so ein Feature und die sind ein paar Millionen mehr User als ihr beiden Einzelpersonen.
ich kenne Mac OS X nicht, weil es nicht habe. Aber ich hab gesehen, wie andere Kolegen von mir damit arbeiten, und diese tolle Features sind nur Desktop bezogene Features. Wenn ich mit einem xterm arbeite, was nutzt mir die Information eines "DefaultBrowsers"?
aber du kennst ncurses Anwendungen nicht.
doch, hab selber welche geschrieben (nur testweise um ncureses zu lernen)
Der Schwachsinn kommt eher von dir.
Warum sollte eine GUI wie /etc/inittab in Textform aussehen?weil /etc/inittab die Konfigurationsdatei von sysv-init ist, und wenn sysv-init läuft, läuft kein X Server, demnach macht eine GUI Form der inittab keinen Sinn.
Wenn du aber nicht eine Ebene weitere teifer gehen willst, dann müssen Konfigurationsprogramme für KDE oder Gnome halt wieder doch
die Konfigurationseigenheiten von Samba, Apache, Bind und Co kennenlernen.die folgende Frage habe ich mind. 3 Mal gestellt und bis jetzt nicht beantwortet: Welchen Vorteil habe ich als KDE/GNOME User, dass KDE an die Apache Konfiguration mittels Elektra rankommt und umgekehrt? Welche Sinn hat es, System Konfiguration mit Desktop Konfiguration kompatibel zu machen, wenn weder Dienste noch Desktop davon profitieren?
-
supertux schrieb:
Wenn du diese Abfragefunktion in ein Programm einbaust,
dann muß sie nicht nur eine Environmentvariable abfragen können,
sondern auch noch die eigene Konfigurationsdaten lesen können. ??? hast du eine Ahnung, was getenv macht? Die Environmentvariablen sind genau dafür da. Einfach eine BROWSER Variable in /etc/profile setzen und fertig, dann kann jedes Programm mittels getenv an die Informatin kommen und da braucht man sowas wie Elektra oder überhaupt Config Dateien nicht. Und getenv kannst du auch für Crossplattform fähige Anwendungen ohne ifdev(Windows) etc. verwnden?
Elektra wird's nebenbei auch für Windows, MacOS X, FreeBSD etc. geben.
Womit dann der Beweis erbracht wurde, das das noch viel komplexer wird, wenn jetzt auch noch /usr/share/appname & Co abgefragt werden können soll.
was hat das mit Elektra zu tun?
Bei Elektra hast du alles unter einem Baum.
Die Konfiguraton User ist ein link von /etc/kbd/user/xy nach /home/xy/.kbd/Seit wann befindet sich Konfiguration in /usr/share?
War ein Fehler von mir, meinte natürlich /usr/etc/ oder /usr/local/etc bzw.
die Punktdateien im Homedirectory der Benutzer.Nun, z.b. möchtest du eine KDE Anwendung verwenden, hast jetzt aber kein KControl-Center installiert, willst das auch nicht installieren da es ja Platz braucht, tja und jetzt möchtest du die Schriftart in dieser KDE Anwendung verändern.
Sowas habe ich: kein kde aber k3b. Und das Problem mit den Fonts kann ich mit einem QT Theme lösen.
Schön, das Problem mit dem Browser bleibt, wenn du in k3b auf Hilfe klickst.
Ich wette du bist in einem von dir bekannten und regelmäßig benutzen Elektra
Konfigurationsbaum schneller am Ziel, als wenn du erst die Konfigurationsdateien und deren Syntax von KDE Konfigurationen kennenlernst.Sicher, aber das ist wieder nur ein Argument für den Einsatz von Elektra mit Desktop Environments, keins für den globalen Einsatz von Elektra für das gesamte System. Das willst du irgendwie nicht verstehen.
Und du willst nicht verstehen, das es Anwendungsfälle geben kann, bei denen
so ein einheitliches Konfigsystem auch von nicht Desktop Env. Anwendungen brauchbar sein kann,Weil du z.b. ein Setuptool hast, mit dem man Apache und noch zig andere Programme, Dienste, Server etc. konfigurieren kann,
was genua verstehst du unter Setup Tool?
Ein Progamm mit dem ich Einstellungen vornehmen kann.
Ich verstehe unter reinem Setup Tool keineswegs einen Installer,
wie man es von der Windows Welt her kennt.
Für mich sind Installer Installer und keine Setup Tools, auch wenn
es in der Windows Welt üblich ist einen Installer z.B. Setup.exe zu nennen.Das Samba Team hat ürbigens an Elektra schon interesse gezeigt, siehe die Newspage auf der Elektra Homepage.
http://www.libelektra.org/News#04.2F24.2F06_-_Samba.2C_Google.27s_Summer_of_CodeIch denke, für ein System wie Samba würde durchaus Sinn machen, aber da steht nicht, dass sie komplett umsteigen, sondern als "Alternative configuration backends"
Jetzt auf einmal haben wir also doch etwas, das ausserhalb von Desktop Env. stattfindet.
Das die nicht komplett umsteigen ist wieder ein anderes Thema.
Vielleicht will man das erst testen, und wenn es sich bewährt dann baut
man das alte Zeugs raus oder deaktiviert es standardmäßig.
Der, der das dann immer noch haben will macht dann ein ./configure --with-old-configFür den Normal Dau wird es einfacher werden ein Linux System zu installieren, konfigurieren und zu benutzen, da es einfacher wird GUI Setup Programme
Ich würde es lieber haben, wenn normale Daus bei Windows bleiben
Ich nicht, denn die breite kaufkräftige Masse besteht nunmal aus Daus.
Und ich hätte gerne mehr kommerzielle SW Produkte für Linux,
insbesondere Lernprogramme für Kinder, Multimediaanwendungen über Thema XY (Raumfahrt, Grand Canyon, Die Medizin des Menschen etc.) sowie natürlich kommerzielle professionelle Computerspiele für dem PC.
Letzteres ist ein Hauptgrund warum ich immer noch Windows nebenbei installiert haben muß.Sollte es also mit einem einfacher zu benutzenden Linux System möglich sein,
den Marktanteil von einem Linux System zu steigern, dann
wird es dafür auch eine größere Vielfalt an SW geben.Wir beide wissen wie fehlerträchtig Yast manchmal sein kann und
warum die meisten Linux Gurus immer noch über nen Editor und ne Konsole
konfigurieren.ja, weil es deutlich schneller, verständlicher und angenehmer ist,
Also schneller ist es sicherlich nicht.
Ein häckchen setzte ich in einer GUI nämlich schneller
als einen "true" Wert nach xy = an Zeile 134 in einer Konfigurationsdatei zu schreiben.Ganz zu schweigen davon, daß ich nicht erst in den Man Pages nachlesen möchte,
welche Optionen ich überhaupt setzen kann.
In der Gui sind die mögliche Konfigurationen intuitiv ersichtlich.Zum Thema Verständnis.
Während du dich bei einem neuen Programm erstmal in die Man Pages einlernen muß,
führt mich ein grafische Wizard mit ausführlicher Hilfsanleitung an die Konfiguration heran.
Bis du dein Programm nach dem Man Pages lesen konfiguriert hast, benutze ich das Programm schon lange.Und angemehm ist die Bedienung mit der Maus durchaus.
eine kleiner Änderung an der Config Datei zu machen, als Hand von der Tatstur wegnehmen, Maus in die Hand nehmen, Mauszeiger platzieren, Doppelklick machen, warten bis der KDE Gedöns startet,
Ich dachte du bentuzt Fluxbox?
root Passwort eingeben, 300 Klicks betätigen, bis man die richtige Stelle hat, wieder Hand von der Maus entfernen und ab in die Tatstatur, eintippen, wieder Hand an die Maus, auf Fertig klicken ....... ufff... das ist umständlich.
Gnome 2.x finde ich mehr streamlined als KDE. Aber ich will ja jetzt keinen
Gnome vs. KDE Flamewar vom Zaun brechen.Ich mache meisten: sudo vim /etc/... irgendwas <esc>:wq --> fertig
Ne, ne, erstmal mußt du die Manpage lesen.
Schließlich reden wir über ein neues Programm.Ich kann mich nur an nmans Worte anschließen: "Du verwendest offensichtlich das falsche Betriebssystem. GNU/Linux ist nicht Windows. Wenn Du ein freies Windwos suchst, dann schau Dir ReactOS an."
Ich will aber kein freies Windows, ich will ein freies Linux mit
einem guten Konfigurationssystem.
-
Und getenv kannst du auch für Crossplattform fähige Anwendungen ohne ifdev(Windows) etc. verwnden?
ja, getenv/setenv ist auch unter Windows vorhanden (und unter alle POSIX Systeme sowieso)
Schön, das Problem mit dem Browser bleibt, wenn du in k3b auf Hilfe klickst.
nie gehabt, weil ich nämlich nie drauf klicken musste
Und du willst nicht verstehen, das es Anwendungsfälle geben kann, bei denen
so ein einheitliches Konfigsystem auch von nicht Desktop Env. Anwendungen brauchbar sein kann,zum Beispiel? Wenn du Samba sagst, dann habe ich durchaus gesagt. Ich hab aber viel zu wenig mit Samba gearbeitet, um wirklich viel zu wissen, was man alles mit Samba tun kann.
Ich nicht, denn die breite kaufkräftige Masse besteht nunmal aus Daus.
Und ich hätte gerne mehr kommerzielle SW Produkte für Linux,Ich werde drauf nicht mehr eingehen, sonst wird sich dieser Thread noch mehr in einen Flameware dau vs veterans ausarten, und das möchte ich nicht. Ich persönlich will keine DAUs, die sollen ruhig unter Windows bleiben und dafür Sorgen, dass die Hacker sich auf Windows spezializieren und Windows Schwachstellen ausnutzen.
Wir haben einfach verschiedene Ansichten, in welche Richtung GNU/Linux sich entwicklen soll und deswegen werden wir uns nicht gegenseitig überzuegen können.
Ganz zu schweigen davon, daß ich nicht erst in den Man Pages nachlesen möchte,
welche Optionen ich überhaupt setzen kann.
In der Gui sind die mögliche Konfigurationen intuitiv ersichtlich.Ich sehe als Vorrausetzung für die Benutzung eines Unix System, dass man weiß, wie man man-pages benutzt.
Ich dachte du bentuzt Fluxbox?
tue ich auch, aber das heißt nicht, dass ich die Maus benutze. Ich benutze Fluxbox, weil es sich so konfigurieren lässt, dass ich ohne Maus klar komme. Maus benutze ich nur, wenn ich mit Opera surfe oder k3b nutze.
Ne, ne, erstmal mußt du die Manpage lesen.
Schließlich reden wir über ein neues Programm.kostet mich vielleicht 10 Minuten meines Lebens, aber dann komme ich überall klar.
Ich will aber kein freies Windows, ich will ein freies Linux mit
einem guten Konfigurationssystem.GNU/Linux ist bereits frei, was du willst ist eine bessere Konfiguration Möglichkeit zwischen verschiedenen Desktop Environments, um an DAUS zu vermarkten, und das ist was anders. Und da wir ganz anderer Meinung sind, wie ein GNU/Linux funktionieren soll, denke ich, dass es keinen Sinn mehr macht, weiter darüber zu diskutieren, denn wir drehen uns offensichtlich nur im Kreis und kommt dabei nichts vernünftiges raus.
Gruss
Pablo
-
supertux schrieb:
Der Schwachsinn kommt eher von dir.
Warum sollte eine GUI wie /etc/inittab in Textform aussehen?weil /etc/inittab die Konfigurationsdatei von sysv-init ist, und wenn sysv-init läuft, läuft kein X Server, demnach macht eine GUI Form der inittab keinen Sinn.
In welchen Fällen könnte ein Anwender die /etc/inittab konfigurieren?
Könnte es auch sein, daß er die unter KDE mit einem Editor öffnet?
Antwort ist definitiv zu bejahen.Mir ist also schleierhaft was du mit einer GUI die wie inittab in Textform aussehen soll, bezwecken willst.
Wenn du aber nicht eine Ebene weitere teifer gehen willst, dann müssen Konfigurationsprogramme für KDE oder Gnome halt wieder doch
die Konfigurationseigenheiten von Samba, Apache, Bind und Co kennenlernen.die folgende Frage habe ich mind. 3 Mal gestellt und bis jetzt nicht beantwortet: Welchen Vorteil habe ich als KDE/GNOME User, dass KDE an die Apache Konfiguration mittels Elektra rankommt und umgekehrt?
Weil es nunmal Benutzer gibt, die Apache nicht mit einem Texteditor sondern
mit eine GUI Anwendung konfigurieren wollen.So, kdelib (oder was weiß ich) bietet jetzt Funktionen um KDE Configdateien zu berarbeiten. Kannst du also mit kdelib (oder der KDE lib, die dafür zuständig ist) die Apache Konfiguration bearbeiten?
Nein.
Und warum kannst du das nicht?
Weil Apache ein eigenes Format für die Konfiguration hat.Könnte man das aber machen, wenn man Apache das Konfigformat von KDE beibringt?
Ja.
Und warum macht man das nicht?
Weil in diesem Fall eine Lösung, die auch für andere Umgebungen Systemweit funktioniert besser wäre.
Und schon bist du bei Elektra.Jetzt kapiert?
Beantwortet habe ich genau das übrigens schon mehrmals in diesem Thread, nur hast du es nicht erkannt.Und um gleich noch einen Aufzusetzen.
Und warum bringt man dann nicht der KDE Konfiganwendung die Apache konfigurieren soll, die Konfig von Apache bei?
Das macht man, ist aber nicht so elegant, weil man so etwas auch für
andere Desktops gut gebrauchen könnte, eine generelle Lösung wäre also besser.Welche Sinn hat es, System Konfiguration mit Desktop Konfiguration kompatibel zu machen, wenn weder Dienste noch Desktop davon profitieren?
Siehe oben.
Der Benutzer profitiert davon, wenn er Apache per GUI konfigurieren kann.
-
supertux schrieb:
Und getenv kannst du auch für Crossplattform fähige Anwendungen ohne ifdev(Windows) etc. verwnden?
ja, getenv/setenv ist auch unter Windows vorhanden (und unter alle POSIX Systeme sowieso)
Und jetzt willst du für alles, wo eine Konfiguration von dem diesem etwas aus mehreren Anwendungen sinnvoll erscheint, eine Environment Variable erstellen?
Schön, das Problem mit dem Browser bleibt, wenn du in k3b auf Hilfe klickst.
nie gehabt, weil ich nämlich nie drauf klicken musste
Ausrede.
Und schon sind wir bei dieser ideologischen Verblendung, du
leugnest das dies für andere Benutzer ein Problem darstellen könnte,
in dem du als Begründung anführts, das du da nie draufklickst.Echt toll! Wirklich klasse! Wenn ich ne Firma hätte und du als Angestellter in meiner Firma Software entwickeln würdest, dann würde ich dir so einen Bug um die Ohren hauen.
Klick mal drauf.
Und du willst nicht verstehen, das es Anwendungsfälle geben kann, bei denen
so ein einheitliches Konfigsystem auch von nicht Desktop Env. Anwendungen brauchbar sein kann,zum Beispiel? Wenn du Samba sagst, dann habe ich durchaus gesagt. Ich hab aber viel zu wenig mit Samba gearbeitet, um wirklich viel zu wissen, was man alles mit Samba tun kann.
Wie ich schon sagte, man könnte so ziemlich alles
über so ein einheitliches Konfigurationssystem konfigurieren.
Auch Cups, obwohl es für Cups schon recht gute GUI Lösungen für, zumindest KDE, gibt.Ich würde daher mal sagen, das macht für nahezu jeden Systemdienst Sinn, ihn mit einer GUI konfigurieren zu können.
Ich nicht, denn die breite kaufkräftige Masse besteht nunmal aus Daus.
Und ich hätte gerne mehr kommerzielle SW Produkte für Linux,Ich werde drauf nicht mehr eingehen, sonst wird sich dieser Thread noch mehr in einen Flameware dau vs veterans ausarten, und das möchte ich nicht. Ich persönlich will keine DAUs, die sollen ruhig unter Windows bleiben und dafür Sorgen, dass die Hacker sich auf Windows spezializieren und Windows Schwachstellen ausnutzen.
Ok.
Was Hacker, Viren, Würmer und Co betrifft.
Mein Vertrauen in Linux, dessen Sicherheitsmechanismen und der OSS Community ist groß genug, daß die es mit dieser Sorte von Gefahr aufnehmen könnte.Wir haben einfach verschiedene Ansichten, in welche Richtung GNU/Linux sich entwicklen soll und deswegen werden wir uns nicht gegenseitig überzuegen können.
Einverstanden.
Ganz zu schweigen davon, daß ich nicht erst in den Man Pages nachlesen möchte,
welche Optionen ich überhaupt setzen kann.
In der Gui sind die mögliche Konfigurationen intuitiv ersichtlich.Ich sehe als Vorrausetzung für die Benutzung eines Unix System, dass man weiß, wie man man-pages benutzt.
Das mit der verschiedenen Ansichten scheint wohl zu stimmen.
Ich bin der Meinung das sich auch Unix weiterentwickeln kann
und das lesen von man pages nicht immer zwingend erforderlich sein muß,
sofern man die entsprechenden GUI Alternativen zur Verfügung stellt.[QUOTE]
Ich dachte du bentuzt Fluxbox?
tue ich auch, aber das heißt nicht, dass ich die Maus benutze. Ich benutze Fluxbox, weil es sich so konfigurieren lässt, dass ich ohne Maus klar komme. Maus benutze ich nur, wenn ich mit Opera surfe oder k3b nutze.
[/QUOTE}
Ok.Ne, ne, erstmal mußt du die Manpage lesen.
Schließlich reden wir über ein neues Programm.kostet mich vielleicht 10 Minuten meines Lebens, aber dann komme ich überall klar.
D.h. für jedes neue Progamm erstmal 10 Minuten verschwenden.
Macht bei 10 Programmen also 100 Minuten.
Ich brauch mit nem Wizard mal sehr vorsichtig geschätzt nur 1-2 Minuten.
Bei 10 Programmen also 10-20 Minuten.Ich will aber kein freies Windows, ich will ein freies Linux mit
einem guten Konfigurationssystem.GNU/Linux ist bereits frei, was du willst ist eine bessere Konfiguration Möglichkeit zwischen verschiedenen Desktop Environments, um an DAUS zu vermarkten, und das ist was anders.
Dieses und zwischen "freies Linux" und "mit einem guten Konfigurationssystem" diente nur der Beschreibung als ganzes.
Und da wir ganz anderer Meinung sind, wie ein GNU/Linux funktionieren soll, denke ich, dass es keinen Sinn mehr macht, weiter darüber zu diskutieren, denn wir drehen uns offensichtlich nur im Kreis und kommt dabei nichts vernünftiges raus.
Gruss
PabloOk, bis Elektra 1.0 draußen ist und man ein Live System mit funktionierenden Backends ausprobieren kann dauert es ja noch ein paar Monate.
Dann könntest du es dir ja mal in der Praxis anschauen wenn du möchtest.Gruss
Gasomat