[arch-general] When will Arch switch to Upstart

[C Anthony Risinger]

On Wed, Jan 19, 2011 at 10:54 AM, Culley Smith <culley.smith at gmail.com> 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