[no subject]

> Forgive my skepticism, but even if you "roll your own" and avoid tight
> coupling to the OS by reducing your use of system calls, isolating an
> application from an OS is *very* tricky business.  I'd liken it making
> sure
> the plumbing and electricity in the third floor of a house were working
> correctly even if someone remodeled and rewired and re-plumbed the entire
> first floor.  The OS is the level you have to get through to get access to
> the HW unless something's changed quite profoundly since I studied the 7
> layer OSI model of computing many, many core dumps ago.  Physical, Data
> Link, Network, Transport, Session, Presentation & Application (I got 6 out
> of 7 correct from 20+ year old synapses!)
>

The whole point of the OSI model is that a layer CAN change without
affecting the overall stack, because there are well defined interfaces
between them. People write code that runs on completely different operating
sysetms by using the same basic concept, i.e. of encapsulating the specifics
of the OS so that their own code runs in terms of their own interfaces.

>
> Correct me, please, if I am wrong, Dean, but I was under the impression
> that
> someone (most likely you) has to personally write a driver for each and
> every piece of HW that CQ supports?  Isn't that task as limitless as the
> amount of HA and HT devices that a user might be expected to control?
> Doesn't it also involve making sure HW upgrades in devices that you
> control
> are reviewed to make sure they still react correctly to commands?  I
> stopped
> buying Sony auxiliary control equipment because they could not standardize
> across model lines.  It was in a constant state of chaos. According to
> this
> site:
>

No, I don't know have to write those drivers. There are currently probably
about as many third party drivers as those we have written. We want to write
the ones for the things that are most important to us from a business
standpoint. But if some user has a less commonly used driver, they are free
to get some third party to write it for them.

> I'm glad you report you're untroubled by such things.  I can't help noting
> that reading through your support forum about the problems supporting
> I-Tunes and I-Pods "gives me pause" as the Bard might say.  How do you
> successfully put a wrapper around something that requires login,
> authentication and DRM control?  How do you talk to a device where the
> maker
> has not revealed the internal protocols?  Those seem like gnarly problems
> to
> me!
>

There are no 'problems' supporting them. We just haven't done it yet. You
put a wrapper around a device that requires login and authentication by
having the driver login. This is already something that is commony done with
security systems that are automated. The driver just logs in itself.

And these issues have zero to do with device drivers or OS problems or
anything else. Obviously someone could create a device that's practically
impossible to interface to. If so, then it just won't get sold to people who
want to automate their systems.

> When CD-recorders hit the market there were waves and waves of
> incompatibility problems, from the low-level firmware in drive controllers
> to the recorders themselves to the recording software to the very blank
> disks themselves.  For self-education, I just typed "Charmed Quark
> Problem"
> without the word driver into Google and the very first message I came
> across
> appears to be driver related.  Simon from Surbiton, England had a
> Zoomplayer
> opening problem:
>

I was just asking if he'd correctly installed the drivers, which he might
not have because he was trying to control multiple instances of Zoom Player,
which has some special considerations. So, no, this does not in any way
support any of your conclusions really.

>
> Speaking of drivers, in searching through the CQ support forums, I found
> what seemed to be an inability to deal with a customer's pre-existing MP3
> library.  Did I read that correctly?  Is CQ, with its heavy emphasis on
> home
> theater, unable to import tagged MP3's correctly into its media
> repository?
> From what I could divine, you decided to support WMA rather than the MP3
> format.  Couldn't one say, if that's the case, that CQ didn't have any
> driver problems with MP3 files because it didn't have any drivers for
> them?
> (-:
>

We are not trying to compete with J.River. We are more interested in
competing with Escient and Kaleidescape. So we've not really made any effort
to improt existing tagged content. We work in terms of actual discs at this
time. It has nothing to do with drivers, it has to do with business
decisions as to what we are trying to accomplish.

> So I guess I still don't quite understand how a client/server product like
> yours can truly insulate itself from the OS that's managing all the
> client/server traffic.  More troubling, I can't see how a product that
> maintains a media repository isn't going to fall into the impending snake
> pit of digital rights management issues.  Surely that has to be one of the
> issues facing you when considering support for I-Tunes and I-Pods.
>

Any system whose DRM doesn't allow for external control will not end up in
automated systems. If it applies to us, it'll apply to any competitor as
well, generally speaking, so it will be just a general issue. But the folks
who sell the content want to sell it. So DRM systems will accomodate
automation systems over time. The AACS system used in the HD world has the
ability to provide for systems like ours, actually better than DVDs do and
legally, though they've not finallized how it's going to work yet.

> You didn't have any issues with CQ or your machines when XP SP2 arrived or
> porting up from an earlier version?  What version of Windows was CQ "born"
> under?  As for your experience, that's a commendable data point, but
> that's
> all.  Reading through support groups for HomeSeer, ADI and others would
> reveal other, incongruent, data points.
>

No. I didn't. CQC started on W2K. It required no changes for XP other than a
small change to ignore some graphics system errors that are caused when the
system is locked. It now runs on Vista without any problems that we can see.
It took me about 15 minutes to get it running on Vista, as I pointed out in
another post. So your predictions of doom and gloom were a few hundred miles
off base.  I explained clearly why it probably wasn't going to be an issue,
which is our abstraction from the system. I guess you have to be a software
engineer to really appreciate what I'm saying, but take my word for it, it
does work.

>> I was refering to the bulk of people implementing an automation system,
>> not of the public at large, since I thought that was the issue at hand.
>
> I think one of the problems we're having here is that we're talking about
> different things, or at least I *think* we are.  I had (mistakenly)
> assumed
> that CQ was an automation program that an average user could deal with.
> Upon closer inspection, it seems to be clearly aimed at people who have
> fairly broad PC, programming, networking and configuration skills.   I
> would
> say that it's probably a good fit for less than 10% of the people who stop
> by CHA to ask automation questions.  That's not a knock, BTW, it's simply
> an
> acknowledgement that you're catering to a different crowd than, say,
> Activehome.
>

It clearly is a system targeted at automation professionals. That is true.
But we have plenty of non-technical DIY customers who have created their own
setups. They do have some spinup, much of it nothing to do with CQC.

>> > A few days?  I think you're quite the optimist, Dean.  We'll have to
>> > wait  and see.  I've worked on a number of software projects for
>> > various clients.  When you have to support another OS, particularly a
>> >  new one, it can double your testing load, it can increase the size and
>> > complexity of your distribution media, it can require multiple sets of
>> > help files tailored to each OS.  Housekeeping and version control can
>> > just eat you alive if you run into significant issues porting.
>

As mentioned above, it took about 15 minutes. I spent 4 or 5 hours setting
up a new machine and getting Vista installed (two times since I made a
mistake first time and wanted to start over and change the drive
configuration.) Then it took about 15 minutes to figure out the new rights
management system and get the installer to run. Once the installer ran,
everything else is working as is.

The difference is software engineering relative to some other companies.

> I do remember being surprised that a program that strove for such a high
> level of abstraction from the OS did not support other platforms, like
> Linux
> and the Mac. Or did I get that wrong?  If you don't support Apple or
> Linux,
> does Apple's switch to an Intel CPU have any impact your future plans?
>

There is not business argument for doing so. It would require a lot of extra
effort (much of it nothing to do with software), that wouldn't bring in any
substantially new amount of revenues.

> A lot of *very* smart AV people I know are heavily invested in Macs.  The
> I-Pods and I-Tunes have incredible market share, AV-wise.  I'd be
> interested
> to know how you incorporate such devices into CQ without having to deal
> with
> some very knotty digital rights management (DRM), driver and networking
> issues.
>

We would deal with the DRM issues, which are easilly dealt with with iTunes
(witness the many systems that incorporate iPods, so clearly it's not a
problem.) There are things like the iPort that provide a well defined
interface to interact with the iPod. And systems like the Russound, which we
have a driver for, also incorporate iPod interfacing.

> I'll readily admit being able to insulate yourself from serious changes in
> the underlying OS is nice, even if it's only from slight version changes
> in Windows.  The problem I have is that my experience tells me that no
> matter how a programmer tries to insulate himself from the OS, the success
> of his efforts lies in how many OS upgrades he's survived, what the OS
> manufacturer has changed and the plain ol' luck of the draw.  How many OS
> revisions has
> it been for CQ?
>

If you count the underlying object frameworks, it's been through OS/2, to
NT, to XP/W2K, now to Vista.

>> The underlying object platform used to run on XP and Linux
>> simultaneously back in the day, and because of the very mechanisms I've
>> pointed out it required no changes in the code, just the use of the
>> virtual kernel layer being implemented on each platform.
>
> "No changes in the code" could be misconstrued.  Who writes the virtual
> kernel for the new OS?  (-:  By using another layer of abstraction, you're
> simply moving the difficult interoperability issues to a different
> software
> layer, but the issues still remain.
>

No changes to the code means that nothing outside of the virtual kernel
layer changes. Yes, a new layer (actually half a layer) needs to be written
for the other OS. But that's less than a percent of the code base in size.

> It almost sounds as if you've built an OS for CQ within the Windows
> framework.  While that might not be a workable solution for other fields,
> perhaps because of HA's relatively relaxed CPU requirements, the
> performance
> hit it would seem you would take re-creating system utilities and services
> embedded in the OS might be worth the gain in reliability.  If, as you
> say,
> you have problems if another device chooses an IP address already in use,
> perhaps you're not as insulated from the OS as you'd like to be.
>

It doesn't 'recreate them' for the most part, it just encapsulates them. The
layer is actually not very large at all, and in the context of a modern PC
the overhead is minimal. The IP port issue has nothing to do with OS
encapsulation. It's just a side effect of the world wide adoption of TCP/IP
as the networking standard. It is not very well designed in this particular
area.

> The reason I brought up the "key man" issue was not to cause FUD.  It was
> a
> reaction to a previous comment that you made.  You're in a slot that's
> infamous for burning people out.  When I read this paragraph you wrote:
[snip....]
> Why would I do this?  Because a single person, grinding himself up slowly
> but surely with no other life but the love of his project, is creating
> something no one else can take over, no matter what the inducements.  Your
> devotion to CQ is quite admirable, but it's likely to be very hard to find
> in another person.  In my business, managers are rated on the success or
> failure of their projects. When I was in grad school, huge SW projects
> were
> failing left and right. Most management education at the time was geared
> towards recognizing what caused such large, apparently well-thought out
> and
> well-funded projects to fail.  Burnout was an important factor, but
> ironically enough, so was lack of motivation.  I wouldn't worry about
> that,
> though, motivation is something you independents have in large quantity!

Unfortunately, the real world doesn't work that way. You have to put in the
time if you want to make it. I'm not going to burn out, because I don't even
consider it a job. It's my life. I'm well designed for this type of life
actually. I've been doing it for over a decade now, and I'm not burned out,
and don't think I will.

What will burn me out is when we do actually bring on those other people and
the company starts growing. At that point, the company won't depend on my
anymore, but I'll find it much more stressfull than what I'm doing now,
which is actually a pretty pure endeavor in which I have no one to argue
with or be disappointed by but myself.

> Please, Dean, you don't really want to go on the record saying CQ has no
> driver issues.  It's so easy to disprove it's hardly worth Googling again.
> The first message I found and quoted above was a driver problem.  There's
> a
> thread going on right now about Z-wave's slow response in CQ because of a
> .
> . . (you guessed it!) . . . a *driver* issue, isn't there?
>

You read these things without understanding them at all, so I find it hard
to even respond to them. You keep changing the argument to fit your needs of
the moment. You talk about Windows drivers, which I said we don't have much
problems with. Now you are talking about our drivers, and you don't
understand what you are reading because you don't understand the context. I
complain a lot about Z-Wave, because Zen-Sys changes a lot for their SDK and
we don't own it, so we are restricted in our understanding of the Z-Wave
system and have struggled to get it happy, particularly early on.

This has absolutely nothing to do with anything you've been saying. It's
just a lack of information which has made it difficult to get a paritcular
device interface as good as it should be.


> I think my comments are far from "incomphensible" - I think they're very
> comprehensible; it's just that they're not very comfortable.  To say that
> neither Windows nor CQ has driver issues strains credulity.  That's why I
> pursued such comments so vigorously.
>

Let's take a vote... Does anyone here think that Peter's arguments are
comprehensible?

--------------------
Dean Roddey
Chairman/CTO, Charmed Quark Systems, Ltd
www.charmedquark.com