The goal of openness is laudable, though I don't understand the software/hardware distinction that appears to be common in GNU/FSF circles; convert proprietary firmware or software into equivalent hardware, and magically it becomes uninteresting that it's proprietary and unable to be modified?
The CPU microcode example from the article is particularly nonsensical. The author seems to be arguing that CPUs without loadable microcode are more free than CPUs with loadable microcode. However, the non-loadable CPU is incapable of being modified or fixed, whereas the loadable CPU's microcode format has the potential to be reverse engineered, at the very least.
This seems to be a prevalent mindset among free software advocates; the OpenMoko project had a similar stance with firmware for a radio: http://lwn.net/Articles/460654/
Aside from all the philosophical debate, and though it's a promising start, the whole thing sounds 10 years or more behind current PC technology in terms of performance; I can't imagine actually using one of these as a daily driver.
This from a piece by RMS in The Guardian "Is Android really free software?" [0] explains his reasoning behind accepting hardware with permanently embedded firmware.
In any case, the phone network firmware in an Android
device is not equivalent to a circuit, because the
hardware allows installation of new versions and this
is actually done. Since it is proprietary firmware, in
practice only the manufacturer can make new versions
– users can't.
Putting these points together, we can tolerate non-free
phone network firmware provided new versions of it won't
be loaded, it can't take control of the main computer,
and it can only communicate when and as the free operating
system chooses to let it communicate. In other words, it
has to be equivalent to circuitry, and that circuitry must
not be malicious.
It's a matter of who owns the device: me, or the company that sold it to me?
Some things are better left unchangeable if the alternative is that somebody besides the owner is in charge of them.
For example, suppose you had the choice between an old-fashioned mercury thermostat for your house, or a fancy programmable Honeywell thermostat that required an overpriced Honeywell technician to come out and make changes, as long as those changes were approved by the Honeywell corporation?
I don't know about you, but regardless of the benefits of the new programmable thermostat, I'm not renting control of my HVAC system from the Honeywell corporation. I will be the one in charge of my home, even if that means using less flexible or out of date technology. Some people feel the same about their digital home as well.
I'm not a fan of OpenMoko since the whole thing seems less intelligently thought through by FSF before they came forth with their conditional endorsement. The implementation behind attempts to make "free" software and hardware are not always right out of the gate. But I believe that the tech of the Lemote being "behind current PC technology" is acceptable if-and-only-if this netbook remains fully hackable as a device. Hardware naturally does not fall under the same conditions as software - you can't easily "make copies" of hardware and "distribute" them, but you can (as the creator) document well the hardware and how it works (interfaces with software) such that users can write useful programs to interface with it, or improve upon the hardware design by pointing out flaws revealed by the software you write - not possible if the hardware is not documented and accessible only via proprietary firmware. Also, as users it is our right to know what the software on a system is doing, and when firmware is locked and proprietary, we don't have full disclosure of the activity of the software - not every user out there can reverse engineer or hack their software to determine if their rights are being violated. Sounds 1984, I know, but these are valid concerns, I think, for more accessibility in the hardware our software runs on.
The CPU microcode example from the article is particularly nonsensical. The author seems to be arguing that CPUs without loadable microcode are more free than CPUs with loadable microcode. However, the non-loadable CPU is incapable of being modified or fixed, whereas the loadable CPU's microcode format has the potential to be reverse engineered, at the very least.
This seems to be a prevalent mindset among free software advocates; the OpenMoko project had a similar stance with firmware for a radio: http://lwn.net/Articles/460654/
Aside from all the philosophical debate, and though it's a promising start, the whole thing sounds 10 years or more behind current PC technology in terms of performance; I can't imagine actually using one of these as a daily driver.