HP, Apotheker, Whitman — the saga continues

The latest news from HP, that the board is supposedly going to fire Leo Apotheker after only eleven months in the job, and install Meg Whitman as the new CEO, is making me very nervous about my Autonomy shares.

I was flummoxed to receive a letter from my dealers stating that the first deadline for acceptances had passed with only 46% of holders accepting, since I had assumed that UK institutional investors, long famed on the boards for their apathy towards AU, would have cashed out at the first opportunity, especially since the offer is widely seen as being an overpayment. I guess the art of brinkmanship is not lost. We'll see, the next deadline is 3rd October, and I think there's another, final one on the 17th or thereabouts.

Gossip on the boards is frenzied right now, with some even speculating on an HP/SAP merger: the rationale being that if HP are indeed moving to be an enterprise software company, they would still lack a big-hitter product even after the AU purchase. SAP would, of course, fit that bill.

I think Larry Ellison would relish the role of Wicked Fairy at that particular wedding. I have no doubt that the M&A specialists at Oracle are even now casting their eyes over HP and running the numbers. A further fall in its share price (already down 47% since Leo came aboard), as might well accompany a bid for SAP, would only make it more vulnerable.

There are other attractions for Larry, besides the pure pleasure of sacking the HP board en masse and putting his mate Mark Hurd back in the CEO's seat. He bought Sun for Java, not for its hardware business, but the addition of HP's Unix server business (and the re-introduction of the Oracle database on those servers) would please HP's midrange customers and add to the critical mass of Oracle's Unix business. If the worst came to the worst, he could perhaps simply shift some proportion of HP customers over to Sun kit the hard way, by simply (over time) raising HP prices faster (even) than Sun's, but there's no need at all to be so cavalier. He could kill Itanium after the next two, contracted-for, revisions by simply failing to extend HP's contracts with Intel, and have HP engineers in the meantime scurry to port HP-UX to SPARC, while scheduling new Superdome SPARC cells for some time around 2015. Any remaining HP IP in Itanium might be a useful addition to SPARC, and increased volume couldn't hurt. If he's as neutral on Sun's x86 business as he says he is, he could complete the spinoff of HP's PC division while throwing in Sun's x86 business as a sweetener. What he'd do with WebOS is anyone's guess.

Well that's enough wild imaginings and uninformed speculation for one night.

Native Client — Google lets a hunded flowers blossom

There are already about a hundred schools of thought contending over the worth of Google's new Native Client ("NaCl") technology.

NaCl (inevitably punned by the Googlegentsia) is a way of allowing native-code (raw machine instructions, instead of an interpreted language such as the currently-standard JavaScript) to execute in your browser. As such it is painfully reminiscent of Microsoft's ill-fated attempt to add ActiveX controls to the browser, a move resulting in so many security breaches that it contributed significantly to the mass developer move away from Internet Explorer.

Some critics contend that NaCl will is merely a rerun of ActiveX and will suffer the same fate. However, unlike ActiveX, Native Client is not restricted to a single operating system, and although currently implemented only in one browser, Google's own rapidly-growing Chrome, it is open source and available for incorporation by other browsers if their developers so desire. As such, Native Client would run on whatever operating systems a given browser does.

A more serious criticism is that NaCl is currently restricted to a single chip architecture, x86-class code, meaning that it won't run on your mobile phone or tablet's browser, as those machines are currently almost all powered by ARM cpus. Google already have an answer to this in the works, based on compiling your C or C++ source down, not to native instructions, but intermediate-level LLVM bitcode. This is where the story starts to get hazy. Will the bitcode get further compiled, and if so when? In the browser? By the web server? It has even been suggested that Google may end up writing a virtual machine to execute LLVM bitcode directly. Shades of Java, why not just use that? — Indeed, your humble blogger remembers writing a post on the Mozilla developers mailing list about a decade ago, advocating exposing Mozilla internals to Java, so that people could write internal-level stuff using Java (which almost everybody could do) instead of C++ (which relatively few people could do), an idea which sank immediately and without trace; but that's another story.

The security angle seems much better thought out. Google are determined to sandbox the native code inside the browser, and seem to have invented a clever way to check and enforce that sandboxing. Said clever way relies on features of the x86 chip family though, and again, the concern must be that similar ways may not be so readily found for other chip families.

The least convincing criticism, I find, is that Google should have spent this effort on implementing the complainer's favourite interpreted language instead, because it's allegedly so much better than JavaScript. Candidates include the usual suspects: Python, Ruby and Lua (though I actually don't remember anyone proposing Perl). The people who make this criticism seem to me not to be one hundred percent awake: the goal of NaCl is to make browser capabilities that are available to JavaScript also be available to C and C++ programs (initially, with other compiled languages later, perhaps). Now if your NaCl program were to be ... a Python interpreter ... a Ruby interpreter? See how that might work? By doing the larger job, Google have automatically provided for the smaller job. Now, all we have to do is get responsible people in the Python, Ruby, Lua and whatever else camps to hook their interpreters up to the Native Client APIs, and a hundred browser languages will blossom,