| |||||||||||||
Raspberry Pi VideoCore driver code releasedRaspberry Pi VideoCore driver code releasedPosted Oct 25, 2012 6:52 UTC (Thu) by paulj (subscriber, #341)In reply to: Raspberry Pi VideoCore driver code released by dlang Parent article: Raspberry Pi VideoCore driver code released The idea that what matters is if it's in ROM or if it can be updated is the most bizarre boundary that I can imagine. It's a perfectly sensible boundary. Indeed, it's perhaps the only reasonable boundary you can draw if you wish to make a distinction between software and hardware. Otherwise they blur into each other. If your goal is to afford users/owners the same level of control over modifications as the designer (as it was for the FSF), then this is a logical boundary to draw. If you have other goals could you draw other boundaries (e.g. "I want to change all code running on the main CPU", "I want to be able to verify all code able to access main RAM")? Sure, as you have done. However, to argue this invalidates the boundary others have chosen only demonstrates you've ignored why they chose that boundary.
(Log in to post comments)
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 7:17 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the designer doesn't have the ability to force you to run an updated program, or to plug in a offline update process. so the designer doesn't have as much control as you make them out to have
Raspberry Pi VideoCore driver code released Posted Oct 25, 2012 7:40 UTC (Thu) by smurf (subscriber, #17840) [Link]
Frankly I don't care why the FSF has chosen that boundary.
The point is that this policy prevents opening up existing devices – either by the original manufacturer or by somebody else. So to me this makes no sense whatsoever.
If a philosophical argument, well-intentioned or not, results in less freedom, it is wrong. Plain and simple.
Raspberry Pi VideoCore driver code released Posted Oct 27, 2012 9:24 UTC (Sat) by paulj (subscriber, #341) [Link]
How exactly?
Raspberry Pi VideoCore driver code released Posted Oct 27, 2012 10:56 UTC (Sat) by smurf (subscriber, #17840) [Link]
That should be obvious.
Today I need to buy a device with closed-source firmware. It's available with the binary either as a BLOB, or on ROM. As the FSF says that only the latter is OK, so I decide to buy that.
Tomorrow the manufacturer finds a bug and releases updated firmware. Oops, mine is on ROM so I'm screwed and can't get the bugfix.
Next month somebody reverse-engineers the firmware and creates a free replacement. Oops, my device has the firmware on ROM so I can't switch.
Next year the manufacturer realizes the game's over, and releases the source code. Oops, my device has the firmware on ROM so I can't use that source code.
Yet the FSF says that firmware-on-ROM is OK while firmware-as-BLOB is not.
Raspberry Pi VideoCore driver code released Posted Oct 27, 2012 22:13 UTC (Sat) by paulj (subscriber, #341) [Link]
That's an interesting dichotomy. However, it will never exist. If a hardware vendor produces a board without a ROM, with drivers that have to download a blob to bootstrap that hardware, then why would they ever release a hardware WITH that blob on ROM? That hardware would be more expensive.
We could go into the economics of downloaded v fixed firmware. The former will be quicker to market, the latter will need higher quality engineering to avoid the expense of returns and so perhaps less buggy compared to the former. etc. The burned-in firmware will have had to have had to be developed in a more rigorous manner, with more QA. Potentially, it will have had to have been designed with more attention paid to the architecture (simpler/cleaner), with more complex functionality left to the host software. So there are side-effects besides freedom - the competing products will *not* be equal on quality / price.
In the field of networking, there are the more simple, functional network adapters and there are the more complex ones that require significant amounts of firmware. In ethernet, the complex firmware ones are things like the TCP/IP offload cards. In wireless, its the difference between cards that do lots of the 802.11 logical functionality onboard, and ones that are more like radio modems with logical 802.11 functionality left to the host. The more simple devices are ultimately more flexible, precisely because more of the software is implemented in the OS than by the hardware vendor.
Anyway.. A line had to be drawn somewhere (RMS can be quite pragmatic). The freedom to modify was a line. There may be other lines, and they have different trade-offs.
Personally, I'll hold my nose and supply firmware blobs to hardware that really needs it. However, the more that hardware is like a general purpose computing device and the more it's expected to be updated regularly, the less I like it, and the more I'll try avoid those products. The more a blob looks like something that needs ongoing software engineering, the more I want the software engineers concerned to be the Linux kernel developers. Unfortunately, that's perhaps too amorphous to draw a clear line between.
Raspberry Pi VideoCore driver code released Posted Oct 28, 2012 3:41 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> why would they ever release a hardware WITH that blob on ROM?
because the FSF will say that their device is Free if they do so, but won't if they don't.
for some segment of users, this is significant, and manufacturers aiming for such users (which most don't) would like to make their buyers happy.
The Raspberry Pi team mentioned the possibility of making a version that had the firmware in ROM, specifically to satisfy such users.
Raspberry Pi VideoCore driver code released Posted Oct 28, 2012 16:23 UTC (Sun) by khim (subscriber, #9252) [Link] To claim that this idiocy can never exist is just wrong. It was discussed quite recently. And since noone of sane mind will ever think of designing something specifically for the FSF-lovers what you get is obsolete and crippled stuff with firmware which is not updateable not because it's so perfect that you never need to update it but because team which designed said hardware is disbanded and no longer creates new versions. Is it really what you want to endorse? As I've already said: FSF approach leads to the "solution" which is not only more expensive, but also less hackable! FSF's preferred "solution" is always, always, ALWAYS worse from the hackability POV!
|
|||||||||||||