On Thu, Nov 29, 2012 at 10:32:46PM +0100, Bernhard R. Link wrote: > > > Claiming that it will work for everyone and that > > > anyone not being able to name a problem existing now has no arguments > > > does not help. > > Do System V Init or Upstart work in EVERY single use case? > Actually, all my experiences with upstart has been when it does not > work. And then it was always a pain to work with. So in my experience > System V Init is quite superior to Upstart. > And the big advantage of System V Init is that everyone can diagnose > and fix it. Everyone knows how to add some echo lines to find out where > something is happening. Having the logic available in some easy > well-known and very extensible syntax means I could easily adopt it > and make it fit my needs even more I understood what most of this stuff > it. And with all the nice properties descriptive systems have and as > much as I love them, nothing beats discoveribility, debugablity and > extendiblity of imperative programming. As true as that may be, the happy declarative syntax is not the only advantage of upstart (or systemd) over sysvinit. Sysvinit's very static, linear notion of runlevels is not well adapted to the modern reality of an event-driven kernel. Ask the maintainers of packages like lvm2, cryptsetup, open-iscsi, or multipath-tools how much fun this is. It may be easy with init scripts to know where the problem is, but that's cold comfort when the architecture prevents you from sanely fixing that problem. Boot speed is actually a proxy metric for this. Nothing slows down the boot of a system quite so well as a 'sleep' call in the middle of your init script. (squeeze)vorlon@becquer:~$ cat /etc/rcS.d/* | grep -c 'sleep[[:space:]]\+[0-9]\+' 11 (squeeze)vorlon@becquer:~$ Why are those sleeps there? Because the use of init scripts ensures that we're always racing the kernel, instead of being able to respond directly to events when they happen. Nearly every one of those sleeps represents *two* bugs: the bug the maintainer noticed that caused them to add the sleep as a workaround, and the remaining bug of the race condition that the maintainer hasn't yet tripped over and needed to fix. So given this fundamental limitation of the design of sysvinit, do you have any suggestions for how upstart could be improved to be less of a pain to work with? I'm sure at least some of this inevitably comes down to what people are familiar with; but if there are things that you think are fundamentally less debuggable about upstart that we should fix (and I already have a few of these on my own list), I'd be interested to hear about them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature