>>>>> "mh" == Martin Husemann <martin%duskware.de@localhost> writes:
I differ from the OP and don't care whether blobs are in pkgsrc or
distributed in the main .tar.gz. Actually I prefer them in the
.tar.gz. But I do use OpenBSD and Linux on access points instead of
NetBSD because I want to either avoid blobs or get a better blob.
mh> The "visible code" is a red hering. For example: I use a wi(4)
mh> card and have to use windows to flash new firmware into it
mh> (which is realy inconvenient if the card normally sits in a
mh> sparc64 machine and is not pcmcia/cardbus). Lucky me, firmware
mh> updates for wi(4) have been rare recently ;-}
it's a little different. When the firmware is burned into the card,
the firmware releaser is forced to do release engineering at the
free/nonfree border more carefully than when the blob is linked
against the driver so the driver will always work with whatever blob
the driver-releaser has linked into it. In the latter case, the blobs
end up getting passed around like warez, and depending on your
relationship with the blob's copyright holder you will get a stable
blob, or you will get a Leffler blob.
This is in fact the case with Atheros, where Windows gets better blobs
than we do and thus has better rate adaption, better performance on
congested networks, working background scanning, much better
stability, whatever. Meanwhile we're forced to run Leffler's beta
test HAL's. Except that things are actually much worse than that,
because usually the blobs are not blobs at all for the writers of
proprietary drivers---they sign NDA's and get source, and thus the
baseline impression of how good is this wireless chip one gets from
its performance in airport AP's, macbooks, and entee peecees, is based
on what the driver writer can do if he tweaks the blob source a bit,
since most of them do. With PRISM there's not a separate fork of the
blob for each driver. We have to be given access to the same blob
everyone else is using, so whatever part of the blob is tweaked or
improved on behalf of the EnTee and Mac OS X drivers, we get to use
that too.
This leads to really disgusting behavior like DD-WRT where the main
value of the software being sold comes from the GPL'd component, while
this one little collaborating troll under the bridge rakes in cash by
selling unlock codez over paypal for his tweaked Atheros HAL that let
it operate at 4.9GHz and such (outside the UNII band). I guess unlock
codez could be implemented with the PRISM style firmware, too, but in
that case Intersil would be the one to sell them. The fact that it's
not really possible to write a proper Atheros driver without access to
the source inside the blob means that Atheros sells lots of licenses
to their blob source, so the blob finds its way into a lot of people's
claws, and one of these unsavory fellows makes a fork of openwrt and
finds something disgusting to do with his NDA privileges.
I sort of agree with you about PRISM being just as proprietary whether
the secret sauce is in a .o or burned into the card, and even have a
stale rant of the same thing you're saying posted on my personal web
page, but in practice I think the situation works out differently, and
binary blobs are pretty toxic.
OpenWRT also has a better forked blob. Felix has signed the Atheros
NDA and releases some blobs more stable than Leffler's, and he is also
working on the branch of the GPL driver which is checked into OpenWRT.
Felix is a good guy, not selling unlock codez like the ddwrt guy, but
it's still a revision control mess. Ubiquiti also has an Atheros
license and sells access points running a fork of OpenWRT with their
blob+driver loaded into it. Their blob supposedly works better for
some of the access point hardware Ubiquiti sells---it has control of
polarization and antenna selection and power calibration and
signal-strength LED's, as well as bug fixes, but then their blob only
works with their (source included as per GPL license, I assume) fork
of madwifi, so you can't use a modern Linux kernel with it unless they
keep it up-to-date which they don't. And their blob refuses to load
unless it detects their serialized hardware, so they use that DRM-ish
tying to collect the brainslayer toll and prevent competitors from
using their bug fixes. While they might have made improvements to the
HAL for the particular model of WiSoC they're using, you can't use it
on a non-Ubiquiti AP using the same WiSoC the way you could with
firmware that would more likely come from Atheros with your WiSoC and
stay with the chip. Neither the revision control problem nor the
TiVo-izing problem are surfacing with PRISM-style burned-in firmware
in common use that I've heard of.
Attachment:
pgpW2cB4zF34e.pgp
Description: PGP signature