On Sun, Aug 12, 2012 at 09:44:09PM +1000, Matt Giuca wrote:

On Sun, Aug 12, 2012 at 7:50 PM, Ben Sturmfels wrote:

...

I see they've already raised $8M in pre-sales though, so perhaps there are other free software organisations that would benefit more from a donation right now. I'm thinking instead of buying a video card from Think Penguin [3].

Also the Kickstarter for Ouya is over ...

I pledged for one, so if it all goes well, I'll let you guys know how it is.

I pre-ordered one over the weekend also. -Adam

Adam Bolte writes:

On Sun, Aug 12, 2012 at 07:50:00PM +1000, Ben Sturmfels wrote:

...

I see they've already raised $8M in pre-sales though, so perhaps there are other free software organisations that would benefit more from a donation right now. I'm thinking instead of buying a video card from Think Penguin [3].

[3] https://www.thinkpenguin.com/gnu-linux/geforce-9500gt-1gb-pci-express-20-vid...

I just noticed... it's an Nvidia card you are talking about. This gives me mixed feelings. Sure supporting free software drivers and stores that find such hardware is great, but supporting Nvidia? <shudder>

I'm assuming it's still the case that Intel drivers are 100% free software for at least some of their newer cards, although obviously the performance won't be the same.

AMD makes cards that have excellent free software drivers, and (unlike Nvidia) they release the specs... however most modern AMD cards rely on non-free firmware - firmware that isn't built into the device's ROM, but instead needs to be loaded by the driver during initialisation.

Even so, it seems to me that AMD is doing far better at helping the free software driver communities than Nvidia ever has. I have a Radeon HD 5870 (which I purchased with Bitcoin) with 6 LCDs hooked up to it at work, running the free software drivers. The performance is great. I can play OpenArea with max detail at 7680x1024, 60fps (I use v-sync or it would likely be much higher). There are some FoV issues in doing that I haven't completely resolved, but it's quite impressive to see.

Note: It appears that newer Nvidia cards also require proprietary firmware, until free software drivers are reverse-engineered. http://nouveau.freedesktop.org/wiki/InstallDRM#Firmware

I would like to put more pressure on AMD to release the code for their firmware though, or at least see as much effort put forward to develop free firmware for AMD cards as we have seen from the Nvidia reverse-engineering guys.

Thanks for pointing this out. Yes, it's certainly an imperfect choice. Buying one of these Nvidia cards support Think Penguin, a new vendor who sells hardware compatible with fully-free software. On the other hand, it results in some profits for Nvidia, who are extremely unfriendly to free software. Choosing an AMD card means I'm giving some profits to AMD, who offer dramatically better support for free software. On the other hand though, I'd be required to use proprietary firmware. In terms of my personal freedom today, the Nvidia card would be the best choice. For encouraging free software-compatible hardware in the longer term though, I don't know that there's a clear answer. Ben

On Sat, Aug 25, 2012 at 04:32:36PM +1000, Ben Sturmfels wrote:

Adam Bolte writes:

...

On Sun, Aug 12, 2012 at 07:50:00PM +1000, Ben Sturmfels wrote:

...

I see they've already raised $8M in pre-sales though, so perhaps there are other free software organisations that would benefit more from a donation right now. I'm thinking instead of buying a video card from Think Penguin [3].

[3] https://www.thinkpenguin.com/gnu-linux/geforce-9500gt-1gb-pci-express-20-vid...

I just noticed... it's an Nvidia card you are talking about. This gives me mixed feelings. Sure supporting free software drivers and stores that find such hardware is great, but supporting Nvidia? <shudder>

...

AMD makes cards that have excellent free software drivers, and (unlike Nvidia) they release the specs... however most modern AMD cards rely on non-free firmware - firmware that isn't built into the device's ROM, but instead needs to be loaded by the driver during initialisation.

Even so, it seems to me that AMD is doing far better at helping the free software driver communities than Nvidia ever has.

Choosing an AMD card means I'm giving some profits to AMD, who offer dramatically better support for free software. On the other hand though, I'd be required to use proprietary firmware.

True. Even basic embedded proprietary firmware that users are not expected to interact with directly can still be a problem, as most people who have purchased a SSD recently would be able to tell you. http://www.tweaktown.com/articles/4870/lsi_sandforce_5_series_ssd_firmware_t... Unfortunately, I'm not aware of any HDDs/SSDs with free firmware... perhaps some basic USB Mass Storage devices qualify as not requiring any (and running hdparm -I on the few USB keys I have produces garbage which might suggest as much)? However I'm guessing you (as well as most/all free software advocates on this list) do use a HDD or SSD of some kind. 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)? Or is it just because the graphics card is from Think Penguin? -Adam

On Sun, Aug 26, 2012 at 10:04:05AM +1000, Ben Finney wrote:

Adam Bolte writes:

...

On Sat, Aug 25, 2012 at 04:32:36PM +1000, Ben Sturmfels wrote:

...

Choosing an AMD card means I'm giving some profits to AMD, who offer dramatically better support for free software. On the other hand though, I'd be required to use proprietary firmware.

True. Even basic embedded proprietary firmware that users are not expected to interact with directly can still be a problem, as most people who have purchased a SSD recently would be able to tell you. […]

...

If my above assumptions are correct, why treat graphics driver firmware specially?

First you'd need to show that we're treating graphics firmware specially. I think the same criticisms are applied to vendors who act against freedom in network interface firmware, graphics firmware, radio firmware, etc.

Like yourself, instead of purchasing computer hardware from perhaps a local computer retailer, Ben has elected to import hardware from the US on the basis that these Think Penguin machines are tested to be "compatible" with free software - or at least that was my understanding. However, even those machines provide the option of various SSDs, HDD&SSD hybrids (all surely requiring non-free firmware), and even non-free BIOSs. eg. https://www.thinkpenguin.com/gnu-linux/emperor-penguin-gnu-linux-notebook Yet, these issues are rarely given any attention. Instead, most efforts seem to be directed towards network and graphics firmware. Observe that all Think Penguin desktops and laptops use Intel graphics cards by default - presumably largely to avoid the issue of proprietary firmware. So yes I think HDD, SSD firmware and even BIOS software is being treated quite differently to graphics firmware in general by free software advocates - even though those IMO represent more serious threats (discussed below). I suspect this is largely because the FSF made a big deal about the binary blobs in the Linux kernel - something that everybody uses and was actually being distributed so was a much easier win (even if far less important).

...

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)?

Almost. The important matter is: who has effective freedom in the device once it's in the hands of the customer, to determine what it does and modify its behaviour and share those modifications with others?

With some devices, such as the keyboard controller chip, the answer is something close to “no-one”. These are devices whose behaviour is entirely determined at the time the customer buys them, and are not under the influence of anyone to change that behaviour.

More specifically, a keyboard controller chip's behaviour would be determined at the time of manufacture and would likely not be reprogrammable by said manufacturer even if the device were returned. It makes sense that having access to such code wouldn't be beneficial.

Such devices are effectively unchanging machines, and don't present much of an imbalance of freedom between the vendor and customer: neither is in a privileged position.

With other devices, such as the CPU, the answer is close to “the customer”. The whole point of the CPU is to be endlessly reprogrammable, and the customer has close to infinite freedom to determine that programming.

Yep - it would be good if that were always true. Which is why I (unlike Think Penguin) try to avoid Intel products. http://www.engadget.com/2010/09/18/intel-wants-to-charge-50-to-unlock-stuff-... (as if that wasn't bad enough, it requires running a proprietary Windows program to unlock) You might also recall the Pentium III unique ID controversy of 1999? Intel later released a program to disable this functionality, suggesting Intel has had for a long time more control over the CPUs it manufacturers than a user would have once the chips leave the factory. http://www.wired.com/politics/law/news/2000/04/35950 For the most part however, Intel doesn't issue microcode updates. AMD has only enabled users to update microcode since 2009 (on GNU/Linux systems at least). Out of sight, out of mind? (See the discussion of HDD firmware below for another example of firmware that is upgradable but until recently rarely was.)

Such devices are effectively under the control of the customer, not the vendor. So those aren't much of a problem for the customer's freedom either.

The border that is contentious is where we find devices designed to have their behaviour modified, but in a rather limited way and through tightly restricted channels – such as upgrading the firmware at boot time or run time from a binary blob.

But do these graphic card firmwares really see proprietary updates from vendors that modify the behaviour in some useful way? Or is this something you are assuming just because a firmware needs to be loaded at boot, and proprietary graphics card drivers (which include the firmware) regularly get updates? I just did a quick check, and downloaded the Debian firmware-nonfree_0.28+squeeze1.tar.gz tarball, and generated an MD5SUM checksum list of everything in linux-nonfree/radeon/*.bin. I then compared that to what was in the Wheezy firmware-linux-nonfree 0.36 source package, and all checksums matched. It seems to me that the problem you are describing isn't real for radeon products throughout the last year - if ever.

For these difficult-to-update devices, the question then turns on who has effective freedom to deploy updates to the device's behaviour. If the customer is effectively restricted from deploying their choice of update, while the vendor has a privileged channel to get updates to the device, then that's a problem for the customer's freedom.

Has anyone developing the radeon drivers ever complained that the non-free firmware (despite having hardware specifications from AMD) was restricted in getting the card to function as desired in any meaningful way? Or is this also an assumption? Could it possibly be that the firmware simply has to exist, but cannot be modified to any obvious benefit were access to the code provided (assuming the firmware is functioning correctly)?

If the customer has no less freedom than the vendor to deploy their choice of update to the device's behaviour, then there's no disparity between the vendor's freedom in that device and the customer's.

This is why a keyboard chip which no-one can modify isn't a significant problem for freedom, and the CPU which the customer can easily modify isn't a significant problem for freedom, while a graphics chip commonly is a problem and we pay close attention to which vendors act to preserve or restrict the customer's freedom in the device.

Citation that the non-free firmware is actually restricting the free software developers from making the card function in any desirable way which the hardware is capable of would be useful. Whilst I haven't performed much investigation here myself, it's difficult to do so with the Xorg wiki always being down as of late. I certainly haven't heard or seen any such claims.

The border is ever shifting, too. Whereas persistent storage devices (such as HDDs) used to have behaviour that neither the vendor nor the customer could update, many SSDs now have the expectation of updates to their behaviour – and the vendor has the same kind of privileged path to choose those updates which the customer doesn't have.

My impression is that the firmware found in graphics cards is far more trivial than that found in devices such as SSDs. Looking again at the Wheezy radeon firmware files, the largest is CAYMAN_mc.bin at 24K. Compare that to my current SSD firmware at 442K. See for yourself - http://kb.sandisk.com/app/answers/detail/a_id/10476/related/1 "SanDisk Extreme 480GB SSD", extract the ramdisk.gz image and see the firmware.bin file (along with separate proprietary(?) updater files). If we take a trip down memory lane... recall the IBM Death^H^H^H^H^HDeskStar failures from 2001? From wikipedia: "A firmware update gives a clue to some of the issues: * Possible data corruption due to a problem with S.M.A.R.T. background operations. * Application of wear levelling to avoid the heads dwelling too long over the same area" https://en.wikipedia.org/wiki/Deskstar There seemingly were issues with the drives beyond firmware, however my point is that it has been clear that proprietary HDD firmwares have been: A. Upgradable by users and manufacturers for well over a decade now (even if updates haven't commonly been released publicly by manufacturers in all that time). B. There are legitimate reasons why end users are being hurt by proprietary firmwares in devices such as HDDs. C. Such issues have been well known for a long time, but few people actually care.

So vigilance is required: the tendency is for newer devices to place freedom to choose the device's behaviour in the vendor's hands while denying it to the customer.

On the contrary, I'm not convinced that any of these firmware blobs are necessarily a new thing. Video cards have always required firmware or otherwise a graphics BIOS (be it on EEPROM or loaded at runtime) which is almost always proprietary, and has been re-flashable easily for many years where stored on EEPROM. HDDs and SSDs have also always used proprietary firmware, however perhaps the firmware hasn't been easy to upgrade past a decade or so ago? Computer BIOSs also have seen very little progress in becoming free (or having free replacements readily available) despite being a significant attack on freedom and a PITA in general, however AMD appears to be helping to change that with their pledged Coreboot support for new processors. http://www.hardware.slashdot.org/story/11/05/09/1115235/AMD-To-Support-Coreb... I believe computer BIOS updates are quite significant in size - far greater than up to a 24K binary for a graphics card. I've mentioned at prior meet-ups the issue with my laptop not allowing me to display to an external HDMI/VGA connector by default (when an LCD is detected) - a feature many BIOSs offer and I would find very useful. By contrast, I am not able to think of a single benefit to modifying the graphics card firmware - aside from hypothetical scenarios where said firmware were to be malfunctioning or was not optimal. To care about graphics card firmware and not the BIOS when making purchasing decisions seems a bit hypocritical IMO. Lastly, we've always had proprietary firmware for our main internal storage devices, and this too has always been ignored. It's just that now such devices (and thus the firmware that drives them) have become more complex and hence more commonly problematic, more upgradable and the threat even more obvious. -Adam

On Mon, Aug 27, 2012 at 09:29:19AM +1000, Adrian Colomitchi wrote:

On Mon, 2012-08-27 at 01:34 +1000, Adam Bolte wrote:

...

...

The border that is contentious is where we find devices designed to have their behaviour modified, but in a rather limited way and through tightly restricted channels – such as upgrading the firmware at boot time or run time from a binary blob.

But do these graphic card firmwares really see proprietary updates from vendors that modify the behaviour in some useful way? Or is this something you are assuming just because a firmware needs to be loaded at boot, and proprietary graphics card drivers (which include the firmware) regularly get updates? Does requiring to runtime load a binary blob to have access to the GPU qualities of the video card is relevant to the "vendors modifying the behavior in some useful way" context?

That is indeed one of the key points of this argument. Is the firmware sufficiently complex that it actually dictates how the device will be used (as opposed to simply getting it to function)? If the firmware isn't actually modifying the device behaviour in some way that the manufacturers decide what is best for the user, this would put the firmware on a similar level to the keyboard controller previously discussed. Unfortunately I do not have those technical details, but I have seen no evidence to suggest otherwise at this point (but still a lot of fuss over this issue). SSD manufacturers get to control whether the user can utilise TRIM, wear-leveling algorithms to increase the product life, SMART functionality, etc. all presumably via firmware. These are all optional features, where the SSD would work perfectly fine for its primary purpose - storage - without these. I cannot immediately think of parallels in the case of graphics firmware. AFAICT, it's simply a case of graphics acceleration (the primary use of such devices) being unable to function if you don't have the firmware - which again would explain why the firmware is so small - with all the important functionality defined in the free software drivers. -Adam

Adam Bolte writes:

On Sun, Aug 26, 2012 at 10:04:05AM +1000, Ben Finney wrote:

...

First you'd need to show that we're treating graphics firmware specially. I think the same criticisms are applied to vendors who act against freedom in network interface firmware, graphics firmware, radio firmware, etc.

Like yourself, instead of purchasing computer hardware from perhaps a local computer retailer, Ben has elected to import hardware from the US on the basis that these Think Penguin machines are tested to be "compatible" with free software - or at least that was my understanding.

Close. They go to that effort in benefit of customer's software freedom, advertise it as a distinguishing feature, and say what devices are in the machine so we can verify exactly what free drivers will be used. That puts them a huge stretch ahead of most Australian notebook vendors in the advance of software freedom for customers.

However, even those machines provide the option of various SSDs, HDD&SSD hybrids (all surely requiring non-free firmware), and even non-free BIOSs.

Which makes them no different from Australian vendors in that regard. On the other hand, I know of no Australian vendor that goes anywhere near close to the level of we-guarantee-it-works-with-only-free-software effort and proactive advertising on the basis of software freedom. If you can find one which goes *even further* than Think Penguin, ZaReason, Gerlach44, and so on, please let us know. Bonus, of course, if they're Australian.

Yet, these issues are rarely given any attention. Instead, most efforts seem to be directed towards network and graphics firmware.

I think that's a function of the long-standing intractability of nVidia and ATI on software freedom, and the rather recent advent of SSDs. I agree with you that they are both important issues for software freedom, and I don't treat either of them as less important than the other. In the case of my SSD, you may recall that I was the one who raised the problems of SSD non-free firmware updates and HDMI+HDCP, at the Free Software Melbourne meeting where I discussed this machine and my efforts in buying it. I was unaware of either problem when I was researching the machine, so I deny the charge you're bringing that I treated them as somehow lesser problems.

For the most part however, Intel doesn't issue microcode updates. AMD has only enabled users to update microcode since 2009 (on GNU/Linux systems at least). Out of sight, out of mind?

No – as I said, if the vendor is not in a privileged position to deploy updates to the device's behaviour, then the customer's freedom is significantly more secure. That's good reson to treat it as less of a problem.

But do these graphic card firmwares really see proprietary updates from vendors that modify the behaviour in some useful way? Or is this something you are assuming just because a firmware needs to be loaded at boot, and proprietary graphics card drivers (which include the firmware) regularly get updates?

Either the firmware update makes a significant change to the device's behaviour, in which case the customer's freedom to choose to load different firmware is important to their freedom; or it's not significant, in which case it's not important. Wherever you draw the line, that's where the change in behaviour becomes significant enough that the issue of the customer's freedom comes in. -- \ “If you can do no good, at least do no harm.” —_Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney

Adam Bolte writes:

On Sun, Aug 26, 2012 at 10:04:05AM +1000, Ben Finney wrote:

...

First you'd need to show that we're treating graphics firmware specially. I think the same criticisms are applied to vendors who act against freedom in network interface firmware, graphics firmware, radio firmware, etc.

Like yourself, instead of purchasing computer hardware from perhaps a local computer retailer, Ben has elected to import hardware from the US on the basis that these Think Penguin machines are tested to be "compatible" with free software - or at least that was my understanding.

Close. They go to that effort in benefit of customer's software freedom, advertise it as a distinguishing feature, and say what devices are in the machine so we can verify exactly what free drivers will be used. That puts them a huge stretch ahead of most Australian notebook vendors in the advance of software freedom for customers.

However, even those machines provide the option of various SSDs, HDD&SSD hybrids (all surely requiring non-free firmware), and even non-free BIOSs.

Which makes them no different from Australian vendors in that regard. On the other hand, I know of no Australian vendor that goes anywhere near close to the level of we-guarantee-it-works-with-only-free-software effort and proactive advertising on the basis of software freedom. If you can find one which goes *even further* than Think Penguin, ZaReason, Gerlach44, and so on, please let us know. Bonus, of course, if they're Australian.

Yet, these issues are rarely given any attention. Instead, most efforts seem to be directed towards network and graphics firmware.

I think that's a function of the long-standing intractability of nVidia and ATI on software freedom, and the rather recent advent of SSDs. I agree with you that they are both important issues for software freedom, and I don't treat either of them as less important than the other. In the case of my SSD, you may recall that I was the one who raised the problems of SSD non-free firmware updates and HDMI+HDCP, at the Free Software Melbourne meeting where I discussed this machine and my efforts in buying it. I was unaware of either problem when I was researching the machine, so I deny the charge you're bringing that I treated them as somehow lesser problems.

For the most part however, Intel doesn't issue microcode updates. AMD has only enabled users to update microcode since 2009 (on GNU/Linux systems at least). Out of sight, out of mind?

No – as I said, if the vendor is not in a privileged position to deploy updates to the device's behaviour, then the customer's freedom is significantly more secure. That's good reson to treat it as less of a problem.

But do these graphic card firmwares really see proprietary updates from vendors that modify the behaviour in some useful way? Or is this something you are assuming just because a firmware needs to be loaded at boot, and proprietary graphics card drivers (which include the firmware) regularly get updates?

Either the firmware update makes a significant change to the device's behaviour, in which case the customer's freedom to choose to load different firmware is important to their freedom; or it's not significant, in which case it's not important. Wherever you draw the line, that's where the change in behaviour becomes significant enough that the issue of the customer's freedom comes in. -- \ “If you can do no good, at least do no harm.” —_Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney

On Mon, Aug 27, 2012 at 03:39:48PM +1000, Chris Samuel wrote:

On 27/08/12 01:34, Adam Bolte wrote:

...

For the most part however, Intel doesn't issue microcode updates.

Yes they do. That's why there's an "update-intel-microcode" program included in the microcode.ctl package in Debian/Ubuntu, so you can grab the latest version they've published rather than the one included in the distro. Latest update as in June apparently.

samuel@eris:~/Downloads/linux$ md5sum /usr/share/misc/intel-microcode.dat a0ed9124a72b31cbb1b307ae4e9c0022 /usr/share/misc/intel-microcode.dat samuel@eris:~/Downloads/linux$ dlocate !$ dlocate /usr/share/misc/intel-microcode.dat intel-microcode: /usr/share/misc/intel-microcode.dat samuel@eris:~/Downloads/linux$ sudo update-intel-microcode successfully downloaded Intel 20120606 microcode samuel@eris:~/Downloads/linux$ md5sum /usr/share/misc/intel-microcode.dat 1a1cf79dd1fab186c8a8fbae69aa9649 /usr/share/misc/intel-microcode.dat

Those microcode updates are (apparently) usually applied via BIOS updates for proprietary operating systems.

Interesting. Thanks for correcting me! I just checked that there is indeed packages called amd64-microcode and intel-microcode in the non-free repository for Wheezy, both of which came out this year. Thanks, Adam

On Mon, Aug 27, 2012 at 02:34:53PM +1000, Chris Samuel wrote:

On 26/08/12 10:04, Ben Finney wrote:

...

The border that is contentious is where we find devices designed to have their behaviour modified, but in a rather limited way and through tightly restricted channels – such as upgrading the firmware at boot time or run time from a binary blob.

Do Intel CPUs count as that with the microcode driver in the kernel which lets a user space app update their firmware?

Some useful background:

https://wiki.archlinux.org/index.php/Microcode

Interesting to note "Microcode updates via software are not persistent. In other words, one needs to apply them at each boot which is why it is placed in the MODULES array." So if there was some important CPU bug fixed in firmware update but no BIOS update to distribute it (eg. say the CPU was running hotter than necessary and the life expectancy was drastically cut short as a result), you would be forced into loading the firmware for your CPU each time you boot, in much the same way people with AMD graphics cards need to load firmware at boot. I realise it's not exactly the same thing (because unlike the AMD case it wasn't expected to be required), but it's very close. Even Think Penguin would be unable to save you from such a scenario! :) This makes it appear very likely IMO that the BIOS is generally responsible for loading microcode into the CPU upon each boot, instead of the kernel. Interesting. -Adam

On Mon, Aug 27, 2012 at 11:04:31AM +1000, Ben Sturmfels wrote:

Adam Bolte 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.

...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

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. 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/06/13 23:37, Matt Giuca wrote:

Did you guys end up chipping in for one?

Not as a group.

Did anybody get theirs?

Yes. Mine arrived on Thursday. The cardboard box was damp and looked like someone had used it as a football... but amazingly the contents inside were unarmed.

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.

This controversy was uncovered some months back, so I was expecting to need a credit card. Some information here: https://support.ouya.tv/entries/23463832-Why-do-you-HAVE-to-put-in-credit-de... - From the link, Ouya support stated "Other than being able to download games via the Discover section, absolutely no other functionality will require that you provide payment information. Period." We know this isn't true - you need to enter this information before you can even log in. Apparently you can load your own .apk files onto the device to run, but you wouldn't even be able to get that far without having some credit verified up front (unless hacking the device, of course). Fortunately, instead of a credit card, you also have the option of using a pre-paid credit code. These were apparently available during pre-order, and can be brought from various places online. eg. http://www.game.co.uk/en/ouya-10-credit-232744 So while some available credit must be verified (which I'm not defending - this aspect of the Ouya console sucks), it seems that you don't have to hand over your credit card to Ouya to store indefinitely if you don't want to. I have a spare debit card which I never have any money in, and I leave at home just for emergencies. eg. If my wallet gets stolen, I can cancel my cards and transfer money to my spare debit card account online while waiting for a replacement. This is the card I used when signing up for an Ouya account. When I made a game purchase (more on this below), I transfered money to the account associated with the card first. That way, I don't have to trust Ouya, and transferring money is still probably easier than dealing with buying pre-paid credit.

https://plus.google.com/108688191891412975833/posts/baejsGtfX3C

To address your concern of accidentally being charged for games by button-mashing, the one game I purchased to date gave the impression that the Ouya payment API forces certain GUI changes, based on the way the UI suddenly appeared - it looked very Android-ish, which was a stark contrast to everything else in-game. In any case, you can also configure (under the Parental menu) that you must enter a PIN first to make any purchase. A boss had just appeared after maybe 30 or so minutes of game-play. Then a message appeared asking me to purchase the game if I wanted to continue. Clicking "Purchase"(?) (this is from memory of course), I was told the game would cost $4.99, and then I had to click another button, "Confirm" IIRC, and then click one more time to dispel the message that I had successfully paid. Then i was back in the game. Having witnessed this myself, I can confirm that it was all very smooth and nicely handled. I can understand why they want a credit card up front (and it probably doesn't hurt that Ouya can say to potential developers "we have X number of people with an Ouya console and credit on file ready to make purchases"). Possibly if people had to quit the game, go to Discover, purchase the game, possibly wait for something to download, and then load the game up again and get back to my last checkpoint, some people wouldn't bother. They might go to the store and say "hey, there's 200 other demos here that I haven't tried out" and instead of paying for the game will just go play something else. And that's Ouya's thing - every game must provide a no-cost playable component. If purchases could not happen in game, I expect commercial game developers might have good reason to be scared of people just playing demos and not making purchases. So it is clear to me that this mandatory credit was deliberately enforced as a marketing factor above all else. In the context of a game console, I'm pretty happy with the Ouya. There have been a few surprises (such as the built-in track-pad on the controller which I only discovered by accident), and of course "Make" being right on the main menu where you can run your software builds from. Already I have more games on my Ouya then I have for my Wii-U. - From a free software perspective however, it's been somewhat of a letdown. Apparently, the boot-loader is locked. There was no reference on the device or in the printed documentation (that I noticed, anyway) to the source code, or the GPL etc. although everything does appear to have been dumped on GitHub. They may have released more code than any other major game console to date, but it's not as much as I had hoped for. These HackPad notes seem to have summed up nicely what Ouya meant by "Open"; "anyone can put games on there". https://randomfoo.hackpad.com/Ouya-Hacking-seqz2sKJfDR - -Adam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRz9vGAAoJEE2M/Tk0piBImIAIAKKIOQFk9yJJEiEX1dL/Anb+ p0QFiCXkiy3X75LQyyqkG/Kb/oDwOx8YcglQqa/+Gssw0lsexcBTmK7j3TYlgOyJ gC025kD5LwSUrP9nZ87ueLIE79hPx+m0dpJmkqYskWmdbn0fcxPsXAy6TIwS9NIY MZRvX7R45+vwHbqICp+B2Yw+E+zsdA/PMP/MS68aCIPcQPeoXpAd6f3Jgm+PewuG wZ5mWyQFSwrTTgUvQl9KuVBmcAL+SkbzGP38fk6B9LGKXlw81HhLm201L9tJ2+7K O2kGCpV28MC9/bU1zZhh0+Y3/KU6leSDc58JbOi8djL89e3uwLhVlnMxkj7+Bak= =ANrg -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Matt, On 30/06/13 17:35, Matt Giuca wrote:

Thanks for a clear and detailed summary of your Ouya experiences.

No worries. Right back at you.

It sucks that there are journalists going around saying that the Ouya is less restrictive than it actually is (for certain, apparently randomly selected, customers).

Yes. I have noticed this too. When I first turned on the device, there was a large firmware update that needed to be applied, so possibly in doing that it has changed the initial sign-up behavior for those of us who only very recently received our Ouya devices.

Fortunately, instead of a credit card, you also have the option of

...

using a pre-paid credit code. These were apparently available during pre-order, and can be brought from various places online. eg.

http://www.game.co.uk/en/ouya-10-credit-232744

So while some available credit must be verified (which I'm not defending - this aspect of the Ouya console sucks), it seems that you don't have to hand over your credit card to Ouya to store indefinitely if you don't want to.

But then I have to pay them more money up front (which I don't feel they deserve right now) and also wait for a physical card to be shipped internationally.

You're right. Hopefully cdkey-hut.com or some such will add Ouya support soon, so we can pay anonymously and without waiting on postage. Still would have to pay something up-front though.

I'm happier to get a general-purpose debit card. At least then I can use the credit elsewhere, not just on Ouya. There are cards that do not require opening a full bank account from Australia Post and Woolworths. I'm trying to decide which one is better. They both have some nasty drawbacks (like credit expiration and cancellation fees).

Interesting. I haven't looked into them, so know nothing about them.

I would definitely configure a PIN just in case I don't find myself mashing the "shoot" button and a dialog pops up and I accidentally mash the "Buy for $100" button.

I'm pretty sure that there isn't any game on Ouya at that price. From game.co.uk, "Every OUYA game is free to try, but unlocking the game, additional features or extra play time can cost between £1 to £20". I've been quite impressed with how cheap the games are priced at so far. Your point still stands though.

...

And that's Ouya's thing - every game must provide a no-cost playable component. If purchases could not happen in game, I expect commercial game developers might have good reason to be scared of people just playing demos and not making purchases. So it is clear to me that this mandatory credit was deliberately enforced as a marketing factor above all else.

Yeah. I get that, and it's a good "hook" for them, but I still want to be given the choice, as a consumer. Don't give me this bullshit about it being "more convenient" for me when you're forcing me to do it. Me having to spend a week researching debit cards is certainly not "more convenient".

Yep. "We're forcing you to do this because we know what's best, it's more convenient for everyone, and what's best for everyone is best for you too" is a shockingly unconvincing response by the Ouya crew. On second thoughts, perhaps the Ouya crew are correct - only they mean that it's more convenient *for them* to make us do this.

In the context of a game console, I'm pretty happy with the Ouya.

...

There have been a few surprises (such as the built-in track-pad on the controller which I only discovered by accident), and of course "Make" being right on the main menu where you can run your software builds from. Already I have more games on my Ouya then I have for my Wii-U.

- From a free software perspective however, it's been somewhat of a letdown. Apparently, the boot-loader is locked.

Really? That's not what their Kickstarter page says: "For hackers: root it. Go ahead. Your warranty is safe. Even the hardware is hackable."

Hmm.. perhaps that link is wrong. I found a forum thread which contradicts the previous link: http://forums.ouya.tv/discussion/1380/recovery-mode/ "The issue is not that the bootloader is locked... The issue is that there is no way to tell the bootloader to interrupt normal boot and enter fastboot mode. Devices usually have a hardware button combination to do this."

That's even more troubling if it isn't even possible to change the operating system if necessary.

So it looks like it's possible - it's just not easy, and not easy to recover from when things go bad. - -Adam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRz/BkAAoJEE2M/Tk0piBIN0sIAICJRbQ+X37TcRvp/yf/C+Rn aWT9rBXXlGn5h9vN+N6uEisLFnokJ8eb49wpJkGg9hNCNMGW1IP523MW2FTLRRWt QTJqTh0jkHpSi2USRkL0R6xuKTwbSWqjeACi0we3yDtiZTPb3AySOW0ekM/snSLE Fod7ixNVQRfZXrX7HUeJB636pkmdfbmRe9sIHn6bFZK+79MT6xc+crSf1ZnY0vlV yb2YQDRU/tsBeWD4VKNbrOctmk9ZOtl0CTxujwhPQYDcpP3pybj08oI+9UKEt1Ev VmR0+1qhI0tyRX8I6GVoeKt6hCHNMqTpeunraDLe/WEbf9uY0aoTCiXqyqdPces= =PVn4 -----END PGP SIGNATURE-----