Why does that seem unreasonable to you? The average user shouldn't be blanket disabling Javascript, as doing so will break 99.9% of the internet (including this commenting system).

AT&T does though, as do a number of MVNOs and a couple of local carriers like Cincinnati Bell. Yes, AT&T is stupidly evil, but I'd argue no more so than Verizon, and at least they're GSM/UMTS.

What? Samsung already fabs (and until recently, essentially designed) all of "Apple's" SoCs.

By what, exchanging it for suffocating domination by ARM and Google? Much better.

It doesn't, but then again that isn't what this stage of testing was about. But hey, I get it - reading to the end of the first sentence of the summary is a lot of work. A busy man like you can't be bothered to invest that much time before rushing off to enlighten us with your genius commentary.

Wait...to die by liver failure? Which is slow and excruciatingly painful, thus totally defeating the point? Great idea!

Really? The rounded corners of the housing, the screen, and the earpiece combine to form the face of the iPhone? Those exact elements had never existed in that combination before, then?

That's a really odd choice of counter-example, since large orchestras like that typically do make the majority of their money through live performances and recording the soundtracks for other productions, rather than through record sales.

Except that Apple totally does have a design patent on rounded rectangles: http://www.google.com/patents/USD618678

The only things that aren't broken lines? The basic shape of the housing.

An ARM processor doing binary translation for x86 would be like trying to tow an 18-wheeler with a Tata Nano. ARM may be low-power, but it's also...well, low-power. Even older Core 2 chips wipe the floor with ARM's latest and greatest from a performance standpoint.

Java can be used to write true cross-platform applications for Linux, Windows, and OS X. It is also the primary language for development on over two-thirds of the world's smartphones and nearly half of the world's ARM tablets. I do know Pascal, but haven't used it in ages. I also know C, but again, rarely use it since I'm not a Linux kernel developer. I once coded something in Zilog Z80 assembly (and you didn't specify!), so I guess I have my trifecta of pretentious covered. And yet when I have to actually do work, I use Java. Like everyone bloody else.

I've always assumed that was kind of the point. Windows RT strikes me as the "embrace" phase of the Wintel Master Plan To Deal With ARM®.

According to ARM's documentation of the Cortex-A9 FPU it takes two cycles to perform one double-precision FMAC operation. 1 GHz * 2 cores / 2 cycles per operation = 1 GFLOP, assuming ideal conditions and zero overhead. In practical scenarios, 300-400 MFLOP is probably about right. And now that I think about it, the figure they list may already be for a dual-core, since Cortex-A9 was never intended to ship in a single-core configuration.

There are a ludicrous number of errors here. The summary says that the CPU is clocked at 1.2 GHz, which the screenshot clearly shows is not the case - it's 1 GHz. The quad-core Galaxy S III only has 1GB of RAM, and the LTE variant with 2GB of RAM doesn't have a quad-core CPU. And both the HSPA+ and LTE Galaxy S III's score well above 1600 on Geekbench when actually running on all cores - the test results that are below 1600 and are no-doubt included in this "average" are custom tests run on fewer cores, which is clearly shown if you actually browse the results.

The problem is, the Source engine already exhibits a lot of really bizarre performance behavior. They say that on Linux with OpenGL they're seeing performnace improvements over Windows with DirectX (with no mention of IQ), but on Windows the OpenGL engine is slightly slower (~10%), and on OS X the OpenGL engine is about 65% of the speed of the DirectX implementation on Windows and has noticeably lower image quality. Source also has wildly different performance on otherwise comparable AMD and nVidia cards. I've even had systems that used to run TF2 just fine a year or so ago, and now are a stuttery mess with the same settings on the same maps with the same number of players, for no readily apparent reason. And of course we're dealing with framerates in the 300+ FPS range for the Source engine on high-end hardware these days, where huge differences can be the result of otherwise tiny factors, as actual GPU performance is marginalized next to things like driver overhead; that wouldn't be the case for, say, Unigine or UE4.

I think if we're honest, Valve's big complaint about Windows 8 has nothing to do with "performance" or expected sales, it's more about "waah we were about to launch an application store but now thanks to Microsoft's we won't have a virtual monopoly on that for Windows."