Linux police offer deviant Android return from exile Linux kernel maintainers have offered Google three ways of returning Android into their good graces. Google's options for re-admission to the kernel are: put the stubs of Android's wait locks into the main kernel, introduce Android's wait locks as PMQOS constraints, or adopt a patch written by a Linux kernel maintainer that …
In the end if, if a phone CPU does not share its owner's attitude to missing a phone call, the phone will fail as a product. This is an issue which will have to be resolved somehow if Linux is to be a serious player in this market. I do not know the technical rights or wrongs of it, but it is good to see that at least some people involved see the sense in coming to some agreement. Let's hope that little spat is soon to become history.
Mike is quite right here, the dilemma is that the phone is the primary device that Android is there to make work, just as a regular Linux distro makes a PC work.
Imagine if your DVR skipped the last five minutes of a film it was recording because the Linux distro it was running decided that it was more important to download and install some software updates - you wouldn't be pleased.
I know this is not a direct analogy but there has to be a "socially acceptable" way forward, as quoted in the article, to bring Android back into the mainstream. Yes, Linux does need Android, but Android also needs Linux and the OSS community, in fact it wouldn't exist without them.
> Imagine if your DVR skipped the last five minutes of a film it was recording because
> the Linux distro it was running decided that it was more important to download and
> install some software updates - you wouldn't be pleased.
I would be far more worried that the system was offline during a recording because the OS allows the software to "run amok" and "run the show".
And yes I have have been using Linux based PVRs of one form or another for more than 10 years.
Of course this whole discussion is going on at a level of the system not adequately captured by your "example".
we're talkin Linux kernel.
I don't think Linux needs Android at all. But that doesn't mean we cant all gain by some sensible co-operation.
We're not talking about DVR skipping due to updates - its a much lower level than that.
A Linux kernel is more than capable of performing all that is required to work as the best phone you've ever seen. Either the Android developers didn't take time to understand the kernel properly before getting in too deep or there was always an ulterior motive to the way development went.
Actually, AT&T (you know, those people that originally wrote Unix) made their reputation based off the idea that phone hardware should be selfish. It should first and foremost ensure it's own survival and then to treat the service of end user requests as entirely secondary.
This approach worked out very well actually.
"Pandering" isn't always the best approach.
Seems Linux needs Android more than Android needs Linux.
I think Google should give them the finger and then ride off into the distance after the arrogant way the Kernel maintainers initially couldn't care less about Android and then did an about turn when it started taking over the world...
Replace the words Google with Apple and Android with OS X, and you've got another generic fanboi article that will attract downvotes like flies to crap.
Is there some sort of list of article templates you fanbios use or something, and you just stick in your platform of choice then cut-and-paste into whatever forum you're drooling in?
Oh, and the best bit has to be the bit where you don't see the irony/hypocracy of calling the KD's "arrogant" while proposing Google rides off into the sunset. Classic stuff. Kudos.
The Linux kernel maintainers will work with the Android developers on this one until the Android patches are in a state which makes the combination long-term maintainable. This means that the extra functionality implemented in Android can't be allowed to degrade anything needed by other kernel users and works in a manner which others wanting the same or similar extra functionality can use and work with.
Until then Google will have the extra cost of having to maintain their fork, compared to the smaller cost of maintaining the code which does what they want as an integral part of mainstream Linux. That is how significant improvement generally occurs in libre software, and it is why people who share the same set of requirements will more often collaborate on a mainstream version of something if they can, in preference to having the extra expense of maintaining everything in more than one place.
Occasionally a fork has to happen if the mainstream direction loses credibility within the developers, as happened with the successful transition from X11 to X.org . But for this to happen requires a leader with the clout to bring the developers along to the new model, and as far as Linux is concerned, no-one is challenging Linus' leadership AFAIK.
Whether the Android patches are accepted as part of a particular kernel version isn't as important as getting the changes right before they goes in.
Sigh!...
I regret that Google/Android is in danger of becoming arrogant, too powerful, thinking they run the universe (errr... they kinda do..) and starting to behave the way other actual/defacto/well-I-think-I-am all-powerful monopolies...
'twill take a bit of time to shake out. I do hope Android comes back into the Linux fold (I use both) but suspect Google will go the way of (almost) all large merkin corporates...
Cheers!
Just not to that pissing show called linux.
FreeBSD
LLVM
TrustedBSD
WebKit
and more
and when they do contribute, it is freely and openly, with a real open source license.
Google don't contribute, they occasionally code drop from the secret development process. Thanks, but no thanks.
They tend to take a project already in existence, add some ideas of their own and then claim all the credit. Or more usually, their fans give them all the credit. Apple's support may make a project more popular, but it can hardly be doubted that what they gain from Open Source is far more than they give back. Without Open Source they would have spent far longer developing OSX. Without Open Source they wouldn't have any server platform. Without Open Source they wouldn't have a browser. Please don't try that old chestnut that Webkit is the best browser engine just because of it's Sunspider benchmarks. Each of the engines has it's own strengths, and webkit is certainly a good one, but fanbois would have us believe that other browsers are barely capable of rendering a webpage in comparison.
It's hard to find any actual developers from the projects that Apple are involved in making comments. I did see someone on the FreeBSD project thank them for the Mach kernel, but the Webkit project was fraught with dispute, as was the Darwin project.
Android is a "serious player", with the zillions of handsets sold, etc. But Android isn't Linux, because of this whole dispute. If they resolve this dispute and reintegrate it, then it will be Linux again, but if not then it will be something that was built *from* Linux, but isn't anymore. Granted, right now they're practically identical, but if they don't get reintegrated, then they are likely to diverge further over time, eventually becoming very different things indeed.
Would that be as different as, say, a supercomputer cluster is to a handheld communications device? It may well be time for the one true kernel to split in order to better service the increasingly disparate demands of the embedded systems/small device market and the large desktop/server/supercomputer segment. If it doesn't voluntarily do so, it may well fragment into a lot more than just two, with the 'official' Linux ending up a bit player on the sidelines. I can't see the current 'Jack of all trades, master of none' going much further.
Evil Jobs? Nowt to do with this post, I just don't like the git.
Why are people trying to hammer a square peg (Android) into a round hole (the generalized desktop/server kernel)?!
A real-time operating system, and an OS which needs primarily to drive a phone, are naturally going to have different requirements than a general desktop/server OS.
So, quit trying to create a gargantuan thing which serves everybody's needs, _poorly_.
Duh.
If memory serves, you mean "wake locks", not "wait locks". They're also known as "suspend locks". Whatever they're called, their purpose is to stop the machine being suspended while the lock is held and have been somewhat controversial.
The idea is quite useful in a phone where there's a fairly aggressive suspend mechanism to save power, but one which you don't want kicking in at an inopportune moment -- like selecting stuff from the screen which would make perceived performance suck.
Actually Google sold very few phones - that's why they killed it. Just about the only company selling fewer phones was Microsoft with their unloved KIN.
<patronise>
What you mean is that lots of Android phones are being sold (which in itself generates zero revenue for Google). As these are smart phones they are likely to add a few web-clicks to sites that generate ad revenue for Google.
What Google is probably aiming at in the long-term is a variety of Android-based devices that are dependent upon Google's search, e-mail, cloud, etc. displacing regular PCs and laptops - thus generating a lot more revenue for Google.
</patronise>
it has been said already but I'll say it again. If I press the power-off button, I the phone owner/user is in control and I want the phone to shutdown. I dont want it doing something else instead. The phone is not HAL from 2001: A Space Odyssey.
It makes no difference kernel maintainers or Google getting on their soap boxes.
My TV does not stay on when I press the power-off button when a news flash or one of those valuable adverts is broadcast and so my portable devices (including my Android based HTC Desire) should go off pronto. Have people forgotten that you switch your phone off for a damn good reason and not just for fun?
Off is off.
> Off is off.
Really? like your desktop system, where pressing the "Off" button is a servile petition to the god-like operating system to stand down and take a rest if it's not too inconvenient, shutting down the hardware in the process? That becomes slightly more urgent if you hold it down for ten seconds?
And your TV, if it's new enough to use integrated circuits, only goes into "standby", not off. Off is when you pull the power cord.
G.
I am not exactly sure what to say.
1) You are turning the phone off
2) you get a phone call
3) android expects to cancel the "shutdown" and allow answering the call
The problem is solved very simply.
1) I requested the phone to turn off
2) the first thing the phone does, is disable the user interface component responsible for showing me there is a phone call
3) the phone is receiving a call, but is shutting down, so marks the call as "missed"
4) the phone shuts down
5) I am ignorant of the missed call until I restart my phone.
BINGO! Why is everything in life so frigging complicated.
if I'm shutting off my phone, tough luck buddy, you're missed call will just get logged and when I turn my phone back on, I'll see the missed call. It's a very simple problem, I can't see why it takes geniuses with PHD's to argue about it.
The Linux kernel community has a long history of Not Invented Here syndrome. Just like the whole Xen/KVM thing.
Because Google wrote the code, it will never be integrated as-is to the mainline kernel, period. The only way to get it integrated would be to make the code subpar, which would please the kernel devs.
The song & dance from the kernel devs is getting old.
Personally I think Google should just port Android to NetBSD and tell the Linux kernel devs to stick their ultimatum where the sun doesn't shine.
Anon to avoid the fanbois.
It will be resolved. Google is a part of the greater Linux world, it is just having a hard time keeping pace.
The Kernel of Linux is the largest, fastest moving software project, in the history of computers.
That pace is awesome. Most people not involved are simply unaware of the scale of it. Technically speaking... it is history in the making.
speaking at/with Google:
http://www.youtube.com/watch?v=L2SED6sewRw
It is the kernel... Google needs to keep up, forking is not an option, they know that if they do, it will not be long before they are just left behind.
Run Google / Android, run fast.
From the article description, it doesn't seem to be about "good" or "evil". Google can concentrate on the Android and develop nifty solutions to phone-specific problems, Linux kernel has to work on an incredible variety of hardware combinations.
If the change is new locking in the kernel that works similarly to other locking in the kernel, and potential new race conditions, I understand why kernel developers don't want it.
If the change is new locking that works differently from old locking mechanisms and is handled separately from old locking, I'm happy current kernel doesn't have it.
Introducing race conditions is easy, finding them and getting rid of them is seriously difficult. I can see the best kernel developers bogged down for months just tracking down odd, transient problems in common hardware combinations, and then removing problems that only come up with rarer hardware every now and then for a few years...
"I think Google should give them the finger and then ride off into the distance after the arrogant way the Kernel maintainers initially couldn't care less about Android and then did an about turn when it started taking over the world..."
Well, to be honest, there's plenty of embedded devices that just permanently run their own custom Linux kernel -- even 2.2 or 2.4 versions -- and it's fine. But that's not what Google wants, they would like to contribute back so they can have a (nearly, if not fully) stock kernel.
And you GREATLY **GREATLY** misunderstand the situation if you claim the kernel maintainers were arrogant. They were not. Google impleneted a video driver using *it's own* video stack, rather than the existing framebuffer system either as-is or patches. They implemented *their own* security model, rather than using (or even patching then using) the very flexible security system in place, honestly I think ACLs (access control lists) could have done everything google is doing with a custom security model. Google made *their own* types of locks, when there were already at least 4 or 5 types of locks already in the kernel, several of which would appear to directly do what Google needed already. This was all perfectly reasonable to get a kernel up and running, and I don't blame Google at all for doing it this way. However, this kind of thing CAN'T be allowed into the mainline kernel, or by now every internal bit of the kernel would have a dozen different implementations used by various bits and drivers.. I mean, hell, there were *4* wireless stacks at one point!
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
