Das wurde im englischen Artikel erwähnt. Initng ist dependency-basiert. Willst du C starten und C braucht B und B braucht A, dann wird erst A, dann B, dann C gestartet.
Bei upstart ist das Konzept schon mal ganz anders. Events!
So wie ich das verstanden haab, kann das upstart. Und eben noch mehr. Ein event kann eben sein, das ein anderes service gestartet oder beendet ist. Damit kann man dependencies ausdrücken. Nachdem A gestartet ist startet B, nachdem B gestartet ist startet C.
Jo es gibt ungefähr 2-3 dependencies jene welche die dienste warten müssen die kann man einfach mit geht einfach mit "wait" dazu braucht man kein ubuntustart. Das ist bereits in der bash drin, Handbuch lesen hilft manchmal.
Hmm ja und was ist mit den bsd-style scripts von slackware? Die sind geschwindigkeitstechnisch Ubuntu auch überlegen. Ehrlich gesagt wäre es wohl besser einfach mal wieder Gedönz rauszunehmen anstatt immer wieder neues zu erfinden. Im Zeitalter des Bootsplash kann man sich doch wirklich mit bsd-skripten abfinden. Ubuntu wird für alte Linuxhasen immer unbedienbarer...
Ja geb ich zu lernunwillig. Aber mal ehrlich welche Firma setzt den bitte Ubuntu ein? Gibt es einen Grund sich Wissen über das Pseudostandard anzueignen? Ich meine Suse, Redhat etc haben ja auch (leider) häufig ihr eigenes Würtschen gegrillt, aber die konnten es sich von ihrer Marktposition her eben leisten. Ubuntu kann es meiner Ansicht nach nicht. Mittlerweile hat auch Novell/Suse einsehen müssen das man es für eine Distro eben ein Pluspunkt ist wenn alles so funktioniert wie bei der Konkurrenz.
Ich denke trotz dessen, dass Ubuntu den Status der am meistverbreiteten Distribution besitzt. Lustig, dass "weißt" hier zweimal falsch geschrieben wurde, einmal wie beim weisen alten Mann, und einmal mit der falschen Version der neuen Rechtschreibung, die so gern benutzt wird.
Also meine Firma z.B. setzt auf allen (6) Arbeitsplätzen und im Backoffice vollständig auf Kubuntu und wir sind recht zufrieden damit. Denke es werden in Zukunft noch mehr werden. Zumindest haben sich schon einige Partnerunternehmen usere IT-Infrastruktur angeschaut und überlegen nun auch umzusteigen.
Von Banana Republic am Di, 29. August 2006 um 15:27 #
Abwarten und Tee trinken. Das Ubuntu in gar nicht so langer Zeit auch im kommerziellen Einsatz sehr, sehr starke Verbreitung finden wird, kann ich Dir auch ohne Glaskugel sagen
Von Alte Männer denken sehr langsa am Di, 29. August 2006 um 13:12 #
Dann sollte Slackware schnellstens seinen Pseudostandard loswerden. Diese Dinosaurier-Distribution besitzt einen derartig marginalen Anteil an den verwendeten Linuxen, dass sie es sich gar nicht leisten kann die Standards der Grossen (RH, Novell, Ubuntu) nicht zu benutzen.
> Die sind geschwindigkeitstechnisch Ubuntu auch überlegen.
1) die aktuelle ubuntu version (6.06) verwendet das neues system noch nicht. 2) ist es noch lange nicht fetig 3) geht es nicht (nur) um die geschwindigkeit sondern vor allem darum neue anforderungen die zu desktopsystemen in den letzten hinzugekommen sind zu erfüllen.
> Ehrlich gesagt wäre es wohl besser einfach mal wieder Gedönz rauszunehmen anstatt > immer wieder neues zu erfinden. Im Zeitalter des Bootsplash kann man sich doch > wirklich mit bsd-skripten abfinden.
sorry, aber für mich hört sich das nach "das hab ich jetzt jahre lang erfolgreich verwendet, da kann was neues nicht gut sein." an.
ich würde dir empfehlen den link auch durchzulesen. dort wird erklärt warum ein neues system benötigt wird.
> Ubuntu wird für alte Linuxhasen immer unbedienbarer...
wenn "alte linuxhasen" nicht bereit sind neues zu lernen werden sie wohl in zukunft mit allen distributionen probleme haben, technik entwickelt sich nun mal weiter. das problem gibt es ja schon heute mit z.b. udev. ich finde es immer wieder lustig wenn leute in irgenwelchen foren empfehlen irgendwelche skripts zu hacken um module zu laden und permission anzupassen, statt einfach die passende udev-rule zu erstellen.
Udev ist ein sinnvoller Standard der von allen Distros unterstützt wird. Das Ubuntu-Init-System ist schon jetzt so verkorkt, dass man es meiner Ansicht nach besser nicht mehr weiterentwickelt. Ubuntu hat einfach den langsamsten Bootprozess, anstatt da noch weiter damit herumzumachen wäre es eben sinnvoll ein besser Technik einzusetzen. BSD-Skripte sind schnell, flexibel und bei Bedarf asynchron. Das Pamphlet is ebenso wie dein Posting reine Rhetorik. Es wird aber auch wirklich gar nichts besser. Bitte wenigstens ein Argument posten warum das neue Initsystem besser sein soll als BSD. Ich finde es überhaupt mit Kanonen auf Spatzen geschossen. Da kommt viel Kritik an bestehendem und heisse Luft von wegen alles soll besser werden. Nur Vaporware gibt es bereits genug in der IT.
Hm dann dürfte vom Start her wohl einige andere Distributionen die wesentlich mehr Dienste starten noch um einiges langsamer sein. Außerdem habe ich bei Ubuntu noch nirgends ein Verbot gesehen nicht benutzte Dienste zu entfernen oder einen selbst kompilierten und auf meine Bedürftnisse zugeschnittenen Kernel zu verwenden.
Slackware startet mit der selben Anzahl von Diensten deutlich schneller sowohl unter 2.4 als auch unter 2.6 kernel. Wers nicht glaubt solls ausprobieren (Slackwareinstallation daurt lediglich 30 minuten) und das alles ohne Anpassung der Skripte. Klar ist die Bootzeit unter Linux weniger wichtig als unter Windows, trotzdem Fakt ist: Keine mir bekannte Distro bootet so langsam wie Ubuntu. Es gäbe also viel aufzuräumen, bevor man mit upstart anfängt.
> trotzdem Fakt ist: Keine mir bekannte Distro bootet so langsam wie Ubuntu.
ich weiß nicht woher du deine fakten nimmst, aber untern der mir bekannten distributionen ist ubuntu noch eine der schnelleren. zugegeben, ich hab slackware schon seit jahren nicht mehr verwendet, aber im vergleich mit z.b. debian (auf welchem ubuntu ja aufbaut) startet es deutlich schneller. ubuntu ist in sachen startzeiten vielleicht nicht das optimum, aber als störend empfinde ich die startzeiten nicht.
> Es gäbe also viel aufzuräumen
ich weiß ja nicht welche ubuntu version du kennst, aber wird da auch noch. beim - wenn ich es richtig in erinnerung habe - sprung zu 5.10 hat sich bootzeit deutlich verschnellert.
> bevor man mit upstart anfängt.
also deiner meinung darf man sich erst gedanken über neue entwicklungen machen, wenn man das alte bis zum äußersten optimiert hat?
... trotzdem ist nicht nur relevant, was technisch möglich und gut ist, sondern auch die historische Entwicklung und Konzeption des Systems in der Vergangenheit. Das Konzept ist zu befürworten, sprachlich sollte es jedoch mehr in die Fusstapfen des bisherigen Systems treten um den Link zum bisherigen herzustellen, die Akzeptanz zu verbessern und die doch in seiner Zeit recht fortschrittliche Technik entsprechend zu würdigen. Einen gewissen Stolz auf die damals überragenden Konzepte sollte man schon haben, sonst meint noch jemand, nur Microsoft und Apple habe eine Geschichte gehabt.
Ich finde das ist eine gute Sache. ArchLinux hat jetzt schon ein vereinfachtes BSD-init (welches ich angenehmer als SYS-V finde). Aber mit upstart kann man das ganz noch vereinfachen und angenehmer machen.
Bin mal gespannt, ob und wann upstart in ArchLinux einzieht.
das haben vector, zenwalk, slackware, pocketlinux etc auch. Im Prinzip gibt es nur suse, fedora, mandriva etc. die es nicht haben. Die BSD-skripts sind einfach und leicht verständlich und erlauben asynchrones starten von Dienste. Das ganze sysv-init und initng ist daher echt überflüssig. Besser wäre wohl so lustig Icons in den bootsplash zu machen, wie bei MacOS. Dort gibt es schon seit System 6 für jeden Dienst ein Bildchen. Das wäre innovativ.
Besser wäre wohl so lustig Icons in den bootsplash zu machen, wie bei MacOS. Dort gibt es schon seit System 6 für jeden Dienst ein Bildchen. Das wäre innovativ. Das konnten die alten Bootsplashs von SuSE 7.1 schon
Ubuntus Lösung hingegen ist System V basiert. Am Ende kommts immer auf SysV raus
SysV ist zu langsam, zu unflexibel und kann nicht ordentlich mit asynchron umgehen. Das mit den Bildchen ist nicht technisch aufwendig es fehlt nur der standard, schön zu sehen das ubuntu wieder standards kaputt macht anstatt auf jahrelange bewährte technik zu setzen-
Manche müssen erstmal auf die Nase fallen, bevor sie kappieren, daß etwas Etabliertes nicht automatisch Müll ist.
Was ich vermisse, ist eine Sammlung an Hintergrundinformation: Wo kann ich nachlesen, welche (z.B.) Init-Ansätze es gibt und gab und warum welcher Ansatz verworfen wurde? Eine solche quasiarchäologische Arbeit scheint bisher niemanden wirklich zu begeistern und so wundert es nicht, wenn dasselbe Thema immer wieder angegangen wird.
Auch ArchLinux verwendet, genauso wie Slackware, sysvinit, welches /etc/inittab ausliest und entsprechend die Skripte in /etc/rc.d ausführt. Mit diesen (bescheuerten) Symlinks in /etc/rcX.d hat sysvinit erst einmal nichts zu tun. Dafür sorgen die auf sysvinit aufsetzenden Init-Scripts.
Wers nicht glaubt: http://www.archlinux.org/packages/4080/ http://www.slackware.it/pb/package.php?q=current/sysvinit-2.84-i486-66
Von Trolley the Troll am Di, 29. August 2006 um 12:50 #
[ ] Du hast den Inhalt der Dikussion verstanden
=> es geht hier übheraupt nicht um sysvinit (das wird natürlich allen Distros verwendet) sondern nur um den Aufbau der INIT-Skripte. Also System-V vs. BSD und nicht sysvinit vs. BSD
Auch wenn ich der Meinung bin, daß ein init Nachfolger nötig ist, sollte man sowas nicht als ein-Mann Projekt durchziehen. Scott's Ideen finde ich schon recht ordentlich (den Code selber habe ich mir noch nicht angesehen), bis zu dem Punkt wo er D-BUS angreift. D-BUS soll natürlich nicht selber init Nachfolger werden, aber für ein Event-basiertes init System ist das verwendete IPC Protokoll schon recht wichtig, und so recht verstehe ich nicht was er da nun gegen D-BUS hat, und schon wieder was eigenes einsetzen will --- und dann mittels proxies die Events evtl. an D-BUS weiterreichen möchte.
Das macht das System unnötig kompliziert und schreit geradezu nach Inkonsistenzen in der Behandlung der Events.
Ich fürchte solche fundamentalen Design Entscheidungen hätte er besser vorher mit alten Unix/Linux/DE Hasen diskutieren sollen, so ist upstart auch nur wieder ein Vorschlag unter vielen.
hmm ja das steht upstart wird alles bisher ersetzen die skript werden zwar weiterlaufen aber wenn ich features will die upstart nicht hat bin ich am a***
Welche Features brauchst Du denn so dringend? Und was meinst Du warum ich geschrieben hab, daß ich bei upstart die Diskussion mit den alten Hasen, was denn nun in ein init System gehört und was nicht, vermisse. Natürlich kann man so ein System mit Features zuknallen, und man bekommt ein schwer wartbares träges Monster. Man kann es auch mit der Schlankheit übertreiben und bekommt dann ein System, daß so rudimentär ist, daß jede Distribution wieder ihren eigenen Aufsatz bastelt um etwas tatsächlich nutzbares zu haben.
Irgendjemand (warst das nicht Du?) forderte doch das starten eines Backups in Abhängigkeit von der Systemlast. Das ist zwar ein schönes Feature, aber ich nehme an, das könnte man genausogut in das Backup Programm selber verlagern: Dann hat man sogar in den Logfiles des Backups sowas wie "Backup canceled because of high system load" wo es ja wohl hingehört und nicht in den logfiles des sysloggers, oder man könnte ein eigenes kleines Tool schreiben, daß von init/upstart aufgerufen den Job in Abhängigkeit der Systemlast startet. Dann würde jedes Programm davon profitieren, trotzdem es nicht den init Prozess "verfettet".
Hauptsache das System ist mal schneller oben. Ich benutz z.Z. initng, weil ich nicht ewig zeit habe, bis mein system gebootet ist. Wenn man das mal mit einem crux bsdinit vergleicht, weiß man, dass das sysvinit weg muss!
Ich boote meine Büro-/Kommuniklationskiste(n) nach Stromausfall, Crash und Kernelwechsel, wobei dies alles seltene Ereignisse sind.
Meine Laborratten... ääääh Pinguine und Dämönchen werden schon häufiger gebootet, aber da schert's mich nicht wirklich ob 'n Boot 'ne halbe Minute dauert oder 15 Sekunden mehr.
Was hätte ich von nem neuen Init-Verfahren?
Na gut, ich bin von Natur aus neugierig und schau mir das mal an, aber mich interessieren nur die administrativen Vorteile und wenn es die nicht hat, dann nehme ich entweder den allerortens etablierten Platzhirsch oder das Ressorcensparendste, je nach Umgebung...
Für "how often will you reboot today"-Emulation sehe ich natürlich ein, daß man jede Sekunde aus dem Bootprozeß rausquetschen muß, um die wichtigen Briefe geschrieben zu bekommen bevor man das Rentenalter erreicht, aber da hat man ja Müntemerkelition sei Dank alsbald 2 Jahre mehr Zeit!
Es geht ja auch darum das Starten von Diensten, das Mounten von Devices, die Reaktion auf abgestüzte Dienste, etc. flexibler und konsistenter zu behandeln. At und cron sind dann z.B. überflüssig, Dateisystemchecks/Mounten werden ausgelöst wenn die Platte hochgelaufen ist, und nicht wenn sie angesteckt wird aber noch garnicht betriebsbereit ist und die Distributionshersteller können den 3rd Party Entwicklern das Leben leichter machen, indem sie nicht mehr in /etc/init.d/ ihr eigenes Süppchen kochen.
Daß ein paralles Startup in einem solchen System einfacher zuverlässig zu implementieren ist, und damit das booten etwas beschleunigt wird halte ich eher für einen angenehmen Nebeneffekt.
Cron überflüssig zu machen ist sehr schlecht, denn ich würde sehr gerne darüber entscheiden welches Cron in meinem System läuft. Wenn Ubuntu da sein eigenes System reinquetscht geht mir diese Freiheit verloren.
Die Auswahl haben und etwas zu Standardisieren sind numal zwei wiedersprüchliech Bestrebungen.
Aber ich glaube fest daran, daß wenn man die Erfahrungen der bisherigen crons berücksichtigt, daß dann ein würdiger Nachfolegr für cron geschaffen wird, bzw. die heutigen Möglichkeiten der "erweiterten crons" sich anders (und evtl. sinnvoller und/oder portabler) implementieren lassen.
"die heutigen Möglichkeiten der "erweiterten crons" sich anders (und evtl. sinnvoller und/oder portabler) implementieren lassen." Sehr intelligent, trotz jahrzehntelanger Erfahrung gibt es noch immer vi und Emacs. Nicht alles lässt sich eben funktionieren, verschiedene Menschen wollen verschiedene Programme
Es geht hier nicht um individuelle Vorlieben bei Benutzeroberflächen oder Editoren, sondern um technisch elegante und flexible Lösungen für konkrete Probleme. Ein passenderes Beispiel ist eher die Entwicklung vom statischen /dev über devfs zum udev System. Oder HAL und D-BUS als grundlegnde und DE- bzw. Plattformübergreifende Lösung. Dort hat man auch proprietäre Lösungen wie dcop oder ungeeignete wie CORBA bzw. bonobo ausprobiert bevor man sich jetzt auf diese Lösung geeinigt hat. Nun portieren selbst die BSD Entwickler D-BUS.
Mit persönlichen Vorlieben wie vi, emacs oder "moderner" GUI Editor (ich nutze selber den emacs) hat das nichts zu tun.
komisch HPUX,AIX, BSD hatten da noch die Probleme und die setzen ist Jahren auf BSD-Skripte. Vor allem IBM und HP sind ja bekannt, dafür gerne eigene Standards zu pushen haben es aber hier nie gemacht. Der Vorteil? Ein Dämon trägt sich unter HPUX,AIX, BSD, bsd-init-Linux usw. immer gleich ein. 3rd-Party Entwickler dürfte das sehr freuen, anstatt irgendwelcher Extrawürste.
Es macht wohl keinen Sinn für 3rd-Party-Entwickler sich so derart tief im System zu vergraben. Die Platte läuft auch weiterhin im gleich hoch, das tut sie immer noch unter jedem Linux unverändert. Da gibt es auch recht wenig zu optimieren. Es wäre also interessanter wenn Ubunut nicht sein eigenes Süppchen kocht, vor allem wenn dann am Ende nur braune Brüher rauskommt.
http://en.wikipedia.org/wiki/Init#BSD-style [...] BSD-style [...] Problems: If a 3rd-party package needs to have an initialization script run during the boot procedure, it needs to edit one of the existing boot scripts, but a simple mistake in that process could lead to an unbootable system.
Nichts gegen BSD, aber BSD style init ist nun wirklich nicht der Weisheit letzter Schluß. Und warum 3dr Party Entwickler sich nicht an Server wagen dürfen verstehe ich nicht. Ich habe hier z.B. einen kommerziellen Upnp Server und Vmware init Skripte aber es gibt sicherlich noch wesentlich mehr.
"Problems: If a 3rd-party package needs to have an initialization script run during the boot procedure, it needs to edit one of the existing boot scripts, but a simple mistake in that process could lead to an unbootable system."
Also erstens mal wenn jemand ein falsches initskript einspielt kann das immer zu einem nicht bootbaren System führen, wenn mein "Modprobe" den Kernel aufhängt dann helfen mir auch Sys-V-Skripte nicht weiter. Da gibt es also keinen Unterschied.
Man kann ihn BSD alles möglich definieren um es für 3-Parties leichter zu machen es gibt ja externe Befehle, als rc.httpd zum Beispiel die aufgerufen werden. Du erzählst hier also echten Müll.
Wenn ich 3rd-Party-Plugin schreiben will/muss das ein eigenes Skript hinzufügt sollte ich das immer am Ende tun, es sei denn ich weiss auf welche Dienste ich warten muss. Damit ist der Vorteil Plattformunabhängigkeit also dahin. Die gibt es nämlich gar nicht.
Wer einen Webservers starten will nennt seinen Dienst rc.httpd usw. Das gibt also gar keine Probleme mit BSD-Skripten. Du beschäftigst dich da auch mit einem Problem, das in der Praxis so kaum oder gar nicht auftaucht.
Fast jedes Unix und fast jede Linux-Distribution verwendet sysvinit, auch wenn manch einer es ungern zugibt. Sobald man eine Datei namens /etc/inittab vorfindet, ist es sysvinit.
Deinem eingeschränkten Weltbild will ich einen neuen Horizont verschaffen: denk bitte mal an Notebooks, auf denen Resume/Supsend-Meachnismen aus irgendwelchen gründen nicht funktionieren und daher bei Standortwechseln meist ausgeschaltet werden. Für diese wäre ein schnelleres Verfahren ein segen!
Ja mit upstart waere der Boot schneller - allerdings ist das nur ein Vorteil. Parallelstart mehrerer Dienste geht mit upstart. Aber wie gesagt: nur ein Vorteil (den andere Systeme wie initng ebenfalls haben)
Da freue ich mich schon drauf! Ich lasse zwar meinen Rechner meistens den Arbeitstag über durchlaufen, aber wenn man mal schnell den Rechner starten lassen muss -weils Telefon unverhofft klingelt und ein Kunde dran ist- zählt jede Sekunde. Ich kann mir als Laie sowiso nicht erklären warum ich hier über eine Minute warten muss. Bei 1,2 Milliarden Rechenoperationen pro Sekunde sollte es doch blitzschnell gehen.
Ich programmiere ein wenig Mikrocontroller- Einschalten, Systemtest, Display konfigurieren und Starten und ein paar hundert mal einen Text ausgeben dauern bei 8MHz unter einer zehntel Sekunde.
Ich glaube nicht, dass es wesentlich schneller wird im Vergleich zu anderen asynchronen Init systemen. Was upstart bringt ist flexibilität. Daemons können basierend auf events gestartet, gestoppt und vorallem re-startet werden. Sehr nützlich für Laptop / Desktop.
Der Ansatz mit den Events ist jedoch nicht ohne Probleme. Das System wird dadurch untransparente. Erinnert mich an Trigger aus der Datenbankwelt. Ab einer gewissen Komplexität blickt keiner mehr durch, wann welcher Trigger gefeurert wird ;-)
Cron abzulösen ist aber ein haariges unterfangen. Wird es dann funktionieren wie fcron, womit ich anhand verschiedener Kriterien den Start von Programmen und Skripten auslösen kann? So ist z.B. mit fcron es leicht möglich Backups an Wochentagen zwischen 22 und 2 Uhr bei einer 15 Minütigen load von weniger als 0.5 zu starten. Das ist sehr praktisch, denn so kann eine Arbeitspause herausgefunden und genutzt werden - ein Feature das ich nicht mehr missen möchte.
Von Felix Schwarz am Di, 29. August 2006 um 10:55 #
Insbesondere hat Cron auch sehr viele Features, die auf den ersten Blick nicht so offensichtlich sind. Einen einfachen Cron-Daemon habe ich schon selber in weniger als einer Woche geschrieben (für Windows). Wenn man aber z.B. Änderungen der Systemzeit ebenfalls berücksichtigen will, wird das ganze doch schnell deutlich komplexer!
Außerdem sehe ich noch nicht, was init mit cron zu tun haben soll. Aus meiner Sicht sind das zwei völlig getrennte Sachen. Höchstens könnten ein paar cron-Einträge überflüssig werden, die prüfen sollen, ob ein Dienst noch läuft und den Dienst ggf. neu starten.
Außerdem sehe ich noch nicht, was init mit cron zu tun haben soll. upstart soll - ähnlich launchd auf MacOS X - sowohl init als auch crond ablösen. Man braucht nur das Erreichen eines bestimmten Zeitpunktes als Ereignis zu definieren.
Von M wie Meikel am Di, 29. August 2006 um 16:20 #
Hmm, noch ein Versuch, das klassische SysV init zu ersetzen. Und zwar einer, der die Aufgabe von init durch ein System ersetzen will, in dem alles Event-getriggert ist. Ich habe mir den verlinkten Blog-Eintrag durchgelesen, ein wenig in den Sourcen gestöbert und bei Google weitere Infos gesucht. Dass das meine Fragen restlos beantwortet hat, kann ich aber nicht sagen.
- Wo kommen die Events her? Die Rede ist zuerst von "generated by the system", aber wie teilt das System denn upstart mit, dass z.B. das Root-Dateisystem jetzt beschreibbar ist? Vor allem, wenn upstart der erste Prozeß ist, der gestartet wird. Überwacht upstart das alles doch selber? Was genau wird überwacht? Wie wird überwacht? Welche Auswirkungen hat das auf die Systemleistung? Wie sehen solche "Event-Sensoren" aus?
- Das State-Diagramm beinhaltet keine Vorkehrungen für den Fehlerfall. Was passiert, wenn z.B. ein Dämon nicht gestartet werden kann? Sollte man für solche Situationen (die den Admin wahrscheinlich brennend interessieren) nicht auch Events bereit halten? Dass die Scripte in /etc/rc*.d/etc/init.d keinen Status zurückmelden können, ist in meinen Augen ein wesentlicher Nachteil des herkömmlichen Systems, und das scheint upstart - anders als launchd oder fma- leider auch zu ignorieren.
- Das Event-Konzept passt für meinen Geschmack wenig auf die üblichen Aufgaben, die beim Starten bzw. Runterfahren eines Systems nötig sind. Es gibt Abhängigkeiten zwischen verschiedenen Tasks, die die Reihenfolge festlegen. Da reicht es, wenn nach dem Script "basic-networking" das Script "apache" aufgerufen wird, dazu muss ich nicht erst diverse Events wie "localhost configured", "default route set", etc generieren oder überprüfen, von denen dann die meisten eh nicht benötigt werden.
- Die Beispiele, warum Events eine tolle Sache sind, beziehen sich eigentlich vollständig auf Hotplug-Geschichten und dafür gibt es Lösungen wie Volume Manager und udev, die das prima erledigen. Das ist aber eine andere Baustelle als der Systemstart, und ich sehe nicht die Notwendigkeit, diese beiden Dinge (und noch viel mehr) miteinander zu vermischen.
- Warum upstart und launchd ähnlich sind, erschliesst sich mir nicht. Apple beschreibt das nirgendwo als "Event-basiert". die Rede ist z.B. von "The launchd daemon offers a single, standardized, interface to any and all programs started automatically by the system." Da hätte ich mir einee ausführlichere Begründung gewünscht, warum man dann nicht launchd als Ausgangspunkt genommen hat.
- D-BUS als IPC-Mechanismus ist wahrscheinlich wirklich nicht ideal für upstart. Wobei das die Frage offen läßt, wie der verwendete IPC-Mechanismus aussieht. Das ganze Konzept klingt für mich noch sehr wolkig. Upstart erzeugt, überträgt und verarbeitet Events, wie das genau aussieht, wird aber nicht verraten.
- Dann ist die Rede davon, dass jeder Prozess Events an upstart verschicken kann. Welche Prozesse sollen das denn tun, und wie sieht es mit Security-Dingen aus, damit z.B. kein normaler Benutzer Hardware-Events vortäuschen kann?
Ich bin da sehr skeptisch, ob das in der Praxis gut funktioniert. Und ob man da nicht lieber etwas mehr Gehinschmalz ins Konzept gesteckt hätte, anstatt später mit viel mehr Aufwand nachzubessern.
Initng ist dependency-basiert.
Willst du C starten und C braucht B und B braucht A, dann wird erst A, dann B, dann C gestartet.
Bei upstart ist das Konzept schon mal ganz anders. Events!
aber auch upstart muss dependancies audruecken koennen...
Lustig, dass "weißt" hier zweimal falsch geschrieben wurde, einmal wie beim weisen alten Mann, und einmal mit der falschen Version der neuen Rechtschreibung, die so gern benutzt wird.
Zeit auch im kommerziellen Einsatz sehr, sehr starke
Verbreitung finden wird, kann ich Dir auch ohne Glaskugel
sagen
Du Schlaumeier hast sicherlich bemerkt, daß Günter eine österreichische GMX-Adresse verwendet, oder?
Martin
1) die aktuelle ubuntu version (6.06) verwendet das neues system noch nicht.
2) ist es noch lange nicht fetig
3) geht es nicht (nur) um die geschwindigkeit sondern vor allem darum neue anforderungen die zu desktopsystemen in den letzten hinzugekommen sind zu erfüllen.
> Ehrlich gesagt wäre es wohl besser einfach mal wieder Gedönz rauszunehmen anstatt
> immer wieder neues zu erfinden. Im Zeitalter des Bootsplash kann man sich doch
> wirklich mit bsd-skripten abfinden.
sorry, aber für mich hört sich das nach "das hab ich jetzt jahre lang erfolgreich verwendet, da kann was neues nicht gut sein." an.
ich würde dir empfehlen den link auch durchzulesen. dort wird erklärt warum ein neues system benötigt wird.
> Ubuntu wird für alte Linuxhasen immer unbedienbarer...
wenn "alte linuxhasen" nicht bereit sind neues zu lernen werden sie wohl in zukunft mit allen distributionen probleme haben, technik entwickelt sich nun mal weiter.
das problem gibt es ja schon heute mit z.b. udev. ich finde es immer wieder lustig wenn leute in irgenwelchen foren empfehlen irgendwelche skripts zu hacken um module zu laden und permission anzupassen, statt einfach die passende udev-rule zu erstellen.
Das Ubuntu-Init-System ist schon jetzt so verkorkt, dass man es meiner Ansicht nach besser nicht mehr weiterentwickelt. Ubuntu hat einfach den langsamsten Bootprozess, anstatt da noch weiter damit herumzumachen wäre es eben sinnvoll ein besser Technik einzusetzen.
BSD-Skripte sind schnell, flexibel und bei Bedarf asynchron. Das Pamphlet is ebenso wie dein Posting reine Rhetorik. Es wird aber auch wirklich gar nichts besser. Bitte wenigstens ein Argument posten warum das neue Initsystem besser sein soll als BSD. Ich finde es überhaupt mit Kanonen auf Spatzen geschossen. Da kommt viel Kritik an bestehendem und heisse Luft von wegen alles soll besser werden. Nur Vaporware gibt es bereits genug in der IT.
Grüße
Sascha
ich weiß nicht woher du deine fakten nimmst, aber untern der mir bekannten distributionen ist ubuntu noch eine der schnelleren. zugegeben, ich hab slackware schon seit jahren nicht mehr verwendet, aber im vergleich mit z.b. debian (auf welchem ubuntu ja aufbaut) startet es deutlich schneller. ubuntu ist in sachen startzeiten vielleicht nicht das optimum, aber als störend empfinde ich die startzeiten nicht.
> Es gäbe also viel aufzuräumen
ich weiß ja nicht welche ubuntu version du kennst, aber wird da auch noch. beim - wenn ich es richtig in erinnerung habe - sprung zu 5.10 hat sich bootzeit deutlich verschnellert.
> bevor man mit upstart anfängt.
also deiner meinung darf man sich erst gedanken über neue entwicklungen machen, wenn man das alte bis zum äußersten optimiert hat?
nicht das stärkste und auch nicht das intelligenteste wesen wird überleben,
sondern das, welches am ehesten bereit ist sich anzupassen.
ciao
ArchLinux hat jetzt schon ein vereinfachtes BSD-init (welches ich angenehmer als SYS-V finde). Aber mit upstart kann man das ganz noch vereinfachen und angenehmer machen.
Bin mal gespannt, ob und wann upstart in ArchLinux einzieht.
Gruß Johannes
http://www.hehejo.de
Besser wäre wohl so lustig Icons in den bootsplash zu machen, wie bei MacOS. Dort gibt es schon seit System 6 für jeden Dienst ein Bildchen. Das wäre innovativ.
Ubuntus Lösung hingegen ist System V basiert.
Das konnten die alten Bootsplashs von SuSE 7.1 schon
Ubuntus Lösung hingegen ist System V basiert.
Am Ende kommts immer auf SysV raus
Das mit den Bildchen ist nicht technisch aufwendig es fehlt nur der standard, schön zu sehen das ubuntu wieder standards kaputt macht anstatt auf jahrelange bewährte technik zu setzen-
Was ich vermisse, ist eine Sammlung an Hintergrundinformation: Wo kann ich nachlesen, welche (z.B.) Init-Ansätze es gibt und gab und warum welcher Ansatz verworfen wurde? Eine solche quasiarchäologische Arbeit scheint bisher niemanden wirklich zu begeistern und so wundert es nicht, wenn dasselbe Thema immer wieder angegangen wird.
https://wiki.ubuntu.com/ReplacementInit
Mit diesen (bescheuerten) Symlinks in /etc/rcX.d hat sysvinit erst einmal nichts zu tun. Dafür sorgen die auf sysvinit aufsetzenden Init-Scripts.
Wers nicht glaubt:
http://www.archlinux.org/packages/4080/
http://www.slackware.it/pb/package.php?q=current/sysvinit-2.84-i486-66
=> es geht hier übheraupt nicht um sysvinit (das wird natürlich allen Distros verwendet) sondern nur um den Aufbau der INIT-Skripte. Also System-V vs. BSD und nicht sysvinit vs. BSD
Das macht das System unnötig kompliziert und schreit geradezu nach Inkonsistenzen in der Behandlung der Events.
Ich fürchte solche fundamentalen Design Entscheidungen hätte er besser vorher mit alten Unix/Linux/DE Hasen diskutieren sollen, so ist upstart auch nur wieder ein Vorschlag unter vielen.
Richtig die Idee dahinter ist ja auch was einiges zu haben das eben das eben nicht mit anderen funktioniert.
anstatt hier lange neues schlecht zu reden solltest du dir einfach den link durchlesen. dort gibt es auch den absatz "What about compatibility?"
Irgendjemand (warst das nicht Du?) forderte doch das starten eines Backups in Abhängigkeit von der Systemlast. Das ist zwar ein schönes Feature, aber ich nehme an, das könnte man genausogut in das Backup Programm selber verlagern: Dann hat man sogar in den Logfiles des Backups sowas wie "Backup canceled because of high system load" wo es ja wohl hingehört und nicht in den logfiles des sysloggers, oder man könnte ein eigenes kleines Tool schreiben, daß von init/upstart aufgerufen den Job in Abhängigkeit der Systemlast startet. Dann würde jedes Programm davon profitieren, trotzdem es nicht den init Prozess "verfettet".
Sorry, ENOPARSE
Meine Laborratten... ääääh Pinguine und Dämönchen werden schon häufiger gebootet, aber da schert's mich nicht wirklich ob 'n Boot 'ne halbe Minute dauert oder 15 Sekunden mehr.
Was hätte ich von nem neuen Init-Verfahren?
Na gut, ich bin von Natur aus neugierig und schau mir das mal an, aber mich interessieren nur die administrativen Vorteile und wenn es die nicht hat, dann nehme ich entweder den allerortens etablierten Platzhirsch oder das Ressorcensparendste, je nach Umgebung...
Für "how often will you reboot today"-Emulation sehe ich natürlich ein, daß man jede Sekunde aus dem Bootprozeß rausquetschen muß, um die wichtigen Briefe geschrieben zu bekommen bevor man das Rentenalter erreicht, aber da hat man ja Müntemerkelition sei Dank alsbald 2 Jahre mehr Zeit!
Es geht ja auch darum das Starten von Diensten, das Mounten von Devices, die Reaktion auf abgestüzte Dienste, etc. flexibler und konsistenter zu behandeln. At und cron sind dann z.B. überflüssig, Dateisystemchecks/Mounten werden ausgelöst wenn die Platte hochgelaufen ist, und nicht wenn sie angesteckt wird aber noch garnicht betriebsbereit ist und die Distributionshersteller können den 3rd Party Entwicklern das Leben leichter machen, indem sie nicht mehr in /etc/init.d/ ihr eigenes Süppchen kochen.
Daß ein paralles Startup in einem solchen System einfacher zuverlässig zu implementieren ist, und damit das booten etwas beschleunigt wird halte ich eher für einen angenehmen Nebeneffekt.
Aber ich glaube fest daran, daß wenn man die Erfahrungen der bisherigen crons berücksichtigt, daß dann ein würdiger Nachfolegr für cron geschaffen wird, bzw. die heutigen Möglichkeiten der "erweiterten crons" sich anders (und evtl. sinnvoller und/oder portabler) implementieren lassen.
Sehr intelligent, trotz jahrzehntelanger Erfahrung gibt es noch immer vi und Emacs. Nicht alles lässt sich eben funktionieren, verschiedene Menschen wollen verschiedene Programme
Es geht hier nicht um individuelle Vorlieben bei Benutzeroberflächen oder Editoren, sondern um technisch elegante und flexible Lösungen für konkrete Probleme. Ein passenderes Beispiel ist eher die Entwicklung vom statischen /dev über devfs zum udev System. Oder HAL und D-BUS als grundlegnde und DE- bzw. Plattformübergreifende Lösung. Dort hat man auch proprietäre Lösungen wie dcop oder ungeeignete wie CORBA bzw. bonobo ausprobiert bevor man sich jetzt auf diese Lösung geeinigt hat. Nun portieren selbst die BSD Entwickler D-BUS.
Mit persönlichen Vorlieben wie vi, emacs oder "moderner" GUI Editor (ich nutze selber den emacs) hat das nichts zu tun.
Es macht wohl keinen Sinn für 3rd-Party-Entwickler sich so derart tief im System zu vergraben. Die Platte läuft auch weiterhin im gleich hoch, das tut sie immer noch unter jedem Linux unverändert. Da gibt es auch recht wenig zu optimieren. Es wäre also interessanter wenn Ubunut nicht sein eigenes Süppchen kocht, vor allem wenn dann am Ende nur braune Brüher rauskommt.
[...]
BSD-style
[...]
Problems: If a 3rd-party package needs to have an initialization script run during the boot procedure, it needs to edit one of the existing boot scripts, but a simple mistake in that process could lead to an unbootable system.
Nichts gegen BSD, aber BSD style init ist nun wirklich nicht der Weisheit letzter Schluß. Und warum 3dr Party Entwickler sich nicht an Server wagen dürfen verstehe ich nicht. Ich habe hier z.B. einen kommerziellen Upnp Server und Vmware init Skripte aber es gibt sicherlich noch wesentlich mehr.
Also erstens mal wenn jemand ein falsches initskript einspielt kann das immer zu einem nicht bootbaren System führen, wenn mein "Modprobe" den Kernel aufhängt dann helfen mir auch Sys-V-Skripte nicht weiter. Da gibt es also keinen Unterschied.
Man kann ihn BSD alles möglich definieren um es für 3-Parties leichter zu machen es gibt ja externe Befehle, als rc.httpd zum Beispiel die aufgerufen werden. Du erzählst hier also echten Müll.
Wenn ich 3rd-Party-Plugin schreiben will/muss das ein eigenes Skript hinzufügt sollte ich das immer am Ende tun, es sei denn ich weiss auf welche Dienste ich warten muss. Damit ist der Vorteil Plattformunabhängigkeit also dahin. Die gibt es nämlich gar nicht.
Wer einen Webservers starten will nennt seinen Dienst rc.httpd usw. Das gibt also gar keine Probleme mit BSD-Skripten. Du beschäftigst dich da auch mit einem Problem, das in der Praxis so kaum oder gar nicht auftaucht.
Geht der Start jetzt schneller vonstatten?
Da war doch mal was in der Diskussion.
Parallelstart mehrerer Dienste?
Gruß
Mark
Da freue ich mich schon drauf!
Ich lasse zwar meinen Rechner meistens den Arbeitstag über durchlaufen, aber wenn man mal schnell den Rechner starten lassen muss -weils Telefon unverhofft klingelt und ein Kunde dran ist- zählt jede Sekunde.
Ich kann mir als Laie sowiso nicht erklären warum ich hier über eine Minute warten muss. Bei 1,2 Milliarden Rechenoperationen pro Sekunde sollte es doch blitzschnell gehen.
Ich programmiere ein wenig Mikrocontroller- Einschalten, Systemtest, Display konfigurieren und Starten und ein paar hundert mal einen Text ausgeben dauern bei 8MHz unter einer zehntel Sekunde.
Aber das ist wohl ne andere Welt
Der Ansatz mit den Events ist jedoch nicht ohne Probleme. Das System wird dadurch untransparente. Erinnert mich an Trigger aus der Datenbankwelt. Ab einer gewissen Komplexität blickt keiner mehr durch, wann welcher Trigger gefeurert wird ;-)
Konkretes Beispiel? (und komm mir jetzt nicht mit "/usr/sbin/httpd &" ohne Fehlerabfrage...)
Meinem letzten Stand nach startet Slackware einen Dienst nach dem anderen. Zwar äusserst schnell, aber nicht parallel.
Außerdem sehe ich noch nicht, was init mit cron zu tun haben soll. Aus meiner Sicht sind das zwei völlig getrennte Sachen. Höchstens könnten ein paar cron-Einträge überflüssig werden, die prüfen sollen, ob ein Dienst noch läuft und den Dienst ggf. neu starten.
fs
upstart soll - ähnlich launchd auf MacOS X - sowohl init als auch crond ablösen. Man braucht nur das Erreichen eines bestimmten Zeitpunktes als Ereignis zu definieren.
- Wo kommen die Events her? Die Rede ist zuerst von "generated by the system", aber wie teilt das System denn upstart mit, dass z.B. das Root-Dateisystem jetzt beschreibbar ist? Vor allem, wenn upstart der erste Prozeß ist, der gestartet wird. Überwacht upstart das alles doch selber? Was genau wird überwacht? Wie wird überwacht? Welche Auswirkungen hat das auf die Systemleistung? Wie sehen solche "Event-Sensoren" aus?
- Das State-Diagramm beinhaltet keine Vorkehrungen für den Fehlerfall. Was passiert, wenn z.B. ein Dämon nicht gestartet werden kann? Sollte man für solche Situationen (die den Admin wahrscheinlich brennend interessieren) nicht auch Events bereit halten? Dass die Scripte in /etc/rc*.d/etc/init.d keinen Status zurückmelden können, ist in meinen Augen ein wesentlicher Nachteil des herkömmlichen Systems, und das scheint upstart - anders als launchd oder fma- leider auch zu ignorieren.
- Das Event-Konzept passt für meinen Geschmack wenig auf die üblichen Aufgaben, die beim Starten bzw. Runterfahren eines Systems nötig sind. Es gibt Abhängigkeiten zwischen verschiedenen Tasks, die die Reihenfolge festlegen. Da reicht es, wenn nach dem Script "basic-networking" das Script "apache" aufgerufen wird, dazu muss ich nicht erst diverse Events wie "localhost configured", "default route set", etc generieren oder überprüfen, von denen dann die meisten eh nicht benötigt werden.
- Die Beispiele, warum Events eine tolle Sache sind, beziehen sich eigentlich vollständig auf Hotplug-Geschichten und dafür gibt es Lösungen wie Volume Manager und udev, die das prima erledigen. Das ist aber eine andere Baustelle als der Systemstart, und ich sehe nicht die Notwendigkeit, diese beiden Dinge (und noch viel mehr) miteinander zu vermischen.
- Warum upstart und launchd ähnlich sind, erschliesst sich mir nicht. Apple beschreibt das nirgendwo als "Event-basiert". die Rede ist z.B. von "The launchd daemon offers a single, standardized, interface to any and all programs started automatically by the system." Da hätte ich mir einee ausführlichere Begründung gewünscht, warum man dann nicht launchd als Ausgangspunkt genommen hat.
- D-BUS als IPC-Mechanismus ist wahrscheinlich wirklich nicht ideal für upstart. Wobei das die Frage offen läßt, wie der verwendete IPC-Mechanismus aussieht. Das ganze Konzept klingt für mich noch sehr wolkig. Upstart erzeugt, überträgt und verarbeitet Events, wie das genau aussieht, wird aber nicht verraten.
- Dann ist die Rede davon, dass jeder Prozess Events an upstart verschicken kann. Welche Prozesse sollen das denn tun, und wie sieht es mit Security-Dingen aus, damit z.B. kein normaler Benutzer Hardware-Events vortäuschen kann?
Ich bin da sehr skeptisch, ob das in der Praxis gut funktioniert. Und ob man da nicht lieber etwas mehr Gehinschmalz ins Konzept gesteckt hätte, anstatt später mit viel mehr Aufwand nachzubessern.