Interesting article on boot ordering

[Nicolas Mailhot]

Le mar 23/09/2003 à 23:23, Enrico Scholz a écrit :
> notting at redhat.com (Bill Nottingham) writes:

> > No, it's still an issue of providing the user with three separate init
> > systems, and expecting them to make sense of them. ... For something
> > like an init system, I'd think the required featureset is small enough
> > that you should be able to only need one system.
> 
> Ok; you have the choice between:
> 
> minit ... fast and reliable
> sysv  ... widely used for years
> lsb   ... you can put a "LSB compliant" sticker on your machine
> 
> 
> >> There is LSB support in rhl-initscripts which can be dropped? ;)
> >
> > Yes, been there since 7.3...
> 
> Mmmh, must be well hidden. E.g. the LSB return codes, 'lsb_start_daemon'
> instead of 'daemon', or the dependencies. ;)

It's not hidden, it's so basic no one in it's right mind would use it.
Plus it's in a package with all the stoopid lsb deps so you can't even
directly depend on the actual specified lsb scripts master file without
pulling in irrelevant stuff like Mesa (just separating the lsb functions
from the rest of the mess would make lsb a real option since RH
implementation is good enough for lots of simple stuff).

Which is a pity btw - while the current RH implementation sucks big time
the LSB part on init scripts is rather sane. In particular it specifies
dependencies between services which is a requirement if you want to do
non-sequential boot like the link proposes to do.

Being LSBish would be a real option provided :
- the init scripts part is separated from the rest of the spec
- someone plugs the big hole wrt starting daemons as non-root
- logs messages are formated sanely (when one compares RH functions
behaviour to the ones in LSB with the same intent one can only wonder if
the LSB->RH mapping was intentionally botched)

The nice thing about this solution is one could drop the same service
definitions in a sequential or parallel boot setup and they would work
in both (ie app packagers would not have to worry about the actual init
backend used)

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20030923/b4ea5a24/attachment.sig>