From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   John Dallman  wrote:   
   >In article <10ckadi$7dr$1@reader2.panix.com>,   
   >cross@spitfire.i.gajendra.net (Dan Cross) wrote:   
   >   
   >> In article ,   
   >> John Dallman  wrote:   
   >> >Our stuff does gain significantly from 64-bit addressing; I could   
   >> >believe fields that didn't need 64-bit gave up on Sun earlier.   
   >>   
   >> I can see that. Personally, I really liked Tru64 nee DEC Unix   
   >> nee OSF/1 AXP on Alpha. OSF/1 felt like it was a much better   
   >> system overall if one had to go if swimming in Unix waters,   
   >> while Solaris felt underbaked.   
   >   
   >I was happy with it, but a very experienced Unix chap of my acquaintance   
   >reckoned "It doesn't run - it just lurches!" regarding it as a   
   >Frankenstein job of parts stitched together.   
      
   Ha! I can sort of see why they'd say that.  It definitely had   
   odd bits of Mach and System V seemingly bolted onto it.  Overall   
   though I thought it was a good system.   
      
   To bring it back to VMS (and sheepishly admit a good bunch of   
   the recent drift is my own) We had an Alpha running OpenVMS AXP   
   1.2, or whatever one of the earlier versions was; it was obvious   
   this was the future over VAX.   
      
   >> Of course, Solaris was still better than AIX, HP-UX, or even   
   >> Irix, but it was a real disappointment when none of the other   
   >> OSF members followed through on actually adopting OSF/1.   
   >> "Oppose Sun Forever!"   
   >   
   >Time was when we supported AIX, HP-UX, Irix, OSF1, and Solaris. We   
   >probably supported them all simultaneously on 32-bit (except Tru64) and   
   >64-bit for a while, along with HP-UX Itanium, although we got rid of that   
   >faster than HP-UX PA-RISC.   
      
   I've said this before in this group, but the homogeneity of   
   modern computing does not strike me as a universally good thing.   
   There are economies of scale one can leverage, to be sure, but   
   just as monocultures aren't robust against external threats in   
   biological systems, I can't help but think that the same is true   
   of computing systems.   
      
   It felt like there was a time when we had built hetergeneous   
   systems that were at least reasonable to manage; these days, I   
   think we'd know how to do much better.  But the diversity of   
   systems and platforms common 30 years ago are mostly gone, and   
   we're left with essentially three buckets: Windows, Linux, and   
   a small sliver of "everything else".  Not great.   
      
   >> I never quite got the business play behind Java from Sun's   
   >> perspective. It seemed to explode in popularity overnight, but   
   >> they never quite figured out how to monetize it; I remember   
   >> hearing from some Sun folks that they wanted to set standards   
   >> and be at the center of the ecosystem, but were content to let   
   >> other players actually build the production infrastructure.   
   >   
   >The trick with monetising something like that is to price it so that   
   >customers find it far cheaper to pay than to write their own. However,   
   >you still need to be able to make money on it. I've seen this done with a   
   >sliding royalty scale.   
   >   
   >However, this kind of scheme definitely would have clashed with the   
   >desire Sun had to make Java a standard piece of client software. It may   
   >have been doomed to unprofitability by the enthusiasm of its creators.   
      
   I think that's a really insightful way to put it.   
      
   My sense was that they overplayed their hand, and did so   
   prematurely relative to the actual value they were holding onto.   
      
   I mentioned Microsoft and Java on the client side: I believe   
   that they were largely responsible for failure of Java desktop   
   applications (and the supporting ecosystem) to take root.  As I   
   recall, at the time, MSFT tried to license Java from Sun: Sun   
   said no, and I'm quite sure that McNealy was positively giddy   
   about it as well.  However, I think in doing so, Sun gravely   
   underestimated Gates-era MSFT, because then Microsoft very   
   publicly said, "we're going to wait and see whether the industry   
   adopts Java on the desktop."  But, since Microsoft was the   
   biggest player in that space, the rest of the industy waited to   
   see what Microsoft would do and whether they would support it on   
   Windows: the result was that Java no one adopted it, and so it   
   never saw widespread client-side adoption.  Oh sure, it had some   
   adoption in mobile phone type applications, but util Android   
   (which tried to skirt the licensing issues with Dalvik) that   
   was pretty limited.  Anyway, while Microsoft stalled, they did   
   C# in the background, and when it was ready, they no longer had   
   any real need for Java on the client side.   
      
   The framing that the web rendered Java on desktops obsolete is   
   incomplete.  Certainly, that was true for _many_ applications,   
   as the web rendered much of the client-side ecosystem obsolete,   
   but consider things in Microsoft's portfolio like Word, Except,   
   PowerPoint, and so on.  Those remained solidly desktop focused   
   until 360; one never saw credible competitors to that in Java,   
   which was something Sun very much wanted (recall McNealy's   
   writing at this time about a "new" style of development based   
   around open source and Java).  Similarly, investment in C# shows   
   that they weren't quite ready to move everything to the web; I   
   think it just took time for the browser ecosystem to reach the   
   level of maturity where it would reasonably support the sorts of   
   rich graphical and highly interactive applications we had   
   formerly seen running natively on desktop (and to some lesser   
   extent, timesharing) machines.  We often forget how much the   
   early web looked like a souped-up 3270.   
      
   >> I thought Microsoft really ran circles around them with Java on   
   >> the client side, and on the server side, it made less sense.  A   
   >> bytecode language makes some sense in a fractured and extremely   
   >> heterogenous client environment; less so in more controlled   
   >> server environments.  I'll grant that the _language_ was better   
   >> than many of the alternatives, but the JRE felt like more of an   
   >> impediment for where Java ultimately landed.   
   >   
   >The main uses for sever-side Java, as I understand it, are:   
   >   
   >It happened to have the right idioms for writing server front-ends that   
   >could distribute requests to the backend efficiently. Being able to do   
   >this the same way, within the parts of the JRE that are effectively an OS,   
   >on all the different host platforms, was more efficient in developer time   
   >than writing a bunch of different implementations. Developer time is   
   >really expensive.   
      
   That makes sense, though I would argue that the same is true of   
   languages that provide a managed runtime, regardless of whether   
   they compile to byte code or native instructions.   
      
   >The hardware resources it soaks up at runtime are beneficial for hardware   
   >vendors, as they get to sell more hardware.   
      
   Indeed, I now recall a BYTE interview with McNealy where he says   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)