[Info-vax] OpenVMS in the future, Open sourced or Closed? Intent is to keep it...

[Stephen Hoffman]

On 2015-05-06 12:24:02 +0000, Bill Gunshannon said:

> In article <059ca1d8-ade0-4428-b003-9c912a872a8b at googlegroups.com>,
> 	seasoned_geek <roland at logikalsolutions.com> writes:
>> On Tuesday, May 5, 2015 at 11:01:34 PM UTC-5, David Froble wrote:
>>> seasoned_geek wrote:
>>>> 
>>>> This fantasy you believe in only works if a single individual can and 
>>>> does posses _ALL_ of the hardware and environment to build from source 
>>>> _AND_ deploy raw to target. This is why wanna-be dutifully disrespected 
>>>> platforms "thrive" as OpenSource and no serious platform does.
>>>> 
>>>> As was pointed out by Hoff. Building VMS from source requires 
>>>> phenomenal setup and significant resources.

Could you point out where I wrote that?  While I did indicate that the 
build — back when I was familiar with it — was complex and it was very 
much tailored to the then-current clusters, but nothing precludes 
simplifying and productizing the build.  Productizing the build would 
be a moderate-sized project, and the complexity here comes largely from 
the scale.   The build is a collection of specific tools and data 
files, and a whole lot of DCL.

There are no specialized hardware requirements, beyond the entirely 
unsurprising "more is faster".

Even for VSI, it'd be handy to have the build overhauled, and features 
such as Xcode and the Xcode bots available.

In short, there are no insurmountable (technical) problems here.  Just 
a whole lot of code-slogging.

Running a full regression test would require the necessary hardware in 
order to test all hardware, but that's entirely separate from the build.

>>> But once all the requirements are set up and available, many would be  
>>> capable of doing the build.  Not that I'm advocating such.  As I've  
>>> written more than once, the reason I wanted to see VMS open sourced was 
>>>  to insure someone at HP could not decide to just delete everything.
>>> 
>> Well, I trust Hoff when it comes to this and if he says few, if any, 
>> are capable of setting up such an environment, I believe him.

As presently implemented.

The folks at VSI would really like to have something like Xcode IDE and 
the build bots for themselves, too.  Whether they get time to work on 
their tooling?

>> We aren't talking about a hokey wanna-be OS like Linux, Windows, BSD, etc.

Those operating systems work quite well, and solve the problems that 
many folks have.  Some of these sites are former OpenVMS sites, too.

>> There is also the issue of all the conditional compilation in the 
>> source code which exists for military and/or very high security 
>> clearance eyes only.

That's a new one.  Never heard of that version of OpenVMS before.

I've never heard of a military or high-security or variant version of 
OpenVMS, beyond Security-Enhanced OpenVMS; SEVMS.  The SEVMS package 
was separate, and hasn't been offered or AFAIK even built in many 
years.    IIRC, the last evaluated versions of SEVMS were back in the 
V6 era, and the product was discontinued a long time ago.

The SEVMS layered product used some add-on tools and add-on utilities 
and features latent in OpenVMS — see the UPGRADE and DOWNGRADE 
privileges, for instance — to implement mandatory access control 
security.

AFAIK, SEVMS was a price book layered product purchase, too.  Most 
anybody could order a copy, and install it.   Not that most sane folks 
really want to manage and utilize a mandatory access control system 
configuration.

The vast majority of OpenVMS source code has been openly published for 
decades via the fiche, and more recently via the source listings kits.  
 The SEVMS hooks are included in the source listings. The hooks are 
present and will AFAIK still function in every shipped copy of OpenVMS 
if you enable the SEVMS system parameters, too.  Not that anybody has 
tried that in some years, AFAIK.

I don't think SEVMS source listings were ever published, but that is 
the case with most (all?) of the layered products.

In years past, you could purchase an OpenVMS source license, too.  It 
wasn't cheap, either.   You can still purchase source listings.  
Hopefully, VSI continues to offer that.  Those have the vast

I am very familiar with the source pool, and familiar with the build 
environment, with the source listings, and with SEVMS.  So I call BS.  
SEVMS is not relevant to building OpenVMS, nor is the complexity of the 
current build relevant to whether the build and the test environment 
could be productized.  A subset of the regression tests that tests core 
functions and (just) the available hardware options is also not an 
insurmountable problem.

The problem here — as with many problems — is not a technical limit.  
It's the copyrights and related agreements, and it's that a whole lot 
of folks just aren't interested in learning and building OpenVMS from 
source code, there are the sorts of non-trivial details that I listed 
in my previous comment, including bug tracking and distributed version 
control and legal releases and the rest, and that it'd take a 
reasonable investment to productize the build and core tests and the 
source control — source control is not going to be a small issue here, 
at the scale of OpenVMS, see the VDE package on the OpenVMS Freeware 
for related details — and the bug tracking.  VSI is likely going to 
invest that time and those people elsewhere here, and at least for the 
foreseeable future, too.   But a secret military version of OpenVMS?  
No.  A publicly-documented and difficult to use and long-retired and 
here-irrelevant version?  Yes.  But SEVMS is AFAICT not even remotely 
relevant here.   Productizing and coordinating and deploying the 
infrastructure for distributed development is all entirely technically 
possible, too.   Just a whole lot of work.

Fear that open source is less secure?  Doubtful.  Ignoring the source 
listings that are available for the vast majority of OpenVMS, source 
code obscurity doesn't mean more security, either.   The 
reverse-engineering tools available now are much better than the ones I 
was using to reverse-engineer and to extend VMS executables, and that 
wasn't particularly difficult.   Now having an engineering team that 
has the testing tools and the fuzzers and the deprecated-feature and 
verification tools and the time and the experience to run those tools — 
whether on open- or closed-source code — and a team has the ability and 
the mandate to retire the old and insecure code — matters far more.


-- 
Pure Personal Opinion | HoffmanLabs LLC