Nut upsdev - May 2007 - Asking hard questions about the NUT architecture

I've spent the better part of two working days reading the NUT code and 
documentation and thinking about typical modern use cases for the software.  
I'm now questioning whether I want to get any further involved with this 
project, because it seems to me that the codebase is a huge and complicated
pile of machinery mainly aimed at solving problems that no longer matter.

I could be wrong about this, and I'm posting to nut-dev rather than simply
folding up my tent and stealing off into the night because I count on the
people here to demonstrate my error if I am wrong.  But the more I look at 
the architecture, the more I feel like I've dropped through a time-warp
back to 1997, or even 1987.

TROUBLING QUESTIONS:

Let's start with a simple question that strikes at the root of my
discontent:

1. In an era when file systems are normally journaled and hardened so they 
recover clean from power failures, what point is there in having your UPS
initiate a controlled shutdown N seconds beforehand?

I sure don't see enough of one to justify a multi-layer architecture
involving three concurrent processes, four configuration files, and a
partridge in a pear tree.  NUT, as it is now, seems to me to be a
textbook case of massive overengineering and overkill based on
outdated assumptions.

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.  At modern disk-write speeds there is plenty
of time for journaling OS buffers between SIGPWR and when the heads 
no longer get juice.

Now I'll anticipate another possible reply: even if modern OS/filesystem
layers have made UPS-controlled shutdowns rather pointless, there's
still some case for NUT as a tool for logging the state history of
your powerlines and the UPS itself. Under this assumption, upsmon and
its config files would go away but there would still be a role for
upsd and the drivers.

The rest of this note will be founded on this assumption, because
without it NUT would be *entirely* pointless.

Which brings me to my next question: 

2. Why should we care about contact-closure UPSes any more?  

NUT carries around a huge load of tools and documentation designed
for a class of UPSes that can't be health-monitored.  All they can
do is initiate shutdown before the actual power drop, which as I've 
argued above is nowadays unnecessary.

It follows that NUT could drop all support for contact-closure and
"dumb" UPSes tomorrow and it wouldn't make a damn bit of
difference
to anybody, at least nobody in the Linux world.  Ext3 is everywhere
now, and the odds that Linux distros will drop back to a non-hardened
filesystem in the future are nil.

And that brings me to my third question:

3.  Why should we care about 'smart' serial UPSes any more?

I've already shown that supporting dumb UPSes is silly under modern
conditions.  Supporting anything RS232, in particular smart serial
UPSes, seems almost as pointless in 2007.  USB UPSes are ubiquitous
and cheap; when I recently went shopping for a UPS I found a
USB-capable unit for $29.99.  Belkin no longer manufactures any
RS232-only units at all and APC hasn't shipped a new RS232-only design
since at least 2004.

And there are good reasons to drop RS232 if it's only a legacy feature.
Supporting RS232 greatly complicates the NUT codebase, documentation,
and installation procedure, because those ports are hard to configure
and don't announce themselves at device-connection time.

Concentrating on USB devices would implications that are user-visible.
In particular, it should mean the entire manual-configuration
apparatus of NUT (everything in /etc/nut) could be made to go away.

WHAT SHOULD BE DONE:

I was originally going to recommend the following steps:

1. Drop continuing support for everything but smart USB UPSes.

2. Flush upsd/upsmon and replace them with a simple, single-process
   monitor driven by hotplug requests and with zero configuration.
   (I have this mentally labeled 'nutless'.)

Then Arnaud Quette explained to me about the HAL abstraction work.
That seems to be heading in the right direction, which is zero
configuration and simply making the status messages from the
UPS available in a well-known place.

So I'm now thinking that. for distribution-packaging purposes anyway, NUT
should break up into three pieces:

1. A drivers kit (ups-drivers).

2. A HAL interface for the drivers (ups-hal, depending on ups-drivers).

3. For non-HAL environments, the aforementioned zero-configuration monitor
   driven by hotplug requests (nutless, depending on ups-driver).

A good first step would be to at least package the drivers separately 
from upsd and above, and to warn all NUT users that the upper layer
will be going away in the future.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The people of the various provinces are strictly forbidden to have in their
possession any swords, short swords, bows, spears, firearms, or other types
of arms. The possession of unnecessary implements makes difficult the
collection of taxes and dues and tends to foment uprisings.
        -- Toyotomi Hideyoshi, dictator of Japan, August 1588

On Tue, 29 May 2007, Eric S. Raymond wrote:
> 1. In an era when file systems are normally journaled and hardened so they 
> recover clean from power failures, what point is there in having your UPS
> initiate a controlled shutdown N seconds beforehand?
Suspenders and a belt.

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.
> 3.  Why should we care about 'smart' serial UPSes any more?
I have a perfectly good serial-only Best 1.8kva from 1996 that gives me 3 
hours of runtime, with monitoring. I should throw it out just because it 
doesn't have USB ?


=========================================================Chris Candreva  --
chris at westnet.com -- (914) 948-3162
WestNet Internet Services of Westchester
http://www.westnet.com/

Sent this to just Eric by mistake.

On Tue, 2007-05-29 at 10:43, Eric S. Raymond wrote:
> 3.  Why should we care about 'smart' serial UPSes any more?
I for one care. I have smart serial based UPSes around the world and I
use NUT to monitor them and do a graceful shutdown if power does fail.
USB is not the only way to go and I think it would be a bad direction
for this project to go to remove all the serial comms.

There are more than just the casual, home-based user to consider in
this. Corporate users must be considered too. The USB differs for almost
every UPS on the market, and many of the makers of these UPSes, will not
publish the protocols. They want you to use their software, even if
their software doesn't work in your environment or operating system.

As for the contact closure UPS, I think that it needs to remain, as a
final fallback position. If you can't get your UPS to communicate in any
other way, you can probably get it to work as a contact closure UPS at
the very least.

-- 
Ronald Reed - RHCE, GCUX, GCIH
Manager of Computer Operations
ARM SGP ACRF Site
(580)388-4053 Ext. 114
rreed at ops.sgp.arm.gov

On 5/29/07, Eric S. Raymond <esr at thyrsus.com>
wrote:
> I've spent the better part of two working days reading the NUT code and
> documentation and thinking about typical modern use cases for the software.
> I'm now questioning whether I want to get any further involved with
this
> project, because it seems to me that the codebase is a huge and complicated
> pile of machinery mainly aimed at solving problems that no longer matter.
[snip]

You are making a number of wrong assumptions:

1. Filesystem journalling is 100% reliable.  -- It isn't. Journalling
tries to keep your data safe as best as it can, but when the hardware
dies there are a million things that can go wrong. I for one, want my
data to be safe, and if there's something I can do to make it safer, I
do it. If the power fails and the box can be notified of this, why not
do a controlled shutdown? Do you unplug your box from the wall just
because you can? Or do you shut it down properly?

2. Filesystem consistency is all that matters. -- Applications are the
real problem here. You want your applications to terminate properly to
avoid losing data.

3. Applications respond to SIGPWR. -- AFAIK, few of them do. And how
do you send SIGPWR to machines not directly connected to the UPS?

4. RS232 and contact-closure don't matter. -- USB hardware may be all
over the market, but every vendor seems to do things different enough
to turn supporting them in NUT a case-by-case thing. RS232 is well
supported and makes for a good fallback. As for contact-closure, they
exist, and that's reason enough to support them. I for one wouldn't
want to dump a perfectly working 2Kva UPS in the dumpster just because
it isn't "cool" anymore.

5. Complex UPS/server scenarios don't exist. -- NUT is mostly useful
in servers, which is where the data worth protecting is. It is not
uncommon to have one, or several, UPSes powering multiple machines.
Sure, if your datacenter has a diesel generator, then you don't need
NUT at all, but small businesses don't have diesel generators... but
they have servers powered by UPSes.

I agree that NUT is a bit complicated for single user, single UPS
scenarios. But that should be fixed while keeping the current level of
functionality, which requires the present (or similar) design.

-- 
Carlos Rodrigues

Hey,

2007/5/29, Eric S. Raymond <esr at thyrsus.com>:
> I've spent the better part of two working days reading the NUT code and
> documentation and thinking about typical modern use cases for the software.
> I'm now questioning whether I want to get any further involved with
this
> project, because it seems to me that the codebase is a huge and complicated
> pile of machinery mainly aimed at solving problems that no longer matter.
>
> I could be wrong about this, and I'm posting to nut-dev rather than
simply
> folding up my tent and stealing off into the night because I count on the
> people here to demonstrate my error if I am wrong.  But the more I look at
> the architecture, the more I feel like I've dropped through a time-warp
> back to 1997, or even 1987.
>
> TROUBLING QUESTIONS:
>
> Let's start with a simple question that strikes at the root of my
discontent:
>
> 1. In an era when file systems are normally journaled and hardened so they
> recover clean from power failures, what point is there in having your UPS
> initiate a controlled shutdown N seconds beforehand?
>
> I sure don't see enough of one to justify a multi-layer architecture
> involving three concurrent processes, four configuration files, and a
> partridge in a pear tree.  NUT, as it is now, seems to me to be a
> textbook case of massive overengineering and overkill based on
> outdated assumptions.
>
> 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.  At modern disk-write speeds there is plenty
> of time for journaling OS buffers between SIGPWR and when the heads
> no longer get juice.
>
> Now I'll anticipate another possible reply: even if modern
OS/filesystem
> layers have made UPS-controlled shutdowns rather pointless, there's
> still some case for NUT as a tool for logging the state history of
> your powerlines and the UPS itself. Under this assumption, upsmon and
> its config files would go away but there would still be a role for
> upsd and the drivers.
>
> The rest of this note will be founded on this assumption, because
> without it NUT would be *entirely* pointless.
>
> Which brings me to my next question:
>
> 2. Why should we care about contact-closure UPSes any more?
>
> NUT carries around a huge load of tools and documentation designed
> for a class of UPSes that can't be health-monitored.  All they can
> do is initiate shutdown before the actual power drop, which as I've
> argued above is nowadays unnecessary.
>
> It follows that NUT could drop all support for contact-closure and
> "dumb" UPSes tomorrow and it wouldn't make a damn bit of
difference
> to anybody, at least nobody in the Linux world.  Ext3 is everywhere
> now, and the odds that Linux distros will drop back to a non-hardened
> filesystem in the future are nil.
>
> And that brings me to my third question:
>
> 3.  Why should we care about 'smart' serial UPSes any more?
>
> I've already shown that supporting dumb UPSes is silly under modern
> conditions.  Supporting anything RS232, in particular smart serial
> UPSes, seems almost as pointless in 2007.  USB UPSes are ubiquitous
> and cheap; when I recently went shopping for a UPS I found a
> USB-capable unit for $29.99.  Belkin no longer manufactures any
> RS232-only units at all and APC hasn't shipped a new RS232-only design
> since at least 2004.
>
> And there are good reasons to drop RS232 if it's only a legacy feature.
> Supporting RS232 greatly complicates the NUT codebase, documentation,
> and installation procedure, because those ports are hard to configure
> and don't announce themselves at device-connection time.
Carlos has perfectly answer. you tend to be too "esr centric" ;-)
I mean, MGE (and others) still sells RS232 UPSs (and is the 2nd ww
mfr, now merging with APC !), many people still uses dumb/smart serial
units. Why should we leave them in the dark?!

focusing on the future doesn't mean erasing the past. We (the NUT
team) are focused on our _users_ and _all_ their needs, whatever
complex / exotic / legacy it is.
You should be in a good position to know that one force of linux /
FLOSS is its ability to support both the legacy _and_ the newest
hardware, in a uniform way.

BTW, get a look on our (soon incomplete) features list:
http://eu1.networkupstools.org/features/

follow up on the future below ...
> Concentrating on USB devices would implications that are user-visible.
> In particular, it should mean the entire manual-configuration
> apparatus of NUT (everything in /etc/nut) could be made to go away.
>
> WHAT SHOULD BE DONE:
>
> I was originally going to recommend the following steps:
>
> 1. Drop continuing support for everything but smart USB UPSes.
>
> 2. Flush upsd/upsmon and replace them with a simple, single-process
>    monitor driven by hotplug requests and with zero configuration.
>    (I have this mentally labeled 'nutless'.)
>
> Then Arnaud Quette explained to me about the HAL abstraction work.
> That seems to be heading in the right direction, which is zero
> configuration and simply making the status messages from the
> UPS available in a well-known place.
>
> So I'm now thinking that. for distribution-packaging purposes anyway,
NUT
> should break up into three pieces:
>
> 1. A drivers kit (ups-drivers).
>
> 2. A HAL interface for the drivers (ups-hal, depending on ups-drivers).
>
> 3. For non-HAL environments, the aforementioned zero-configuration monitor
>    driven by hotplug requests (nutless, depending on ups-driver).
several points you've missed since you came too recently here and not
have digged enough:

1) HAL

Considering that HAL is becoming the de facto standard on our beloved
and main focus systems (linux, *bsd, solaris, maybe others later on),
good efforts have been put there.

A basic implementation (read "something that is as good as on windows
/ OS X") will be shipped with the upcoming 2.2 "Sophie Mina"
release.

More features are coming, like DBus methods (to poweroff the UPS,
change its HW settings, ...), along with HAL support for legacy
devices (serial ; discussed with Dave Zeuthen on HAL and NUT), network
support through avahi, ...

And I've already proposed you (feisty) packages that ships only HAL
support (read the four NUT USB driver compiled with HAL bridging, so
not requiering ups{d,mon})
You can otherwise build your own (ln -s packaging/debian debian &&
debuild ... ; I'm sure you're now fluent with this ;-)

I feel like you really have fallen into a time warp, and not have seen
the major updates in NUT since 2 years ;-)

Using MacFly <http://software.inl.fr/trac/trac.cgi/wiki/Macfly> would
btw be a good QA test for NUT!

2) Legacy support

This both includes non HAL enabled systems, and serial (smart / dumb) UPSs

Parts have already been exposed above (user focused, HAL legacy
support) and below (packaging).

NUT's configuration complexity (along with NUT's architecture) allows
to address _any_ kind of setup!

Since we have addressed the mass market with hal support, we can focus
on the remainder : that is to say legacy system and complex / exotic
... systems.

The point on which we're ok is that the configuration is really a mess.
I've add an intern last year to work on creating a lib and a tool to
configure nut easilly and allow the creation of NUT Config GUIs. Note
that the tool can be called by hotplug / udev on non HAL systems.

http://opensource.mgeups.com/projects/nut-config.htm
http://svn.debian.org/wsvn/nut/branches/JD-NewConf/?rev=0&sc=0

This branch still has to be reworked, completed and merged.
> A good first step would be to at least package the drivers separately
> from upsd and above, and to warn all NUT users that the upper layer
> will be going away in the future.
the plan is now to lobby for including the nut-hal-drivers (providing
hal-ups-support and conflicting with nut) in the base system, without
depending on it. This way, the system will allow out of the box
support for USB devices, while allowing users to install the "classic"
nut

I'm currently building a packagers task force, composed by members of
CentOS, Debian, RedHat, SuSE, *BSD, ... to prepare / apply several
changes to the existing packages, including the above.

welcome to our wonderful UPS world Eric ;-)
as you can see, we don't lack ideas, innovations, nor user focus, but
we really miss time, and manpower for coding, documenting, and
marketing (lobbying, website, ...)

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/

On Tue, May 29, 2007 at 11:43:49AM -0400, Eric S. Raymond
wrote:
> TROUBLING QUESTIONS:
> 
> Let's start with a simple question that strikes at the root of my
discontent:
> 
> 1. In an era when file systems are normally journaled and hardened so they 
> recover clean from power failures, what point is there in having your UPS
> initiate a controlled shutdown N seconds beforehand?
Did you forget about RAID?

The task of a RAID is to maintain an invariant between the data and the 
redundant information it stores. These invariants provide the ability to 
recover data in the case of a disk failure. For RAID-1, this means that 
each mirrored block contains the same data. For parity schemes, such as 
RAID-5, this means that the parity block for each stripe stores the 
exclusive-or of its associated data blocks.

However, because the blocks reside on more than one disk, updates cannot 
be applied atomically. Hence, maintaining these invariants in the face 
of failure is challenging. If a crash occurs during a write to an array, 
its blocks may be left in an inconsistent state. Perhaps only one mirror 
was successfully written to disk, or a data block may have been written 
without its parity update.


Some ATA/SATA drives lie about disk writes (meaning the journal may not 
be updated).

RAM is often the first thing to experience problems during a low power 
condition.  Random data may end up on the disk during a power failure.

Databases need to shutdown properly or they may end up corrupt.

Any application that modifies more than 1 file can end up in an 
inconsistent state after a power failure.


Journaling file systems can't help any of the above.

> 
> I sure don't see enough of one to justify a multi-layer architecture
> involving three concurrent processes, four configuration files, and a
> partridge in a pear tree.  NUT, as it is now, seems to me to be a
> textbook case of massive overengineering and overkill based on
> outdated assumptions.
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.


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.

> 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.

> At modern disk-write speeds there is plenty
> of time for journaling OS buffers between SIGPWR and when the heads 
> no longer get juice.
See "RAM" above.

> Now I'll anticipate another possible reply: even if modern
OS/filesystem
> layers have made UPS-controlled shutdowns rather pointless, there's
> still some case for NUT as a tool for logging the state history of
> your powerlines and the UPS itself. 
> Under this assumption, upsmon and its config files would go away but 
> there would still be a role for upsd and the drivers.
Maybe you use google (try "ext3 corruption") instead of making 
assumptions.

There are many ways that a filesystem can be corrupted after power 
failure.  The purpose of a UPS and NUT is to guard against them.

> The rest of this note will be founded on this assumption, because
> without it NUT would be *entirely* pointless.
...
> Which brings me to my next question: 
> 
> 2. Why should we care about contact-closure UPSes any more?  
> 
> NUT carries around a huge load of tools and documentation designed
> for a class of UPSes that can't be health-monitored.  All they can
> do is initiate shutdown before the actual power drop, which as I've 
> argued above is nowadays unnecessary.
See above.

> It follows that NUT could drop all support for contact-closure and
> "dumb" UPSes tomorrow and it wouldn't make a damn bit of
difference
> to anybody, at least nobody in the Linux world.  Ext3 is everywhere
> now, and the odds that Linux distros will drop back to a non-hardened
> filesystem in the future are nil.
NUT is Linux only?  Maybe that should be mentioned on the web page.

> 3.  Why should we care about 'smart' serial UPSes any more?
> 
> I've already shown that supporting dumb UPSes is silly under modern
> conditions.  Supporting anything RS232, in particular smart serial
> UPSes, seems almost as pointless in 2007. USB UPSes are ubiquitous
> and cheap; when I recently went shopping for a UPS I found a
> USB-capable unit for $29.99.  Belkin no longer manufactures any
> RS232-only units at all and APC hasn't shipped a new RS232-only design
> since at least 2004.
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.
> And there are good reasons to drop RS232 if it's only a legacy feature.
> Supporting RS232 greatly complicates the NUT codebase, documentation,
> and installation procedure, because those ports are hard to configure
> and don't announce themselves at device-connection time.
If you don't have a RS232 UPS then you don't need to configure a driver 
for it.

Removing drivers may be your personal preference but it has nothing to 
do with NUT configuration, maintenance or development.

> Concentrating on USB devices would implications that are user-visible.
> In particular, it should mean the entire manual-configuration
> apparatus of NUT (everything in /etc/nut) could be made to go away.
Then how do we make network UPS's work?  How are those automatically 
configured?

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.

> 1. A drivers kit (ups-drivers).
Maybe you should suggest that to the linux kernel developers first.

Why should the drivers be separate?  NUT is useless without drivers.

Do you mean RS232 drivers should be separate?  Why?  Do they take up too 
much disk space?  Is build time a problem?  Are we back in 1980?

Extra drivers sitting on the disk can only help people who need them.

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

> 2. A HAL interface for the drivers (ups-hal, depending on ups-drivers).
> 
> 3. For non-HAL environments, the aforementioned zero-configuration monitor
>    driven by hotplug requests (nutless, depending on ups-driver).
> 
> A good first step would be to at least package the drivers separately 
> from upsd and above, and to warn all NUT users that the upper layer
> will be going away in the future.
Bad ideas.  All of them.  Except for auto configuration of USB devices.

On 5/29/07, Eric S. Raymond <esr at thyrsus.com>
wrote:
>
> 1. In an era when file systems are normally journaled and hardened so they
> recover clean from power failures, what point is there in having your UPS
> initiate a controlled shutdown N seconds beforehand?
Somebody else has already raised the clean application shutdown, so I
won't repeat that.

However, back in the human world, why shouldn't the admin know that
the power has gone out and the system is now on battery support?
Getting the page to say that it's all going wrong *before* the lights
go out can be rather useful :)
> 2. Why should we care about contact-closure UPSes any more?
<---SNIP--->
> It follows that NUT could drop all support for contact-closure and
> "dumb" UPSes tomorrow and it wouldn't make a damn bit of
difference
> to anybody, at least nobody in the Linux world.  Ext3 is everywhere
> now, and the odds that Linux distros will drop back to a non-hardened
> filesystem in the future are nil.
But there's more than just Linux out there (and, while ext3 is better
than ext2, I've still personally experienced edge cases where those
multi TB file systems require a full fsck, which is time consuming and
painful).
> 3.  Why should we care about 'smart' serial UPSes any more?
>
> I've already shown that supporting dumb UPSes is silly under modern
> conditions.  Supporting anything RS232, in particular smart serial
> UPSes, seems almost as pointless in 2007.  USB UPSes are ubiquitous
> and cheap; when I recently went shopping for a UPS I found a
> USB-capable unit for $29.99.  Belkin no longer manufactures any
> RS232-only units at all and APC hasn't shipped a new RS232-only design
> since at least 2004.
But why should I (or where I work) have to buy a new UPS when the old
one works just fine?
> 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?
That'll be that Linux centric view again - FreeBSD doesn't support
SIGPWR (and, if I'm honest, it's USB support is still relatively
immature comparted to Linux), but it works just fine as a NUT master.

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Eric S. Raymond wrote:
> Rob Crittenden <rcrit at greyoak.com>:
>> So what does NUT bring to the table other than a few data points?
> 
> Not much.  But be careful what you argue for -- you might end up
> demonstrating thst the *entire* edifice of NUT is pointless.
Pointless to you.

rob

Just two short remarks on this.
> 1. In an era when file systems are normally journaled and hardened  
> so they
> recover clean from power failures, what point is there in having  
> your UPS
> initiate a controlled shutdown N seconds beforehand?
We're running a software RAID on eight 150G discs.
Not cleanly shutting down that server makes me lose the RAID parity.
Rebuilding the RAID parity takes 22 hours.
I have no redundancy during the parity rebuild.
> 3.  Why should we care about 'smart' serial UPSes any more?
Because there are people out there with those? Should we trash  
working older hardware?
> when I recently went shopping for a UPS I found a USB-capable unit  
> for $29.99.
We're running four mid-range (3kVA) UPS. They do have USB, but there  
seem to be reliability problems with the USB interface.

* Eric S. Raymond <esr at thyrsus.com> [2007-05-29
17:44]:
> 1. In an era when file systems are normally journaled and hardened so they 
> recover clean from power failures, what point is there in having your UPS
> initiate a controlled shutdown N seconds beforehand?
> 3.  Why should we care about 'smart' serial UPSes any more?
I might come as a surprise to you, but:
1) not all the world is i386, ELF, Linux
2) there's more UPSes than your little home boxes. I should throw away 
my ~ 25KW worth of serial only, relatively new UPSes, right, For the 
record, I have 0 USB ones.

this is hilarous.

you do have a point abourt the config. this is not exactly news tho.

-- 
Henning Brauer, hb at bsws.de, henning at openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam