Subject: Re: Embedded NetBSD? [was Re: CVS commit: basesrc]
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: Matt Doughty <email@example.com>
Date: 10/29/2001 15:55:18
On Fri, Oct 26, 2001 at 05:47:26PM -0400, Greg A. Woods wrote:
> [ 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).
Well, in alot of cases coporate policy may prevent the developement
department from choosing what platform they want to work on. I have
worked at a number of shops where individual departments can't choose
their workstation OS. Are you really going to deprive these groups locked
out of *BSD usage because of issues they may have no control over?
> > 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. :-)
What was the principle again exactly. Oh I see, I don't like there OS so I want
punish them for trying to use NetBSD.
> > 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.
See above, the developers may be trying to get a mind share with management.
It may be a case of trying to show those who make decisions that using NetBSD
is the 'right thing to do'(tm). Unfortunately, you seem bent on blocking these
people at the gate with a 'all or nothing' mentality. This is not good for
increasing the NetBSD mindshare, and your unwilliningness to accept that there
may be extenuating circumstances that may prevent a shop from switch to a
pure NetBSD developement environment is exactly the narrowmindedness that
is most damaging to NetBSD not developers who for whatever reason have to
develope on the admittedly braindead platform known as windows.
> > 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.
And if you would just let them in the door to look around, they might just
realize the potential of NetBSD as developement, and make the move to NetBSD
as developement platform. You have to look at price of entry, and realize
that requiring a shop to change OSes to use something is a price that most
executives will not be willing to sign off on, and honestly they shouldn't
have to. There really isn't a good reason to prevent people from gradually
switching developement platforms. Isn't it exactly this kind of attempt to
force people to use their OS in order to use their SDKs that M$ is often
ridiculed for? Think about.