On Mon, 07 Apr 2003 at 01:59 (+0200), Marc Schmitt wrote: [...]
Man muss sich die Frage stellen, was man bezwecken will, und was für Werkzeuge dafür zur Verfügung stehen. Nachdem der Kernel die Kontrolle an init abgibt, ist es dessen Aufgabe, das System in einen definierten Zustand zu bringen, mehr erstmal nicht. Wie es das bewerkstelligt sollte zweitrangig sein, hauptsache es tut dies zuverlässig und schnell.
Wie? Was? Der Kernel gibt die Kontrolle an den init ab? Wo hast Du das denn her? Der Kernel gibt nie die Kontrolle ab. Zuverlässigkeit und Performance sind nicht die einzigen Kriterien. Skalierbarkeit, Flexibilität, Portabilität ... sind im professionellen Bereich mindestens ebenso wichtig.
Die Tatsache, dass bis jetzt die Bash zur Verwendung gekommen ist, mag ihre historische Begründung haben ( die Shells liegen unter /bin/ ab, was per Definition auf der Root-Partition zu liegen hat - ganz im Gegensatz zu /usr, das als externe Partition erst viel später im Initprozess eingehängt werden brauch und daher keine Bootkritischen Daten enthalten darf ). Die Frage ist nur, ob diese historischen Wurzeln heute noch ihre Berechtigung haben.
Was hat das Programmverzeichnis der bash mit dem Booten zu tun? Du kannst doch in /bin ablegen, was Du willst! Und Du kannst eine Shell ohne weiteres in /usr/bin oder in /gruesse_an_meine_Magenbeschwerden ablegen. Die bash liegt in /bin, _weil_ sie zum Booten benötigt wird - nicht andersrum. Und ganz nebenbei muss /usr keine eigene Partition (schon gar keine *externe* - was immer das auch sein mag) bilden. Es ist nur in den meisten Fällen sinnvoll (nicht immer!). Die bash dient vor allem als Vehikel zum Start der eigentlichen Prozesse, das sind nämlich Binaries. Du wirst den Systemstart nicht dadurch beschleunigen, dass Du die bash durch einen anderen Interpreter (Perl) ersetzt. Auch Perl muss letztendlich Systemprozesse starten.
Um konkurenzfähig zu bleiben, halte ich Bootzeit für weitaus kritischer, als eine Pseudo-Standardkonformität zu irgendwelchen Unixderivaten. Einen Anwender interessiert es in keinster Weise, warum Linux doppelt so lange zu starten braucht, wie XP. Ihn interessiert nur, dass es das tut. Meiner Ansicht nach ist hier Kreativität gefragt, und der Mut neue Ideen auch durchzusetzen. Denn die Antwort auf die Frage "Warum macht Ihr das so ?", kann doch in einem modernen Betriebsystemumfeld nicht lauten "Weil wir das schon immer so gemacht haben".
Ich finde es schon ziemlich gewagt, den Kernel- und anderen Entwicklern zu unterstellen, ihnen fehle die Kreativität und sie würden aus lauter *wir haben das schon immer so gemacht*-Mentalität Neuerungen ablehnen. Was meinst Du mit *Pseudo-Standardkonformität*? Wie wäre es, wenn Du Dich erstmal intensiv mit dem Konzept der System-Initialisierung bei Unix / Linux befasst, bevor Du solche (falschen) Schlagwörter hier raushaust? Das Boot-Konzept existiert vor allem deshalb so lange, weil es sinnvoll ist. Den Anwender (wenn es z. B. ein Systemadministrator eines oder mehrerer Server ist) interessiert die Zeit zum Booten einen Sch...dreck - das tut er im Normalfall nämlich äußerst selten. Ihn interessiert vor allem ein flexibel zu konfigurierendes, skalierbares, performantes, zuverlässiges und leicht zu wartendes - und vor allem _laufendes_ - System! Du machst den Fehler, _Deine_ Sichtweise eines Linux-Systems zu verallgemeinern. Linux heisst sowohl Server als auch Client, diskless Terminal, embedded System, Mainframe, Cluster, ... Bei dieser Vielfalt spielt die von Dir so abwertend bezeichnete *Pseudo-Standardkonformität zu irgendwelchen Unixderivaten* eine sehr wichtige Rolle. Es ist nämlich keineswegs egal, ob ich ein Programm in _einer_ Version für verschiedene Architekturen und Einsatzzwecke oder in verschiedenen für jeden kleinen Systemunterschied vorhalte. Der Aufwand wäre gerade für die Open Source Programmierer nicht zu bewältigen, wenn es nicht einheitliche Standards für das Programm-Umfeld gäbe. Und nebenbei gesagt wäre die Verbreitung von *Killerapplikationen* wie apache oder Samba längst nicht so hoch, wenn sie nicht auch unter Solaris, AIX, HP-UX usw. laufen würden - und die werden ja auch während des Bootvorgangs gestartet. SCNR Jan