Also, (I unfortunately can't find the link at the moment, but it was on the Tizen mailing lists a few months ago) - While Samsung technically has "partners" in the Tizen project, the reality is, "We are Samsung, we do what we want."
On the opposite end, Android as Google envisions it is far more open. Unfortunately, as a compromise to get some manufacturers on board, most of the HALs are Apache-licensed, so manufacturers (especially Samsung) can mangle the hell out of them and not document what they did, making AOSP-derived firmwares on some devices nearly impossible.
Anyone who thinks Samsung is a champion of openness is completely and totally ignorant of how they have behaved towards the open source community over the past year or two.
Other than the "ultrapixel" marketing bullshit - a lower resolution camera IS better at the sensor sizes of mobile devices.
There's a reason Canon dropped from 14 to 10 going from the G10 to G11 (or was it G9 to G10?) - yes, they DROPPED resolution in their flagship P&S.
It's well known to experienced photographers that more pixels = less area per pixel = lower dynamic range (more noise) per pixel, especially in low light.
Especially since there's a fixed amount of "overhead" per pixel taking up sensor area - as the pixels are packed more densely, that overhead becomes a higher percentage of the sensor area that is wasted.
10+ megapixels, even 8, is simply way too much for the sensor size of mobile devices. A mobile device with 75% of the pixel count of a DSLR but only 25% or less of the physical sensor area = guaranteed to be shit in anything but sunlight.
Yup. That's the thing that kills nearly every MMO that has attempted to compete with WoW - bugs and launch performance issues.
If you have performance issues on launch, you are doomed to fail if there is any viable competition out there, the initial experience will poison people's minds. If you DO have launch problems - you HAVE to resolve them before that first free month is up. If you don't - A ton of people are going to leave and not give you a second chance.
As I understand it, WoW had some initial launch problems, but: 1) Were resolved within the first month 2) Didn't have much viable competition out there - now everyone has to compete with well established competitors.
Aion had potential - but it had LOTS of initial problems that weren't solved until after much of their playerbase quit. They refused to provision additional servers with the end result being 2-3 hour queue times... Their reasoning was they didn't want to do a merge down the line. Yes, that's right, they PLANNED TO FAIL.
Same with Warhammer Online - It had potential, but the lag and game balance issues weren't resolved in the first month. End result: dead game.
Actually, many of us are quite responsible with our data. I don't think any of us support the "I HAVE A RIGHT TO EAT 20GB OF DATA PER MONTH OVER A CONNECTION THAT WASN'T DESIGNED TO HANDLE THAT!" crowd. Let's face it, if you're in that crowd, your days are numbered and few people will have sympathy for you.
My average monthly usage is around 500MB. I stay on unlimited only because I like having that "safety net" of not getting charged insane amounts if my device flakes out on me.
I still remember around that time having to call Verizon and get a *new fucking number* when I spent the summer in New Jersey. Then *another fucking new number* when I moved back to New York for my senior year of college. *yet another fucking number* when I moved back to NJ in 2002. I think it was shortly thereafter that you could finally get a real nationwide plan.
That said, in 2006, Verizon was unable to make changes to my plan because I was living in New York but had a New Jersey number. Funny thing - throughout grad school, they added data plans without my permission no less than three times. Once I was employed and had income PLUS eligibility for a 25% discount through my employer - the idiots couldn't figure out how to add data to my plan.
I left for AT&T in late 2006 or 2007 (can't remember...) and never looked back. While I'm going to leave AT&T soon for Straight Talk, I will NEVER again consider Verizon. Especially not after seeing their "we own your phone, you do not" hijinks in 2012.
Verizon is the only network worse than AT&T... Verizon pulls the same "must pay for a data plan on a smartphone" shit (they added data to my Treo 600 no less than THREE TIMES without my permission...)
On top, they're even worse than AT&T in terms of mangling their devices and locking them down. With AT&T, you can at least bring a device to their network that AT&T had no involvement with whatsoever. With Verizon, your ONLY choices are devices in their ESN whitelist database - which means only phones approved (read: crippled) by Verizon.
As much as I hate AT&T, I'll take them over Verizon any day of the week. With AT&T, at least I can own my own device. (That said, I'm switching to Straight Talk no-contract once my AT&T contract is up. Same network, less bullshit.)
This sort of shit is exactly why I'm going to no-contract service with Straight Talk when my contract is up.
Yes, I know ST is heavily affiliated with and/or owned by Wal-Mart - but as evil as Wal-Mart is, they understand that good business involves not treating the customer like shit. They're nothing compared to the Deathstar Network in terms of douchebaggery.
To be honest, Windows Mobile 6.x was decent for power users. Of course, once Android hit, it quickly became overshadowed, but WM6.x did have a reasonably good core market.
The problem is, Microsoft utterly threw away the entirety of that market with WP7. They went from an OS popular with power users to one that catered to the tech inexperienced.
It seems like a great approach, except when you have a well established competitor that is targeting the EXACT same market. With a company as well established as Apple, you are going to fail if you target the exact same market segment and use the exact same development model (pay-to-play).
How did Android succeed? They targeted the casual user in a way that didn't drive away the power user... They did an excellent job of stealing pretty much the entirety of Microsoft's WM6.x user base, because WP7 had none of WM6.x's redeeming qualities. Some might say that early Android revisions targeted the power user more than the casual user - which is actually a good way to flesh out your platform initially and gain developer mindshare.
Then Google did the one thing that was critical to being able to compete with Apple - they dropped the barriers to entry into Android development as low as they could possibly go.
The end result: Apple - High barriers to entry for developers (must have a MacOS machine, $99/year) but high reward (large userbase) - Pretty obviously a valid choice Google - Absurdly low barriers to entry for developers (no fees for application development, development environments for all major desktop platforms) but questionable reward (low userbase initially) - Why not, what do you have to lose other than time? Microsoft - Only slightly lower barriers to entry for developers, low userbase - Why bother?
Now that Google' userbase is much larger, Microsoft's position is even poorer.
Software can do it if it causes low-level data corruption in a component.
It's amazing how many things in modern systems have internal firmware these days. For example, any eMMC flash chip (found in many smartphones) has internal firmware that handles wear levelling algorithms and such.
Samsung's 2011 smarphones were rather notorious for containing eMMC chips that were not JEDEC compliant - if you issued a secure erase command to the chip, it had a very good chance of corrupting the wear leveller's internal state. This would render the eMMC chip mostly inoperable (this failure mode was nicknamed "Superbrick" for the fact that it couldn't be recovered via JTAG). If you corrupted the firmware itself somehow (which apparently happened more than 50% of the time if an attempt was made to update/reset it according to Samsung engineers...), it would render it fully inoperable and effectively dead.
The previous guy commenting about "sabotaging free software" got marked as a troll... But this is pretty similar to a major eMMC firmware bug present in many of Samsung's phones manufactured in 2011.
The eMMC flash chip is NOT JEDEC compliant, and the wear leveller can go out into la-la-land if you issue a secure erase command to the chip.
Starting with ICS, Google started performing eMMC erase when wiping data in recovery for privacy reasons. This would kill Samsung flash chips.
In the Galaxy Nexus, Google forced Samsung to fix the damn chip with an internal firmware update.
However, in other devices, Samsung worked around it in two ways: 1) Disabling MMC_CAP_ERASE in I9100 kernels for a while 2) Replacing secure erase with nonsecure erase and not documenting this anywhere
Without the assistance of an engineer from Google (whom Samsung later tried to silence as far as I can tell) providing critical information, the opensource community would have been fucked.
In late August/early September, they submitted a patch to the Linux kernel to work around the issue at a kernel level - It was merged to mainline on September 4.
In early October, they released an update for Sprint devices WITHOUT THE FIX. "testing takes time" is an invalid excuse, as the build date for Sprint FI27 was September 27, 2011 - Almost a MONTH after the patch had been mainlined. The patch is very easy to backport to their I9100 kernel source baseline, so there is no excuse for this.
As a result, I still get PMs on XDA once or twice a week due to people accidentally digging up userspace binaries that perform secure erase. This shouldn't be an issue, as it is the kernel's responsibility to protect hardware from getting damaged by userspace. Samsung's position was that it was an "open source problem" and hence refused to fix it in the end.
Now that the exynos-abuse vulnerability is known and an exploit has been published, it's not an open source problem any more - Anyone who has not yet received an update to patch the exynos-abuse hole is dependent on this planet, out of 7 billion people, not having a SINGLE asshat who decides they want to permanently destroy a few Samsung devices. Even if exynos-abuse is patched, as long as the kernel still allows secure erase commands through, any other privilege escalation exploits will endanger devices again. Despite this, Samsung released an update for Sprint devices (FL24) at the end of December 2012 that *did not contain any protection against this issue in the kernel*
So yeah, Samsung wishes free software would go away - they claim otherwise, and make promises that they care and are trying to fix things, but they never deliver on such promises. Actions speak louder than words, and Samsung's actions send a pretty clear message to open source software - "fuck off and die".
(I won't even go into Samsung's constant and incessant GPL violations here... But it's incredibly rare for any Samsung source drop to correspond to any existing firmware release for a given device. When asked about this inconsistency, Samsung will claim that the firmware that came preinstalled on the device you purchased on launch day at Best Buy is a "leak" and thus they do not need to provide source that matches it.)
Read Dianne Hackborn's comments in the G+ thread linked from the article you posted. Her first comment is pretty high level, later on she goes into deeper detail about exactly how it breaks the CDD/CTS.
You'll also see a comment from Steve that says what I said above but in a different way: "CM does pass the CTS, but not in any official context. For that, you need to have hardware to go with your software." - In short, CM can pass the tests, but to actually get certified, a complete system (hardware/software) must go through official/formal testing with Google's cooperation.
The most relevant part, eventually, is: "Ultimately here is what we would probably tell anyone wanting to ship this modification with Market (which would need a compatibility exception because as we both agree it is not entirely compatible with the CDD/CTS): all existing apps must run on a screen that never changes in size, which is compatible with the sizes specified by the CDD. This means for you probably all existing apps running full-screen (you could probably have your panels slide out on top of them as long as they don't impact the display size seen by the app). You can have a custom API for applications to opt in to your experience (for example a meta-data tag in their manifest), but they must explicitly opt in to any such changes in behavior, and not by you assuming they might work because they support both landscape and portrait." This is what Samsung did - except instead of by using a custom API for apps to opt-in, Samsung hardcoded a whitelist into the framework.
Sorry, it just doesn't work that way. Users are stupid. CM could put all the disclaimers it wants - if Cornerstone caused app breakage, users would leave unfair 1-star reviews on the Play Store.
Wrong. The "not bundled with a device" is why CM has not FORMALLY had the CTS run against it.
HOWEVER: Cornerstone would have GUARANTEED a CTS failure if CM with Cornerstone had been put through a formal CTS run. If something is GUARANTEED to cause CTS to fail if it were to be run, it is justification for Google to attempt to blacklist CM from the Play Store.
There's a difference between "has not passed CTS because it hasn't been formally run" and "could not possibly, under any means, pass CTS".
CM is currently in the former state, and Google is OK with this. CM with Cornerstone would have been in the latter category, which Google is NOT OK with.
Samsung's APIs are usually shit. You wouldn't believe the horrific rottenness one finds when you start digging through their implementations of Android...
There was a company (Onskreen) working on a multiwindow implementation (Cornerstone) long before Samsung pushed this out. It was killed for a variety of reasons, the primary being application compatibility issues.
One valid question would be: Did they accidentally post something related to the beta in a public discussion forum instead of the private one related to the game?
One thing you forget is the atrocious anti-GPL licensing clauses of TI's StellarisWare libraries. Those are why most of my TI dev boards have been collecting dust for a year or two now...
Most of my microcontroller projects are licensed under the GPL, and TI's libraries are so GPL-incompatible that they explicitly call it out as incompatible with some VERY nasty language. So to work with TI's chips I need to completely start from scratch.
If you buy an Arduino with a socketed DIP AVR, most of that board's reason to exist goes away.
Plus I've done about half the things in that list of "ways to destroy an AVR" without destroying it.........
Oh yeah, they forgot "plug the chip in backwards so the power supply is completely reversed". Well, actually, they didn't since that won't kill most AVRs, although if you're using a solderless breadboard, it'll melt the breadboard's plastic underneath the chip. Yes, I did that in my first microcontrollers class in school - killed a breadboard, unplugged the chip, rotated it the correct way, plugged it into another breadboard, it worked perfectly.
Arduino hardware provides a great starting point for AVR work. It's the best way to get a variety of cheap AVR dev boards.
However, rather than use the Arduino IDE, I strongly suggest avr-gcc - the initial learning curve is a bit steeper, but you gain a lot of long-term flexibility.
Most importantly, if you learn using avr-gcc, you can more easily migrate designs to AVR variants that aren't supported by the Arduino environment well or at all. For example, if you have a very basic project that can fit in a Tiny85 - it's fairly easy to migrate something you prototyped on a Mega168/328 down to that if you're using AVR-GCC. If you're using the Arduino environment, it's extremely difficult if not impossible.
(And yes, I know that the Arduino IDE is layered on top of avr-gcc - but when dealing with a microcontroller, all those extra layers of abstraction are counterproductive in the long run.)
Slashdot Mirror
https://lists.tizen.org/pipermail/general/2012-October/001068.html
Also, (I unfortunately can't find the link at the moment, but it was on the Tizen mailing lists a few months ago) - While Samsung technically has "partners" in the Tizen project, the reality is, "We are Samsung, we do what we want."
Aaaah - found the link - https://lists.tizen.org/pipermail/general/2012-October/001061.html
Also, apparently their kernel repo has commit history obliterated - https://lists.tizen.org/pipermail/product-dev/2012-November/000100.html
On the opposite end, Android as Google envisions it is far more open. Unfortunately, as a compromise to get some manufacturers on board, most of the HALs are Apache-licensed, so manufacturers (especially Samsung) can mangle the hell out of them and not document what they did, making AOSP-derived firmwares on some devices nearly impossible.
Anyone who thinks Samsung is a champion of openness is completely and totally ignorant of how they have behaved towards the open source community over the past year or two.
CM10.1 nightlies for a device released last spring just starting now is nothing to be proud of.
S-ON bullshit plus rampant GPL noncompliance = HTCs suck to work with for developers.
Samsungs with Exynos chipsets aren't much better... All of the Exynos maintainers have switched to Sony.
Other than the "ultrapixel" marketing bullshit - a lower resolution camera IS better at the sensor sizes of mobile devices.
There's a reason Canon dropped from 14 to 10 going from the G10 to G11 (or was it G9 to G10?) - yes, they DROPPED resolution in their flagship P&S.
It's well known to experienced photographers that more pixels = less area per pixel = lower dynamic range (more noise) per pixel, especially in low light.
Especially since there's a fixed amount of "overhead" per pixel taking up sensor area - as the pixels are packed more densely, that overhead becomes a higher percentage of the sensor area that is wasted.
10+ megapixels, even 8, is simply way too much for the sensor size of mobile devices. A mobile device with 75% of the pixel count of a DSLR but only 25% or less of the physical sensor area = guaranteed to be shit in anything but sunlight.
Yup. That's the thing that kills nearly every MMO that has attempted to compete with WoW - bugs and launch performance issues.
If you have performance issues on launch, you are doomed to fail if there is any viable competition out there, the initial experience will poison people's minds. If you DO have launch problems - you HAVE to resolve them before that first free month is up. If you don't - A ton of people are going to leave and not give you a second chance.
As I understand it, WoW had some initial launch problems, but:
1) Were resolved within the first month
2) Didn't have much viable competition out there - now everyone has to compete with well established competitors.
Aion had potential - but it had LOTS of initial problems that weren't solved until after much of their playerbase quit. They refused to provision additional servers with the end result being 2-3 hour queue times... Their reasoning was they didn't want to do a merge down the line. Yes, that's right, they PLANNED TO FAIL.
Same with Warhammer Online - It had potential, but the lag and game balance issues weren't resolved in the first month. End result: dead game.
Yup. Not having to worry about power-to-weight ratio can help you get MAJOR improvements in both efficiency AND emissions controls.
There's also the fact that while we're not anywhere close to 100% nuclear, we do have a decent amount of nuclear (and other non-coal) power installed.
A grid-powered EV is a win even on a 100% coal-powered grid. It's significantly more so in our current mixed-power grid.
Actually, many of us are quite responsible with our data. I don't think any of us support the "I HAVE A RIGHT TO EAT 20GB OF DATA PER MONTH OVER A CONNECTION THAT WASN'T DESIGNED TO HANDLE THAT!" crowd. Let's face it, if you're in that crowd, your days are numbered and few people will have sympathy for you.
My average monthly usage is around 500MB. I stay on unlimited only because I like having that "safety net" of not getting charged insane amounts if my device flakes out on me.
I know a few of the XDA admins are on ST and love it, and more are hopping over.
I have yet to talk to a user of their BYOD SIM plans that was unhappy in any way.
Solution: Buy from an MVNO that is a dumb pipe. Straight Talk's BYOD SIM plans are proving quite popular.
Nexus 4 from the Play Store + Straight Talk = device you control hooked up to a dumb pipe.
I still remember around that time having to call Verizon and get a *new fucking number* when I spent the summer in New Jersey. Then *another fucking new number* when I moved back to New York for my senior year of college. *yet another fucking number* when I moved back to NJ in 2002. I think it was shortly thereafter that you could finally get a real nationwide plan.
That said, in 2006, Verizon was unable to make changes to my plan because I was living in New York but had a New Jersey number. Funny thing - throughout grad school, they added data plans without my permission no less than three times. Once I was employed and had income PLUS eligibility for a 25% discount through my employer - the idiots couldn't figure out how to add data to my plan.
I left for AT&T in late 2006 or 2007 (can't remember...) and never looked back. While I'm going to leave AT&T soon for Straight Talk, I will NEVER again consider Verizon. Especially not after seeing their "we own your phone, you do not" hijinks in 2012.
Verizon is the only network worse than AT&T... Verizon pulls the same "must pay for a data plan on a smartphone" shit (they added data to my Treo 600 no less than THREE TIMES without my permission...)
On top, they're even worse than AT&T in terms of mangling their devices and locking them down. With AT&T, you can at least bring a device to their network that AT&T had no involvement with whatsoever. With Verizon, your ONLY choices are devices in their ESN whitelist database - which means only phones approved (read: crippled) by Verizon.
As much as I hate AT&T, I'll take them over Verizon any day of the week. With AT&T, at least I can own my own device. (That said, I'm switching to Straight Talk no-contract once my AT&T contract is up. Same network, less bullshit.)
This sort of shit is exactly why I'm going to no-contract service with Straight Talk when my contract is up.
Yes, I know ST is heavily affiliated with and/or owned by Wal-Mart - but as evil as Wal-Mart is, they understand that good business involves not treating the customer like shit. They're nothing compared to the Deathstar Network in terms of douchebaggery.
To be honest, Windows Mobile 6.x was decent for power users. Of course, once Android hit, it quickly became overshadowed, but WM6.x did have a reasonably good core market.
The problem is, Microsoft utterly threw away the entirety of that market with WP7. They went from an OS popular with power users to one that catered to the tech inexperienced.
It seems like a great approach, except when you have a well established competitor that is targeting the EXACT same market. With a company as well established as Apple, you are going to fail if you target the exact same market segment and use the exact same development model (pay-to-play).
How did Android succeed? They targeted the casual user in a way that didn't drive away the power user... They did an excellent job of stealing pretty much the entirety of Microsoft's WM6.x user base, because WP7 had none of WM6.x's redeeming qualities. Some might say that early Android revisions targeted the power user more than the casual user - which is actually a good way to flesh out your platform initially and gain developer mindshare.
Then Google did the one thing that was critical to being able to compete with Apple - they dropped the barriers to entry into Android development as low as they could possibly go.
The end result:
Apple - High barriers to entry for developers (must have a MacOS machine, $99/year) but high reward (large userbase) - Pretty obviously a valid choice
Google - Absurdly low barriers to entry for developers (no fees for application development, development environments for all major desktop platforms) but questionable reward (low userbase initially) - Why not, what do you have to lose other than time?
Microsoft - Only slightly lower barriers to entry for developers, low userbase - Why bother?
Now that Google' userbase is much larger, Microsoft's position is even poorer.
Software can do it if it causes low-level data corruption in a component.
It's amazing how many things in modern systems have internal firmware these days. For example, any eMMC flash chip (found in many smartphones) has internal firmware that handles wear levelling algorithms and such.
Samsung's 2011 smarphones were rather notorious for containing eMMC chips that were not JEDEC compliant - if you issued a secure erase command to the chip, it had a very good chance of corrupting the wear leveller's internal state. This would render the eMMC chip mostly inoperable (this failure mode was nicknamed "Superbrick" for the fact that it couldn't be recovered via JTAG). If you corrupted the firmware itself somehow (which apparently happened more than 50% of the time if an attempt was made to update/reset it according to Samsung engineers...), it would render it fully inoperable and effectively dead.
The previous guy commenting about "sabotaging free software" got marked as a troll... But this is pretty similar to a major eMMC firmware bug present in many of Samsung's phones manufactured in 2011.
The eMMC flash chip is NOT JEDEC compliant, and the wear leveller can go out into la-la-land if you issue a secure erase command to the chip.
Starting with ICS, Google started performing eMMC erase when wiping data in recovery for privacy reasons. This would kill Samsung flash chips.
In the Galaxy Nexus, Google forced Samsung to fix the damn chip with an internal firmware update.
However, in other devices, Samsung worked around it in two ways:
1) Disabling MMC_CAP_ERASE in I9100 kernels for a while
2) Replacing secure erase with nonsecure erase and not documenting this anywhere
Without the assistance of an engineer from Google (whom Samsung later tried to silence as far as I can tell) providing critical information, the opensource community would have been fucked.
Eventually, Samsung claimed they were "working hard" on the issue in early June 2012 - http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/
A month later, in early July, they added MMC_CAP_ERASE to I9100 kernels without providing even the slightest warning - Within a day, a pile of bricks showed up:
http://forum.xda-developers.com/showthread.php?t=1756242
In late August/early September, they submitted a patch to the Linux kernel to work around the issue at a kernel level - It was merged to mainline on September 4.
In early October, they released an update for Sprint devices WITHOUT THE FIX. "testing takes time" is an invalid excuse, as the build date for Sprint FI27 was September 27, 2011 - Almost a MONTH after the patch had been mainlined. The patch is very easy to backport to their I9100 kernel source baseline, so there is no excuse for this.
As a result, I still get PMs on XDA once or twice a week due to people accidentally digging up userspace binaries that perform secure erase. This shouldn't be an issue, as it is the kernel's responsibility to protect hardware from getting damaged by userspace. Samsung's position was that it was an "open source problem" and hence refused to fix it in the end.
Now that the exynos-abuse vulnerability is known and an exploit has been published, it's not an open source problem any more - Anyone who has not yet received an update to patch the exynos-abuse hole is dependent on this planet, out of 7 billion people, not having a SINGLE asshat who decides they want to permanently destroy a few Samsung devices. Even if exynos-abuse is patched, as long as the kernel still allows secure erase commands through, any other privilege escalation exploits will endanger devices again. Despite this, Samsung released an update for Sprint devices (FL24) at the end of December 2012 that *did not contain any protection against this issue in the kernel*
So yeah, Samsung wishes free software would go away - they claim otherwise, and make promises that they care and are trying to fix things, but they never deliver on such promises. Actions speak louder than words, and Samsung's actions send a pretty clear message to open source software - "fuck off and die".
(I won't even go into Samsung's constant and incessant GPL violations here... But it's incredibly rare for any Samsung source drop to correspond to any existing firmware release for a given device. When asked about this inconsistency, Samsung will claim that the firmware that came preinstalled on the device you purchased on launch day at Best Buy is a "leak" and thus they do not need to provide source that matches it.)
Read Dianne Hackborn's comments in the G+ thread linked from the article you posted. Her first comment is pretty high level, later on she goes into deeper detail about exactly how it breaks the CDD/CTS.
https://plus.google.com/100275307499530023476/posts/ViCME1bb8F6 for the lazy (can't directly link to a comment though...)
You'll also see a comment from Steve that says what I said above but in a different way: "CM does pass the CTS, but not in any official context. For that, you need to have hardware to go with your software." - In short, CM can pass the tests, but to actually get certified, a complete system (hardware/software) must go through official/formal testing with Google's cooperation.
The most relevant part, eventually, is:
"Ultimately here is what we would probably tell anyone wanting to ship this modification with Market (which would need a compatibility exception because as we both agree it is not entirely compatible with the CDD/CTS): all existing apps must run on a screen that never changes in size, which is compatible with the sizes specified by the CDD. This means for you probably all existing apps running full-screen (you could probably have your panels slide out on top of them as long as they don't impact the display size seen by the app). You can have a custom API for applications to opt in to your experience (for example a meta-data tag in their manifest), but they must explicitly opt in to any such changes in behavior, and not by you assuming they might work because they support both landscape and portrait."
This is what Samsung did - except instead of by using a custom API for apps to opt-in, Samsung hardcoded a whitelist into the framework.
Sorry, it just doesn't work that way. Users are stupid. CM could put all the disclaimers it wants - if Cornerstone caused app breakage, users would leave unfair 1-star reviews on the Play Store.
Wrong. The "not bundled with a device" is why CM has not FORMALLY had the CTS run against it.
HOWEVER: Cornerstone would have GUARANTEED a CTS failure if CM with Cornerstone had been put through a formal CTS run. If something is GUARANTEED to cause CTS to fail if it were to be run, it is justification for Google to attempt to blacklist CM from the Play Store.
There's a difference between "has not passed CTS because it hasn't been formally run" and "could not possibly, under any means, pass CTS".
CM is currently in the former state, and Google is OK with this. CM with Cornerstone would have been in the latter category, which Google is NOT OK with.
Samsung's APIs are usually shit. You wouldn't believe the horrific rottenness one finds when you start digging through their implementations of Android...
There was a company (Onskreen) working on a multiwindow implementation (Cornerstone) long before Samsung pushed this out. It was killed for a variety of reasons, the primary being application compatibility issues.
Well then that just isn't kosher.
One valid question would be: Did they accidentally post something related to the beta in a public discussion forum instead of the private one related to the game?
One thing you forget is the atrocious anti-GPL licensing clauses of TI's StellarisWare libraries. Those are why most of my TI dev boards have been collecting dust for a year or two now...
Most of my microcontroller projects are licensed under the GPL, and TI's libraries are so GPL-incompatible that they explicitly call it out as incompatible with some VERY nasty language. So to work with TI's chips I need to completely start from scratch.
If you buy an Arduino with a socketed DIP AVR, most of that board's reason to exist goes away.
Plus I've done about half the things in that list of "ways to destroy an AVR" without destroying it.........
Oh yeah, they forgot "plug the chip in backwards so the power supply is completely reversed". Well, actually, they didn't since that won't kill most AVRs, although if you're using a solderless breadboard, it'll melt the breadboard's plastic underneath the chip. Yes, I did that in my first microcontrollers class in school - killed a breadboard, unplugged the chip, rotated it the correct way, plugged it into another breadboard, it worked perfectly.
AVRs are incredibly robust.
avr-gcc is "production ready" for AVR. In fact I believe Atmel's own official development tools use avr-gcc at the core.
Same for most ARM microcontrollers - all of these have "production-ready" gcc toolchains.
Yup. My personal preference:
Arduino hardware provides a great starting point for AVR work. It's the best way to get a variety of cheap AVR dev boards.
However, rather than use the Arduino IDE, I strongly suggest avr-gcc - the initial learning curve is a bit steeper, but you gain a lot of long-term flexibility.
Most importantly, if you learn using avr-gcc, you can more easily migrate designs to AVR variants that aren't supported by the Arduino environment well or at all. For example, if you have a very basic project that can fit in a Tiny85 - it's fairly easy to migrate something you prototyped on a Mega168/328 down to that if you're using AVR-GCC. If you're using the Arduino environment, it's extremely difficult if not impossible.
(And yes, I know that the Arduino IDE is layered on top of avr-gcc - but when dealing with a microcontroller, all those extra layers of abstraction are counterproductive in the long run.)