The solution to that sort of optimization is to delegate it to drivers. And providing and debugging drivers is a big part of what OEMs have to do (actually, the drivers are provided by the hardware vendors -- OEMs don't make the bits and pieces, they put them together -- but generally as source code and OEMs tweak and fix).

There are about ten web sites in the world that could actually have servers in thousands of locations without going bankrupt.

You don't need a server. You need a COTS router running OpenWRT and OpenVPN (with hardware acceleration), a couple of well-placed antennas, and a commercial- (not carrier-) grade symmetric DSL, cable, or wireless connection.

In other words: You don't need a million spinning-disks server with its own abilities to serve content, you need a a million low-power NAPs with a gateway to your own content.

How much traffic does google.com see from my small Ohio town of ~45k citizens? Answer: Not enough to swamp a well-proportioned 802.11a link. Or a 45Mbps T3. Or a 75Mbps symmetric DOCSIS connection from TWC...all of which are cheaper than hosting actual servers on a mesh.

An existing Internet service that wants to be on a local mesh doesn't need a server, per se, but just a point of access to their existing servers.

And I'm sure I won't be the first to volunteer my resources (land, electricity) in exchange for them to do just this, as long as I get fast Internet and a mesh node in exchange. If I get a fueled and maintained standby generator to use, too, I might even pay them to let them use my resources...but either way, it's win-win.

(What if a node fails because COTS routers are shit, or power is out, or TWC has fucked up that branch? Who cares. There will be other nodes, they'll just be a few more hops away than usual. Yay, redundancy.)

(Oh, you're a small website? Akamai has a theoretical mesh package for you! And I'll gladly use an Akamai mesh node as a warm footstool, after I build the tower, string the cable, and align the antennae while I bask in the warm glow of fast and free Interwebs for myself.)

Your notion of "optimizing for the hardware" is something that isn't real. According to your theory, Linux also shouldn't perform well because it also is hardware-agnostic.

As for what OEMs have to do, a modern mobile device is immensely complex, consisting of dozens of processors, many on the SoC (system on a chip) but many not. All of them have to be configured, which is a complex and tedious operation, and easy to get wrong -- and every custom board requires a custom configuration. In addition, there are drivers for all of the bits and pieces that have to be assembled and tested together. Plus there's also typically a complex, multi-stage boot process that has to be orchestrated to bring up all the bits and pieces of the hardware in the right way and in the right order. And other stuff that I don't know about because I'm not a hardware systems guy.

Some of the above doesn't depend on the OS, and can be done before it's available. But much of it does depend on OS requirements and has to wait.

And then if the OEM decides to customize Android they have to do that, with whatever skin, and default apps they want, plus whatever changes they need deep in the system to support the hardware and their changes to the software. Finally there is lots and lots of testing, because such complex, custom devices always expose new interactions between components that have to be debugged and fixed. Oh, and lots of hardware testing as well, including endless burn-in tests to validate that the stuff not only works but that some subtle design flaw doesn't stop it from working.

And I'm sure there's still more that I don't know about at that level as well.

Then they have to run Google's compliance tests, to find out what they've broken with all of their changes, or what they missed in configuring their device for proper support (actually, this is something they do throughout, not at the end), and then go back and fix what's broken until it passes... or else negotiate with Google for waivers on things they think should be okay.

Then comes carrier validation and testing, more rounds of fixes, etc.

Little or none of this has anything to do with "optimization". That's mostly the compiler's job, and it does that job well.

I had a fancy-ish Panasonic for about 13 years, including a variable-speed magnetron (which is a hell of a neat trick). I recently gave it to a friend when the SO downsized it; I expect it to live at least another 4 years of regular use.

It was neither particularly cheap, nor alarmingly expensive when I bought it. Other than some of the superficial silkscreening being being rubbed off from cleaning, it looks and performs like new with zero maintenance over the years.

Aren't they all like this? I don't think I've ever seen a microwave oven retired simply because it suddenly stopped working.

My grandparents' 1975-ish Amana RadarRange was still working fine when she died a couple of years ago.

Remember to include the manufacturing energy consumed to replace it every 10 years.

Why do people keep talking about the energy used in manufacturing as if it is a separate thing? That energy is already built into the purchase price of the item, from the energy consumed by the machines digging the ore to the truck delivering the finished product to your doorstep, and including all of the energy which in turn was used to produce those machines.

It doesn't need to be factored separately. It's already a part of the equation.

That said, the primary energy savings in a new-fangled front-load washer/drier combo seems to be in having a better/faster spin cycle: The less-wet that the clothes are after they exit the washer, the less heat energy the drier needs to use to finish the job of producing dry clothes.

(And none of this beats a washer (any semi-modern automatic washer) and an outdoor clothesline, weather-permitting.)

Don't get me wrong, I think that ARM has a great story to tell for phones and tablets. There power conservation and efficiency dominate. Once you leave that space then ARM is in a different world of expectations, with different business models and all the rest. That's why I always think that ARM servers are a bit of a fantasy. There are a lot of deluded people talking about how ARM is "gonna" revolutionize servers, and desktops. Yeah, so where are all these great products I keep hearing about?

You mean like the Corel NetWinder? You heard it here first, but the year that the power-efficient ARM server is going to change everything is 1999.

You'd only need to do it once- an app in force stop state should not be restarted on reboot, as its inelligible to have a BOOT_COMPLETE receiver.

I'm not saying it shouldn't be improved, I was telling the OP how to fix his problem.

Authoritarians, of both the "left" and "right" wings, love to use government force

Agreed, look no farther than reactions to the war on drugs. A local government banning Big Gulps because it's bad for you is government overreach into areas of your life and people should have the personal responsibility not to overuse, but we need to spend billions of dollars at the federal level to prevent people with no personal responsibility from smoking a plant they grew in their own backyard because it's bad for you.

You know, in this fucked up world the poor worker could still get a lecture from his manager for doing the right thing because "it could have been a prank" and "we could have been held responsible if anything happened".

There is no such thing as a Pizza Hut where the staff reads the stuff you write in the extra line.

True, but if anyone freaked it might have ended badly.

well, it would certainly make finding a seat on the bus easier.

Er, nothing actually. TFA mentioned "Microsoft's take on Unix", which I took to mean NT's stab at POSIX support, or maybe something else equally ridiculous. Looking at the article again, it actually says "Xenix, Microsoft's take on Unix". Not being more than vaguely aware of Xenix, I didn't realize it was bought by Microsoft and I took that text as two separate items in the list (should have paid closer attention to commas vs semi-colons).

Indeed. There I claim selective memory, driven by the massive stain on the Unix world left by SCO's successor-in-ownership, The SCO Group.

I heard good things about Coherent back in the day, but never touched it.