Re: rc and smf

[Tim <tim@xxxxxxxxxxxxxxxxxxxx>]

> djbware challenges conformity, that's one of the reasons why DJB is so
> hated. He's a guru with meticulous attention to security and reliability
> details in both code and design, and that offends many people.
 
OK this thread was amusing but I think it's getting a bit ridiculous.

First of all, I am a huge DJB fan (I run nearly all his software on
my systems).  I am also a huge fan of Matt that's why I read this list.
That said, you are not doing DJB any favors with your arguments and
I bet he would agree more with Matt than you in nearly all cases
(and I am aware of the qmail/softupdates issue too).

By your definition, MessageWall is broken.  Stop trying to figure
out what can be done to patch its brokenness.  What if MessageWall
received an mail, acknowledges to the sender, but before sending
to the recipient some hardware failure happens?  Power failure?
If some cosmic gamma ray flips a bit in your RAM, can you system
automatically detect and correct that (better make sure you have ECC)?
If your CPU overheats, and assuming you have a monitoring program for
it, what do you do with your messages in queue?  Do you restart the
system or shut the system down.  These scenarios are far more likely
to happen before the mythical overcommit randomly killed process case
in a *properly* setup system.  Neither Linux nor FreeBSD will take
care of these issues for you.  A good sysadmin anticipates these
issues and pick the right tools for it.  If you want reliability,
pick {qmail|sendmail|postfix|your favorite disk-based queue MTA}
and run any number of available filtering solutions based on them.

The more I think about it, the worse I think MessageWall is, if we
need absolutely reliable message delivery (most of us do).  Let's say
it holds a message in RAM-based queue and the remote connection is
out (network connection or whatever}.  You are only INCREASING the
chance of that message getting lost by holding it in RAM and taking
chances with the system going down until the remote can accept it.
When you have a such huge failure case, it's pointless to hash on
and on about the much smaller overcommit issue.

> runit is meant as  replacement for both init, and/or daemontools. runit
> is a daemontools-like design with more features. Service
> dependencies, service waitdown, and reliable logger shutdown.
> 
> smarden.org/runit/

Again, I am a huge fan of DJB tools but so what?  There's nothing in
DragonflyBSD or *BSD to keep you from using these tools.  Some people
has even replaced init with supervise.  Some people have different
philosophy on how to handle this and the *BSD folks would rather keep
what they have (not to mention DJB licensing is more restrictive than
BSD).

Lastly, DJB runs FreeBSD and before that, OpenBSD on all his servers
(see http://cr.yp.to/serverinfo.html).  So your trying to use him as
an example in argument FOR Linux fails miserably, IMHO.

Sorry to contribute further to this thread.

Tim