Also ich finde es schon sehr arm von dir, mich zutieren, den zitierten text aber zu verändern.. naja...
UL Wirkt recht chaotisch... Eben: Die Distris scheinen nichtmal untereinander kommunizieren zu können.. ob das was wird?
Wenn man fragen darf, was schreibst du denn für software, die Konfigfiles benötigt die überall an einem anderen ort sind?
Auch das mit den initscripts geht... Zugegeben, es ist keine Ideale Situation.. Aber wenn die Entwickler das nicht hinkriegen, dann wird auch deren software nicht viel taugen (sorry... weil dazu braucht man keine grosen fachkentnisse..)
Sorry, sollte kein Zitat werden, aber Du darfst mich natürlich gerne dennoch beleidigen - muss man hier wohl erwarten. Ich hätte auch jedem zugetraut zu erkennen, dass das kein Zitat war - nicht mal im entferntesten, zumal die Argumentationsrichtung ganz anders war. Aber gut: Beleidigungen gehören ja zum guten Ton, werde ich mir also auch aneignen müssen.
"UL wirkt recht chaotisch" (richtig zitiert?): wieso: was weisst Du bisher davon? Es ist noch nichts veröffentlicht, aber: ich bin gerade auf eine Multivendor-Schulung von jemandem der mehr Insider-Wissen hat: es sieht geplant aus, die Ziele stehen fest, über 100 Entwickler arbeiten dran.
"Die Distris scheinen nicht mal untereinander kommunizieren zu können.." Wieso glaubst Du das, woher hast Du die Informationen? Eine ziemlich heftige Behauptung, wenn Du view grossen Firmen die Fähigkeit absprichst, dass zu tun, was allen finanzielle Vorteile bringt.
Sagt Dir OpenView was? Wahrscheinlich nicht. Ist eher für Experten(hint: s.o.) und Firmenkunden. Nehmen wir mal an, Du schreibst einen Dienst der im Runlevel 4 und 5 laufen soll, in den anderen aber nicht. Also musst Du "S"-Skripte in die Verzeichnisse plazieren, /etc/init.d/rc.[45], bzw. /etc/rc.d/rc.[45], je nachdem. "K"-Skripte müssen in alle, ausser bei einigen Distris und bei einigen Unices bei denen Runlevel aufeinander aufbauen, was z.B. bei SuSE nicht der Fall ist. Wenn Du vom RunLevel 5 nach 4 wechselst, werden in 4 die "K"-Skripte ausgeführt und dann die "S". Andere (RedHat ?) führen noch die K-Skripte in 5 aus,... Es sollte immer alles korrekt funktionieren, ansonsten gibt es evtl. in Datenbanken Inkonsistenzen, d.h. Einzel-Arbeit je Distri ist gefragt.
"Auch das mit den initscripts geht": soso: Du willst also für jeder Plattform ein eigenes Installation/Deinstallations-Script schreiben: viel Spass, zumal Zeit Geld ist. Deine Formulierung/Detaillierung lässt darauf schliessen, dass Du davon eigentlich keine Ahnung hast. Natürlich geht es: aber ist es den Aufwand wert? Das hat nichts damit zu tun, dass die Software dann nichts taugt (wie gesagt, Du darfst hier gerne Beleidungen rumposaunen wie es Dir passt), aber es _lohnt_ nicht. Zwischen SuSE 6.X und 7.X haben sich diese Dinge wieder geändert, also: 6.X wird nicht unterstützt. Mandrake, Connectiva und TurboLinux machen es anders als z.B. Caldera, also fallen die raus, weil Caldera auch dem RedHat-Schema ähnelt und es früher schon unterstützt wurde. Also: alles was nicht Markführer (bzw. "Monopolist" (RedHat-USA)) ist, fällt raus. Gefällt Dir das besser? Ist es das was wir wollen? Nein! Bestimmte Dinge müssen verlässlich sein, z.B. Basistools und Verzeichnisstruktur der Konfig-Bereiche. Für all das _brauchst_ Du Fachkenntnisse, solange init-Prozeduren auf den verschieden Unices und Linux-Distris so verschieden sind, Deine Software aber von Natur aus und dem Zwecke nach systemnah ausgerichtet ist. Das übersiehst Du wohl: wenn ich ein Office-Paket schreibe, ist mir das alles völlig egal - gebe ich Dir recht. Aber wenn es richtig ans Eingemachte geht? Beispiel cpio: Bei Suse ist es in /usr/sbin ansonsten oft in /usr/local/cpio/bin, die libs sind mal in /usr/share mal in /usr/local/share/cpio/libs. Hast Du Spass daran (und die Zeit) für alle Systeme das zu untersuchen? Ich bin leider/zum Glück nicht für die Linux-Plattformen zuständig und erspare mir da viel, aber die, die das machen, haben ständig damit zu kämpfen, dass z.B. Caldera von 2.x auf 3.x wieder Verzeichnisstrukur geändert haben, Scripte umbenannt, automounter für bestimmte Bereiche aktiviert hat usw. Das ist nicht sehr professionell und nicht sehr verlässlich. Schau Dir HP-UX, Solaris, AIX etc. an: wann hat sich da mal grundlegend was verändert? Antwort: Nie! Jeder hat auf einem historisch bedingten Stand begonnen (z.B. System 5, 2 Release im Falle von AIX) und darauf aufgebaut - keine "Seitensprünge", alles ist wie immer. Einige Parameter sind inzwischen überflüssig, aber noch vorhanden, so dass vorhandene Software weiter ihren Dienst tut. Unter Linux geht manchmal nach einem neuen Distri-Release etwas nicht mehr und erstmal wundern sich alle. (Obwohl auch da die Tradition bleibt, z.B. die zweitletzte Zahl in der /etc/fstab: die ist eben da damit die letzte Zahl die 2. der Zahlen ist und nicht die erste. Früher hätte es mal Backup-Zwecken dienen soll. Würde man sie aber entfernen, könnte die Mount-Reihenfolge durcheinanderkommen, was z.T. unangenehme Konsequenzen haben könnte.
naja...
UL Wirkt recht chaotisch... Eben: Die Distris scheinen nichtmal untereinander kommunizieren zu können.. ob das was wird?
Wenn man fragen darf, was schreibst du denn für software, die Konfigfiles benötigt die überall an einem anderen ort sind?
Auch das mit den initscripts geht... Zugegeben, es ist keine Ideale Situation.. Aber wenn die Entwickler das nicht hinkriegen, dann wird auch deren software nicht viel taugen (sorry... weil dazu braucht man keine grosen fachkentnisse..)
Ich hätte auch jedem zugetraut zu erkennen, dass das kein Zitat war - nicht mal im entferntesten, zumal die Argumentationsrichtung ganz anders war. Aber gut: Beleidigungen gehören ja zum guten Ton, werde ich mir also auch aneignen müssen.
"UL wirkt recht chaotisch" (richtig zitiert?): wieso: was weisst Du bisher davon? Es ist noch nichts veröffentlicht, aber: ich bin gerade auf eine Multivendor-Schulung von jemandem der mehr Insider-Wissen hat: es sieht geplant aus, die Ziele stehen fest, über 100 Entwickler arbeiten dran.
"Die Distris scheinen nicht mal untereinander kommunizieren zu können.."
Wieso glaubst Du das, woher hast Du die Informationen? Eine ziemlich heftige Behauptung, wenn Du view grossen Firmen die Fähigkeit absprichst, dass zu tun, was allen finanzielle Vorteile bringt.
Sagt Dir OpenView was? Wahrscheinlich nicht. Ist eher für Experten(hint: s.o.) und Firmenkunden. Nehmen wir mal an, Du schreibst einen Dienst der im Runlevel 4 und 5 laufen soll, in den anderen aber nicht. Also musst Du "S"-Skripte in die Verzeichnisse plazieren, /etc/init.d/rc.[45], bzw. /etc/rc.d/rc.[45], je nachdem. "K"-Skripte müssen in alle, ausser bei einigen Distris und bei einigen Unices bei denen Runlevel aufeinander aufbauen, was z.B. bei SuSE nicht der Fall ist. Wenn Du vom RunLevel 5 nach 4 wechselst, werden in 4 die "K"-Skripte ausgeführt und dann die "S".
Andere (RedHat ?) führen noch die K-Skripte in 5 aus,... Es sollte immer alles korrekt funktionieren, ansonsten gibt es evtl. in Datenbanken Inkonsistenzen, d.h. Einzel-Arbeit je Distri ist gefragt.
"Auch das mit den initscripts geht":
soso: Du willst also für jeder Plattform ein eigenes Installation/Deinstallations-Script schreiben: viel Spass, zumal Zeit Geld ist. Deine Formulierung/Detaillierung lässt darauf schliessen, dass Du davon eigentlich keine Ahnung hast. Natürlich geht es: aber ist es den Aufwand wert?
Das hat nichts damit zu tun, dass die Software dann nichts taugt (wie gesagt, Du darfst hier gerne Beleidungen rumposaunen wie es Dir passt), aber es _lohnt_ nicht. Zwischen SuSE 6.X und 7.X haben sich diese Dinge wieder geändert, also: 6.X wird nicht unterstützt. Mandrake, Connectiva und TurboLinux machen es anders als z.B. Caldera, also fallen die raus, weil Caldera auch dem RedHat-Schema ähnelt und es früher schon unterstützt wurde.
Also: alles was nicht Markführer (bzw. "Monopolist" (RedHat-USA)) ist, fällt raus. Gefällt Dir das besser? Ist es das was wir wollen?
Nein! Bestimmte Dinge müssen verlässlich sein, z.B. Basistools und Verzeichnisstruktur der Konfig-Bereiche.
Für all das _brauchst_ Du Fachkenntnisse, solange init-Prozeduren auf den verschieden Unices und Linux-Distris so verschieden sind, Deine Software aber von Natur aus und dem Zwecke nach systemnah ausgerichtet ist.
Das übersiehst Du wohl: wenn ich ein Office-Paket schreibe, ist mir das alles völlig egal - gebe ich Dir recht. Aber wenn es richtig ans Eingemachte geht?
Beispiel cpio: Bei Suse ist es in /usr/sbin ansonsten oft in /usr/local/cpio/bin, die libs sind mal in /usr/share mal in /usr/local/share/cpio/libs. Hast Du Spass daran (und die Zeit) für alle Systeme das zu untersuchen?
Ich bin leider/zum Glück nicht für die Linux-Plattformen zuständig und erspare mir da viel, aber die, die das machen, haben ständig damit zu kämpfen, dass z.B. Caldera von 2.x auf 3.x wieder Verzeichnisstrukur geändert haben, Scripte umbenannt, automounter für bestimmte Bereiche aktiviert hat usw.
Das ist nicht sehr professionell und nicht sehr verlässlich. Schau Dir HP-UX, Solaris, AIX etc. an: wann hat sich da mal grundlegend was verändert? Antwort: Nie! Jeder hat auf einem historisch bedingten Stand begonnen (z.B. System 5, 2 Release im Falle von AIX) und darauf aufgebaut - keine "Seitensprünge", alles ist wie immer. Einige Parameter sind inzwischen überflüssig, aber noch vorhanden, so dass vorhandene Software weiter ihren Dienst tut. Unter Linux geht manchmal nach einem neuen Distri-Release etwas nicht mehr und erstmal wundern sich alle.
(Obwohl auch da die Tradition bleibt, z.B. die zweitletzte Zahl in der /etc/fstab: die ist eben da damit die letzte Zahl die 2. der Zahlen ist und nicht die erste. Früher hätte es mal Backup-Zwecken dienen soll. Würde man sie aber entfernen, könnte die Mount-Reihenfolge durcheinanderkommen, was z.T. unangenehme Konsequenzen haben könnte.
Mehr Beispiele auf wunsch...
Soviel also dazu.
Gruss
Norbert