[Info-vax] RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[David Froble]

Stephen Hoffman wrote:
> On 2016-06-19 02:48:33 +0000, David Froble said:
> 
>> lawrencedo99 at gmail.com wrote:
>>>
>>> Hands up all those who think RMS should die already...
>>
>> Perhaps you are ready to re-write billions of dollars of existing 
>> software?
>>
>> Why cannot the old and new co-exist?
> 
> That works for a while, but then you still have to update and test and 
> maintain the old stuff, and there's a non-trivial and increasing cost to 
> that effort.

I got to jump all over this.

While there are some specifics, such as needing TLS V1.2 because the older stuff 
is no longer secure, in general, if software does needed tasks, it will continue 
to perform those needed tasks.  Why does one need to update, or test?  What are 
the non-trivial and increasing costs?  Labor might cost more, but that's across 
the board, not just for old stuff.  I just don't agree with the above statement.

> You often end up putting in place workarounds, and which almost always 
> hamper new adoptions and new development, too.

Nope.  Hasn't happened to me.  New development going on all the time.

> If there are sufficiently good reasons and sufficient incentives to 
> migrate, then the old code will migrate across.

If there are NOT reasons to migrate, then don't.  If it ain't broke, don't fix it.

> If not, then there were problems — whether technical or incentives or 
> ease-of-migration or otherwise — with the new code, or your customers 
> are underfunded and/or understaffed and/or are focused elsewhere.

Maybe that is the issue.  I read about clusters, 50-100 servers, large migration 
projects, and such.  Perhaps my customers are underfunded?

Back in the day, we didn't have 24 hour operations.  We could take the 
applications down for backups and such.  Today, with the internet, e-commerence, 
and such, the is the desire / demand for 24 hour operations.  So, customer wants 
less down time.  Can such be done?  Sure, it happens all the time.  But the 
customer's environment doesn't support such.  So, you look at options, and 
present customer with options and cost.  Quite often the customer's response is 
something like, "ya know, the current stuff is doing pretty well, maybe we don't 
need all the bells and whistles".

> Assuming that you didn't screw up the new code bits somehow and did 
> deliver substantial improvements, then those folks that aren't moving 
> forward and aren't updating their tools are a completely different 
> business and different business model, with different expectations.  
> This is where (and why) long-term-support products are offered. by some 
> vendors  Though those always age out, too.

Not yet ....

> But in this case, RMS isn't ever going away on OpenVMS, if for no reason 
> other than that it's far too entrenched in the operating system and 
> tools.  It'd be nice to see some file system defaults change (e.g. not 
> defaulting to creating VFC), and better and simpler file system 
> alternatives becoming available.  But RMS works.  (If VSI did ever 
> replace RMS, ODS-2 and ODS-5 and related bits with truly modern 
> alternatives and with more modern programming interfaces, it'd approach 
> — or would effectively be — a completely different operating system.)

Selling RDB was a HUGE mistake.  If not sold, perhaps it would have found it's 
way into more OS things.  VMS problems are mistakes and neglect.

But yeah, VMS was written in the 1970s, based upon RSX to some degree which was 
even older.  There are always going to be concepts that are outdated.  There 
have been improvements through the years.  Mostly good things.  But still the 
old concepts remain, and while some maybe timeless, some aren't.

A while back we discussed doing I/O directly into and out of memory devices, 
such as SSD thingies.  Not sure how well such would fit into VMS, but I can sure 
see some benefits.  And some problems.

Today brings new requirements, but it also has many of the old requirements. 
Supporting the old requirements is probably more important than the new 
requirements, mainly because the ratio of old to new favors the existing tasks 
greatly.