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

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

Hi Jean-Yves,

On 7/22/2011 1:31 PM, Jean-Yves Migeon wrote:
> On 22.07.2011 17:56, Scrap Happy wrote:
> > Unfortunately, there is no simple, intuitive parallel to draw to
> > the PC world that just rolls off your tongue.  Instead, you have
> > to try to draw on parallels that migrate into the application
> > domain (e.g., "OK, Bob, everyone in your organization runs Windows,
> > right?  But, do they all use MSWord for their document preparation
> > tool?  Or, do some folks use WordPerfect, FrameMaker, etc.?").
> > Most people are savvy enough to realize that these *are* applications
> > so the analogy fails to take hold in their mind.  There's nothing
> > *big* enough (in that world) to put the issue into proper perspective.
> >
> > Perhaps if there were a wide variety of window managers in use this
> > might have some resonance with "users" as the basis of an analogy.
> > <shrug>
>
> Well, if they do not understand the difference and need questionable
> metaphors to illustrate the situation, I am not sure they are in the
> right position to make technological choices.

<grin>  That has never stopped "them" from being in those positions!

> Generally speaking, using system "foo" over "bar" should be more a
> matter of costs (ease of development, available skills and technologies,
> licensing terms, etc) rather than clueless buzzwording; yeah, that's
> rarely the case.

Unlike a desktop/mainframe (i.e., "software shop") development, when
it comes to embedded products, the folks making the decisions have to
wear many hats:  hardware, software, application domain, packaging,
etc.  So, it is rare to find a manager with much depth in any *one*
of those areas (I've had Mechanical Engineers, by training, managing
projects that were essentially electronic+software in nature; I've had
folks whose sole experience with software was that they had written
some code in *BASIC* managing largely software projects; etc.).  It
seems logical for these folks to at least want to *explore* any
ideas they may have come across that might (in their mind) save them
some development effort.

The same mentality applies to folks who think "using a PC" will
magically short-cut their development process:
    "Um, all that really gives you is a keyboard and a display.
    And, in your product environment, that's not really what your
    user interface will *want* to be!  It gives you nothing in
    terms of the hardware you will need to interface with the
    Field, needs to be ruggedized to work (reliably) in that
    non-desktop environment, etc."
I can't count the number of times I've had that argument...  :<

> > Understood.  But the PHB's making these sorts of decisions see
> > lots of opportunities and *implementations* of Linux-based devices
> > (again, my experience is with embedded systems so that's the
> > argument I am always forced to face).  It's only natural for them
> > to think, "Why can't *we* go that route, also?".  (it's just like
> > trying to explain why you typically *don't* want to base a product
> > on a PC platform; it just *looks* "so easy"... :<  )
>
> I have rarely seen PHB concerned about using Linux or something else;
> I'd even say that most of the embedded stuff sold with "runs Linux" is
> quite secondary, most users do not care whether their webcam, phone, or
> home router uses Linux. It's more something that appeals to hobbyists.

I've never heard it expressed as a "marketing point" but, rather, as
a shortcut to development.  I.e., "we get the OS for zero investment".

> > If *I* then have to sort out how easy/hard (i.e., expensive!) it
> > will be to port NetBSD to some *modern* piece of hardware, I'm
> > faced with doing much of it from scratch.  OTOH, they (client)
> > look and see how their competitors have taken some COTS piece of
> > hardware, added some I/O's, slapped "Linux" on it and now have a
> > (supposedly) working product on the market.
> >
> > E.g., I'm presently researching low-cost tablets for a product.
> > I can almost *bet* that some Linux hacker/group will have a
> > big start on porting Linux (the kernel is all I really care
> > about since the application layer rarely resembles a desktop
> > machine) to many of the tablets I am interested in.  How many
> > will have a significant NetBSD effort already under way (or,
> > *completed*)?  :<
>
> Well, first, don't neglect the application layer, unless you believe
> that having a Linux + busybox running is enough to be attractive to
> customers.
>
> Rest is a matter of evaluating your position, especially what you
> already have, and what you don't. If some Linux hacker/group has a big
> start on porting Linux, you are not necessarily at an advantage against
> competition, as you are counting on others to do the porting for you.

There are several issues involved.

The first is just expediency.  If I can pick up some "suitable"
hardware platform and quickly throw a "proof of concept" application
framework on it, then the job of selling a particular approach to
a client (e.g., "let's use a portable/wireless solution.  It could
work like this...") is much easier.  People like "touchy-feelies".

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

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.

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.

> If you're a manufacturer not interested in selling chips/SOCs but
> complete products, chances are you want to be the first-mover. So if

This depends entirely on the application, market and "value added"
in your product.  If, for example, your competitors have desktop
(meaning, fixed position, large, bulky) implementations and you
have a *portable* (handheld) approach, you have a distinct marketing
advantage.  If the transition from fixed to handheld is non-trivial
(e.g., battery life, user interface design issues, packaging, etc.)
then the bar is pretty high for your competitors to follow you
(belatedly).

> your OS development starts off by building up your OS stack, you are
> losing time in administrativia instead of going straight to developing a
> port.
>
> If you want to keep (or pick up) some code private for whatever reason
> (confidentiality, IP problems, licensing, NDA, etc) or that you don't
> want to keep asking about legality of "what happens when I link my
> foobar code especially if I use XYZ headers?", good for you, I consider
> this a PITA. Especially when this involves redeveloping stuff that is
> otherwise available but not usable due to legal concerns (yuck).
> Releasing patches in a corner on open-source.foo.com does not
> necessarily help either, unless you want to gather statistics on bit
> rotting.

The resistance I often see (to Linux/GPL) is the disclosure of
proprietary methods that follows from the license terms.  Often,
there may be a lot of value in how data is acquired and conditioned
(i.e., algorithms that allow you to use less capable hardware
to achieve results previously only available *with* more capable
hardware).  If the company has to disclose these to comply with
some portion of the license, it devalues their IP.

[there are ways around this but they end up forcing you into
"less natural" designs than you would otherwise wish to follow.
E.g., moving things to user land, obscuring linkages (to make
probes of the software more difficult), etc.]

> There's no real "one size fits all" answer.
>
> > [Again, I'm not a zealot/evangelist.  I have to consider how
> > efficiently I can get from point A to point B in a product
> > development cycle.  The "mascot/logo" matters very little to
> > me or my clients.]
>
> As said: if efficiency is a matter of relying on work done by others,
> yes, pick up what has already been done. And assume the risk that you
> might not dispose of it at your convenience (it's a joke to believe that
> having access to the source ought to be enough). Just take a look at the
> Honeycomb saga, although "it's Linux" many were left behind.

I'm well aware of that.  This is why I have undertaken the development
of my own platforms for development -- the wireless tablet simply being
the "next in line".

> > While I can document what I do (did) to get a NetBSD kernel
> > running on some particular piece of hardware, I'd rarely have
> > the time to *generalize* that for others to build upon.  So,
> > unless someone was interested in exactly the same piece of kit
> > (hint:  there are far more choices for embedded platforms than
> > there are COTS "systems" -- I had half a dozen SB2000's that I
> > couldn't *give* away! -- that may have been supported), those
> > notes are of little value.
> >
> > [It also seems that there are more hardware hackers in the
> > Linux camp than NetBSD]
> >
> > I said it in an earlier post; NetBSD doesn't have a "positioning"
> > so there is nothing to explicitly draw people to it.  Linux, then,
> > "wins" based solely on "seats" (not merit, etc).
>
> Do you have any number to share regarding "seats" for network equipments?

No idea.  But, I have *never* heard anything other than "Linux"
raised by a client as a deployment possibility (neglecting other
"specialized" OS's).  I consider this a "missed opportunity"
for its competitors (at least in those application domains where
a UNIX-y OS might be appropriate).

--don