Re: Dedicated Z-wave sites?

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Dean Roddey" <droddey@xxxxxxxxxxxxxxxx> wrote in message news:5D8gh.8172

<stuff snipped>

> > enviroment is also getting more and more complicated with so many
versions
> > of Windows to support.  IIRC, each one of those failed companies died
> > shortly after a major new OS was introduced.  A specialized program like
> > yours takes all the incompatibility hits, deserved or not, and you end
up
> > troubleshooting a lot of problems that aren't yours.
> >
>
> In this we are actually in a very good position. We use very few system
> services. We have now over 700,000 lines of proprietary code and we do as
> much as possible ourselves. This is why if you read our forum we have very
> little of the stuff you see on many fora, where people complain that they
> installed something and the product stopped working. Of the couple of high
> level features we use, a media player wrapper is one, and we had a little
> growing pains with that initial implementation. But mostly we just aren't
> too troubled with this kind of thing. We'll certainly have to do a little
> tweaking for Vista, due to their changed security implementation, but it
> shouldn't be a huge deal. The product currently runs on XP, XP Home, W2K
> Server, and W3K Server unchanged.

I dunno.  I'm watching a vidcast of a briefing called "Improving the
Reliability of Commodity Operating Systems" and it talks about how much of
Windows resides outside of MS's control in device drivers.  If the lecturer
is to be believed, 85% of Windows crashes are device driver related.  He's
discussing an OS helper called NOOKS

http://nooks.cs.washington.edu/nooks-sosp.pdf

that seeks to protect the kernel of Linux from errant drivers usings a
variety of techniques like isolation, object monitoring and shadow drivers
(that try to restart failed drivers and replay inputs to recover what was
lost by the driver crash).  He notes that the problem drivers that escape
into the real world often suffer from transient faults that are difficult to
find.  If merely restarting the driver overcomes the problem that often
means the driver crashes are occuring when interrupts come at precisely the
wrong time.

> We have a couple of 'virtual kernel' modules and all system services are
> encapsulated inside them (a core one, a windowing one, and a couple for
some
> specialized bits like ODBC.) Everything else is completely built on top of
> that virtual kernel, and not even any system or language runtime headers
are
> visible outside of them. This provides us with a lot of flexibility to
deal
> with changes in the OS.

But you still have to deal with device drivers, don't you?  That's where the
failures are located.   IIRC, in the Linux study, the most failures were
caused by sound card drivers at 40+, then network drivers, then IDE drivers,
with only eight reported.  That's what I would expect.  Your driver wouldn't
last long if it corrupted data, but if a certain slider on a volume control
was twitchy, a driver might still survive without being fixed.

Maybe you're doing a lot of what NOOKS does already in Charmed Quark.  It's
a lot of coding work to provide the sort of encapsulation and error recovery
that NOOKS does.  It also costs CPU cycles - sometimes twice the normal
load.

--
Bobby G.