[Info-vax] CRTL and RMS vs SSIO

[John Dallman]

In article <1ae749de-d462-4c18-af01-4c077cb97ea2n at googlegroups.com>,
lawrencedo99 at gmail.com (Lawrence D_Oliveiro) wrote:

> On Saturday, October 16, 2021 at 7:01:22 AM UTC+13, Simon Clubley 
> wrote:
> > FUSE filesystems come with performance limitations on Linux.
> 
> They work well enough for NTFS, for example. Given that Linux 
> already runs on higher-performance hardware than anything VMS can 
> manage, I doubt the penalty will be noticeable. ;)

Do people use FUSE NTFS on Linux for serious work, on which their
organisations' finances depend? It does not seem like a great idea to me,
after painful experiences with the reverse situation, running an NFS
server on Windows NT. 

> I keep thinking in terms of reducing the amount of work (and hence 
> time) to get something going. That means foregoing 
> higher-performance, but possibly more difficult, design choices in 
> favour of easier ones. Learn to walk before you can run. ;)

The situation for VMS is different from the history of Linux, although
that may be obscured by the presence of VMS hobby usage. 

Currently, VSI have significant income from VMS support work, and that
comes from organisations running VMS for work that isn't easy to move to
some other OS (or they'd have done it already). However, those
organisations have a ticking clock as their Itanium hardware gets older.
They need to be able to transition to a commercial-grade VMS on x86-64
before they're forced to drop VMS and thus stop paying VSI. So VSI need
to take the route from here-and-now that produces a commercial product
most rapidly. 

They have been engaged in porting the existing VMS codebase for just over
seven years, and have it working fairly well. The time to consider
producing an OS based on a different kernel was in 2013-14; switching to
that strategy now would require considerable time to get caught up to the
current position. Some things after that would definitely be easier, but
the delivery of a commercial-grade OS would end up being later. 

John