That has to be the stupidest virus on the planet. Why would you want to do this I mean, sure, you annoy somebody for a day or so, possibly make them spend money to get it fixed, but then the problem is solved. The most successful viruses are ones that nobody knows are there. You can then spread to other machines silently without anybody knowing. Then the virus gives you remote control over the machine so you can collect valuable information. If you really just want to annoy the user and break their computer, you could probably just have the virus flash the BIOS with some invalid firmware.

ianal, but I think 'free to go' means free to move about. it does not mean you have to change (x,y) locations right there at that moment.

I can see you're a young'un. Borland didn't make "compilers for Windows shareware developers", Borland was the dominant maker of high-quality Pascal, C, and C++ development tools for the PC platform for many years, for DOS and Windows, especially DOS. Borland's overlay manager was fantastic and made large DOS programs (programs that used more than 640K) very easy. Microsoft eventually managed to shove them out, but Borland was by far the better tool set for years, and was the choice of many professional development shops. It's what the software companies I worked for in the early to mid-90s used.

I think what eventually did them in was their decision to try to offer a better Windows API than that mess that was MFC. Borland's Object Windows Library was orders of magnitude cleaner and better thought-out than MFC, but because they had to wait for each release of Windows before they could update it, it lagged behind MFC in functionality. Probably also because the OWL team took the time to think about how to do things right, rather than just slapping a thin pseudo-OO wrapper on the Win32 API, which was MFC's approach. So Windows devs learned that if you wanted to stay current, you needed to use MFC, hence you may as well use Microsoft's whole tool set, since you had to buy it all (several hundred dollars).

These day's Duff's Device is almost always premature optimization, because compilers will unroll most loops for you. You should only use it after profiling to prove that the loop is a hot spot, and after benchmarking to prove that it actually improves performance. Even then you should include both implementations, selecting one by #ifdef, so you can periodically re-test, because eventually a new platform or new compiler or something will result in it no longer making a difference, or even being more expensive, if the compiler is cleverer than you.

Depends on the sort of code. There is lots of code that needs to handle, for example, large classes of error codes, and for 50 codes there may be only two or three sensible ways to handle them. Being able to have big lists of cases that nearly all fall through is very nice then.

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.

Per Wikipedia, Microsoft licensed System 7 from AT&T and called it Xenix because AT&T wasn't licensing the UNIX name.

And I didn't "come at you". I thought the second sentence of my second paragraph made that clear. Sorry if it wasn't.

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.