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

[Rob Crittenden]

Eric S. Raymond wrote:
> Christopher X. Candreva <chris at westnet.com>:
>> We have the applications to think about too. It's all well and good to say 
>> they should be able to recover gracefully, but to those of us supporting 
>> things we didn't write, having the system shut down cleanly just might save 
>> me hours of work later.
> 
> I don't understand this objection, sorry.  What could NUT's UPS-controlled
> shutdown possibly be doing for you that a shutdown on SIGPWR wouldn't?

If NUT isn't going to shut down the system gracefully what is the point 
of having a driver for the hardware? It will still provide power in a 
black out, provide clean power in a brown out and the system, according 
to you, will cheerfully come up when the battery finally dies (this is 
of course assuming that the user has plugged things in correctly).

So what does NUT bring to the table other than a few data points? Does 
Grandma care about the input voltage? The only interesting data point 
would be runtime, but then again, the system will be fine when power 
cuts out abruptly, right? So there is no need to save your work or 
anything, you can just walk away and let it beep. Or if you can tolerate 
the beeps, work right up to the point where the last key press is 
registered.

I've always felt that NUT was by default configured for the hard case 
instead of the simple case (1 computer, 1 UPS) but I really don't see 
what dumping upsd and upsmon buys you.

What would this replacement daemon do beyond logging something that 
wouldn't matter because the system is off or soon-to-be-off anyway? You 
can always just run the driver directly and achieve what you want, 
right? I mean, if the target audience is a single home-user won't they 
already know the "state" of things merely by looking around? Do they 
need a file to tell them that the UPS is on line or on battery?

rob