Man kann sagen, was man will, aber Yast ist eins der besten Konfigtools, die es für Linux gibt. Auch as alte Mehr, dass SuSE Configdateien überschreibt, stimmt schon lange nicht mehr, da Yast die alten Configfiles immer wegsichert (Name.rpmnew). Jetzt können Entwickler das noch so ändern, dass z.B: immer die bestehende Datei bestehen bleibt, und die Configdatei vom neuen Paket als Backup gesichert wird. Yast ist sehr gut, um z.B: Hardware einzurichten etc. Ich finde diesen Schritt von SuSE sehr gut. Das wird dazu beitragen, dass auch andere Distributionen die Möglichkeit haben, ein einheitliches Konfigtool einzusetzen.
Erstaunlich nicht wahr? Wie sich die Gurus gegen ein Tool währen. Ist das denn so schlimm das jezt jeder Schüler X einrichten kann? Ich finde es prima! YAST ist ein Tool, ok? also irgendwas was hilft. Wer es nicht mag kann nach wie vor mit "blossen händen" es machen. Na dann viel Spass.
Standard sollte ein brauchbares Update-Verfahren sein. Das jetzige ist nervig. Ganz blöd beim Bastlersystem gentoo. Die Konfigurationsverzeichnisse werden mit ._cfg* Dateien zugemüllt. Zumutung so was. Da sind mir die paar rpmsave zwar lieber, aber eigentlich taugt auch das nix. Da muss sich was tun.
Äh, sollte man nach einem Update bei Gentoo nicht etc-update aufrufen? Das dient eigentlich dazu die neuen Konfigurationsdateien (*._cfg*) mit den bisherigen zusammenzufügen. In diesem Prozess werde dann die ._cfg* Dateien auch gelöscht.
Ganz ehrlich, mein Verhältnis zu YAST ist gespalten, zu viele Fehler waren in der Vergangenheit in diesem Tool. Aber SuSE war mit YAST der einzige Distributor, der den Ansatz, eines einheitlichen Tools für die ganze Systemkonfiguration konsequent gegangen ist. Das macht die Konfiguration für den Laien/PC-Nutzer möglich, für den Profi effektiv. Ich war unter SuSE 7.2 mit dem YAST1 immer schneller am Ziel, als unser "Profi"-Admin mit vi.
Und das ist ja der Vorteil von YAST: Leute, die sich so wahnsinnig toll finden, daß sie die Hilfe von YAST nicht brauchen, können ja weiterhin auf der Komandozeile die Konfigurationsdateien verstümmeln. YAST hindert sie daran exakt gar nicht.
> ... YAST nicht brauchen, können ja weiterhin auf der Komandozeile die > Konfigurationsdateien verstümmeln. YAST hindert sie daran exakt gar nicht.
Hi, das Problem von Yast (sorry kenne die aktuelle nicht mehr bin schon lange erst von Suse'97 -> zu RedHat & Debian) war definitive das Yast probleme mit den "Original" Config Dateien hat. Config.rc - yast, manuelle Aendereungen waren weg :-(
Von Der Professor am Mi, 21. April 2004 um 00:57 #
Ich denke mal, ein weiteres Problem war, daß YaST sehr gut seinen Dienst verrichtet hat, aber SuSE zu früh (standardmäßig) auf YaST2 umgestiegen ist. Die ersten Versionen waren (insbesondere in der Textversion) eine ziemliche Zumutung. Man hatte allerdings immer die Möglichkeit YaST1 als funktionierende Alternative einzusetzen. Wie dem auch sei, inzwischen finde ich, daß YaST2 so ausgereift (evtl. nicht 100% fehlerfrei, aber welche Software ist das?) ist, daß man es getrost als Standardadministrationsprogramm einsetzen kann. Der Vorteil ist, daß man das gesamte System administrieren kann. Der Vorteil, wenn es jetzt offen ist, ist, daß es sich jetzt wohl schneller entwickelt. Das kann nur von Vorteil sein und führt evtl. tatsächlich zu einem universell verwendbaren Konfigurations- und Administrationstool für sämtliche Distributionen (fände ich zumindest super).
Das beste Konfigurationstool ist und bleibt das Wissen das Administrators. Yast trägt in keiner Weise dazu bei - im Gegenteil :(
Er überschreibt aktuell keine Konfigurationen mehr, aber die Benutzung ist mehr als Umständlich und die Geschwindigkeit sehr langsam. Ob er in anderen Distro's Einzug hält ist fraglich.
> fest steht das anfänger damit gut zurecht kommen und profis sowieso alles pr hand machen. was also ist falsch an yast?
Das Problem ist doch: SuSE/Yast will (wie Windoof) dem User alle Arbeit abnehmen und meint, alles besser zu können. Manchmal stimmt das ja auch;-) Aber die Folge ist, dass der Unterbau von SuSE so kompliziert (und manchmal fehlerhaft) geworden ist, dass auch viele alte Hasen nicht mehr durchblicken. Zur manuellen Konfiguration (d.h. ohne Yast) ist SuSE absolut ungeeignet
> Er überschreibt aktuell keine Konfigurationen mehr, aber die Benutzung ist mehr als > Umständlich und die Geschwindigkeit sehr langsam.
Ich finde Yast auch sehr langsam und das für mich einer der Gründe SuSE gegen eine andere Distri auszutauschen..
Ich hatte vor einiger Zeit mal ins Forum geschrieben, das Yast sehr lahm sei... Und prompt musste ich das mit irgendwelchen Beispielen "beweisen".. (ist ja mitlerweile standart) -maul-
Trotzdem begrüße ich die öffnung von yast.. stefan
Damit mal eine vernünftige Meinung kommt: ich stimme dir voll zu. Benutze zwar Debian und Gentoo, hätte aber gegen ein gutes, einfaches Konfigurationsprogramm wie YaST nichts auszusetzen. Naja, manchen machts ja Spaß, erst 10 Seiten Doku zu lesen, um vielleicht mal ihren Drucker einzurichten, mit YaST gehts mit ein paar Klicks und selbsterklärend.
Das apt-get ist einer der Hauptvorteile von Debian gegenüber SuSE. Nun gibt es mit apt4rpm auch für SuSE eine solche Lösung.
http://apt4rpm.sourceforge.net/
Hat jemand damit Erfahrungen gemacht? Ist das Ding brauchbar oder sollte man lieber die Finger davon lassen? Eignet es sich schon für Business-Serveranwendungen?
Manche Provider (z.B. 1&1) bieten Rootserver ja nur mit Suse an. Da wäre ein apt-get wirklich praktisch.
Also ich hab mit letztens die SuSe 8.2 aufs Notebook gespielt, apt4rpm nachgeschoben und ein komplettes update auf die 9.0 gemacht. das ganze ist relativ unproblematisch zumindest bei mir gewesen, wenngleich ich erstmal eine menge pakete deinstallieren musste, wg. abhängigkeiten, was im normalen betrieb nicht vorkommt... insgesamt weder besser noch schlechter als apt4deb
Ich nutze es auf meinem Home-PC und bin damit an sich zufrieden. Bisher war das größte was ich damit gemacht habe, ein wechsel der KDE Version von SuSE 3.1 zu 3.2
also, ich nutze apt-get auf zwei servern und zu Hause...seit ca. 1,5 Jahren. Läuft super, ist einfach zu bedienen und Probleme hatte ich bisher auch noch keine. Empfehlung des Hauses !!!
schon seltsam: man will auf suse 9.0 der dependency-hell mit apt4rpm entfliehen. die installation von apt4rpm scheitert aber an abstrusen abhaengigkeitsproblemen.
Nun, dann machst du etwas falsch, mein apt4rpm lies sich problemlos unter 9.0 installieren, oder Abhängigkeitsprobleme. Du kannst auf deren HP im grunde auch alle Libs runterladen die du brauchst
Obwohl die Installation sicher einfacher sein könnte
# apt dist-upgrade Lese Paketlisten... Fertig Erzeuge Abhängigkeitsbaum... Fertig Berechne Upgrade... Fertig Die folgenden Pakete werden upgegradet werden: cdrecord ucdsnmp 2 Pakete upgegradet, 0 neu installiert, 0 entfernt und 0 nicht upgegradet. Muss 0B/814kB an Archiven holen. Nach dem Auspacken werden 9323B zusätzlicher Plattenplatz benutzt werden. Wollen Sie fortsetzen? [J/n] Führe RPM aus (-Uvh)... Fehler: Failed dependencies: ucdsnmp = 4.2.6-125 is needed by ucdsnmp-4.2.6-152 cdrecord = 2.01a18-27 is needed by cdrecord-2.01a18-60 E: Unterprozesss /bin/rpm gab Fehlercode zurück (2) #
aber da yast ja nun frei ist, wird apt4rpm eh obsolet werden.
fuer mich schaut das eher aus, als haette der hotmail-heini einfach vergessen ein apt-get update vorher auszufuehren. kann mich auch irren, kenn suse nicht. auf redhat/fedora hatte ich - wenn ueberhaupt - nur kleinere probleme. hehe, und ja, ich hab mein eigenes apt-repository laufen. ist naemlich dann einfacher angepasste rpms auf die server zu verteilen :) hab naemlich noch rechner mit - ok, stark gepatchte - rh62 laufen. is aber ned wirklich viel aufwand patches fuer aktuellere versionen zurueckzuportieren.
du halst mich wohl fur doof? klar habe vorher apt update augefuhrt, schliesslich habe ich ahnung.
nein, fuffys vermutung klingt plausibel. fragt sich nur, welche quelle ich aus der sources.list entfernen muss, damit diese patch-rpms aus der datenbank verschwinden. gibt es uberhaupt gute repositories, um suse 9.0 z. b. mal mit dem aktuellen und guten kde zu versehen?
> Manche Provider (z.B. 1&1) bieten Rootserver ja nur mit Suse an. Da wäre ein apt-get wirklich praktisch.
* Rescue-System starten * mkfs.(fs-deiner-wahl) /dev/hda3 * mount /dev/hda3 /mnt/neues-system * und jetzt kannst dir das ISO deiner Wahl ziehn und loslegen. Wo ist das Problem?
Das höhrt sich irgendwie an wie "Manche Computerläden (z.B. Comtech) bieten Computer ja nur mit Windows an. " .. nichts für ungut
Richtig. Ich habe einige RootServer die mit SuSE laufen, andere mit Debian. Bei 1und1 ist es sehr einfach auf Debian zu wechseln, u.a. beim Rootforum.de gibts tipps und Links dafür.
Für 1&1 gibt es auch komplette Scripte die einem nur wenige Fragen stellen, 10 minuten später rennt Debian.
Das Problem ist doch das es keine gute Möglichkeit gibt die verschiedenen Konfigurationsdateien sinnvoll zu updaten. Es gibt keine einheitliche API um geziehlt Werte zu verändern oder zu manipulieren. Mann müsste für jedes Konfigurationsformat einen eigenen Parser schreiben um so auf die einzelnen Werte zuzugreifen.
Eine Lösung für dieses Problem wäre eine Art Registry wo die einzelnen Werte über eine einheitliche API abgreifbar und manipulierbar sind. Und siehe da sowas ist in Arbeit.
und das ganze ist nicht nur auf den Desktop beschränkt sondern soll aus für allgemeine Config's (fstab etc. ) gelten. Also ich finde es eine klasse Idee.
Bitte nicht gleich flamen. erst mal anschauen und ausprobieren.
Mhh, ich finde das eine schlechte Idee, das ist völlig gegen das Unix Prinzip gerichtet. (IMHO).
Es wäre besser, wenn jemand einfach mal eine RFC oder ähnliches für Config Files schreiben würde, die z.B. eine Config wie die von Apache vorschreibt. Diese finde ich bereits sehr gut. Eine gut gemachte automatik kann diese problemlos verarbeiten, durch include files auch ohne umstände in getrennten bereichen erweitern.
Ich sehe eher XML und co hier als Problem, da diese die configs aufblähen und für einen Menschen überfrachten mit Steuertags. Das finde ich eher weniger schön.
Ich habe gute Erfahrungen mit dem Apache Configstyle gemacht, auch bei Proftpd die das ja ebenso handhaben. Häusert einfach von hand zu ändern, und von automatiken ebenso.
Ich würde mich vor allem freuen, wenn sie Programme nicht einfach Ihre dot Files und Ordner (z.B. .kde, .mc usw.) in den Homeordner schmeisen würden, sondern es einen Config Unterordner gäbe Ich kann zwar die Dotfiles ausblenden, aber das ist auch eher unpraktisch wenn ich dann doch was ändern will. Das dauernte Wechseln nervt, nur ohne das abschalten sind das bei mir über 150 Dateien und Ordner, die ich im Alltag nicht brauche
muss ich dir recht geben. man könnte es auch etwas einfacher halten was das Configformat angeht. Aber man sollte sich wenigstens auf was einheitliches einigen was dann von Programmen ausgewertet werden kann.
Ich wollte mal ein RPM Paket zusammenstellen was eine einfach Desktopinstallation um die für mich wichtigen Zusätze (Schriften, Icons, Configs etc.) erweitert um mir so das nachträgliche Anpassen des System zu ersparen. Gescheitert ist es letztendlich daran das ich hierzu einzelne Einstellungen in den verschiedensten Configdateien hätte ändern müssen und das ohne andere Einstellungen in diesen gleich mit zu beeinflussen. es gibt da zwar ein Script von sun welches Konfigdateien merged aber das war auch nicht das wahre bzw. hätte den Aufwand noch grösser gemacht.
Ich finde aus verschiedenen Gründen XML den besten Weg, Konfigurationsdateien zu strukturieren. Erstens erlaubt dieses Format eine flexible Erweiterung. Neue Parameter können einfach aufgenommen werden, da muß nicht das Format verändert werden. XML-Parser gibt es schon gute, auch das menschliche Auge parst diese Dateien gut, da man selbstredende Tags verwenden kann.
Und für solche Dateien ist es dann auch einfach, ein Tool zu schreiben, was aus einer XSLT-Datei die "Aufgabenstellung" liest und danach eine valide Konfig-Datei erstellt. Das ist wesentlich eleganter, als das bisher dominierende zeilenorientierte Format. Und der erhöhte Speicherbedarf spielt IMHO kaum eine Rolle.
In Klartext-Configs koennen noch viel einfacher neue Parameter aufgenommen werden und die Lesbarkeit von XML ist stark eingeschraenkt.
Mir ist ehrlich gesagt ziemlich unklar, was der Vorteil von XML in Konfigdateien sein soll. Man sollte nicht ohne zwingende Gruende auf uebersichtliche Konfigs verzichten. Das Vorhandensein von XML ist jedenfalls keiner.
Den letzten Abschnitt solltest Du nochmal genauer erklaeren, denn da verschliesst sich mir noch der Sinn der Sache.
Du kannst definitiv nicht ein neues Element in der Mitte einer CSV oder Space separierten Zeile aufnehmen, ohne Probleme mit der Kompatibilität der alten zur neune Datei zu bekommen. Zentral verwaltete Konfig-Dateien, wie sie im normalen Netzwerkbetrieb üblich sind, haben dann beim Deployment neuer Software erhebliche Probleme. Der XML-Parser ignoriert Tags, die er nicht kennt (bei neuer Konfig, altem Programm) und umgekehrt ersetzt er nicht in der Konfig enthaltene Parameter durch ihre Standard-Werte. Das ist nur ein Vorteil.
Aber XML bietet viele Vorteile, nur die scheint hier keiner zu kennen und sich auch nicht zu informieren. In einer Text-Datei kann man eben nicht eine Liste der erlaubten Werte hinterlegen, bei XML ist das unproblematisch.
DOch, ich kenne die Vorteile von XML im allgemeinen, und nutze es auch. Aber für Configs will ich es nicht haben :)
Einfache Gründe: 1) Configurationdateien dienen nicht dem Datenaustausch 2) Sie müssen klar für Mensch und Maschiene sein. XMLs sind Menschenlesbar, das heisst aber nicht das sie eine ideale Form dafür haben. CSV Dateien sind auch Menschenlesbar, aber was nüttz das ohne eine Tabellenkalkulation die es übersichtlich macht? ;) 3) XMLs sind in "Bäume" Organisiert, das ist für einen Menschen schwer nachvollziehbar. Ab der (meine Erfahrung) 5. Ebene wirds schwer. 4) Ein guter XML Parser braucht immernoch mehr Zeit zum lesen einer XML als für eine einfacher formatierte Datei, da er mehr regeln folgen muss. (wobei diese zeit nicht relevant sein dürfte)
Zudem transeriert man Configs überweise nicht in andere Formate, und ihre Möglichkeiten sind bereits anderweitig beschrieben, eine Vorgabe wie für XML üblich ist eigentlich nicht unbedingt nötig.
XML ist sicher nett, aber ich sehe keinen Vorteil hier, eher Nachteile. Wie gesagt, ein simples Format wie das von Apache, das zum teil auch Tagbassiert ist, halte ich für perfekt.
Zu deinem Argument mit den CSV: Das ist schlicht falsch. Eine gute CSV besteht aus einer Headerline und dann dem Kontext, ein guter CSV parser ignoriert spalten deren Header er nicht kennt, und die Reihenfolge ist ihm auch egal. Ich hab jeden Tag mit solchen Dateien zu tun, mit diesen beiden einfachen Grundregeln sind sie eigentlich problemlos :)
Und: Viele der Kunden mit denen ich zu tun habe, nutzen auch eigene XML Parser die eben nicht sehr intelligent sind. Dann kannst du die auch nicht einfach ändern :)
Es gibt ja bereits Linux Configs als XML. Ich halte diese für abschreckende Beispiele, siehe KDE und GNOME
Meine Argumentation für XML ist einfach folgende: Anstatt immer wieder ein eigenes und neues Konzept zu erfinden, nutze man einfach ein vorhandenes, was allen Anforderungen entspricht, wenn auch nicht optimal.
XML ist vielleicht nicht optimal, aber es erfüllt alle Vorderungen. XML dient nicht nur dem Datenaustausch, sondern auch der Datenpersistierung. Es gibt sogar Datenbanken, die sich dieses Formates bedienen. Also XML ist sehr wohl geeignet, Config-Daten zu speichern.
Die Lesbarkeit durch Menschen steht bei Conf-Dateien nicht im Vordergrund, ich schätze, eine Config-Datei wird tausendmal mehr von einem Programm, als von einem Menschen gelesen (selbst der Editor ist ja ein Programm).
In gewisser Weise ist ein Editor ja auch ein universelles GUI-Programm zum editieren von Conf-dateien. Aber es gibt keine Möglichkeit, ihm etwas mehr 'Intelligenz' beizubringen (Hilfe zu den Parametern und Wertehilfe).
Vorteil von XML liegt eindeutig in der Trennung von Daten und Beschreibung. Dafür bietet kein anderes Verfahren ein bereits so gut standardisiertes Verfahren.
Von mir aus können die XML-Config-Dateien für schnellere maschinelle Verarbeitung auch precompiliert werden. Solche Ansätze gibt es ja auch.
Für mich stellt XML das Optimum aus maschineller und manueller Verarbeitung, Flexibilität, Mächtigkeit und Universalität dar.
Beruflich bin ich im Support, habe mit sehr vielen Programmen zu tun, die alle anders zu konfigurieren sind und auch noch über unterschiedliche Tools. Jedesmal muß man die Besonderheiten beachte, angefangen von Kommentaren bis hin zur meist dürftigen Dokumentation. Dann dort Fehler suchen ist nicht wirklich lustig. Da wünscht man sich _ein_ Format, auch wenn es nicht optimal ist und _ein_ Frontend, der alle Konfigs erstellen kann, ohne dafür programmiert zu sein. Und genau diese Möglichkeit bietet XML
Sorry LH, dass ich Dir widersprechen muss, aber die rc.config, die SuSE gehabt hat war 100% UNIX und zwar damals von der OSF so fuer OSF-konforme Systeme vorgeschrieben. In HP/UX gibts das Ding heute noch, und ich glaube in True64 auch.
Ist doch wunderbar, wenn es wieder ein Tool unter der GPL gibt. Yast ist eine feine Sache, übersichtlich und funktioniert - unter dem Vorbehalt, dass es einfach keine absolut fehlerfreie Software gibt (insbesondere bei einem sich so schnell entwickelnden System wie Linux) - wunderbar. Ausserdem sind SuSE's Patch-RPMs eine innovative und feine Sache. Wer jetzt schreit, dass ihm Konfdateien editieren oder apt4rpm (was wohl nicht wirklich mit Yast vergleichbar ist, sondern eher mit dem Yast-Updatemodul) lieber ist, sollte mal still in sich gehen, etwas Zucker fürs Hirn verbrennen und sich überlegen, was er da von sich gibt. Yast muss man nicht benutzen, SuSEconfig kann man einfach abschalten und dann kann man die Administration sogar von SuSE vollständig von Hand/ von Vi(m) erledigen. Für jemanden, der Linux auf dem Desktop nutzt und damit "die üblichen" Aufgaben bestreiten will, als Textverarbeitung, Mail, Musik hören, Bildbearbeitung, Browsing/Surfing, ist es aber einfach unzumutbar, besändig mit dem Editor in Textdateien herumzupfuschen. Warum also das Genöle - kann man sich doch zurücklehnen und sich freuen, dass Linux einem die Freiheit gibt, Systemadministration so zu betreiben, wie man es selbst am liebsten mag.
Tom, du erwähnst, daß man SUSEconfig ausschalten kann. Wie?
Und bzgl. eines einheitlichen Konfigurationswerkzeuges für alle Distributionen: Die Offenlegung von YAST2 hatte zunächst große Begeisterung in KDE-Kreisen ausgelöst, wurde jedoch rasch von einer gewißen Ernüchterung abgelöst. YAST2 ist keine Software, die sich nahtlos integrieren ließe und im Gegenteil starke Umbauten zumindest bei Debian erfordern würde. Da ich mir das nicht genauer angesehen habe, kann ich nicht viel dazu sagen, aber es hieß sogar, daß sich SUSE die Mühe gemacht hätte, eine eigene Sprachvariante von C zu entwickeln, um das Ding zu schreiben. Kann ich mir zwar nicht wirklich vorstellen, aber es hat schon komischere Sachen gegeben.
Und letzlich: wie ändere ich mit YAST2 die AUTOHANGUPTIME eines ISDN Controlers? Antwort: garnicht, dazu muß man isdnctrl bemühen. So viel dazu
Hi, SuSEconfig abschalten: einfach in /etc/sysconfig/suseconfig den Wert "ENABLE SUSECONFIG" auf "no" setzen. Du kannst aber auch im Yast2-Sysconfigeditor einzelne Bereiche, die SuSEconfig abarbeitet, abschalten. ISDN-Controller habe ich leider keinen (mehr), ich meine mich aber zu erinnern, dass man das direkt über kinternet einstellen konnte (aber die Hand leg ich dafür jetzt nicht ins Feuer).
Danke für den Hinweis. Die SUSEconfig Geschichte - das ganze sysconfig Verzeichnis - ist mir halt nicht bekannt. Ich helfe nur einem Freund ein wenig aus.
Bezgl. des AUTOHANGUPTIME: SUSE verwaltet zwei Zeiten, einmal die IDLE Time, die per Providerdefinition gesetzt wird und einmal die AUTOHANGUPTIME, die per ISDN Controler verwaltet wird. Zumindest SUSE 9.0 Pro scheint diese per Default auf 60 Sekunden zu setzen. Die AUTOHANGUPTIME ist der IDLE Time vorgeschaltet, d. h. die Kinternet Einstellungen bzw. die Providereinstellungen kommen ggf. nicht zum Zug.
Daher muß mit isdnctrl die AUTOHANGUPTIME so gesetzt werden, wie man es gerne hätte. Und das geht nur über die Kommandozeile und nicht mit YAST.
> [...] SuSEconfig kann man einfach abschalten und dann kann man die Administration sogar von SuSE vollständig von Hand/ von Vi(m) erledigen. [...]
Das Problem ist doch: SuSE/Yast will (wie Windoof) dem User alle Arbeit abnehmen und meint, alles besser zu können. Manchmal stimmt das ja auch;-) Aber die Folge ist, dass der Unterbau von SuSE so kompliziert (und manchmal fehlerhaft) geworden ist, dass auch viele alte Hasen nicht mehr durchblicken. Zur manuellen Konfiguration (d.h. ohne Yast) ist SuSE absolut ungeeignet
>Das Problem ist doch: SuSE/Yast will (wie Windoof) dem User alle Arbeit abnehmen und meint, alles besser zu können. Manchmal stimmt das ja auch;-) Aber die Folge ist, dass der Unterbau von SuSE so kompliziert (und manchmal fehlerhaft) geworden ist, dass auch viele alte Hasen nicht mehr durchblicken. Zur manuellen Konfiguration (d.h. ohne Yast) ist SuSE absolut ungeeignet
Wenn du etwas unwahres wiederholst, dann steigt der Wahrheitsgehalt _nicht_ - ich hatte noch _nie_ Probleme mit der manuellen Konfiguration von SuSE-Systemen.
>Wenn du etwas unwahres wiederholst, dann steigt der Wahrheitsgehalt _nicht_ - ich hatte noch _nie_ Probleme mit der manuellen Konfiguration von SuSE-Systemen.<
Da lach ich ja mal. Sachen stimmen für die einen, für die anderen eben nicht. Das hat nichts mit der Chimäre metaphysische Wahrheit zu tun. Logisch wahr ist wieder was ganz anderes und darüber brauchen wir uns ja wohl nicht zu unterhalten.
So, um die empirischen Daten ein wenig auszuweiten: ich habe nur einen Bekannten, der SUSE 9 Pro einsetzt und kenne mich nicht so gut mit SUSEs /etc/sysconfig aus, aber es macht Dinge schon anders als beispielsweise Debian, Mandrake oder Red Hat. Insofern habe ich ständig Probleme mit manueller Konfiguration unter SUSE.
Was sagt uns das? Phänomene, nichts weiter. Bei dir toll, bei Hans und mir nicht so toll.
Um mal dem (wohl unvermeidlichen) Geflame entgegen zu wirken, hier mal ein paar Argumente für Yast:
1. einfache Installation, bei Bedarf sind weitreichende Eingriffe in die automatischen Installationsvorgaben Vorschläge möglich
2. sehr gute Hardwareerkennung
3. 95% der vom Otto-Normalnutzer gebrauchten Konfigurationseinstellungen an einem Platz (frag doch mal einen durchschnittlichen Redhat oder Debian-nutzer, wo er den Internetzugang, Scanner, Drucker, Firewall usw konfiguriert)
4. Sowohl im Grafikmodus als auch im Textmodus zu bedienen (auch der Textmodus ist mittlerweile sehr gut bedienbar, für ganz eilige reicht beispielsweise auch ein "yast2 -i xemacs", um das RPM-Paket des xemacs inklusive aller dafür benötigten Pakete zu installieren)
5. Als Installationsquellen können bunt gemischt CDs, DVDs, NFS- FTP- HTTP-Server mit Prioritärten angegeben werden, z.B. für das neue KDE 3.2 wird einfach nur als neue Quelle das entsprechende Verzeichnis auf dem Suse FTP-Server angegeben, und dann kann man KDE bzw. einzelne Pakete mit automatischer Auflösung von Abhängikeiten installieren. (Ich weiß, bei Debian ist das auch kein Problem, bei Redhat ist da aber z.B. deutlich mehr Handarbeit angesagt)
6. Autoyast (automatische Installation von Linux-Maschinen über XML-Profile) ist für größere Umgebungen ein geniales Tool
ich hoffe ich konnte einige von denen, die Yast nur vom Hörensagen runtermachen, ein wenig zum Nachdenken anregen, mb...
PS: Ich weiß übrigens meistens wo man all die schönen Dinge die man mit Yast konfigurieren kann auch direkt einstellt, meine aber auch, dass der "Otto-Normalbenutzer" nicht jede Config-Datei seines Systems kennen muss, um mit Linux zu arbeiten
PPS: ich habe auch nichts dagegen, dass alle die nicht wissen wie ein Transistor funktioniert, einen Computer benutzen
Aber, obwohl ich YaST2 mag, gibt es auch zu fast jede positiven Punkt auch einen negativen :)
"1. einfache Installation, bei Bedarf sind weitreichende Eingriffe in die automatischen Installationsvorgaben Vorschläge möglich"
Stimmt, allerdings sagt einem YaST2 nicht genau was es tut, man kann es auch nicht mit einem "Detail" Button oder so in Erfahrung bringen. Das ist IMHO schade, weil man so das System nicht besser verstehen kann
"2. sehr gute Hardwareerkennung"
mhhh, jein. Ich habe oft Probleme mit der Druckererkennung von YaST2. Die von KDE ist deutlich besser. Vor allem bei Netzwerkdruckern (auch hardware ) habe ich schlechte Erfahrungen mit YaST2 gemacht
"3. 95% der vom Otto-Normalnutzer gebrauchten Konfigurationseinstellungen an einem Platz "
Ja, allerdings ist YaST2 immernoch ein Fremdkörpfer im System, da es das falsche Design haben kann, und alleine 1/5 des Platzes für grundlose Eigenwerbung draufgeht. Das macht Mandrake inzwischen besser. Ich muss nicht jedesmal sehen das es YaST2 heisst ;)
"4. Sowohl im Grafikmodus als auch im Textmodus zu bedienen"
YaST2 hat aber immernoch keine Mausbedienung wie z.B. der Midnight Commander (zumindest funktioniert nichts dergleiches bei mir)
"5. Als Installationsquellen können bunt gemischt"
Ja, aber du kannst nicht z.B. zwei gleiche Quellen auf zwei Servern einspielen (zur Sicherheit), und die Tools hierfür sind generell noch recht umständlich. Eine einfache Config Datei wie bei Debian wäre schön, der ein apt-get update reicht. Außerdem erkennt Debian die Quellen wesentlich schneller. YaST2 schläft bei mir mehrere Minuten ein wenn er eine große Online-Quelle einliest
"6. Autoyast (automatische Installation von Linux-Maschinen über XML-Profile) ist für größere Umgebungen ein geniales Tool"
Kann ich nichts zu sagen, hab ich nie benutzt :)
Das sind nur meine Anregungen und Erfahrungen damit, es muss nicht jedem so gehen. Dennoch überwiegen für mich die Vorteile bei weitem. Wenn andere außer mir das so sehen, dann schreibt SuSE an. Je mehr es tun, umso besser wirds (seihe Konsolemodus)
Das Yast auch seine Macken hat gebe ich gerne zu, noch ein paar Anmerkungen:
>Ich habe oft Probleme mit der Druckererkennung von YaST2. >Die von KDE ist deutlich besser. Hat KDE ne Hardwareerkennung für Drucker ???
>Ja, allerdings ist YaST2 immernoch ein Fremdkörpfer im System, >da es das falsche Design haben kann Das Aussehen finde ich eigentlich ganz in Ordnung, ist wohl ne Geschmacksfrage
> YaST2 hat aber immernoch keine Mausbedienung ist mir noch nicht negativ aufgefallen, da ich den Textmodus nur über ne SSH-Konsole (ohne Maus) nutze
>Außerdem erkennt Debian die Quellen wesentlich schneller. >YaST2 schläft bei mir mehrere Minuten ein wenn er eine große Online-Quelle einliest Das ist wahr, liegt wohl an den riesigen Indexdateien, ist bei Online-Quellen wahrscheinlich nur mit DSL o.ä. zu ertragen Ein weiterer Nachteil ist, das die Index-Datein der Quellen nicht automatisch aktualisiert werden, da merkst ohne manuelle Aktualisierung gar nicht, dass auf dem FTP-Server schon seit ewigkeiten neue versionen rumliegen...
Zum teil hat es soetwas, bzw. auch nicht weniger als Windows Ich finde dort vor allem die Dialoge logischer, und im gegensatz zu YaST2 findet es sogar die SMB Drucker, das schaft YaST2 hier im Firmenetzwerk nie :/
"Das ist wahr, liegt wohl an den riesigen Indexdateien, ist bei Online-Quellen wahrscheinlich nur mit DSL o.ä. zu ertragen"
Leider finde ich es auch mit DSL nicht erträglich :)
"Ein weiterer Nachteil ist, das die Index-Datein der Quellen nicht automatisch aktualisiert werden, da merkst ohne manuelle Aktualisierung gar nicht, dass auf dem FTP-Server schon seit ewigkeiten neue versionen rumliegen..."
ja, auch das ist nicht so toll. vor allem da es keine 1-klick aktuallisierung gibt. Gut, ich meine ich mach jetzt nicht soo viel damit, aber vieleicht auch grad weil es so unkonfortabel ist. Da ziehe ich inzwischen apt4rpm doch vor.
3. 95% der vom Otto-Normalnutzer gebrauchten Konfigurationseinstellungen an einem Platz (frag doch mal einen durchschnittlichen Redhat oder Debian-nutzer, wo er den Internetzugang, Scanner, Drucker, Firewall usw konfiguriert)
Wieso ist das ein Punkt für Yast? Ich habe auch alles an einem Platz: /etc
Seltsam, bei Suse ist es auch unter /etc oder /etc/sysconfig.
Die Frage ist doch wohl eher, WIE ein MDK, RH oder Debian-User sein System administriert. Bei MDK dürften mind. die Hälfte der User doch das MDK-Kontrollcenter nennen, das genauso vielle Fehler macht, wie Yast. Bei RH dürfte es linuxconf sein, am besten noch mit GTK-Gui.
so auf die schnelle fallen nicht jedem alle Namen der Configfiles für obige Dienste ein, selbst wenn sie alle unter /etc und Unterverzeichnissen liegen. Ganz zu schweigen davon, dass jedes File seine eigene Syntax hat. Naja und dann da noch die Ausnahmen, z.B. named, der seine Zonenfiles meist unter /var sucht oder grub, oder der cron usw...
> 5. Als Installationsquellen können bunt gemischt CDs, DVDs, > NFS- FTP- HTTP-Server mit Prioritärten angegeben werden, > z.B. für das neue KDE 3.2 wird einfach nur als neue Quelle > das entsprechende Verzeichnis auf dem Suse FTP-Server > angegeben, und dann kann man KDE bzw. einzelne Pakete mit > automatischer Auflösung von Abhängikeiten installieren.
Das Finden dieser Verzeichnisse ist aber nicht ganz trivial (vor allem weil yast schon an einem fehlenden "/" am Ende scheitert ...)
Dein Beitrag klingt so, als ob du diese Prozedur schon hinter dir hast: Wie löse ich denn den Konflikt zwischen kdebase3 und kdebase3-SuSE? kdebase3 hat explizit als Konflikt kdebase3-SuSE <= 9.0 eingetragen ...
a) Konflikt ignorieren? b) kdebase3-SuSE deinstallieren?
(c) Ich habe die kdebase3-Suse entpackt und die files in die entsprechenden ordner kopiert. Dadurch ist das rpm system beruhigt und suseplugger und susewatcher laufen wie vorher. ;-)
C. Yanker PS: Da diese Installation nur vorläufig ist und diese Woche durch 9.1 ersetzt wird, schien mir das der Weg des geringsten Widerstands
jetzt können die ganzen Experten hier mal rangehen und yast verbessern, wo es doch ein sooo furchtbares Tool ist. Also, die yast nicht leiden können: Bitte Ihr könnt es jetzt nach Eurem Credo verändern. mal sehen, obs dann mehr als nur dummes Gelaber gibt.
dein posting war so ziemlich das schwaechste argument, dass ich jemals fuer yast (zast?) gelesen habe. ich bin wegen yast von suse weg und bereue es ueberhaupt nicht. und nein, ich habe keine lust diesen muell zu verbessern. alles klar?
Anstatt wie die Trolle da oben über das für und wieder von Yast zu polemisieren, interessiert mich die Freigabe von YaST nur für zukünftige Entwicklungen und Einflüsse. Wie werden Redhat, Mandrake, sowie Debian, Gentoo und Slackware damit umgehen? Was ist an Veränderungen (eher: Einflüsse durch YaST) für deren Install- und Konfig-Tools zu erwarten?
Niemand braucht Yast: es würde schon genügen auf (zumindest) 1 einheitlichen Benutzer-Interface Standard (distributions-übergreifend) zu achten
-> trotzdem kann Yast hierfür aber gute Anregungen liefern ! (aber als Standard-Plattform ist z.B. RedHat gegenüber Novell/SuSE aus diesem Grund eher vorzuziehen - obwohl SuSE dzt. so ziemlich die "modernste" Distri sein dürfte, welche auch die besten Migrationsmöglichkeiten bietet)
Anm.: ein (Standard-) Sortiment von "modularen", einzelnen Tools ist vorteilhaft aufgrund der Übschaubarkeit und Flexibilität - im Vergleich mit einem unberechenbaren "Monster"-Tool (alleine schon wenn es um die Anpassung an verschiedene Distributionen geht) ------------------------ (-> gilt aber nur bei einem Standard-Sortiment mit einheitlichen Benutzer-Interface )
( so ein Standard kann durch Profis (für eigene Zwecke) auch beliebig erweitert werden -und würde trotzdem jedem(!) Linux-Admin erlauben, sich in einer beliebigem Distri zurechtzufinden...)
(der Schlüssel zum Erfolg von Linux/OpenSource liegt auch im Willen zur EINIGUNG und Gemeinsamkeit)
jap... der hat da anscheinend n haufen fake-accounts und beschwert sich über das 'von jedem deppen zu manipulierende' bewertungssystem. auf die idee, dass er wohl auch einer dieser deppen ist, kommt er nicht....
Ich nutze schon längere Zeit kein SuSE mehr. Aber zu Zeiten von SuSE 6.2 war Yast sehr stark mit der übrigen Distribution verzahnt, z.B. gab es mehrere grosse SuSE-eigene Konfigurationsdateien, die damit bearbeitet wurden.
Wäre es heutzutage ein grosser Aufwand, Yast2 auf andere Distris anzupassen? Aber selbst wenn nicht, wird es wohl kaum jemand machen. Bis jetzt hat noch fast jede Distri ihre eigenen Konfigurationstools gebastelt. Das ist ja auch fast das einzige, was sie voneinander unterscheidet.
Aber immerhin ist jetzt endlich den SuSE-Gegnern etwas Wind aus den Segeln genommen, dass ein wichtiger Teil der Distri nicht freie Software ist.
Ja, die Verzahnung ist sehr eng, ein Auftrennen ist fast unmöglich. Der größte Vorteil ist, das es nun in z.B. KDE für SuSE direkt integriert werden kann, ein Wrapper wäre nicht nötig. Vieleicht wird dadurch eine noch bessere zusammenführung möglich.
Jetzt können Entwickler das noch so ändern, dass z.B: immer die bestehende Datei bestehen bleibt, und die Configdatei vom neuen Paket als Backup gesichert wird.
Yast ist sehr gut, um z.B: Hardware einzurichten etc.
Ich finde diesen Schritt von SuSE sehr gut. Das wird dazu beitragen, dass auch andere Distributionen die Möglichkeit haben, ein einheitliches Konfigtool einzusetzen.
Das macht aber nicht YaST, sondern RPM und sollte Standard sein.
Das jetzige ist nervig.
Ganz blöd beim Bastlersystem gentoo. Die Konfigurationsverzeichnisse werden mit ._cfg* Dateien zugemüllt. Zumutung so was.
Da sind mir die paar rpmsave zwar lieber, aber eigentlich taugt auch das nix.
Da muss sich was tun.
Klar, wenn man sich die Config-Files zumüllen lässt hat man's auch nicht anders verdient...
Schonmal an ein "etc-update" gedacht? Sowas wirkt Wunder!
;-)
Was hat das mit Yast zu tun? Yast ist müll und überflüssig, deswegen setzen andere Distris es nicht ein und werden es hoffentlich auch nicht tun.
ansonsten hättest du auch auf den Müll den du schreibst verzichten können.
Und das ist ja der Vorteil von YAST: Leute, die sich so wahnsinnig toll finden, daß sie die Hilfe von YAST nicht brauchen, können ja weiterhin auf der Komandozeile die Konfigurationsdateien verstümmeln. YAST hindert sie daran exakt gar nicht.
> ... YAST nicht brauchen, können ja weiterhin auf der Komandozeile die
> Konfigurationsdateien verstümmeln. YAST hindert sie daran exakt gar nicht.
Hi, das Problem von Yast (sorry kenne die aktuelle nicht mehr bin schon lange erst von Suse'97 -> zu RedHat & Debian) war definitive das Yast probleme mit den "Original" Config Dateien hat. Config.rc - yast, manuelle Aendereungen waren weg :-(
Also falls dem nicht so ist korrigiert mich.
g
C.
finde ich, daß YaST2 so ausgereift (evtl. nicht 100% fehlerfrei, aber welche Software ist das?) ist, daß man es getrost als Standardadministrationsprogramm einsetzen kann. Der Vorteil ist, daß man das gesamte System administrieren kann. Der Vorteil, wenn es jetzt offen ist, ist, daß es sich jetzt wohl schneller entwickelt. Das kann nur von Vorteil sein und führt evtl. tatsächlich zu einem universell verwendbaren Konfigurations- und Administrationstool für sämtliche Distributionen (fände ich zumindest super).
Yast trägt in keiner Weise dazu bei - im Gegenteil :(
Er überschreibt aktuell keine Konfigurationen mehr, aber die Benutzung ist mehr als Umständlich und die Geschwindigkeit sehr langsam.
Ob er in anderen Distro's Einzug hält ist fraglich.
Das Problem ist doch: SuSE/Yast will (wie Windoof) dem User alle Arbeit abnehmen und meint, alles besser zu können. Manchmal stimmt das ja auch;-)
Aber die Folge ist, dass der Unterbau von SuSE so kompliziert (und manchmal fehlerhaft) geworden ist, dass auch viele alte Hasen nicht mehr durchblicken. Zur manuellen Konfiguration (d.h. ohne Yast) ist SuSE absolut ungeeignet
Ach so. Seit wann denn dass?
> Umständlich und die Geschwindigkeit sehr langsam.
Ich finde Yast auch sehr langsam und das für mich einer der Gründe SuSE
gegen eine andere Distri auszutauschen..
Ich hatte vor einiger Zeit mal ins Forum geschrieben, das Yast sehr lahm sei... Und prompt musste
ich das mit irgendwelchen Beispielen "beweisen".. (ist ja mitlerweile standart) -maul-
Trotzdem begrüße ich die öffnung von yast..
stefan
http://apt4rpm.sourceforge.net/
Hat jemand damit Erfahrungen gemacht? Ist das Ding brauchbar oder sollte man lieber die Finger davon lassen? Eignet es sich schon für Business-Serveranwendungen?
Manche Provider (z.B. 1&1) bieten Rootserver ja nur mit Suse an. Da wäre ein apt-get wirklich praktisch.
insgesamt weder besser noch schlechter als apt4deb
Läuft super, ist einfach zu bedienen und Probleme hatte ich bisher auch noch keine.
Empfehlung des Hauses !!!
da bleibt man doch lieber beim original.
Obwohl die Installation sicher einfacher sein könnte
# apt dist-upgrade
Lese Paketlisten... Fertig
Erzeuge Abhängigkeitsbaum... Fertig
Berechne Upgrade... Fertig
Die folgenden Pakete werden upgegradet werden:
cdrecord ucdsnmp
2 Pakete upgegradet, 0 neu installiert, 0 entfernt und 0 nicht upgegradet.
Muss 0B/814kB an Archiven holen.
Nach dem Auspacken werden 9323B zusätzlicher Plattenplatz benutzt werden.
Wollen Sie fortsetzen? [J/n]
Führe RPM aus (-Uvh)...
Fehler: Failed dependencies:
ucdsnmp = 4.2.6-125 is needed by ucdsnmp-4.2.6-152
cdrecord = 2.01a18-27 is needed by cdrecord-2.01a18-60
E: Unterprozesss /bin/rpm gab Fehlercode zurück (2)
#
aber da yast ja nun frei ist, wird apt4rpm eh obsolet werden.
Vieleicht hast du ja einfach deine rpm db zerstört
Vieleicht reagiert die auf trolle ja empfindlich 
kann mich auch irren, kenn suse nicht. auf redhat/fedora hatte ich - wenn ueberhaupt - nur kleinere probleme.
hehe, und ja, ich hab mein eigenes apt-repository laufen.
ist naemlich dann einfacher angepasste rpms auf die server zu verteilen :)
hab naemlich noch rechner mit - ok, stark gepatchte - rh62 laufen. is aber ned wirklich viel aufwand patches fuer aktuellere versionen zurueckzuportieren.
nein, fuffys vermutung klingt plausibel. fragt sich nur, welche quelle ich aus der sources.list entfernen muss, damit diese patch-rpms aus der datenbank verschwinden. gibt es uberhaupt gute repositories, um suse 9.0 z. b. mal mit dem aktuellen und guten kde zu versehen?
* Rescue-System starten
* mkfs.(fs-deiner-wahl) /dev/hda3
* mount /dev/hda3 /mnt/neues-system
* und jetzt kannst dir das ISO deiner Wahl ziehn und loslegen. Wo ist das Problem?
Das höhrt sich irgendwie an wie "Manche Computerläden (z.B. Comtech) bieten Computer ja nur mit Windows an. " .. nichts für ungut
Für 1&1 gibt es auch komplette Scripte die einem nur wenige Fragen stellen, 10 minuten später rennt Debian.
Eine Lösung für dieses Problem wäre eine Art Registry wo die einzelnen Werte über eine einheitliche API abgreifbar und manipulierbar sind. Und siehe da sowas ist in Arbeit.
http://freedesktop.org/pipermail/xdg/2004-April/003710.html
und das ganze ist nicht nur auf den Desktop beschränkt sondern soll aus für allgemeine Config's (fstab etc. ) gelten. Also ich finde es eine klasse Idee.
Bitte nicht gleich flamen.
erst mal anschauen und ausprobieren.
Ist übrigends auch file basierend.
Es wäre besser, wenn jemand einfach mal eine RFC oder ähnliches für Config Files schreiben würde, die z.B. eine Config wie die von Apache vorschreibt. Diese finde ich bereits sehr gut. Eine gut gemachte automatik kann diese problemlos verarbeiten, durch include files auch ohne umstände in getrennten bereichen erweitern.
Ich sehe eher XML und co hier als Problem, da diese die configs aufblähen und für einen Menschen überfrachten mit Steuertags. Das finde ich eher weniger schön.
Ich habe gute Erfahrungen mit dem Apache Configstyle gemacht, auch bei Proftpd die das ja ebenso handhaben. Häusert einfach von hand zu ändern, und von automatiken ebenso.
Ich würde mich vor allem freuen, wenn sie Programme nicht einfach Ihre dot Files und Ordner (z.B. .kde, .mc usw.) in den Homeordner schmeisen würden, sondern es einen Config Unterordner gäbe
Ich kann zwar die Dotfiles ausblenden, aber das ist auch eher unpraktisch wenn ich dann doch was ändern will. Das dauernte Wechseln nervt, nur ohne das abschalten sind das bei mir über 150 Dateien und Ordner, die ich im Alltag nicht brauche
Ich wollte mal ein RPM Paket zusammenstellen was eine einfach Desktopinstallation um die für mich wichtigen Zusätze (Schriften, Icons, Configs etc.) erweitert um mir so das nachträgliche Anpassen des System zu ersparen. Gescheitert ist es letztendlich daran das ich hierzu einzelne Einstellungen in den verschiedensten Configdateien hätte ändern müssen und das ohne andere Einstellungen in diesen gleich mit zu beeinflussen. es gibt da zwar ein Script von sun welches Konfigdateien merged aber das war auch nicht das wahre bzw. hätte den Aufwand noch grösser gemacht.
XML-Parser gibt es schon gute, auch das menschliche Auge parst diese Dateien gut, da man selbstredende Tags verwenden kann.
Und für solche Dateien ist es dann auch einfach, ein Tool zu schreiben, was aus einer XSLT-Datei die "Aufgabenstellung" liest und danach eine valide Konfig-Datei erstellt. Das ist wesentlich eleganter, als das bisher dominierende zeilenorientierte Format. Und der erhöhte Speicherbedarf spielt IMHO kaum eine Rolle.
Mir ist ehrlich gesagt ziemlich unklar, was der Vorteil von XML in Konfigdateien sein soll. Man sollte nicht ohne zwingende Gruende auf uebersichtliche Konfigs verzichten. Das Vorhandensein von XML ist jedenfalls keiner.
Den letzten Abschnitt solltest Du nochmal genauer erklaeren, denn da verschliesst sich mir noch der Sinn der Sache.
Michael.
Der XML-Parser ignoriert Tags, die er nicht kennt (bei neuer Konfig, altem Programm) und umgekehrt ersetzt er nicht in der Konfig enthaltene Parameter durch ihre Standard-Werte. Das ist nur ein Vorteil.
Aber XML bietet viele Vorteile, nur die scheint hier keiner zu kennen und sich auch nicht zu informieren. In einer Text-Datei kann man eben nicht eine Liste der erlaubten Werte hinterlegen, bei XML ist das unproblematisch.
Einfache Gründe:
1) Configurationdateien dienen nicht dem Datenaustausch
2) Sie müssen klar für Mensch und Maschiene sein. XMLs sind Menschenlesbar, das heisst aber nicht das sie eine ideale Form dafür haben. CSV Dateien sind auch Menschenlesbar, aber was nüttz das ohne eine Tabellenkalkulation die es übersichtlich macht? ;)
3) XMLs sind in "Bäume" Organisiert, das ist für einen Menschen schwer nachvollziehbar. Ab der (meine Erfahrung) 5. Ebene wirds schwer.
4) Ein guter XML Parser braucht immernoch mehr Zeit zum lesen einer XML als für eine einfacher formatierte Datei, da er mehr regeln folgen muss. (wobei diese zeit nicht relevant sein dürfte)
Zudem transeriert man Configs überweise nicht in andere Formate, und ihre Möglichkeiten sind bereits anderweitig beschrieben, eine Vorgabe wie für XML üblich ist eigentlich nicht unbedingt nötig.
XML ist sicher nett, aber ich sehe keinen Vorteil hier, eher Nachteile. Wie gesagt, ein simples Format wie das von Apache, das zum teil auch Tagbassiert ist, halte ich für perfekt.
Zu deinem Argument mit den CSV: Das ist schlicht falsch. Eine gute CSV besteht aus einer Headerline und dann dem Kontext, ein guter CSV parser ignoriert spalten deren Header er nicht kennt, und die Reihenfolge ist ihm auch egal. Ich hab jeden Tag mit solchen Dateien zu tun, mit diesen beiden einfachen Grundregeln sind sie eigentlich problemlos :)
Und: Viele der Kunden mit denen ich zu tun habe, nutzen auch eigene XML Parser die eben nicht sehr intelligent sind. Dann kannst du die auch nicht einfach ändern :)
Es gibt ja bereits Linux Configs als XML. Ich halte diese für abschreckende Beispiele, siehe KDE und GNOME
XML ist vielleicht nicht optimal, aber es erfüllt alle Vorderungen.
XML dient nicht nur dem Datenaustausch, sondern auch der Datenpersistierung. Es gibt sogar Datenbanken, die sich dieses Formates bedienen. Also XML ist sehr wohl geeignet, Config-Daten zu speichern.
Die Lesbarkeit durch Menschen steht bei Conf-Dateien nicht im Vordergrund, ich schätze, eine Config-Datei wird tausendmal mehr von einem Programm, als von einem Menschen gelesen (selbst der Editor ist ja ein Programm).
In gewisser Weise ist ein Editor ja auch ein universelles GUI-Programm zum editieren von Conf-dateien. Aber es gibt keine Möglichkeit, ihm etwas mehr 'Intelligenz' beizubringen (Hilfe zu den Parametern und Wertehilfe).
Vorteil von XML liegt eindeutig in der Trennung von Daten und Beschreibung. Dafür bietet kein anderes Verfahren ein bereits so gut standardisiertes Verfahren.
Von mir aus können die XML-Config-Dateien für schnellere maschinelle Verarbeitung auch precompiliert werden. Solche Ansätze gibt es ja auch.
Für mich stellt XML das Optimum aus maschineller und manueller Verarbeitung, Flexibilität, Mächtigkeit und Universalität dar.
Beruflich bin ich im Support, habe mit sehr vielen Programmen zu tun, die alle anders zu konfigurieren sind und auch noch über unterschiedliche Tools. Jedesmal muß man die Besonderheiten beachte, angefangen von Kommentaren bis hin zur meist dürftigen Dokumentation.
Dann dort Fehler suchen ist nicht wirklich lustig.
Da wünscht man sich _ein_ Format, auch wenn es nicht optimal ist und _ein_ Frontend, der alle Konfigs erstellen kann, ohne dafür programmiert zu sein. Und genau diese Möglichkeit bietet XML
gruss,
mad
>>Jo, ist gestern pünktlich bei mir eingetrudelt.
Wie das denn? Ich weiss aus 100%ig sicherer Quelle, dass SUSE heute erst die Pakete aus dem Presserk zur Freigabe bekommen hat.
Einer der besten Kommentare seit langem!
Was soll's, einfach zurücklehnen über diesen Kinderkram lächeln ist das beste, was man tun kann, wir waren schließlich alle mal naß hinter den Ohren.
bye,
Silvio
Ich kritisiere die Herabsetzung von Leuten, die lieber GUI gestützt konfigurieren.
Das ist IMHO Kinderkram.
bye,
Silvio
da kann ich mich nur voll anschliessen.
cu
markus
Und bzgl. eines einheitlichen Konfigurationswerkzeuges für alle Distributionen: Die Offenlegung von YAST2 hatte zunächst große Begeisterung in KDE-Kreisen ausgelöst, wurde jedoch rasch von einer gewißen Ernüchterung abgelöst. YAST2 ist keine Software, die sich nahtlos integrieren ließe und im Gegenteil starke Umbauten zumindest bei Debian erfordern würde. Da ich mir das nicht genauer angesehen habe, kann ich nicht viel dazu sagen, aber es hieß sogar, daß sich SUSE die Mühe gemacht hätte, eine eigene Sprachvariante von C zu entwickeln, um das Ding zu schreiben. Kann ich mir zwar nicht wirklich vorstellen, aber es hat schon komischere Sachen gegeben.
Und letzlich: wie ändere ich mit YAST2 die AUTOHANGUPTIME eines ISDN Controlers? Antwort: garnicht, dazu muß man isdnctrl bemühen. So viel dazu
"ENABLE SUSECONFIG" auf "no" setzen. Du kannst aber auch im Yast2-Sysconfigeditor einzelne Bereiche, die SuSEconfig abarbeitet, abschalten. ISDN-Controller habe ich leider keinen (mehr), ich meine mich aber zu erinnern, dass man das direkt über kinternet einstellen konnte (aber die Hand leg ich dafür jetzt nicht ins Feuer).
Bezgl. des AUTOHANGUPTIME: SUSE verwaltet zwei Zeiten, einmal die IDLE Time, die per Providerdefinition gesetzt wird und einmal die AUTOHANGUPTIME, die per ISDN Controler verwaltet wird. Zumindest SUSE 9.0 Pro scheint diese per Default auf 60 Sekunden zu setzen. Die AUTOHANGUPTIME ist der IDLE Time vorgeschaltet, d. h. die Kinternet Einstellungen bzw. die Providereinstellungen kommen ggf. nicht zum Zug.
Daher muß mit isdnctrl die AUTOHANGUPTIME so gesetzt werden, wie man es gerne hätte. Und das geht nur über die Kommandozeile und nicht mit YAST.
Das Problem ist doch: SuSE/Yast will (wie Windoof) dem User alle Arbeit abnehmen und meint, alles besser zu können. Manchmal stimmt das ja auch;-)
Aber die Folge ist, dass der Unterbau von SuSE so kompliziert (und manchmal fehlerhaft) geworden ist, dass auch viele alte Hasen nicht mehr durchblicken. Zur manuellen Konfiguration (d.h. ohne Yast) ist SuSE absolut ungeeignet
Aber die Folge ist, dass der Unterbau von SuSE so kompliziert (und manchmal fehlerhaft) geworden ist, dass auch viele alte Hasen nicht mehr durchblicken. Zur manuellen Konfiguration (d.h. ohne Yast) ist SuSE absolut ungeeignet
Wenn du etwas unwahres wiederholst, dann steigt der Wahrheitsgehalt _nicht_ - ich hatte noch _nie_ Probleme mit der manuellen Konfiguration von SuSE-Systemen.
Da lach ich ja mal. Sachen stimmen für die einen, für die anderen eben nicht. Das hat nichts mit der Chimäre metaphysische Wahrheit zu tun. Logisch wahr ist wieder was ganz anderes und darüber brauchen wir uns ja wohl nicht zu unterhalten.
So, um die empirischen Daten ein wenig auszuweiten: ich habe nur einen Bekannten, der SUSE 9 Pro einsetzt und kenne mich nicht so gut mit SUSEs /etc/sysconfig aus, aber es macht Dinge schon anders als beispielsweise Debian, Mandrake oder Red Hat. Insofern habe ich ständig Probleme mit manueller Konfiguration unter SUSE.
Was sagt uns das? Phänomene, nichts weiter. Bei dir toll, bei Hans und mir nicht so toll.
1. einfache Installation, bei Bedarf sind weitreichende Eingriffe in die automatischen Installationsvorgaben Vorschläge möglich
2. sehr gute Hardwareerkennung
3. 95% der vom Otto-Normalnutzer gebrauchten Konfigurationseinstellungen an einem Platz (frag doch mal einen durchschnittlichen Redhat oder Debian-nutzer, wo er den Internetzugang, Scanner, Drucker, Firewall usw konfiguriert)
4. Sowohl im Grafikmodus als auch im Textmodus zu bedienen (auch der Textmodus ist mittlerweile sehr gut bedienbar, für ganz eilige reicht beispielsweise auch ein "yast2 -i xemacs", um das RPM-Paket des xemacs inklusive aller dafür benötigten Pakete zu installieren)
5. Als Installationsquellen können bunt gemischt CDs, DVDs, NFS- FTP- HTTP-Server mit Prioritärten angegeben werden, z.B. für das neue KDE 3.2 wird einfach nur als neue Quelle das entsprechende Verzeichnis auf dem Suse FTP-Server angegeben, und dann kann man KDE bzw. einzelne Pakete mit automatischer Auflösung von Abhängikeiten installieren. (Ich weiß, bei Debian ist das auch kein Problem, bei Redhat ist da aber z.B. deutlich mehr Handarbeit angesagt)
6. Autoyast (automatische Installation von Linux-Maschinen über XML-Profile) ist für größere Umgebungen ein geniales Tool
ich hoffe ich konnte einige von denen, die Yast nur vom Hörensagen runtermachen, ein wenig zum Nachdenken anregen, mb...
PS: Ich weiß übrigens meistens wo man all die schönen Dinge die man mit Yast konfigurieren kann auch direkt einstellt, meine aber auch, dass der "Otto-Normalbenutzer" nicht jede Config-Datei seines Systems kennen muss, um mit Linux zu arbeiten
PPS: ich habe auch nichts dagegen, dass alle die nicht wissen wie ein Transistor funktioniert, einen Computer benutzen
"1. einfache Installation, bei Bedarf sind weitreichende Eingriffe in die automatischen Installationsvorgaben Vorschläge möglich"
Stimmt, allerdings sagt einem YaST2 nicht genau was es tut, man kann es auch nicht mit einem "Detail" Button oder so in Erfahrung bringen. Das ist IMHO schade, weil man so das System nicht besser verstehen kann
"2. sehr gute Hardwareerkennung"
mhhh, jein. Ich habe oft Probleme mit der Druckererkennung von YaST2. Die von KDE ist deutlich besser. Vor allem bei Netzwerkdruckern (auch hardware
) habe ich schlechte Erfahrungen mit YaST2 gemacht
"3. 95% der vom Otto-Normalnutzer gebrauchten Konfigurationseinstellungen an einem Platz "
Ja, allerdings ist YaST2 immernoch ein Fremdkörpfer im System, da es das falsche Design haben kann, und alleine 1/5 des Platzes für grundlose Eigenwerbung draufgeht. Das macht Mandrake inzwischen besser. Ich muss nicht jedesmal sehen das es YaST2 heisst ;)
"4. Sowohl im Grafikmodus als auch im Textmodus zu bedienen"
YaST2 hat aber immernoch keine Mausbedienung wie z.B. der Midnight Commander (zumindest funktioniert nichts dergleiches bei mir)
"5. Als Installationsquellen können bunt gemischt"
Ja, aber du kannst nicht z.B. zwei gleiche Quellen auf zwei Servern einspielen (zur Sicherheit), und die Tools hierfür sind generell noch recht umständlich. Eine einfache Config Datei wie bei Debian wäre schön, der ein apt-get update reicht. Außerdem erkennt Debian die Quellen wesentlich schneller. YaST2 schläft bei mir mehrere Minuten ein wenn er eine große Online-Quelle einliest
"6. Autoyast (automatische Installation von Linux-Maschinen über XML-Profile) ist für größere Umgebungen ein geniales Tool"
Kann ich nichts zu sagen, hab ich nie benutzt :)
Das sind nur meine Anregungen und Erfahrungen damit, es muss nicht jedem so gehen. Dennoch überwiegen für mich die Vorteile bei weitem.
Wenn andere außer mir das so sehen, dann schreibt SuSE an. Je mehr es tun, umso besser wirds (seihe Konsolemodus)
>Ich habe oft Probleme mit der Druckererkennung von YaST2.
>Die von KDE ist deutlich besser.
Hat KDE ne Hardwareerkennung für Drucker ???
>Ja, allerdings ist YaST2 immernoch ein Fremdkörpfer im System,
>da es das falsche Design haben kann
Das Aussehen finde ich eigentlich ganz in Ordnung, ist wohl ne Geschmacksfrage
> YaST2 hat aber immernoch keine Mausbedienung
ist mir noch nicht negativ aufgefallen, da ich den Textmodus nur über ne SSH-Konsole (ohne Maus) nutze
>Außerdem erkennt Debian die Quellen wesentlich schneller.
>YaST2 schläft bei mir mehrere Minuten ein wenn er eine große Online-Quelle einliest
Das ist wahr, liegt wohl an den riesigen Indexdateien, ist bei Online-Quellen wahrscheinlich nur mit DSL o.ä. zu ertragen
Ein weiterer Nachteil ist, das die Index-Datein der Quellen nicht automatisch aktualisiert werden, da merkst ohne manuelle Aktualisierung gar nicht, dass auf dem FTP-Server schon seit ewigkeiten neue versionen rumliegen...
Zum teil hat es soetwas, bzw. auch nicht weniger als Windows
Ich finde dort vor allem die Dialoge logischer, und im gegensatz zu YaST2 findet es sogar die SMB Drucker, das schaft YaST2 hier im Firmenetzwerk nie :/
"Das ist wahr, liegt wohl an den riesigen Indexdateien, ist bei Online-Quellen wahrscheinlich nur mit DSL o.ä. zu ertragen"
Leider finde ich es auch mit DSL nicht erträglich :)
"Ein weiterer Nachteil ist, das die Index-Datein der Quellen nicht automatisch aktualisiert werden, da merkst ohne manuelle Aktualisierung gar nicht, dass auf dem FTP-Server schon seit ewigkeiten neue versionen rumliegen..."
ja, auch das ist nicht so toll. vor allem da es keine 1-klick aktuallisierung gibt. Gut, ich meine ich mach jetzt nicht soo viel damit, aber vieleicht auch grad weil es so unkonfortabel ist. Da ziehe ich inzwischen apt4rpm doch vor.
Wieso ist das ein Punkt für Yast? Ich habe auch alles an einem Platz: /etc
Die Frage ist doch wohl eher, WIE ein MDK, RH oder Debian-User sein System administriert.
Bei MDK dürften mind. die Hälfte der User doch das MDK-Kontrollcenter nennen, das genauso vielle Fehler macht, wie Yast.
Bei RH dürfte es linuxconf sein, am besten noch mit GTK-Gui.
> NFS- FTP- HTTP-Server mit Prioritärten angegeben werden,
> z.B. für das neue KDE 3.2 wird einfach nur als neue Quelle
> das entsprechende Verzeichnis auf dem Suse FTP-Server
> angegeben, und dann kann man KDE bzw. einzelne Pakete mit
> automatischer Auflösung von Abhängikeiten installieren.
Das Finden dieser Verzeichnisse ist aber nicht ganz trivial (vor allem weil yast schon an einem fehlenden "/" am Ende scheitert ...)
Dein Beitrag klingt so, als ob du diese Prozedur schon hinter dir hast: Wie löse ich denn den Konflikt zwischen kdebase3 und kdebase3-SuSE? kdebase3 hat explizit als Konflikt kdebase3-SuSE <= 9.0 eingetragen ...
a) Konflikt ignorieren?
b) kdebase3-SuSE deinstallieren?
Trotz ignorieren dieser abhängigkeit sollten keine Probleme mit den Anpassungen auftauchen.
C. Yanker
PS: Da diese Installation nur vorläufig ist und diese Woche durch 9.1 ersetzt wird, schien mir das der Weg des geringsten Widerstands
APT-RPM? YUM?
Also, die yast nicht leiden können: Bitte Ihr könnt es jetzt nach Eurem Credo verändern. mal sehen, obs dann mehr als nur dummes Gelaber gibt.
..
ich bin wegen yast von suse weg und bereue es ueberhaupt nicht. und nein, ich habe keine lust diesen muell zu verbessern.
alles klar?
das Beste ist doch, dass es jedem selbst überlassen bleibt, ob er SuSE verwendet oder nicht.
Und selbst wenn einer SuSE hat, muss er nicht unbedingt zu YAST greifen.
Mit vi gehts doch auch oder ?
Grüße
B
Gefällt mir viel besser als das ressourcenfressende und aufgeblasene Yast2
es würde schon genügen auf (zumindest) 1 einheitlichen Benutzer-Interface Standard (distributions-übergreifend) zu achten
-> trotzdem kann Yast hierfür aber gute Anregungen liefern !
(aber als Standard-Plattform ist z.B. RedHat gegenüber Novell/SuSE aus diesem Grund eher vorzuziehen - obwohl SuSE dzt. so ziemlich die "modernste" Distri sein dürfte, welche auch die besten Migrationsmöglichkeiten bietet)
Anm.: ein (Standard-) Sortiment von "modularen", einzelnen Tools ist vorteilhaft aufgrund der Übschaubarkeit und Flexibilität - im Vergleich mit einem unberechenbaren "Monster"-Tool
(alleine schon wenn es um die Anpassung an verschiedene Distributionen geht)
------------------------
(-> gilt aber nur bei einem Standard-Sortiment mit einheitlichen Benutzer-Interface )
( so ein Standard kann durch Profis (für eigene Zwecke) auch beliebig erweitert werden -und würde trotzdem jedem(!) Linux-Admin erlauben, sich in einer beliebigem Distri zurechtzufinden...)
(der Schlüssel zum Erfolg von Linux/OpenSource liegt auch im Willen zur EINIGUNG und Gemeinsamkeit)
http://www.whiteboxlinux.org/
so dumm kann aber auch kein Elch sein...
Konsequente Umsetzung von (offenen / distributions-übergreifenden) Standards und Kundenorientierung:
-> dann ist für den Erfolg von OpenSource/Linux auch im professionellen Umfeld der Weg frei... :-)
Wäre es heutzutage ein grosser Aufwand, Yast2 auf andere Distris anzupassen? Aber selbst wenn nicht, wird es wohl kaum jemand machen. Bis jetzt hat noch fast jede Distri ihre eigenen Konfigurationstools gebastelt. Das ist ja auch fast das einzige, was sie voneinander unterscheidet.
Aber immerhin ist jetzt endlich den SuSE-Gegnern etwas Wind aus den Segeln genommen, dass ein wichtiger Teil der Distri nicht freie Software ist.