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

[VAXman- at SendSpamHere.ORG]

In article <mailman.11.1466432458.13355.info-vax_rbnsn.com at rbnsn.com>, "Kerry Main" <kemain.nospam at gmail.com> writes:
>> -----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)
>>=20
>> On 2016-06-20 03:26:09 +0000, David Froble said:
>>=20
>> > 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.
>>=20
>> 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 =E2=80=94 for cases =
>such as
>> TLS or weak hashes or such=E2=80=94 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.
>>=20
>> The vast majority of OpenVMS works well.    But there are areas that
>> need to be rethought and refactored.   Some changes =E2=80=94 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 =
>=E2=80=93 will
>> never happen.   Some =E2=80=94 such as seeing executable code in =
>64-bit space
>> =E2=80=93
>> 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.
>>=20
>> >> 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.
>>=20
>> 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 =
>=E2=80=94
>> such as a flat 64-bit address space =E2=80=94 are unachievable.    =
>Which leaves
>> us with 32-bit and 64-bit descriptors, $mumble and $mumble64() calls,
>> and a host of other arcana.
>>=20
>> Compatibility is a most wonderful thing, right up until it becomes an
>> impediment and a millstone.
>>=20
>
>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.=20
>
>We both know these other platforms have their share of significant=20
>challenges as well - and these challenges include how to maintain=20
>compatibility while still moving forward with new technology that could=20
>enhance the underlying platform.

Look at what moving forward has done with/for 'El CRAPitan'!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.