The OS suffers from a platform schism that can't be fixed with Win RT or virtualization.
Windows 8 is the spiritual successor to the OS that must not be named--you know, the one that forced Microsoft to keep the XP licensing desk open almost five years after its planned end date.
The issue isn't just that Metro (excuse me, "Modern UI") will, like Vista's UI, annoy users to no end with its bloated, full-screen or second-monitor interface with applications represented as varying-size cubes. Ever try to find the right icon on an overcrowded desktop? Add clashing primary colors to the mix. No, the big problem with Windows 8 is that Microsoft is not executing on tying touch and conventional computing devices into a single, unified OS.
An integrated PC/tablet/phone platform is a neat idea, predicated on the concept that IT can give users standard business desktop builds on their PCs and tablets. Great in theory, but problematic because these apps tend not to work on the ARM processors that modern tablets use; they're limited to x86/x64 architectures from AMD or Intel. ARM is here to stay--these processors have a substantially better power-utilization profile than x86/x64 microarchitectures, and power is the single biggest problem in mobility. Energy storage sucks, and processors are hungry. ARM chips are nearly 30% better on energy use than x64, and that's a big deal because the last major advance in battery technology was the invention of lithium ion cells by Exxon in the '70s. So why would anyone want to push lousier power efficiency chips into the tablet market when usage times are already abysmal?
Enter Microsoft's new "unified" development framework for desktops and tablets, Win RT. RT was supposed to remedy this defect in compatibility by providing a common framework for device application development, but it doesn't. Because Metro plug-ins are compiled for x86/x64 and won't run on ARM, you can forget about the plug-ins that are a large part of the new functionality of Win 8 on your ARM devices. But even worse, Microsoft has no plans to extend an intermediate software language layer, which would allow standard x86/x64 apps to run on Win 8 ARM edition. Further, .NET and Silverlight are not supported on ARM, so let's start rewriting everything that's in .NET for ARM. Or not.
Microsoft could write a layer of intermediary code to make apps cross-architecture-compatible; after all, it's done it before with Microsoft Intermediate Language for .NET. Intermediary languages translate higher-level application instructions into native architecture instructions in real time or through the use of a virtual machine, which essentially makes MSIL a form of local app virtualization. Yes, MSIL adds overhead and potentially headaches in maintenance and performance, but it's really the only way to get non-native apps on the ARM platform seamlessly. Of course it's possible to get any sort of application you want on any platform with a terminal or VDI delivery approach, but variances in screen size, lack of basic touch compatibility (or transport of touch gestures), and non-native interfaces make this a difficult value proposition at best, and a nightmare at worst.
Google in the Enterprise SurveyThere's no doubt Google has made headway into businesses: Just 28 percent discourage or ban use of its productivity ≠products, and 69 percent cite Google Apps' good or excellent ≠mobility. But progress could still stall: 59 percent of nonusers ≠distrust the security of Google's cloud. Its data privacy is an open question, and 37 percent worry about integration.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.