[ On Thursday, October 25, 2001 at 14:29:17 (-0700), Andrew Gillham wrote: ]
> Subject: Embedded NetBSD? [was Re: CVS commit: basesrc]
>
> Don't get hung up on the cross-development issue.  Think more about the
> idea of "targeting an embedded environment" where the only NetBSD in the
> place might very well be the embedded system.

but that's the very point -- if the goal is to build embedded systems
that happen to be running *BSD kernels and userland (or subsets thereof)
then most certianly is is best to use Unix(like) development systems!

Indeed if I were to ever encounter any shop operating in the fashion
you've described I'd very seriously question the sanity and
effectiveness of their management, not to mention their experience and
backgrounds, and their higher agendas too.

Just as Unix is good at hosting its own development, so too is it very
good at hosting the development of similar kinds of systems software,
including that targeted for embedded systems (no matter what they are
based on).

> Personally I think changing names from "cmd" to "command" is much better
> anyway, since we can support the longer names why not use them?

I'm not particularly concerned about the details in this case -- it's
more a matter of the principle.  Next thing we'll have some pointless
surge through the tree lowercasing all the file names!  I don't want to
have to see restrictions placed on how NetBSD's source tree lives just
to cater to other broken, brain-damaged, and limited so-called
development platforms!  If they want to use the *BSD source tree then
they can damn well use it on at least some kind of Unix host!  Now don't
get me wrong here though -- I'd be all for 14-char filenames if there
were still any significant number of more traditional Unix systems in
daily use.  :-)

>  Losing
> some names like "aux" is a small price to pay for the ability to provide
> support for embedded type work to the people that are looking at VxWorks,
> or WindowsCE, or Windows XP embedded.

Well, it all depends....  If a shop is going to be developing a target
based on *BSD but isn't willing to do at least some of their development
_on_ *BSD then why do we really care to support them?  They obviously
don't have our complete interests in mind and they may do as much to
damage our goals as they do to benefit them.

> We _want_ those people looking at NetBSD and using it in the next Widget 2000
> right?  We're not _trying_ to chase them off because they use an "inferior"
> OS on their existing development systems are we?

I'm not so sure, which is exactly why I posted in the first place.

Personally I do not want to target people who are not willing to "embed"
their own developers into a *BSD environment, and especially not if they
are intending to develop *BSD targets, but no _on_ *BSD hosts!

There's a lot more to being a good Unix developer than being able to
build the code and boot it.  Unix systems have almost always been self
hosting, and the result has been a suite of refined development tools
that are extremely well suited for the kinds of programs that make up a
Unix system (be it an embedded target system, or the host development
system itself).  I believe the psychology of embedding your developers
in the environment they are targeting has very powerful and positive
benefits.  Indeed their participation in the host environment will
hopefully benefit others as well in further refinement to the tools we
all use, as well as in their support for the whole system, not just some
trimmed down portion of it.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>