djb utilities

Michael A. Peters mpeters at
Thu May 8 03:53:40 PDT 2003

On Wed, 2003-05-07 at 04:49, Stefan Krah wrote:

> I was just trying to make a point: It had been suggested _not_ to use
> daemontools or even kick it out of BLFS because "we already have sysvinit".
> Daemontools has the same right to exist as sysvinit. There are in fact
> people who run svscan as process 1.
> Now, if I really wanted to kick out sysvinit I'd suggest it on lfs-dev.

My point is that multiple ways of starting a daemon adds complexity to
an operating system - not simplifying it.

Since the author of daemontools himself claims that his product should
be used to simplify, then a solution that adds complexity is not what he
wants either. Using both sysVinit and daemontools adds complexity. It is
far better to have one method by which daemons are started and stopped
on the system.

Knowing that /etc/init.d/qmail stop

will stop the daemon because daemons are started and stopped in
/etc/init.d is a hell of a lot easier than having to look at whether a
daemon is implemented using init.d or daemontools.

We should use one or the other.

I also really don't like the remarks of the author - I don't find the
author of SysV init or BSD init scripts making half truth and complete
untruth remarks about each other or daemontools - yet the daemontools
author feels a need to do that. And he feels a need to make slanderous
accusations about the unix industry - such as they plan to make their
systems different for their own greedy purposes.

That kind of untrue spin combined with the half truths - it really makes
me not trust the integrity of his products. Really.

But anyway - for something such as which gui library (motif, qt, gtk+,
etc.) having multiple is not really an issue. For something boot scripts
- it's a cleaner system that doesn't mix and match. And a cleaner system
is what the author of daemontools indicates he prefers.
Michael A. Peters <mpeters at>

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list