etc
etc
Hi
Gibt es eigentlich in Debian oder in der Linuxgemeinde allgemein eine Bestrebung die Konfigurationsdateien zu standardisieren?
Bei dem Durcheinander unter /etc kommen Anfänger doch nie auf einen grünen Zweig.
Es gibt zig Konfigurationstools die alle ein bischen was können. Aber keines, mit dem man alle Programme auf dem Rechner verwalten kann.
Warum einigt man sich nicht auf einen Standard wie XML. Dann währe auch ein (z.B. grafisches) Allroundtool möglich.
Gibt es eigentlich in Debian oder in der Linuxgemeinde allgemein eine Bestrebung die Konfigurationsdateien zu standardisieren?
Bei dem Durcheinander unter /etc kommen Anfänger doch nie auf einen grünen Zweig.
Es gibt zig Konfigurationstools die alle ein bischen was können. Aber keines, mit dem man alle Programme auf dem Rechner verwalten kann.
Warum einigt man sich nicht auf einen Standard wie XML. Dann währe auch ein (z.B. grafisches) Allroundtool möglich.
Doch, das gibt es. Es nennt sich vi, scnr. Aber ernsthaft, worin unterscheidet es sich, ob ich in einem GTK2-GUI ein paar Häkchen mit der Maus sezte, oder ob ich das in einem Editor direkt in der entsprechenden Datei mache?Es gibt zig Konfigurationstools die alle ein bischen was können. Aber keines, mit dem man alle Programme auf dem Rechner verwalten kann.
Denk dran, dass die meisten Dateien unter /etc zu irgendwelchen installierten Programmen gehören, und diese das Format und die Optionen vorgeben, nicht die Distribution. XML könnte man als Basis für einen Standard nehmen, aber bist du schonmal XML-Dateien per Hand durchgegangen? Ich finde das ermüdend, eine herkömmliche, gut dokumentierte *.conf ist mir da allemal lieber. Zumal XML ja auch nur das Format definiert, nicht den Inhalt. Am Ende hätte man nur wieder zig verschiedene Dateien, für die es jeweils wieder ein abgestimmtes Konfigurationstool bräuchte (wenn man denn eines benötigt).
Auch aus einem anderen Grund ist ein solches Vorhaben imho Unsinn: Wozu benötigt man ein Tool, mit dem man einen httpd und z.B. xmms gleichermaßen konfigurieren kann? Wer schreibt ein Tool, welches auf die weit über 10.000 einzelnen Programme und deren spezifische Optionen abgestimmt ist, und wer hält es aktuell?
cu
niemand
Ich muss mich da meinen Vorrednern anschließen.
Und es fällt imho nur denen schwer damit zurecht zu kommen, die aus irgendeinem Grund die falsche Herangehensweise an den Tag legen.
Unter Debian z.b. kann ich einfach mit die config files zu einem Bestimmten paket finden.
Mit finde ich config files und Umgebungsvariablen die für ein bestimmes Programm relevant sind.
Mit bekomme ich für viele config files eine Dokumentation was in der Datei wie zu tun ist (bis auf wenige Exoten auch relativ einheitlich was das Format angeht soweit zweckmäßig (Option=Wert)
Das einzige was evtl etwas schwierig am Anfang, aber vielleicht um so angenehmer spät ist, sind gesplittete config files die nach dem Ändern per Skript gemerged werden (wie z.B. bei exim oder modconf) oder die init.d/rcX.d ähnlichen config.dirs in denen die configs nach Benennung abgearbeitet werden. Aber auch hierzu stehen in den meisten Fällen ein paar brauchbare Hinweise entweder unter oder in den configfiles selbst.
Und im Notfall (sollte nicht sein, aber Ausnahmen gibt es leider immer mal):
Nicht verzagen, Google fragen
Auch jede andere Distib hat diese oder andere Möglichkeiten der Sache Herr zu werden (Natürlich niemals so gute wie bei Debian
)
Und wer sich damit absolut nicht anfreunden kann oder will, der sollte entweder ein anderes OS als GNU/Linux wählen oder eine Distibution mit hübsch buntem Configtool das zumindest alle für einen solchen User erforderlichen Einstellungen für ihn vornehmen kann.
Gruß
Stephan
Und es fällt imho nur denen schwer damit zurecht zu kommen, die aus irgendeinem Grund die falsche Herangehensweise an den Tag legen.
Unter Debian z.b. kann ich einfach mit
Code: Alles auswählen
dpkg-query -L $paketname | grep /etc
Mit
Code: Alles auswählen
man $programm
Mit
Code: Alles auswählen
man $configfilename
Das einzige was evtl etwas schwierig am Anfang, aber vielleicht um so angenehmer spät ist, sind gesplittete config files die nach dem Ändern per Skript gemerged werden (wie z.B. bei exim oder modconf) oder die init.d/rcX.d ähnlichen config.dirs in denen die configs nach Benennung abgearbeitet werden. Aber auch hierzu stehen in den meisten Fällen ein paar brauchbare Hinweise entweder unter
Code: Alles auswählen
/usr/share/doc/packetname
Und im Notfall (sollte nicht sein, aber Ausnahmen gibt es leider immer mal):
Nicht verzagen, Google fragen

Auch jede andere Distib hat diese oder andere Möglichkeiten der Sache Herr zu werden (Natürlich niemals so gute wie bei Debian

Und wer sich damit absolut nicht anfreunden kann oder will, der sollte entweder ein anderes OS als GNU/Linux wählen oder eine Distibution mit hübsch buntem Configtool das zumindest alle für einen solchen User erforderlichen Einstellungen für ihn vornehmen kann.

Gruß
Stephan
- Es gewinnt immer der, der den vorletzen Fehler macht -
Moin,
es gibt schon "eine Art Registry für Linux" namens Elektra, die sogar auf XML basiert. Dazu stand mal was in den Pro-Linux News[1].
Ob sich so ein Konfigurations-Standard jemals durchsetzen kann ist eine andere Frage.
Die Leute, die ihre configs von Hand bearbeiten und damit zurechtkommen würden wohl nicht so glücklich darüber sein, auf einmal mit XML-Dateien rumhantieren zu müssen. Dagegen ist es den Benutzern von grafischen Konfigurationsprogrammen egal, wie es unter der Haube aussieht.
Gruß, Marius
[1]http://www.pro-linux.de/news/2004/7571.html
es gibt schon "eine Art Registry für Linux" namens Elektra, die sogar auf XML basiert. Dazu stand mal was in den Pro-Linux News[1].
Ob sich so ein Konfigurations-Standard jemals durchsetzen kann ist eine andere Frage.
Die Leute, die ihre configs von Hand bearbeiten und damit zurechtkommen würden wohl nicht so glücklich darüber sein, auf einmal mit XML-Dateien rumhantieren zu müssen. Dagegen ist es den Benutzern von grafischen Konfigurationsprogrammen egal, wie es unter der Haube aussieht.
Gruß, Marius
[1]http://www.pro-linux.de/news/2004/7571.html
Ich hoffe inständig, dass sich dieser Quatsch nicht durchsetzen wird.
Ich mag die Windows Registry nicht und dieses ekelige gconf hatte ich schon wieder verdrängt. Undurchsichtig bis zum geht nichtmehr und wenn ich die Worte 'automatisch eintragen' höre könnte mir speiübel werden...
Direkt nach 'automatisch eintragen' kommt dann 'automatisch anpassen' dann 'Einstellungen optimieren' (gleichbedeutend mit willkürlich überschreiben)... und schon haben wir die M$ Entmündigung des Users.
Ich mag die Windows Registry nicht und dieses ekelige gconf hatte ich schon wieder verdrängt. Undurchsichtig bis zum geht nichtmehr und wenn ich die Worte 'automatisch eintragen' höre könnte mir speiübel werden...
Direkt nach 'automatisch eintragen' kommt dann 'automatisch anpassen' dann 'Einstellungen optimieren' (gleichbedeutend mit willkürlich überschreiben)... und schon haben wir die M$ Entmündigung des Users.

- Es gewinnt immer der, der den vorletzen Fehler macht -
Eine Registry an sich ist gar nicht schlecht. Es kommt nur auf die Implementierung an und die ist bei Windows eben sehr schlecht.
Eine XML basierte Registry ist schon ok. Und ob es euch gefällt oder nicht, die Evolution geht weiter und Linux wird nicht so bleiben wie wir es jetzt alle kennen...soviel ist sicher. Da keine einzelne Firma dahinter steht wird sich die beste und praktikabelste Lösung durchsetzen und es gibt keinen Grund zu jammern. Man kann es natürlich nicht jedem Recht machen und wahrscheinlich werden sich diese Leute dann ein anderes OS suchen müssen.
Fakt ist, Linux fehlt es an vielen Stellen noch zu einem modernen Betriebssystem. Und ich sage das als langjähriger überzeugter Linuxuser, damit mich hier keiner falsch versteht. Aber auch im Linuxland ist nicht alles nur toll und schön.
Eine XML basierte Registry ist schon ok. Und ob es euch gefällt oder nicht, die Evolution geht weiter und Linux wird nicht so bleiben wie wir es jetzt alle kennen...soviel ist sicher. Da keine einzelne Firma dahinter steht wird sich die beste und praktikabelste Lösung durchsetzen und es gibt keinen Grund zu jammern. Man kann es natürlich nicht jedem Recht machen und wahrscheinlich werden sich diese Leute dann ein anderes OS suchen müssen.
Fakt ist, Linux fehlt es an vielen Stellen noch zu einem modernen Betriebssystem. Und ich sage das als langjähriger überzeugter Linuxuser, damit mich hier keiner falsch versteht. Aber auch im Linuxland ist nicht alles nur toll und schön.
Ich habe irgendwo einmal ein kleines Tool gesehen, mit welchem man die Config-Files grafisch bearbeiten konnte. Zumindest einen Großteil davon. Der Aufbau der Files ist ja relativ eindeutig.
Kommentare, die vor der Optionszeile waren und in der gleichen Zeile wurden als Tooltips angezeigt.
Und wenn einmal eine Konfigurationsdatei gefehlt hat, konnte man diese fehlende Konfigurationsdatei in die Konfigurationsdatei des Tools eintragen und schon war sie auch vorhanden.
Aber bitte fragt mich jetzt nicht, wie dieses Tool geheißen hat. Es kann auch sein, dass das was SuSE-Spezifisches war.
Es gibt meines Erachtens einen Standard. Denn alle Konfigurations-Dateien sind im grunde gleich aufgebaut. Einige sind etwas komplexer und sind verschachtelt oder benutzen zusätzliche Logiken und Direktiven, aber der Großteil ist gleichartig aufgebaut.
Der Vorteil der jetztigen Konfigurationsdateien ist - wie schon mehrfach erwähnt - die unabhängigkeit. Man benötigt keinen großartigen Tools um diese zu bearbeiten. XML und was es noch an Möglichkeiten gibt hat alles den Nachteil, dass es in einem reinen Texteditor ziemlich unleserlich. Natürlich kann man auch da die Files bearbeiten, aber es ist um ein Vielfaches unübersichtlicher.
Am liebsten mag ich die gute alte Ini-Datei aus Dos-Zeiten bzw. aus der Anfangszeit von Windows. Und die Linux-Conf-Dateien sind im Grunde genauso aufgebaut.
Code: Alles auswählen
option=value
Und wenn einmal eine Konfigurationsdatei gefehlt hat, konnte man diese fehlende Konfigurationsdatei in die Konfigurationsdatei des Tools eintragen und schon war sie auch vorhanden.
Aber bitte fragt mich jetzt nicht, wie dieses Tool geheißen hat. Es kann auch sein, dass das was SuSE-Spezifisches war.
Es gibt meines Erachtens einen Standard. Denn alle Konfigurations-Dateien sind im grunde gleich aufgebaut. Einige sind etwas komplexer und sind verschachtelt oder benutzen zusätzliche Logiken und Direktiven, aber der Großteil ist gleichartig aufgebaut.
Der Vorteil der jetztigen Konfigurationsdateien ist - wie schon mehrfach erwähnt - die unabhängigkeit. Man benötigt keinen großartigen Tools um diese zu bearbeiten. XML und was es noch an Möglichkeiten gibt hat alles den Nachteil, dass es in einem reinen Texteditor ziemlich unleserlich. Natürlich kann man auch da die Files bearbeiten, aber es ist um ein Vielfaches unübersichtlicher.
Am liebsten mag ich die gute alte Ini-Datei aus Dos-Zeiten bzw. aus der Anfangszeit von Windows. Und die Linux-Conf-Dateien sind im Grunde genauso aufgebaut.
-
- Beiträge: 145
- Registriert: 04.01.2005 04:32:46
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Bremen
@niemand:
Ich sehe folgende Vorteile eines zentralen Konfigtools:
1. Konsistenz: (theoretisch) identische Daten an verschiedenen Stellen können auch praktisch identisch gehalten werden bzw. bei Abhängigkeiten aufeinander abgestimmt werden. Und dies durch einen einzigen Eingriff.
2. Korrektheit und Vollständigkeit: Prüfung der Daten, ob sie auch (syntaktisch) richtig sind, und Sinn machen oder ob etwas fehlt.
Einfach erreicht. Ohne evtl. wochenlanges Suchen nach brauchbarer, aktueller Doku oder ewigem Herumexperimentieren. So muß man sich als Admin nicht um jeden Pipifax kümmern, sondern kann sich auf das Wesentliche konzentrieren. Also für Qualität und Effizienz positiv.
Nur so kann Linux aus seiner Schmollecke herausfinden und den Anwender durch einfache Benutzbarkeit überzeugen. Freie Software darf nicht als 'das beste Argument für Windos' mißbraucht werden, sondern muß auch Wahlfreiheit bieten, also eine echte Alternative zu kommerzieller darstellen. Das Argument 'wer mit Linux nicht klarkommt, soll zu Windos gehen' halte ich deshalb für fatal; der Herr der Fenster freut sich darüber sicher diebisch!
Gruß
Odysseus24
Ich sehe folgende Vorteile eines zentralen Konfigtools:
1. Konsistenz: (theoretisch) identische Daten an verschiedenen Stellen können auch praktisch identisch gehalten werden bzw. bei Abhängigkeiten aufeinander abgestimmt werden. Und dies durch einen einzigen Eingriff.
2. Korrektheit und Vollständigkeit: Prüfung der Daten, ob sie auch (syntaktisch) richtig sind, und Sinn machen oder ob etwas fehlt.
Einfach erreicht. Ohne evtl. wochenlanges Suchen nach brauchbarer, aktueller Doku oder ewigem Herumexperimentieren. So muß man sich als Admin nicht um jeden Pipifax kümmern, sondern kann sich auf das Wesentliche konzentrieren. Also für Qualität und Effizienz positiv.
Nur so kann Linux aus seiner Schmollecke herausfinden und den Anwender durch einfache Benutzbarkeit überzeugen. Freie Software darf nicht als 'das beste Argument für Windos' mißbraucht werden, sondern muß auch Wahlfreiheit bieten, also eine echte Alternative zu kommerzieller darstellen. Das Argument 'wer mit Linux nicht klarkommt, soll zu Windos gehen' halte ich deshalb für fatal; der Herr der Fenster freut sich darüber sicher diebisch!
Gruß
Odysseus24
...in a sea of random images
the self-destructing animal
waiting for the waves to break
(Richard Wright)
the self-destructing animal
waiting for the waves to break
(Richard Wright)
-
- Beiträge: 145
- Registriert: 04.01.2005 04:32:46
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Bremen
@hafner:
es gibt auch Config4Gnu; aber (noch) nicht für Debian. Soll aber evtl mit in das dcontrol-Projekt einfließen; ich wette aber, das dauert noch Jahre, da Collin Walters bisher mit dem Installer sicherlich vollauf beschäftigt war.
Gruß
Odysseus24
es gibt auch Config4Gnu; aber (noch) nicht für Debian. Soll aber evtl mit in das dcontrol-Projekt einfließen; ich wette aber, das dauert noch Jahre, da Collin Walters bisher mit dem Installer sicherlich vollauf beschäftigt war.
Gruß
Odysseus24
...in a sea of random images
the self-destructing animal
waiting for the waves to break
(Richard Wright)
the self-destructing animal
waiting for the waves to break
(Richard Wright)
Doch. Falls du aber ein nur ein zentrales Konfigurationsverzeichnis wie rc.config.d unter HP-UX meinst, ist es ok.Indy500 hat geschrieben:Eine Registry an sich ist gar nicht schlecht.
XML-basierende Konfigurationen sind IMHO Schwachsinn. Nicht geht über ASCII.Indy500 hat geschrieben:Eine XML basierte Registry ist schon ok.
Das ist wohl war. Wenn man sich wieder auf die klaren, übersichtlichen, verständlichen Konfigurationsdateien der Unixe besinnen würde, wären die Linux-Distributionen einen deutlichen Schritt weiter. Ich bekomme jedenfalls immer eine Krise, wenn ich umständlich von XML nach ASCII konvertieren muss, nur um eine Gnome-Konfigurationsdatei zu lesen.Indy500 hat geschrieben:Aber auch im Linuxland ist nicht alles nur toll und schön.
Gruß
ernohl
ernohl
Odysseus24, das ist eine nette Vorstellung, nur wie soll man die mit der spezialisierten Software umsetzen? Gut, beim httpd ist Apache Quasistandard, aber schon beim ftpd, pop3d, smtpd, ..., ist doch schon wieder alles offen. Vorteil von Linux ist doch gerade, dass es viele Alternativen zu einer Sache gibt, und dass diese dezentral entwickelt werden, so dass sich jeder das raussuchen kann, was ihm am Ehesten zusagt.
Und wenn es nur darum geht, die Systeminterna mittels eines Tools vor dem Anwender zu verstecken, kann man das imho auch mit den derzeitigen Configs, wie Mossi schon erwähnte: Option (=) Value.
Aber du wirst mir zustimmen, dass es nicht die Frage des Formates (XML vs. Plaintext) ist, die ein solches Tool verhindert, sondern schlicht die schiere Menge an Software. Ein Tool für ausgewählte Vertreter zu schreiben würde hingegen bedeuten, den (einsteigenden) User darauf festzulegen und somit Alternativen aussterben zu lassen.
Wochenlanges Suchen nach/in der Doku ist kein Argument, denn die Konfigurationsdateien sind kommentiert, weiterhin lässt sich in den Manpages alles Relevante finden. Wochenlang müsste ich eher suchen, wenn ich in einer zentralen Konfigurationsdatei eine bestimmte Option für ein Programm suchen sollte.
Gerade für Einsteiger ist doch das Konzept, welches KDE verfolgt (und das gar nicht mal so weit von den Forderungen hier entfernt ist), nämlich die zentralisierte Konfiguration mittels Kontrollzentrum und die spezielle Konfiguration in den Programmen, zumutbar, und unter Windows wird es auch nicht anders gehandhabt. Ich behaupte, dass es einem Einsteiger reichlich egal ist, wie es darunter aussieht, und dass ein Einsteiger an den Sachen, die er derzeit direkt unter /etc einstellen müsste, größtenteils nichts verstellen möchte. Und selbst das lässt sich heute schon weitgehend zentral konfigurieren, wie SuSE so schön(?) vormacht.
Selbst, wenn man die Entwickler von freier Software dazu bringen würde, sich an ein einheitliches Konfigurationsschema zu halten, und dieses auf XML basieren lassen würde, führte das doch letztlich dazu, dass dem Einsteiger das Tool dafür vorgeschrieben würde, und dass der ambitionierte User, der lieber schnell die Datei öffnet und die Werte anpasst, "vergrault" würde, weil eben dieses mit XML keinen Spaß macht (mir persönlich jedenfalls nicht).
Und dass Linux in einer Schmollecke ist, halte ich für ein Gerücht
Indy500, wenn die Entwicklung dazu führt, dass Linux zwar als Desktopsystem eine hohe Akzeptanz erfährt, als Netzwerkbetriebssystem (und für sogenannte fortgeschrittene User) aber quasi unbrauchbar wird und sich diese Leute ein anderes OS zulegen müssen, wird das eher nicht so toll sein (was natürlich wieder Ansichtssache ist). Ich finde den derzeitigen Weg ganz passabel: Zentrale Konfiguration der für Desktopuser wichtigen Sachen, etwa den Desktop Environments, bei gleichzeitiger Freiheit, bei Bedarf einfacher zu konfigurierende Software einzusetzen. Ich bin absolut nicht dafür, sich den Windowsumsteigern anzupassen und dafür jahrelang bewährte Konzepte radikal zu ersetzen. Auch, wenn ich das nicht sagen sollte, weil es fatal wäre: Sollen die Windowsuser doch bei Windows bleiben, wenn sie nur ein Windows mit anderem Namen suchen. Oder sich von mir aus auch eine Distri suchen, die versucht, Windows nachzubauen - etwa SuSE. Ich bin zu Linux gekommen, weil ich da direkte Kontrolle über mein System habe und dieses nicht durch irgendwelche obskuren Tools verhindert wird.
Und zumindest meiner Meinung nach ist Linux ein sehr modernes OS, welches nur ein anderes Konzept verfolgt: Für jedes Problem eine einfache, dafür effiziente Lösung auch bei der Konfiguration anstelle einer einzigen, absolut unübersichtlichen Datei, in die alles gesteckt wird.
Aber letztlich prallen hier nur wieder zwei Welten aufeinander: Die traditionalle Usergruppe mit der "Ich komm von Windows und will hier alles genauso wie dort haben"-Gruppe. Wenn diese Gruppen in einer solchen Diskussion aufeinandertreffen, kann es keine einfache Lösung geben, so dass ich mich wieder dezent aus diesem Thread verabschiede
cu
niemand
Und wenn es nur darum geht, die Systeminterna mittels eines Tools vor dem Anwender zu verstecken, kann man das imho auch mit den derzeitigen Configs, wie Mossi schon erwähnte: Option (=) Value.
Aber du wirst mir zustimmen, dass es nicht die Frage des Formates (XML vs. Plaintext) ist, die ein solches Tool verhindert, sondern schlicht die schiere Menge an Software. Ein Tool für ausgewählte Vertreter zu schreiben würde hingegen bedeuten, den (einsteigenden) User darauf festzulegen und somit Alternativen aussterben zu lassen.
Wochenlanges Suchen nach/in der Doku ist kein Argument, denn die Konfigurationsdateien sind kommentiert, weiterhin lässt sich in den Manpages alles Relevante finden. Wochenlang müsste ich eher suchen, wenn ich in einer zentralen Konfigurationsdatei eine bestimmte Option für ein Programm suchen sollte.
Gerade für Einsteiger ist doch das Konzept, welches KDE verfolgt (und das gar nicht mal so weit von den Forderungen hier entfernt ist), nämlich die zentralisierte Konfiguration mittels Kontrollzentrum und die spezielle Konfiguration in den Programmen, zumutbar, und unter Windows wird es auch nicht anders gehandhabt. Ich behaupte, dass es einem Einsteiger reichlich egal ist, wie es darunter aussieht, und dass ein Einsteiger an den Sachen, die er derzeit direkt unter /etc einstellen müsste, größtenteils nichts verstellen möchte. Und selbst das lässt sich heute schon weitgehend zentral konfigurieren, wie SuSE so schön(?) vormacht.
Selbst, wenn man die Entwickler von freier Software dazu bringen würde, sich an ein einheitliches Konfigurationsschema zu halten, und dieses auf XML basieren lassen würde, führte das doch letztlich dazu, dass dem Einsteiger das Tool dafür vorgeschrieben würde, und dass der ambitionierte User, der lieber schnell die Datei öffnet und die Werte anpasst, "vergrault" würde, weil eben dieses mit XML keinen Spaß macht (mir persönlich jedenfalls nicht).
Und dass Linux in einer Schmollecke ist, halte ich für ein Gerücht

Indy500, wenn die Entwicklung dazu führt, dass Linux zwar als Desktopsystem eine hohe Akzeptanz erfährt, als Netzwerkbetriebssystem (und für sogenannte fortgeschrittene User) aber quasi unbrauchbar wird und sich diese Leute ein anderes OS zulegen müssen, wird das eher nicht so toll sein (was natürlich wieder Ansichtssache ist). Ich finde den derzeitigen Weg ganz passabel: Zentrale Konfiguration der für Desktopuser wichtigen Sachen, etwa den Desktop Environments, bei gleichzeitiger Freiheit, bei Bedarf einfacher zu konfigurierende Software einzusetzen. Ich bin absolut nicht dafür, sich den Windowsumsteigern anzupassen und dafür jahrelang bewährte Konzepte radikal zu ersetzen. Auch, wenn ich das nicht sagen sollte, weil es fatal wäre: Sollen die Windowsuser doch bei Windows bleiben, wenn sie nur ein Windows mit anderem Namen suchen. Oder sich von mir aus auch eine Distri suchen, die versucht, Windows nachzubauen - etwa SuSE. Ich bin zu Linux gekommen, weil ich da direkte Kontrolle über mein System habe und dieses nicht durch irgendwelche obskuren Tools verhindert wird.
Und zumindest meiner Meinung nach ist Linux ein sehr modernes OS, welches nur ein anderes Konzept verfolgt: Für jedes Problem eine einfache, dafür effiziente Lösung auch bei der Konfiguration anstelle einer einzigen, absolut unübersichtlichen Datei, in die alles gesteckt wird.
Aber letztlich prallen hier nur wieder zwei Welten aufeinander: Die traditionalle Usergruppe mit der "Ich komm von Windows und will hier alles genauso wie dort haben"-Gruppe. Wenn diese Gruppen in einer solchen Diskussion aufeinandertreffen, kann es keine einfache Lösung geben, so dass ich mich wieder dezent aus diesem Thread verabschiede

cu
niemand
Hi!
Gerade weil nur wenige Firmen dahinter stecken, deren Hauptziel es ist, das ganze benutzerfreundlich zu bekommen, wird es eben auf Dauer so bleiben, wie die Entwickler der Programme damit klarkommen, nämlich so, wie seit 30 Jahren die "beste und praktikabelste Lösung" für Unixer ist.
Bye
g-henna
(Das "keinen Grund zu jammern" ist das Argument, diesen Thread zu schließen und jeden anderen, der Missstände kritisiert...)Indy500 hat geschrieben:Und ob es euch gefällt oder nicht, die Evolution geht weiter und Linux wird nicht so bleiben wie wir es jetzt alle kennen...soviel ist sicher. Da keine einzelne Firma dahinter steht wird sich die beste und praktikabelste Lösung durchsetzen und es gibt keinen Grund zu jammern.
Gerade weil nur wenige Firmen dahinter stecken, deren Hauptziel es ist, das ganze benutzerfreundlich zu bekommen, wird es eben auf Dauer so bleiben, wie die Entwickler der Programme damit klarkommen, nämlich so, wie seit 30 Jahren die "beste und praktikabelste Lösung" für Unixer ist.
Bye
g-henna
follow the penguin...
Nur weil es 30 Jahre so war, heißt das nicht das es deswegen optimal ist. Das erleben wir ja auch täglich im richtigen Leben. In 5 Jahren kannst du den Thread nochmal ausgraben dann wirst du sehen wieviel sich verändert hat.
Nach deiner Logik würden wir heute noch mit Pferdekutschen fahren. Linux hat nunmal Schwächen auch wenn dir das nicht gefällt. Man sollte das aber sachlich zur Kenntnis nehmen und die religiösen Anschauungen beiseite lassen.
P.S
Hier geht es nicht um Linux vs. Windows.
Nach deiner Logik würden wir heute noch mit Pferdekutschen fahren. Linux hat nunmal Schwächen auch wenn dir das nicht gefällt. Man sollte das aber sachlich zur Kenntnis nehmen und die religiösen Anschauungen beiseite lassen.
P.S
Hier geht es nicht um Linux vs. Windows.
Vielleicht sollte ich anbei noch eine Kleinigkeit erwähnen. Ich bin Software-Entwickler in verschiedenen Branchen. Zum Großteil verwenden meine Kunden Windows. Persönlich versuche ich aber, meine Tools weitestgehend systemunabhängig zu halten. Dies ist für mich der Grund, warum ich nur selten (außer auf Wunsch) irgendwelche Daten in der Registry von Windows ablege. Ich gehe das Risiko ein und stelle meine Programme mit einer Ini-Datei bereit. Die Optionen kann man natürlich auch per Oberfläche setzen falls eine Oberfläche vorhanden ist. Ich nenne es deswegen Risiko, weil es in der Windows-Welt ein recht eigenwilliger Weg ist.
Nun aber das worauf ich eigentlich hinaus will: Fast alle meiner Kunden sind mit einer solchen Konfigurationsmethode absolut zufrieden und ältere Kunden verlangen dies sogar als Voraussetzung für neue Projekte. Ich hatte erst kürzlich ein Gespräch mit jemanden, der davon eben begeistert ist. Seine Brgündung für seine Begeisterung und warum ihm meine Tools gefallen beruht zum Großteil darauf, dass es übersichtlicher zu verwalten ist, wenn jedes Tool seine eigene Konfiguration hat und wenn der User weiß, wo er nachschauen muss um etwas zu ändern. Weitere Aspekte waren zum Beispiel portierbarkeit auf andere Installationen oder sogar andere Systeme.
Ja. Das wäre auch mit XML gegeben, aber wie bitte soll ein unerfahrener User eine XML-Datei bearbeiten, wenn keine Oberfläche zur Verfügung steht? Und ich werde mich weigern eine billige Oberfläche für ein Tool zu schreiben, welches sowieso nur als Hintergrundprozess laufen soll.
XML war vormals als allgemeingültige Schnittstellen-Beschreibung gedacht. Das Ziel war es systemübergreifend Daten in einem definierten Format zu transferieren. Bei dieser Anschauung hat der User nichts mit diesem Format zu tun. Ein Datentransfer soll ja auch absolut transparent verlaufen und den User nicht mit unnötigen Fragen belästigen. Von einer direkten Bearbeitung solcher Daten war eigentlich nichts geplant außer dass man fehler im Protokoll direkt bearbeiten kann, da es eben als ASCII abgelegt ist. Wenn man von diesem Konzept ausgeht, ist XML für eine Konfigurations-Datei die absolut falsche Basis. Von welchem System werden zu welchem System Daten transferiert?
Nun aber das worauf ich eigentlich hinaus will: Fast alle meiner Kunden sind mit einer solchen Konfigurationsmethode absolut zufrieden und ältere Kunden verlangen dies sogar als Voraussetzung für neue Projekte. Ich hatte erst kürzlich ein Gespräch mit jemanden, der davon eben begeistert ist. Seine Brgündung für seine Begeisterung und warum ihm meine Tools gefallen beruht zum Großteil darauf, dass es übersichtlicher zu verwalten ist, wenn jedes Tool seine eigene Konfiguration hat und wenn der User weiß, wo er nachschauen muss um etwas zu ändern. Weitere Aspekte waren zum Beispiel portierbarkeit auf andere Installationen oder sogar andere Systeme.
Ja. Das wäre auch mit XML gegeben, aber wie bitte soll ein unerfahrener User eine XML-Datei bearbeiten, wenn keine Oberfläche zur Verfügung steht? Und ich werde mich weigern eine billige Oberfläche für ein Tool zu schreiben, welches sowieso nur als Hintergrundprozess laufen soll.
XML war vormals als allgemeingültige Schnittstellen-Beschreibung gedacht. Das Ziel war es systemübergreifend Daten in einem definierten Format zu transferieren. Bei dieser Anschauung hat der User nichts mit diesem Format zu tun. Ein Datentransfer soll ja auch absolut transparent verlaufen und den User nicht mit unnötigen Fragen belästigen. Von einer direkten Bearbeitung solcher Daten war eigentlich nichts geplant außer dass man fehler im Protokoll direkt bearbeiten kann, da es eben als ASCII abgelegt ist. Wenn man von diesem Konzept ausgeht, ist XML für eine Konfigurations-Datei die absolut falsche Basis. Von welchem System werden zu welchem System Daten transferiert?
-
- Beiträge: 145
- Registriert: 04.01.2005 04:32:46
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Bremen
@niemand und alle sonst
Habe ja nicht behauptet, daß das so mirnichts dirnichts umzusetzen ist. Hast ja auch recht, das größte Problem dabei ist die Menge und die Vielfalt der angebotenen Software. Denn formale Fragen wie Formate, Korrektheit bzw. Vollständigkeit einzelner Config-Files sind technisch sicher unproblematisch (p.s. Klartext ist schon ok; aber wer dort selbst Veränderungen vornimmt, muß eben wissen, was er tut...).
Die Handhabung der Masse bei potentiellen Abhängigkeitsproblemen dürfte da halt schon eher schwierig werden. Solche Abhängigkeiten müssten definiert und geprüft werden; eher vom Packet-Maintainer der Distro denn vom Entwickler selbst. Die Menge der potentiellen Inkonsistenzen dürfte mit steigender Anzahl von Packeten fakultativ wachsen... Aber um die tatsächlichen Abhängigkeiten herauszufinden gibt's ja Sid und Sarge.
Eine Architektur für ein Tool zu finden, das die gefundenen Konsistenzregeln dann in den Dateien (dezentral unter /etc/; wie gehabt; bloß keine zentrale Datenbank; würde ja die Entwickler nötigen alles umzuschreiben) überprüft und ggf. auch bemängelt oder auch Lösungsvorschläge macht, dürfte dann wiederum technisch machbar sein. Wo ein Willi ist, ist auch ein Weg. Und wer's nicht braucht, der installiert es halt nicht; soll ja keiner zu seinem Glück gezwungen werden...
Gruß
Odysseus24
Habe ja nicht behauptet, daß das so mirnichts dirnichts umzusetzen ist. Hast ja auch recht, das größte Problem dabei ist die Menge und die Vielfalt der angebotenen Software. Denn formale Fragen wie Formate, Korrektheit bzw. Vollständigkeit einzelner Config-Files sind technisch sicher unproblematisch (p.s. Klartext ist schon ok; aber wer dort selbst Veränderungen vornimmt, muß eben wissen, was er tut...).
Die Handhabung der Masse bei potentiellen Abhängigkeitsproblemen dürfte da halt schon eher schwierig werden. Solche Abhängigkeiten müssten definiert und geprüft werden; eher vom Packet-Maintainer der Distro denn vom Entwickler selbst. Die Menge der potentiellen Inkonsistenzen dürfte mit steigender Anzahl von Packeten fakultativ wachsen... Aber um die tatsächlichen Abhängigkeiten herauszufinden gibt's ja Sid und Sarge.
Eine Architektur für ein Tool zu finden, das die gefundenen Konsistenzregeln dann in den Dateien (dezentral unter /etc/; wie gehabt; bloß keine zentrale Datenbank; würde ja die Entwickler nötigen alles umzuschreiben) überprüft und ggf. auch bemängelt oder auch Lösungsvorschläge macht, dürfte dann wiederum technisch machbar sein. Wo ein Willi ist, ist auch ein Weg. Und wer's nicht braucht, der installiert es halt nicht; soll ja keiner zu seinem Glück gezwungen werden...
Gruß
Odysseus24
...in a sea of random images
the self-destructing animal
waiting for the waves to break
(Richard Wright)
the self-destructing animal
waiting for the waves to break
(Richard Wright)
*sigh* also ok:

Fühl dich nicht angegriffen, aber wenn wir schon bei hinkenden Vergleichen sind, darf ich auch einmal.
Ich denke eigentlich, dass ich herausgestellt habe, dass es lediglich meine Meinung ist, die langen Texte dazu sollten nur dazu dienen, die ein wenig nachvollziehbar zu begründen.
Dass Linux Schwächen hat, ist mir wohlbekannt, allerdings ist die vermeintliche Schwäche, um die es hier geht, aus meiner persönlichen Sicht eine grundlegende Stärke.
Mossi, XML eignet sich auch gut zur Speicherung von Daten (siehe OOffice) und für Konfigurationszwecke (siehe Ant). Allerdings ist es auch meine Meinung, dass es nichts in Dateien zu suchen hat, die manuell bearbeitet werden. Vom enormen Overhead von XML mal abgesehen (ich wage zu behaupten, dass bei kleineren Programmen der Anteil der XML-Tags 70% der Konfigurationsdateien einnehmen würde).
Meine Standpunkt ist schlicht folgender: Ein solches Tool zur Konfiguration mag für manche sinnvoll erscheinen, für manche auch nicht. Deshalb kann man es doch so umsetzen, wie es SuSE vormacht: Das Tool (in dem Fall SuSEConfig (k.A., ob es das so noch gibt, ist lange her, dass ich damit gearbeitet habe)) ist eine Art Wrapper, es liest seine Daten aus einer zentralen Datei und verteilt die Konfigurationsdirektiven auf die nativen Configs. Damit ist doch den Wünschen beider Lager entsprochen: einerseits eine zentrale Konfigurationsdatei, deren Zugriff über das Tool erfolgt, andererseits die Möglichkeit, ohne Nachteile darauf verzichten zu können.
Wenn man das Ganze, im Gegensatz zu dem Teil von SuSE, noch modular aufbaut, so dass jeder, der gerade Lust hat, für sein Lieblingsprogramm einen Regelsatz für dessen Config zu schreiben (und da könnte man auch das geforderte XML einbringen), es kann, ist doch alles super - der Win-Umsteiger findet seine liebgewonnene, zentrale Verwaltung und der Unixliebhaber kann wie gehabt alles selbst kontrollieren.
cu
niemand
Zum Einen hat es sich im Laufe der Jahre sehr wohl geändert (anfangs waren die Konfigurationsdateien um einiges kryptischer), zum Anderen ist diese Art der Konfiguration ein grundlegendes Konzept vieler Unices, welches man (hoffentlich) nicht über den Haufen werfen wird, nur weil man irgend einem Desktop-OS Marktanteile abluchsen will.Nur weil es 30 Jahre so war, heißt das nicht das es deswegen optimal ist. Das erleben wir ja auch täglich im richtigen Leben. In 5 Jahren kannst du den Thread nochmal ausgraben dann wirst du sehen wieviel sich verändert hat.
Nach meiner Logik ist das mit dem Autos aber schon ok so (Verbesserung des Antriebes - Pferd vs. Motor) bei gleichzeitigem Beibehalten des grundlegenden Konzeptes (vier Räder, deren Anordnung, Karosserie, ...). Nur nach deiner dürften Autos heute nicht so aussehen, wie sie es tun (ich hätte da ein paar Designvorschläge...).Nach deiner Logik würden wir heute noch mit Pferdekutschen fahren. Linux hat nunmal Schwächen auch wenn dir das nicht gefällt. Man sollte das aber sachlich zur Kenntnis nehmen und die religiösen Anschauungen beiseite lassen.

Fühl dich nicht angegriffen, aber wenn wir schon bei hinkenden Vergleichen sind, darf ich auch einmal.
Ich denke eigentlich, dass ich herausgestellt habe, dass es lediglich meine Meinung ist, die langen Texte dazu sollten nur dazu dienen, die ein wenig nachvollziehbar zu begründen.
Dass Linux Schwächen hat, ist mir wohlbekannt, allerdings ist die vermeintliche Schwäche, um die es hier geht, aus meiner persönlichen Sicht eine grundlegende Stärke.
Du schriebst weiter oben, dass eine Registry nicht schlecht wäre. Registry assoziiere ich aber nunmal mit Windows, weil es dessen Konzept ist. Das Prinzip der Kapselung des Systems vom User ist auch eher typisch für Win. Und die Forderung, ein solches Prinzip auch bei Unices einführen zu wollen, ist eher typisch für Umsteiger von Windows. Ich habe mir daher erlaubt, Windows als Synonym für die Zusammenfassung zu verwenden. Ich selbst bin Win gegenüber gar nicht mal so negativ eingestellt, finde aber, dass dessen Konzepte in Unices nichts zu suchen haben.Hier geht es nicht um Linux vs. Windows.
Mossi, XML eignet sich auch gut zur Speicherung von Daten (siehe OOffice) und für Konfigurationszwecke (siehe Ant). Allerdings ist es auch meine Meinung, dass es nichts in Dateien zu suchen hat, die manuell bearbeitet werden. Vom enormen Overhead von XML mal abgesehen (ich wage zu behaupten, dass bei kleineren Programmen der Anteil der XML-Tags 70% der Konfigurationsdateien einnehmen würde).
Meine Standpunkt ist schlicht folgender: Ein solches Tool zur Konfiguration mag für manche sinnvoll erscheinen, für manche auch nicht. Deshalb kann man es doch so umsetzen, wie es SuSE vormacht: Das Tool (in dem Fall SuSEConfig (k.A., ob es das so noch gibt, ist lange her, dass ich damit gearbeitet habe)) ist eine Art Wrapper, es liest seine Daten aus einer zentralen Datei und verteilt die Konfigurationsdirektiven auf die nativen Configs. Damit ist doch den Wünschen beider Lager entsprochen: einerseits eine zentrale Konfigurationsdatei, deren Zugriff über das Tool erfolgt, andererseits die Möglichkeit, ohne Nachteile darauf verzichten zu können.
Wenn man das Ganze, im Gegensatz zu dem Teil von SuSE, noch modular aufbaut, so dass jeder, der gerade Lust hat, für sein Lieblingsprogramm einen Regelsatz für dessen Config zu schreiben (und da könnte man auch das geforderte XML einbringen), es kann, ist doch alles super - der Win-Umsteiger findet seine liebgewonnene, zentrale Verwaltung und der Unixliebhaber kann wie gehabt alles selbst kontrollieren.
cu
niemand
Zuletzt geändert von DeletedUserReAsG am 10.01.2005 04:16:00, insgesamt 1-mal geändert.
XML:
XML war ein Beispiel. Wenn es einen besseren Standard gibt (oder einer erfunden wird) bin ich der Letzte der sich dagegen streuben würde.
Registry:
Ich finde die Windows-Registry noch viel schlimmer als die Unordnung in /etc. Aber das heist ja nicht, dass es nicht besser geht. Mir ist auch unklar, warum Microsoft die ganze Registry ständig im Speicher haben muß. Aber das ist deren Problem....
GUI:
Meiner Meinung nach muß man die Configurationsdateien als solches bearbeiten können UND mit einem grafischen Tool. Das Letztere ist vor allem für Einsteiger wichtig. Mann kann von einem Otto-Normalverbraucher nicht erwarten das er die ganze Linuxstruktur kennt. Ein Workstation-Betriebssystem sollte intuitiev zu bedienen sein. Hier ist Windows Linux leider noch weit voraus.
Fazit:
Es kann nicht schaden einen einheitlichen Standard für das /etc Verzeichnis zu entwickeln. Für die Allgemeinheit währe es schlicht mehr Ordnung und für die Einsteiger ergeben sich weniger Umstiegsprobleme.
XML war ein Beispiel. Wenn es einen besseren Standard gibt (oder einer erfunden wird) bin ich der Letzte der sich dagegen streuben würde.
Registry:
Ich finde die Windows-Registry noch viel schlimmer als die Unordnung in /etc. Aber das heist ja nicht, dass es nicht besser geht. Mir ist auch unklar, warum Microsoft die ganze Registry ständig im Speicher haben muß. Aber das ist deren Problem....
GUI:
Meiner Meinung nach muß man die Configurationsdateien als solches bearbeiten können UND mit einem grafischen Tool. Das Letztere ist vor allem für Einsteiger wichtig. Mann kann von einem Otto-Normalverbraucher nicht erwarten das er die ganze Linuxstruktur kennt. Ein Workstation-Betriebssystem sollte intuitiev zu bedienen sein. Hier ist Windows Linux leider noch weit voraus.
Fazit:
Es kann nicht schaden einen einheitlichen Standard für das /etc Verzeichnis zu entwickeln. Für die Allgemeinheit währe es schlicht mehr Ordnung und für die Einsteiger ergeben sich weniger Umstiegsprobleme.
Ich kann nicht erkennen, was an dem "Option=Wert"-System so schlecht und altbacken sein soll. Im Gegenteil, es ist ein System, dass sich bewährt hat, da ist es ziemlich egal ob es 10, 30 oder 100 Jahre alt ist. Das ist Konfiguration in simpelster Form, die IMHO sofort eingängig und für jeden verständlich ist und mit in-Place-Kommentaren innerhalb einer Datei sogar guten Komfort bietet. Nebenbei halte ich die Vorgehensweise, dass es für jedes Programmpaket eine eigene Datei bzw. ein eigenes Unterverzeichnis gibt, für eine ziemlich eindeutige und sinnvolle Strukturierung.
Zum Vergleich: Die Schlüssel und Werte in der Windows-Registry können in-Place überhaupt nicht dokumentiert werden und eine externe Dokumentation fehlt meistens auch komplett. Nebenbei ist sie an vielen Stellen unzureichend strukturiert, d.h. dass sich viele Programme (auch die von Microsoft) quer über sämtliche Schlüssel verteilen und man nicht selten nicht mehr nachvollziehen kann, welche Schlüssel/Werte nun zu welchem Programm gehören. Eine weitere bittere Pille sind die meist ebenfalls nicht dokumentierten Abhängigkeiten zwischen einzelnen Programmpaketen. Aber auch dokumentierte Verfahren wie die Registrierung von COM-Schnittstellen und -Implementierungen sind bei manueller Modifikation eine Qual.
Last but not least kann ich die Konfigurationsdateien der Unices mit jedem Texteditor bearbeiten und ich bin nicht auf ein spezielles Programm angewiesen, um sie für mich überhaupt lesbar bzw. modifizierbar zu machen. Wenn ich von einem absoluten Notsystem (sei es eine Diskette mit Kernel und vi drauf) booten muss ist das definitiv ein Killerfeature. Auch wenn man remote über das Internet irgendeine Büchse administrieren muss ist das ziemlich nützlich, das klappt sogar mit einer einer popeligen Modemverbindung.
Auch finde ich es immer wieder hinreichend lächerlich, wenn Leute im Schlagwortrausch irgendwelche Technologien erwähnen/fordern, die momentan gerade en Vogue sind, ungeachtet dessen, ob sie für die jeweilige Aufgabe Sinn machen oder nicht. XML z.B. ist für die meisten Konfigurationsdateien einfach nur Overkill, da ich mich nicht nur auf die einzelnen Optionen konzentrieren muss, sondern auch darauf achten muss, dass die ganze Datei wohlgeformt bleibt und ich keine Markups beschädige. Ganz übel finde ich das bei gconf oder der Menüverwaltung von Gnome 2.x. So sehr ich Gnome auch mag, aber das war IMHO ein Rückschritt. Ich könnte jedes mal das Kotzen kriegen wenn ich beispielsweise Dateien in ~/.gnome2/vfolders bearbeiten will.
Ein zentrales Konfigurationstool mag für Standardaufgaben (User anlegen, NICs konfigurieren, etc.) ja noch ganz nützlich sein, für die meisten Programme wäre dies aber ein nicht zu vertretender Mehraufwand. Man müsste bei jedem Update eines Programmpaketes sicherstellen, dass dieses zentrale Konfigurationstool noch macht was es soll und schauen, ob neue Optionen brücksichtigt werden müssen, um keinen Feature- oder gar Funktionsverlust zu riskieren. Bei gut 15000 Pakten ist das ein ziemlich aussichtloses Unterfangen. Sinnvoller ist da sicher der Ansatz von Debconf, wo die Konfiguration nicht wirklich zentral sondern auf Paketbasis erfolgt, und das lediglich bei Paketen, wo dies auch hilfreich ist (z.B. X-Server-Konfiguration).
Das GUI-Argument macht auch nicht 100%ig Sinn, da es doch einige Programm gibt, bei denen eine GUI absolut hinderlich wäre. Z.B. bei einer Datei mit mehreren 100 oder gar 1000 Mail-Konten kann man mit der Suchen-Funktion (gerne auch mit Reg-Ex) eines Texteditors wesentlich flotter zu Werke gehen als man es mit einer GUI könnte.
Für einfache Standardaufgaben gibt es natürlich schon Tools wie Webmin oder Linuxconf, die einem die Arbeit etwas erleichtern können und möglicherweise schon vieles Abdecken, was man braucht. Sie sind AFAIK auch in Debian vorhanden.
Wer natürlich eine vollständigere und zentralere Konfiguration haben möchte, sollte sich besser bei einer anderen Distribution wie SuSE oder Mandrake umsehen, da der Desktop für Anfänger seither eher deren Domäne ist, mit all den Problemchen, die damit verbunden sind.
Zum Vergleich: Die Schlüssel und Werte in der Windows-Registry können in-Place überhaupt nicht dokumentiert werden und eine externe Dokumentation fehlt meistens auch komplett. Nebenbei ist sie an vielen Stellen unzureichend strukturiert, d.h. dass sich viele Programme (auch die von Microsoft) quer über sämtliche Schlüssel verteilen und man nicht selten nicht mehr nachvollziehen kann, welche Schlüssel/Werte nun zu welchem Programm gehören. Eine weitere bittere Pille sind die meist ebenfalls nicht dokumentierten Abhängigkeiten zwischen einzelnen Programmpaketen. Aber auch dokumentierte Verfahren wie die Registrierung von COM-Schnittstellen und -Implementierungen sind bei manueller Modifikation eine Qual.
Last but not least kann ich die Konfigurationsdateien der Unices mit jedem Texteditor bearbeiten und ich bin nicht auf ein spezielles Programm angewiesen, um sie für mich überhaupt lesbar bzw. modifizierbar zu machen. Wenn ich von einem absoluten Notsystem (sei es eine Diskette mit Kernel und vi drauf) booten muss ist das definitiv ein Killerfeature. Auch wenn man remote über das Internet irgendeine Büchse administrieren muss ist das ziemlich nützlich, das klappt sogar mit einer einer popeligen Modemverbindung.
Auch finde ich es immer wieder hinreichend lächerlich, wenn Leute im Schlagwortrausch irgendwelche Technologien erwähnen/fordern, die momentan gerade en Vogue sind, ungeachtet dessen, ob sie für die jeweilige Aufgabe Sinn machen oder nicht. XML z.B. ist für die meisten Konfigurationsdateien einfach nur Overkill, da ich mich nicht nur auf die einzelnen Optionen konzentrieren muss, sondern auch darauf achten muss, dass die ganze Datei wohlgeformt bleibt und ich keine Markups beschädige. Ganz übel finde ich das bei gconf oder der Menüverwaltung von Gnome 2.x. So sehr ich Gnome auch mag, aber das war IMHO ein Rückschritt. Ich könnte jedes mal das Kotzen kriegen wenn ich beispielsweise Dateien in ~/.gnome2/vfolders bearbeiten will.
Ein zentrales Konfigurationstool mag für Standardaufgaben (User anlegen, NICs konfigurieren, etc.) ja noch ganz nützlich sein, für die meisten Programme wäre dies aber ein nicht zu vertretender Mehraufwand. Man müsste bei jedem Update eines Programmpaketes sicherstellen, dass dieses zentrale Konfigurationstool noch macht was es soll und schauen, ob neue Optionen brücksichtigt werden müssen, um keinen Feature- oder gar Funktionsverlust zu riskieren. Bei gut 15000 Pakten ist das ein ziemlich aussichtloses Unterfangen. Sinnvoller ist da sicher der Ansatz von Debconf, wo die Konfiguration nicht wirklich zentral sondern auf Paketbasis erfolgt, und das lediglich bei Paketen, wo dies auch hilfreich ist (z.B. X-Server-Konfiguration).
Das GUI-Argument macht auch nicht 100%ig Sinn, da es doch einige Programm gibt, bei denen eine GUI absolut hinderlich wäre. Z.B. bei einer Datei mit mehreren 100 oder gar 1000 Mail-Konten kann man mit der Suchen-Funktion (gerne auch mit Reg-Ex) eines Texteditors wesentlich flotter zu Werke gehen als man es mit einer GUI könnte.
Für einfache Standardaufgaben gibt es natürlich schon Tools wie Webmin oder Linuxconf, die einem die Arbeit etwas erleichtern können und möglicherweise schon vieles Abdecken, was man braucht. Sie sind AFAIK auch in Debian vorhanden.
Wer natürlich eine vollständigere und zentralere Konfiguration haben möchte, sollte sich besser bei einer anderen Distribution wie SuSE oder Mandrake umsehen, da der Desktop für Anfänger seither eher deren Domäne ist, mit all den Problemchen, die damit verbunden sind.
Was man bei der Diskussion nicht vergessen sollte: Linux läuft auch auf anderen Geräten als einem Desktop. Wenn ich z.B. auf einem Router erst noch die komplette libxml installieren muss, nur damit ich meine Konfigurationsdateien parsen kann, dann ist das nicht unbedingt von Vorteil.
Was soll den vereinheitlich werden?
Das XML Format selber ist ja nur ein Container, der im Bereich Konfigurationsdatei nicht mehr Möglichkeiten bietet als z.B. das Windows-INI Format. Dadurch würden aber die Konfigurationsdateien nicht einfacher oder übersichtlicher. Im Gegenteil: XML ohne eine GUI zu bearbeiten ist eine Qual - und wenn ich als Netzwerkadmin mal kurz eine Datei remote verändern möchte, dann möchte ich nicht erst hin- und herkopieren, dann eine grafische Oberfläche finden nur um ein Häckchen zu machen.
Was soll den vereinheitlich werden?
Das XML Format selber ist ja nur ein Container, der im Bereich Konfigurationsdatei nicht mehr Möglichkeiten bietet als z.B. das Windows-INI Format. Dadurch würden aber die Konfigurationsdateien nicht einfacher oder übersichtlicher. Im Gegenteil: XML ohne eine GUI zu bearbeiten ist eine Qual - und wenn ich als Netzwerkadmin mal kurz eine Datei remote verändern möchte, dann möchte ich nicht erst hin- und herkopieren, dann eine grafische Oberfläche finden nur um ein Häckchen zu machen.
Bin auch der Meinung das das Registry System von Windows nicht so das wahre ist! Man sieht ja wie schnell so eine (ja ach so übersichtliche) Registry so zugemüllt ist das es einfacher is das System neu aufzusetzen als da wieder sauber zu machen.
Ich liebe die Flexibilität die Linux systeme durch die einzelnen Config Dateien erhalten!
Das einzige was vllt sinnvoll wäre is eine etwas mehr standartisierte Art von Config Dateien damit diese leichter und übersichtlicher verändert werden können und auch grafische Oberflächen für diese kein Problem mehr darstellen.
Ich liebe die Flexibilität die Linux systeme durch die einzelnen Config Dateien erhalten!
Das einzige was vllt sinnvoll wäre is eine etwas mehr standartisierte Art von Config Dateien damit diese leichter und übersichtlicher verändert werden können und auch grafische Oberflächen für diese kein Problem mehr darstellen.
Debian Lenny, Squeeze (Server)
Openindiana (NAS)
PfSense (Router, Firewall)
Ubuntu (Notebook)
Arch Linux (Desktop)
Openindiana (NAS)
PfSense (Router, Firewall)
Ubuntu (Notebook)
Arch Linux (Desktop)
Hi!
(Jetzt bitte keine Kommentare über religiöse Vorurteile...)
Bye
g-henna
...und zwar genau deshalb, weil der sog. "Einsteiger" und "Normalverbraucher" nur Windows kennt und weiß, wo was ist und wie oft man wo klicken muss (wenn er es weiß... *grin*). Ansonsten ist es einfach *anders*. Wenn ich heute an ein Windows XP soll, Netzwerkeinstellungen ändern, dann bekomm ich immer sooon Hals, über tausende Buttons ("Verbindungen", "Eigenschaften", "Protokolle", "Erweitert" etc.), die teilweise alles andere als intuitiv positioniert und beschriftet sind, da komm ich nur deswegen zurecht, weil ich den Stil von früher kenne. Und ich muss trotzdem immer noch suchen. Man müsste Versuche mit Kindern von so Computer-Abstinenzlern machen und die mit zehn Jahren das erste Mal vor einen PC setzen. Aber-- ja gut, lassen wir das, es wird OT *grin*Hafner hat geschrieben:Das Letztere ist vor allem für Einsteiger wichtig. Mann kann von einem Otto-Normalverbraucher nicht erwarten das er die ganze Linuxstruktur kennt. Ein Workstation-Betriebssystem sollte intuitiev zu bedienen sein. Hier ist Windows Linux leider noch weit voraus.
(Jetzt bitte keine Kommentare über religiöse Vorurteile...)
Bye
g-henna
follow the penguin...
Für wieviel muß diese Ausrede noch herhalten?g-henna hat geschrieben: ...und zwar genau deshalb, weil der sog. "Einsteiger" und "Normalverbraucher" nur Windows kennt und weiß, wo was ist und wie oft man wo klicken muss
Sicher hat man sich an ein Betriebssystem gewöhnt, aber alles nur darauf zu schieben ist schlicht falsch. Mit MacOS kommt man auch ohne größere Probleme klar, obwohl man es noch nie zuvor gesehen hat.
Niemand will in Linux die Shell abschaffen.
Niemand sagt, das es nicht besser und übersichtlicher geht, als es Microsoft macht. Man solle Linux auch nicht zwanghaft wie Windows machen. Das ist 1. nicht möglich und 2. will das auch keiner.
Warum man bei jeder Kritik bzw. bei jedem Verbesserungsvorschlag gleich in die Windows-Ecke geschoben wird ist mir schleierhaft.