Slashdot Mirror
Android and the Linux Kernel Community
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 ..."
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.
"Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on."
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.
Have you heard about SoylentNews?
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.
In Liberty, Rene
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
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
You can use Android, but you're now dependent on Google for maintenance, bug-fixes, and trusting that they don't include any evil bits.
Courtesy of the google translator ...
Still no idea what it meant. :-P
Lost at C:>. Found at C.
If you head over to LWN, we've already gone back and forth on this a bit. http://lwn.net/Articles/372419/. The short form is that if they don't like how we use the kernel, we're unlikely to be accepted upstream. It's all still released as source code to the world, but the mainline is not interested in most of what we've with to the kernel.
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
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.
Tired of Political Trolls? Opt Out!
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. :)
Tired of Political Trolls? Opt Out!
"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, and specifically this:
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:
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/ 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.
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?
I suspect this isn't clear cut and there is more than a little "Google is too big we must hate them now" attitude. The fact is Android is open source and anyone can take their code do what they want with it just as Google can take any other open source code and do what they want with it.
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.
"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.
Tired of Political Trolls? Opt Out!
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.
I, for one, welcome our Android kernel overlords. My phone doesn't need server optimizations.
deleting the extra space after periods so i can stay relevant, yeah.
Kernel development isn't driven by the product needs but by egos people maintaining it. In that sense it is no different to any closed source kernel. The only option to get things done quickly is to fork it and then hope to get it merged later. Linus isn't exactly known as "accommodating" and "reaching out" individual and merging code upstream isn't exactly a priority on Google product schedule so there.
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.
Help stamp out iliturcy.
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) where the interface between the driver and other (non-kernel) software changes far more rapidly than the interface between the driver and the kernel (and especially for 3d graphics, where the driver contains an entire thread stack, JIT compiler, etc.).
Good programmers will tell you that the driver belongs next to the component to which it is more tightly bound by a rapidly-changing API. Linux programmers will tell you the driver belongs in the Linux kernel so LKML can keep it up-to-date with changes to the mostly-unchanging kernel/driver API (and you can only make changes to the more-rapidly-changing driver/userlevel API during the merge window every three months). And to an extent Linux programmers are right - in an ideal world, the driver should be refactored until the driver/userlevel API is not so rapidly changing, at which point the driver should indeed live in the kernel. It's very easy for a Linux programmer to demand such ideal code as the cost of merging it into the kernel; it's much harder to take a "good enough" system and achieve such a high level of perfection, especially when merely achieving "good enough" is a target that moves fast enough to consume almost all of a programmer's time.
The two camps will never see eye-to-eye; both are completely convinced that they are correct.
A witty [sig] proves nothing. --Voltaire