On Sat, 2 Sep 2006, Garrett D'Amore wrote:

> Of course I would prefer to have _source_, but I also recognize there
> are cases for binary blobs.  I believe ath(4) is one such case.

What is the case for that, exactly?  I dont have any ath hardware, but as
far as I am aware its to do with the restrictions that the manufacturers
claim that the regulatory body in the USA places on them with regards to
users being able to tweak the device beyond its regulated limits?

> My biggest complaint with blobs is lack of portability, but in at least
> one case (ath(4)) the supplier has gone out of his way to make sure the
> blob is available for any platform that might have the hardware.

I have two complaints with blobs.

a) The sys/contrib/dev/ath directory (eg) is 8Mb of uuencoded binary
bloat, and every time another platform wants to add ath(4) support, more
bloat ensues. How big is the source for a wireless device driver anyway?
(as a reference, there seems to be 150k of wi(4) related source)

b) NetBSD is an open source operating system. While I dont think that we
should be saying 'Hey, we wont deal with these evil blobs' I dont think
they should be distributed as part of the source code.

> I totally disagree with any stance we take that prevents binary blobs
> from being used with the operating system.  It will prevent NetBSD from
> being used in a number of scenarios going forward.

I think there is a correct place for these binary blobs, and that is to be
brought in via a pkgsrc package when required.  That may be inconvenient,
but maybe it would inspire somebody to make kernel modules beautiful for
the rest of us :)

iain