[GRLUG] Jenison Electrician
Bob Kline
bob.kline at gmail.com
Wed Jan 27 12:46:44 EST 2010
On Wed, Jan 27, 2010 at 12:32 PM, Michael Mol <mikemol at gmail.com> wrote:
> On 1/27/2010 12:06 PM, Bob Kline wrote:
> >
> >
> > On Wed, Jan 27, 2010 at 11:50 AM, Michael Mol <mikemol at gmail.com
> > <mailto:mikemol at gmail.com>> wrote:
> >
> > On 1/27/2010 11:34 AM, Bob Kline wrote:
> > >
> > >
> > > On Wed, Jan 27, 2010 at 10:59 AM, <mikemol at gmail.com
> > <mailto:mikemol at gmail.com>
> > > <mailto:mikemol at gmail.com <mailto:mikemol at gmail.com>>> wrote:
> > >
> > > On Wed, Jan 27, 2010 at 10:45 AM, Bob Kline
> > <bob.kline at gmail.com <mailto:bob.kline at gmail.com>
> > > <mailto:bob.kline at gmail.com <mailto:bob.kline at gmail.com>>> wrote:
> > >
> > >
> > >
> > > On Wed, Jan 27, 2010 at 10:36 AM, <mikemol at gmail.com
> > <mailto:mikemol at gmail.com>
> > > <mailto:mikemol at gmail.com <mailto:mikemol at gmail.com>>> wrote:
> > >
> > >
> > > On Wed, Jan 27, 2010 at 9:30 AM, Casey DuBois
> > > <casey at grlug.org <mailto:casey at grlug.org> <mailto:casey at grlug.org
> > <mailto:casey at grlug.org>>> wrote:
> > >
> > >
> > > For something like that you need a real
> electrician,
> > > however I'm not
> > > sure how many if any have the thermal imager like
> > we've
> > > seen on TV.
> > >
> > >
> > > Most of my day job involves writing software that
> > talks to
> > > them, but the
> > > hardware we talked to is danged expensive. That said,
> > we've
> > > written software
> > > specifically for folks who do property analysis using
> > > thermal cameras.
> > > (Windows-only, sorry; Driver support issue.) If
> anyone's
> > > interested in
> > > starting such a business in the area...
> > >
> > > -
> > >
> > >
> > > For people who want to sell you
> > > information about how to better
> > > insulate your abode? Maybe
> > > starting with triple pane windows?
> > > Is that a hot (...) business in cash
> > > strapped MI?
> > > -- Bob
> > >
> > >
> > > To a point, yeah, it's about replacing poor windows and adding
> > > insulation. The nice thing a thermal camera can do for you is
> > help
> > > you figure out which windows, doors, walls and areas of the
> > roof you
> > > ought to shore up, and which you shouldn't bother with.
> > >
> > > (Now, if I may deflect the subject into a personal rant)
> > >
> > > What irritates me greatly is that the SDKs for talking to the
> > main
> > > types of cameras we work with is only practically available
> for
> > > Windows. In one case, the manufacturer only provides an OCX
> > file.
> > > In the other case, the manufacturer opted for a 3rd-party API
> > called
> > > GigEVision, but the number of implementations of that API is
> > > exceedingly small, and the group of companies controlling the
> > spec
> > > manage it more tightly than the MPEG group; I'm not sure how
> one
> > > could legally build a FL/OSS implementation. There's one
> > > non-Windows implementation, but you pay through the nose for
> > it, and
> > > say Hello to system library version requirements.
> > >
> > > It's still the case that many - most? -
> > > companies will only talk to M$ about
> > > their hardware. Canon is notorious
> > > that way. All an aid to keeping M$'s
> > > de facto monopoly intact.
> >
> > Erm...Believe me, it's not in the their interest to keep a Microsoft
> "de
> > facto" monopoly intact. Most implementations for talking to
> GigEVision
> > devices are pure-hardware, now, without a trip through userland
> > software. I'd have to look into it again, but I believe most of the
> > companies in the group behind the API are also in the industry of
> > selling pure-hardware solutions.
> >
> > Tell me where that helps Microsoft.
> >
> > That much doesn't. But many companies
> > don't want the expense and bother of
> > supporting several platforms. So they
> > withhold information from anyone but M$,
> > and that helps keep M$'s monopoly in
> > place.
>
> That's not how driver development on Windows works. Microsoft isn't
> responsible for the development of others' drivers. They'll write
> generic drivers to available standards, but they won't write a driver
> for some other company's hardware. (Well, I suppose if that other
> company offered to pay enough, they might.)
>
> Driver development on Windows involves purchasing and downloading the
> DDK, and doing your own coding. When you're ready, you pay Microsoft
> for WHQL certification; That's a quality control process where they
> hammer your driver through a testing process. You don't *have* to get
> WHQL certification; Your driver will still load on most systems without
> the certification, but the user will see a warning saying that
> "such-and-such driver hasn't been WHQL-certified, and may cause your
> system to be unstable." Most users will click through that. Some won't.
>
> It's not Microsoft's choice whether companies develop products that work
> with non-Microsoft operating systems. There's only one major reason for
> it that I've seen...Visual Studio is a darned-good C/C++ IDE, better
> than anything else I've worked with extensively.
>
> The closest thing to a contractual limitation I've seen is that one of
> the optional add-on packs for MFC has licensing clauses in it that are
> supposed to make you think twice about running your app under winelib.
> However, if you're using MFC as part of your drivers, you've got other
> problems, and they have more to do with competency...
>
>
> You're right; Most hardware manufacturers don't want to bother with the
> expense of supporting multiple platforms, but they withhold the details
> needed to implement support from *everybody*, and do their own
> implementation. If Microsoft was no longer the majority target, and,
> say, Ubuntu was, then they'd do that single implementation for Ubuntu,
> and let Microsoft users twist in the wind.
>
> The crux of the issue, though, is that a lot of the magic that makes or
> breaks a quality "hardware" device actually happens in software; it's
> just cheaper to patch and fix software than hardware. Users who buy a
> fast video card or quality-output printer are really paying for a device
> that the fancy, well-written drivers will talk to. Things like color
> conversion and quality halftoning in printing, or shader path and data
> transfer optimizations in video cards, are largely handled in the
> drivers for consumer-grade hardware. Want a printer that does it in
> hardware? That's what Postscript is for. Video cards are still a bit
> tricky.
>
> It's the behind-the-scenes in-software magic that the hardware
> manufacturers don't really want to open up; If they lose that, they lose
> the edge they have over their competitors.
>
>
I'll take that at face value, but it
certainly suggests to me that if
a vendor only supports windows
drivers then it is helping M$ stay
in the driver's seat.
I had the impression that M$ had
it's own in house driver software
people. How and when it writes a
driver I don't know - perhaps as
you suggest, for a fee.
But it brings up another issue.
If a company builds its products
using proprietary chips then it
can control the specs. Big companies
can do this. In general you'd think
the objective is to sell hardware.
So the more platforms that support
it, the better. It's possible that if
someone can figure out how your
hardware works, or what chips are
used, they will clone your gadget I
suppose. Years ago companies
went to the bother to black out the
parts ids so a potential repair person
didn't even know what chips to get.
I can only speculate that the
open versus proprietary wars are
not really over yet. There's a love-hate
relationship with standards. Many
companies would still like to have
proprietary approaches, with the
obvious goal of locking people in
to their products. Think FAX machines
before group 3 standards showed up.
You bought FAX machines in pairs, at
the least, and they cost $thousands.
So do you try to sell more hardware,
and allow OSes like Linux to play, or
do you stick with M$ and keep things
locked up? It strikes me the verdict
is not totally in on this.
-- Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20100127/9833a499/attachment-0001.htm
More information about the grlug
mailing list