Android and the Linux Kernel Community 354
An anonymous reader links to Greg Kroah-Hartman's explanation of a rift (hopefully mendable) in the development culture of Google's Linux-based Android OS and the Linux kernel itself. "As the Android kernel code is now gone from the Linux kernel, as of the 2.6.33 kernel release, I'm starting to get a lot of questions about what happened, and what to do next with regards to Android. So here's my opinion on the whole matter ..."
Google (Score:4, Interesting)
Because Google doesn't have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community.
Google shows no sign of working to get their code upstream anymore.
Oh come on, was it really a surprise to anyone that Google does only care about OSS when it suits them and drops out instantly when it doesn't. All of their own sites, business and back-end technology is just as closed as Microsoft's.
I see someone coming along and saying "but they contribute to open source!". Sure, they do, they release little snippets of code and open source those products they base on OSS code because they have to by GPL. One could seriously argue if their open sourcing efforts are making better open source community in general, or not. Like TFA states, their ignorance has caused more turmoil than ever before in Linux land. Companies are obviously going to create support and drivers for Android-branch of Linux kernel, but cant contribute the same code back to real Linux kernel. And possibly never will because it costs them too much work, money and time. Even those companies that previously did develop linux drivers. That's not harming Linux and OSS community?
Get off your lazy ass and see what's really happening.
Re: (Score:2)
That's not harming Linux and OSS community?
No, it isn't, because there is open competition from other vendors. The only group it's harming is Google and those companies dumb enough to buy into Android for their future.
Re: (Score:2, Interesting)
The only group it's harming is Google and those companies dumb enough to buy into Android for their future.
Google has a major advantage here as one of the largest companies in the world, and those companies "dumb enough" are going to jump on Google's side because they have the market share.
Re:Google (Score:5, Interesting)
Google has a major advantage here as one of the largest companies in the world
Nokia has the major advantage that they are *the* largest phone producer on the face of the planet and have *the* largest world market share by a large percentage. Google and particularly, Android are small fry in comparison, despite their size in other markets. Those companies jumping on Android are dumb because their horizon is limited to the US market and a single platform.
For irony, Google "Maemo" and "Nokia N900".
As I said, the only groups being hurt by this are Google and those dumb enough to rely on Android for their future, anyone else with a brain will take a look at the competition and more open platforms.
Re: (Score:2)
Google has a major advantage here as one of the largest companies in the world
Nokia has the major advantage that they are *the* largest phone producer on the face of the planet and have *the* largest world market share by a large percentage.
Yeah but that is mainly because of their hold on the market for cheap, dumb phones. The smartphone market is really a different beast now.
Re:Google (Score:4, Informative)
Eh, trolling much? If you look outside US, Nokia is dominating. iPhone is nowhere as successful as it is in US. In top of that, Nokia holds patents (that they really deserve) over many technologies used with GSM, 3G and so on.
And Nokia offers a real Linux phone, not just Android or locked-down iPhone shit.
Well I live in Australia and the iPhone is very popular. Most people who want a smart phone will have an iPhone. Many older people who just want to make calls will have a $50 nokia. I use an openmoko, which is also a real Linux phone.
Re:Google (Score:5, Interesting)
What people seem to overlook is that Google wrote Android on their dime, opened it up, and then handed it over to the Open Handset Alliance, which has companies like Nokia on the board. Google does not own and control Android. The Alliance does.
And how is Android not open? The entire thing is FOSS.
Re:Google (Score:5, Insightful)
I wondered that myself when looking into the N900, and the explanation as to why Android is not open is because while it is Open Source, it does not have an open community.
If you look at the OHA FAQ, they explain why an open platform is good for everyone EXCEPT the end-user. Unless you mistake who your customer is, you'd realize that the end-user's input is just as important as those who apply your OS to their device. Both the OHA and the cell vendors make that mistake, as the OHA thinks the user of Android is the handset maker, who themselves think their customer is the carrier. The only true customer is the person who pays for and uses the device in the end, and they should be able to have input into their device and its OS should they care.
The simple solution (Score:4, Interesting)
I'm hiding the easy answer here deep in the thread under your question.
Google has Android slates (tablet format ARM-powered machines). If Google took 1000 of them ($400K worth) and just gave them to select Kernel developers (several each) to do with what they would, the problem would solve itself. The Kernel developers would adapt their preferred distro to work on the first slate they had, and they'd keep the rest to work as they were intended until it limited them - and then they'd want to break the limit by improving the Android code, which they would then want back in the Kernel tree because they would want their improvements to persist. It's all about motivation, and you motivate a Kernel geek with cool tech he wants to continue to use.
HP did this. Why do you think Kernel.org runs on HP servers and has for many years? It's because HP donates servers strategically, and yields huge benefits therefrom.
Re: (Score:3, Interesting)
> And how is Android not open? The entire thing is FOSS
(cringes, wrings hands for a while, coughs a bit, then sighs)
"Android" might be "open", but people fighting on the Android front lines and trying to run open builds without the blessing of HTC and their carrier might politely beg to differ. To date, nobody has been able to independently build a fully working 2.6.29 kernel for ANY CDMA Hero phone that shipped with Android 1.5 (Sprint Hero, Sprint Samsung Moment, Verizon Droid Eris). Without a 2.6.29 k
Re: (Score:3, Informative)
As I said, the only groups being hurt by this are Google and those dumb enough to rely on Android for their future, anyone else with a brain will take a look at the competition and more open platforms.
Newsflash: Consumers don't care about whether Google's playing nice with the Linux community or not.
Re:Google (Score:5, Insightful)
Is that why we already succeeded at Year Of Linux On Desktop back in 2003?
Haven't you noticed? The desktop is irrelevant. It's been abstracted to an Internet access platform. It's the phone in the pocket which is the current battleground, and Linux has won that already.
Re: (Score:2, Interesting)
Re:Google (Score:4, Interesting)
> since yes, the desktop is going away,
Oh pleaze. For all the buzz about "the desktop going away", the number of desktop computers seems to just keep growing. Homes that had one PC now have two. Or three. Individuals who had their own now have their own desktop PC and a laptop (or at least a netbook, which contrary to its name seems to end up spending at least as much "on" time doing stuff a few thousand feet above sea level, inside flying aluminum cylinders that are one of the last frontiers where internet access is still rare and expensive). Most of the people "making do" with a laptop as their only computer are people who formerly had no computer at all. The people who owned computers 15+ years ago won't give up their desktop until laptops routinely come with dual 24" displays and quad+core CPUs.
Cloud computing is the new paperless office. As more than a few have observed over the years, the paperless office was officially welcomed 15 years ago, yet 21st-century offices still seem to somehow generate at least twice as much printed output per employee as they ever did in the dark ages. The main difference is that back then, the paper copies were carefully stored in file folders for future reference. Now, they're stored in the SAN, and four dozen copies get casually printed on demand so everyone can pretend to read them at the weekly status meeting & use them to scribble notes on before tossing them all in the big blue bin after lunch. I'm quite confident that when the day arrives that I have a hundred terrabytes of data stored "in the cloud", I'll have at least ten times as much physically present within my home.
Desktops aren't going away anytime soon, any more than TVs with eight-foot screens are going to be displaced by personal media tablets. They might end up mutating into our own personal faux-clouds, perpetually connected to our PadPCs and phones, but at the end of the day, when you need to edit video (from the 25 years of videotapes you're still trying to digitize before they rot into grey digital goo), sort out 400,000 family photos digitized and captured over the years, do your taxes, and write cool software for your new phone to sell online for enough profit to buy a stale gumball from a vending machine, you're going to have one hell of a home PC that will make the most high-end PC available today look like a Commodore 64. With liquid nitrogen cooling to keep it from causing a mini fireball (it only throws off 10 watts of heat thanks to miniaturization & efficiency, but those 10 watts are concentrated in an area the size of a poppy seed).
Re:Google (Score:4, Insightful)
This is some seriously poor logic. Consider for a moment GM. In 2008 they were the 4th largest company in the United States. By your logic it would be ideal to attach your company's future well being to GM. Now consider how well that worked out for over 1000 GM dealers, hundreds of parts suppliers, etc. See how that turned out. For the record, Google was #117 in 2008.
Re:Google (Score:5, Funny)
Apparently Google employees have mod points today.
Re: (Score:3, Funny)
Apparently Google employees have mod points today.
Well, duh. Google employees always have mod-points. Where do you think slashdot gets them from in the first place?
Re: (Score:2, Offtopic)
I started a comment with the sentence "The good thing about the iPhone ..." in a prior Google / Android article and what did i get for my troubles? an instant ... Troll
Make no mistake, Googles hidden geek mafia run this here town.
Re: (Score:3, Insightful)
Re:Google (Score:5, Informative)
It is called Embrace, Extend and Extinguish. I thought it only applies to MS. Well I think, Do no Evil is gone through the window :)
Well, we know what Steve Jobs said [wired.com] about Google's "Don't Be Evil" mantra--"It's bullshit." Or, "a load of crap," depending on your source.
Re: (Score:2, Insightful)
Well, we know what Steve Jobs said [wired.com] about Google's "Don't Be Evil" mantra--"It's bullshit." Or, "a load of crap," depending on your source.
Is that actually based on anything though? You have to remember that 'evil' is a point of view and when a company gets that large and that diversified obviously they are eventually going to step on the toes of someone who has a different interpretation of what is 'evil'.
Re: (Score:2)
Is that actually based on anything though? You have to remember that 'evil' is a point of view and when a company gets that large and that diversified obviously they are eventually going to step on the toes of someone who has a different interpretation of what is 'evil'.
Just so we understand each other, I'm not necessarily advocating Jobs's position, just quoting him. But I think that what you're saying is pretty much in line with what Jobs said, which is not that Google is evil, only that "Don't Be Evil" isn't really applicable.
Re:Google (Score:5, Interesting)
Well, we know what Steve Jobs said [wired.com] about Google's "Don't Be Evil" mantra--"It's bullshit." Or, "a load of crap," depending on your source.
Is that actually based on anything though?
Yes - it's based on one rich guy being annoyed that another rich guy threatened to take some of his richness. From the linked article:
On Google: We did not enter the search business, Jobs said. They entered the phone business. Make no mistake they want to kill the iPhone. We won’t let them, he says. Someone else asks something on a different topic, but there’s no getting Jobs off this rant. I want to go back to that other question first and say one more thing, he says. This don’t be evil mantra: “It’s bullshit.” Audience roars.
Steve Jobs wasn't making some deep point about Google's manipulation of FOSS, he was just ranting about unfair competition (for 'unfair competition to Apple in the eyes of Steve Jobs' read 'Giant, friendly, happy-go-lucky Silicon Valley company treating design and user experience as important'). He may as well have just complained that Google won't share their toys.
Re: (Score:3, Interesting)
To be fair, there's a little more to it than that. Eric Schmidt, the CEO of said "giant, friendly, happy-go-lucky Silicon Valley company," was s
Re: (Score:3, Interesting)
You know, this might explain the giant hole between the original release of iPhone and the release of Android.
Apple created the SmartPhone market place and can carry the "I was here first badge". Of course we had other SmartPhones prior to this but the market was fairly restricted to business use not really domestic (everyone one from 16yr old kids to 70+ year old retirees use iPhone).
And I'll say it again, hoping i wont get marked a troll for stating a true but negative POV, but Google I believe missed the
Re: (Score:3, Informative)
Wrong. Let's not act like a product category that had been around for 10 years prior to iPhone was suddenly created by Apple. Apple did not create the smart phone. They did not even define the product:
Palm, Blackberry and Microsoft (to a lesser extent) defined the product. Apple came out with the best model in the 2008 model year. That is the extent of the achievement, and to give Apple more credit is simply an insult to the people that created iconic products like the Blackberry, Treo and to a lesser de
Re:Google (Score:5, Insightful)
Google's "Don't Be Evil" mantra--"It's bullshit."
What's sad is that, here on Slashdot, we run with the worst possible interpretation of everything.
So, what started as one non-Google developer deleting some Android-specific drivers from Linux (mind you, leaving in massive amounts of upstreamed work from Google, this is just the small Android-specific bits) becomes "Google is abusing the open source community and is now evil."
Sad, just sad.
Re:Google (Score:5, Insightful)
Re: (Score:3, Insightful)
The problem is the idea of a single code base that will satisfy all needs is a pipe dream and always will be. Developers may have to do some extra work to write appropriate drivers for both trees. Welcome to the real world.
No, I don't think so (Score:5, Interesting)
Google has frankly set a new standard as far as how companies can become very successful by embracing the open and free software communities. I honestly don't think you can point to many other companies that are doing better, nor could you realistically expect to. In the mobile space, pretty much the next nearest competitor in terms of openness is Apple (Darwin, et al) - in other words, a joke. Meanwhile Google not only has a wonderfully organized system for playing with all the Android code, but a broad commitment across products. Look at Wave, for instance - wide, wide open, and very deliberately (because they know it cannot succeed any other way). Google has probably done more for Linux and its credibility than most other companies in the world.
I think this is something totally different - a disagreement about direction between the mainline maintainers and Google's Android team. Corporate developers, even well-intentioned ones, have a conceptual hurdle to get over when someone Not Their Manager is telling them "you must spend x man-months refactoring your code thusly."
Many, many companies have run into this issue with Linux (and other projects) before, and many will again. It usually goes something like this:
Step 1: Whatever. We're Google. Am I going to rearrange my whole development roadmap to follow the directions of some whiny nerd in his mom's basement? LOL.
Step 2: Oh. Crap. Wow it is kind of a lot work maintaining my own entire fork of the Linux kernel/KHTML/etc. all by myself.
Step 3: Either A) capitulation - the last guy is fired or smacked with the clue stick, and the cooperation restarts, or B) a true fork. These usually stagnate and die, and are also riddled with bugs and security holes btw... unless, the fork is really more interesting than what it forked from, in which case, the community switches to the fork and justice is served.
Often between Step 1 and 2, the maintainer will attempt to play a little corporate politics by embarrassing said middle manager in the media. By the way, this is pretty smart and it often works - especially with companies as large but otherwise savvy as Google, a slashdot story can jumpstart efforts to mend the rift by bringing more senior eyes on the problem. Cooperating is in everyone's interest, and they will realize it.
Wait, I take it back (Score:3, Insightful)
Somehow I managed to forget Nokia for being more open than Apple - and arguably - Google. I guess because so few people use, or will likely ever use, their smartphones. :)
Re: (Score:2)
Re:Wait, I take it back (Score:4, Insightful)
I can't find anything yet that actually gives N900 or Maemo sales figures. Your link does not - I am all ears if you have something. Something tells me that Nokia isn't anywhere remotely near selling 21 million devices truly comparable to iphone or android in Q4. "Converged mobile device volumes" is very carefully worded and my guess, careful weasel wording is the only way the can come up with a number so impressive-sounding.
Apple has only shipped 75 million [gizmodo.com] iphone and ipod touch devices combined worldwide, and something like 8.7 million iphones in Q4. [fiercewireless.com] So if Nokia "true" smartphones were outselling Apple smartphones by such a margin, in any way shape or form, I think that would be bigger news, no?
I think this confusion comes from Nokia labelling any $50 gadet of theirs with a dime-store web browser and a music player as a "converged mobile device." But even in this case I should have qualified my remarks as referring to smartphones, rather than just "mobile."
Option B (Score:2, Interesting)
Has there ever really been a serious option B effort to just pick a time and do a major kernel fork and maintain it forever by any company as large as google, with their level of developers and resources/cash behind them? Any precedent there?
Yes, Redhat (Score:5, Interesting)
"Redhat Enterprise Linux 5" is essentially a massive kernel fork at 2.6.18. Redhat is the most plausible contender for doing this, since they employ a really significant number of the world's kernel devs, including Alan Cox (until last year). That split was even acrimonious at times IIRC. But then again, you can just call it similar to Canonical's LTS - people choose whether to go with a version of something that's more or less mature - and most distros going with the "more mature" option frequently cheat and backport all kinds of things in the meantime (with greater and lesser success).
Depending on who you ask, RHEL can be more risky than mainline. I've definitely had RHEL panics take down production, only to later discover linux kernel bugs that had been fixed in mainline for a while, but that redhat hadn't backported to their ancient linux fork. But then again, people get burned going the other way all the time too. I don't know if anyone's really independently studied what's ultimately safest. My guess is that you are usually safest inside the biggest crowd - i.e. closer to mainline - but not too near the very latest version.
Re:Google (Score:4, Insightful)
Sure, they do, they release little snippets of code and open source those products they base on OSS code because they have to by GPL.
Erm, no. While I don't consider Google to be a particularly charitable organization, they do regularly open source their products (though mostly minor ones, as you rightly pointed out) when there is no legal obligation on them to do so.
The reason for that is perfectly clear, too: it strengthens the image of Google as both "geeky" and "open" tech company, which are both important parts of Google's public image.
Re:Google (Score:5, Informative)
It's not just public image. There's also the fact that Google is a company full of geeks, many of whom are open source fans in their own right.
I was primarily responsible for Google releasing Protocol Buffers [googlecode.com]. I did it not for the sake of improving my employer's public image, but because I thought it was a useful tool that should be shared, and those around me agreed. Because of the bottom-up nature of decision making at Google -- and given that I was willing to do the work -- I had no trouble pushing this through.
So yeah, it's pretty upsetting to me to see people say things like "Google does only care about OSS when it suits them and drops out instantly when it doesn't.". This kind of statement completely misunderstands how Google even works. This just isn't the kind of company where orders comes down from executives on high with the only motive being profit -- anyone who thinks otherwise obviously doesn't work here.
Honestly, I think the main reason we haven't released more stuff is because it's kind of a lot of work (as I have learned). Dumping code over a wall does not please the open source community -- you have to maintain it; document it; test it on a zillion platforms; answer e-mail from people who think they are not just entitled to your code, but are doing *you* a favor by using it; review patches from college kids who don't really know what they're doing; etc.
(Oblig. disclaimer: These are my own personal opinions; I am not authorized to speak for my employer.)
Re:Google (Score:5, Funny)
So just authorise yourself, right? ;)
Re:Google (Score:5, Informative)
I don't think the Android team would describe it that way. TFA doesn't really cover their side of the story. As is usually the case when two sides don't agree, the details are complicated. I'm not on Android so I'm not going to attempt to get into it, but they aren't particularly happy with the situation either.
Re: (Score:3, Insightful)
Please spend two minutes looking at Google.org.
Re: (Score:3, Insightful)
Re: (Score:2)
So sponsoring the "Summer of Code" doesn't count as contributing? Seeing as how they have paid for development time on hundreds (if not thousands) of good projects? What have you done for Open Source lately?
Yes, their behavior with regard to the code going into their products does not really embrace the open source model, but given the constraints they are under to protect their core business IP, can you blame them?
It seems like the best thing that can happen is for Google to maintain the Android changes
Re:Google (Score:5, Interesting)
They don't support OSS when it doesn't suit them?
They pay the salaries of guys like Andrew Morton and then cut him free to work on Linux as he sees fit, basically just answering to Linus.
They pay for projects like the Summer of Code, paying for the development of projects they don't use internally.
They released patches for projects like Wine well before they were using Wine in any releases of their projects.
You claim they only release code when they have to. They were never required to create an OS. Are you aware the Chromium browser code is BSD released, right? It wasn't like they just wanted to build upon some GPL project and then were required to stick with GPL. They build a whole new browser, and opened it up BSD so anyone can use the code however they want. How is that closed?
Look what they're doing with Wave. They developed an entire protocol from the ground up. The protocol and all the server code is open. They could have tried to patent the protocol and charge for licensing. They're just releasing the whole thing and telling people to do whatever they want with it completely for free.
What about protocols like SPDY they wrote from scratch and released for free? What about their various hardware designs for power supplies they've released for free? These are things that give them a competetive edge. If anything, most people would argue it hurts them to give them away for free, but still they do it. They rarely get credit for how many things they open up. And yet the very communities Google helps finance and take care of turn around and slam Google. Do you realize who your allies are in the FOSS world?
You claim they're just as closed as Microsoft?
Pure lies and trolling. Seriously, shut the hell up.
Re: (Score:3, Interesting)
The point he was making is that WebKit (a rendering engine, NOT a browser)
How can you have a browser without a rendering engine? What would be the point?
Unlike Apple (for example), who took the BSD licensed WebKit, did significantly less with it when they built Safari, and kept the result locked up.
What? WebKit is LGPL licensed, not BSD licensed. And it wasn't called WebKit when Apple started using it, it was called KHTML. WebKit is Apple's name for their fork of the KHTML project. And Apple didn't "do significantly less with it" - they basically made the whole thing over, and turned a rendering engine that was going nowhere and not used very widely into a modern, high performance and widely adopted engine.
WebKit is far mor
Re:Google (Score:5, Insightful)
Oh come on, was it really a surprise to anyone that Google does only care about OSS when it suits them and drops out instantly when it doesn't. All of their own sites, business and back-end technology is just as closed as Microsoft's.
Point 1) how is not pushing to mainline code "dropping out" of open source development exactly?
Point 2) The Common Android Kernel tree [kernel.org] is browsable, and looks to be fairly easy for anyone to take advantage of. The complaint here seems to be that Google isn't putting in enough work to merge their Linux kernel changes into the mainline, not that they have failed to release anything in a usable way. I find it somewhat disingenuous to slap down an open source contributor for failing to do our work for us.
Point 3) Microsoft's services are just as open?! Great, where is Microsoft's instructions on how I can export all of my data from all of their services in open formats? Google provides that [dataliberation.org] so I'm certain you're aware of where Microsoft publishes such information as well... Oh and while you're at it, how many open source projects do Microsoft projects contribute to? Python, Linux, and dozens of other existing projects get updates from Google and they've released more open source software of their own making than anyone else.
So, what company have you been watching that confused you so badly that you thought Google wasn't the single largest benefactor open source has?
Re: (Score:2)
Did you forget about the Google Summer of Code and multiple other projects where they basically fund the development of OSS tools?
Re: (Score:2)
"If". "If linux was under"
No more happy hour for me.
Re:Google (Score:5, Informative)
If linux was under the BSD license it would be in the same shape FreeBSD is in, nearly no one using it in the server room.
So sure we have to wait for btrfs instead of using ZFS, but only because SUN decided to make sure they chose an incompatible license.
Re:Google (Score:4, Interesting)
Server room, depends. Desktop, BSD is still beating Linux (Thanks to Apple.) Where BSD has found a niche is in Network appliances such as routers and firewalls. FBSD still has a superior networking stack from what I've seen. I know we use pfSense around here and Monowall before that. We also deploy Juniper networking equipment and JunOS is based on FreeBSD.
We actually deploy all our production servers on FreeBSD including our PostgreSQL and MySQL database servers. And they do so with rock solid realiability. The only time I can think of boxes crashing had to do with hardware failures. Including a couple boxes that were still running FBSD 6.x. We didn't bother taking them offline to upgrade until we replaced the hardware.
Re:Google (Score:5, Funny)
I want ZFS for my home server, zfs is not the answer
Very Zen.
Re: (Score:2, Funny)
zfs-fuse. Bah. I quit.
Re: (Score:2)
Hey, Google doesn't need to contribute back their code to the Linux main tree. It's perfectly fine not try to merge it. But because it makes sense for everyone (end users, Google, Android developers, hardware manufacturers), people is trying to fix the situation. Maybe you don't care about working together, but Linux people do.
One sentence to say it all... (Score:5, Insightful)
That's all. It's obvious that Google doesn't care about it that much. And yet nobody demanded them to do so -- if Google wants it its own way, why shouldn't it be able to?
I may be a crazy open-source lunatic, but I am tired of all of this "It's a world conspiracy against Linux"-thing. Let's get a grip, talk less and code more.
Re: (Score:3, Insightful)
I don't think he is seeing this as a conspiracy against linux. He is just saying that some work may have to be done twice (because merging is not feasible) which is really bad for everybody. no one wants to maintain 2 code base.
Re: (Score:2, Insightful)
So then maybe they shouldn't have kicked the android code out of mainline in the first place?
Re:One sentence to say it all... (Score:4, Insightful)
If it created code dependencies that nobody buy Google could compile against, it's got no business in the mainline -- it effectively breaks the kernel for everyone else.
This isn't a matter of getting voted off the island because they don't like your features -- it's about making something which was incompatible and people deciding that it had to go.
Google has just TIVO-ized the kernel (Score:3, Interesting)
Re: (Score:3, Informative)
Hardly. Nobody's forcing you to run their binaries on your phone. You can still compile the kernel and other applications from code, forked or not.
Re: (Score:2)
I wasn't talking about a generic kernel. You can still compile from Google's copy of the source just fine, it's no less visible.
Re: (Score:3, Interesting)
You do realize that Google does not own nor control Android, right?
Google handed Android over to the Open Handset Alliance the moment they unveiled it. There are several large companies (like Nokia and Motorolla) who take part in that alliance.
Re:One sentence to say it all... (Score:4, Informative)
it never made it out of staging into mainline... it wouldn't build as there were items Google never released that it was dependent upon.
Re:One sentence to say it all... (Score:5, Informative)
it wouldn't build as there were items Google never released that it was dependent upon.
Are you sure that statement is true? It seems inconsistent with other information posted here, and in the LWN discussion.
Re: (Score:3, Informative)
How is this +5 informative? It's completely false.
The reason it didn't make it to mainline is because the Google code was reviewed and found to have problems that stopped it being accepted into mainline. Because there are user space items in Android that would be affected, only Google could make the changes without breaking Android.
Think about it, if you were unable to build the Android kernel because Google were withholding stuff, it would be in direct violation of GPL v2. Do you see Greg KH complaining
Re: (Score:3, Interesting)
Does that mean Android handles OOM conditions gracefully? I've only seen one OS that does it well[1], but the Linux behaviour in these conditions is the absolute worst (pick a process at random, typically the one with the most unsaved data, kill it). This is one of the biggest problems I saw with Maemo. Run low on memory, and suddenly apps die. Make sure you save regularly, because there's only a small chance it will be the web browser that is killed and not the editor that you were writing in...
[1] R
Re: (Score:2, Interesting)
I would like to see people looking at what Google did and say: "Oh well, it's their choice and I can't do
Re:One sentence to say it all... (Score:5, Interesting)
Nothing is stopping people from porting android to use a standard Linux kernel.
Honestly It's a two way street, and I doubt that google looked at the Linux guys and told them to go fornicate with themselves.
Google does releases on their own schedule. Being someone that is deep into Android guts on the x86 level for a project of my own (android based car stereo) I am frustrated at them not releasing the latest version, but I can either sit and while like a baby, or take what I got and build on it.
Re: (Score:2)
Or you could just use a regular linux kernel for your project, would save you a ton of hassle.
Re:One sentence to say it all... (Score:4, Informative)
And what for the interface? Android is at least 9000 years ahead of anything else for a limited attention easy to use touchscreen interface. Plus I get a pile of apps ready to go including navigation.
Re: (Score:2)
Re: (Score:2)
I would have suggested using a voice interface, touch screen in a car seems like asking for an accident.
not quite... (Score:5, Insightful)
This isn't about some anti-Linux conspiracy, it's about conflicting business interests.
Google has made modifications to make their software work. Those modifications can not be integrated as is with the kernel. Cleaning up their open source code can be done, but their internal closed code would likely also need modifications to account for that cleanup. So for Google, merging their code would likely be expensive and require extensive testing and a large download and upgrade system for all of the live phones.
On the other hand, companies that are developing drivers and software that depend on the new kernel are now hosed because the kernel is no longer exposed as part of the Linux kernel. So they have to deal directly with Google for any changes to their kernel, and if they also want to release their products for other Linux platforms, they have to re-engineer much of the os-interaction functionality. Obviously a pricey situation for them.
If Google updates their code to get it into the kernel, it makes it cheaper and easier for other developers to work it, but it costs them money. If they don't then it costs the developers more money.
-Rick
Re: (Score:3, Insightful)
Nice summary.
I'd like to add: Developers, developers, developers, developers. Google should spend that money. Consider it an investment in your platform -- it makes it that much more attractive to other developers.
Re: (Score:2)
up merge justification has to be Android-agnostic (Score:5, Interesting)
You don't merge new features into a robust low-level code base.
You merge support for abstractions the new features rely upon into the low-level code base, and build on them.
Make a case for kernel support of the "new lock" and "security model" independent of Android's reliance on it, and remove as many of the Android drivers using these facilities OUT of the main tree. IMHO, drivers really don't belong there, but should be available in "driver package sets" aggregated by distro providers.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
And to a lot of people outside the Linux kernel development community, that "stable API nonsense" document is such a blindingly wrong example of software design that advocating it would get you shown the door in a job interview.
The "nonsense" docuemnt assumes that the purpose of all drivers is to converge to a single less-buggy ideal; this is true for a hardware driver where the hardware is frozen when it goes out the door. This is blatantly untrue for software drivers (e.g. 3d graphics, virtualization) wh
Lots of comments on LWN.net's coverage (Score:5, Informative)
Re: (Score:2)
Re: (Score:3, Informative)
Might be rather hard to "clean up". Back in 2008 Mathew Garret wrote: [livejournal.com]
Re: (Score:2)
Re:Lots of comments on LWN.net's coverage (Score:4, Interesting)
That's completely disingenuous. Everyone agrees that the problems Android needs to solve should be solved. The kernel community simply disagrees with *how* Google solved the problems. Long ago Google could have asked "we need to optimize power usage by doing agressive suspend" and then worked with the kernel community to get a solution that everyone was happy with.
But instead, Google went off into a corner, created their own solution behind closed doors that nobody in the kernel community likes and now it can't go upstream.
It's not about "how we use the kernel", it's about how you coded things in isolation then expect everyone to be ecstatic with the result despite the fact that the gatekeepers never had any input into the design.
Re:Lots of comments on LWN.net's coverage (Score:5, Insightful)
But instead, Google went off into a corner, created their own solution behind closed doors that nobody in the kernel community likes and now it can't go upstream.
No one in their right mind is going to start a lengthy debate with kernel developers when they have a deadline to meet and a product to ship.
In the industry, getting things done on time is priority #1. Google's implementation may not have been ideal, but it was delivered.
Re:Lots of comments on LWN.net's coverage (Score:4, Interesting)
I think thats the whole issue here. Why does Goggle have to do any work to get "accepted" into the main kernel anyway?
The android is an embedded device that works with a small subset of chips sets and devices. Why does it have to be in the main kernel to begin with? Is somone going to be shoving a PCI card in that thing? Heck, why does Google have to spend the weeks/months talking back and forth with the developers when they can get their own solution, that works just as well for them, in half the time?
Talking about "giving back to the community" is all well and good, but I don't expect Google to sacrifice their profitability or deadlines just to make some members of the community happy.
Lets be honest here though, all the code is in GPL so whats stopping someone else from doing the work?
Re:Lots of comments on LWN.net's coverage (Score:5, Insightful)
I think thats the whole issue here. Why does Goggle have to do any work to get "accepted" into the main kernel anyway?
They don't have to. If they don't, however, their codebase and the mainline codebase are going to grow further and further apart, which means that (a) the Android kernel will not be able to easily gain the bugfixes and enhancements that go into mainline and (b) the mainline kernel will not be able to easily take advantage of the drivers written for the Android kernel. Both will lose.
I strongly suspect that what will ultimately happen, as has happened before, is that the Android devs will eventually realize that maintaining their own fork of the Linux kernel is just too much effort and that it is actually less work to do what's required to get their changes integrated into mainline. Many other companies have been through this same process and come to the same conclusion.
Re: (Score:2, Insightful)
Which is perfectly fine, but it shows the autism in the google culture when it comes to working with people from outside. There're many companies working on Linux (doing more serious hacking than Android does), and they have learnt to interact with the Linux community when they want to add a feature. They ask maintainers what design they should follow to implement some feature. They listen, they write code, they get reviews, they make changes, they repost the patches. In other words, they interact with the
Re:Lots of comments on LWN.net's coverage (Score:5, Informative)
Okay. I got off my ass and actually looked at waitlock. It isn't, as I thought, a lock with a restoration of execution context when held, so that one can temporarily surrender other locks, and reacquire them. It is a lock on keeping the system out of various low-power states.
Mainline has an (arguably, according to Google-folk, inefficient), lock on guaranteed service latency (low, medium, high?). and Google wants a lock on specific activity level abstractions (idle, suspend, etc.). Did I get that right?
Well, if the present implementation is inefficient (a linear search...), fix that: use an AA-tree or heap, or something.
I suspect the latency time guarantees are coarse at best and probably map to specific power states (idle, suspend, etc.) anyway. I think BOTH models should be supported (heck, you could always map levels to latencies in some tunable fashion, if you had to fake it: "responsiveness SUSPEND" vs. "hardware SUSPEND") but only because there are already standard abstract notions of what IDLE, SUSPEND, and POWEROFF are.
What may have happened is that the existing implementation was inefficient, not quite fitting the expected model, and Google-folk found it faster to roll their own driven by time-pressure, instead of reworking the existing inefficiencies, thinking "heck, we can layer our API over the existing implementation later" and finding the models are more different than thought.
Reconciling that is called "refactoring" and sometimes it breaks APIs as much as one does not want it to.
Now, who has a vested interest in doing that?
Google? Not really. They figure they can handle the overhead of a kernel fork, at least for a while.
Mainline kernel devs? No. The existing model "works".
I'll tell you who: Google's downstream customers. One of them will do it.
Re: (Score:3, Interesting)
Even if the floor is less round [wikipedia.org]? (Not saying this is the case here. Just pointing out, that ideals can change. Einstein said it best: “Leaving research exclusively in the hands of engineers, we would have perfectly functioning oil lamps, but no electricity.”)
Technical aspects (Score:5, Informative)
"OMG fork!" and other political issues aside, I think it's interesting to look at the technical side of the problem. What is the exact nature of Google's changes to the kernel, why did they feel they need them, and are they actually a good idea or not? Can someone with kernel hacking experience enlighten us?
I'm particularly curious after reading the comments on LWN [lwn.net], and specifically this [lwn.net]:
Kernel developers (including other embedded developers who have achieved good power savings modes) don't believe that the Android way of doing things is good.
and this [lwn.net]:
The code could be mainlined if Google were willing to consider that their wakelock approach was suboptimal and adapt to a more reasonable one. ...
The wakelock patches were first posted to the linux-pm list on the 13th of January 2009, which is just over a year ago. http://lwn.net/Articles/318611/ [lwn.net] gives a good overview of how they were received - there's basically no buy in, even from other developers in the embedded Linux field. ...
the major sticking point (ie, wakelocks) were posted for public review a year ago and most of the substantive issues people had with them weren't addressed at all in the four months of intermittent discussion that followed. If the entire world suggests that you do something in some other way and you refuse to, that doesn't constitute a genuine effort to work with them. Nokia have managed to obtain the same level of power management without such invasive changes, so any assertion that wakelocks are required for Android to achieve its goals seem pretty baseless.
So apparently the issue at the heart of this is a questionable design decision by Google.
Re: (Score:2, Insightful)
I love how they blast Google for not being willing to meet halfway, but they're doing exactly the same thing.
Not that there's actually anything wrong with -either- side, but if you're going to redress someone for something, you should make sure you're not guilty of it yourself first.
Re:Technical aspects (Score:5, Informative)
Some background on this:
Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again?
Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is complete, userspace can release the wakelock and the phone will suspend again.
The problem here is that your wakelocks are tied to your userspace. Userspace needs to know which wakelocks the kernel takes in order to be able to release them. Which wakelocks you want will depend on how your platform is designed. Google have implemented the wakelocks they need to solve the problems they face - other vendors may wish to use different wakelocks. The end result is that you end up with a kernel that can only usefully run with a specific userland, and userland modifications require kernel modifications. It's broadly like saying that it'd be fine for some kernel drivers to require gnome and some others to require KDE.
What's depressing about this is that it's an entirely unnecessary approach. You don't need the system to fully suspend. Modern ARM hardware supports something generally referred to as retention mode, which is where the hardware enters a power state equivalent to suspend without actually performing a full state transition. Rather than explicitly suspending, if there are no tasks to run then the kernel idle routine will put the CPU into this state. When a task is scheduled to run (either because of a timer or in response to an event), it runs.
The stated objection to this is that applications can't be trusted to behave themselves. If I write an Android application that repaints itself by sleeping for a frame and then drawing, that'll keep waking up the CPU. In the wakelock scenario, the system isn't running and so this isn't a problem. In the retention scenario, it'll keep getting scheduled and battery life will suffer.
There's two easy solutions to this. The first is to use the range timer functionality in the kernel. This allows applications to say "I want to sleep for about a second, and can afford this much inaccuracy". The kernel uses this to attempt to merge wakeups - if an application sleeps for a second and a millisecond later another application does the same, they can both be woken up at once rather than causing two wakeups. But we can also take this to more extreme lengths, for instance by changing the accuracy value to a millennium when the screen is turned off. The application won't get scheduled again until we receive a "wakeup" event and set the timers back. The second approach is even simpler - just SIGSTOP all non-system tasks when we'd otherwise release the wakelocks.
So I wouldn't frame this as refusing to meet Google halfway. People have tried to come up with solutions that would meet the usecases that Google want to deal with and which don't end up forcing people to tie their kernel to their userland. Nokia achieve comparable power consumption without any of the wakelock infrastructure, so it's clearly not a requirement in order to hit these targets. What would you expect a meeting halfway solution to look like?
Re:Technical aspects (Score:5, Interesting)
I'm commenting anonymously because I'm closely involved with Android. I'm not going to comment on whether wakelocks are good or bad.
But mjg59's comment about ARM retention state being as good as suspend is blatantly wrong at a SoC level. There are several good reasons why a suspend details is better than retention but I can't go into the details due to NDAs. But I can vouch that I have personally seen power usage shoot up on well known Android phones when suspend is disabled and only retention is done.
So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.
Just to make my stance clear, I'm all for having the Android kernel merged into mainline.
Re:Technical aspects (Score:4, Interesting)
Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.
Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.
Re:Technical aspects (Score:5, Interesting)
So, mjg59, I would kindly request that you stop making such claims. I doubt you have worked on embedded devices -- I believe you work on server level stuff -- but you most certainly haven't worked extensively on the SoCs being used on Android phones.
I have worked on embedded devices - Linux based and others - for over a decade, and mjg59 is right. If you need something as brutal as hard suspend mode, you're doing it wrong. Any serious low power optimized ARM SoC can run down to very low current when idle, and has peripherals which can be individually clocked down and/or gated. I did work in a periphery way on the G1 at Google, and was very surprised at the way power gating was done. Put simply: the only other embedded OS in the same class as Android which does power gating like this is Windows Mobile. Everyone else learned it was unnecessary a long time ago. I was fairly shocked how few engineers had ever done serious embedded work before, and the result shows.
I know the Qualcomm parts have horrendously stupid design decisions in them which prevent decent idle current, but it's a wash compared to the other sources of battery drain. It's also a wash compared to the damage it does to your code design to support full suspend as part of normal per-second operation.
The Linux maintainers are right: Android is just doing it the wrong way. If there's any one feature I think Android could have done without, it's wake-locks. Learn how to use fine-grained clock switching and gating, not brutally-coarse-grained suspend. This isn't a bloody laptop. And no, I'm not saying this as a back seat driver: I really have done this kind of crap for a decade.
Re:Technical aspects (Score:5, Informative)
I love how they blast Google for not being willing to meet halfway, but they're doing exactly the same thing.
It doesn't appear that's the case. It seems Google coded a bunch stuff without consulting other, more knowledgeable kernel developers. Google then announces what they've done and throw it over the wall. The feedback is the design stinks and is very fragile. They also ask why Google didn't leverage the existing infrastructure which is already working, and which seems to have been in place long before Google started, which addresses their very issue. Nokia via their Linux/OMAP ARM efforts don't seem to have trouble using the existing infrastructure.
Google responds by saying the existing infrastructure isn't a complete solution for their needs. The kernel guys ask why Google didn't simply update the existing code to address their specific needs rather than add poorly conceived new code/interfaces. Even the Linux/Nokia guys step forward and state the existing infrastructure is plenty useful and powerful and is easily able to address Google's need with only minor changes. Furthermore, the general consensus is that the required changes can be made such that its fully compatible with their userspace applications.
Google response? Who gives a shit?!?!? We don't need it upstream. Let everyone else fend for themselves. We don't care if it ads bloat and is unusable for anyone else.
Now the kernel guys are left with unmaintained code, which nobody wants, which exists only to add bloat to the kernel, which benefits nobody but Google. Seems to me, Google doesn't care to meet in the middle and they've made it very clear its Google's way or no way. And as result, Android's kernel is more bloated because of it. Seems like a lose-lose for everybody while highlighting just how huge Google's ego can be.
An oldie but a goodie: (Score:2)
Re: (Score:2)
Since when is forking considered "embracing"?
Android is open source so does it really matter? (Score:3, Insightful)
That's the point of open source code. Claiming something is open and all about freedom and then trying force everyone into doing what you think should be done is neither really free or open.
In summary... (Score:3, Informative)
Google has silently forked the kernel. There is an 'Android' kernel, and the mainline kernel
Is this the first time this has happened?
Will it matter?
Apparently, this is reasonably well understood [theregister.co.uk].
I, for one, welcome our Android kernel overlords. My phone doesn't need server optimizations.
Re: (Score:3, Interesting)
Example?
N900? Heavily marketed as something a lot like the G1. Usually as a 'Mobile Internet Device and Smartphone'. I interpret that as an even more general-purpose mobile platform. They chose (probably because they started before Android was) to not use Android, the alternative was, um, Linux. And I see them not going to Android, I think they mistrust Google even more.
This is an area where there is disagreement. But phones DO have different needs. Obviously. Nokia accomodated those within the mainl
Re: (Score:3, Funny)
Courtesy of the google translator ...
Still no idea what it meant. :-P