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:Google (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:One sentence to say it all... (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 anything about it. However, I can help the Linux kernel with something better and more useful than that will ever be."
Unfortunately, few people think like me...am I just nuts?
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.
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: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.
Google has just TIVO-ized the kernel (Score:3, Interesting)
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.
Re:Google (Score:2, Interesting)
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: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.”)
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?
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: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: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 has just TIVO-ized the kernel (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.
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: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:2, Interesting)
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.
Unfortunately, this is Google's standard operating procedure. Don't get me wrong, I like Google and enjoy tinkering with Android, but its far from perfect. And don't make suggestions to the core developers as some are more than happy to give you the middle finger for simply not bowing to their brilliance. Some of them are pretty good, but some are brilliant at being assholes. I mean, look at some of their widgets. Eeek! Its as if the people who wrote some of the widgets had never actually used UI widgets before. Saw someone politely make suggestion and the Google engineer rudely ignored them after telling them they were wrong.
Should double clicking of a button, which opens a new window, result in two new windows being opened? No. Shouldn't widgets maintain state? Yes. According to Google's they do yet cancel doesn't actually cancel despite the fact they've already notified the user of the change. Its up to applications to actually track state and cancel it. So on and so on. If a widget's cancel doesn't actually cancel, I don't believe that qualifies as stateful.
Despite Google's assurances everything they do is better than anything you could ever do, sadly the truth is nowhere near. Google very much has a problem with not invented here and in some cases, a complete lack of consultation with people who actually know what the hell is going on. As a result, some things Google does are just truly horrific, lacking any clue, forcing developers to add lots of code to work around their huge ego and seemingly lack of real world experience.
I'm posting anonymously because some of the Google engineers also hold petty grudges.
Re:Lots of comments on LWN.net's coverage (Score:1, Interesting)
So maybe they need to ship the fork in the short term, meanwhile get engaged in that lengthy debate on something everybody agrees with, and get that working for the next release. Problem solved?
Re:Google (Score:1, Interesting)
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: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 serving on Apple's Board of Directors while they were developing the iPhone. It's not hard to see why Steve Jobs might have taken it personally when he found out Schmidt's company also happened to be developing a touchscreen-based smartphone platform. The non-evil thing to do would have been for him to resign for the board as soon as it became clear Google would be competing with Apple, yet he stuck around until the secret was out.
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).
Btrfs vs ZFS (Score:1, Interesting)
http://www.codestrom.com/wandering/2009/03/zfs-vs-btrfs-comparison.html
Re:Google (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 more significant than Chromium, which is little more than a GUI wrapper round WebKit.
Re:Google (Score:2, Interesting)
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.
If you read TFA (sacrilege I know), you learn that the problem is that the changes need to be made both in the Android kernel code and correspondingly in the Android userland, and only Google can change the latter.
Re:Google (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 SmartPhone rush. Just like Apple missed the Personal Computer rush way back when.
A phrase from the movie Pirates of Silicon Valley -
Jobs: "Mines Better!"
Gates: "It doesn't matter."
And i think this is the case again, maybe too early to tell but i just see so much development being done for iPhone specific apps and websites these days i find it difficult to believe Google will get the same attention so easily.
VHS vs Beta, MS vs Mac, Guitar Hero vs Rock Band, iPhone vs Andriod
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: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:One sentence to say it all... (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] Recent OS X suspends processes that try to allocate when memory is full, reserves a small amount of memory for root, and lets you quit apps to free up memory or delete some files to make some space available for swap. Processes can also set a flag indicating that they have no unsaved data. When this is set, the system can kill them at any point to reclaim their resources and restart them later.
Re:Google (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 kernel, major parts of Android 2.x won't work properly. Work is underway, but the fact is, right now... today... my Sprint Hero is running a hacked-up build that can be described as a liquefied Cupcake injected into the clay mock-up of an Eclair facade. And I'm "lucky" -- my other CDMA Android 1.5-shackled brethren can't even do *that*.
Right now, the cruel reality is that people who buy many Android phones are kind of like consumers who bought a very, very proprietary Packard Bell or HP computer in the mid/late-90s. If the manufacturer didn't feel like supporting Windows NT or Linux, you were basically screwed. You couldn't just download OEM drivers, because they didn't exist -- the company who sold the computer WAS the OEM. Open-source drivers didn't exist, because the hardware itself was built around proprietary ASICs designed for that specific manufacturer.
OK, let me make the analogy a little better: it's 2000, and you need to buy a new laptop. Your ISP allows you to choose between exactly two laptops, both sold only by the ISP itself with a 2-year contract that has a substantial penalty for early termination. Your ISP personally knows the MAC address of the network interface for every computer it sells, and refuses to accept network traffic from any network interface whose MAC address isn't in its holy database. It's not necessarily *impossible* to spoof an official MAC address with an unapproved laptop, but it happens to be a major federal offense that can be prosecuted as an act of terrorism, narcotics distribution, or organized crime. The laptops are only available with an old, obsolete distro of Linux that's proprietary to the laptop's manufacturer, and the hardware drivers are all compiled straight into the kernel (which happens to be 2.2, even though 2.4 has been considered mature enough to use for at least the past 6 months). Oh, the source? You won't see it until 4-6 months after you buy the laptop -- if you're lucky -- and the code for the proprietary hardware will be obfuscated & devoid of comments.
Welcome to the brave new world of Americans who buy Android phones in 2010, where "open" phones have to be hacked & rooted to allow upgrades, and it's easier to upgrade an old phone to a newer version of Windows Mobile than it is to upgrade a 4 month old Android phone to a newer version of Android.
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:In summary... (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 mainline (?) kernel. Google drove Android in a very different direction.
Let's not get into the Maemo thing. It's just a little different, not quite as much as Android.
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.