[Nut-upsdev] Asking hard questions about the NUT architecture

[Eric S. Raymond]

oss-list-ups at technorama.net <oss-list-ups at technorama.net>:
> Did you forget about RAID?

Sort of.  You make good points about RAID creating some risks that 
aren't present in a non-RAID system.  On the other hand, RAID is
hardly a typical use case.

> Is this the 80's?  Do you have enough RAM for 3 processes?  NUT follows 
> the Unix philosophy:
>     Write programs that do one thing and do it well.
>     Write programs to work together.
>     Write programs to handle text streams, because that is a universal interface.

I wrote the modern reference on the Unix philosophy, with active help
from Ken Thompson and Doug McIlroy and half a dozen other Bell Labs
ancients: <http://www.catb.org/esr/writings/taoup/>.  I am therefore
about the *least* subject to being pushed around by these sorts of
quotes of anyone you will ever meet short of Ken Thompson himself.
Don't bother trying, because I'll just laugh.

> Many of the drivers can't be tested by the core NUT developers since 
> they don't have the hardware.  If a single program crashes how do you 
> know if it's the driver portion, monitoring portion, etc, etc.

If you wrote your daemon properly, the event logs will tell you that.  I'm not
speaking theoretically; fetchmail and gpsd actually do this.  NUT has got
a fair start on it.

> > One possible reply is that filesystem hardening sometimes fails.  But
> > that objection implies the right solution, which is to fix the
> > filesystem hardening rather than messing around with compensatory
> > kludges in userspace.
> 
> Perhaps you should spend your time hardening the hardware so that NUT 
> and UPS's in general are obsolete.

That would be better, of course.  But software is much easier for people
like us to fix than hardware designs are.

> Maybe you use google (try "ext3 corruption") instead of making 
> assumptions.

Yes, it happens.  Often enough to invalidate my point?  I don't think so.
All systems are subject to failure; reliability engineering is about
evaluating the marginal cost of better odds against it.

My argument amounts to asserting that for most users, the value of
the marginal gain in reliability from UPS-controlled shutdown is exceeded
by the complexity cost of configuring it under NUT.  

You can't refute that simply by noticing the fact (which I don't
dispute) that ext3 fails once in a blue moon or so.

> A $30 UPS tends to fail more often than the power does.
> 
> Show me where I can find a 2000VA UPS for $30 to replace the one 
> that I have.

I'll do that right after you explain to me why USB-UPS users are
paying complexity costs for your legacy hardware.

> Having the hardware drivers abstracted away from the monitoring is good 
> design.  Not everything is USB and USB may be replaced in the future 
> just like serial ports have partially been replaced today.

You're refuting an argument I never made.  I don't want to weld the
drivers to the monitor, I want a simpler zero-configuration monitor.
 
> > 1. A drivers kit (ups-drivers).
> 
> Maybe you should suggest that to the linux kernel developers first.

Why?  The NUT drivers don't need to run in kernel space
 
> Why should the drivers be separate?  NUT is useless without drivers.

Since the NUT project lead has endorsed this idea, I'll let him
explain it to you.

> It looks like you only want to make it a PITA to work with anything you 
> consider "old".

That's backwards.  I want to reduce the PITA factor of current hardware.  

> Bad ideas.  All of them.  Except for auto configuration of USB devices.

I repeat: Since the NUT project lead has endorsed these ideas, I'll let him
explain them to you.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>