The future of the boot system in Debian

Nico Schottelius nico-cinit at schottelius.org
Mon Sep 7 07:10:36 UTC 2009


Good morning initscripts-ng-devel, Petter,

Petter Reinholdtsen [Sun, Sep 06, 2009 at 11:51:02PM +0200]:
> > Petter Reinholdtsen [Sat, Sep 05, 2009 at 01:21:00PM +0200]:
> > > The future of the boot system in Debian
> > > =======================================
> > 
> > may I recommened cinit[0] instead?
> > 
> > I'm very open to critics and improvements on it, if needed.
> > 
> > It is planned to release cinit-0.3 within this year.
> > 
> > Greetings from Zurich,
> > 
> > Nico
> > 
> > [0]: http://unix.schottelius.org/cinit/
> >      http://www.nico.schottelius.org/software/cinit/
> 
> Sure.  I pass your email on to the mailing list where we discuss the
> boot system in debian, initscripts-ng-devel at .
> 
> Looking at the package, I am unable which part of the problem we are
> trying to address you believe it will solve.  Can you explain more?

Sure. Compared to sysvinit cinit has real dependencies (one of its
greatest strength) and supports profiles (for different environments).

cinit _can_ use the old sysvinit scripts, though this is heavily
deprecated, because you loss a lot of performance.

Thus said, cinit is enormous fast: All dependencies are solved
and a console login displayed in < 2 seconds after cinit has been
started (on a p3/600mhz/pata).

The aim with cinit is also to provide a portable init, not bound to
Linux. This could probably close one of the gaps between bsd<->sysv
in the future.

On the other hand, there are some disadvantages currently:

a) cinit is not know: the principle of soft and hard dependencies is pretty unknown
b) cinit-0.3 is not yet stable (should be until the end of the year)
c) cinit does not listen to kernel events, but provides an API to interact with events

a & b have to be fixed soon anyway.

Regarding c: I'm not yet convinced that an event driven init is the best
way to go. I think seperating the bootup phase ("startup reliable and fast")
from the normal running phase ("events are triggered") is important:

An event system (like udev/hal) has to be very smart and provide good
interfaces to other systems (like UIs, logging, etc.).

An init system on the other hand should imho be as dumb as possible
(providing a fast and reliable startup) and provide simple APIs to change
the status of a service.

It is very much the "one tool for one job" philosophy.

Now I'm very much interested in your opinions.

Sincerly,

Nico

-- 
Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20090907/6400a1f9/attachment.pgp>


More information about the initscripts-ng-devel mailing list