We already have that in the UNIX world... its called Python with the dbus-python package.

ISA is pretty much completely abstracted that this point.

It would take almost zero actual silicon modification to take a Cortex A-15, switch out the microcode and have a x86 processor. You might have to add some new features to the instruction decoder logic but that's it. You wouldn't sell such a chip until after you optimize the A-15 design to efficiently execute x86 instead of ARM of course :)

Same thing on the Intel side. They could take an Ivybridge chip, write some new microcode and poof, its an ARM chip.

In essence, ISA really doesn't have much impact on power vs. performance anymore, its essentially the "API" that sits on top of the actual processor. What DOES matter is the chip design itself, and the process technology. ARM has spent 20 years optimizing their design for power, whereas Intel has spent 20 years optimizing their design for speed.

Now that the two markets are starting to overlap, Intel's designers are optimizing for power, and ARM's designers are optimizing for speed. The big question is which company is going succeed in the other company's home market first?

Seriously, lets stop pretending that the current state of affairs has anything to do with ISA. /. is acting like a bunch of old techies that remember the CISC vs. RISC war and want a rematch.

MSFT's net income for 2012 is 26.6% lower than it was in 2011. Subscription Office is about 1 thing, bringing the income numbers back up.

Office 2010's home and student edition was $140, which licensed 3 PCs, and gave you the latest version for about 3 years. That works out to $46/year assuming you upgrade (which you don't have to do). Now they want $100/year with forced upgrades. This is for software that does the same thing it did 3 years ago.

Unfortunately this article lacks detail, it seems that Bernstein Research considers Intel's latest smartphone designs to be as energy efficient as competitors. Intel's latest smartphone chip is Medfield, which is 32nm. Unfortunately the article does not say what chips they compared... but it would be surprising if they didn't include the Qualcomm (Snapdragon S4 @ 28nm node) in their comparison. So we at least have some indirect evidence that even when they are at the same technology node, Intel's design is still close to ARM's. It will be interesting to see what Silvermont (22 nm) brings in 2013, at which point Intel SoCs will have LTE capability (instead of 3G GSM only) as well as Ivybridge graphics (instead of PowerVR), and they will be Quad-core. The smaller technology node paired with the new design features is probably going to yield an awesome smartphone/tablet platform.

Actually there was a bit of a fire sale on the Kin.

The Kin ONE went from $50 to $30 after a month. The Kin TWO went from $100 to $50 at the same time. The devices where then discontinued shortly after.

Verizon then sent the remaining unsold units back to Microsoft. After a year, that same inventory of unsold devices emerged with a firmware update that turned them into feature phones, named the Kin ONEm and the Kin TWOm.

Remember that Microsoft is shipping Windows RT with Office 2010 included... as in the DESKTOP version of Office running in the "Desktop app"! Windows RT is truly the complete Windows 8 stack from top to bottom with Win32 and everything else. The big difference is that Windows RT will only run code that is signed by Microsoft. As Mozilla has pointed out to quite a bit of fanfare Microsoft refuses to sign any 3rd party ARM desktop application.

Windows RT has been intentionally nerfed in the name of boosting Metro application development. Why you ask? Because Microsoft wants to leverage their dominant position in the PC market to create an ecosystem of applications for Windows Phone and the upcoming Xbox.

Have you noticed that they have gone to painstaking lengths to make is so Metro applications that use the WinRT API cannot access the win32 API or the full featured preemptive multitasking OS which WinRT is implemented on top of? Check out the WinRT API reference sometime, it gives you access to a very limited subset of what the full operating system can do. This is intentional, Metro applications are designed to be boxed in to only what Windows Phone 8 supports. Also, all Metro applications must be distributed by Microsoft's app store. How much you want to bet that once Windows Phone 8 comes out Microsoft suddenly announces that all your Metro apps for Windows 8 will run be instantly be available for download and use on Windows Phone 8 via the Microsoft app store?

Microsoft is up to the same tricks as usual. Trying to leverage their core Windows/Office monopoly to gain a dominant position in emerging market segments.

Windows RT comes with a copy of Office 2010 bundled in. That's the reason for the $88 price tag.

While we are on the subject of Metro applications and traditional application development languages... As many others have pointed out, native code is not dead. If anything, WinRT represents a revival of native code. Microsoft has created a new language called C++/CX for WinRT just for the purpose of writing native code Metro applications. Metro applications written in C++/CX use the same APIs as Metro .Net applications, this has never been the case for desktop applications. This is the first time in over 10 years that native code developers have enjoyed feature parity with managed code developers on the Windows platform.

It still remains to be seen if lightpeak is vaporware or not. I suspect that Intel will find the power consumption of fiber optic interconnects to not be acceptable for a laptop battery.

I don't know much about this, but wouldn't you be able to use D3D10 in windowed mode for the same effect?

Using the MIL would give you access to the compositing engine, which you don't get with DirectX. Access to the compositing engine enables special effects that depend on the contents of multiple windows at once like glass. The MIL would enable someone to write a program that makes windows wobble for example.

If the answer to my earlier question is "no", then I guess it's true, but then you could just treat WPF as yet-another-Windows-API.

Well WPF isn't exactly meant to be a managed wrapper for the MIL, its meant to be a widget set. If one wanted to use it as such, one would likely need to dig in to WPF implementation details fairly deep.

For starters, all those frameworks that you've listed (and others which you did not) are layers on top of the core Win32 APIs, which can greatly simplify things, but don't really provide new capabilities.

Sadly that is not 100% true anymore. The MIL (Media Integration Layer) in Vista and later does not have a public API.

The MIL allows one to pass vertex data as well as pixel shaders instead of bitmaps to render a GUI. The MIL is used by the desktop window manager to create those pretty glass effects. WPF (a .NET only API) accesses the MIL directly and provides vertex data, there is no supported way of doing this from a native application. Thus you are forced to use Microsoft middleware to use that part of the OS.

The MIL is also used by Remote Desktop. Notice that if you remotely log in to a Vista/Win7 machine from another Vista/Win7 machine, you will still get the glass effects. This is because the MIL instance on the remote system is sending its data structures to the local system over the network, allowing your computer's MIL instance to render the content, including the pixel shaders for the glass effects. Because there is no public API for the MIL, VNC will never be able to copy this functionality, forcing you to buy the more expensive versions of Windows that have Remote Desktop for that feature.