Slashdot/IBM: How To Speed Up Linux Booting

Sven Mueller debian at
Wed May 2 17:32:00 UTC 2007

Marco d'Itri wrote on 02/05/2007 18:56:
> On May 02, Sven Mueller <debian at> wrote:
>>Though I agree that we should clean up the init system while we enable
>>usage of newer, better, faster init systems, I don't think that we can
>>remove much yet. For a while to come, many system administrators (think
>>servers) will like to stay with the old faithful, long tested sysvinit.
> Do we need to care? Ubuntu switched to upstart and I have not noticed
> anybody complaining.

Hmm, two things vome to mind:
1) Ubuntu is still relatively new (2-3 years), and I know of nobody who
   is using it in a production environment designed for maximum
2) Many people say that Ubuntu isn't the right fit for servers. Mainly
   because a lot of software is without official security support.

I don't know how good upstart actually is, and frankly, I'm still not
completely understanding how the event based init works, but I admit I
didn't try hard to understand it (I fully understand sysvinit and
dependency based inits though).

>>That being said, a lot of cleanup could be done while we move to
>>script-generated (from meta-information, script snippets and templates)
>>init scripts.
> This would introduce a lot of complexity. Complexity is bad, and needs
> to be weigthed about the benefits. What are the benefits of supporting
> many init system schemes?

Many people (including me) think of the ability to choose as one of the
main features of free software (and Debian). So the main benefit for me
is that I could safely switch between init systems to try which fits my
needs best. Really easy to understand how it works: sysvinit. Relatively
easy to understand, faster: dependency based. More complex to understand
completely, but perhaps even more efficient: event based. However, even
within a class of init systems, there are choices and I welcome them,
even if it means that packaging daemon packages becomes a bit more
complex. But as I wrote in my original mail: I don't actually think that
packaging needs to become more complex.

The point in my ideas on init system support is that we gather 99% of
the complexity in a single initsystems-base package which generates the
needed init config/scripts from meta information included with the
daemon packages. And at the same time make this meta information as easy
(or even easier) to handle for package maintainers as the current
sysvinit scripts.

> Is there a middle ground which allows a compromise?

Depends on what you see as the positions:

In my opinion, we should support at least three init systems:
- sysvinit (slow, but known to work well for servers)
- some dependency based init with daemon babysitting (ie. ensuring the
  daemons keeps running). runit? (faster, not as thoroughly tested)
- upstart or a similar event based init (even faster? different approach
  but probably better tested because of the usage in Ubuntu)

If another init system wants to get added to the supported list, it
should be able to provide some generator script which creates its
configuration and support scripts based on the meta information we
already have for the above three init systems. This generator script
should then be included in the initscripts-base package or that init
system's package. I would prefer the latter.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: OpenPGP digital signature
Url :

More information about the initscripts-ng-devel mailing list