Square Wheels

So, more on why I said that the JavaStation had "square wheels." As you may have gathered from yesterday's post, I actually think that the JavaStation concept had merit. But concepts that are poorly implemented can quickly overshadow all merit they may have had in the beginning.

At the time of the JavaStation everyone thought that Java was the be-all and end-all of all time. Java was going to rule the planet, give us world peace, end world hunger, and all the rest of it. Well, we were not that far off, as Java does pretty much rule at least the world of the Web and Web Applications, but it also showed some serious short-comings.

Java was never meant for writing an Operating System. It just wasn't. It was, at least at that time, too slow and too feature-incomplete to properly implement an OS. Since that time Java has come a long way in speed and features, but I would still say that it is not an appropriate vehicle for implementing an operating system. Why did we stick with Java for an OS for so long? Probably inertia. Frankly, not a single customer I ever talked to (and I talked to thousands of them at the time) ever cared one single bit what the Operating System was written in. We could have written it in COBOL for all they cared, as long as it was fast, reliable, and ran the applications they needed. Unfortunately, JavaOS did none of these things.

But just because JavaOS was bad does not mean that the concept of the JavaStation was bad. I still think that the division between client and server in the JavaStation model was, if not absolutely correct, at least more correct than most. But again, the idea of the correctness of the division has a great deal to do with what the intended tasks are. For a Graphic Designer or Digital Illustrator the division is much different than for a Call Center Operator. There is no one right answer. There will always be areas where a full-blown workstation with lots of processing power, memory, and local disk (and possibly a high-end graphics card) are the only real solution. There are also situations where a zero-compute solution like the SunRay make sense. But then there is that pesky grey area in the middle where some compute power is needed, but the overhead of a full workstation is too high. This is where the JavaStation concept was supposed to land. It just landed with an anchor tied around it called JavaOS.

So how do we round off the wheels of that concept and make it roll smoothly? How do we fill that gap between high-end, fully-loaded workstation and SunRay? That's the question. Well, that's one of the questions. Don't get me wrong here, I am certainly not arguing that we (Sun) should make any attempt to resurrect the JavaStation. What I am saying is that we need to take a closer look at this division of compute resources issue and possibly make some finer-grained adjustments. It seems that somewhere between "it's all on the desktop" and "it's all on the server" there is a sweet-spot that has yet to be hit. It also seems to me that hitting that sweet-spot could be an extremely lucrative market.

P.S. I don't want to be CEO. I think our CEO does a fantastic job and I greatly respect and admire him. Yes, sometimes he spits into the wind, but just as often the wind changes directions just as he spits and it turns out to be the exact right thing to do at that moment.


For consumer users of Sun Rays, I think the best way to bridge the gap is to port the client software to run on games consoles - some current ones and possibly all future ones will have hi-res monitor outputs I believe. So highly interactive or video heavy content can run locally, more complex stuff runs as a Sun Ray over broadband. And Sun doesn't even have to do any hardware development or work to get them into customer hands! (just the "minor" problem of getting people to actually use it... and for hosting companies to provide Sun Ray servers)

Posted by Chris Rijk on July 22, 2004 at 12:24 PM EDT #

Javastation ran Inferno (www.vitanuova.com) much better than JavaOS. Being close relative of Plan9, Inferno allows one to decide where to draw the line server/client or local/remote execution almost arbitrarily.

Posted by Art on July 24, 2004 at 05:21 AM EDT #

Since I regard the ability to know for sure what the device is, where it is, and that it isn't doing anything it shouldn't be doing, as the best things about sunrays, all of the ideas aimed at transforming them into yet another client strike me as abhorrent. Nevertheless, there may be a sensible opportunity for you to do just that.

Ideas like having AOL or BT hand out Sunrays have not made sense to me until very recently - great service potential, I thought, but not financially feasible. What changed is my understanding of the threat posed by phishing and CNP (Card not present) frauds and therefore the opportunities counter-action open up for Sun and the Sunray.

The key would be partner with a major financial player like citibank in the US to offer companies like AOL customized sunrays with credit card reading hardware tightly incorporated in the sunray hardware - not as a plugin, something that can't be ripped out and replaced without destroying the unit.

Obviously matching server software would be needed too and the european versions would have to allow four digit PIN entries etc, but there are no show stoppers there given the dollars available from setting up and running the server end for several million AOL or BT subscribers.

What would sell this is that, from the financial partner's perspective, ecommerce transactions originating with users of these devices would then be verified card present. Because these would now be card present transactions the bank (or other debt acquirer) would face much lower fraud risks, web merchants wouldn't face chargebacks on those transactions, and users would reduce their exposure to identity theft.

Everybody wins, especially Sun.

Posted by Paul Murphy on August 13, 2004 at 05:37 AM EDT #

Post a Comment:
Comments are closed for this entry.



« June 2016