[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[Stephen Hoffman]

On 2016-09-18 07:18:38 +0000, Paul Sture said:

> I'd certainly miss one or two things...



Nobody here — nobody — wants to have to rework their existing 
application code.   Ask that question of anyone around, and you will 
get the obvious and expected answer.

A better question is...  If you're overhauling an existing or doing a 
wholly new application on OpenVMS, what features of OpenVMS do you plan 
to use or want to use?   What existing features would you not plan to 
use?

The use of DECnet — wonderful old protocol, that — just isn't on that 
list for the vast majority of sites.   Yes, a few of you have a PDP-11 
or some other weird hardware stashed somewhere.  Good on you.   You're 
not the future of any operating system.   DECnet is simply not going to 
be used in any substantial application updates, and not for new 
application designs and deployments.

There are more than a few areas of OpenVMS that really need help, too.  
 DECnet isn't one of those areas, but any effort spent on those old 
areas such as DECnet — testing, qualification, kitting, securing, 
whatever — is effort that could go to new work and new testing and new 
features for those folks that are moving forward.

Those of you with existing applications?   If any of you have DECnet or 
telnet or ftp or otherwise — and claim you believe in OpenVMS security 
— please stop deluding yourselves.   Because that's what you are doing. 
  Go get your VT52 terminals powered up and fire up your TECO editor or 
whatever your chosen interface, and start working to get your 
applications and your code over to TLS and secure connections and IPv6.

Unfortunately in current OpenVMS, getting TLS and IPv6 working involves 
much more effort than it should be and is much less integrated than 
DECnet ever was, which should tell you something about how OpenVMS has 
been backsliding.

Even given infinite resources, some code has to go away.   Some 
judicious and carefully-handled code has to go away.   There is some 
code that is an anchor impeding progress.   Failure to remove runt or 
deprecated or problematic APIs inevitably produces a ginormous and 
unmaintainable and un-documentable and un-securable morass — whether 
it's an application or an operating system.

Yes, customers will have to rework some of their code for better 
security or better features.   There's just no way around that.   The 
cost of creating compatibility eventually and inevitably goes to 
infinity, and — as I have pointed to specific cases here in comp.os.vms 
before — the desire for compatibility can block all changes in areas 
that really need to be changed to better secure the platform.  You can 
delude yourself into believing the password hash is secure — and it's 
way too fast to be secure — or that VAX C code isn't buggy and unstable 
and quite possibly insecure — or any number of other issues in older 
APIs and older code.   There are specific things that need to be 
changed that can't be changed without breaking compatibility, or that 
deprecation will produce better results in actively-maintained and new 
code.

If you can't rework your application code, then stay on a long-term 
support release or — as more than a few folks have done over the years 
— simply fall off of support entirely.

Catering to the folks that aren't reworking their code — whether for 
good and valid reasons, or just because it's been abandoned — just 
holds back OpenVMS and the rest of the folks that are able and willing 
to do that.  And it saddles the folks that can rework their code with 
the added costs and complexities and difficulties.   Have you looked at 
doing 64-bit addressing on OpenVMS?  It's a marvelous design that 
provides compatibility, and makes new 64-bit work much more effort than 
it should be.   But I digress.

VSI can either do what's been done for the last years and cater 
exclusively to the existing installed base — likely lucrative for a 
while, but we all know where that ends — or they can internalize and 
adopt the leadership role they already possess where they want to take 
OpenVMS and where they want or need to improve OpenVMS and start to 
work toward and start to tell us that story.   Clinging to old APIs and 
insecure network protocols like DECnet and telnet and ftp and 
preserving the current and unintegrated IP and bad IPv6 support is not 
the future of any viable operating system platform.   OpenVMS can 
either cater to folks with old legacy apps — probably a decent 
business, at least for a few years — or VSI can get going toward a 
modern operating system with modern features, modern capabilities, 
marketing, and drag the apps forward...

Well, you get the picture...




-- 
Pure Personal Opinion | HoffmanLabs LLC