Wie findet ihr eine gemeinsame Registry wie Elektra?

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
Pablo

Ok, 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

supertux

gasomat schrieb:

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.

*lol* an dieser Stelle wusste ich nicht, ob ich lachen oder weinen soll. Tut mir leid, aber das ist alles Unsinn. KDE hat nichts mit Apache zu tun und umgekehrt auch nicht. Auch ist es nicht vorausgesetzt, dass Apache und KDe zusammen sein müssen. Auf einem DAU Desktop wird mit großer Wahrscheinlichkeit kein Apche vorhanden sein, wozu soll denn KDE Apaches Konfig. lesen sollen?

Außerdem, Apache ist kein Spiel, sondern ein mächtiges Tool, das man richtig konfigurieren muss und nicht so einfach intutiv per Maus Klick konfigurieren soll. Ein falsch konfigurierter Apache ist eine offene Tür ins System. D.h. jemand, der Apache konfiguriert, sollte sich zuerst informieren, wie man Apache richtig konfiguriert, und jemand, der das getan hat, hat kein Problem eine Text Datei zu editieren. Außerdem erwarte ich, dass mindestens ein Sysadmin Apache konfiguriert oder ein User, der sich informiert hat.

Und jetzt willst du für alles, wo eine Konfiguration von dem diesem etwas aus mehreren Anwendungen sinnvoll erscheint, eine Environment Variable erstellen?

Mir ist das alles egal, du bist der jenige, der alles in einer einzelne Instanz haben will. Und wenn du VAR=VALUE Configs haben willst, dann ist das eine schnelle Lösung und man braucht keine zusätzliche Bibliothek.

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.

Klar Ausrede, deswegen ja mein Smily. Aber es hat mich interessiert, was passiert, wenn ich auf Help klicke, also habe ich mein k3b gestartet und selber ausprobiert:

"Could not launch the KDE Help Center"

Naja, es war zu erwarten, da ich kein KDE habe, das bedeutet, dass KDE ein eigenes Help System hat und das hat mit einer Konfiguration nichts zu tun. Selbst Microsoft hat verschiedene Help Systeme, die nicht ganz miteinander kompatibel sind, und nicht mal die Registry kann das lösen.

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.

Kann sein, aber ohne GUI bist du [1] verloren, während ich mit und ohne GUI ein System konfigurieren kann. Das ist der Unterschied.

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

werde ich nicht, denn ich sehe keine Zukunft für dieses Projekt und halte die Idee, dass jeder die Konfig von jedem "beherrscht" für Unsinn.

Und es gibt bereits Distris, die in diese Richtung gehen, siehe Mandriva, Linspire, usw.

Gruss
Pablo

[1] damit meine nicht unbedingt dich, sondern Leute, die nur über GUI etwas "intuitiv" konfigurieren, ohne zu verstehen, was sie tun

nman

Elektra schrieb:

Ich habe lediglich Linus Torvalds zitiert.

Den darfst Du aber nicht so wörtlich nehmen.

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 _bin_ MacOS-User. Und da ist das auch nicht in Darwin enthalten, was dort das Gegenstück zu GNU/Linux ist.

Ich kenne Cups, aber du kennst ncurses Anwendungen nicht.

Du redest Blödsinn. Natürlich kenne ich ncurses, aber ich brauche keinen ncurses-Elektra-Schmonz um meinen Default-Drucker einzustellen, das geht seit ein paar Jahrzehnten wesentlich eleganter.

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.

Samba, Apache, Bind und Co haben mit KDE oder Gnome aber leider überhaupt nichts zu tun. Wäre auch nicht sinnvoll.

Der Schwachsinn kommt eher von dir.
Warum sollte eine GUI wie /etc/inittab in Textform aussehen?

Nicht in Textform. Aber eben zb so wie eine inittab in Elektra-Form. Und die ist für einen Dau nicht verständlicher als eine /etc/inittab und für einen technisch versierten User nicht praktischer als eine echte inittab.

Aha und mehr Code macht das Programm natürlich gleich wieder stabiler
und zuverlässiger.

Hä? Was hat denn mehr Code mit Abstraktion zu tun?

Konfigurationstools wie YaST sind deswegen beliebt, weil sie zusätzliche Abstraktionsebenen einführen. Der User kann aufgabenorientiert arbeiten und darf dafür die Implementierung vernachlässigen. Das kann ein Vorteil, aber auch ein Nachteil sein, je nach Anwendungszweck.

Du hast definitiv nicht den Vorteil von GUI+Elektra verstanden.

Stimmt. Und Du bis jetzt keine einzige meiner Aussagen.

Ganz davon zu schweigen das du Yast nicht kennst.

Habe jahrelang damit gearbeitet, von SuSE 5.2 bis 7.1. (Oder doch 7.3? Keine Ahnung mehr.

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.

Wie gesagt, Elektra-Konfigurationen sind für technisch nicht versierte User auch nicht verständlicher als rohe Config-Dateien. YaST oä hingegen schon, das ist ein völlig anderes Anwendungsgebiet.

Die nicht 100%ige Kontrolle bezog sich auch auf derartige Tools, die einfach andere Vor- und Nachteile als rohe Configdateien haben.

nman

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.

Oh Mist, ein guter Abschluss und ich habe ihn verpasst.

Schankedön, ich mach hier mal dicht, weitere Diskussionen führen wohl tatsächlich aufgrund sehr unterschiedlicher Ansichten zu sehr wenig bis nichts.