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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 20-Jun-16 9:08 AM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] RMS record metadata, was: Re: Re; Spiralog, RMS
> Journaling (was Re: FREESPADRIFT)
> 
> 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.
> 

While no one here would state OpenVMS does not have things it
needs to address, you make it sound like all the other platforms
do not have major challenges as well. 

We both know these other platforms have their share of significant 
challenges as well - and these challenges include how to maintain 
compatibility while still moving forward with new technology that could 
enhance the underlying platform.

Remember - it's not the technology that Business types like, it’s the
ability of that technology (old OR new) to support their business and 
their customers that is important to them. 

And it’s the business that funds the IT groups.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com