From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   John Dallman  wrote:   
   >In article <109fa1s$2hamk$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)   
   >wrote:   
   >> I consider it a reasonable assumption that attrition rate   
   >> on a platform with a future is equal to or less than attrition   
   >> rate on a doomed platform.   
   >   
   >That is a reasonable assumption, but not an absolutely solid one. There   
   >are plausible reasons why it could be otherwise:   
   >   
   >One is simply management turnover. If a company has been continuing to   
   >use VMS (but not expanding its use, while it seemed doomed), a new   
   >manager, wanting to make their mark, might decide it's time to migrate   
   >off VMS, irrespective of its future.   
   >   
   >Also, now that VMS is not intrinsically doomed, management become willing   
   >to think about it, rather than ignoring the problem for their own peace   
   >of mind. At that point, they may decide it's time for a migration.   
      
   Or, the organization may be adopting different technologies at   
   an accelerating rate, and decide that the incremental cost of   
   supporting VMS as a legacy one-off is no longer worthwhile.  At   
   some point, you hit a tipping point and just move off of it.   
      
   Instead of being the platform of preference for ongoing   
   deployment, it is seen soley as a cost.   
      
   >One-year commercial licenses, perversely, make that more likely. A year   
   >is not enough time to migrate a complex system, starting from zero. If   
   >there's a perceived risk of VSI going broke, then a migration plan needs   
   >to be made and periodically updated. Once someone gets emotionally   
   >invested in that plan, it's likely to get executed to remove a risk.   
      
   Additionally, as the VMS market share shrinks, and engineers and   
   system managers with expertise retire or move on, the support   
   cost _increases_.  Why pay a premium for training and   
   educational support services when, at this point, knowing how to   
   effectively negotiate Linux (as only one example) is expected as   
   part of a table-stakes skillset?   
      
   Vis VMS specifically, this starts the climb up the far side of   
   the classic "bathtub curve" in software engineering (and other   
   types of engineering, for that matter): lack of knowledge leads   
   to lack of maintenance leads to lack of investment leads to   
   increasing unreliability until finally it's not worth it anymore   
   and the system is retired.   
      
   The hobbyist program helped with this somewhat.  I get that the   
   support cost on the VSI side was high, with little observed   
   return, but I submit that shutting it off was a mistake.  It may   
   have seen more useful uptake for x86.   
      
   >To maintain a niche in the industry, VMS needs to be demonstrably   
   >superior to Linux in some way that matters to a reasonably large number   
   >of potential customers. I don't know what that might be, but supporting   
   >legacy customers doesn't last forever.   
      
   I would argue that the VMS IO architecture lends itself much   
   more readily to supporting the sorts of asynchronous language   
   features and concurrent runtimes of modern languages like Rust   
   and Go, than POSIX-based systems (which have system interfaces   
   that are highly synchronous by design).  Maybe it is notable   
   that the many of the AIO and real-time features added in POSIX   
   were actually inspired by VMS; despite being in the standard,   
   these remain poorly supported and don't interact well with the   
   existing (synchronous) facilities.   
      
   It would not surprise me at all if tail latency for network   
   services on VMS implemented using an event-driven asynchronous   
   architecture could be shown to have significantly lower   
   tail-latency at, say, the 95% or 99% percentile than Linux,   
   illumos, or BSD.   
      
   I imagine that VMS could have a home as an object of study in   
   advanced university setting, as well.  The sad reality is that   
   the vast, vast majority of systems studied these days are based   
   on Unix-y style designs; this isn't bad per-se but has led to a   
   real monoculture of systems thinking, and an alternative would   
   be good.  I don't know what shape that would take, per se, or   
   how VSI might use it to generate revenue, but it would give   
   exposure; recall that part of the way that Unix spread into   
   industry was via students who used it in university and graduate   
   programs and then brought it with them.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)