Re: promoting NetBSD for embedded & appliance projects

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

Hi Greg,

On 7/23/2011 10:01 PM, Greg A. Woods wrote:
> At Sat, 23 Jul 2011 05:02:31 -0700, Scrap Happy<Scrap%GMX.com@localhost>  wrote:
> Subject: Re: Re (2): NetBSD documentation-hackathon from August 10th to  August 
> 14th
> > 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!).
>
> I suppose that's a fair approximation of the initial naive reaction some
> business folks might have when faced with such a situation, but I think

Realistically?  How are they to know any better?  Most managers
are pretty out of touch (even those with technical backgrounds)
with what's "under the hood" of their products.  I suspect most
couldn't even come up with a semi-formal definition of an OS's
"responsibilities" (i.e., "value")

> that it can be put into a bigger context such that the appeal of
> something like Linux isn't quite so compelling.

Remember, if you're just saying "Linux is no better than *BSD", you
haven't made any *progress*.  The next question is, "Then why aren't
we using <commercial_RTOS>?"

> The big obvious non-technical difference between NetBSD and Linux is of
> course the licensing.  This seems to keep coming up in these kinds of
> discussions, but it seems to be a really hard thing to quantify.

It, actually, is one of the best things working *against* Linux.
Many are fearful of its implications and assume it means they have
to "give away the store" if the go the Linux route.

> Perhaps recent cases of companies suing each other (AVM vs. Cybits for
> example) and a now relatively long history of companies being sued by
> gpl-violations.org, etc. will help make it easier to make people more
> aware of these costs.
>
> The other mostly non-technical issue, more a similarity than a
> difference between GNU/Linux and NetBSD, is that no matter which
> platform one chooses there will be design and implementation trade-offs
> which might equalise the costs somewhat.  With NetBSD it might mean
> having to do more low-level porting, but with Linux it might mean having
> to rewrite something else or deal with unnecessary complexity and
> overhead (look at how much effort goes into avoiding use of glibc in
> some GNU/Linux-based embedded projects) or continually deal with a
> fire-hose of changes in kernel upgrades.

Yes, but a developer (let alone a *manager*) is hard pressed to
anticipate and *quantify* those issues/"risks" (and the manager is
obsessed with managing risk!)

> Another big non-technical issue is the difference between NetBSD and
> GNU/Linux with respect to dealing with the "vendor" so to speak.  It may
> be easier for a company to work with NetBSD due to the way The NetBSD
> Foundation is structured and due to the way the NetBSD source and
> development process is managed with core developers and appointed
> committers.  I've heard that working with the mainstream GNU/Linux
> community is a little more hit-and-miss, especially if one is trying to
> push back changes to several different parts of the GNU/Linux system.
> In NetBSD there are of course similar issues with the 3rd-party software
> which NetBSD includes in its distribution, but these are far fewer than
> with the average GNU/Linux distribution.

In the cases with which I have some casual knowledge, the "vendor"
is only visible to the *developer* (consultant, employee, etc.).
The manager never sees a purchase order for "time" so he is
insulated from the ease/difficulty of interacting with that
"vendor".

The fact that the manager *can't* call "someone's boss" to complain
about the (lack of) service his company has been getting makes him
uneasy.  But, that's pretty much true of any OSS approach.  So, it
cuts equally wrt Linux or NetBSD, etc.

The saving grace is having a developer capable of working with
the software chosen.

> > 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!)
>
> It's hard to think of ways to show how Linux in particular can be a bad
> technical choice in a given application despite having given claims to
> the contrary without really calling the Linux supporters to the carpet
> and showing people how shoddy their "solutions" often are.  It's a very
> negative way to go about things.
>
> These problems can go well beyond hardware support not living up to
> expectations, on to deep rooted and more widespread technical problems
> with choosing Linux for a project which requires further kernel work
> (especially for an embedded/appliance projects).  More than once I've
> heard at least some resentment and dissenting comments from kernel
> programmers and managers who've worked on projects which used Linux,
> even from people who in other cases would and have supported the use of
> Linux.

+42

I've kept in touch with a few groups who have gone the Linux route.
Often, they purchase some bit of I/O from a third party (e.g.,
special DAS, controller, etc.) and were *handed* a CD with that
supplier's "license obligations" (e.g., driver sources) and that
was the extent of the "support".

Since the kernel is (presumably) *big*, there inevitably are
things that aren't completely understood or quantified by the
supplier.  When these things pop up in the developer's product
(because the device isn't being used in *exactly* the same
environment and/or manner that the supplier intended), the
supplier scratches his head, points to the CD and says (effectively)
"That's all we've got!  It works, *here*..."

> On the flip side I think it's also worth keeping in mind that with the
> hoards of Linux hackers poking away at the myriad of different platforms
> out there (and increasingly the hardware vendors themselves providing
> Linux support directly), at least there is a reference port from which
> enough hardware information can be gleaned to do a proper implementation

<grin>  Of course!  This is one of the first things I check when looking
for possible hardware candidates.  I.e., if the Linux folk have NOT
started playing with it, it is possible that too much of it is
"closed" and would represent a serious hurdle for us.  Especially if
the device in question seems pretty mainstream...

> in NetBSD.  :-) (assuming the GPL is fully upheld too of course and that
> such implementations are published and/or fed back in a timely manner
> into the mainstream Linux sources)
>
> One of the things that really makes me sad in the context of GNU/Linux
> vs. NetBSD (or any *BSD for that matter) is that much of the support by
> hardware vendors (especially in the sever segment, but increasingly in
> the embedded sector as well) seems to me to come not from some fair and
> open evaluation that favoured Linux, but rather from the direct sales
> and marketing efforts of large GNU/Linux support companies, such as and
> especially Red Hat.  FreeBSD gets more support from hardware vendors in
> part due to the direct and indirect marketing efforts of the few
> companies which provide FreeBSD support, but NetBSD is now more or less
> limping along only on the indirect support given to The NetBSD
> Foundation and that's apparently not enough to promote it to the likes
> of IBM, HP, Intel, or Dell, etc.  Seeing native NetBSD support in-tree
> for the likes of S390 and the current POWER systems would be awesome,
> but selling IBM on the idea of supporting such a port seems nearly
> impossible, especially now with their apparent firm commitment to
> GNU/Linux.  I.e. the "sad" part is that NetBSD didn't have such a
> champion at a time when it could have counted and now it seems too late.
> So many hardware companies see the open-source vs. proprietary OS debate
> as simply and only as GNU/Linux vs. proprietary, never anything broader.

Yup.  <frown>  I think this is a consequence of the "quantity"
of Linux seats, evangelism, etc.

I can't do anything about *that*.  But, I *can* "casually" show
NetBSD based systems to other developers/clients so they can see
what *can* be done for "no money" (cough).

I'm just getting ready to deploy a set of sizable (distributed)
systems with exactly that goal in mind.  *Not* presented as
selling points for NetBSD but, rather, letting that detail come
up more casually, after the fact.

--don