Resurrecting this old thread, now that OUYA is out... Did you guys end up chipping in for one? Did anybody get theirs? I got mine this week, and I am severely disappointed from both a freedom and security standpoint that it requires me to enter a credit card before I can even turn it on.
https://plus.google.com/108688191891412975833/posts/baejsGtfX3C To be fair, it *is* hackable hardware, as promised. Apparently you can root it, flash the firmware, etc. But I'm not so interested in this (because after all, it's just a small ARM computer if you're just going to wipe the software). I'm really disappointed that the console that is supposed to give me full control over my system is making such stupid demands up front. This doesn't bode well. Oh well, it was reasonably cheap. On Mon, Aug 27, 2012 at 7:35 PM, Adam Bolte <[email protected]>wrote: > On Mon, Aug 27, 2012 at 11:04:31AM +1000, Ben Sturmfels wrote: > > Adam Bolte <[email protected]> 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 > > _______________________________________________ > Free-software-melb mailing list > [email protected] > > http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb > > _______________________________________________ Free-software-melb mailing list [email protected] http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/
