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

[Stephen Hoffman]

On 2016-06-20 03:26:09 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2016-06-19 02:48:33 +0000, David Froble said:
>> 
>>> 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.

Look at OpenVMS, David.  Really, really look at it.   Look at the 
password hash.  Look at the design of SYSUAF and of clustering.  Look 
at how PKE and TLS works, and how it is (not) integrated.  Look at what 
has happened with 64-bit addressing, and the effort involved in using 
that.   Fixing some of these cases compatibly is certainly possible, 
but that will mean leaving the old code around and — for cases such as 
TLS or weak hashes or such— and having old security code around is very 
far from desirable.   Compatibility means accretions of deprecated and 
variously under- or undocumented interfaces and tools which then either 
have to be tested and maintained and considered whenever working on 
related code or risk breaking existing applications.  Code accretions 
mean the time and effort involved in making future changes increases, 
too.  Sometimes dramatically.  Eventually asymptotically.

The vast majority of OpenVMS works well.    But there are areas that 
need to be rethought and refactored.   Some changes — like going to a 
flat address space and away from the current segmented model, or 
yanking out RMS and its rather baroque record access processing – will 
never happen.   Some — such as seeing executable code in 64-bit space – 
seem unlikely, but might be possible.    But in specific places, 
OpenVMS and some of the dependent applications really need to be broken 
apart, re-designed, rebuilt, and the old code deprecated.   Not 
everything.  Certainly not on a whim.   Just specific spots.  For good 
and valid and customer-benefiting reasons.

>> 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.

There are things that fundamentally cannot change in OpenVMS without 
breaking applications.   Compatibility means never changing those 
things.   Compatibility means that what would some simple designs — 
such as a flat 64-bit address space — are unachievable.    Which leaves 
us with 32-bit and 64-bit descriptors, $mumble and $mumble64() calls, 
and a host of other arcana.

Compatibility is a most wonderful thing, right up until it becomes an 
impediment and a millstone.




-- 
Pure Personal Opinion | HoffmanLabs LLC