Google in talks to re-admit Android to Linux kernel Android's deviant Linux could be readmitted to the main kernel following talks at the Linux Collaboration Summit in San Francisco today and Friday. Developers from Google's Android team are due to meet the Linux kernel devs in the hope of working out their differences and closing an awkward chapter in the history of Linux. …
Seems to me that Apple and its App store is manna from heaven for many electronics and software companies (MSFT included if they could just find a way of merging this method with its current business model). Certainly the phone companies love the walled garden- approved apps only approach. Android has already adopted this of course, but for non-phone devices there is no clear equivalent - ipad yet to be proven.
Linux has removed a huge barrier to entry into the OS market and for complex electronic devices. Google has already forked into Android and even if they remerge you can bet there will be optional modules designed for mobile and other locked down devices.
Does this matter? It's good to break the msft stranglehold but am I alone in worrying that Linux could get hijacked well way from its free ethos?
More power to the likes of Greg KroahHartman and Richard Stallman I say!
In terms of people not caring about Android, he's right in relative terms. Android might be installed on 30 models of smartphone, but Linux is installed on tens of millions of machines and is the basis for enormous commercial and open source industries. Going off and merging weird non-standard code into this was bound to result in this scenario...
Just follow the kernel coding standards, apply an acceptable license and be responsive to 3rd-party comments and suggestions to your code. Just meet those condition and your code will be accepted. That works for everyone else who contribute to the kernel, so why should Google deserve preferential treatment?
Gavin,
What do you think Zemlin means by table here?
> Linux Foundation executive director Jim Zemlin, whose
> group hosts the annual summit, told The Reg: "I think
> they can hopefully work it out... the purpose of this event
> is to table those conversations."
As a Brit, you know that when we table an issue, we put it forward for discussion. But when Americans suggest tabling something, they mean they don't want to hear any more about it.
So does Zemlin think they want to discuss this, or drop it?
Sorry Jeff11, can you clarify?
> Android is installed on 30 smartphone MODELS
> Linux is installed on tens of millions of MACHINES
It seems that you're not comparing like with like.... did you mean Linux is installed on tens of millions of models?
Given that Linux has been around for some time and the variant called Android is still in its infancy I wouldn't dismiss it so fast. Even 7.1% of the US smartphone market is a lot of devices
I was at Chris Dibonas presentation and it seemed that Google is under pressure to hack the kernel to get it work as the #1 priority rather than push acceptable code into the upstream kernel. GregKH was right to pull the Android kernel code out of the kernel since Google wasn't playing ball in putting effort into the upstreaming of their code in a timely manner.
You cannot just dump code into the kernel and run away. Google needs to wise up and play the open source kernel game correctly - otherwise they will get lots of enemies. As it was, Chris was keen to give out loads of shirts and free Nexus One google mobile phones - is this a reflection of Google's arrogant position that they have loads of money and think they can buy good will. Good will in the Linux community is won by doing things right.
They also created the IPhone/IPod locked down closed source proprietry database system that is not accessible unless you use ITunes components (Requiring ITunes shop front to be installed on the users machine). Rather than just letting people drop MP3's on their device like other PMPs.
A little background on embedded Linuxes, in general they will take a certain kernel version (so 2.6.31 for instance), and progressively modify it for that particular embedded platform -- making changes so the bootloader can load the kernel, perhaps changes to reduce size or shave a few cycles off boot time, and add platform-specific drivers. Since these drivers are platform-specific, they may take liberties that make them inappropriate to include with the nromal kernel, like they just assume a device is at a certain I/O address and DMA, and access that directly, instead of doing plug-n-play, having the kernel set up DMA buffers, etc etc. Some platforms still use 2.4 kernels. So once this kernel is going, they may port their customizations to a newer kernel from time to time. Or maybe they won't.
The article (and article linked from it) are a bit light on details. Here's the ones I've heard about...
I had read a summary of changes between mainline Linux kernel and Android's. From what I heard, there were a lot of ARM optimizations and drivers. The ARM improvements are probably already mainline, and drivers being implemented when possible. BUT, although the kernel has plenty of lock types already, Google introduced a new one seemingly superflously, and the drivers tend to use it instead of one of the numerous existing lock types. They introduced a new security model, even though there's users&groups, Access Control Lists, and 1 or 2 additional VERY flexible security systems already in the kernel tree. They also have their frame buffer drivers implementing a new type of framebuffer Google implemented instead of just showing as a standard Linux framebuffer, and making improvements to that framebuffer code as needed. These three are the real issues from what I've read, the kernel guys would VASTLY prefer the lock, securtiy model, and extra framebuffer type not go in kernel unless Google makes a VERY compelling case there's a reason for it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
