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 ..."
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:One sentence to say it all... (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:One sentence to say it all... (Score:2, Insightful)
So then maybe they shouldn't have kicked the android code out of mainline in the first place?
Re:Google (Score:3, Insightful)
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.
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: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, 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:Google (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.
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: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: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:Google (Score:0, Insightful)
Sorry, I haven't noticed.
Please elucidate. Please give me a list of the top three Linux devices and their sales volumes compared to, say, symbian, rim and iPhone.
Or perhaps you can explain some of these http://w3counter.com/globalstats.php [w3counter.com] stats and how Linux, Android and WAP come in at less than 2% with regard to your "irrelevant" statement.
Dammit, you're trolling, aren't you? Well... Fool me once, strike one, fool me twice, strike, uh three.
Re:not quite... (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: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:Technical aspects (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: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."
Re:Lots of comments on LWN.net's coverage (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 community, they are a part of the community. SGI, for example, has done a tremendous amount of work in the past years to get the kernel in shape for their beasts with thousands of CPUs, they have touched a lot of complex core code, yet they did all contributing with the community, targetting the main kernel in first place.
Google, in the other hand, is not a "part" of the community. It hacks the kernel for months without any contact outside of Google, some day it announces a future product using the code and only after that, it drops a shitload of code to the community which does very weird things that many Linux hackers don't like. Then it does nothing to improve the design (because there's already production code depending on it), and it makes zero efforts to fix it or get it merged. Then it claims that everything is fine, because the code is GPL which means you can reuse it. In other words: Google doesn't care about what the rest of the community thinks before modifying the code, and it doesn't care when it releases either.
Given that Android is supposed to be not just a Google project but a community, and Google is a opensource oriented company, one would expect that Google would have done it better. Sadly, Android has become one of the best examples of how not to work in a opensource community,
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.
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:Google (Score:1, Insightful)
Yeah but that is mainly because of their hold on the market for cheap, dumb phones.
What, you mean by far the most popular phone choice across the world? Not everyone wants a smart-phone or to be held ransom with exorbitant data plans to use the expensive device. The vast majority of the world uses phones to talk, how strange.
Re:Google (Score:3, Insightful)
Please spend two minutes looking at Google.org.
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:Wait, I take it back (Score:2, Insightful)
Uh patent trolling? Nokia is one of the companies that actually deserve any patent they hold. They have spent millions in generating the mobile technology we all use today.
Btw, your signature having a link to your money making "iPhone app reviews" website kind of makes you biased.
Re:Google (Score:2, Insightful)
But which hardly translate to Linux having "won that already" when their combined percentage is around 10%.
Re:up merge justification has to be Android-agnost (Score:3, Insightful)
Re:Lots of comments on LWN.net's coverage (Score:2, Insightful)
No one except Red Hat, IBM, Oracle, Sun, and thousands of embedded hardware manufacturers the world over. Other than that, though, NO ONE!
Re:Google (Score:2, Insightful)
Linux won? Citation, please.
Re:Lots of comments on LWN.net's coverage (Score:2, Insightful)
It's like Einstein said, "I didn't say half the shit people think I did."
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.
Re:Google (Score:5, Insightful)
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:Couple of things to say... apk (Score:1, Insightful)
Man, if you have posted here 6 years, just please try to learn to type like a normal person. No one would be trolling you if you didn't post like this. Your text is really, really hard to read. It itself comes out as trollish. Replace the @'s with at and &'s with "and" and don't use so many unnecessary ". Your points might be good but no one bothers to read them like this.
Re:up merge justification has to be Android-agnost (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) 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.
Re:Google (Score:3, Insightful)