djb utilities

Michael A. Peters mpeters at
Sun May 4 03:44:32 PDT 2003


On Fri, 2003-05-02 at 07:25, Larry Lawrence wrote:
> and send LBS a
> packing (sorry, this does not make me cry, adopting 'rpm' was a big
> mistake).

Um, yeah - rather than create standards that actually help compatibility
(like standardizing which kernel headers glibc is built against - and
how glibc can be modified) they dictate a package management system.

Makes no sense. I like rpm, but I'd rather have binary compatibility
between distro's and their glibc's than something stupid like a standard
for package manager so that I can install binaries from one distro onto
another where they won't work right because their glibc isn't *quite*
the same ;)


> So the question is this.  Are we doing DJB Utilities a disservice by
> relocating all the files just like every other distrobution AND would
> installing these utilities as the author intended harm any of our current
> packages?
> Larry

I looked at Daemontools once.
It looked like an interesting concept - but wasn't well documented and I
didn't see the point, really. As far as the "symlink mess" that he
complains about w/ SysV init - solutions such as chkconfig to manage
those have existed for a LONG time (as in before Linux afaik) so there
really isn't much point imho in having daemontools as part of blfs.

But if you have it - standards compliance is a good thing.

Things like this from his web page:
"In contrast, with init.d and rc.local, daemons are not monitored. Your
daemon will fail to start if, for example, a previously started daemon
has temporarily chewed up almost all available memory. The system
administrator has to manually restart your daemon after he notices the

That's a half truth at best. Every system where service availability is
an issue has software that monitors the daemons, and many daemons fork
themselves once started to prevent loss of service etc.

So since he's not really completely honest with his propoganda, then
force his stuff to be as standards compliant as possible.

I love this from his page:


Portability. With /service, your program works the same way on every
system: Linux, BSD, Solaris, etc.

In contrast, inittab and ttys and init.d and rc.local vary from system
to system. Some systems don't have init.d, for example, and the ones
that do have it don't agree on its location. This is extremely annoying
for cross-platform system administrators.

um, no - with /service, your program works the same on any system
[emphasis]with your fricken software installed[/emphasis] - which can be
said for ANY boot scheme.

Sorry to rant - he just doesn't seem to be honest. I don't think his
stuff should be included at all.

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