[Info-vax] report of the last "rendez-vous autour de VMS" (2-FEB-2024)

[Arne Vajhøj]

On 4/18/2024 10:19 PM, Craig A. Berry wrote:
> On 4/18/24 1:48 PM, Arne Vajhøj wrote:
>> On 4/18/2024 8:23 AM, Simon Clubley wrote:
>>> On 2024-04-17, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>> It may be time-consuming and VSI has limited resources, but given
>>>> that >70% of code used in modern solutions is open source code
>>>> and because VSI has limited resources, then it very important
>>>> for VSI to get the VMS open source collaboration working!!
>>>
>>> Don't forget that they now ship Perl as part of the x86-64 kit and
>>> that was only possible because of the work Craig has put into making
>>> the public distribution continue to work on VMS.
>>
>> If I have understood that context correctly, then the end
>> result is all good, but not really collaboration.
> 
> Yes and no.  I've had cordial correspondence with one of the engineers
> and traded tips about some of the initial problems building Perl on x86.
> Before that we had exchanges about their adding signing information to
> my kits for Alpha and Itanium and releasing those with my blessing.
> These things could be construed as a form of collaboration, but mainly
> in kitting and distribution, not in porting or maintaining.
> 
> But the story with Perl is probably not a model to follow for other
> things.  I suspect what happened with Perl is that some of the cooks
> wanted a longer spoon to stir the soup they were making and just grabbed
> one they happened to like, and it's hard to keep the cooks from choosing
> some of the tools for their kitchen.  There's nothing wrong with that,
> but there are other reasons to choose packages worth porting or
> distributing, and there are a lot of other things that will be necessary
> to create, at the risk of a cliché, an open source ecosystem.

> Higher up the application chain, better collaboration seems both
> possible and necessary.  I infer from reports of the recent French
> workshop that JFP and VSI were both working on getting Python onto x86
> but without collaborating.  Oops.  Lets hope that gets sorted out, and
> that when VSI is looking at maintaining ports of PHP, or OpenSSL, or
> whatever, that it works with the people who are already doing those things.

To me it seems like first step is to have a single source repo.

Optimal:
* single upstream repo
* both VSI contributors and community contributors use that
* community contributors can do a build and distribute a ZIP
* VSI can do a build and distribute a PCSI kit for those customers
   that only install VSI approved software on their VMS system
   (I suspect that mentality will be dying out, but there are probably
   still some left)

Almost optimal:
* upstream repo
* VMS repo shared by VSI contributors and community contributors
* community contributors can do a build and distribute a ZIP
   that everyone can grab
* VSI can do a build and distribute a PCSI kit for those customers
   that only install VSI approved software on their VMS system
   (I suspect that mentality will be dying out, but there are probably
   still some left)

Disaster:
* upstream repo
* VSI repo used by VSI contributors
* N repo's used by N community contributors
* signficant differences between builds from different repos

 > Probably the most important thing for VSI related to open source is to
 > focus on the basic enabling features that only they can do.  That means
 > finishing SSIO, finishing or reimplementing named pipes, implementing
 > pthread_sigmask (which is not just a function call but a whole threads +
 > signals thing), implementing posix_spawn(), implementing a pipe() that
 > is truly both unbuffered and stream-oriented, and implementing 64-bit
 > versions of all the CRTL functions that don't have them yet as well as
 > the system and library calls that are still 32-bit only (yes,
 > sys$filescan, I'm looking at you). This off the top of my head and no
 > doubt leaving out a lot of things.
 >
 > There is probably not much room for collaboration with such core
 > infrastructure, but something akin to GNV or analogous toolset will be
 > necessary as well in order to build anything else, and there always have
 > been at least a few people willing to participate in porting and
 > maintaining those things.

The required OS and compiler functionality to support (mostly)
open source C code coming from *nix world is obviously on VSI.

The good thing is that it is limited in scope. The bad thing is
that some of this can be tricky if the desired functionality
is based on *nix system design and does not really fit well with
VMS system design.

Arne