>>>>> "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.
Description: PGP signature