Vishera is enough of a step up that I think there's still hope for AMD. I only own one AMD processor (and at least 3 Intel ones) but the 8350 looks good enough for its price point and I guess I have a certain degree of "support the underdog" here. Nobody wants Intel to be even more of a monopoly than they are right now. Granted that the 81xx series was a huge disappointment, but that doesn't mean the company is automatically doomed to never again be relevant. The original P4s from Intel were crap too...
Also, AMD has apparently hired some really top talent in microprocessor design, and it came late enough in the 83xx design process that the design was already set... but supposedly there's some real hope for the next generation or two.
Nitpick: 22nm, 32nm. You may be thinking of Angstroms, which are 1/10 of a nanometer. Also, AMD has 28nm in their GPUs; I'm not sure why their CPUs are still using a 32nm process.
I just built a from-scratch brand new system. Every part from the mobo to the graphics card is current-generation and fairly high-end. While Win7 SP1 didn't have the drivers out of the box to use its network interface (somewhat surprisingly; I wouldn't have expected the mobo's built-in gigabit Ethernet to be that different from those in the days of Win7 and on older PCs Win7 always recognized the network for me), Win8 did. It also supported the graphics card (I installed the Catalyst drivers anyhow because I wanted more control over it, but the system worked fine without, but that was just a short trip to amd.com), SSD, USB3, USB headest (Logitech), etc. Not a single unknown item in Device Manager after Windows Update (automatically!) pulled the drivers for a few peripherals. This is absolutely a 64-bit system (32GB of RAM...)
So, system found. Not sure what's wrong with yours. I didn't even do any research beyond checking the Newegg and Amazon reviews.
Depends on your definition of "suck". Price-for-price, AMD and Intel are fairly comparable right now (each one is better at some things, sometimes embarrassingly so, but in most cases they aren't far apart). However, Intel's line goes a lot higher than AMD's. A top-of-the-line AMD desktop processor is currently around $200 (less on sale, which isn't hard to find this time of year). A top-of-the-line Intel CPU will run you over $1000, and that's on sale. The 3770K isn't top of the line, but it is well over $300 on sale. Note that that's not including the cost of the motherboards either, which also seem to be higher for Intel chipsets.
To people who want the absolute best performance and money is no problem, Intel is the current king. Since the goal of the benchmarking is to test the graphics processor, they wanted to make sure that the performance wouldn't be CPU bottlenecked.
I'm saying this by way of giving you the benefit of a doubt, but since anybody who pays attention to current benchmarks and hardware prices knew it already, it really does in fact look like you're trolling.
The Windows drivers for Apple hardware (especially their trackpads and their special versions of otherwise-commodity graphics cards) are crap compared to what is normally available for Windows (yes, Apple graphics card drivers are even crappier than normal graphics drivers, on Windows), but it is still the only OEM I know of that makes it that easy to run a competitor's software on their hardware. They've already made their huge profit margin on the hardware though, so why not?
Both the "hybrid" sleep (where the data is written to hiberfile, then the system enters sleep) and the hybrid shutdown (where the system shuts down but writes startup data to the hiberfile) are easy to disable in the Windows power settings. More importantly, though, if they are enabled then when the system enters Hibernation you're protected anyhow. The hiberfile is on the system (encrypted) volume! They can't pull the key out of that...
This attack only works if for some reason you are using full drive encryption, but not on the system volume. By default, Windows won't even let you configure BitLocker that way; you'd have to do it manually or encrypt the drive using a different PC (one that does have its system volume encrypted) and then transfer it over and provide the decryption key.
Windows uses a hibernation file on the system partition, rather than using a separate swap partition, but the point is the same. You see, when BitLocker is active, the whole system volume is encrypted. So... yeah the key *might* be on there (though it also might not; it's supposedly stored in security-sensitive memory space that doesn't get written to disk) but since the hibernation file itself is encrypted, good luck digging it out!
As for the attacks using a RAM dump or a Firewire (or other DMA) connection, that's just silly. Sure, you can get a key out of that, but that's been known for approximately the entire lifetime of full volume encryption. The obvious solution is to not leave the computer running where an attacker can get hold of it. Sleep mode counts as running, here (the RAM is maintained, and BitLocker at least doesn't prompt for the unlock passphrase on resume from sleep) but hibernate is a different matter entirely, and should be fine.
Actually, most of the supposedly-nonexistent features in RT are just disabled as well. It's compiled from the same source code (aside from the HAL, a few other low-level parts of the kernel, and possibly the program loader) and a number of the things it theoretically doesn't do (for example, act as a Windows Networking server) are in fact present, just disabled by default and hidden.
Some stuff may be truly missing, but I wouldn't count on it. However, working around some of the disabled stuff is being a pain, because some of the ways that would help to do this (like TestSigning mode or a kernel debugger) are blocked by the Secure Boot configuration. Besting that one will be a challenge. Currently, the leading theory is that it's easier to break in through an EoP from local Admin to kernel (which is a class of security bug that MS has never bothered with much, as on normal Windows installs an Admin could just install a kernel-mode driver or enable kernel debugging anyhow).
Yes, the bootloader is locked, but within the running system we have pretty much full access and we can attach a debugger to anything short of the kernel itself, which means we technically can actually run unsigned desktop software, it's just a complete pain to do so. Load a program on the desktop (at which point its signature is checked and verified, attach debugger, modify the in-memory image to do something different (usually just PoC stuff like changing some strings, but in theory you could change anything within user-mode), resume execution.
There are a couple of different approaches that people are taking toward unlocking full desktop apps. Partial successes so far, such as running unsigned command-line desktop apps within an AppContainer and finding (authenticated, local) exploits that allow changing some kernel memory are encouraging. I prefer a different approach, modifying the program between verification and execution by loading it off a network share (which could be loopback) and using an SMB proxy (which it should be possible to implement as a sideloaded TIFKAM app). There's lots of options.
Also iOS (which, unlike OS X, does not have a Silverlight plugin) and consoles (none of which, including the Xbox 360, have Silverlight) and Windows phones and Windows RT devices (which don't have Silverlight browser plugins either, although Windows Phone 7 and higher can run local apps written in Silverlight). That's really the thing, though: it requires a dedicated app, not just a browser plugin like you use on the PC. It would be nice to have either an official app or plugin for desktop Linux (Android being an example of mobile Linux), though.
Why do you think this even *can* be fixed? Windows 8 and Windows RT come with full Admin access. They're rooted by design; there's nowhere you can hide a DRM setting (and that's all this is) that it can't be found and changed. Worst case, you can always just attach a debugger to the application (locally on Win8, using the remote debugger tools on Windows RT) and go to town.
While I'm a little surprised that an employee of a MS partner such as Nokia would publish something like this, there's really nothing MS could do about it. This type of thing is a bit harder on Android, where you typically don't have root access right off the bat, and a lot harder on iOS or most consoles, where you're not supposed to have any access to the system at all except through the approved channels, but on desktop/laptop/tablet versions of Windows or OS X or Linux or *BSD or whatever, it's only a matter of finding the switch; you already know you have the permissions to access and modify it.
Wow, let the accusations of shilling fly. That totally reinforces your argument there. Feel better now? OK, moving on...
The right-click-on-Start menu is obvious to me for two reasons: I right click *everything* that looks like it's interactive, and I read (and share) tips and tricks for the software I use. Apparently, right-clicking on things is hard for some people? I prefer to use keyboard shortcuts, which I sometimes learn about by looking at the menu for something, but to me, asking "what are the options for this thing?" is completely normal, and on the PC, that's typically done with a right-click. As for the tips, these have been published for every version of Windows going back to my childhood. People spend a ton of time finding things for Photoshop and stuff, why wouldn't they do that for the software that Photoshop runs on?
With that all said, that's merely the easiest way to launch the legacy Control Panel; it's not the only one. Hit Start, type "Cont", hit Enter; behold the Desktop control panel (since Vista). Open Windows Explorer (so many ways to do this), click the drop-down for the root breadcrumb, select Control Panel (since Vista). Open "Computer" (or navigate to it in Explorer), Click the Computer tab on the ribbon (assuming you hid it in the first place), click Control Panel. Or, of course, just use the Start search to deep-navigate into the part of the Control Panel that you want (again, as people have done since Vista). Actually navigating *within* the control panel feels like I'm in the 90s or something. In any case, the point was that the Control Panel is totally still there. Pin it to the taskbar or put it on the desktop if you want.
Start -> Shut Down has been a joke leveled at Windows for the last 17 years, but as soon as it's gone, people freak out? I'm amused (in a highly eye-rolling fashion). Yes, Microsoft totally could have included the Power button on the Start screen, and speaking from a perspective of keeping the people who only "know how to operate a computer" by rote happy, they probably should have. I find the outrage over it ridiculous, though. As for "deliberately hidden", you realize there's a "Turn off your PC" Search result on the Start menu that come up if you type "turn" or "shut" into the Search? Also, and again maybe this is something that "normal" users don't do, but Settings is one of the first things I find on any piece of software, OS included, at which point the Power button is pretty obvious indeed.
Are you trolling, or just really, really dumb? WC:OaH is an RTS; WoW is a (MMO)RPG. They aren't even vaguely related genres. There's absolutely zero technical elements of WC1 in WoW. There aren't even any in WC3 (probably not in WC2, though I may be wrong there). Story elements, sure, but not a single line of (16-bit DOS-based) code was carried over.
Aren't both StarCraft (1, including Brood War) and WarCraft 2 (Battle.Net edition, which include the expansion) still supported on Battle.Net? Those games are at least 14 years old now. WC3 is also still supported, at over 10 years. I suspect Diablo 2 is as well, although I haven't checked. I do not like the direction that Blizzard has gone, and refuse to buy their new games until they make signing into Battle.Net completely optional, but they do a fantastic job of supporting their old ones.
It's funny, because you're exactly backward. T-Mobile is dropping subsidized contract plans altogether. Instead, all plans will be month-to-month (even on iPhones) and when you buy a new phone, you'll have the option of paying full retail price or putting it on a payment plan that is added to your monthly bill until the loan is paid off. A much better system all around than the other big carriers, and one that I'm pleased to see T-Mobile is able to take even with the iPhone (not that I have any interest in buying an iPhone, but this is not the way they're usually sold and it sounds like TMo standing up for its customers).
Up to 5GB at max speed. They'll throttle you back to about 300kbps (still fast enough for music streaming, which is where most of my phone data usage goes) until the end of the month if you go over 5GB on that plan, or so I've heard; my friends who have it say that's never happened to them. I'll probably switch to that plan shortly myself.
Plus, once the plan is paid off, your monthly rate goes down. The other carriers don't do that; if you don't jump on the upgrade opportunity as fast as possible, you end up wasting even more continuing to pay as though you still owe money for the phone.
I've been a TMoUS customer for years, and have been happy with them. This makes me more happy. Thank $DIETY AT&T's grubby paws were kept away. My only real concern out of this is that they might end up facing worse network congestion. Right now, it's incredible how much less loaded their network is that the big two.
Dev kit is free. If they don't already have VS, there are free versions which can use the dev kit; If they don't already have Win8, that's $40/seat for the Pro edition.
Testing, specifically testing on a Windows RT device, is probably the biggest cost, at perhaps $500 (baseline Surface). The rest of the costs are almost negligible, aside from developer time.
That said, 2 man-months could cost the dev 10k pounds (especially if you include things like benefits in that computation) but why the hell would it take that long? Coding to WinRT is not hard. I assume their game logic was already in C/C++ (for the Android version; they probably weren't using Dalvik) so it's a matter of rewriting the graphics stack to use DirectX, mostly. That *could* take two man-months but seems unlikely to (although I say that without having a good feel for the game's graphics).
Compared to early iPads and most Android tablets, the Tegra 3 is a perfectly good CPU and GPU. Quite a few Android tablets are using them as well, actually. Sure, it's not going to compare favorably to desktop or even gaming laptop hardware, but it will knock the socks off of smartphones.
There are other Windows RT devices (Asus has the Vivo Tab RT at least, probably some others exist too; I know several companies had them planned). Surface is by far the best-promoted one, but it's also in many ways the least available and visible; you can buy the others at any electronics retailer, in person or online, across the country (and spreading around the world). The Surface, by comparison, can only be bought directly from Microsoft either at Microsoft stores (not nearly common enough, and somewhat geographically concentrated) or from the Microsoft website.
With that said, I agree with the core of your comment. ARM is a 32-bit platform, little-endian by default. Unless your game contains ARM assembly language, recompiling it (I'm assuming it's C/C++) for x86 is a trivial operation (change one drop-down in Visual Studio) and even compiling for x64 should be fine so long as you were careful to use sizeof instead of simply assuming that pointers and such are 32 bits wide. I don't understand what they were thinking.
There are multiple Windows RT devices. Surface RT is one, but absolutely not the only one. Its base price is no higher than a new iPad either, and I believe some of the competition is a bit cheaper.
That said, while I don't really understand why MS wouldn't promote an app (just on RT, of course) simply because it's RT-only, it seems incredibly stupid of the developer to release the app as RT-only. Clicking on the Platform drop-down in Visual Studio, selecting "x86", and then clicking Build again was too hard? Or are they relying on some weird characteristic of ARM which inexplicably isn't present on other 32-bit systems (ARM is by default also little-endian, as it is on x86). Performance optimization shouldn't even be a concern; even an older Atom CPU will outperform most ARM chips.
What I don't get is the existence of an ARM-only app at all. What idiocy could lead somebody to intentionally exclude a large number of users, users who have more powerful hardware at that, to save the cost of changing one drop-down menu in Visual Studio and hitting Build again? On the face of it, that seems completely asinine. Unless the guy was using assembly or something else stupid like counting on pointers being 32 bits (which would *still* work in an x86 app, just not x64 native), porting to x86 should have been trivial.
Slashdot Mirror
Vishera is enough of a step up that I think there's still hope for AMD. I only own one AMD processor (and at least 3 Intel ones) but the 8350 looks good enough for its price point and I guess I have a certain degree of "support the underdog" here. Nobody wants Intel to be even more of a monopoly than they are right now. Granted that the 81xx series was a huge disappointment, but that doesn't mean the company is automatically doomed to never again be relevant. The original P4s from Intel were crap too...
Also, AMD has apparently hired some really top talent in microprocessor design, and it came late enough in the 83xx design process that the design was already set... but supposedly there's some real hope for the next generation or two.
Nitpick: 22nm, 32nm. You may be thinking of Angstroms, which are 1/10 of a nanometer. Also, AMD has 28nm in their GPUs; I'm not sure why their CPUs are still using a 32nm process.
I just built a from-scratch brand new system. Every part from the mobo to the graphics card is current-generation and fairly high-end. While Win7 SP1 didn't have the drivers out of the box to use its network interface (somewhat surprisingly; I wouldn't have expected the mobo's built-in gigabit Ethernet to be that different from those in the days of Win7 and on older PCs Win7 always recognized the network for me), Win8 did. It also supported the graphics card (I installed the Catalyst drivers anyhow because I wanted more control over it, but the system worked fine without, but that was just a short trip to amd.com), SSD, USB3, USB headest (Logitech), etc. Not a single unknown item in Device Manager after Windows Update (automatically!) pulled the drivers for a few peripherals. This is absolutely a 64-bit system (32GB of RAM...)
So, system found. Not sure what's wrong with yours. I didn't even do any research beyond checking the Newegg and Amazon reviews.
Depends on your definition of "suck". Price-for-price, AMD and Intel are fairly comparable right now (each one is better at some things, sometimes embarrassingly so, but in most cases they aren't far apart). However, Intel's line goes a lot higher than AMD's. A top-of-the-line AMD desktop processor is currently around $200 (less on sale, which isn't hard to find this time of year). A top-of-the-line Intel CPU will run you over $1000, and that's on sale. The 3770K isn't top of the line, but it is well over $300 on sale. Note that that's not including the cost of the motherboards either, which also seem to be higher for Intel chipsets.
To people who want the absolute best performance and money is no problem, Intel is the current king. Since the goal of the benchmarking is to test the graphics processor, they wanted to make sure that the performance wouldn't be CPU bottlenecked.
I'm saying this by way of giving you the benefit of a doubt, but since anybody who pays attention to current benchmarks and hardware prices knew it already, it really does in fact look like you're trolling.
The Windows drivers for Apple hardware (especially their trackpads and their special versions of otherwise-commodity graphics cards) are crap compared to what is normally available for Windows (yes, Apple graphics card drivers are even crappier than normal graphics drivers, on Windows), but it is still the only OEM I know of that makes it that easy to run a competitor's software on their hardware. They've already made their huge profit margin on the hardware though, so why not?
Both the "hybrid" sleep (where the data is written to hiberfile, then the system enters sleep) and the hybrid shutdown (where the system shuts down but writes startup data to the hiberfile) are easy to disable in the Windows power settings. More importantly, though, if they are enabled then when the system enters Hibernation you're protected anyhow. The hiberfile is on the system (encrypted) volume! They can't pull the key out of that...
This attack only works if for some reason you are using full drive encryption, but not on the system volume. By default, Windows won't even let you configure BitLocker that way; you'd have to do it manually or encrypt the drive using a different PC (one that does have its system volume encrypted) and then transfer it over and provide the decryption key.
Windows uses a hibernation file on the system partition, rather than using a separate swap partition, but the point is the same. You see, when BitLocker is active, the whole system volume is encrypted. So... yeah the key *might* be on there (though it also might not; it's supposedly stored in security-sensitive memory space that doesn't get written to disk) but since the hibernation file itself is encrypted, good luck digging it out!
As for the attacks using a RAM dump or a Firewire (or other DMA) connection, that's just silly. Sure, you can get a key out of that, but that's been known for approximately the entire lifetime of full volume encryption. The obvious solution is to not leave the computer running where an attacker can get hold of it. Sleep mode counts as running, here (the RAM is maintained, and BitLocker at least doesn't prompt for the unlock passphrase on resume from sleep) but hibernate is a different matter entirely, and should be fine.
Actually, most of the supposedly-nonexistent features in RT are just disabled as well. It's compiled from the same source code (aside from the HAL, a few other low-level parts of the kernel, and possibly the program loader) and a number of the things it theoretically doesn't do (for example, act as a Windows Networking server) are in fact present, just disabled by default and hidden.
Some stuff may be truly missing, but I wouldn't count on it. However, working around some of the disabled stuff is being a pain, because some of the ways that would help to do this (like TestSigning mode or a kernel debugger) are blocked by the Secure Boot configuration. Besting that one will be a challenge. Currently, the leading theory is that it's easier to break in through an EoP from local Admin to kernel (which is a class of security bug that MS has never bothered with much, as on normal Windows installs an Admin could just install a kernel-mode driver or enable kernel debugging anyhow).
I'm actually one of those people :-)
Yes, the bootloader is locked, but within the running system we have pretty much full access and we can attach a debugger to anything short of the kernel itself, which means we technically can actually run unsigned desktop software, it's just a complete pain to do so. Load a program on the desktop (at which point its signature is checked and verified, attach debugger, modify the in-memory image to do something different (usually just PoC stuff like changing some strings, but in theory you could change anything within user-mode), resume execution.
There are a couple of different approaches that people are taking toward unlocking full desktop apps. Partial successes so far, such as running unsigned command-line desktop apps within an AppContainer and finding (authenticated, local) exploits that allow changing some kernel memory are encouraging. I prefer a different approach, modifying the program between verification and execution by loading it off a network share (which could be loopback) and using an SMB proxy (which it should be possible to implement as a sideloaded TIFKAM app). There's lots of options.
Also iOS (which, unlike OS X, does not have a Silverlight plugin) and consoles (none of which, including the Xbox 360, have Silverlight) and Windows phones and Windows RT devices (which don't have Silverlight browser plugins either, although Windows Phone 7 and higher can run local apps written in Silverlight). That's really the thing, though: it requires a dedicated app, not just a browser plugin like you use on the PC. It would be nice to have either an official app or plugin for desktop Linux (Android being an example of mobile Linux), though.
You don't have to do any such thing. It's easier if you use a tool built for the purpose, but you can use Notepad or fucking edlin if you want to.
Why do you think this even *can* be fixed? Windows 8 and Windows RT come with full Admin access. They're rooted by design; there's nowhere you can hide a DRM setting (and that's all this is) that it can't be found and changed. Worst case, you can always just attach a debugger to the application (locally on Win8, using the remote debugger tools on Windows RT) and go to town.
While I'm a little surprised that an employee of a MS partner such as Nokia would publish something like this, there's really nothing MS could do about it. This type of thing is a bit harder on Android, where you typically don't have root access right off the bat, and a lot harder on iOS or most consoles, where you're not supposed to have any access to the system at all except through the approved channels, but on desktop/laptop/tablet versions of Windows or OS X or Linux or *BSD or whatever, it's only a matter of finding the switch; you already know you have the permissions to access and modify it.
Wow, let the accusations of shilling fly. That totally reinforces your argument there. Feel better now? OK, moving on...
The right-click-on-Start menu is obvious to me for two reasons: I right click *everything* that looks like it's interactive, and I read (and share) tips and tricks for the software I use. Apparently, right-clicking on things is hard for some people? I prefer to use keyboard shortcuts, which I sometimes learn about by looking at the menu for something, but to me, asking "what are the options for this thing?" is completely normal, and on the PC, that's typically done with a right-click. As for the tips, these have been published for every version of Windows going back to my childhood. People spend a ton of time finding things for Photoshop and stuff, why wouldn't they do that for the software that Photoshop runs on?
With that all said, that's merely the easiest way to launch the legacy Control Panel; it's not the only one. Hit Start, type "Cont", hit Enter; behold the Desktop control panel (since Vista). Open Windows Explorer (so many ways to do this), click the drop-down for the root breadcrumb, select Control Panel (since Vista). Open "Computer" (or navigate to it in Explorer), Click the Computer tab on the ribbon (assuming you hid it in the first place), click Control Panel. Or, of course, just use the Start search to deep-navigate into the part of the Control Panel that you want (again, as people have done since Vista). Actually navigating *within* the control panel feels like I'm in the 90s or something. In any case, the point was that the Control Panel is totally still there. Pin it to the taskbar or put it on the desktop if you want.
Start -> Shut Down has been a joke leveled at Windows for the last 17 years, but as soon as it's gone, people freak out? I'm amused (in a highly eye-rolling fashion). Yes, Microsoft totally could have included the Power button on the Start screen, and speaking from a perspective of keeping the people who only "know how to operate a computer" by rote happy, they probably should have. I find the outrage over it ridiculous, though. As for "deliberately hidden", you realize there's a "Turn off your PC" Search result on the Start menu that come up if you type "turn" or "shut" into the Search? Also, and again maybe this is something that "normal" users don't do, but Settings is one of the first things I find on any piece of software, OS included, at which point the Power button is pretty obvious indeed.
Are you trolling, or just really, really dumb? WC:OaH is an RTS; WoW is a (MMO)RPG. They aren't even vaguely related genres. There's absolutely zero technical elements of WC1 in WoW. There aren't even any in WC3 (probably not in WC2, though I may be wrong there). Story elements, sure, but not a single line of (16-bit DOS-based) code was carried over.
Aren't both StarCraft (1, including Brood War) and WarCraft 2 (Battle.Net edition, which include the expansion) still supported on Battle.Net? Those games are at least 14 years old now. WC3 is also still supported, at over 10 years. I suspect Diablo 2 is as well, although I haven't checked. I do not like the direction that Blizzard has gone, and refuse to buy their new games until they make signing into Battle.Net completely optional, but they do a fantastic job of supporting their old ones.
The individual rate for unlimited is $50/month. I'd expect you can wrangle a better deal when it's a group rate.
It's funny, because you're exactly backward. T-Mobile is dropping subsidized contract plans altogether. Instead, all plans will be month-to-month (even on iPhones) and when you buy a new phone, you'll have the option of paying full retail price or putting it on a payment plan that is added to your monthly bill until the loan is paid off. A much better system all around than the other big carriers, and one that I'm pleased to see T-Mobile is able to take even with the iPhone (not that I have any interest in buying an iPhone, but this is not the way they're usually sold and it sounds like TMo standing up for its customers).
Up to 5GB at max speed. They'll throttle you back to about 300kbps (still fast enough for music streaming, which is where most of my phone data usage goes) until the end of the month if you go over 5GB on that plan, or so I've heard; my friends who have it say that's never happened to them. I'll probably switch to that plan shortly myself.
Plus, once the plan is paid off, your monthly rate goes down. The other carriers don't do that; if you don't jump on the upgrade opportunity as fast as possible, you end up wasting even more continuing to pay as though you still owe money for the phone.
I've been a TMoUS customer for years, and have been happy with them. This makes me more happy. Thank $DIETY AT&T's grubby paws were kept away. My only real concern out of this is that they might end up facing worse network congestion. Right now, it's incredible how much less loaded their network is that the big two.
Dev kit is free.
If they don't already have VS, there are free versions which can use the dev kit;
If they don't already have Win8, that's $40/seat for the Pro edition.
Testing, specifically testing on a Windows RT device, is probably the biggest cost, at perhaps $500 (baseline Surface). The rest of the costs are almost negligible, aside from developer time.
That said, 2 man-months could cost the dev 10k pounds (especially if you include things like benefits in that computation) but why the hell would it take that long? Coding to WinRT is not hard. I assume their game logic was already in C/C++ (for the Android version; they probably weren't using Dalvik) so it's a matter of rewriting the graphics stack to use DirectX, mostly. That *could* take two man-months but seems unlikely to (although I say that without having a good feel for the game's graphics).
Possibly an elliptical orbit, with those representing the closest and furthest distances from Earth? Just a guess; I don't know either.
Compared to early iPads and most Android tablets, the Tegra 3 is a perfectly good CPU and GPU. Quite a few Android tablets are using them as well, actually. Sure, it's not going to compare favorably to desktop or even gaming laptop hardware, but it will knock the socks off of smartphones.
There are other Windows RT devices (Asus has the Vivo Tab RT at least, probably some others exist too; I know several companies had them planned). Surface is by far the best-promoted one, but it's also in many ways the least available and visible; you can buy the others at any electronics retailer, in person or online, across the country (and spreading around the world). The Surface, by comparison, can only be bought directly from Microsoft either at Microsoft stores (not nearly common enough, and somewhat geographically concentrated) or from the Microsoft website.
With that said, I agree with the core of your comment. ARM is a 32-bit platform, little-endian by default. Unless your game contains ARM assembly language, recompiling it (I'm assuming it's C/C++) for x86 is a trivial operation (change one drop-down in Visual Studio) and even compiling for x64 should be fine so long as you were careful to use sizeof instead of simply assuming that pointers and such are 32 bits wide. I don't understand what they were thinking.
There are multiple Windows RT devices. Surface RT is one, but absolutely not the only one. Its base price is no higher than a new iPad either, and I believe some of the competition is a bit cheaper.
That said, while I don't really understand why MS wouldn't promote an app (just on RT, of course) simply because it's RT-only, it seems incredibly stupid of the developer to release the app as RT-only. Clicking on the Platform drop-down in Visual Studio, selecting "x86", and then clicking Build again was too hard? Or are they relying on some weird characteristic of ARM which inexplicably isn't present on other 32-bit systems (ARM is by default also little-endian, as it is on x86). Performance optimization shouldn't even be a concern; even an older Atom CPU will outperform most ARM chips.
What I don't get is the existence of an ARM-only app at all. What idiocy could lead somebody to intentionally exclude a large number of users, users who have more powerful hardware at that, to save the cost of changing one drop-down menu in Visual Studio and hitting Build again? On the face of it, that seems completely asinine. Unless the guy was using assembly or something else stupid like counting on pointers being 32 bits (which would *still* work in an x86 app, just not x64 native), porting to x86 should have been trivial.