On Mon, Aug 27, 2012 at 11:04:31AM +1000, Ben Sturmfels wrote: > Adam Bolte <abo...@systemsaviour.com> writes: > > > If my above assumptions are correct, why treat graphics driver firmware > > specially? I'm certainly not saying it's wrong to demand free firmware, > > however I'm curious why some firmware is treated differently. Is it because > > one lives in your filesystem on your HDD, but the other is stored in an > > EEPROM > > (and if so, why does this matter)? > > Yes, for me, that's it exactly. I distinguish between devices that > require non-free firmware to be uploaded each time I turn them on and > devices that have firmware inside but don't require me to touch it.
Thanks for the clarification. I respect your opinion. Personally, I feel that if the firmware is uploaded from the file system via free software, as opposed to being uploaded by a closed system external to the kernel which I don't control, I'd rather have it on my file system. > ...and devices that have firmware inside but don't require me to touch it. If the firmware is freely distributable under a "do whatever you want"-type license (but still proprietary), you don't actually have to touch anything yourself. It's generally no different to firmware on EEPROM from a user perspective, if the drivers are coded correctly. Actually, maybe *you* do have to touch something since you run Trisquel, but for the vast majority of GNU/Linux users this will go unnoticed. (Note: I'm not trying to have a go at you and want to be absolutely clear about that, but it must be noted that proprietary firmware is a much bigger deal for you than most because you chose to make it so - regardless of it being right or wrong. I had forgotten this when this thread all began). > It's important to me to draw clear lines between the free and the > non-free software. I don't want my operating system project to have to > distribute non-free software, because fully-free operating systems are > so much more powerful as an advocacy tool. That's why I use Trisquel; > because it makes no exceptions. Trisquel might give some people the illusion that they can run their computer with 100% free software at least, and certainly they are doing their best to make sure that you are running as little as absolutely possible (even if it means non-functioning hardware). When hardware does function however, I do not want it to be just because the proprietary bits have been swept under the rug. > Beyond that, I also think it's important that we have free firmware for > devices that come with it embedded such as motherboards and hard > drives). These are a smaller violation of freedom though, and cleanly > segmented from operating system distributions. Right now I prefer > instead to focus on the bigger problems for freedom such as Skype and > Adobe Flash. Interesting. As per information pointed to me by Chris, it appears that microcode is loaded into the CPU via the BIOS upon boot. This microcode (along with the BIOS generally) is proprietary. What you appear to be saying is that if AMD's graphics firmware was also loaded by the BIOS instead (where you would actually have less control over how and what gets loaded), it's not so bad. My view on all this is that I don't care about boundaries so much. If there are tiny bits of proprietary software on my file-system required to have a functioning computer, that's fine - *provided* the end result is an overall larger reduction in proprietary software over what it would be by segregating it to different storage systems (such as EEPROMs) that can be more difficult to access. As a small side-benefit, I would expect having separate firmware files loaded by the kernel would make reverse engineering efforts slightly easier, as there would be no requirement to figure out how to dump EEPROMs, and you can directly compare it against all the other firmware files for similar hardware - likely all distributed within the same package. Of course, I'd prefer to not have any proprietary firmwares, microcodes, etc. stored anywhere on my systems... I'm just drawing a different line for myself. Cheers, Adam
Description: Digital signature
_______________________________________________ Free-software-melb mailing list Freeemail@example.com http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb