In post #828, I said:
>An example of the complexity of relationship between the NC client and server is >that upon boot up, the NC server will discern the state of the NC/OS and >download "patches" as necessary to keep it up to date. You can't "patch" someone >else's OS.
This contained an overstatement. Yes, you can "patch" someone else's OS. It would indeed be possible for an NC server to provide updates for more than just a single brand of an NC/OS. However, understanding precisely how this might be accomplished is important for adding to our appreciation of the likelihood that NCI will emerge as the leader not only in NC server software, but NC/OS software as well.
Specifications for the NC Reference Platform no doubt include a description of what happens when the NC initiates contact with the NC server. For one thing, we know the end-user will be identified using a NC smartcard. For another, we know the NC/OS itself, or supporting utilities, or even applications, will require automatic updating. Through a standardized dialog, the NC would have to inform the server as to the version of each of its software components, and be receptive to any update patches transmitted by the server. The point is that the server only needs the brand and version of the NC/OS to know that a certain subset of patches need to be sent. It doesn't need to know anything about the patches, what they are for, and how to install them on the NC.
Now let's get real. Somebody has to keep straight all the patches needed for a particular NC/OS, as a complicated function of the version of each software component. Appropriate patches need to be organized with an installation script that works with the version of the NC/OS that is to receive the patches. Once the NC goes consumer, the patching sequence must be flawless, without any possibility of taking down zillions of NCs by screwing up their internals.
This someone then has to make sure that all NC servers likely to encounter the NC/OS have the updated patches and conditions for applications properly in place. An alternative would be if all the NC servers would simply check with a universal patch server, or a universal patch server specific to the particular NC/OS. Universal patch servers may prove useful in future years, but not in the near-term. The reasons are: (1) the added delay in completing the bootup and (2) a possibility of a security breach which could knock out a multitude of NCs. The latter problem can be reduced, but not eliminated, by encrypting server-to-server communications. The possibility remains that the universal patch server itself is corrupted, either intentionally or by human error.
The job of interfacing with all the NC servers regarding all manner of software updates will be a monumental task falling on NCIs broad shoulders. To complicate that task by requiring that they take on Brand X NC/OS is unrealistic, given the amount of work involved and the liability for contributing to a problem with patching Brand X NC/OS. At most, you can expect that NCI will take on one or two other primary NC/OS that emerge, say, from IBM and Apple. Since IBM is stuck with the same problem, you can expect IBM to limit NC/OS it supports to NCI and one or two others. Unsupported NCs can still be served, they just will not be provided update patches automatically, greatly reducing their no-maintenance appeal.
I believe the NCs that exist today, or those that are due out this summer, are not complete in regard to much of the functionality needed to make them fully functional and maintenance free. When Oracle first jumped on the NC idea, the company contracted with Acorn Computer to build an NC -- OS and all. In parallel, Oracle undertook its own NC/OS development apparently based on Unix source code in the public domain. All these early developments are now bearing fruit, but none of them in final form.
At some point, Oracle must have realized that the small does not mean simple, just like small luxury cars cost more than big ones. Just like any other embedded systems application developer using a "roll-your-own" RTOS, Oracle must have awakened to the reality that they needed a modern but lean-and-mean OS to serve as a foundation for the NC/OS. At that point last September they picked WIND.
It seems to me that many complicated issues regarding the NC/OS and NC server relationship must be resolved carefully before the NC is ready for prime time - and the first NC/OS that addresses those issues is the 2nd generation NC/OS from NCI which is based on VxWorks. For example, Bill Gates castigates the NC because the necessary size of browser precludes it as a practical matter from being downloaded during the NC bootup sequence. (Although when Netscape first started talking about the internet browser as an internet OS, Bill Gates went on record saying the browser was just a simple application program.) He may be right, but the solution is simply to embed the browser, written in C/C++, in the NC/OS, eliminating any need to ever download a copy. Another example is the plethora of possible communication protocols that would need to be available to an NC. Most of this software already exists in one form or another, but not in Java. Exactly what is available and getting it all tied together, remembering that each component will need to be maintained through automatic patch updates, is a large job that requires serious deliberation and work, and requires a fully functional OS capable of more than handling more than must Java.
I don't regard the NCI NC/OS effort as a shotgun approach that so far has yielded a number of competing NCs based on a variety of OSs, including Acorn's, Unix, JavaOS and VxWorks (still in the works). In my view, everything is experimental, transitory, until the real VxWorks-based NC/OS is debuted later this year or next. If I am right, then despite the fact that the NC/OS represents just another design win for WIND, it will contribute significantly to WINDs future bottom line. If I am wrong and the NC/OS never contributes significantly to WIND's bottom line, it only will be because even a contribution of this magnitude is insignificant in relation to all the design wins dutifully contributing royalties by then.
Allen |
