Re: Re (2): NetBSD documentation-hackathon from August 10th to August 14th

[Scrap Happy <Scrap%GMX.com@localhost>]

Hi Jukka,

On 7/23/2011 3:35 AM, Jukka Ruohonen wrote:
> On Sat, Jul 23, 2011 at 02:59:36AM -0700, Scrap Happy wrote:
> > The problem with this approach is that *discarding* the "concept
> > piece" makes folks balk -- "You were SO CLOSE (to being finished),
> > why do you now want to start over FROM SCRATCH (using NetBSD instead
> > of whatever you had on that little gizmo you showed us)?"  It's
> > just another step that you have to document and argue to the client
> > (i.e., why that original approach "wouldn't work"; problems with
> > that particular piece of hardware; licensing issues; etc.)
>
> There are many talented engineers in the NetBSD project. If you are doing
> something specific, I wonder whether hiring a developer to do the
> low-level tasks would be any less cost-inefficient. But if you are doing
> consumer electronics, indeed, probably not.

But, to the client, it doesn't matter if he's paying *you* or
someone you've subcontracted the work out to... he's still
paying for *work* to be performed "just for him".  In his mind,
the appeal of "Linux" (or any other OSS) is that he gets
"something for nothing" (regardless of how big a fallacy this
is, in fact!).

We've been able to come up with some "reference platforms" that
have allowed us to throw together dog-and-pony's on "non-portable"
(i.e., non-handheld) NetBSD platforms without having to scrap
everything.  But, they have been geared towards lower-volume
solutions (i.e., hundreds to thousands of units).  This has worked
well as many of these tend to be very high value-added systems
where there isn't as much pressure on the hardware cost (this
isn't as true in some of the higher *volume* solutions we're
exploring).

> > The second issue is access to information.  Many of these devices
> > are poorly documented and have short production lifespans.  By the
> > time you pick a platform, sort out *how* to develop on it and
> > actually finish the development, the platform may no longer be
> > available commercially (or, may no longer be cost-effective).  So,
> > you either need to shorten the development timeline or *plan* on
> > repeating some part of it to port your "solution" to the successor
> > platform.
>
> If you are doing a SoC (with with say 1000K units), you have the necessary
> documentation (and/or help) or you are doing it wrong. Alas, if you are
> doing one unit as a hobbyist, the situation may be entirely different.

Actually, with much of the Pac Rim suppliers, the "necessary
documentation" simply doesn't exist!  Systems are now designed
with some intended use in mind so you end up dealing with
suppliers who *think* they know what you want a device (hardware)
to do and how they think you will use it.  If you are doing
anything out of the ordinary, "all bets are off".  (vendors don't
*have* to cater to your needs because they are selling these
devices in HUGE quantities to people who are using them "the way
they intended").

E.g., a client wanted a device that would remotely give him access
to a video feed with little or no infrastructure requirements.
I.e., literally set something down (perhaps in the middle of a
forest) and walk away.

Almost any consumer cell phone can provide this sort of capability
(if a secure mechanism can be put in place to access/enable it
from the "calling" end of the connection).  Phones are inexpensive.
Perfect solution, right?

Try getting a phone supplier to give you information on what temperature
range their devices will *reliably* operate.  And, how battery life
is affected by those temperature extremes.  *Simple* questions -- and
things you would readily know if designing from scratch!  Do you
"characterize" particular units?  What if the manufacturer makes a
design change -- that is transparent to the *typical* user of that
phone but deleterious to *your* usage?

Similarly, we were looking at a PoE PD controller, recently, for a
wired application.  We asked the silicon vendor if there was any
way that we could cause the controller to renegotiate its connection
with the PSE (e.g., so we could dynamically vary the PD's class).

"Why would you want to do that?  That's not how we EXPECT you to use it"

"Um, why do you *care*?  Can your product do this or not?"

"Sorry, no.  You'd have to add some external circuitry that ..."

(if you're doing everything the way the vendor *expects* you to do
things, then, chances are, you aren't adding much value to your
design but are just coming up with yet another cookie-cutter solution.
I.e., "Here's THE app note telling you how to use this device.
*Copy* it into your schematic...")

> > Being able to short-circuit the "hardware discovery phase" :>  goes
> > a long way to shortening that timeline.  Having *real* users
> > (developers, in this case) who are identifying and solving the
> > issues that you will ultimately stumble across in *your* port helps
> > immeasurably.
>
> No disagreements. Note though that a SoC is not bulk-x86.

The x86 comparison is worth noting -- in that much of the PC's
(by far the most notable x86) success was attributed to it's
openness.  The fact that lots of people knew (or could easily
find out!) what was under the hood -- instead of the Privileged
Few.

The greater the number of "supported devices", published "hacks",
etc., the easier it is for would-be OS porters to adopt a particular
OS (on a particular platform).  That's where "Linux" is winning
the contest (without commenting on how *good* those efforts are
or how "worthy" the OS may be of the application!)

--don