On Wed, Jan 19, 2011 at 10:54 AM, Culley Smith <culley.smith@xxxxxxxxx> wrote: > > Perhaps someone with more insight into this matter can speak up as to the > advantages of upstart vs System V init? boot times are more of a side affect. for upstart, this may have been a primary goal, but there is much more to systemd. sysvinit doesnt do anything for you.... _anything_ at all. you pass it a number, and it runs ONE app (usually) based on that number, and all other apps up to that number. it can respond to SIGINT, and SIGPWR as well, but thats it. everything else is giant bash scripts. everything you see in /etc/inittab is the extent of sysvinit's power. upstart takes advantage of udev to "bubble up" the init processes. events "emitted" by udev rules trigger various hook points. these hooks fulfill goals, and them emit more events to eventually complete the init goal process; in short, upstart takes a "bottoms up" approach to init -- where you end up is based on the chain of things that have already happened. a downside to this is most dependencies are explicit. systemd is my personal favorite; it is a solid concept and the most novel and complete solution. systemd is related to upstart, but works in the complete opposite direction. with systemd, you define where you WANT TO BE first, and actions "trickle down" to get you there. this is the directly comparative to your thought processes. for example, you set `apache` as a goal/target... apache is started first. if apache needs a filesystem that isnt mounted, it is automounted. if apache were to make a dbus request, the app on the other side is only started at that point, not before. and most importantly, if no one has made an http request yet... apache isnt even started.... but systemd listens on port 80, waiting to start apache when needed. systemd is highly related to Apple's launchd. init/pid 1 has special superpowers endowed to it by the kernel and we should be taking advantage of this, not cutting it off at the neck. not good for servers?? systemd allows you to actually _verify_ that what you wanted started is appropriately started. it lets you use dbus to query init and verify these things in a consistent and programmatic way. it uses cgroups to ensure that apps cannot double fork escape. you can use these cgroups to limit memory/cpu/etc on a per app basis. systemd uses socket/dbus/FS activation... meaning it blocks callers while it starts up the callee... this is 100% TRANSPARENT to the caller. this has nothing to do with "other distros using it". sysvinit has worked well yes; sometimes you fix things because there are better way or times change, not because it's "broke". seriously, have some vision :-) in short: upstart was a great kick in the ass, but i believe it works from the wrong direction though i applaud ubuntu for their vision while everyone is chanting "sysvinit works... blah blah woka woka woka". systemd is the future. it is a true system state manager, and takes over the menial aspects of startup/shutdown with fast code, and even other less trivial processes like RAID. it provides guarantees. it provides interfaces. it does all this with loose or implicit dependencies. i encourage everyone to read these insightful posts by Lennart: http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html http://0pointer.de/blog/projects/systemd-for-admins-2.html http://0pointer.de/blog/projects/systemd-for-admins-3.html http://0pointer.de/blog/projects/systemd-for-admins-4.html the first is an overview, the last 4 directed at system admins. if your still not convinced after reading those.... you either can't read or you don't do any serious administration work. C Anthony
