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

[Bill Gunshannon]

In article <midap3$v3k$1 at dont-email.me>,
	Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
> 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.
> 
> 

Please watch your attribution.  There is nothing in this message that I wrote.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>