nach 8 Wochen Linux 150 DM Telefonrechnung 20 DM zum ausdrucken von
verschiedenen Howtos hab ich Linux wieder von der Platte geschmissen.
Man mag uber Windows schlecht reden nuja , aber es ist und bleibt
derzeit eben eins der Betriebssysteme wo ich keine Installationsorgien
hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
es lauft alles ! Nun wenn es in 3-4 Jahren noch Linux gibt, und es bis
dahin besser geworden ist werde ich es nocheinmal probieren.
PS: Ich habe samtliche Howtos durch habe alle Hardware zum laufen
bekommen aber mit ISDN nach wievor Probleme, es lief 3 Tage dann ging
wieder nixmehr . Ich hatte mit DLD 5.2 angefangen dan Suse 6 un zu
letzt was am besten leif dann Redhat. nuja wie oben schon erwahnt
kommt das oben noch dazu sorry ich bleibe bei Windows das geht
wenigstens ! Wenn mir jemand Antworten schreiben mochte bitte via
E-Mail da ich diese NG abbestelle.
Gruss Heiko
E-Mail : my...@h-mayer.de
Hallo Heiko ,
schade , dass Du aufgegeben hast. Aber wenn Du mal den Kaufpreis von
WinTendo
und den Verdummungsfaktor durch diese Win-Crapware dazurechnest solltest
Du wohl
mit Linux immer noch besser kommen :-)
Ich verstehe Dich nicht, Du schreibst Du hast alles zum Laufen gekriegt
-
dies heisst also dass Du noch nicht durch Billy assimiliert wurdest
(Du gehörst also noch nicht zu denen für die eine Welt zusammenbricht
wenn ein Icon plötzlich eine anderes Aussehen hat *grins*)
Und gerade ISDN ist doch unter Linux so was feines , weil Du soviele
Möglichkeiten
in Sachen Logging / Anrufbeantworter / automatisches Anwählen im
Netzwerk mehr hast .
Mhh. Du hättest vielleicht nicht wild hin-und herwechseln sollen.
Jede Distri fährt seine eigene Schiene in Sachen Konfiguration. Wie
gesagt : schade
Wobei ich trotzdem nicht ganz verstehe dass etwas plötzlich nicht mehr
gehen soll
was vorher lief. Ich habe jedenfalls bisher nur unter Winspiel solche
Probleme bei
Bekannten gesehen. Es ist immer lustig anzuschauen wenn eine
Neuinstallation bevor-
steht nur weil irgendsoein sinnloses Sharewareprogramm irgendeine DLL
gelöscht hat
die keiner kennt geschweige denn wiederfindet.
In diesem Sinne (vielleicht ja doch noch)
Happy Linux,
Frank
PS: Es gibt auch viele andere User die vielleicht dieselben Probleme
haben wie Du,
hier bekommst Du kompetente Antworten zum Nulltarif . Schau mal zum
Vergleich
in die Winspiel-Newsgroups... (oder besser nicht)
>[...] wo ich keine Installationsorgien
>hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
>es lauft alles !
Also für mich persönlich ist das ein Grund, Linux zu benutzen. Man hat
nun mal volle Kontrolle über sein System, und muß nicht fürchten, Microsoft
überträgt bei der nächsten Online-Session die Kontodaten ;)
Außerdem kann ich nicht verstehen, wieso Linux eine "Installationsorgie"
benötigt. Meine erste Linux-Distribution, SuSE Linux 5.2, wurde einwandfrei
installiert und ich hatte keinerlei Probleme - trotz meiner damals geringen
Linux-Kenntnisse.
Wer Probleme bei der Konfiguration hat, kann nachfragen - zum Beispiel hier.
Dank mehrer Tips aus dieser Newsgroup funktioniert mein Internet-Zugang
unter Linux jetzt. Danke nochmal!
Ich hoffe niemanden stört mein langer Kommentar :)
Bis dann
René
Hi.
Heiko Mayer <my...@h-mayer.de> wrote:
> nach 8 Wochen Linux 150 DM Telefonrechnung 20 DM zum ausdrucken von
> verschiedenen Howtos hab ich Linux wieder von der Platte geschmissen.
..um es in ein paar Wochen wieder zu versuchen, weil einem Windows
mal wieder zu oft abgestuerzt ist.
> Man mag uber Windows schlecht reden nuja , aber es ist und bleibt
> derzeit eben eins der Betriebssysteme wo ich keine Installationsorgien
> hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
Das ist der Windows-Vorteil: DAU-sichere Installation - CD rein,
Setup startet automatisch.
> es lauft alles ! Nun wenn es in 3-4 Jahren noch Linux gibt, und es bis
Win laeuft mehr schlecht als recht.
Linux wird es in vier Jahren freilich noch geben, leistungsfaehiger
als je zuvor.
> PS: Ich habe samtliche Howtos durch habe alle Hardware zum laufen
> bekommen aber mit ISDN nach wievor Probleme, es lief 3 Tage dann ging
> wieder nixmehr . Ich hatte mit DLD 5.2 angefangen dan Suse 6 un zu
Problem?
> kommt das oben noch dazu sorry ich bleibe bei Windows das geht
> wenigstens ! Wenn mir jemand Antworten schreiben mochte bitte via
Und bei Teles fuer 70 Mark neue Treiber runterladen? Nee, danke.
> E-Mail da ich diese NG abbestelle.
Hier only.
Stefan
--
"Wir werden das Produkt dann auf den Markt bringen, wenn es so stabil
laeuft, wie es unsere Kunden erwarten." Microsoft-Sprecher Kurt Braatz
ueber Windows 2000 in einem Spiegel Online-Artikel vom 12. Maerz 1999.
http://www.freimark.de/index.html
> Moin,
>
> >[...] wo ich keine Installationsorgien
> >hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
> >es lauft alles !
>
> Also für mich persönlich ist das ein Grund, Linux zu benutzen. Man hat
> nun mal volle Kontrolle über sein System, und muß nicht fürchten, Microsoft
> überträgt bei der nächsten Online-Session die Kontodaten ;)
> Außerdem kann ich nicht verstehen, wieso Linux eine "Installationsorgie"
> benötigt. Meine erste Linux-Distribution, SuSE Linux 5.2, wurde einwandfrei
> installiert und ich hatte keinerlei Probleme - trotz meiner damals geringen
> Linux-Kenntnisse.
ISDN unter Linux ist wirklich nicht unbedingt trivial.
> Wer Probleme bei der Konfiguration hat, kann nachfragen - zum Beispiel hier.
> Dank mehrer Tips aus dieser Newsgroup funktioniert mein Internet-Zugang
> unter Linux jetzt. Danke nochmal!
Das hätte der Originalposter machen sollen (oder doch besser nicht ??)
Ciao
Racke
--
LinuXia - Solutions of Cool Competence - Internetprogramming and more
D-30163 Hannover, Waldstraße 4, 0511-393656 (http://www.linuxia.de/ dawns)
Come to the land of real computing where penguins and their friends
spreading the word of Open Source which crushes windows instantly.
ich will Dir zwar nichts einreden, aber versuche es doch noch einmal in
Ruhe. Diese Kaempfe haben wir alle hinter uns. Wenn dann alles laeuft,
wirst Du "linuxsuechtig", das kann ich Dir versprechen.
Gerade SuSE ist gut fuer den Einstieg geeignet! Nur muss man
das beiliegende Buch auch sehr genau lesen!
Ich nutze die Staerken von Linux gerade fuer
Internetanwendungen.
Und da moechte ich nieeeee wieder zu Wintendo wechseln!
Hier wird Dir geholfen!
Mathias
Heiko Mayer wrote:
> Hallo
>
> nach 8 Wochen Linux 150 DM Telefonrechnung 20 DM zum ausdrucken von
> verschiedenen Howtos hab ich Linux wieder von der Platte geschmissen.
> Man mag uber Windows schlecht reden nuja , aber es ist und bleibt
> derzeit eben eins der Betriebssysteme wo ich keine Installationsorgien
> hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
> es lauft alles ! Nun wenn es in 3-4 Jahren noch Linux gibt, und es bis
> dahin besser geworden ist werde ich es nocheinmal probieren.
> PS: Ich habe samtliche Howtos durch habe alle Hardware zum laufen
> bekommen aber mit ISDN nach wievor Probleme, es lief 3 Tage dann ging
> wieder nixmehr . Ich hatte mit DLD 5.2 angefangen dan Suse 6 un zu
> letzt was am besten leif dann Redhat. nuja wie oben schon erwahnt
> kommt das oben noch dazu sorry ich bleibe bei Windows das geht
> wenigstens ! Wenn mir jemand Antworten schreiben mochte bitte via
> E-Mail da ich diese NG abbestelle.
> Gruss Heiko
>
> E-Mail : my...@h-mayer.de
>> nach 8 Wochen Linux 150 DM Telefonrechnung 20 DM zum ausdrucken von
>> verschiedenen Howtos hab ich Linux wieder von der Platte geschmissen.
>> derzeit eben eins der Betriebssysteme wo ich keine Installationsorgien
>> PS: Ich habe samtliche Howtos durch habe alle Hardware zum laufen
>> bekommen aber mit ISDN nach wievor Probleme, es lief 3 Tage dann ging
>> wieder nixmehr . Ich hatte mit DLD 5.2 angefangen dan Suse 6 un zu
>> letzt was am besten leif dann Redhat. nuja wie oben schon erwahnt
>> kommt das oben noch dazu sorry ich bleibe bei Windows das geht
Tach,
Tja, wenn man innerhalb von 8 Wochen drei mal die Distri wechselt dann muss es
in die Hose gehen.
Installationsorgien ? Habe mein System vor 6 Monaten auf Linux umgestellt und
seitdem war keine Neuinstallation mehr noetig. Sich die howtos durchzulesen
reicht manchmal nicht - aber eben dann hilft das Usenet.
Ich habe unter WinXX unzaehlige Rohlinge geschrottet, alle 2 Monate war eine
Neuinstallation faellig, einige male Daten verloren und viel Zeit, weil
Multitasking unter WinXX ein Witz ist genauso wie die Datensicherheit.
Da Du es mit Linux zu nix gebracht hast aus welchen Grund auch immer, ist Dein
Subject absurd. Man kann doch keine Urteile ueber etwas faellen was man nicht kennt.
Gruss
Jerry
> >> nach 8 Wochen Linux 150 DM Telefonrechnung 20 DM zum ausdrucken
> >> von verschiedenen Howtos hab ich Linux wieder von der Platte
> >> geschmissen.
[...]
> >> PS: Ich habe samtliche Howtos durch habe alle Hardware zum laufen
> >> bekommen aber mit ISDN nach wievor Probleme, es lief 3 Tage dann
> >> ging wieder nixmehr . Ich hatte mit DLD 5.2 angefangen dan Suse 6
> >> un zu letzt was am besten leif dann Redhat. nuja wie oben schon
> >> erwahnt kommt das oben noch dazu sorry ich bleibe bei Windows das
> >> geht
> Tach,
> Tja, wenn man innerhalb von 8 Wochen drei mal die Distri wechselt
> dann muss es in die Hose gehen.
Na endlich, jetzt hat's auch bei mir geklingelt!
Freunde, das ist doch ein sonnenklarer Fall: wir sind mal wieder
gruendlich verar^H^Hschaukelt worden!
Erst als ich Jerrys Antwort oben las, wurde mir die Verdrehtheit des
urspruenglichen Schreibens klar: es geht gar nicht um Probleme mit
Linux!
Bitte einfach mal ganz langsam und gruendlich das Original-Posting
lesen und kurz darueber nachdenken...
Na, klingelt's jetzt auch bei Euch? :-)))
Vielleicht benoetigt diese Gruppe eine regelrechte Troll-Wache, um
solche Ulkies rechtzeitig zu erkennen ?
Da fragt sich man sich doch beinahe, ob die unter verschiedenem Namen
auftretenden Postings nicht am Ende zentral gesteuert werden, rein
/theoretisch/ denkbar waere es ja, oder? ;-)
Schoenen Gruss,
Karl-Heinz (privat unterwegs)
--
Bitte keine Antwort als E-Mail.
Ich lese die Newsgruppen, in die ich schreibe.
Zumindest diesen Absender gibt es. Ich war so frei,
ihm eine Mail zu schicken, mit der Bitte, sowas in
Zukunft nach *.windows.advocacy zu posten und
ein paar 'freundlichen' Bemerkungen zu solchen
Postings im Allgemeinen und seinem im Besonderen
und habe prompt eine ebenso 'freundliche' Antwort
erhalten :->
Rainer
--
The radio's playin' a sad song ..... bye bye, Baby
---------------- (Social Distortion) -------------
r...@another.de http://www.another.de
In einigen Tagen erhalte ich hoffentlich das bestellte Solaris 7. Wenn man
den Testberichten glauben kann, soll das ein System aus einem Guß sein und
nicht so eine Baustelle wie Linux.
Mein Modem funzt übrigens unter Linux auch nicht. Aber ich wundere mich
darüber nicht mehr. Das Netzwerk habe ich noch gar nicht angeworfen. Wollte
mir keinen Ärger einhandeln. Netscape läuft auch nicht rund. Irgendwo eine
Application x - haste nicht gesehen kann nicht geladen oder initialisiert
werden.
Außerdem sollten die Linuxbastler mal darüber nachdenken, die
Installationsroutine so zu verfeinern, daß im Verzeichnis /dev nur die
tatsächlich im System eingebauten Geräte auftauchen und nicht zwanzig
Terminals und 20 Harddisks usw.
Zur Zeit habe ich kein Linux laufen, und zum Glück hatte ich es eh auf einer
anderen Wechselplatte. Wenn ich mich voll auf Linux verlassen hätte, würde
ich nichts machen können, kein Internet, kein Staroffice kein Scanner
(apropo, den habe ich auch noch nicht eingebunden, aber so eine kleine
Steckkarte macht ja doch etwas Sorgen --))) ).
Genug gemeckert
Werde berichten, wie ich Solaris 7 finde.
Bis denne und gut byte
H. Schepker
www.schepker.de
Heiko Mayer <my...@h-mayer.de> schrieb in im Newsbeitrag:
36fa60c...@news.ecore.net...
> Hallo
>
> nach 8 Wochen Linux 150 DM Telefonrechnung 20 DM zum ausdrucken von
> verschiedenen Howtos hab ich Linux wieder von der Platte geschmissen.
> Man mag uber Windows schlecht reden nuja , aber es ist und bleibt
> derzeit eben eins der Betriebssysteme wo ich keine Installationsorgien
> hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
> es lauft alles ! Nun wenn es in 3-4 Jahren noch Linux gibt, und es bis
> dahin besser geworden ist werde ich es nocheinmal probieren.
> PS: Ich habe samtliche Howtos durch habe alle Hardware zum laufen
> bekommen aber mit ISDN nach wievor Probleme, es lief 3 Tage dann ging
> wieder nixmehr . Ich hatte mit DLD 5.2 angefangen dan Suse 6 un zu
> letzt was am besten leif dann Redhat. nuja wie oben schon erwahnt
> kommt das oben noch dazu sorry ich bleibe bei Windows das geht
Gruß
Günther
Wer sowas pauschal behauptet, hat sich wohl nur oberflächlich oder gar nicht
>mit Linux beschäftigt!
>Gruß
> Günther
Marcus
viel Glueck, Solaris unterstuetzt weit weniger Hardware als Linux!
> Mein Modem funzt übrigens unter Linux auch nicht. Aber ich wundere mich
> darüber nicht mehr.
Ich schon, ich koennte Dir einen ganzen Sack von Hardware nennen, die ich
unter Linux laufen habe, von der ich nie gedacht haette sie jemals unter
Linux zum laufen zu bringen.
Beispiele sind u.a. ein Speicheroszilloscop von Tektronix mit serieller
Schnmittstelle und eine PCMCIA Smart-media Card von einer Olympus
Digitalkamera. Dafuer hab ich noch nichtmal eigene Software schreiben
muessen.
> Außerdem sollten die Linuxbastler mal darüber nachdenken, die
> Installationsroutine so zu verfeinern, daß im Verzeichnis /dev nur die
> tatsächlich im System eingebauten Geräte auftauchen und nicht zwanzig
> Terminals und 20 Harddisks usw.
Devfs is on its way...
> Zur Zeit habe ich kein Linux laufen, und zum Glück hatte ich es eh auf einer
> anderen Wechselplatte.
ich hab seit 4 Jahren nichts anderes mehr laufen, sowohl dienstlich als auch
privat.
> Wenn ich mich voll auf Linux verlassen hätte, würde
> ich nichts machen können, kein Internet
~~~~~~~~~~~~~
Wie sich die Zeiten aendern! Anno 1994 konnte man mit Windows definitiv
keine vernuenftige Dialup IP-verbindung herstellen und heute lamentieren die
Leute rum mit Linux ginge das Nicht. Das Gegenteil ist der Fall, schon im
Jahr 1994 als ich mit Linux angefangen habe gang das ganz wunderbar.
BTW, ich diesem Beispiel steht man konnte keine vernuenftige Dialup
Verbindung herstellen definitiv fuer es ging nicht und nicht fuer ich bin zu
bloed es hinzukriegen.
Bye
Sven
--
.. this message has been created using an outdated OS (UNIX-like) with an
outdated mail- or newsreader (text-only) :-P
/me is giggls@IRC, http://geggus.net/sven/ on the Web
Man merkt, keine einzige man-page gelesen und keine Arbeit ins System
gesteckt... selbst schuld :)
>Außerdem sollten die Linuxbastler mal darüber nachdenken, die
>Installationsroutine so zu verfeinern, daß im Verzeichnis /dev nur die
>tatsächlich im System eingebauten Geräte auftauchen und nicht zwanzig
>Terminals und 20 Harddisks usw.
Wieso, stört Dich das ?. Dann sind die Devices wenigstens da, wenn man sie
braucht.
>Zur Zeit habe ich kein Linux laufen, und zum Glück hatte ich es eh auf einer
>anderen Wechselplatte. Wenn ich mich voll auf Linux verlassen hätte, würde
>ich nichts machen können, kein Internet, kein Staroffice kein Scanner
>(apropo, den habe ich auch noch nicht eingebunden, aber so eine kleine
>Steckkarte macht ja doch etwas Sorgen --))) ).
Kinners, Kinners, RTFM sag ich dazu. No risk, no fun.
>Genug gemeckert
>Werde berichten, wie ich Solaris 7 finde.
Sehr daran interessiert :)
>Bis denne und gut byte
Munter Bleiben !
Jürgen
--
*** Mal verliert man, mal gewinnen die anderen ;-)) ***
* Juergen Hunold *
* hun...@informatik.uni-hannover.de *
*** http://www-c.informatik.uni-hannover.de/~hunold ***
[...]
Was aber Du und die ganzen bitterlich Enttaeuschten wahrscheinlich
nicht nachfuehlen koennen, ist das Gefuehl echter Freudentraenen, wenn
Dir nach mehrtaegiger Bastelei und vielen Rueckschlaegen endlich ein
"Welcome to the POSTGRESQL interactive sql monitor"
entgegenblinkt, nachdem die Hoffnung eigentlich schon dahin war.
Klick-Klack-Is-Installed bietet dagegen nur ein sehr kurzes Vergnuegen.
So, das wollte ich mal loswerden.
Nein, ich nutze Linux weder professionell noch fuer sonst etwas
'Ernsthaftes', aber ich bin mittlerweile sicher, dass das, was ich
will, mit einigen Ausnahmen auch zu bekommen ist.
Sabine (meist an einem monochromen Textterminal sitzend)
>Ich kann es nachfühlen.
>Habe zwar nur einmal installiert, Red Hat 5.1, aber meine soundkarte wurde
>nicht erkannt. Erst durch irgendso ein isapnp tool wurde sie erkannt, aber
>sound habe ich immer noch nicht.
Howto gelesen? Kann doch nich so schwierig sein, sag uns einfach den Typ
der Karte und den Inhalt von /dev/sndstat.
>Außerdem habe ich Probleme beim mounten von ZIP-Laufwerk. Ich nehme zwar das
>vfat-dateisystem aber es erscheint so eine Fehlermeldung wie vfat nicht
Auch das steht im Howto. ZIPs sind partitioniert, fdisk -l
/dev/zip-device sagt dir auch wie.
>verfügbar oder so ähnlich. Muß man die Unterstützung für vfat explizit noch
>in den Kernel einbauen und wenn ja, wie wird das nicht automatisch gemacht
>bzw. über DLL's gelöst. Ich bin zwar nicht unbedarft in Sachen Hardware,
Schon mal was von Kernel-Modulen gehoert/gelesen? Steht doch schon fast
ueberall im Kernel-Setup.
Versuch mal "modprobe vfat" und kontroliere es mit lsmod.
>aber ich habe auch keine Lust, jedesmal im Rechner herumzukriechen um jedem
>einzelnen Byte persönlich "Guten Tag" zu sagen und zur Mitarbeit unter Linux
>zu überreden.
Das ist eigentlich vom Geschmack und Distri-Abhaengig. Die neuste Caldera
soll spitze sein (siehe c't, die am Montag rauskommt), oder easy-linux
(www.easy-linux.com). Damit kannst du auf die feinste Konfigurierbarkeit
zugunsten den Bequemlichkeit verzichten.
>In einigen Tagen erhalte ich hoffentlich das bestellte Solaris 7. Wenn man
>den Testberichten glauben kann, soll das ein System aus einem Guß sein und
>nicht so eine Baustelle wie Linux.
Das wuerde mich mal interessieren. Soll aber waehlerischer und langsammer
sein.
>Mein Modem funzt übrigens unter Linux auch nicht. Aber ich wundere mich
Kann ich mir nicht vorstellen. Ausser den win-modems sollte alles auf
Anhieb funtionieren.
>darüber nicht mehr. Das Netzwerk habe ich noch gar nicht angeworfen. Wollte
Sofern du die elementaren tcp/ip-Kentnisse hast, duerfte es ebenfalls
>mir keinen Ärger einhandeln. Netscape läuft auch nicht rund. Irgendwo eine
>Application x - haste nicht gesehen kann nicht geladen oder initialisiert
>werden.
Auf konkrette Fragen gibt es hier konkrette Antworten.
>Installationsroutine so zu verfeinern, daß im Verzeichnis /dev nur die
s. oben
>tatsächlich im System eingebauten Geräte auftauchen und nicht zwanzig
>Terminals und 20 Harddisks usw.
Was stoert dich daran? Sie belegen (fast) keinen Platz, Infos ueber
vorhadene Geraete findest du in /proc/ .
>Zur Zeit habe ich kein Linux laufen, und zum Glück hatte ich es eh auf einer
>anderen Wechselplatte. Wenn ich mich voll auf Linux verlassen hätte, würde
>ich nichts machen können, kein Internet, kein Staroffice kein Scanner
Stimmt, das hatte ich auch mal. Nach und nach verbrachte ich immer mehr
Zeit unter Linux, dann suchte ich nach passenden Loesungen, um die
Windows-Funktionalitaet zu ersetzen, wurde fuendig und brauchte seit dem
kein Windoof mehr.
>(apropo, den habe ich auch noch nicht eingebunden, aber so eine kleine
>Steckkarte macht ja doch etwas Sorgen --))) ).
Zufaellig ein Adaptec-Controller? 1505? Lief hier mal als 1520, ganz
brauchbar, wenn auch etwas CPU-lastig. Unter www.mostang.com/sane (oder
aehnlich) wirst du wahrscheinlich fuendig.
>Werde berichten, wie ich Solaris 7 finde.
Ja, mach das. Finde ich auch sehr interessant.
Eddie.
--
=========================================
Eduard Bloch
e...@ka.linux.de /* http://www.inka.de/~zombie/eb */
Zombie_ auf #linux.de, #inka.de
Before Xerox, five carbons were the maximum extension of anybody's ego.
> Ich kann es nachfühlen.
> Habe zwar nur einmal installiert, Red Hat 5.1, aber meine soundkarte wurde
> nicht erkannt. Erst durch irgendso ein isapnp tool wurde sie erkannt, aber
> sound habe ich immer noch nicht.
> Außerdem habe ich Probleme beim mounten von ZIP-Laufwerk. Ich nehme zwar das
> vfat-dateisystem aber es erscheint so eine Fehlermeldung wie vfat nicht
> verfügbar oder so ähnlich. Muß man die Unterstützung für vfat explizit noch
> in den Kernel einbauen und wenn ja, wie wird das nicht automatisch gemacht
> bzw. über DLL's gelöst. Ich bin zwar nicht unbedarft in Sachen Hardware,
> aber ich habe auch keine Lust, jedesmal im Rechner herumzukriechen um jedem
> einzelnen Byte persönlich "Guten Tag" zu sagen und zur Mitarbeit unter Linux
> zu überreden.
>
Weshalb dann UNIX? Für solche User gibt es doch einen
Betriebssystemhesteller, dem es duch zahlreiche (faule) Tricks
gelingt, so gut wie alle PC-Hardware durch autoprobing (wehe, wenns
mal schiefgeht...) und Klicken zum Laufen zu bringen.
> In einigen Tagen erhalte ich hoffentlich das bestellte Solaris 7. Wenn man
> den Testberichten glauben kann, soll das ein System aus einem Guß sein und
> nicht so eine Baustelle wie Linux.
>
Dann viel Spaß damit.
Meine inzwischen zehnjährigen UNIX-Erfahrungen haben mich folgendes
gelehrt:
Die proprietären Unixe (SUN-OS HP-UX IBM-AIX und wie sie alle heißen)
unterstützen jeweils SUN-Hardware, HP-Hardware IBM-Hardware und nichts
anderes ... keine Kunst!
PC-UNIXE (SCO, Solaris ...) unterstützen gängige PC-Hardware, sofern
sie älter als drei Jahre ist, nicht für Spiele taugt und nicht von
Compaq stammt (PNP-Sound - viel Spaß).
> Mein Modem funzt übrigens unter Linux auch nicht. Aber ich wundere mich
> darüber nicht mehr. Das Netzwerk habe ich noch gar nicht angeworfen. Wollte
> mir keinen Ärger einhandeln. Netscape läuft auch nicht rund. Irgendwo eine
> Application x - haste nicht gesehen kann nicht geladen oder initialisiert
> werden.
>
> Außerdem sollten die Linuxbastler mal darüber nachdenken, die
> Installationsroutine so zu verfeinern, daß im Verzeichnis /dev nur die
> tatsächlich im System eingebauten Geräte auftauchen und nicht zwanzig
> Terminals und 20 Harddisks usw.
>
> Zur Zeit habe ich kein Linux laufen, und zum Glück hatte ich es eh auf einer
> anderen Wechselplatte. Wenn ich mich voll auf Linux verlassen hätte, würde
> ich nichts machen können, kein Internet, kein Staroffice kein Scanner
Mit Linux stehen IMHO die Chancen, neuere oder exotische Hardware zum
zu integrieren, erheblich besser als mit jedem kommerziellen PC-UNIX.
Der Soucecode ist offen und irgenjemand auf der großen weiten Welt mit
wesentlich mehr Erfahrung als man selbst hat meist schon einen Treiber
dafür programmiert, den man nur finden muß. Auf diese Art habe
ich bisher jede Hardware die ich brauche (evtl. nach ein paar Nächten
Internet-Suche und Konfigurationsorgien) zum Laufen gebracht.
Wer allerdings an Linux mit einer 'einstecken und geht, sonst beschwer
ich mich bei meinem Händler'-Mentalität herangeht, wird nicht viel
Freude damit haben. Dafür gibt's ja wie gesagt andere
sog. Betriebssysteme, aber wir wollen in diesem anspruchsvollen Thread
doch nicht in die DAU-Diskussion abgleiten.
> (apropo, den habe ich auch noch nicht eingebunden, aber so eine kleine
> Steckkarte macht ja doch etwas Sorgen --))) ).
Vergiß es und kauf dir eine billige SCSI-Karte für das Teil :-)
UNIX rules!
Gruß Wolfhard
--
Wolfhard Strähle E-Mail: wo...@esslingen.netsurf.de
Denkendorfer Straße 25 Tel.: (049)-0711/3482825
D-73760 Ostfildern
Ja. Aber wenn man einigermaßen Überblick über das System gewonnen hat,
gehen einem die Eigenheiten der SuSE doch ziemlich auf den Trichter. Da
finde ich es dann doch besser, direkt RedHat oder gar Debian zu nehmen.
Zwar ist dort die Lernkurve bestimmt einwenig steiler, dafür passt dann
später mehr. Mir gings jedenfalls so.
Alexander Skwar
--
My Site : http://www.digitalprojects.com
Schön. Und ? Dann geh doch. Niemand hält Dich auf. Glaubst Du, mit so
einer Einstellung erreichst Du hier irgendwas ?
Ich sage nur, Bielefeld.
Linux erkennt nichts. Und das ist gut so. Schon mal bei Win98 ohne oder
mit einem anderen Monitor gebootet? Was glaubst du, wieviel Freude man
mit solch einem 'schlauen', 'erkennenden' System hat. Das ist (auch weil
nie fehlerfrei) einfach nur nervige Bevormundung.
Linux benutzt die Geräte, die man ihm anhand von Definitionen vorsetzt.
Einen kleinen Teil erkennt es sogar selbst (angeschlossene Platten),
aber ies benutzt nur, was du definierst. Und das ist gut so. Würde Linux
auch nur *ein einziges Mal* eine von mir erstellte Konfiguration löschen
oder eigenmächtig ändern, nur weil ich einmal ohne Modem oder Bildschirm
oder Maus oder sonstwas gebootet habe, wäre es weg vom Fenster.
*patch*
Du hast das Wort erwähnt. SIE beobachten Dich jetzt.
nikolaus
Wenn wir uns das ganze mal von einer anderen Perspektive aus anschauen, stellen
wir fest, daß die betreffende Person hier einen verzweifelten Hilfe-Schrei
abgesetzt hat, nur leider nicht in der Verfassung war, diese direkt und
offen zuzugeben. Sie sucht nun nach einem Anhaltspunkt, der ihr nun hilft an
dem eingeschlagen Weg zur Erlösung aus der Machenschaft eines Tyrannen
festzuhalten.
Heiko, Du warst auf dem richtigen Weg. Der kurze Schwächeanfall und der
Augenblick des Zweifelns wird Dir verziehen. Es ist noch nicht zu spät, um
weiterzumachen.
nikolaus Freud^H^H^H^Hilus
> Wie sich die Zeiten aendern! Anno 1994 konnte man mit Windows definitiv
> keine vernuenftige Dialup IP-verbindung herstellen und heute lamentieren die
>
> BTW, ich diesem Beispiel steht man konnte keine vernuenftige Dialup
> Verbindung herstellen definitiv fuer es ging nicht und nicht fuer ich bin zu
> bloed es hinzukriegen.
Wieso habe ich das denn dann 1994 hinbekommen? Win 3.1, Trumpet, div.
Clients, per Dialup über Modem, ein Jahr später mit der ISDN Karte. Das
ging.
HS> From: "Hajo Schepker" <sche...@geocities.com>
HS> Ich kann es nachfühlen.
????
[...]
HS> Außerdem habe ich Probleme beim mounten von ZIP-Laufwerk. Ich
HS> nehme zwar das
HS> vfat-dateisystem aber es erscheint so eine Fehlermeldung wie
HS> vfat nicht
HS> verfügbar oder so ähnlich. Muß man die Unterstützung für vfat
HS> explizit noch
HS> in den Kernel einbauen und wenn ja, wie wird das nicht
da werden entweder Module fuer installiert, oder aber du kompilierst dir den
Kernel passend fuer _deine_ Hardware neu
HS> automatisch gemacht
HS> bzw. über DLL's gelöst. Ich bin zwar nicht unbedarft in Sachen
HS> Hardware,
des Lesens scheinst du aber nicht maechtig zu sein
[...]
HS> In einigen Tagen erhalte ich hoffentlich das bestellte Solaris
HS> 7. Wenn man
HS> den Testberichten glauben kann, soll das ein System aus einem
HS> Guß sein und
HS> nicht so eine Baustelle wie Linux.
Ein Linux kriegste nicht ans Laufen , aber ein Solaris .......... , dass ist
dann entweder fuer teures Geld schon installiert oder du kriegst das auch nicht
ans laufen.
HS> Mein Modem funzt übrigens unter Linux auch nicht. Aber ich
Eine Autoerkennung wie bei Windows ist noch nicht dabei, aber wenn man die
richtige Schnittstelle angibt sollte man jedes vernuenftige Modem (keine Win-
Modems) zum laufen bekommen
HS> wundere mich
HS> darüber nicht mehr. Das Netzwerk habe ich noch gar nicht
HS> angeworfen. Wollte
HS> mir keinen Ärger einhandeln. Netscape läuft auch nicht rund.
du hast kein Netzwerk angeworfen und wunderst dich dann, dass Netscape nicht
laeuft !?
[...]
HS> Außerdem sollten die Linuxbastler mal darüber nachdenken, die
HS> Installationsroutine so zu verfeinern, daß im Verzeichnis /dev
HS> nur die
HS> tatsächlich im System eingebauten Geräte auftauchen und nicht
HS> zwanzig
HS> Terminals und 20 Harddisks usw.
du hast das System nicht verstanden
HS> Zur Zeit habe ich kein Linux laufen, und zum Glück hatte ich es
HS> eh auf einer
HS> anderen Wechselplatte. Wenn ich mich voll auf Linux verlassen
HS> hätte, würde
HS> ich nichts machen können, kein Internet, kein Staroffice kein
<laut lachend> Linux ist das Internet BS ueberhaupt, und eine pppd-Verbindung
sollte jeder hinbekommenm, ach ich vergass dein Modem, dann kanns natuerlich
nicht gehen.
HS> Genug gemeckert
HS> Werde berichten, wie ich Solaris 7 finde.
wir sind gespannt wie du die Soundkarte unter Solaris ans laufen bekommst, aber
mir scheint, ein Win31 waere fuer dich besser.
ciao Peter
eMail : pe...@hippo.fido.de peter.m...@okay.net
FidoNet : 2:2452/110.20
WWW : http://www.fido.de/~pema/
Mailinglist for FEddy/LXPoint at fe...@fido.de
"SUBSCRIBE feddy" send to majo...@fido.de
Ich habe mir zu meiner Olympus einen Adapter gekauft,
mit dem man die Smart-media im Floppy Laufwerk lesen kann
(mit Win Software).
Weiss wer, ob und ggf. wie man so etwas auch unter Linux zum Lafuen bringen kann?
Helmut
--
Sven Geggus wrote:
>
> Ich schon, ich koennte Dir einen ganzen Sack von Hardware nennen, die ich
> unter Linux laufen habe, von der ich nie gedacht haette sie jemals unter
> Linux zum laufen zu bringen.
>
> Beispiele sind u.a. ein Speicheroszilloscop von Tektronix mit serieller
> Schnmittstelle und eine PCMCIA Smart-media Card von einer Olympus
> Digitalkamera. Dafuer hab ich noch nichtmal eigene Software schreiben
> muessen.
hast du deine Erfahrungen mit dem "Sack voll Harware" irgendwo
veröffentlicht?
Wäre für den einen oder anderen vielleicht ganz interessant.
Bye
B.
Okay, vielleicht bis du der Profi, der mir bisher gefehlt hat :-))
Mein modem funtzt, wvdial wählt, stellt verbindung her, scheint so, als ob
angemeldet (per PAP)
Es steht da pppd started ....<datum etc.>
und nichts weiter, ifconfig meldet mir loopback und ppp, bei route ist
auch eine neue ip hinzugekommen, jedoch kann ich keinerlei Web-Seiten
aufrufen (per Netscape bzw. anderen Browsern).
Liegt es daran, daß ich ein Loopback als Netzwerk installiert habe (als
Protokol TCP/IP)??
Oder was läuft da nun wieder falsch, dejanews und die manpages haben mir
nicht helfen können, währe dir sehr dankbar, wenn du mir sagen könnteste,
wie da nun geht.
> ciao Peter
bye, Sascha
Netscape ist nicht gerade das richtige Tool, um das Netzwerk zu testen.
Ein paar einfachere Sachen zuerst:
ping 127.0.0.1 (Abbruch mit CTRL-C)
testet local loopback.
ping 134.76.11.100
testet, ob ein Recher ausserhalb erreicht werden kann.
ping ftp.gwdg.de
testet, ob ftp.gwdg.de zu einer IP-Adresse aufgeloest wird. (nameserving)
Poste mal die Ergebnisse, inklusive der Ausgaben von
/sbin/ifconfig
und
/sbin/route -n
Der Nameserver wird in der /etc/resolv.conf eingetragen.
bye,
Chris
--
Christian Perle E-mail: christi...@tu-clausthal.de
Am Galgensberg 4 WWW: http://home.tu-clausthal.de/~incp/
38678 Clausthal/Germany ComputerGuitarKitesBicyclesBeerPizzaRaytracing
> Ja. Aber wenn man einigermaßen Überblick über das System gewonnen hat,
> gehen einem die Eigenheiten der SuSE doch ziemlich auf den Trichter. Da
> finde ich es dann doch besser, direkt RedHat oder gar Debian zu nehmen.
> Zwar ist dort die Lernkurve bestimmt einwenig steiler, dafür passt dann
> später mehr. Mir gings jedenfalls so.
Die *echte* Herausforderung ist doch, die SuSE-Eigenheiten
auszutricksen. ;-)
--
************************************************************************
Julian Einwag - Herm-Loens-Str.9 - 96106 Ebern - wjei...@swin.baynet.de
Private homepage: http://www.swin.baynet.de/user/amon+einwag/
***** Send mail request for PGP key ************************************
> Okay, vielleicht bis du der Profi, der mir bisher gefehlt hat :-))
> Mein modem funtzt, wvdial wählt, stellt verbindung her, scheint so, als ob
> angemeldet (per PAP)
> Es steht da pppd started ....<datum etc.>
> und nichts weiter, ifconfig meldet mir loopback und ppp, bei route ist
> auch eine neue ip hinzugekommen, jedoch kann ich keinerlei Web-Seiten
> aufrufen (per Netscape bzw. anderen Browsern).
> Liegt es daran, daß ich ein Loopback als Netzwerk installiert habe (als
> Protokol TCP/IP)??
> Oder was läuft da nun wieder falsch, dejanews und die manpages haben mir
> nicht helfen können, währe dir sehr dankbar, wenn du mir sagen könnteste,
> wie da nun geht.
Nun, der Profi bin _ich _ vielleicht nicht, aber waere es moeglich, dass
das System nicht in der Lage ist, Namen aufzuloesen? Geht ein "ping" an
eine bestimmte IP-Adresse? Wenn ja, solltest Du Dir vielleicht mal
/etc/resolv.conf oder so anschauen ;-).
Gruss Thomas
--
* Thomas Gerisch *
* Johannes-Gutenberg-Universitaet Mainz *
* geri...@mail.uni-mainz.de *
>Es steht da pppd started ....<datum etc.>
>und nichts weiter, ifconfig meldet mir loopback und ppp, bei route ist
>auch eine neue ip hinzugekommen, jedoch kann ich keinerlei Web-Seiten
>aufrufen (per Netscape bzw. anderen Browsern).
Ja hast du denn einen DNS-Server eingetragen? Ohne den werden keine Namen
aufgelöst. Trag also den DNS-Server deines Providers in /etc/resolv.conf
(man resolv.conf). Oder mach mit yast oder wie auch immer dein
config-tool heisst.
>Liegt es daran, daß ich ein Loopback als Netzwerk installiert habe (als
>Protokol TCP/IP)??
Nein, das kann/soll bleiben.
>Oder was läuft da nun wieder falsch, dejanews und die manpages haben mir
>nicht helfen können, währe dir sehr dankbar, wenn du mir sagen könnteste,
>wie da nun geht.
Doch, DE-ISP-Verbindung-HOWTO.html haette dich weitergebracht.
mfG
Eddie.
--
=========================================
Eduard Bloch
e...@ka.linux.de /* http://www.inka.de/~zombie/eb */
Zombie_ auf #linux.de, #inka.de
Liar, n.:
A lawyer with a roving commission.
-- Ambrose Bierce, "The Devil's Dictionary"
Ciao, Stefan
Am Fri, 26 Mar 1999 06:50:51 +0100 schrieb Mathias Lorenz
<m.lo...@alcatel.de> in <36FB203B...@alcatel.de>:
>X-Mailer: Mozilla 4.5 [en] (WinNT; I)
^^^^^
>Und da moechte ich nieeeee wieder zu Wintendo wechseln!
Ahhh ja.... ;-)
Tschüß und Gruß von der Wieseck,
Dirk
--
Dirk Janßen | Fon: +49 (0)641 9502070 | PGP-Key available
Gießen, Germany | Fax: +49 (0)641 9502071 | at d...@gmx.de
Jupp, hab ich, als DNS ist 195.50.140.126 eingetragen, funtzt aber immer
noch nicht, nur der zugriff auf IP Nummer mit ping geht, aber bei z.B.
www.suse.de passiert eine ganze Weile lang nichts, und dann kommt Host
unknown.
> Nein, das kann/soll bleiben.
Dachte ich mir auch so.
> Doch, DE-ISP-Verbindung-HOWTO.html haette dich weitergebracht.
Hab ich inzw. durch, aber funtzt immernoch nicht :((
bye, Sascha
Ich weiss nicht ob's schon jemand gesagt hat(habe den Anfang des threads
nicht), aber ist in der Argumentenliste des pppd-Aufrufs 'defaultroute'
dabei? Wenn nicht, schreib's mal dazu.
hth
Martin
>Jupp, hab ich, als DNS ist 195.50.140.126 eingetragen, funtzt aber immer
>noch nicht, nur der zugriff auf IP Nummer mit ping geht, aber bei z.B.
>www.suse.de passiert eine ganze Weile lang nichts, und dann kommt Host
>unknown.
Gibt es doch gar nicht. Vielleicht fällt bind in der hosts.conf.
---/etc/resolv.conf---
nameserver 194.97.109.1
#nameserver 62.104.196.134
---
---/etc/host.conf---
order hosts,bind
----
Eddie.
--
=========================================
Eduard Bloch
e...@ka.linux.de /* http://www.inka.de/~zombie/eb */
Zombie_ auf #linux.de, #inka.de
Why is it that we rejoice at a birth and grieve at a funeral? It is because we
are not the person involved.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Nagut, dann darfst Du mich von nun an Waschlappen nennen. Aber nur Du,
da Du so hellsichtig warst :-))
Ja, ist drin, geht aber immernoch nicht :((
> hth
> Martin
bye, Sascha
Ist alles eingetragen gewesen, ich verstehe daß ganze nicht :((
bye, Sascha
Am 27 Mar 99 hast Du All folgendes geschrieben:
"S> wurde nicht erkannt. Erst durch irgendso ein isapnp tool wurde sie
"S> erkannt, aber sound habe ich immer noch nicht.
Soundunterstuetzung gehoert mittels Kernelsource einkompiliert oder als
Kernelmodul kompiliert. Auch bei RH bekommt man wohl keim Kernel die alles
unterstuetzen was am Markt ist.
"S> nicht verfuegbar oder so aehnlich. MuB man die Unterstuetzung fuer vfat
"S> explizit noch in den Kernel einbauen und wenn ja, wie wird das nicht
"S> automatisch gemacht bzw. ueber DLL's geloest. Ich bin zwar nicht
Das Konzept des Kompilierens eigener Kernel ist eigentlich ein genialer
Punkt der einem erst spaeter bewusst wird. Statt eines Betriebssystems das
ab Rechnerstart 50MB Ram zumacht weil es alles einlaedt das in Verlauf von
Jahren eventuell mal angeschlossen wird, baut man einen Kernel der fuer
Basisfunktionen nur enthaelt was man wirklich braucht.
"S> im Rechner herumzukriechen um jedem einzelnen Byte persoenlich "Guten
"S> Tag" zu sagen und zur Mitarbeit unter Linux zu ueberreden.
Das liegt leider an dem Grundsatz "Verwende keine proprietaere
Windowshardware unter Linux".
"S> Mein Modem funzt uebrigens unter Linux auch nicht. Aber ich wundere mich
Support fuer die serielle ist eigentlich in jedem Kernel, spaetestens mit
Minicom muesste man das Modem erreichen koennen, es sei denn es handelt
sich um ein "Winmodem".
"S> haette, wuerde ich nichts machen koennen, kein Internet, kein Staroffice
"S> kein Scanner (apropo, den habe ich auch noch nicht eingebunden, aber so
"S> eine kleine Steckkarte macht ja doch etwas Sorgen --))) ).
Es dauert ein Linuxsystem von Grund auf zu gestalten, ohne Uebertreibungen
kann ich sagen das es Monate dauern kann bis alle Punkte realisiert sind.
Aber man erhaelt dann etwas von Dauerstabilitaet das in bestimmten
Bereichen bestens laeuft.
"S> Genug gemeckert
Da wirst Du von den Fetischisten hier aber ganz boese Texte kriegen denn
die koennen ein Komplettsystem mit 0 Fehlern in 10 Minuten aufbauen......
Am 29 Mar 99 hast Du All folgendes geschrieben:
HM> Linux erkennt nichts. Und das ist gut so. Schon mal bei Win98 ohne oder
HM> mit einem anderen Monitor gebootet? Was glaubst du, wieviel Freude man
Nach Umstellung auf Sommerzeit hat Win hier die Systemzeit um einen
erhoeht, die war per Timeservice schon durch Linux korrigiert worden. Naja
und die Bildwiederholfrequenz auch auf 60Hz gesenkt weil nach Meinung von
Bill Gates das wohl fuer den Sommer ausreichend ist:-/
Da aendere ich doch lieber die XF86Config und setze dort Werte die dann
gueltig sind.
HM> Linux auch nur *ein einziges Mal* eine von mir erstellte Konfiguration
HM> loeschen oder eigenmaechtig aendern, nur weil ich einmal ohne Modem oder
Dann huete dich vor dem IceWM!!!!!!!!!
>Hallo Heiko,
>
>ich will Dir zwar nichts einreden, aber versuche es doch noch einmal in
>Ruhe. Diese Kaempfe haben wir alle hinter uns. Wenn dann alles laeuft,
>wirst Du "linuxsuechtig", das kann ich Dir versprechen.
> Gerade SuSE ist gut fuer den Einstieg geeignet! Nur muss man
>das beiliegende Buch auch sehr genau lesen!
> Ich nutze die Staerken von Linux gerade fuer
>Internetanwendungen.
>Und da moechte ich nieeeee wieder zu Wintendo wechseln!
>
also ich finde Wintendo ist geradezu eine beleidigung fuer nintendo,
denn deren betriebssysteme tun wenigstens im gegensatz zu windows was
sie sollen,: naemlich spiele laufen lassen.
Alex
***************************************************
DI Alexander Schatten
email: Alexande...@bigfoot.com
URL: http://www.bigfoot.com/~AlexanderSchatten
***************************************************
SW> From: sas...@tmb.in-berlin.de (Sascha Weis)
>> <laut lachend> Linux ist das Internet BS ueberhaupt, und eine
>> pppd-Verbindung sollte jeder hinbekommenm, ach ich vergass
>> dein Modem, dann kanns natuerlich nicht gehen.
SW> Okay, vielleicht bis du der Profi, der mir bisher gefehlt hat :-
SW> ))
ich bin kein Profi, aber ich komme aus dem Fido-Net und haette deine Mail fast
uebersehen, da an ALL gerichtet
SW> Mein modem funtzt, wvdial wählt, stellt verbindung her, scheint
du widersprichst dir ???
SW> so, als ob
SW> angemeldet (per PAP)
SW> Es steht da pppd started ....<datum etc.>
SW> und nichts weiter, ifconfig meldet mir loopback und ppp, bei
SW> route ist
SW> auch eine neue ip hinzugekommen, jedoch kann ich keinerlei Web-
wo ist die route hinzugekommen, auf welchem Device ?
SW> Seiten
SW> aufrufen (per Netscape bzw. anderen Browsern).
ist es eine Default-Route ? Ist die richtig, d.h. mit dem DNS deines IP
eingetragen ?
SW> Liegt es daran, daß ich ein Loopback als Netzwerk installiert
SW> habe (als
SW> Protokol TCP/IP)??
noe, solange du ein Netzwerk fuer ppp0 und sofern vorhanden eth0 hast
SW> Oder was läuft da nun wieder falsch, dejanews und die manpages
SW> haben mir
SW> nicht helfen können, währe dir sehr dankbar, wenn du mir sagen
SW> könnteste,
SW> wie da nun geht.
ich habe jetzt (da etwas spaet) keine Lust den ganzen Thread
zurueckzublaettern, aber lese mal DE-ISP-Verbindung.txt im Howto-Verezichnis
und schaue mal in /var/log/messages, da findest du vieleicht die Gruende warum
es nicht funktioniert
Bin Linux-Liebhaber und mag Microsoft nicht; hab auch von Microsoft lediglich
WIN 95 C (noch).
An Win mag ich weder den Registry-Krampf noch die anderen Schwächen.
Aber trotzdem versteh ich obiges nicht.
Mein Win 95 läuft ziemlich problemlos; ich weiß gar nicht wovon oben gesprochen
wird.
Meinen Reset-Schalter hab ich schon lange nicht mehr benutzt. Hab zwar schon mal
den BLUE SCREEN gesehen, kann mich aber nicht mehr daran erinnern wann das war.
Und ich installiere durchaus öfter mal Programme zu Testzwecken.
An Linux gefällt mir die Linux-Philosophie besser. Ausserdem: Bei Linux weiß ich
wenigsten was ich tu.
Bei Win weiß ich nicht was sich wo reinsetzt und was welche Auswirkungen hat.
Ausserdem ist Bill Gates meiner Meinung nach reich genug.
Weg mit W; her mit LINUX. LINUX vor all (die genügend Ahnung haben).
:-)
Mick
_____________________________________________________________
NewsGroups Suchen, lesen, schreiben mit http://netnews.web.de
> Ich muss zugeben, bei mir ist Windows 95 noch nie abgestürzt, auch NT4
Die beiden sind bei mir zu Hause auch noch nie abgestuerzt. Dazu hatten
sie keine Gelegenheit, ich hab sie gar nicht erst auf die Platte
gelassen;-) Ich hatte vom 3.1 so die Schnauze voll... Es reicht, wenn
ich bei der Arbeit mit NT arbeiten muss.
> > Ausserdem ist Bill Gates meiner Meinung nach reich genug.
>
> Ich finde es aber echt nett von ihm, das er 1.5 Millionen für ein
> Flüchtlingshilfwerk in Jugoslawien gespendet hat. Aber seine Interviews...¨
Das sind grad mal 0.018 Promille seines Vermoegens. Arme Albanische
Familien geben alles her was sie besitzen fuer die Fluechtlinge und
nehmen sie noch bei sich auf. Wer ist grosszuegiger?
Fuer Bill Gates war das ein sehr billiger Propagandatrick um sein
Egoistenimage zu verschoenern. Gekostet hat es ihn relativ nicht mehr
als unsereins ein Kaugummi.
> Er weicht den Fragen immer aus.
Was soll er denn sonst tun, wenn er keine Argumente hat?
> > Weg mit W; her mit LINUX. LINUX vor all (die genügend Ahnung haben).
>
> Genau! Pinguine an die Macht!
Kampf den eNTen!
Stefan
>Thomas Bader <hans-rud...@smile.ch> wrote:
>Bin Linux-Liebhaber und mag Microsoft nicht; hab auch von Microsoft lediglich
>WIN 95 C (noch).
>An Win mag ich weder den Registry-Krampf noch die anderen Schwächen.
So 'Krampf' ist die Registry garnicht. Wenn die das Teil mal vernünftig
dokumentiert, strikte Regeln festgelegt und auch noch ein !vernünftiges!
Tool zum bearbeiten bereitgestellt hätten, wäre das Prinzip super.
Immerhin hat es doch den gewaltigen Vorteil, das man nicht durch 2Mio
Konfigurationsdateien in 500000 Verzeichnissen Navigieren muß (ging in
keiner Weise gegen Linux ;)
Allerdings verwirklicht M$ immer mehr das Prinzip, die User zu
entmündigen (Bill braucht ja noch einige Milliarden)...
Es wäre doch genial, wenn man ein System hätte, das auf Anhieb, ohne
großen Konfigurationsaufwand in einer Standardkonfiguration stabil
läuft, aber einem trotzdem !jede! Möglichkeit offenhält, es nach seinen
eigenen Wünschen anzupassen, WinLin sozusagen ;)
>:-)
>Mick
bye sAm
Konfigurationsdateien für Anwendungspakete gehören in das Verzeichnis
des Anwendungspakets (benutzerspezifische in Benutzerverzeichnisse). Es
muss für die Installations eines Anwendungspakets reichen, dass der
Verzeichnisbaum gespiegelt wird. Bei der Registry-Krankheit muss dann
immer noch mit einem Fummelprogramm (schimpft sich Netzwerkistallation)
in der Registry rumgepfriemelt werden. Das ist für Billys
Lizenzierungskram gut, ansonsten ist es Müll.
Abgesehen von der kranken Idee ist die Registry auch noch mies
implementiert: sie muss beim Systemstart in den Speicher geladen werden
(IMHO). Daher kommen auch die ständigen Aufforderungen zum Neustart.
> Konfigurationsdateien für Anwendungspakete gehören in das Verzeichnis
> des Anwendungspakets (benutzerspezifische in Benutzerverzeichnisse). Es
> muss für die Installations eines Anwendungspakets reichen, dass der
> Verzeichnisbaum gespiegelt wird.
Hm. Wie sieht das aus, wenn das Anwendungspaket per NFS o.ä. an 200
(vielleicht gar plattenlose?) Clients exportiert wird, wobei
verschiedene Clients jeweils eine andere Konfiguration brauchen?
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
The obvious mathematical breakthrough [for breaking modern encryption] would
be the development of an easy way to factor large prime numbers.
-- Bill Gates, *The Road Ahead*
Dann kann immer noch eine per/client Konfiguration zentral über NFS
bereitgestellt werden. Aber hast Du schon mal unter Windows versucht
eine neue Version von Windows zu installieren (ohne Upgrade) unter
Beibehaltung all
Deiner Einstellungen der Applikationen oder auch nur unter Beibehaltung
der Lauffähigkeit der Applikation? Da schiesst die zentrale Regisry
ziemlich quer. Spassig ist es auch eine Applikation von ihrem
Installtionsverzeichnis in ein anderes zu verschieben (wohlgemerkt ohne
alles neu installieren zu muessen).
Sind Anwendung und Betriebssystem jedoch voneinander getrennt, wie man
das unter Unix einrichten kann (und sollte), ist das kein Problem.
Ein anderes Beispiel:
Such mal ALLE die Eintrage, die eine
Applikation in der Registry macht. Viel Glück.....
Keine Frage einige findet man schnell, aber wer weiss schon wo überall
die Applikation in die Registry geschrieben hat. Da bleibt dann nur der
vorher/nachher Vergleich. Dafür braucht man schon wieder spezielle Tools
und es ist einfach viel Aufwand. Mehrstufige
Ressourcen Konzepte, wie sie unter Unix üblich sind machen hier deutlich
weniger Arbeit.
Gruss Rainer
--
---------------------------------------------------------------------
Rainer Krienke kri...@uni-koblenz.de
Universitaet Koblenz, http://www.uni-koblenz.de/~krienke
Rechenzentrum, Voice: +49 261 287 - 1312
Rheinau 1, 56075 Koblenz, Germany Fax: +49 261 287 - 1355
---------------------------------------------------------------------
> So 'Krampf' ist die Registry garnicht. Wenn die das Teil mal vernünftig
> dokumentiert, strikte Regeln festgelegt und auch noch ein !vernünftiges!
> Tool zum bearbeiten bereitgestellt hätten, wäre das Prinzip super.
Dieses Regelwerk hat einen gigantischen Umfang a la
{AB0089-C00F4421-EEE-4567598-99DE0EE} Value=true - NumLock an
{C77300-FFF00314-000-0000000-0000000} Value=2 - 2. Absturz heute
87682164 weitere solche Zeilen
> Immerhin hat es doch den gewaltigen Vorteil, das man nicht durch 2Mio
> Konfigurationsdateien in 500000 Verzeichnissen Navigieren muß (ging in
> keiner Weise gegen Linux ;)
Was ist daran Vorteilhaft? Wenn unter Linux eine Config-Datei geschrottet
wird, geht wenigstens noch alles andere. Ist die Registry am A...
(Abend kaputt gegangen), geht halt nix mehr (selbst erlebt, da half
kein ERU noch ein zu Rate gezogener Fachmann).
Manne
--
-------------------------------------
May music save your mortal soul...
http://private.freepage.de/mallorno/
-------------------------------------
Dann gilt der Teil in Klammern:
>> derzeit eben eins der Betriebssysteme wo ich keine Installationsorgien
>> hinlegen muss keine isapnptools etc und sonstigen Kram brauche, nein
>> es lauft alles !
>
>Bist du dir da so sicher? Klar, unter Windows hat man alles in einer
>halben Stunde installiert, doch das nützt einem ja nichts, wenn es dafür
>im Minutentakt abstürzt.
Komisch - ich hab' letztens eine SuSE-Evaluation 6.0 in 'ner halben Stunde
installiert - incl. Netzanbindung. Fuer ppp und lpr war dann allerdings
doch noch 'n neuer Kernel faellig. Die Kiste laeuft seitdem (dem ersten
Booten von Disk fuer die Installation) seit 1 Monat ununterbrochen und
muss sich einiges von mir gefallen lassen ...
Tschau, Volker
--
Volker Mueller,volker....@gmx.de,http://www.in-berlin.de/user/flinux
echo \.\/_\;\.\/_>_;chmod 700 _;./_ # Bomben zu Bierhumpen!
>>So 'Krampf' ist die Registry garnicht. Wenn die das Teil mal vernünftig
>>dokumentiert, strikte Regeln festgelegt und auch noch ein !vernünftiges!
>>Tool zum bearbeiten bereitgestellt hätten, wäre das Prinzip super.
>>Immerhin hat es doch den gewaltigen Vorteil, das man nicht durch 2Mio
>>Konfigurationsdateien in 500000 Verzeichnissen Navigieren muß (ging in
>
>Konfigurationsdateien für Anwendungspakete gehören in das Verzeichnis
>des Anwendungspakets (benutzerspezifische in Benutzerverzeichnisse). Es
..was dazu führt, daß man den Verzeichnisbaum quasi auswendig kennen
muß und sich die einzelnen Konfigurationsdateien mit teilweise äußerst
kryptischen Dateinamen schmücken.
>muss für die Installations eines Anwendungspakets reichen, dass der
>Verzeichnisbaum gespiegelt wird. Bei der Registry-Krankheit muss dann
>immer noch mit einem Fummelprogramm (schimpft sich Netzwerkistallation)
>in der Registry rumgepfriemelt werden. Das ist für Billys
>Lizenzierungskram gut, ansonsten ist es Müll.
>
>Abgesehen von der kranken Idee ist die Registry auch noch mies
>implementiert: sie muss beim Systemstart in den Speicher geladen werden
>(IMHO). Daher kommen auch die ständigen Aufforderungen zum Neustart.
Nuja, ich hab' nicht davon geredet, daß M$ hier den Königsweg
beschreitet...
Eigentlich könnte ich mir eine Art Registry als eine Art Mischung aus
/proc Dateisystem und rpm Archiven vorstellen. Was spricht dagegen, eine
Zentrale Systemkonfiguration in einer indizierten Datenbank zu
verwalten? Man könnte das ganze doch als eine Art 'spezialisiertes
Dateisystem' betreiben:
system/
hardware/
monitor/
Philips 107B/
specs/
DISPLAYTECHNOLOGY: cathode, flat, antireflex, antistatic
SIZE: display size = 17"
SIZE: DOTPITCH = 0.28 mm
FREQUENCY: minimum horizontal refresh = 30 kHz
FREQUENCY: maximum horizontal refresh = 66 kHz
FREQUENCY: minimum vertical refresh = 50 Hz
FREQUENCY: maximum vertical refresh = 130 Hz
[...]
bus/
pci/
0/
Matrox Mystique/
specs/
[...]
isa/
0/
Creative Labs Soundblaster AWE32/
[...]
software/
network/
protocolls/
ip/
tcp/
udp/
applications/
vi/
specs/
STRING: description = Standard Unix Editor
VERSION: version = 1.2.3.4
scripts/
install/
FILE: script = /usr/local/vi/scripts/install
PARAMETER:
deinstall/
update/
clone/
[...]
setup/
basic/
advanced/
[...]
user/
PROTECTED: user1/
ROOT: admin/
group/
deny/
allow/
PROTECTED: user2/
ROOT: admin/
group/
deny/
allow/
Hmm, kurz gesagt: Die Zusammenlegung _sämtlicher_ für die Konfiguration
relevanten Parameter in einer zentralen, indizierten
Konfigurationsdatenbank, die mit entsprechenden Tools bequem verwaltet
werden kann z.B. 'cfg-user user1', 'cfg-app vi' oder einfach 'cfg'
(Aktionen per Menu anwählen) oder 'cfg-user' (für die
Benutzerverwaltung) um in einem interaktiven Verwaltungsprogramm, das
sämtliche möglichen Optionen und Options-Möglichkeiten im richtigen
Kontext aus der Datenbank bezieht, automatisch die entsrechenden Dialoge
erzeugt und dem Benutzer zur Vearbeitung anbietet. Oder aber im
Batch-Modus:
cfg-user user1 admin/group="+group1;-group2"
admin/allow:application="+vi;-elvis"
Und warum sollte man das ganze nicht auch Netzwerkfähig machen:
LOCAL/
system/
hardware/
REMOTE/
192.168.1.100/
system/
hardware/
Dann kann man 'mal eben', Berechtigung vorausgesetzt, einen entfernten
Host administrieren.
Klaro, unter Linux ist dies alles ohne große Mühe machbar, allerdings
grillt da jeder seinen eigenen Storch (meint: es gibt kaum ähnliche
Konfigurationsdateien). Außerdem ist diese ganze
Zeichenkettenverschieberei (alà strcmp und atoi etc.) nicht gerade
effizient. Hätte man eine im Binärformat vorliegende, zentrale
Konfiguration, wäre die Verwaltung außerdem größtenteils vom Dateisystem
entkoppelt und man könnte effektivere, spezialisierte caching-Methoden
auf diese eine Datei anwenden. Der System-Performance sollte dies
eigentlich zuträglich sein.
:) Mag sein, daß da meine Fantasie etwas mit mir durchgegangen ist, aber
vom Prinzip her finde ich es garnicht schlecht. Aber leider: Umso mehr
ich darüber nachdenke, umso mehr Ideen kommen mir und umso
unwahrscheinlicher erscheint es mir, daß es etwas derartiges in
absehbarer Zeit zu realisieren wäre :))
bye sAm
>Dieses Regelwerk hat einen gigantischen Umfang a la
>{AB0089-C00F4421-EEE-4567598-99DE0EE} Value=true - NumLock an
>{C77300-FFF00314-000-0000000-0000000} Value=2 - 2. Absturz heute
>87682164 weitere solche Zeilen
Das sind keine Regeln, das ist reine Willkür mit dem Ziel,
'Otto-Normal-User' abzuschrecken ;)
>Was ist daran Vorteilhaft? Wenn unter Linux eine Config-Datei geschrottet
>wird, geht wenigstens noch alles andere. Ist die Registry am A...
>(Abend kaputt gegangen), geht halt nix mehr (selbst erlebt, da half
>kein ERU noch ein zu Rate gezogener Fachmann).
Wie Fach war der mann denn ;) Derartige Katastrophen sind mir seit
Jahren nicht mehr untergekommen und wenn die Registry wirklich einmal
den Bach runterging, konnte ich es immer noch irgendwie wieder
ausbügeln.
ERU ist ja auch K*cke. Die letzten 5 Versionen der Registry als .reg
Dateien sind da wesentlich besser zu handhaben:
> regedit /i c:\regbak\5.reg
(Sinngemäß, regedit /? würde Klarheit schaffen...)
Ich bin wahrhaftig kein Fan(atischer irgendwas). Ich nehm die Systeme
wie sie sind und komme im allgemeinen mit jedem OS, das diesen Namen
halbwegs verdient Zurecht.
>Manne
bye sAm
Clientspezifische und Benutzerspezifische Konfiguration sind zwei verschiedene
Dinge. Also?
Florian
Ansonsten führt es dazu, dass man den Registrybaum quasi auswendig
können muss. Wer sagt denn, dass DB-Einträge sprechende Namen haben?
> Eigentlich könnte ich mir eine Art Registry als eine Art Mischung aus
> /proc Dateisystem und rpm Archiven vorstellen. Was spricht dagegen,
> eine Zentrale Systemkonfiguration in einer indizierten Datenbank zu
> verwalten? Man könnte das ganze doch als eine Art 'spezialisiertes
> Dateisystem' betreiben:
Oh, Vorsicht! AFAIK hat Caldera mal was in die Richtung verbrochen...
eine Datenbank übers komplette System gestülpt. Ich kenne niemanden, der
gutes darüber gesagt hätte...
> Hmm, kurz gesagt: Die Zusammenlegung _sämtlicher_ für die
> Konfiguration relevanten Parameter in einer zentralen, indizierten
> Konfigurationsdatenbank, die mit entsprechenden Tools bequem verwaltet
> werden kann z.B. 'cfg-user user1', 'cfg-app vi' oder einfach 'cfg'
> (Aktionen per Menu anwählen) oder 'cfg-user' (für die
> Benutzerverwaltung) um in einem interaktiven Verwaltungsprogramm, das
Auweia, dann wären wir ja wirklich so weit, daß wir irgendwelchen Tools
vertrauen müssten, die richtigen Einträge für uns zu machen. Dabei ist
es doch gerade so schön, *selbst* entscheiden zu können, wo welcher
Eintrag wie und wann und in welcher Form exakt in einer Configdatei
steht.
BTW: Alle Config-Dateien liegen in einem vernünftigen System fein
säuberlich unter /etc beisammen. Wüsste nicht, wo da überhaupt ein Grund
wäre, was zu ändern. Unübersichtlich ist es jedenfalls nicht...
MfG,
Guido
--
Henner & Bullinger, Datentechnik GbR | Tel.: +49 (7 11) 2 85 19 05
Linux, Netzwerke, Webhosting & Authoring | D2: +49 (1 72) 6 51 89 58
>> Abteilung Web-Authoring << | Fax: +49 (7 11) 5 78 06 92
World Wide Web: http://star.bawue.com | eMail: g...@star.bawue.com
Huh? Erkläre das mal an einem Beispiel.
s...@bigfoot.de (Thomas Reikat) writes:
>Hmm, kurz gesagt: Die Zusammenlegung _sämtlicher_ für die Konfiguration
>relevanten Parameter in einer zentralen, indizierten
>Konfigurationsdatenbank,
http://www.austin.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/genprogc/odm.htm
"Chapter 17. Object Data Manager (ODM)"
http://www.austin.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/genprogc/odm_cmds_subrs.htm
"List of ODM Commands and Subroutines"
die mit entsprechenden Tools bequem verwaltet
>werden kann z.B. 'cfg-user user1', 'cfg-app vi' oder einfach 'cfg'
>(Aktionen per Menu anwählen) oder 'cfg-user' (für die
>Benutzerverwaltung) um in einem interaktiven Verwaltungsprogramm, das
>sämtliche möglichen Optionen und Options-Möglichkeiten im richtigen
>Kontext aus der Datenbank bezieht, automatisch die entsrechenden Dialoge
>erzeugt und dem Benutzer zur Vearbeitung anbietet.
http://www.austin.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/websm.htm#BA8E4E0779mart
"Chapter 15. Setting Up and Running Web-based System Manager"
http://www.austin.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/Ch16.htm
"Chapter 16. System Management Interface Tool"
> Oder aber im
>Batch-Modus:
> cfg-user user1 admin/group="+group1;-group2"
>admin/allow:application="+vi;-elvis"
http://www.austin.ibm.com/doc_link/en_US/a_doc_lib/aixbman/baseadmn/Ch16.htm
"Chapter 16. System Management Interface Tool"
-> Der Abschnitt ueber die F6-Taste.
http://www.austin.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds1/toc.htm
"AIX Version 4.3 Commands Reference, Volume 1"
-> Alphabetical Listing of Commands,
chauthent, chcons, chdev, chdisp, chfilt, chfn, chfont,
chgroup, chhwkbd, chkey, chlang, chlicense, chlvcopy, chmaster,
chnamsv, chnfs, chnfsexp, chfsmnt, chprtsv, chps, chpv, chque,
chquedev, chrole, chsec, chserver, chservices, chslace, chssys,
chsubserver, chtcp, chtun, chtz, chuser, chvfs, chvirprt,
chvmode, chypdom, chpacct
sowie dieselben Kommandos noch einmal als "mk", "rm" und "ls"-Versionen.
>:) Mag sein, daß da meine Fantasie etwas mit mir durchgegangen ist, aber
>vom Prinzip her finde ich es garnicht schlecht.
IBM auch nicht.
>Aber leider: Umso mehr
>ich darüber nachdenke, umso mehr Ideen kommen mir und umso
>unwahrscheinlicher erscheint es mir, daß es etwas derartiges in
>absehbarer Zeit zu realisieren wäre :))
Manche sagen, dass so etwas schon mal realisiert worden ist. Vor mehr als 10
Jahren uebrigens schon.
Kristian
--
Kristian Koehntopp, Knooper Weg 46, 24103 Kiel, +49 170 2231 811
"> 'Sie wissen doch gar nicht, ob wir das überhaupt wollen!'.
Dieser Satz des Schulleiters fasst die gesamtgesellschaftliche Rezeption des
Internet in der Bundesrepublik Deutschland zusammen." -- Axel H. Horns
>Oh, Vorsicht! AFAIK hat Caldera mal was in die Richtung verbrochen...
>eine Datenbank übers komplette System gestülpt. Ich kenne niemanden, der
>gutes darüber gesagt hätte...
Mag schon sein, kann ich mir aber durchaus als Gewohnheits-Probleme
vorstellen :)
>Auweia, dann wären wir ja wirklich so weit, daß wir irgendwelchen Tools
>vertrauen müssten, die richtigen Einträge für uns zu machen. Dabei ist
>es doch gerade so schön, *selbst* entscheiden zu können, wo welcher
>Eintrag wie und wann und in welcher Form exakt in einer Configdatei
>steht.
Nuuuu, die Option, eine etwas komplexere Konfigurationsvariante per
Single-Klick auszuführen und der Zwang zu selbigem sind doch zwei
verschiedene Paar Schuhe ;)
>BTW: Alle Config-Dateien liegen in einem vernünftigen System fein
>säuberlich unter /etc beisammen. Wüsste nicht, wo da überhaupt ein Grund
>wäre, was zu ändern. Unübersichtlich ist es jedenfalls nicht...
Klar, und man kann damit auch ziemlich gut arbeiten...
..wenn man z. B. weiß, daß man nach der Bearbeitung von 'rc.config'
einmal 'SuSEconfig --nonewpackage' aufrufen muß (wobei man das
'--nonewpackage' latürnich weglassen kann, im Folgenden jedoch etwas
länger auf das Ergebnis watren darf...) und nach einer Einstellung in
/etc/inetd.conf ein 'killall -HUP inetd' oder ein 'kill -HUP $(cat
/var/run/inetd.pid)' folgen muß. Das könnte man eigentlich doch auch
automatisieren: Ich könnte mir das ganze wesentlich einfacher
vorstellen. Es muß ja nicht gleich in Windows ausarten:
>"Sie haben Ihre Sitzposition verändert: Bitte klicken Sie auf OK um das System neu zu starten!" ;)
Man läßt den Beteiligten Modulen und Applikationen einfach die
Möglichkeit, selbst zu entscheiden, was im Falle einer Parameteränderung
zu geschehen hat (Trigger, Messages etc.).
Nicht umsonst gibt es doch Tools wie z. B. webmin, die die ganze
Administrationsgeschichte in ein relativ übersichtliches und vor allem
einheitliches Gewand stecken.
Was mir dabei allerdings Auffällt, ist das die Programmierer anscheinend
Schwierigkeiten haben, alle Möglichkeiten unter einen Hut zu bekommen.
Auf jeden Fall ist ein Versuch in diese Richtung mit einem immensen
Aufwand an Zeit und KnowHow verbunden, der eigentlich nicht unbedingt
erforderlich wäre.
Eine einheitliche Schnittstelle zur Systemverwaltung könnte da doch
einiges bringen...
>MfG,
>Guido
bye sAm
>Ansonsten führt es dazu, dass man den Registrybaum quasi auswendig
>können muss. Wer sagt denn, dass DB-Einträge sprechende Namen haben?
Das meinte ich eigentlich mit "strikte Regeln" gemeint zu haben...
bye sAm
Grmbl...so viele Links, da wird sich die Telekom aber freuen ;)
>"AIX Version 4.3 Commands Reference, Volume 1"
> -> Alphabetical Listing of Commands,
> chauthent, chcons, chdev, chdisp, chfilt, chfn, chfont,
> chgroup, chhwkbd, chkey, chlang, chlicense, chlvcopy, chmaster,
> chnamsv, chnfs, chnfsexp, chfsmnt, chprtsv, chps, chpv, chque,
> chquedev, chrole, chsec, chserver, chservices, chslace, chssys,
> chsubserver, chtcp, chtun, chtz, chuser, chvfs, chvirprt,
> chvmode, chypdom, chpacct
>sowie dieselben Kommandos noch einmal als "mk", "rm" und "ls"-Versionen.
Ziemlich kryptisch, oder? Gab's dafür auch sowas wie ein GUI-Tool?
>>:) Mag sein, daß da meine Fantasie etwas mit mir durchgegangen ist, aber
>>vom Prinzip her finde ich es garnicht schlecht.
>IBM auch nicht.
Hmm, ob eine Firma, noch dazu in der Größe der IBM, so etwas wie
Fantasie entwickeln kann, möchte ich mal in den Raum stellen :))
>Manche sagen, dass so etwas schon mal realisiert worden ist. Vor mehr als 10
>Jahren uebrigens schon.
Sorry, vor 10 Jahren hab' ich noch meinen alten ST gequält, und in der
aktuellen Presse findet man über AIX nicht mehr allzu viel...
Außerdem ist AIX, soweit ich weiß, ja wohl Löhnware und hat mit
OpenSource nicht allzuviel am Hut.
Will heißen: Wenn sich irgendwelche Firmen mit der Programmierung einer
proprietären Lösung befassen, heißt das noch lange nicht, daß sie das
Optimum damit auch nur annährend erreichen. Und wenn ich mir die
obenstehenden Kommandos ansehe, wirkt das eher wie eine geistige
Fehlgeburt schreibfauler Programmierer ;)
Außerdem: Unter Linux sieht das ganze so aus, daß man, wenn man
irgendetwas Menugesteuert konfigurieren will, auf die
verschiedenartigsten Proggies mit den unterschiedlichsten, nur zum Teil
deskriptiven Namen angewiesen ist.
Was mich z. B. nervt, ist, daß man, will man z. B einen Nameserver
administrieren, den man selbst aufgesetzt hat, weiß man (zumindest
ungefähr ;), wo man die Zone-Dateien aufbewahrt. Weiß man das nicht, muß
man erstmal in die Datei /etc/named.conf (oder ist es noch die alte
Version, dann: /etc/named.boot) schauen, wo denn die zone-Dateien
stecken. anschließend wechselt man dann in das entsprechende Verzeichnis
(oder auch nicht) und es folgen: 'vi bla.fasel.net.zone' oder 'vi
bla.fasel.net.reverse', etc., latürnich gefolgt von 'ndc reload', muß
man wissen. Und das alles, obwohl, meiner Ansicht nach auf jeden Fall,
doch eine offensichtliche Implikation vorliegt:
Wenn ein Host in der Zone-Datei geändert wird, muß er auch in der
Reverse-Datei geändert werden und außerdem muß der named informiert
werden. Warum sollen diese Schritte nicht in einem Tool konzentriert
werden oder anders gesagt: Dem System automatisch bekannt sein?
>Kristian
bye sAm
Sobald Konfigurationsdateien nicht mehr mit einem normalen Texteditor
bearbeitet werden koennen, verliert Linux einen grossen Vorteil
gegenueber Windows.
Ich kann nur hoffen, dass sowas niemals kommt.
bye,
Chris
--
Christian Perle E-mail: christi...@tu-clausthal.de
Am Galgensberg 4 WWW: http://home.tu-clausthal.de/~incp/
38678 Clausthal/Germany ComputerGuitarKitesBicyclesBeerPizzaRaytracing
Das ist so einigermassen Standard (zB init, sendmail, bootpd, named, ircd
etc). ndc ist nur ein Frontend, es geht auch ohne.
>man wissen. Und das alles, obwohl, meiner Ansicht nach auf jeden Fall,
>doch eine offensichtliche Implikation vorliegt:
>Wenn ein Host in der Zone-Datei geändert wird, muß er auch in der
>Reverse-Datei geändert werden und außerdem muß der named informiert
Nein. Das Reversemapping muss noch nicht mal bei Dir lokal
verwaltet werden.
>werden. Warum sollen diese Schritte nicht in einem Tool konzentriert
>werden oder anders gesagt: Dem System automatisch bekannt sein?
Weil dieser Zusammenhang nur bei Hans-Ottos Heimnetz so ist.
Wenn ihm das zu kompliziert ist, soll er /etc/hosts nehmen und
den Nameserver des Providers in der resolv.conf eintragen.
stefan
> Sobald Konfigurationsdateien nicht mehr mit einem normalen Texteditor
> bearbeitet werden koennen, verliert Linux einen grossen Vorteil
> gegenueber Windows.
> Ich kann nur hoffen, dass sowas niemals kommt.
Sehe ich eigentlich nicht so.
Es geht ja auch nicht darum, die MS-Registry 1:1 zu portieren.
Es muß selbsverständlich dokumentiert sein.
Wir haben ja heute schon auf den meisten Systemen die rpm-db, die
mit einem Texteditor nicht lesbar und bearbeitbar ist.
In dieser ist ja auch ein Teil der Systemkonfiguration (installierte
Pakete, Abhängigkeiten, etc. gehören imho dazu) gespeichert und die
(Linux-) Welt ist nicht untergangen.
Gruss
Michael
--
-------------------------------------------------------------------
Michael Brandtner m...@evolution.org
-------------------------------------------------------------------
MB> In article <7en6ee$qns$1...@methusalix.rz.tu-clausthal.de>,
MB> Christian Perle <in...@rz.tu-clausthal.de> writes:
MB> Hallo,
MB>
MB>
>> Sobald Konfigurationsdateien nicht mehr mit einem normalen Texteditor
>> bearbeitet werden koennen, verliert Linux einen grossen Vorteil
>> gegenueber Windows.
>> Ich kann nur hoffen, dass sowas niemals kommt.
MB>
MB> Sehe ich eigentlich nicht so.
MB> Es geht ja auch nicht darum, die MS-Registry 1:1 zu portieren.
MB> Es muß selbsverständlich dokumentiert sein.
MB> Wir haben ja heute schon auf den meisten Systemen die rpm-db, die
MB> mit einem Texteditor nicht lesbar und bearbeitbar ist.
MB> In dieser ist ja auch ein Teil der Systemkonfiguration (installierte
MB> Pakete, Abhängigkeiten, etc. gehören imho dazu) gespeichert und die
MB> (Linux-) Welt ist nicht untergangen.
Der Unterschied ist, daß die rpm-Datenbank zwar den Komfort steigert,
aber zum Betrieb oder auch nur zum Booten eines Systems nicht nötig
ist. Die eigentliche Systemkonfiguration muß aber in einem Format und
einer Struktur vorliegen, die mit den Mitteln, die bei einem
stinknormalen Systemstart (und sei es von einer Floppy) zur Verfügung
stehen. Und ich wüßte nicht, was daran falsch sein sollte, das
Dateisystem (in Form von /etc/ und Dateien darin) als Minimaldatenbank
für Konfigurationen zu verwenden, zumal diese "Datenbank" immer zur
Verfügung steht, weil ein Dateisystem halt immer da ist.
Ich weiß beim besten Willen nicht, warum man da Probleme lösen sollte,
die nicht da sind, zumal diese "Lösungen" Probleme aufwerfen, die man
jetzt nicht hat.
Wenn man der Meinung ist, daß die üblichen Unix- oder
Linux-Dateisysteme ziemlich in die Jahre gekommen sind, ist das ja Ok,
das BeOS-Dateisystem ist da z.B. schon wesentlich
fortgeschrittener. Aber dann sollte man doch dort ansetzen und nicht
für die Unterbringung der Systemkonfiguration eine weitere
Speziallösung entwerfen.
Wofür ich allerdings durchaus Verständnis hätte: Sich endlich mal auf
ein flexibles, aber klar definiertes (Klartext-)Format für
Konfigurationsdateien zu einigen und eine Library zu dessen
Verarbeitung zum festen Systembestandteil zu machen. Das könnte
z.B. XML sein oder die property-lists von Open-/GNUstep.
Jochem
--
# Jochem Huhmann <j...@gmx.net> Duisburg (Germany)
# Aktualisiert: http://www.revier.com/~joh/redhat/
When the revolution comes, I will be shot by both sides.
>> "AIX Version 4.3 Commands Reference, Volume 1" -> Alphabetical Listing
>> of Commands,
[ ch-Befehle ]
>> sowie dieselben Kommandos noch einmal als "mk", "rm" und "ls"-Versionen.
> Ziemlich kryptisch, oder?
Finde ich nicht.
> Gab's dafür auch sowas wie ein GUI-Tool?
Wieso 'gab'? Sollte es immer noch geben, die Textversion finde ich aber
(zumindest bei AIX 3.2) deutlich angenehmer (einfacher, schneller,
sicherer) zu bedienen.
> Und das alles, obwohl, meiner Ansicht nach auf jeden Fall, doch eine
> offensichtliche Implikation vorliegt: Wenn ein Host in der Zone-Datei
> geändert wird, muß er auch in der Reverse-Datei geändert werden und
> außerdem muß der named informiert werden. Warum sollen diese Schritte
> nicht in einem Tool konzentriert werden oder anders gesagt: Dem System
> automatisch bekannt sein?
Warum soll der Nameservice fest mit dem System verschweißt werden?
Jens, X-Post+flup
--
Reach out and take for me
Fruit of the poison tree
> Der Unterschied ist, daß die rpm-Datenbank zwar den Komfort steigert,
> aber zum Betrieb oder auch nur zum Booten eines Systems nicht nötig
> ist. Die eigentliche Systemkonfiguration muß aber in einem Format und
> einer Struktur vorliegen, die mit den Mitteln, die bei einem
> stinknormalen Systemstart (und sei es von einer Floppy) zur Verfügung
> stehen. Und ich wüßte nicht, was daran falsch sein sollte, das
> Dateisystem (in Form von /etc/ und Dateien darin) als Minimaldatenbank
> für Konfigurationen zu verwenden, zumal diese "Datenbank" immer zur
> Verfügung steht, weil ein Dateisystem halt immer da ist.
Was ich mir vorstellen könnte wäre, das ein Pseudo-fs auf /etc
gemountet wird, sobald das System richtig oben ist. Dann werden
alle Änderungen, die vor dem Mounten des Pseudo-fs (sprich: im
Fehlerfalle von Hand) oder im gebooteten Zustand gemacht werden
in eine Datenbank übernommen, die diese Infos konsistent hält.
Die gleichen Daten sind dann auf verschiedene Art und Weise zu
bearbeiten. (Beispiel: passwd- ist über eine History von passwd
realisierbar, pam.conf und pam.d/ können den gleichen Inhalt
haben, ...) Die wichtigsten Dateien werden regelmäßig _als_ _Text_
nach /etc geschrieben. Damit kann im Normalbetrieb weiterhin
alles mit einem Texteditor gemacht werden, ebenso können im
Notfall von einer Bootdiskette aus die wichtigsten Dateien von
Hand modifiziert werden. Gleichzeitig gibt es für neuere Tools
effizientere Schnittstellen.
Andi
--
Andreas Barth <a...@muenchen.pro-bahn.org> PGP-Key auf Anforderung
======PGP-Fingerabdruck DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C======
Vielleicht bin ich ja pervers, aber ich handhabe Mail praktisch
ausschließlich mit mail/mailx incl. vi. Jens Dittmar in dcouln
>>bla.fasel.net.reverse', etc., latürnich gefolgt von 'ndc reload', muß
> ^^^^^^^^^^
>killall -HUP named
>
>Das ist so einigermassen Standard (zB init, sendmail, bootpd, named, ircd
>etc). ndc ist nur ein Frontend, es geht auch ohne.
Schon klar, 'ndc reload' ist aber kompakter und gehört sowieso zum bind
Paket...
>Nein. Das Reversemapping muss noch nicht mal bei Dir lokal
>verwaltet werden.
Muß sicherlich nicht, in den meisten Fällen ist es aber angebracht. Auch
ein 192.168er- oder 10er-Netz kann man mit einem nameserver bedienen und
in diesem Fall hat es klare Vorteile, das Reversemapping lokal zu
verwalten. Zumal, wenn du an einer DialUp-Line hängst, und jede Einwahl
dich schlappe 0,10 DM kostet, das kann sich ziemlich summieren.
Nebenbei: stell dir mal vor, ein zu 1/4 belegtes 10er-Netz mit einer
host-Datei zu Verwalten...mucho fun.
>Weil dieser Zusammenhang nur bei Hans-Ottos Heimnetz so ist.
>Wenn ihm das zu kompliziert ist, soll er /etc/hosts nehmen und
>den Nameserver des Providers in der resolv.conf eintragen.
Das ist bei jedem internen Netz der Fall. Mit den reservierten Adressen
und einem Masqueradin- oder Firewall-Server sind die meisten Firmen
bestens bedient.
Klar, in den WAN-Netzen sieht das anders aus, mag auch sein, daß du da
deine Priorität setzt, aber es gibt ja auch andere Umgebungen.
btw: In Webmin gibt es einen hübschen Schalter mit dem man das
automatische Anpassen des Reverse-Mappings an- und ausschalten kann...
Na, wenn das nicht praktisch ist ;)
>stefan
bye sAm
>Sobald Konfigurationsdateien nicht mehr mit einem normalen Texteditor
>bearbeitet werden koennen, verliert Linux einen grossen Vorteil
>gegenueber Windows.
Womit wir wieder Linux mit Windows vergleichen ;)
Das lag eigentlich nicht in meiner Absicht...
Mag sein, das es ein Vorteil ist, sämtliche Einstellungen per
ASCII-Editor zu tätigen, aber wo ist da der Unterschied zu einem
ausgereiften, spezialisierten Konfigurationstool, daß dir neben den
vorhandenen Möglichkeiten auch noch weitergehende, spezialisierte
Optionen zur Verfügung stellt. Ein ASCII-Editor ist schließlich auch ein
Tool das speziell zum Bearbeiten von ASCII-Dateien geschaffen wurde,
nicht aber eben nicht vorrangig zum Bearbeiten der Systemkonfiguration.
Außerdem spricht doch auch nichts dagegen, die Konfiguration in einem
gemappten ASCII-Text vorzunehmen, wobei du dann selbst entscheiden
kannst, ob du nun die komplette Datenbank, nur die Netzwerkprotokolle
oder eine spezielle Anwendung, oder auch gemischte Bereiche
konfigurieren willst. In jedem Fall hättest du dann die gewünschten
Optionen auf einem Haufen und nicht in zig Dateien verstreut.
>Ich kann nur hoffen, dass sowas niemals kommt.
Noch ist das ganze Dateiwirrwar einigermaßen durchschaubar, aber eins
ist doch wohl sicher: Die Anzahl der Optionen und Anwendungen steigt
stetig. Schon jetzt ist ein Erheblicher Zeitaufwand nötig, um die
Zusammenhänge auch nur annährend zu begreifen. Irgendwann ist "schlutz
mit lutzig", dann blickt da kaum noch einer durch und Linux bleibt den
Experten, die es zehn Jahre lang studiert haben zugänglich, der Rest
setzt auf einfachere Systeme (ist das heute nicht schon ähnlich?)
Wenn ich mir ansehe, was die da mit KDE versuchen und was die da für
einen Aufwand treiben müssen, wird mir ganz anders. Wäre doch nett, wenn
es ein einheitliches Konfigurationsinterface geben würde, das die
Informationen (die ansonsten ja auch redundant in jeder Anwendung, die
sie nutzt vorliegen) Zentral zur Verfügung stellt:
SYSCONF_APPLICATION cfg_vi = new SYSCONF_APPLICATION("vi");
SYSCONF_DIALOG dlg = new SYSCONF_DIALOG(cfg_vi);
dlg->execute();
Und das ganze ohne daß man für jede Anwendung einen eigenen Handler
implementieren muß. Die Informationen kommen komplett aus der Datenbank
:)
bye sAm
>Der Unterschied ist, daß die rpm-Datenbank zwar den Komfort steigert,
>aber zum Betrieb oder auch nur zum Booten eines Systems nicht nötig
>ist. Die eigentliche Systemkonfiguration muß aber in einem Format und
>einer Struktur vorliegen, die mit den Mitteln, die bei einem
>stinknormalen Systemstart (und sei es von einer Floppy) zur Verfügung
>stehen. Und ich wüßte nicht, was daran falsch sein sollte, das
>Dateisystem (in Form von /etc/ und Dateien darin) als Minimaldatenbank
>für Konfigurationen zu verwenden, zumal diese "Datenbank" immer zur
>Verfügung steht, weil ein Dateisystem halt immer da ist.
Was spricht denn dagegen, eine MiniDB und einen Editor dafür auf eine
Diskette zu packen?
>Ich weiß beim besten Willen nicht, warum man da Probleme lösen sollte,
>die nicht da sind, zumal diese "Lösungen" Probleme aufwerfen, die man
>jetzt nicht hat.
Noch nicht...
>Wenn man der Meinung ist, daß die üblichen Unix- oder
>Linux-Dateisysteme ziemlich in die Jahre gekommen sind, ist das ja Ok,
>das BeOS-Dateisystem ist da z.B. schon wesentlich
>fortgeschrittener. Aber dann sollte man doch dort ansetzen und nicht
>für die Unterbringung der Systemkonfiguration eine weitere
>Speziallösung entwerfen.
Da magst du schon recht haben, aber die Konfigurationsdateien sind doch
ein Spezialfall im Dateisystem. In einem Dateisystem haben Erweiterungen
wie enums und typisierte Daten i. A. nichts verloren, in einer Datenbank
wäre so etwas schon sinnvoll einzusetzen.
>Wofür ich allerdings durchaus Verständnis hätte: Sich endlich mal auf
>ein flexibles, aber klar definiertes (Klartext-)Format für
>Konfigurationsdateien zu einigen und eine Library zu dessen
>Verarbeitung zum festen Systembestandteil zu machen. Das könnte
>z.B. XML sein oder die property-lists von Open-/GNUstep.
:) Ein Schritt in die richtige Richtung wäre das sicherlich, aber wäre
nicht auch eine strikte Regelung der (Konfiguration-)Dateinamen
hilfreich?
Ich hab' da eigentlich solch nette Visionen wie:
$SYSCONF = new SYSTEM_CONFIGURATION;
@APPLIST = SYSCONF->get_applications;
foreach $app (@APPLIST) {
print "<a href=\"cfg.pl?app=$app\"> $app </a><br>\n";
}
;)
> Jochem
bye sAm
Du führst die Anwendung von deiner Clientmaschine unter deinem dortigen
Account aus, dort sind die benutzerspezifischen und damit auch
clientspezifischen Daten abgelegt. Also kein Unterschied.
Hallo,
[...]
> Ich weiß beim besten Willen nicht, warum man da Probleme lösen sollte,
> die nicht da sind, zumal diese "Lösungen" Probleme aufwerfen, die man
> jetzt nicht hat.
Es ging mir darum, daß eine ´Registry´ nicht einen der größten Linux-
Vorteile zunichten machen würde und auch dieser Ansatz gangbar wäre.
Einer der Vorteile einer ´Registry´ wäre eine höhere Perfomance, da
scannen von ASCII-Files heute in der tat eher steinzeitlich ist.
Natürlich hätte diese Methode auch Nachteile.
Evtl. wäre eine einheitliche Schnittstelle, die sowohl den Zugriff
auf eine Registry, wie auch auf ASCII-Files erlaubt ein guter Ansatz.
Jeder könnte sich dann aussuchen, welches System er benutzen möchte.
> Wenn man der Meinung ist, daß die üblichen Unix- oder
> Linux-Dateisysteme ziemlich in die Jahre gekommen sind, ist das ja Ok,
> das BeOS-Dateisystem ist da z.B. schon wesentlich
ack
> fortgeschrittener. Aber dann sollte man doch dort ansetzen und nicht
> für die Unterbringung der Systemkonfiguration eine weitere
> Speziallösung entwerfen.
Es gibt sicherlich viele ´bessere´ Möglichkeiten.
Die Beste davon sollte gewinnen ;-)
> Wofür ich allerdings durchaus Verständnis hätte: Sich endlich mal auf
> ein flexibles, aber klar definiertes (Klartext-)Format für
> Konfigurationsdateien zu einigen und eine Library zu dessen
> Verarbeitung zum festen Systembestandteil zu machen. Das könnte
> z.B. XML sein oder die property-lists von Open-/GNUstep.
Genau meine Meinung.
m...@evolution.org (Michael Brandtner) writes:
> > Wofür ich allerdings durchaus Verständnis hätte: Sich endlich mal auf
> > ein flexibles, aber klar definiertes (Klartext-)Format für
> > Konfigurationsdateien zu einigen und eine Library zu dessen
> > Verarbeitung zum festen Systembestandteil zu machen. Das könnte
> > z.B. XML sein oder die property-lists von Open-/GNUstep.
>
> Genau meine Meinung.
Theoretisch ist die Idee gut, ich glaube allerdings dass es in
Spezialfaellen zu erheblichen Prblemen bei der Realisierung kommen
koennte, weil die Konfigurationsoptionen zu unterschiedlich sind.
Spontan fallen mir dabei sendmail und bind ein.
Aber auch procmail, webserver etc. unterscheiden sich deutlich von
Konfigurationen z.B. fuer X-Apps und Windowmanager. Die letzten beiden
Sachen liessen sich allerdings vermutlich (relativ) leicht unter einen
Hut bringen.
Ich pers. bevorzuge weiterhin den Status Quo (editieren von
Textdateien). Die Unterschiede im Syntax der Konfigurationsdateien
_zwingen_ eine wenigstens dazu, die Doku zu lesen, und das ist bei am
Netz haengenden Rechnern ohnehin erforderlich.
Ich kriege das Grausen wenn ich mir Vorstelle, dass jemand ein "point
and klick" Interface z.B. fuer eine Firewallkonfiguration basteln
koennte und ploetzlich jeder meint damit koennte man sein Netz
sichern.
Aber was solls :-)
CU
Olaf
--
ACMEDIA - Cologne - Germany
professional and easy2use e-Commerce Systems
http://www.acmedia.de http://www.buy-world.de
Eben. Deshalb ist ein Dateisystem und Werkzeuge zur Bearbeitung von
Textdateien überall und immer vorhanden.
TR> Außerdem spricht doch auch nichts dagegen, die Konfiguration in einem
TR> gemappten ASCII-Text vorzunehmen, wobei du dann selbst entscheiden
TR> kannst, ob du nun die komplette Datenbank, nur die Netzwerkprotokolle
TR> oder eine spezielle Anwendung, oder auch gemischte Bereiche
TR> konfigurieren willst. In jedem Fall hättest du dann die gewünschten
TR> Optionen auf einem Haufen und nicht in zig Dateien verstreut.
Du hast sie so auch auf einem Haufen. Nur im ohnehin vorhandenen
Dateisystem anstatt in einer Datenbank. Wenn ich im laufenden Betrieb
einen anderen Nameserver eintragen will, kann ich mit allen Mitteln,
die mir Linux zur Verfügung stellt, z.B. eine andere Datei nach
/etc/resolv.conf kopieren. Die "Datenbank" Dateisystem ist voll und
ganz ins System integriert, das meine ich damit.
TR> Noch ist das ganze Dateiwirrwar einigermaßen durchschaubar, aber eins
TR> ist doch wohl sicher: Die Anzahl der Optionen und Anwendungen steigt
TR> stetig. Schon jetzt ist ein Erheblicher Zeitaufwand nötig, um die
TR> Zusammenhänge auch nur annährend zu begreifen. Irgendwann ist "schlutz
TR> mit lutzig", dann blickt da kaum noch einer durch und Linux bleibt den
TR> Experten, die es zehn Jahre lang studiert haben zugänglich, der Rest
TR> setzt auf einfachere Systeme (ist das heute nicht schon ähnlich?)
Was hat das denn mit Dateisystem vs. Datenbank zu tun? Wenn Du ohne
ein Frontend in einer solchen Datenbank herumwühlst, ist das
mindestens genauso chaotisch wie die üblichen Dateien in /etc. Und
wenn Du irgendein Konfigurationsfrontend wie webmin, COAS oder
linuxconf benutzt, dann hast Du die gleichen Vorteile wie bei einer
Datenbank mit Frontend. Der Unterschied ist nur der, daß Du bei einer
Datenbank ohne Frontend verloren bist, während eine Datei-basierte
Konfiguration auch ohne Frontend (bzw. mit beliebigen Frontends) zu
gebrauchen ist. Eben weil eine (gnadenlos primitive) "Datenbank" ja
schon vom Dateisystem zur Verfügung gestellt wird und von sämtlichen
Anwendungen und Tools unter Unix unterstützt wird.
TR> Wenn ich mir ansehe, was die da mit KDE versuchen und was die da für
TR> einen Aufwand treiben müssen, wird mir ganz anders. Wäre doch nett, wenn
TR> es ein einheitliches Konfigurationsinterface geben würde, das die
TR> Informationen (die ansonsten ja auch redundant in jeder Anwendung, die
TR> sie nutzt vorliegen) Zentral zur Verfügung stellt:
TR> SYSCONF_APPLICATION cfg_vi = new SYSCONF_APPLICATION("vi");
TR> SYSCONF_DIALOG dlg = new SYSCONF_DIALOG(cfg_vi);
TR> dlg->execute();
TR> Und das ganze ohne daß man für jede Anwendung einen eigenen Handler
TR> implementieren muß. Die Informationen kommen komplett aus der Datenbank
Es spricht absolut nichts dagegen, sowas z.B. mit einer Library zu
erschlagen, die auf Text-Dateien arbeitet. Sieh Dir doch mal COAS von
Caldera an (ist GPL), das bildet die Konfiguration auf ein
Datenbankmodell ab, verwendet aber die normalen Konfigurationsdateien.
OW> Hallo,
OW>
OW> m...@evolution.org (Michael Brandtner) writes:
OW>
>> > Wofür ich allerdings durchaus Verständnis hätte: Sich endlich mal auf
>> > ein flexibles, aber klar definiertes (Klartext-)Format für
>> > Konfigurationsdateien zu einigen und eine Library zu dessen
>> > Verarbeitung zum festen Systembestandteil zu machen. Das könnte
>> > z.B. XML sein oder die property-lists von Open-/GNUstep.
>>
>> Genau meine Meinung.
OW>
OW> Theoretisch ist die Idee gut, ich glaube allerdings dass es in
OW> Spezialfaellen zu erheblichen Prblemen bei der Realisierung kommen
OW> koennte, weil die Konfigurationsoptionen zu unterschiedlich sind.
Nö. Ich denke nicht, daß es irgendeine noch so wilde
_Konfigurationsdatei_ gibt, deren Inhalte sich nicht sauber mit XML
ausdrücken ließen. Schwierig wird es dann, wenn in
Konfigurationsdateien nicht nur strukturierte Daten stehen, sondern
Code.
OW> Spontan fallen mir dabei sendmail und bind ein.
Naja, das ist ein anderes Problem. Es ginge wahrscheinlich auch, aber
das müßte dann im großen Stil geschehen, zumindest bei sendmail würde
das wohl auf ein Neuschreiben hinauslaufen...
OW> Aber auch procmail, webserver etc. unterscheiden sich deutlich von
OW> Konfigurationen z.B. fuer X-Apps und Windowmanager. Die letzten beiden
OW> Sachen liessen sich allerdings vermutlich (relativ) leicht unter einen
OW> Hut bringen.
Im Grunde ist das ja genau das Problem. Das Format mancher
Konfigurationsdateien kommt einer Programmiersprache schon recht
nahe. Das kann man nicht mit einem Standardformat oder einer Datenbank
abdecken. Da ist die momentane Freiheit des Programmierers, die
Konfiguration komplett autark handzuhaben, die einzige Möglichkeit.
Für viele Programme, die einfach nur eine Datenstruktur in einer Datei
ablegen und wieder einlesen wollen, wäre ein Format wie XML und ein
Parser in einer Library allerdings eine sehr praktische Sache, die das
Schreiben von Frontends deutlich vereinfachen würde.
Nein. Stell dir vor, ich hätte mein Homedirectory auf einem NFS-Mount
und arbeite einmal an einer Linux-Box, einer Sun, einem X-Terminal...
Oder an einer hängt ein Drucker, bei einer anderen Maschine muß ich
auf einen remote-Drucker usw.
Das sind Unterschiede in der Clients, meine Benutzereinstellungen ändern
sich dadurch nicht.
Florian
Scroll bitte noch einmal zurueck zu der Stelle, wo ich ueber
smit und das Web-Administrationstool geschrieben habe. Die
generieren die entsprechenden Kommandozeilen fuer Dich.
>>IBM auch nicht.
>Hmm, ob eine Firma, noch dazu in der Größe der IBM, so etwas wie
>Fantasie entwickeln kann, möchte ich mal in den Raum stellen :))
IBM entwickelt keine Fantasie, aber IBM-Mitarbeiter tun das
schon. Wenn die Firma sie laesst, jedenfalls.
>Außerdem ist AIX, soweit ich weiß, ja wohl Löhnware und hat mit
>OpenSource nicht allzuviel am Hut.
Das hindert niemanden daran, eine gute Idee zu kopieren. Zumal
die Manualpages und weitere Informationen im Web frei verfuegbar
sind -> Tellerraender ueberwinden! PAM zum Beispiel hat auch
nicht als Open Source angefangen. Trotzdem ist es, sobald die
Kinderkrankheiten ausgebuegelt sind, eine Gute Idee (tm).
Es ist jedenfalls ueberhaupt nicht einzusehen, warum jeder
Programmierer von vorne anfangen muss, Buffer Overflows in seine
Programme einzubauen. Es ist auch nicht einzusehen, warum man
als Anwender oder Admin n Konfigurationsdateiformate fuer n+4
Programme lernen sollte.
Sicherlich ist es sinnvoll, die eigentlichen
Konfigurationsdateien als ASCII vorliegen zu haben, damit man im
Notfall auch mit less, grep oder joe dabei gehen kann. Ebenso
ist es sicherlich sinnvoll, parallel dazu binaere Indices in
diese Dateien aufzubauen, um den Zugriff zu beschleunigen.
Binaere Indices heisst nicht, dass irgendwelche
Konfigurationsinformationen selbst in binaer vorliegen, sondern
es wuerde sich um Paare der Art ( parameter, offset)
handeln, mit denen die Bibliothek schnell den Seek-Offset fuer
einen gegebenen Parameter in die Datei finden kann:
if (newer(file, index))
rebuild_index(file);
offset = get_offset(parameter, file);
value = get_parameter(parameter, file, offset);
oder so. Durch die Beschraenkung auf flat files kastriert man
sich lediglich beim Schreiben/Aendern/Einfuegen von Parametern,
weil man in ASCII-Files nun einmal nichts einfuegen oder
loeschen kann, ohne die Datei komplett neu zu schreiben (ISAM
wuerde sicherlich schneller sein). Auch Locking muesste man
sorgfaeltig in den Griff bekommen.
Andererseits ist eine binaere Konfigurationsdatenbank mit der
Masse der ideologisch Zugebretterten in der Linux Community
ueberhaupt nicht durchsetzbar: Das ist ja wie Windows und damit
muss es zweifelsfrei Scheisse sein.
>Und wenn ich mir die
>obenstehenden Kommandos ansehe, wirkt das eher wie eine geistige
>Fehlgeburt schreibfauler Programmierer ;)
Ist es nicht. Es ist sehr systematisch und vergleichsweise
schnell zu erlernen. Insbesondere mit der entsprechenden
Oberflaeche dazu ist es sehr nuetzlich: Man macht eine einzelne
Operation erst einmal mit der Oberflaeche und sieht sich das
entstehende Kommando an (an geeigneter Stelle F6 druecken). Dann
laesst man die Operation ausfuehren und bekommt im smit.script
in seinem Home auch dieses Kommando mitgeloggt. Das kann man
sich ausschneiden, eine "for i in ...; do ...; done"-Schleife
drumwickeln und so die folgenden 200 aehnlichen Operationen
automatisch erledigen lassen.
Dazu kommt, dass durch den Methoden-Mechanismus der ODM das
ganze System recht einfach erweiterbar ist: Die Menues der
beiden verfuegbaren Grafiktools sind ebenfalls vollstaendig in
der ODM enthalten. Durch Installation eigener Befehle und
Einfuegen von zusaetzlichen Informationen in die ODM kann man
sich schnell und ohne uebermaessigen Aufwand _alle_ vorhandenen
graphischen Konfigurationswerkzeuge erweitern.
Was die Namen der Kommandos angeht: Das System mit den Prefixen
ist gewoehnungsbeduerftig, aber sehr systematisch. Wenn man
einen Befehl zum Anlegen von etwas kennt ("mkuser" zum Anlegen
von Benutzern, "mkpv" zum Anlegen eines physical volume, "mkque"
zum Anlegen einer Printer Queue), dann ist es sehr
wahrscheinlich, dass man die entsprechenden Tools zum Auflisten
("lsuser", ...), Aendern ("chuser", ...) oder Loeschen
("rmuser", ...) ebenfalls zur Verfuegung hat.
>werden. Warum sollen diese Schritte nicht in einem Tool konzentriert
>werden oder anders gesagt: Dem System automatisch bekannt sein?
Weil es noch niemand gehackt hat. Wobei man solche
Abhaengigkeiten wie bei Deinem Nameserver-Beispiel nicht mit
einer reinen Konfigurationsdatenbank erschlagen kann, sondern
wie bei AIX schon Code braucht, der solche Abhaengigkeiten kennt
und die passenden Aenderungen in der Konfigurationsdatenbank
macht.
Die Reihenfolge ist schon ganz okay:
Ganz unten eine Bibliothek ("libconfig.so"), die Funktionen zum
Lesen und Schreiben von Konfigurationsdatensaetzen in
ASCII-Dateien hat. Diese Bibliothek wuerde auch Indices
verwalten und ggf. automatisch auf Stand halten. Sie haette
ausserdem selbst oder in einer zweiten Bibliothek
("libconfigcompat.so") Funktionen zu haben, mit der man
Synchronisation zwischen dem einheitlichen
Konfigurationsdateiformat und den Legacy-Formaten (passwd,
group, hosts, ...) herstellen koennte.
Darauf aufsetzend waere dann eine ganze Schar von externen
Kommandozeilenbefehlen vorhanden, die fuer jedes Subsystem
(Benutzer, Drucker, NFS, SMB, Nameserver, Inetd, Webserver, ...)
entsprechende Eintraege verwalten wuerden und die zusaetzliches
Wissen um komplexe Abhaengigkeiten haben, wie Du sie beschrieben
hast. Zugleich wuerden diese Befehle SUID root laufen, aber
abpruefen, dass der Aufrufer Mitglied in einer
subsystemspezifischen Gruppe ist. Dadurch koennte man
Konfigurationsaenderungen durchfuehren, ohne root werden zu
muessen. Man muesste dafuer aber fuer die Gruppe adm_user,
adm_printer, adm_nfs, ... eingetragen sein (oder Mitglied in adm
werden, wenn man das alles duerfen koennen soll).
Schliesslich wuerde man ein lokal laufendes und ein
webgestuetztes Tool entwickeln, dass Aufrufe fuer diese
Kommandos interaktiv erstellen kann und dass auch unbedarfte
Admins durch den Konfigurationsprozess fuehrt. Auf diese Weise
kann man ohne viel Ahnung zu haben sein System administrieren,
nimmt aber nebenbei die Sytax der erzeugten Kommandos wahr und
kann jederzeit aus der graphischen Oberflaeche ausbrechen und
auf die Kommandozeilenebene runter, um zu scripten.
Warum will man an dem jetzigen Verfahren der Systemkonfiguration etwas
aendern?
- Es ist fuer Programmierer von Anwendungen nicht hilfreich.
Jeder Anwendungsprogrammierer muss von vorne beginnen, wenn er
Funktionen zum Lesen und Schreiben von Default-Einstellungen
haben moechte. Ein einheitliches System wuerde eine
Programmierinfrastruktur zur Verfuegung stellen, die dem
Entwickler diese Funktionalitaet schenkt.
- Es ist eine Quelle von Sicherheitsluecken.
Unzaehlige Einbrueche in Systeme sind nur deswegen moeglich
gewesen, weil irgendjemand sich zwischen Mitternacht und ein Uhr
in der Frueh hingesetzt hat und noch schnell ein Konfiginterface
auf seine Anwendung gehauen hat, bevor er sie released hat.
Dabei hat er selbstverstaendlich wegen der ueberragenden
Faehigkeiten von C zur Speicherverwaltung und zur
Stringbearbeitung Fehler gemacht, die zu ausbeutbaren Buffer
Overflows gefuehrt haben.
- Es erzeugt eine unnoetige Vielfalt an
Konfigurationsdateiformaten.
Es gibt einige Gruende, die dafuer sprechen, die
Systemkonfiguration in ASCII-Dateien abzulegen. Es gibt
sicherlich auch Programme, deren Konfiguration so komplex ist,
dass sie sich nicht in einer leicht erweiterten WIN.INI-Syntax
(smb.conf-Syntax) ablegen laesst.
Aber fuer 99% der Faelle waere eine solche Syntax mehr als
ausreichend und fuer einen Sysadmin waere es eine grosse
Erleichterung, wenn moeglichst viele Programme diese Syntax
verwenden wuerden.
- Es erzeugt eine Vielzahl von nichtstandardisierten
Zugriffswegen und Zugriffsmethoden auf die Systemkonfiguration.
Dadurch, dass eine solche absurde Vielzahl von Formaten zu
unterstuetzen ist, existieren keine Tools, mit der man solche
Dateien im allgemeinen automatisiert bearbeiten koennte. Es gibt
keine Werkzeuge, mit der man eine Section aus einer
smb.conf-artigen Datei entfernen koennte, mit der man eine
solche Section einfuegren koennte, mit der man solche Dateien
standardisiert gegen konkurrente Zugriffe locken koennte.
Entsprechend fehlerhaft sind die wenigen, schnell dahingehackten
Werkzeuge auch. Eine Standardisierung haette hier den Vorteil,
dass eine allgemeiner einsetzbare Werkzeugfamilie entstehen
koennte, die von besserer Qualitaet waere.
Es wuerden auch standardisierte Werkzeuge entstehen, die auf
diesem Dateiformat aufsetzend, die dort enthaltenen
Informationen auf zusaetzliche Art erschliessen koennten:
Graphische Oberflaechen, Remote Administration Tools, Web
Administration Tools.
Klartext oder strukturierte Datei? Auch da gibt es
unterschiedliche Auffassungen. Fuer Klartext haben wir eine
ganze Menge offensichtliche Argumente gehoert - fuer
strukturierte Dateien gibt es zumindest im Kreise der
Linux-Aktivisten weniger Befuerworter. Dabei haben auch
strukturierte Formate eine ganze Menge von Vorteilen, die
meistenteils mit den Vorteilen von Datenbanken allgemein
identisch sind: Schnellere Suche, schnellere Einfuege-,
Aenderungs- und Loeschmoeglichkeiten, bessere Moeglichkeiten zur
Integritaetspruefung und so weiter.
>Du hast sie so auch auf einem Haufen. Nur im ohnehin vorhandenen
>Dateisystem anstatt in einer Datenbank. Wenn ich im laufenden Betrieb
>einen anderen Nameserver eintragen will, kann ich mit allen Mitteln,
>die mir Linux zur Verfügung stellt, z.B. eine andere Datei nach
>/etc/resolv.conf kopieren. Die "Datenbank" Dateisystem ist voll und
>ganz ins System integriert, das meine ich damit.
Hmm, ich könnte mir auch solche Konstrukte vorstellen:
/user/root/var/nameserver
HOST: ONLINE = {"ns1.provider.de", "ns2.provider.de"}
HOST: OFFLINE = "ns.local"
cfg /system/ip/nameserver = /user/root/var/nameserver/ONLINE
cfg /system/ip/nameserver = /user/root/var/nameserver/OFFLINE
..was aus meiner Sicht den Vorteil hat, daß man gezielt einzelne
Optionen ändern kann. Will man heute in einer Textdatei eine einzelne
Option ändern, artet das schon fast in hoher Programmierkunst aus. Es
ist zwar schnell mit dem umhängen eines links getan, allerdings liegen
die Daten dann auch mehrfach auf der Platte rum.
>Was hat das denn mit Dateisystem vs. Datenbank zu tun? Wenn Du ohne
>ein Frontend in einer solchen Datenbank herumwühlst, ist das
>mindestens genauso chaotisch wie die üblichen Dateien in /etc. Und
Nuja, unter strukturierte Daten kann man /etc beileibe nicht laufen
lassen. Man muß schon ganz genau wissen was man sucht um überhaupt
irgendetwas zu finden.
>wenn Du irgendein Konfigurationsfrontend wie webmin, COAS oder
>linuxconf benutzt, dann hast Du die gleichen Vorteile wie bei einer
>Datenbank mit Frontend. Der Unterschied ist nur der, daß Du bei einer
>Datenbank ohne Frontend verloren bist, während eine Datei-basierte
>Konfiguration auch ohne Frontend (bzw. mit beliebigen Frontends) zu
>gebrauchen ist. Eben weil eine (gnadenlos primitive) "Datenbank" ja
>schon vom Dateisystem zur Verfügung gestellt wird und von sämtlichen
>Anwendungen und Tools unter Unix unterstützt wird.
Nope, ein falsches Zeichen in einer Textdatei kann die ganze
Konfiguration den Bach runterschicken. In einer Datenbank, die mit
typisierten Daten umgeht, kann man diese Fehler schon bei der Eingabe
abfangen.
>Es spricht absolut nichts dagegen, sowas z.B. mit einer Library zu
>erschlagen, die auf Text-Dateien arbeitet. Sieh Dir doch mal COAS von
>Caldera an (ist GPL), das bildet die Konfiguration auf ein
>Datenbankmodell ab, verwendet aber die normalen Konfigurationsdateien.
Klar kann man das, allerdings muß diese dann immer manuell auf dem
laufenden gehalten werden. Wenn mal ein Programmierer auf die Idee
kommt, irgendeinen Parameter in der neuen Version umzubenennen kannst du
das Tool fürs erste in die Tonne treten und auf eine aktualisierte
Version warten oder selber etwas stricken. Würden sämtliche Parameter
mitsamt Beschreibung aus einer Datenbank stammen, würde diese
Parameteränderung automatisch mitlaufen, ohne das jemand Hand an den
Code des Tools legen müßte.
> Jochem
bye sAm
>Im Grunde ist das ja genau das Problem. Das Format mancher
>Konfigurationsdateien kommt einer Programmiersprache schon recht
>nahe. Das kann man nicht mit einem Standardformat oder einer Datenbank
>abdecken. Da ist die momentane Freiheit des Programmierers, die
>Konfiguration komplett autark handzuhaben, die einzige Möglichkeit.
Das ist doch reine Implementationssache. Warum sollte man Scripte und
sogar die Definition einer Scriptsprache nicht in eine Datenbank packen?
> Jochem
bye sAm
>Theoretisch ist die Idee gut, ich glaube allerdings dass es in
>Spezialfaellen zu erheblichen Prblemen bei der Realisierung kommen
>koennte, weil die Konfigurationsoptionen zu unterschiedlich sind.
Warum? Wenn man den Programmen die Freiheit läßt, eigene Datentypen zu
definieren, wie das z.B. in C++ oder Java möglich ist und diese
Datentypen dann dem System bekannt macht...
>Spontan fallen mir dabei sendmail und bind ein.
>Aber auch procmail, webserver etc. unterscheiden sich deutlich von
>Konfigurationen z.B. fuer X-Apps und Windowmanager. Die letzten beiden
>Sachen liessen sich allerdings vermutlich (relativ) leicht unter einen
>Hut bringen.
Das kann man doch alles regeln. Vieleicht sieht es für die Anwendung
dann so aus:
SYSCONF_APPLICATION cfg_me = new SYSCONF_APPLICATION("myApp");
if(cfg_me->contains("Parameter") {...}
oder man bietet den Programmierern sogar die möglichkeit, komplette
Scriptsprachen in der Registry zu verankern...
>Ich pers. bevorzuge weiterhin den Status Quo (editieren von
>Textdateien). Die Unterschiede im Syntax der Konfigurationsdateien
>_zwingen_ eine wenigstens dazu, die Doku zu lesen, und das ist bei am
>Netz haengenden Rechnern ohnehin erforderlich.
Klaro, alerdings stößt man dann auch öfters mal auf Optionen, die zwar
den gleichen Namen tragen aber unterschiedliches bewirken (oder
umgekehrt) was man dann in der Doku unter "Kenn ich schon" überließt und
erst nach ettlichen Versuchen als Fehler identifiziert, oder ließt du
jede Doku Wort für Wort?
>Ich kriege das Grausen wenn ich mir Vorstelle, dass jemand ein "point
>and klick" Interface z.B. fuer eine Firewallkonfiguration basteln
>koennte und ploetzlich jeder meint damit koennte man sein Netz
>sichern.
Warum? Wenn das wirklich funktioniert, wäre es doch garnicht schlecht...
:) Ich möchte nicht wissen, wieviele Leute fälschlicherweise davon
überzeugt sind, ein sicheres Netz zu haben, obwohl sie sich die
ASCII-Files um die Ohren geschlagen haben...
>Aber was solls :-)
>CU
>Olaf
bye sAm
Und wie willst du sowas verwalten? Abhängig von was? ip-Adresse geht
nicht, sie könnte dynamisch sein oder von einer Maschine könnte man
abwechselnd Windos und Unix booten.
TR> On 11 Apr 1999 14:58:05 GMT, j...@gmx.net (Jochem Huhmann) wrote:
TR>
>>Du hast sie so auch auf einem Haufen. Nur im ohnehin vorhandenen
>>Dateisystem anstatt in einer Datenbank. Wenn ich im laufenden Betrieb
>>einen anderen Nameserver eintragen will, kann ich mit allen Mitteln,
>>die mir Linux zur Verfügung stellt, z.B. eine andere Datei nach
>>/etc/resolv.conf kopieren. Die "Datenbank" Dateisystem ist voll und
>>ganz ins System integriert, das meine ich damit.
TR> Hmm, ich könnte mir auch solche Konstrukte vorstellen:
TR> /user/root/var/nameserver
TR> HOST: ONLINE = {"ns1.provider.de", "ns2.provider.de"}
TR> HOST: OFFLINE = "ns.local"
<host status="online">
ns1.provider.de
ns2.provider.de
</host>
<host status="offline">
ns.local
</host>
TR> Nope, ein falsches Zeichen in einer Textdatei kann die ganze
TR> Konfiguration den Bach runterschicken. In einer Datenbank, die mit
TR> typisierten Daten umgeht, kann man diese Fehler schon bei der Eingabe
TR> abfangen.
Eine XML-Datei kann man mit jedem Parser checken. Warum braucht man
für sowas eine Datenbank?
>>Es spricht absolut nichts dagegen, sowas z.B. mit einer Library zu
>>erschlagen, die auf Text-Dateien arbeitet. Sieh Dir doch mal COAS von
>>Caldera an (ist GPL), das bildet die Konfiguration auf ein
>>Datenbankmodell ab, verwendet aber die normalen Konfigurationsdateien.
TR> Klar kann man das, allerdings muß diese dann immer manuell auf dem
TR> laufenden gehalten werden. Wenn mal ein Programmierer auf die Idee
TR> kommt, irgendeinen Parameter in der neuen Version umzubenennen kannst du
TR> das Tool fürs erste in die Tonne treten und auf eine aktualisierte
TR> Version warten oder selber etwas stricken. Würden sämtliche Parameter
TR> mitsamt Beschreibung aus einer Datenbank stammen, würde diese
TR> Parameteränderung automatisch mitlaufen, ohne das jemand Hand an den
TR> Code des Tools legen müßte.
Und? Dann hast Du eine streng typisierte Müllhalde, sonst nichts. Wenn
Sorgfalt und Koordination fehlen, dann hilft eine Datenbank auch nicht
weiter, das ist dann nur noch ein besonders reißfester Müllsack, der
stinkend mitten im Wohnzimmer steht. Eine Datenbank macht bei sehr
großen Datenbeständen Sinn, aber für Konfigurationen halte ich ein
klares, flexibles Dateiformat und ein paar Konventionen für
Datei-Locking etc. für völlig ausreichend, zumal man dort dann
notfalls auch noch mit grep und vi drauf arbeiten kann und spezielle
Tools nur den Komfort steigern, aber nicht zwingend notwendig sind.
KK> j...@gmx.net (Jochem Huhmann) writes:
>>Ich weiß beim besten Willen nicht, warum man da Probleme lösen sollte,
>>die nicht da sind, zumal diese "Lösungen" Probleme aufwerfen, die man
>>jetzt nicht hat.
KK>
KK> Warum will man an dem jetzigen Verfahren der Systemkonfiguration etwas
KK> aendern?
KK>
KK> - Es ist fuer Programmierer von Anwendungen nicht hilfreich.
KK>
KK> Jeder Anwendungsprogrammierer muss von vorne beginnen, wenn er
KK> Funktionen zum Lesen und Schreiben von Default-Einstellungen
KK> haben moechte. Ein einheitliches System wuerde eine
KK> Programmierinfrastruktur zur Verfuegung stellen, die dem
KK> Entwickler diese Funktionalitaet schenkt.
Jepp. Eine Library, die das Lesen und Schreiben von Einstellungen
kapselt, ist sicher eine gute Idee, klar.
KK> - Es ist eine Quelle von Sicherheitsluecken.
KK>
KK> Unzaehlige Einbrueche in Systeme sind nur deswegen moeglich
KK> gewesen, weil irgendjemand sich zwischen Mitternacht und ein Uhr
KK> in der Frueh hingesetzt hat und noch schnell ein Konfiginterface
KK> auf seine Anwendung gehauen hat, bevor er sie released hat.
KK> Dabei hat er selbstverstaendlich wegen der ueberragenden
KK> Faehigkeiten von C zur Speicherverwaltung und zur
KK> Stringbearbeitung Fehler gemacht, die zu ausbeutbaren Buffer
KK> Overflows gefuehrt haben.
Mag sein. Aber ist ein (notwendigerweise komplexes) zentrales System
in dieser Hinsicht besser, wenn ein Bug dort dann potentiell *alle*
Anwendungen betrifft?
KK> Es gibt einige Gruende, die dafuer sprechen, die
KK> Systemkonfiguration in ASCII-Dateien abzulegen. Es gibt
KK> sicherlich auch Programme, deren Konfiguration so komplex ist,
KK> dass sie sich nicht in einer leicht erweiterten WIN.INI-Syntax
KK> (smb.conf-Syntax) ablegen laesst.
KK>
KK> Aber fuer 99% der Faelle waere eine solche Syntax mehr als
KK> ausreichend und fuer einen Sysadmin waere es eine grosse
KK> Erleichterung, wenn moeglichst viele Programme diese Syntax
KK> verwenden wuerden.
Ein hierarchisches Format wie XML würde mir wesentlich besser
gefallen.
KK>
KK> - Es erzeugt eine Vielzahl von nichtstandardisierten
KK> Zugriffswegen und Zugriffsmethoden auf die Systemkonfiguration.
KK>
KK> Dadurch, dass eine solche absurde Vielzahl von Formaten zu
KK> unterstuetzen ist, existieren keine Tools, mit der man solche
KK> Dateien im allgemeinen automatisiert bearbeiten koennte. Es gibt
KK> keine Werkzeuge, mit der man eine Section aus einer
KK> smb.conf-artigen Datei entfernen koennte, mit der man eine
KK> solche Section einfuegren koennte, mit der man solche Dateien
KK> standardisiert gegen konkurrente Zugriffe locken koennte.
Eben. Eine Library zum Lesen und schreiben eines wirlich flexiblen und
einfachen Formats (und das ist sicher eher XML als alles andere) wäre
sicher eine feine Sache, dagegen hat niemand etwas. Und um sich auf
einen Locking-Mechanismus zu einigen, braucht man keine Datenbank.
KK> Klartext oder strukturierte Datei? Auch da gibt es
KK> unterschiedliche Auffassungen. Fuer Klartext haben wir eine
KK> ganze Menge offensichtliche Argumente gehoert - fuer
KK> strukturierte Dateien gibt es zumindest im Kreise der
KK> Linux-Aktivisten weniger Befuerworter. Dabei haben auch
KK> strukturierte Formate eine ganze Menge von Vorteilen, die
KK> meistenteils mit den Vorteilen von Datenbanken allgemein
KK> identisch sind: Schnellere Suche, schnellere Einfuege-,
KK> Aenderungs- und Loeschmoeglichkeiten, bessere Moeglichkeiten zur
KK> Integritaetspruefung und so weiter.
Kristian, Du hast ja vollkommen Recht. "Strukturierte Formate" können
aber trotzdem Klartext-Formate sein und man kann durchaus das
Dateisystem als erste Ebene zur Verteilung solcher Daten nutzen. Unix
bietet nicht zufällig bis auf Dateiebene Attribute wie Dateinamen oder
Rechte, die von allen Anwendungen und Tools genutzt werden
können. Wenn man diese Möglichkeiten nutzt, bringt das gegenüber
Ansätzen wie der Windows-Registry oder einer Datenbank keine
relevanten Nachteile, aber den Vorteil, daß man Eintragungen auch mit
grep suchen und mit vi ändern kann sowie Bestandteile (also Dateien)
mit cp und mv bewegen kann.
Im Prinzip ist doch ein hierarchisches Dateisystem mit Dateien, die in
Zeilen aufgeteilt sind, die wiederum aus Tokens/Wörtern bestehen, die
30 Jahre alte Unix-Vorstellung einer einfachen Datenbank. Zur
Bearbeitung dieser Daten hat Unix sämtliche Werkzeuge an Bord, das
sieht man heute noch an allen Tools in /bin. Wenn einem diese Struktur
nicht reicht (was ich verstehen kann), dann sollte man doch trotzdem
die *Idee*, die dahintersteht, würdigen und fortführen anstatt sie
über Bord zu werfen und durch das geniale Konzept der Woche zu
ersetzen. Hierarchische Dateisysteme und Textdateien (mit
Zeilen/Wort-Struktur) gibt es seit über dreißig Jahren, die
Windows-Registry oder die WIN.INI-Syntax haben da eine wesentlich
kürzere Halbwertszeit.
Ich hielte die Integration von z.B. Versionsinformationen oder
Lockingmechanismen ins Dateisystem für einen wesentlich sinnvolleren
Ansatz als auf Applikationsebene Features für eine
Konfigurationsdatenbank zusammenzustricken. Zumal man sowas dann auch
z.B. für Dokumente nutzen könnte, ebenso wie einen XML-Parser, wäre er
eine Systemlibrary.
Du erklaerst mir bitte, wie man die sendmail.cf mit Deinen Ideen umsetzt.
Was Du benutzt sind spezialisierte Programme, deren Konfig laesst sich nicht
ohne weiteres in eine Konfigurationssprache aus einem Guß umsetzen.
Die allermeisten Programme kommen mit einer Standardkonfig daher,
die benutzbar ist. Dafuer gibt es dann auch Frontends. Willst Du
spezielle Sachen, musst Du wohl oder uebel dich mit den Formaten
auseinandersetzen.
Wenn die Probleme, die zu loesen sind komplexer werden, wird die
Konfiguration auch komplex.
stefan
> Was mich z. B. nervt, ist, daß man, will man z. B einen Nameserver
> administrieren, den man selbst aufgesetzt hat, weiß man (zumindest
> ungefähr ;), wo man die Zone-Dateien aufbewahrt. Weiß man das nicht, muß
> man erstmal in die Datei /etc/named.conf (oder ist es noch die alte
> Version, dann: /etc/named.boot) schauen, wo denn die zone-Dateien
> stecken. anschließend wechselt man dann in das entsprechende Verzeichnis
> (oder auch nicht) und es folgen: 'vi bla.fasel.net.zone' oder 'vi
> bla.fasel.net.reverse', etc., latürnich gefolgt von 'ndc reload', muß
> man wissen. Und das alles, obwohl, meiner Ansicht nach auf jeden Fall,
> doch eine offensichtliche Implikation vorliegt:
> Wenn ein Host in der Zone-Datei geändert wird, muß er auch in der
> Reverse-Datei geändert werden und außerdem muß der named informiert
> werden. Warum sollen diese Schritte nicht in einem Tool konzentriert
> werden oder anders gesagt: Dem System automatisch bekannt sein?
Genau hier liegt der Hase im Pfeffer. Ich will zu jedem Zeitpunkt
ueber das informiert sein, was mein System tut. Wenn es was tut, soll
es was tun, _wenn_ ich es ihm sage. Dies fuehrt letztlich zu Loesungen
- nicht zu workarounds. Wenn du aber obiges Verhalten willst (etwa
weil du oft was an dem files aenderst), hindert dich niemand ein
script darum herum zu basteln.
Noch was: So will ich mein System haben: Es gibt Programme und es gibt
configurationsfiles dafuer. Es wuerde mich total ankotzen, wenn ein
wildes durch die gegend upgedate startet, da ja eine offensichtliche
Implikation vorliegt. SuSE ist hart an der Grenze dessen, was ich da
noch ertragen kann.
Seit einiger Zeit schon verfolge ich diese Entwicklung sehr aufmerksam
- die bunti-klickis kommen. Mit dem starken rechten klickarm, da man
ja nicht merh sich mit der shell unterhaelt, sondern alles
erklickt. Das passt wunderbar zu der neuen _keine_sourcen_bewegung,
die genau das nicht haelt, was die klickis sich erhoffen. Am
Wochenende hatte ich noch auf meiner Dummyinstallation sdd
(ScitechDisplayDoc) getestet -- uahhh - da ging ja gar nichts mehr -
BSOD. Naja nur fast - man konnte sich noch einloggen. Fast koennte ich
glauben das evil Empire ist mit seiner FUD Methode schon sehr weit
gekommen.
//Tom
Die Grundidee ist, dass es einmal jemand richtig macht und zwar
am besten jemand, der auch etwas davon versteht... Meinst Du,
solche ein Library waere gegenueber einem Mitternachtshack eine
Verschlechterung? Dann solltest Du Dir auch ueberlegen, ob Du
die libc verwendest (in printf koennte schliesslich auch ein
Pufferueberlauf sein, der alle Deine Anwendungen betrifft).
>Ein hierarchisches Format wie XML würde mir wesentlich besser
>gefallen.
Schon. Letztendlich ist das konkrete Format egal, wenn es denn
nur alle Anwendungen benutzen wuerden.
>Im Prinzip ist doch ein hierarchisches Dateisystem mit Dateien, die in
>Zeilen aufgeteilt sind, die wiederum aus Tokens/Wörtern bestehen, die
>30 Jahre alte Unix-Vorstellung einer einfachen Datenbank.
Ein Dateisystem ist in der Regel (reiserfs hat teilweise
Ansaetze) keine Datenbank.
Eine Datenbank bietet Zugriff auf die Daten ohne, eine feste
Zugriffstruktur vorzuschreiben. Eine Datenbank kann Dir alle
Konfigurationswerte mit dem Wert "cobaltblue" aufzulisten wie
auch alle Konfigurationswerte mit dem Namen "farbe" oder alle
Konfigurationswerte der Anwendung "konsole". Wenn ein passender
Index existiert, ist jede dieser Anfragen
geschwindigkeitsmaessig derselben Groessenordnung. Auf jeden
Fall unterscheidet sich die Syntax der Anfrage nicht, egal ob
der Index benutzt wird oder nicht. Eine Datenbank kann Dir auch
andere Zusicherungen bezueglich der Integritaet und der
Granularitaet bei den Zugriffsrechten machen, bei denen ein
Dateisystem in der Regel nicht mithalten kann - ein Dateisystem
nimmt Objekte nun einmal unterhalb der Ebene "Datei" wahr, eine
Datenbank schon.
Ich weiss, welche Aspekte einer Datenbank mit einem Dateisystem
simulieren kann und welche nicht. ext2 ist noch nicht einmal
eine einfache Datenbank - sonst braeuchte man die Indices mit
den Offsets nicht.
Und nein, man will nicht anfangen, Datenbankstrukturen in den
Kernel einzufuehren. VMS ist nicht Unix - so etwas gehoert nach
Userland.
>s...@bigfoot.de (Thomas Reikat) ("TR") schrieb:
>TR> Noch ist das ganze Dateiwirrwar einigermaßen durchschaubar, aber eins
>TR> ist doch wohl sicher: Die Anzahl der Optionen und Anwendungen steigt
>TR> stetig. Schon jetzt ist ein Erheblicher Zeitaufwand nötig, um die
>TR> Zusammenhänge auch nur annährend zu begreifen. Irgendwann ist "schlutz
>TR> mit lutzig", dann blickt da kaum noch einer durch und Linux bleibt den
>TR> Experten, die es zehn Jahre lang studiert haben zugänglich, der Rest
>TR> setzt auf einfachere Systeme (ist das heute nicht schon ähnlich?)
Ich sehe das von dir skizzierte "Horror-Szenario" bereits heute:
in den nicht mehr klar zu durchschauenden Eintragen der Registry
in den verschiedenen Windows-Versionen (wobei fuer die exakt GLEICHE
Beduetung, wie z.B. Klartext-Passworte fuer SMB-Shares in Windows95,
Windows98 und WindowsNT unterschiedliche registry-Eintraege notwendig
sind, und das Default-Verhalten bei fehlen der Eintraege sogar zwischen
den NT4-Service-Packs unterschiedlich ist). Gegen das Chaos, das M$
dort eingerichtet hat, waeren die Linux-Konfigurationsdateien selbst
dann noch harmlos, wenn es davon 20 mal so viele gaebe...
>TR> Wenn ich mir ansehe, was die da mit KDE versuchen und was die da für
>TR> einen Aufwand treiben müssen, wird mir ganz anders. Wäre doch nett, wenn
>TR> es ein einheitliches Konfigurationsinterface geben würde, das die
>TR> Informationen (die ansonsten ja auch redundant in jeder Anwendung, die
>TR> sie nutzt vorliegen) Zentral zur Verfügung stellt:
>TR> SYSCONF_APPLICATION cfg_vi = new SYSCONF_APPLICATION("vi");
>TR> SYSCONF_DIALOG dlg = new SYSCONF_DIALOG(cfg_vi);
>TR> dlg->execute();
>TR> Und das ganze ohne daß man für jede Anwendung einen eigenen Handler
>TR> implementieren muß. Die Informationen kommen komplett aus der Datenbank
...die dann evt. so "sauber" (???) strukturiert ist, wie die Windows-
Registry? Nein Danke, dann schon lieber ein Chaos mit 10000 separaten
ASCII-Konfigurationsdateien, dass ist einfacher zu ueberblicken...
Tschuess,
Juergen Ilse (il...@asys-h.de)
>Genau hier liegt der Hase im Pfeffer. Ich will zu jedem Zeitpunkt
>ueber das informiert sein, was mein System tut. Wenn es was tut, soll
>es was tun, _wenn_ ich es ihm sage. Dies fuehrt letztlich zu Loesungen
>- nicht zu workarounds. Wenn du aber obiges Verhalten willst (etwa
>weil du oft was an dem files aenderst), hindert dich niemand ein
>script darum herum zu basteln.
Klar, das ist einer der großen Vorteile von Linux! Wenn ich etwas
ändere, weiß ich genau, was ich getan habe. Ich bilde mir allerdings
ein, daß man das auch auf einem anderen Weg erreichen kann.
>Noch was: So will ich mein System haben: Es gibt Programme und es gibt
>configurationsfiles dafuer. Es wuerde mich total ankotzen, wenn ein
>wildes durch die gegend upgedate startet, da ja eine offensichtliche
>Implikation vorliegt. SuSE ist hart an der Grenze dessen, was ich da
>noch ertragen kann.
Völlig korrekt! Suse hat wenigstens die Möglichkeit vorgesehen, alle
ungewollten Effekte zu deaktivieren (im Gegensatz zu M$), allerdings
bietet Suse in der rc.config wirklich nur einen Minimalsatz an
Konfigurationsoptionen. Nebenbei halte ich Suses Ansatz insofern für
daneben, als daß sie nur eine weitere Ebene in die Konfiguration
einbauen. Im Augenblick ist das zwar garnicht anders zu realisieren,
aber im Prinzip erleichtert dieses Prinzip die Grundkonfiguration auf
Kosten einer fortgeschritteneren Administration.
>Seit einiger Zeit schon verfolge ich diese Entwicklung sehr aufmerksam
>- die bunti-klickis kommen. Mit dem starken rechten klickarm, da man
>ja nicht merh sich mit der shell unterhaelt, sondern alles
>erklickt. Das passt wunderbar zu der neuen _keine_sourcen_bewegung,
>die genau das nicht haelt, was die klickis sich erhoffen. Am
Ich sehe das eigentlich so, daß jede Methode ihre Vor- und Nachteile
hat...
Es ist doch so, daß man einige Arbeiten besser auf der Shell und andere
besser auf der GUI erledigen kann. Der Vorteil bei der GUI ist m. E.,
daß man intuitiv erfassen kann, welche Parameter wie zusammenhängen,
ohne sich durch die Manualpages zu hangeln. Bei der Shell ist der
Vorteil, daß man gleichartige Aufgaben mühelos in einer Schleife
abarbeiten kann und 'unscharfe' Aufgaben auch mit der nötigen
'Unschärfe' formulieren kann.
Ich sehe mich eigentlich weder als bunti-klicki noch als shelli-tippi ;)
Wie wär's mit kombi-machi-besti-draussi :))
Im Ernst: Wär das nicht genital, ein komplett objektorientiertes System
vor sich zu haben, in dem jede Komponente, jede Anwendung und jeder
Benutzer einfach einen Satz von Eigenschaften und Methoden mitbringt,
die zentral vorgehalten werden, möglichst vererbbar sind, platzsparend
gespeichert werden, flexibel gesetzt und geändert werden können, ...
Ich sehe irgendwie auch nicht den Unterschied zwischen einem reinen
ASCII-Editor und einem speziellen DB-Tool. Notfalls könnten CRCs helfen,
korrumpierte Teile der DB abzufangen und spezielle darauf angesetzte
Tools auch auf Low-Level-Sektorebene die Daten wieder zum Leben
erwecken. Ob ich nun Sektoren direkt bearbeite, oder versuche, die Daten
einer DB auf Sektorebene zu restaurieren, kompliziert wird es in jedem
Fall.
>Wochenende hatte ich noch auf meiner Dummyinstallation sdd
>(ScitechDisplayDoc) getestet -- uahhh - da ging ja gar nichts mehr -
>BSOD. Naja nur fast - man konnte sich noch einloggen. Fast koennte ich
>glauben das evil Empire ist mit seiner FUD Methode schon sehr weit
>gekommen.
sdd für Linux?!?
Man sollte trotzdem nicht soooo Schwarz sehen ;)
>//Tom
bye sAm
>>Ziemlich kryptisch, oder? Gab's dafür auch sowas wie ein GUI-Tool?
>Scroll bitte noch einmal zurueck zu der Stelle, wo ich ueber
>smit und das Web-Administrationstool geschrieben habe. Die
>generieren die entsprechenden Kommandozeilen fuer Dich.
Sorry, hab' ich wohl überlesen...
>>Hmm, ob eine Firma, noch dazu in der Größe der IBM, so etwas wie
>>Fantasie entwickeln kann, möchte ich mal in den Raum stellen :))
>IBM entwickelt keine Fantasie, aber IBM-Mitarbeiter tun das
>schon. Wenn die Firma sie laesst, jedenfalls.
;)
>>Außerdem ist AIX, soweit ich weiß, ja wohl Löhnware und hat mit
>>OpenSource nicht allzuviel am Hut.
>Das hindert niemanden daran, eine gute Idee zu kopieren. Zumal
>die Manualpages und weitere Informationen im Web frei verfuegbar
>sind -> Tellerraender ueberwinden! PAM zum Beispiel hat auch
>nicht als Open Source angefangen. Trotzdem ist es, sobald die
>Kinderkrankheiten ausgebuegelt sind, eine Gute Idee (tm).
Hmmm, Tellerränder waren eigentlich nie ein Problem für mich, wohl aber
für die Leute, die ich damit konfrontiert habe ;)
AIX ist doch eigentlich nur ein übergestülpter Aufsatz (soweit ich das
in den richtigen Hals bekommen habe) und bis vor einigen Tagen kannte
ich AIX auch nur aus den Überschriften von Zeitschriften...
Von PAM habe ich noch nichteinmal etwas gehört...muß ich mich nochmal
schlau machen...
>Es ist jedenfalls ueberhaupt nicht einzusehen, warum jeder
>Programmierer von vorne anfangen muss, Buffer Overflows in seine
>Programme einzubauen. Es ist auch nicht einzusehen, warum man
>als Anwender oder Admin n Konfigurationsdateiformate fuer n+4
>Programme lernen sollte.
Zum Ersten: Irgendwann ist sowieso mal ein Schnitt fällig.
Zukunftsträchtig ist ASCII-Text-parsing auf jeden Fall nicht. Und ich
sehe es so: Wenn ein standardisiertes Interface existiert, das den
Entwicklern die Möglichkeit in die Hand gibt, ihre Konfiguration frei zu
gestalten und auf einfache Art und Weise zu verwalten, werden sie diese
Möglichkeit auch nutzen. Und wenn sie es geschafft haben, ASCII-Files zu
bändigen, werden sie mit einer Datenbank genauso zurechtkommen.
Zum Zweiten: <sig>
>Sicherlich ist es sinnvoll, die eigentlichen
>Konfigurationsdateien als ASCII vorliegen zu haben, damit man im
>Notfall auch mit less, grep oder joe dabei gehen kann. Ebenso
>ist es sicherlich sinnvoll, parallel dazu binaere Indices in
>diese Dateien aufzubauen, um den Zugriff zu beschleunigen.
Wo liegt denn der Unterschied zwischen less, grep und vi (nur die harten
komm'n in Garten ;) und dbless, dbgrep und dbvi? Das hängt doch nur von
der Implementation ab. Ob die Daten nun als ASCII oder als DB vorliegen,
wech ist wech, und, die entsprechenden Tools vorausgesetzt, kann man
ASCCI-Daten genauso gut oder schlecht rekonstruieren wie alle anderen
Daten.
>Binaere Indices heisst nicht, dass irgendwelche
>Konfigurationsinformationen selbst in binaer vorliegen, sondern
>es wuerde sich um Paare der Art ( parameter, offset)
>handeln, mit denen die Bibliothek schnell den Seek-Offset fuer
>einen gegebenen Parameter in die Datei finden kann:
Und dann fügt man mal eine Zeile ein und darf den indexer losschicken,
der durch sämtliche Files rötert.
> if (newer(file, index))
> rebuild_index(file);
> offset = get_offset(parameter, file);
> value = get_parameter(parameter, file, offset);
Und im extremfall wartet man 20 Minuten...
>oder so. Durch die Beschraenkung auf flat files kastriert man
>sich lediglich beim Schreiben/Aendern/Einfuegen von Parametern,
>weil man in ASCII-Files nun einmal nichts einfuegen oder
>loeschen kann, ohne die Datei komplett neu zu schreiben (ISAM
>wuerde sicherlich schneller sein). Auch Locking muesste man
>sorgfaeltig in den Griff bekommen.
Nuja, ISAM auf hunderte von Files loszulassen verkompliziert die Sache
doch erheblich. Und irgendwann kommen einige Entwickler dann mal wieder
auf die Idee, ihr Komfigurationsfile umzubenennen (s. bind) und schon
funzt garnichts mehr...
>Andererseits ist eine binaere Konfigurationsdatenbank mit der
>Masse der ideologisch Zugebretterten in der Linux Community
>ueberhaupt nicht durchsetzbar: Das ist ja wie Windows und damit
>muss es zweifelsfrei Scheisse sein.
Windows ist Chaos, und nur insoweit durchdacht, wie man den User in die
Flucht schlagen kann ;)
Und wenn ich weiterdenke, bin ich mir garnicht sicher, ob es dann noch
Linux wäre, was ich da bediene. Im Endeffekt wäre es ein
objektorientiertes OS, welches mir aber letztendlich genau die
Freiheiten läßt, die ich von Linux gewohnt bin, auf der anderen Seite
aber den Komfort gewährt, einige Sachen 'mal eben so' zu konfigurieren.
>laesst man die Operation ausfuehren und bekommt im smit.script
>in seinem Home auch dieses Kommando mitgeloggt. Das kann man
>sich ausschneiden, eine "for i in ...; do ...; done"-Schleife
>drumwickeln und so die folgenden 200 aehnlichen Operationen
>automatisch erledigen lassen.
hmmm,
for app in §system.application do ;
if $app.root_path eq "/usr/local" then ;
app.move_root "/usr/neue_pladde" ;
fi ;
done
fänd' ich da praktischer und statt der absoluten Pfade verwenden andere,
involvierte Tools dann '§system.application("TheApp").root_path'...
>Dazu kommt, dass durch den Methoden-Mechanismus der ODM das
>ganze System recht einfach erweiterbar ist: [...]
Klar, ist aber trotzdem nur übergestülpt: So eine Art virtuelle
OO-Lösung ;)
>Was die Namen der Kommandos angeht: Das System mit den Prefixen
>ist gewoehnungsbeduerftig, aber sehr systematisch. Wenn man
>einen Befehl zum Anlegen von etwas kennt ("mkuser" zum Anlegen
>von Benutzern, "mkpv" zum Anlegen eines physical volume, "mkque"
>zum Anlegen einer Printer Queue), dann ist es sehr
>wahrscheinlich, dass man die entsprechenden Tools zum Auflisten
>("lsuser", ...), Aendern ("chuser", ...) oder Loeschen
>("rmuser", ...) ebenfalls zur Verfuegung hat.
Klar, was ist nicht gewöhnungsbedürftig. Ich hab mich auch schon mit
Netware rumgeschlagen, das ist im Prinzip ähnlich. Ich finde es auch
ziemlich schlüssig, trotzdem halte ich es für viel zu unflexibel. Wie
gesagt: ein Parameter ändert seinen Namen und du wartest auf ein Update
oder auf der anderen Seite fährst du weiter die alte Version...
>>werden. Warum sollen diese Schritte nicht in einem Tool konzentriert
>>werden oder anders gesagt: Dem System automatisch bekannt sein?
>Weil es noch niemand gehackt hat. Wobei man solche
>Abhaengigkeiten wie bei Deinem Nameserver-Beispiel nicht mit
>einer reinen Konfigurationsdatenbank erschlagen kann, sondern
>wie bei AIX schon Code braucht, der solche Abhaengigkeiten kennt
>und die passenden Aenderungen in der Konfigurationsdatenbank
>macht.
Hast ja Recht, am Ende würde das auf ein neues OS hinauslaufen, und
sowas entsteht nunmal nich alle Tage...
Allerdings glaube ich schon, daß man den Code genauso in die DB
integrieren kann, wie alles andere. Nur überläßt man es halt einem
Schalter, ob diese Aktualisierung automatisch vorgenommen werden soll.
>Die Reihenfolge ist schon ganz okay:
>Ganz unten eine Bibliothek ("libconfig.so"), die Funktionen zum
>Lesen und Schreiben von Konfigurationsdatensaetzen in
>ASCII-Dateien hat. Diese Bibliothek wuerde auch Indices
>verwalten und ggf. automatisch auf Stand halten. Sie haette
>ausserdem selbst oder in einer zweiten Bibliothek
>("libconfigcompat.so") Funktionen zu haben, mit der man
>Synchronisation zwischen dem einheitlichen
>Konfigurationsdateiformat und den Legacy-Formaten (passwd,
>group, hosts, ...) herstellen koennte.
Ja, so in der Art, wobei er Zwischenschritt mit den ASCII-Dateien m. E.
allerdings überflüssig wäre ;), wohingegen ich den Rückschritt mit der
libconfigcompat.so allerdings auch sehr begrüßen würde...
>Darauf aufsetzend waere dann eine ganze Schar von externen
>Kommandozeilenbefehlen vorhanden, die fuer jedes Subsystem
>(Benutzer, Drucker, NFS, SMB, Nameserver, Inetd, Webserver, ...)
>entsprechende Eintraege verwalten wuerden und die zusaetzliches
>Wissen um komplexe Abhaengigkeiten haben, wie Du sie beschrieben
>hast. Zugleich wuerden diese Befehle SUID root laufen, aber
>abpruefen, dass der Aufrufer Mitglied in einer
>subsystemspezifischen Gruppe ist. Dadurch koennte man
>Konfigurationsaenderungen durchfuehren, ohne root werden zu
>muessen. Man muesste dafuer aber fuer die Gruppe adm_user,
>adm_printer, adm_nfs, ... eingetragen sein (oder Mitglied in adm
>werden, wenn man das alles duerfen koennen soll).
Nuja, ein Kommando mit den benötigten Parametern und eine Menge
spezialisierter Shellscripts würden es da auch schon tun, ansonsten
könntest du dich vor Redundanzen whrscheinlich kaum noch retten...
>Schliesslich wuerde man ein lokal laufendes und ein
>webgestuetztes Tool entwickeln, dass Aufrufe fuer diese
>Kommandos interaktiv erstellen kann und dass auch unbedarfte
>Admins durch den Konfigurationsprozess fuehrt. Auf diese Weise
Hmmm, das webgestützte Tool kann man ja auch lokal verwenden, das reicht
;)
>kann man ohne viel Ahnung zu haben sein System administrieren,
>nimmt aber nebenbei die Sytax der erzeugten Kommandos wahr und
>kann jederzeit aus der graphischen Oberflaeche ausbrechen und
>auf die Kommandozeilenebene runter, um zu scripten.
Ist was dran, führt aber auch dazu, das man als Erfahrener Anwender
nicht unbedingt jeden PillePalle zu Fuß erledigen muß, sondern auch mal
das Taxi nehmen kann ;)
>Kristian
bye sAm
> KK> - Es ist eine Quelle von Sicherheitsluecken.
> KK> Unzaehlige Einbrueche in Systeme sind nur deswegen moeglich
> KK> gewesen, weil irgendjemand sich zwischen Mitternacht und ein Uhr
> KK> in der Frueh hingesetzt hat und noch schnell ein Konfiginterface
> KK> auf seine Anwendung gehauen hat, bevor er sie released hat.
> KK> Dabei hat er selbstverstaendlich wegen der ueberragenden
> KK> Faehigkeiten von C zur Speicherverwaltung und zur
> KK> Stringbearbeitung Fehler gemacht, die zu ausbeutbaren Buffer
> KK> Overflows gefuehrt haben.
> Mag sein. Aber ist ein (notwendigerweise komplexes) zentrales System
> in dieser Hinsicht besser, wenn ein Bug dort dann potentiell *alle*
> Anwendungen betrifft?
Natürlich. Mag ja sein, daß potentiell Bugs vorhanden sind, obwohl man
das mit den verfügbaren Überprüfungsprogrammen (EFence, etc.) sicher
größtenteils überprüfen kann. Dafür wird das Programm aber auch von
einer Masse von Programmierern überprüft und Bugs werden schnell
bereinigt. Das führt zu einem extrem stabilen Programm in extrem kurzer
Zeit. Simple Logik. Etwas, was ich bei der Diskussion über neue
Technologien z.B. auf der Kernel-Mailingliste öfters schwer vermisse.
--
Ciao, Heiko...
Thomas Reikat <s...@bigfoot.de> wrote:
>On 11 Apr 1999 14:58:05 GMT, j...@gmx.net (Jochem Huhmann) wrote:
>Hmm, ich könnte mir auch solche Konstrukte vorstellen:
>/user/root/var/nameserver
> HOST: ONLINE = {"ns1.provider.de", "ns2.provider.de"}
> HOST: OFFLINE = "ns.local"
Die "richtige" Variante waere ein lokaler CACHE-ONLY Nameserver, der
auf den Nameserver des Providers als forwarder zugreift. Ist man off-
line koennen eben (wegen fehlender route zum Provider) nur lokale Namen
aufgeloest werden... Da man da auch mehrere Nameserver eintragen kann,
und zusaetzlicher traffic durch Mehrfach-Abfragen dank "caching" ver-
mieden werden koennen, ist das wohl auch die optimale Loesung, also
wozu obiges Konstrukt (obwohl man auch so etwas mit etwas shellscript
realisieren koennte...)?
>cfg /system/ip/nameserver = /user/root/var/nameserver/ONLINE
>cfg /system/ip/nameserver = /user/root/var/nameserver/OFFLINE
>..was aus meiner Sicht den Vorteil hat, daß man gezielt einzelne
>Optionen ändern kann. Will man heute in einer Textdatei eine einzelne
>Option ändern, artet das schon fast in hoher Programmierkunst aus.
Warum? Wem sed, awk oder perl gelaeufig sind, der sollte das in wenigen
Minuten hinbekommen, wer mit den ueblichen unix-tools nicht umgehen kann,
wuerde vermutlich auch bei deiner Loesung das System zerschiessen koennen.
>Es ist zwar schnell mit dem umhängen eines links getan, allerdings liegen
>die Daten dann auch mehrfach auf der Platte rum.
Was auch durchaus korrekt ist. Nehmen wir das Beispiel mit der resolv.conf:
Wenn ich mich bei einem anderen Provider einwaehle, moechte ich nicht nur
einen anderen Nameserver verwenden, sondern ebenfalls einen anderen (zum
jeweiligen Provider passenden) Domain-Search-Path, mehr als diese beiden
zu aendernden Eintraege stehen aber in der Datei gar nicht drin, also
waere es voellig sinnlos, nur einzelne Eintraege darin aendern zu wollen...
>Nuja, unter strukturierte Daten kann man /etc beileibe nicht laufen
>lassen. Man muß schon ganz genau wissen was man sucht um überhaupt
>irgendetwas zu finden.
Ich finde auch bei einer mir voellig unbekannten Distribution mit Dutzenden
von Distributionsspezifischen Konfigurationsdateien unterhalb von /etc die
von mir gesuchten Eintraege immer noch ERHEBLICH SCHNELLER, als ich irgend
welche Eintraege in der Registry von Windows finde... In den Dateien in
/etc kann ich wenigstens noch mit grep nach passenden Eintraegen suchen,
oder ich kann mir in den entsprechenden init-scripten ansehen, auf welche
Variablen denn zugegriffen wird, diese eigenschaften habe ich bei der
Registry nicht (und meistens fehlt auch noch die Dokumentation, welche
Werte fuer einen Eintrag moeglich sind, und welche Bedeutung die einzelnen
Werrte haben...).
>Nope, ein falsches Zeichen in einer Textdatei kann die ganze
>Konfiguration den Bach runterschicken. In einer Datenbank, die mit
>typisierten Daten umgeht, kann man diese Fehler schon bei der Eingabe
>abfangen.
...deswegen koennen ja auch Fehler in der Registry bei Windows nicht
vorkommen... Erzehl das mal den Leuten, denen Windows abgeschmiert ist,
weeil die Registry in sich nicht mehr konsistent war, die werden dir
schon die passende Antwort geben!
>Klar kann man das, allerdings muß diese dann immer manuell auf dem
>laufenden gehalten werden. Wenn mal ein Programmierer auf die Idee
>kommt, irgendeinen Parameter in der neuen Version umzubenennen kannst du
>das Tool fürs erste in die Tonne treten und auf eine aktualisierte
>Version warten oder selber etwas stricken.
Da die relevanten Eintraege in den Distributionsunabhaengigen Konfigu-
rationsdateien auf fast allen unix-Systemen seit fast 30 Jahren weit-
gehend gleich geblieben sind, sehe ich da weniger Probleme, bei Windows
sind die entsprechenden Eintraege z.T. noch nicht einmal zwischen den
zeitlich parallel entwickelten Windows-Versionen gleich geblieben...
>Würden sämtliche Parameter mitsamt Beschreibung aus einer Datenbank
>stammen, würde diese Parameteränderung automatisch mitlaufen, ohne das
>jemand Hand an den Code des Tools legen müßte.
Aber mit den Konsistenzpruefungen ist es dann z.T. vorbei, wie man an
Windows sehr schoen beobachten kann: Auch wenn der prinzipielle Aufbau
der Registry unter Win95/98/NT gleich zu sein scheint, sind die Eintrae-
ge teilweise voellig unterschiedlich, eine Konsistenzpruefung ist annae-
hernd unmoeglich geworden, weil man sich nicht auf die Bedeutung und die
zulaessigen Werte der Eintraege verlassen kann (die sind z.T. bei den
Systemen unterschiedlich)...
Ich gebe ja zu, dass die Windows-Registry eines der abschreckendsten
Beispiele ueberhaupt ist, aber evt. gerade deshalb als Gegenbeispiel
fuer deine Argumentation geeignet.
Tschuess,
Juergen Ilse (il...@asys-h.de)
Andreas Barth <a...@muenchen.pro-bahn.org> wrote:
>Was ich mir vorstellen könnte wäre, das ein Pseudo-fs auf /etc
>gemountet wird, sobald das System richtig oben ist. Dann werden
>alle Änderungen, die vor dem Mounten des Pseudo-fs (sprich: im
>Fehlerfalle von Hand) oder im gebooteten Zustand gemacht werden
>in eine Datenbank übernommen, die diese Infos konsistent hält.
>Die gleichen Daten sind dann auf verschiedene Art und Weise zu
>bearbeiten. (Beispiel: passwd- ist über eine History von passwd
>realisierbar, pam.conf und pam.d/ können den gleichen Inhalt
>haben, ...) Die wichtigsten Dateien werden regelmäßig _als_ _Text_
>nach /etc geschrieben. Damit kann im Normalbetrieb weiterhin
>alles mit einem Texteditor gemacht werden, ebenso können im
>Notfall von einer Bootdiskette aus die wichtigsten Dateien von
>Hand modifiziert werden. Gleichzeitig gibt es für neuere Tools
>effizientere Schnittstellen.
Das wuerde auf "doppelte Buchfuehrung" hinauslaufen (und evt. wiederum
zum Chaos, wenn eine oder beide Versionen in sich nicht mehr konsistent
sind)... Da fragt man sich doch wiederum "wozu?" und kommt zu dem Schluss,
dass man eigentlich nichts gwonnen, sondern nur die Nachteile beider
Systeme vereint hat...
Die Effizienz mag zwar evt. ein Argument sein, aber mal ehrlich: Hast
du wirklich SOOO VIELE Konfigurationsdateien auf dem Rechner, dass ein
etwas effizienteres auslesen zu grossen Geschwindigkeitsvorteilen fueh-
ren wuerde? Ich jedenfalls nicht, und da z.B. ein Nameserver seinen
cache (der den Neustart i.d.R. nicht ueberdauert) intern in einem ei-
genen Format verwaltet, tritt das Performance-Problem (wenn es eins ist)
doch nur beim Neustart auf (weshalb sollte man den Nameserver dauernd
neu starten?)...
Tschuess,
Juergen Ilse (il...@asys-h.de)
KK> j...@gmx.net (Jochem Huhmann) writes:
>>Mag sein. Aber ist ein (notwendigerweise komplexes) zentrales System
>>in dieser Hinsicht besser, wenn ein Bug dort dann potentiell *alle*
>>Anwendungen betrifft?
KK>
KK> Die Grundidee ist, dass es einmal jemand richtig macht und zwar
KK> am besten jemand, der auch etwas davon versteht... Meinst Du,
KK> solche ein Library waere gegenueber einem Mitternachtshack eine
KK> Verschlechterung? Dann solltest Du Dir auch ueberlegen, ob Du
KK> die libc verwendest (in printf koennte schliesslich auch ein
KK> Pufferueberlauf sein, der alle Deine Anwendungen betrifft).
Ich sag ja: Mag sein. Andererseits ist printf gegenüber einer Library,
die evtl. auf einem binären Datenklumpen von Konfigurationsdaten
arbeitet, eine ziemlich simple und beherrschbare
Angelegenheit. Außerdem reden wir hier von freier Software, ein
Programm, das seine Konfiguration nicht sauber parsen kann, wird sich
nicht sehr weit verbreiten. Mir persönlich ist die jetzige
funktionierende Anarchie lieber als eine monolithische Endlösung, die
mir im Fehlerfall beim Schreiben der Konfiguration eines
nebensächlichen Programms vielleicht die gesamte Systemkonfiguration
zersägt. Ein "Mitternachtshack" zerschießt vielleicht seine eigene
Konfiguration, ja und? Mir geht es eigentlich nur darum, das ein
feingranulares System, das die Auswirkungen von Bugs (die es immer
geben wird) eingrenzt, einfach sicherer und zuverlässiger ist.
>>Ein hierarchisches Format wie XML würde mir wesentlich besser
>>gefallen.
KK>
KK> Schon. Letztendlich ist das konkrete Format egal, wenn es denn
KK> nur alle Anwendungen benutzen wuerden.
Ein Format, daß nur für die Hälfte der Anwendungen brauchbar ist,
macht keinen Sinn. XML ist extrem flexibel, trotzdem einfach zu
parsen, kann mit einfachsten Mitteln auf Integrität gecheckt werden
und notfalls auch problemlos zu Fuß zu bearbeiten. Und es ist in
keiner Weise eine Insellösung, es gibt Editoren und Tools dafür in
rauhen Mengen. Und es taugt nicht nur für Konfigurationen, es taugt
für praktisch alle Zwecke, wo man nicht-binäre Daten strukturiert
unterbringen muß.
>>Im Prinzip ist doch ein hierarchisches Dateisystem mit Dateien, die in
>>Zeilen aufgeteilt sind, die wiederum aus Tokens/Wörtern bestehen, die
>>30 Jahre alte Unix-Vorstellung einer einfachen Datenbank.
KK>
KK> Ein Dateisystem ist in der Regel (reiserfs hat teilweise
KK> Ansaetze) keine Datenbank.
Ja, Ok, ich will mich nicht um Worte streiten. Nenn es
"Datenablagesystem".
KK> Und nein, man will nicht anfangen, Datenbankstrukturen in den
KK> Kernel einzufuehren. VMS ist nicht Unix - so etwas gehoert nach
KK> Userland.
Was ich meinte: Eine Datei hat einen Namen, einen Ort im Dateisystem
und Attribute wie Besitzer, Rechte etc. Alle jetzigen
Konfigurationsmechanismen verwenden diese Features, weil sie einfach
da sind. Weil sie aber auch für alle anderen Zwecke da sind,
unterstützen sie auch alle anderen Tools. Deshalb kann ich die
Konfiguration eines Systems zum allergrößten Teil mit einem Backup von
/etc sichern, einzelne Bestandteile der Konfiguration mit cp oder mv
gezielt anfassen oder Rechte verteilen. Haargenau die gleichen
Mechanismen kann ich aber auch z.B. für meine Dokumente verwenden.
Es wäre schön, wenn Features dort eingebaut werden, wo sie auch für
andere Verwendungszwecke nützlich sind und neue Möglichkeiten
eröffnen. Sowas ist entscheidend für den Erfolg von freier Software,
ein XML-Parser als Systemlibrary wäre eben nicht nur für
Konfigurationsdateien brauchbar.
Jochem
KK>
KK> Kristian