Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Android Intel Open Source Operating Systems Linux

Intel Builds On Top of Android, But Hedges On Open-Sourcing Improvements 156

Barence writes with this news as carried by PC Pro: "Intel claims it is making significant improvements to the multicore performance of Android — but isn't sure if it's willing to share them with the open-source community. Speaking to journalists in London, Intel's mobile chief Mike Bell said that Intel's engineers were making significant improvements to Android's scheduler to improve its multicore performance. 'Android doesn't make as effective use of multicore as it could,' he said. However, when pressed by PC Pro on whether those improvements would be shared with the open-source community and Intel's competitors, Bell remained non-committal. 'Where we are required to give back to open source, we do,' said Bell. 'In cases where it's not required to be open source, I'm going to think about it. I don't like doing R&D for competitors if they're not going to contribute themselves,' said Bell, before adding that 'in general, our philosophy is to give things back.'"
This discussion has been archived. No new comments can be posted.

Intel Builds On Top of Android, But Hedges On Open-Sourcing Improvements

Comments Filter:
  • by Metabolife ( 961249 ) on Thursday June 07, 2012 @01:48PM (#40246991)

    They're abiding by the terms of the GPL and considering giving more than is required. It's a company, not a charity.

  • by Andy Dodd ( 701 ) <atd7NO@SPAMcornell.edu> on Thursday June 07, 2012 @02:55PM (#40247861) Homepage

    Android is a perfect example of this - While the userspace Android stack is open source, the Apache license allows vendors to close the source and not release any modifications.

    Pretty much all of them do, except for those working on Google's reference devices (the Nexus series).

    Now I can understand closing up your "special sauce" modifications like custom UI skins and additional applications - but these companies close down their HALs and frequently change their HAL interfaces so they differ from the Android standards, making it difficult for those who want to run pure AOSP on a non-Nexus device to do so. There is no benefit to doing this - it only pisses people off if they are unhappy with your skin but are unable to change it.

    Samsung is especially bad in this regard - they will find every excuse they can to avoid providing source. For example:
    The wifi drivers for the ath6k chip in the Tab 7.0 Plus and Tab 7.7 are apparently dual-licensed (BSD/GPL) by Atheros. Samsung chose BSD - so as a result owners of those devices are stuck with shitty wifi that doesn't work well and can't be fixed.
    AT&T released an OTA update to Gingerbread for the Samsung Infuse. Two weeks later, Samsung still had not provided kernel source in compliance with the GPL. At this point, AT&T stopped providing the update due to issues with the touchscreen drivers. A week later, Samsung claimed they did not need to provide source for that release because the update was no longer being provided. This is in conflict with the GPL - Samsung DID provide binaries officially to many users, and they are legally obligated to provide source to those users.

    In a manner HIGHLY atypical for them given their corporate history, Sony seems to be the only company in the Android ecosystem that isn't paying lip service to open source. They provided ICS alphas and betas (INCLUDING kernel source) to the community, have provided technical documentation and assistance to the Cyanogenmod team that has been greatly instrumental in bringup of Cyanogenmod on Sony devices, have open-sourced their sensor HAL even when they didn't have to, and actually have a developer relations guy (Karl-Johan Dahlström) that does his job. (As opposed to Samsung's developer relations guy, who just cross-posts to XDA teasing of "awesome things to come" and completely failing to deliver, and tweeting source code release announcements for source code releases that have already been out for a week or more.) It's enough that there's a good chance my next phone will be a Sony despite a historical hatred of them for their past bad behavior in other business areas.

  • by aaronb1138 ( 2035478 ) on Thursday June 07, 2012 @04:27PM (#40249021)

    I wonder if some of the issue is actually Intel vetting approval from their legal department. A lot of people like to point at Intel engineering and point and say look at all the cool stuff they holding back and only offering as binary blobs. The reality is that their middle management business to business side keeps letting 3rd parties write horrific terms into contracts.

    I know with Atom CPU development that the GPU is extremely encumbered by NDAs with PowerVR which prevent Intel from releasing any decent drivers for Linux or Android. There was even one support technician who commented on the fact that he compiled working Android x86 graphics drivers for GMA 500/600 based hardware only to find out from his boss that they could not be released because parts of the code tree where contaminated by bits of PowerVR code. The technician in question goes by "pinebud77" on YouTube and just "PineBud" on pocketables.com. At the time, about 2 years ago, Intel then and up through now, has had to completely rewrite their drivers for GMA graphics on both Windows and *nix platforms due to bad legal agreements. They've had to go so far as to reverse engineer drivers they had already paid for. It has even been questioned how much this killed Meego development in early stages.

    I suspect there might be similar bad deals with partners hurting Intel here. The gist I have gotten is that they don't want to withhold drivers or technology, but even when they back up a Brinks truck of cash, they get screwed on contract terms by 3rd parties. The management folks don't have any clue why they might need rights to code they buy from Imagination Technology, Tungsten, or others.

    I know the article is related to multi-threading CPU processes, which Intel definitely has a lot of their own engineering invested, but I wouldn't take the "I don't like doing R&D for competitors if they're not going to contribute themselves," as the sole reason. Further, seriously consider the current x86 vs ARM environment. If you look at the article comments and forums at many other tech news sites (namely arstechnica.com and theverge.com) there are a LOT of relatively ignorant people who seem to think various ARM architectures are vastly superior in computing power to x86 and trying to turn it into some kind of architecture holy war on the scale of AMD vs. Intel vs. Cyrix debates of years past. People who actually think that ARM has equivalent processing power to low end i5 CPUs, when top end quad core ARM CPU's can't even match the FPU performance of 4 year old ATOM single cores. It's even harder to explain to those crowds the massive issues ARM has with scaling and multitasking due to huge bandwidth to IO busses bottlenecks. All of these factors give Intel very good reasons not to share their undertakings with competitors who have brainwashed enough masses to no longer need to compete on merits. I'll give various ARM implementations the performance to battery use crown all day, it's a great CPU for something like a smartphone. When I hear derpity derp about ARM for high utilization clusters though, I vomit a bit in my throat.

  • by citizenr ( 871508 ) on Thursday June 07, 2012 @05:47PM (#40250219) Homepage

    If they are talking about a scheduler change, that is very likely a kernel modification.

    Android has its own scheduler, in java and everything. This is why you get FPS drops on dual core 1.5GHz phones while on home screen just sliding tabs around, or 100ms Audio LAG, or >100ms input lag..

The hardest part of climbing the ladder of success is getting through the crowd at the bottom.

Working...