rc and smf

[George Georgalis]

djbware is quite the catalyst for ongoing disagreements, no doubt about
that but I think the contention comes from FUD, not the software which
has never bitten me once I understood its operation.

It is very different, and people that don't understand it are often
frustrated with the documentation, which is very accurate and complete,
if lacking in howto type documents. I am still frustrated with some of
the commands that don't have man pages, but I've always been able to
find the documentation.

If however you try to discover for yourself the commands, through
experimentation, for example how to stop a service under supervise:
cd /service/softwareX && rm /service/softwareX && svc -dx . ./log
that can be frustrating. Not to say experimentation is bad, but the
actual operation is easy and clearly documented.

There are widely used packages on the other end of the spectrum for which
the documentation is so cushy that I've never tried the software. Detailed
HOWTOs are fine for package introduction but if I'm going to deploy it,
I want a concise, nuts and bolts description of what it is going to do.

I have my own patch set for various djb packages which is a blend of 3rd
party and my own. As a green novice c programmer, I can say the code is
clean and clear, and my nominal modifications are easy to retain. If,
however, one tries to break the djb methodology, I imagine that could
get messy, quick.

Per Matt's smf comment, my first thought was that's just what
daemontools has done for years, presumably better invoked under
runit vs init.

For those considering (and those with prejudice), I'd like to remind
that, the people who use above softwares are happy, if quiet. Also,
there is excellent support on their respective lists too, especially if
you don't put down the software while there, do the homework and remain
receptive to the criticize you solicit.

I'm looking forward to working out my own runit/supervise standard for
running on dfly and submitting patches/dfports to do so, if they aren't
already available.

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george at xxxxxxxxx