LinuxGram

Analysis by Tim Negris

MokaFive is slumming. Like Citrix, VMware and countless other vendors, they call themselves a “desktop virtualization” vendor, but they ain’t.

Since 1959 the computing world has generally used the word virtual as a rough synonym for simulated as in “virtual disk in RAM,” or “virtual memory on disk,” or “virtual machine” in VMware, for that matter. Consistent with this usage is the latest virtual thingie, the virtual desktop, but among the solutions sporting this label, MokaFive is the thing that’s not like the others.

There are at least five different flavors of desktop virtualization (see http://tinyurl.com/CIO-5-Flavors). Three are some variant of the “thin client,” where a scaled-down desktop device supporting the user’s screen, keyboard and mouse is persistently connected to a server computer where the desktop applications actually run. Of the remaining two, one is the Java “sandbox” scheme, where a downloaded or locally installed application on the PC runs in a subordinate, controlled partition, largely independent of whatever else is on the system. The other is where a desktop-based hypervisor manages one or more virtual machines in which the applications run, like the way one runs Windows apps on a Mac.

MokaFive’s offering is none of the above, and, for most IT purposes, it’s probably better than all of the above. Backed by 10 years of R&D at Stanford and the NSF and over 20 patents, MokaFive is a new new thing. It’s a portable PC stack – OS, drivers, applications and data – that’s forged and versioned on a server, compressed, and then downloaded to a PC, Mac or smart phone. Once instantiated on the user’s device, it can operate completely independently of, or in conjunction with the server; it can be dynamically updated or killed on that PC by the server; its data can be synchronized with that on the server; and it can be easily moved or cloned from one device to another by the server. And, according to the company, it does all this very, very quickly. Here’s how the company divvies up its benefits.

Choice Computing

MokaFive enables what the company calls “BYOC,” where the ‘C’ stands for computer. This is where the user can use a device of choice to run corporate applications, with no need for IT to provision or configure the target device. This means that a company can create a complete, authorized desktop image and temporarily “loan” it to a guest worker for use on his or her system and remove it when the job is done, or it can enable telecommuters to use their own hardware to run company software. BYOC means a potentially enormous reduction in hardware cost for many IT organizations.

Mobility

You’ve heard about GoToMyPC and the like. How about “Bring me my PC”? With MokaFive, users can clone, move or remotely access their corporate desktops on any device, without having to worry about security, backup, customization or reconfiguration.

Disaster Recover

In the MokaFive scheme, the server maintains a master copy of every user’s PC image. If the user’s device is damaged, lost or stolen, the server can rapidly kill the system image and destroy the data on the device, preserving license and data security, and re-instantiate it on a replacement user system through the network or by a USB key. If the network gets whacked by a hurricane, users can keep on truckin’ until it comes back up. If a server gets fried, the user devices get re-synched to a backup server.

Outsourcing

For most companies, moving the help desk to Hyderabad or diagnosticians to Delhi usually means a lengthy, complex implementation process, hardware budget and standards squabbles, and ongoing work and worry to manage software and protect data across organizations. MokaFive aims to change the face of outsourcing by eliminating these concerns. The contractors buy and install their desktop PCs of choice, download the authorized desktop images, including OS, apps and data, and get to work. Back at HQ, IT retains control of data and communications security and keeps everybody’s desktop software completely up-to-date and all their data safely backed up.

That’s quite a menu and it’s hard to find any other vendor offering comparable fare. And, given MokaFive’s savvy management and considerable intellectual capital, that’s likely to remain true for a while. But, to break away from the noisy pack in which it is currently running, it probably needs to do something about its positioning in the marketplace. It does itself a disservice by calling what it does “desktop virtualization.” It’s “me too” and not even correct. And then it pokes itself in the other eye by swinging the synonymous stick of “Desktop-as-a-Service.” Again, it’s not accurate and, with no disrespect intended to the MokaFive marketing folks, the world need another “aaS” like I need another “ass.”

If MokaFive can muster the marketing mastery to match its apparent product prowess, it can go from being best-in-class to being in a class by itself.

by Mervyn Bunter, an Alias for a Senior Executive

For the last several months, Silicon Valley has been buzzing with news of HTML5. Basically, if you don’t have HTML5, you’re nothing. Steve Jobs has insisted that HTML5 is the only way to go, and even Microsoft has indicated that HTML5 is where the future of the web lies. And the high-tech press is having a field day – people who aren’t on the HTML5 bandwagon are obsolete (Steve told me so) and so 20th century.

The interesting thing is that, if asked, probably not more than one in 10 could tell you what the technical (not feature) difference between HTML4 and HTML5 is (other than that there’s a different number – that’s technical, isn’t it?) And probably not more than one in a hundred has read all the thousand pages of the UNRELEASED specification. And probably the same number knows (or cares) about the shadow group (called the WHATWG) that is actually crafting the spec while pretending to be part of the W3C.

So, what is Hypertext Markup Language Version 5? Unfortunately, it is easier to define by what it is not.

It is a language that is derived from current practice – that is, what do browsers do now and how do we codify current practices? Note that HTML5 is a backward-looking analysis of how browsers work – not how a Hypertext Markup Language is supposed to work. It is written using current browser practice (both real and imagined) as the basis for the spec. It is basically being written by four browser makers (Google, Apple, Firefox and Opera) who had originally planned to revitalize the use of HTML in browsers.

To understand how this happened, it is necessary to go back in time to the attempted merger of HTML and XML within W3C. The problem with HTML4, from a structure point of view, is that it is a little more casual than XML. W3C was intent on making XML the web language, and by combining XML and HTML into XHTML, they hoped to catch the success of HTML and the structure of XML, showing a wonderful knowledge of human nature. Needless to say, the additional complications of XML, while more precise and probably better for the long term, were little appreciated by the browser manufacturers and others who were used to the causal nature of HTML.

So, in 2004, Apple, the Mozilla Foundation and Opera Software created the Web Hypertext Application Technology Working Group (WHATWG) as an organization that would “represent real-world authors.” (Their words, not mine). It is necessary to keep in mind that the WHATWG is a mailing list – that is, there are no meetings and no process that one would recognize as open. It harks back to the days when Microsoft said that they were open because they listened to users and then gave them what they wanted.

By their own description, the “…focus of this working group is limited to technologies that will need to be directly implemented in web browsers. It is not the right forum for very domain-specific proposals that would not be suitable for implementation in, for instance, Safari, Firefox or Opera. Having said that, those technologies do affect other implementations, and we try to take that into account when designing them.”

So, the splinter group, having a mission from “real authors” (who were only concerned with web browser implementations) started to write their “new and improved and copyrighted” specification. (Mozilla, Google, Apple and Opera jointly own the copyright to the WHATWG spec.) Unfortunately, they soon realized that removing themselves from the W3C – while it got rid of all of those silly rules about consensus and openness – also got rid of all of those useful rules about IPR. (From the WHATWG web site, about openness “This is not a consensus-based approach – there’s no guarantee that everyone will be happy! There is also no voting.”)

So, they went back to the W3C with a proposal – accept us as we are, and we’ll do the WHATWG work in the W3C and you can call us the HTML5 WG and we’ll keep the WHATWG mailing list as our way of doing things. And we’ll also keep a separate spec for the browser makers (who own the copyright).

Now, in case you were wondering about the WHATWG rules are (and how the HTML5 group continues to work) – from the WHATWG web site again – “People send e-mail to the mailing list. The editor then reads that feedback and, taking it into account along with research, studies and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone’s needs as well as possible while keeping the language consistent.” This is McCarthyism at its best. From secret sources (his research, and feedback from “many other sources”), the editor makes the decision about what stays and what goes in.

One would assume that the W3C would say – “Whoa there, fella. This isn’t really open, you know. You’ve gotta have meetings and some form of tracking and so on.” And sure enough, they did. And sure enough, the editor consulted his many other sources and came back and said “No.” And W3C said “Well, shucks. Okay.”

And the editor continues to make all of the decisions on what goes in and what stays out. Granted, there is four or five (or possibly more) steps to ask for the larger committee (with its over 400 invited experts who are rarely heard from) to take a non-binding decision to possibly ask the editor to consider changing the spec (I said “NO and NO I meant”), but that’s about as far as it goes. The ultimate decision continues to rest with the editor and his band of true believers (how open source is that?)

The separation of openness reality and pleasant fiction finally reached a critical stage when the editor and the companies that had the private label for HTML5 were asked by W3C to no longer continue to pursue a separate development process. The members of WHATWG contended that it was necessary for them to continue to play in their sandbox because you never knew when W3C would fold up and just go away. (One has to wonder whether an informal group representing the true users has more longevity than an institutionalized standards organization.) But, be that as it may, WHATWG continues to define and create HTML5, and its advocates continue to insist that (with apologies to Orwell) “All comments are equal but some are more equal than others,” and the market continues to hyperventilate about HTML5.

And as for the spec itself? Again, from the WHATWG web site: “It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn’t mean you can’t start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. ). But other sections are still being actively worked on and changed regularly or not even written yet.”

If you read this correctly, it says that the fragmentation of the web is somewhat assured. “The spec will reach candidate recommendation two years from now, but what the heck, start using it now. No idea of who’s going to use what, but it’ll all work together” – or something like that. The only constant in the current web is HTML4 – which is still not completely implemented by all the browser makers. And the market is making the assumption that HTML5 is going to arrive and there will be an instantaneous and complete shift to an obscure 100 page spec?

What’s really going to happen is that HTML5, for all the Apple and Mozilla hype, will be a long time coming (especially in web years.) And during that time, we’re getting ready to see a start up of the “Best viewed by…” wars. Best viewed with Canvas, best viewed with Flash, best viewed without plug-ins, best viewed by SVG-enabled browsers and so on and so on. Let alone consider the codec wars – On2 VP8, Ogg Theora, H.264 and so on.

The problem is that both the WHATWG and the W3C don’t understand how the market works. Users don’t really care about browsers (the European Commission proved that with their mandated Browser Choice fiasco). Users want ubiquity and ease of use. They want all browsers to behave pretty much the same. Like cars, nobody really expects large variations in the basic design. What we have with the WHATWG is a group of self-appointed experts who represent “true authors” who have taken it upon themselves to impose their vision on the web on the rest of us. They are more arrogant than Microsoft ever dared to be – and the voices of the open source community (those who are most shrill about the freedom of making their voice heard) have all been stilled.

HTML5 is a fiasco. There are no conformance test cases (other than “what do you mean, it broke the web?”), no set of common implementations (except what the product managers at Safari, Mozilla, Google and Opera can agree on), and no common date for completion.

And you know, with a completion date of 2012, the predictions about the year of the Apocalypse may just be valid.