Hmm zaujimave. Neviem ako ostatni, ale mne sekvencne spustanie init skriptov uplne vyhovuje. Ma to dve velmi dobre vlastnosti:
1. Ked sa nieco stane, viem presne v ktorom kroku sa to stalo a dokazem to vysledovat az ku pricine. Ak vsetko bezi paralelne, smola. Vznikne skoro nerozlustitelny bordel.
2. Dlhy start ma nuti optimalizovat init skripty a teda sa zbavit zbytocnych a nepotrebnych veci.
Je zaujimave ze to zavadza prave Ubuntu. Ten system vo mne zanechal pocit ala Windows. neprehladny a skoro nefunkcny bordel. Po mesiaci ked som ho nedokazal prinutit aby fungoval podla mojich predstav som sa vratil ku Gentoo. Nevadi ze gentoo nevedel automount USB a podobne ficurky. Hlavne sa dokazal prisposobit mojim poziadavkam.
Jedna vec na zamyslenie. Predstavte si ze sa start systemu zastavi na manualnej akcii (napriklad fsck potrebuje pomoct). Ako upstart garantuje ze system caka na zasah a nesnazi sa (s poriadnymi problemami) dalej startovat ?
Pokud se služby startují paralelně, v případě selhání startu některé služby nebudou nastartovány služby závislé, a uživatel bude na selhání služby upozorněn (ve Windows).
Paralelní start umožňuje zkrátit dobu startu. Samozřejmě to závisí na řadě dalších věcí (třeba co se startuje :) ), ale obecně to tak je.
Manuální akce u startu služby nepřipadá (ve Windows) v úvahu. Služba nemá uživatelský interface - od toho je to služba (tak je psáno v design guides; byly i služby, které se toho nedržely). Chkdsk (na unixech fsck) u žurnálového FS pomoci nepotřebuje; po startu provede rollback/commit dle údajů z žurnálu, a víc se nic neřeší. Pokud je vážně corrupted root FS, dozví se to uživatel ještě před startem služeb. Odpojení (nepřipojení) FS na kterém sídlí služby se projeví jejich nespuštěním. Pokud služba nenajde data (protože jí chybí FS), musí si s tím stejně poradit sama.
