Samsung Set To Open-Source Parts Of The Exynos

[droidhacker]

I can't understand why can't google require that in order to use the android brand, device manufacturers would have to mainline any code required in a google branch so that the updates come from google instead of these lazy greedy oems. This should probably make getting the newer android version working easier for the AOSP than it is right now right? And anything helping the android fragmentation should be good for google right? What is it that I'm missing?

Its called.... APACHE LICENSE.
Google did this in order to combat the perceived issue with OEM's being able to make their own modifications without releasing the source code for those. If Google didn't make this compromise in the license, Android wouldn't be the phenomenal success it is today. It would be right about where MS is.

[droidhacker]

Monthly releases are "for-absolutely-fucking-ever?" Over 2.5 million people use CyanogenMod. Do you honestly think they "break almost everything"?

It took them the better part of a YEAR to move on to AOSP 4.

You say CyanogenMod "bastardizes" AOSP, but it is really fairly close to AOSP. There are some added options to allow users to customize their device but they keep it down to a reasonable and usable amount.

It is nothing but a MASSIVE pile of broken bloat. Go read the source if you don't believe me. What they have BARELY resembles AOSP.

Beyond this, the primary changes to AOSP are for compatibility of the 100+ devices that CyanogenMod supports.

AOSP doesn't require any changes for device compatibility.

CyanogenMod supports almost every major SoC architecture in one code base and it honestly does it very well, this is something that neither Google or the major OEMs do.
It is great that you build AOSP for your devices but don't act like CyanogenMod and others do nothing of value for the community.

They barely touch anything at all at the hardware level. They do NOT do anything valuable. They BREAK AOSP. They add pointless graphics. They pretend that what they release is somehow THEIRS when the only FUNCTIONAL parts are copied verbatim from AOSP.

Back to what was originally brought up about CyanogenMod, I don't think Samsung is releasing more source code *just* because of CyanogenMod or other 3rd party distributions of Android. That said, I do think Samsung at least cares about that community to some degree because they made this announcement at a small Android enthusiast conference made up largely of AOSP hackers. In addition, Samsung has also been making a concerted effort to reach out to AOSP hackers through forums and other means. At the end of the day Samsung is really just getting up to the standard of what TI and Qualcomm do with OMAPZoom and Code Aurora respectively.

Samsung *might* be providing this to respect their customers. They aren't doing anything for AOSP bastardizers.

[Figueiredo]

WTF is a "valleyview"?

Valley View is intel's next gen Atom SoC with an Ivy Brigde class GPU instead of a PowerVR one. There is already plenty of support for Valley View in mesa and it should be pretty well supported when it is lauched at the end of next year:

http://www.phoronix.com/scan.php?pag...tem&px=MTA3NDc

http://www.anandtech.com/show/6203/d...ridge-graphics

Seems like every android user's wet dream since you do not depend on the odm for anything in order to support android updates. Unless there is some other component which still requires closed drivers. Is there?

[droidhacker]

I could definitely see this being useful in a hypothetical Chromebook CM10/11, and if Android on netbooks turns out to make sense, enthusiasts can get another taste of the future (much like the Nook Color + CM7 hinted at the Nexus 7, i.e. an affordable real android tablet, a year later)

The upside of 'fragmentation' is that such avenues can be explored... unlike, say, being completely unable to port Windows on ARM to one of those little Chinese stick computers. A $100-150 one with Windows and Office might've just saved the Windows desktop from seeming irrelevant, but we'll probably never know.

Chinese stick computers won't be running microshit because their products would end up banned in markets where balmer still has any influence, in particular, the US and Europe. Chinese computer companies DO NOT PURCHASE rights to software. They use Android because it is offered FOR FREE. Before Android, the Chinese phone-clone makers had terrible proprietary Chinese firmware, or software that was downright STOLEN. Since Android, the Chinese "cloners" have been approaching legitimacy since they have been able to offer an economical and POWERFUL platform, and have been able to escape the need to make *visual* clones of things like apple. Now they're focusing on producing FUNCTIONAL hardware and offering it with world-class software for discount prices.

[Figueiredo]

Its called.... APACHE LICENSE.
Google did this in order to combat the perceived issue with OEM's being able to make their own modifications without releasing the source code for those. If Google didn't make this compromise in the license, Android wouldn't be the phenomenal success it is today. It would be right about where MS is.

Ok, but that only applies to the userspace. The kernel itself, which seems to be the most important part in supporting devices has a GPL licence, so the code is out there, or at least should be, it's just a matter of getting everthing in the same branch in order to have a proper distribution supporting multiple devices, like we currently have in GNU/Linux. Unless I'm missing something.

[droidhacker]

Valley View is intel's next gen Atom SoC with an Ivy Brigde class GPU instead of a PowerVR one. There is already plenty of support for Valley View in mesa and it should be pretty well supported when it is lauched at the end of next year:

http://www.phoronix.com/scan.php?pag...tem&px=MTA3NDc

http://www.anandtech.com/show/6203/d...ridge-graphics

Seems like every android user's wet dream since you do not depend on the odm for anything in order to support android updates. Unless there is some other coponent which still requires closed drivers. Is there?

I have a few kiosks running Android on Intel hardware, and they work quite nicely as 100% open software. To be honest though, I would rather go with AMD since they haven't burned me in the past, and have good hardware available NOW. I wouldn't touch anything x86 for something highly portable though. I'm about to pull the trigger on a new Samsung w/Snapdragon S4 (2xKrait+Adreno225), and I'm already way past the tablet fad, netbooks and phones are both a million times more practical. I see tablets as the inconvenience of a touch-only phone with the inconvenient size of a netbook (or even worse/bigger).

[droidhacker]

Ok, but that only applies to the userspace. The kernel itself, which seems to be the most important part in supporting devices has a GPL licence, so the code is out there, or at least should be, it's just a matter of getting everthing in the same branch in order to have a proper distribution supporting multiple devices, like we currently have in GNU/Linux. Unless I'm missing something.

Well, Google doesn't have the authority to enforce much in terms of the kernel. Linus et al have expressed on many occasions, their distaste with the way things go with the ARM kernels.

At least the Android parts are back in at kernel.org.

I, too, have experienced a distasteful situation when it comes to ARM kernels. In particular, the "source" drops made by phone manufacturers, are DESIGNED to be nightmares. What you would hope for is a concise patch against some upstream kernel version. What you get is a full kernel tree that has been patched against a mishmash of multiple versions of upstream kernel, making it near impossible to separate the customizations based on upstream kernel version.

[Figueiredo]

I have a few kiosks running Android on Intel hardware, and they work quite nicely as 100% open software. To be honest though, I would rather go with AMD since they haven't burned me in the past, and have good hardware available NOW. I wouldn't touch anything x86 for something highly portable though. I'm about to pull the trigger on a new Samsung w/Snapdragon S4 (2xKrait+Adreno225), and I'm already way past the tablet fad, netbooks and phones are both a million times more practical. I see tablets as the inconvenience of a touch-only phone with the inconvenient size of a netbook (or even worse/bigger).

I agree with you. Current tablets aren't my cup of tea. A netbook/tablet thingie running a fullblown OS (much like x86 surface) would be much better. I don't care if the SoC is behind the screen of behind the keyboard.

But intel's 32nm 2 GHz atom is already on phones:

http://www.anandtech.com/show/6307/m...powered-razr-i

So I expect that a 22 nm variant much more competent at supporting android would be a no-brainer. I would love to see an tablet/netbook with an AMD SoC, but they can't properly support GNU/Linux, much less android, so the only alternative for them is windows.

[Figueiredo]

Well, Google doesn't have the authority to enforce much in terms of the kernel. Linus et al have expressed on many occasions, their distaste with the way things go with the ARM kernels.

At least the Android parts are back in at kernel.org.

I, too, have experienced a distasteful situation when it comes to ARM kernels. In particular, the "source" drops made by phone manufacturers, are DESIGNED to be nightmares. What you would hope for is a concise patch against some upstream kernel version. What you get is a full kernel tree that has been patched against a mishmash of multiple versions of upstream kernel, making it near impossible to separate the customizations based on upstream kernel version.

Google cannot force phone manufacturers to mainline their kernel code, but it can prevent them from using the android trademark if they don't, see the difference? So the fact is that google is not trying that hard to avoid the current mess.

Thinking about it, maybe that's just what what google is planning to do with their multiple nexus strategy. They might create a comprehensive line of nexus devices with their code mainlined, differenciated from the rest of the android devices. That way, if you don't buy a nexus device, it would be your own fault to be stuck with a upgradeless device. One can only hope...

[droidhacker]

Google cannot force phone manufacturers to mainline their kernel code, but it can prevent them from using the android trademark if they don't, see the difference? So the fact is that google is not trying that hard to avoid the current mess.

That is not actually correct. Google placed their trademark *within the code*, which is licensed APL. As long as it is used as an identifier for that code, there is not a single thing that Google can do to stop it. If somebody used it in reference to an operating system that is NOT ANDROID, only then would Google be able to create legal problems.

Thinking about it, maybe that's just what what google is planning to do with their multiple nexus strategy. They might create a comprehensive line of nexus devices with their code mainlined, differenciated from the rest of the android devices. That way, if you don't buy a nexus device, it would be your own fault to be stuck with a upgradeless device. One can only hope...

"Nexus" *does* happen to be a trademark that they can actually restrict use of. However, it doesn't mean a whole lot -- in fact, it has no meaning AT ALL with respect to upgrades. All it actually means is that it is "google approved".

It is a terrible misconception that there is some advantage to "nexus" devices when it comes to software upgrades. Nexus 1 is out in the cold already (despite being perfectly capable of running AOSP 4.1.2), those associated with the US CDMA networks are late and unreliable when it comes to upgrades.