Am Samstag den, 16. M=E4rz 2002, um 07:42, schrieb Wojciech Puchar:

>> What about systems where Intel gear is integrated already?
>>
>> The more drivers we have, the bigger out potential market is in terms=20=

>> of
>> customers.  It is in our best interests to have more drivers, =
whatever
>
> i can see on WWW page:
>
> "NetBSD focuses on clean design and well architected solutions. =
Because=20
> of
> this NetBSD may support certain 'exciting' features later than other
> systems,
>      but as time progresses the NetBSD codebase is getting even =
stronger
> and easier to manage, while other systems that value features over =
code
> quality are
>      finding increasing problems with code management and conflicts. "

Philosophical ruminations to follow...

Unfortunately, relative to i386 designs, NetBSD from my perspective does=20=

have
certain 'lacks' relative to ease of install, update, and get the local=20=

hardware
userful, that other approximately 'free' software packages have already.

Perhaps it is because of the wide 'other processor' support, that some=20=

of these
things don't get done. For example, I'm thinking about a bootable CD for
my ARM/XScale distribution. Why, because my hardware set includes a SCSI
device, and hence I can support a direct CD access. Someone doing an=20
Compaq
iPAQ, which uses an ARM processor as well, may not think about such, and
hence I have to write from scratch. Further, someone may not like the=20
fact that
I'm going to use El Torito CD boot format, and write their own, if they=20=

need to, hence
eventually there may be several techniques, and leads to a sense of=20
confusion.

In the PC and PPC worlds, the hardware vendors have already 'solved' =
this
variation by having boot methods specified, and the NetBSD porter then=20=

makes
NetBSD work in that environment.

However, the main point here is, that I'm in control of my hardware, I=20=

don't need
an NDA, or spend many many hours reverse engineering hardware to do=20
what I
need to do. Hence, if NDA are the requirement to support hardware=20
quickly, then
that's what needs to be done, as long as the eventual source result is=20=

open
to the NetBSD community. (The alternative is that folks will execute=20
NDA's
write their code, and not mention to anyone that the support exists,=20
except in
advertising, if at all...)

What the NetBSD community, especially the 'commercial' entities can do =
is
act as Agents for the porter, so the company which requires an NDA has=20=

the
sense of doing business with a business. However, with that comes the=20
requirement
that until the NDA entity grants permission for the work to be=20
published, the
work is not published... Otherwise that will be the last time the=20
manufacturer
will enter into such an arrangement.

I expect most people anticipate Intel will continue to produce chips for=20=

which
Intel support will be needed early enough in the chip's life to make it=20=

worth
the while to support, and hence wish to continue a working relationship
with Intel in regard to getting information needed.

Of course, if OpenChips Inc takes off where all designs from the chip=20
discriptions
in the appropriate design language are 'open source', such NDA's would=20=

not
be necessary.

Unfortunately, and rather disappointing for me, the world seems to have=20=

gone
more capitalistic in the last 30 years... FSF/GNU not withstanding...