In the novel "Shogun," Toranaga has Blackthorne build a ship, secretly burns it down and has him build another. The ships are meant as bargaining tools for Toranaga's negotiation with the Portuguese, who control sea trade with Japan.

A working Macbook-anything running an A5 chip would be extremely useful for Steve Jobs when negotiating terms with Intel, even if in the end he "burns" it.

The fact that we know about this supports this idea. Apple is quite capable of keeping much bigger secrets than this when it tries.

I love the idea of lower power ARM devices, but the first thing my mind goes to is visualization. What are the implications?

VirtualBox has been a boon for me for virtual server environment testing.

You quite probably won't get decent x86 emulation speed out of an ARM processor. It takes an order of magnitude more transistors than an ARM has just to make an x86 out of hardware. You can do code translation on the fly, but doing that and keeping your virtual environment anything like the server you are trying to emulate.

When it comes to simulating servers, I've been opting for things like lxc and openvz. OSX should be able to use BSD's jail.

They will want to support x64 on ARM anyway, because Windows is going on it. If Apple was to do this, now is a good time. Have a Windows program, and a Mac port you care about? Port both (hopefully). That's assuming anyone other than VM and driver companies will notice the change and will have to code for ARM.

x64 is a specific 64-bit derivative of the x86 architecture, ARM has it's own 64-bit arch. Microsoft is porting Windows 8 natively to ARM.

True, but you got my point, calls that used to be purely written for x86 have been ported to run on ARM.

> They will want to support x64 on ARM anyway, because Windows is going on it.

Could you explain that?

There's an ARM version of Windows 8, either it launches with no software or MS builds in a way to support all the existing stuff.

Microsoft is porting Office. There is no way a current ARM can emulate a modern x86 with performance comparable to real hardware. Microsoft can make it easy for companies to compile their codebases for ARM, provided they use Microsoft tools. C# and Java should be able to run cleanly, but there is a lot of VB6 code still floating around.

There are ways to use the transistor surplus an ARM code has (it's much simpler than a comparable x86) to hardware-assist the translation, but, by the time you have a functional silicon, you will be in the x86 size range, negating all the advantages ARM has.

I have no inside knowledge, but I'm betting that the ARM version of Windows will strictly run .net user applications. (There's already precedence for this with Windows Phone.)

Microsoft already tried to support Windows on two different architectures (x86 and Alpha) and failed when application developers never bothered porting to Alpha. They're not about to repeat that.

.NET stuff is not native code. It's CLR bytecode, interpreted much the same way Java bytecode is. Some runtime environments do JITing, when the bytecode gets translated to native instructions.