[Info-vax] VMS survivability

[Arne Vajhøj]

On 2/20/2023 6:28 AM, Dan Cross wrote:
> In article <tsuep3$hia4$1 at dont-email.me>,
> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>> On 2/19/2023 4:48 PM, Dan Cross wrote:
>>> In article <tst9dd$dhc4$1 at dont-email.me>,
>>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>>> On 2/18/2023 10:06 PM, Dan Cross wrote:
>>>>> In article <tsrpoc$5qhq$2 at dont-email.me>,
>>>>>> It is problematic to find people to maintain the ifdefs
>>>>>> and build scripts of for VMS in many open source projects.
>>>>>
>>>>> Have you ever stopped to wonder why that is, and how one might
>>>>> go about changing it?
>>>>
>>>> It is not obvious to me why VMS being open source should
>>>> make it more attractive to develop open source on VMS.
>>>
>>> It's prohibitively expensive to do so today.  Should commercial
>>> vendors port to OpenVMS using the hobbyist program?  How about
>>> open source vendors?
>>
>> ????
>>
>> Commercial vendors can use VSI's excellent ISV program.
>>
>> Open source developers can use either same ISV program
>> or hobbyist program.
>>
>> Minimum cost = zero.
> 
> Too bad there are no native compilers for x86_64 yet,
> which means using a different platform, which comes back
> to cost.
> 
> Do you...really not understand this?

The compilers are available for VMS Alpha.

The native compilers for VMS x86-64 are available for
development for some languages and the remaining languages
will become available soon.

Not really a cost problem.

(most certainly a timing problem for those waiting for
those native compilers)

>>>> VMS does not need people that say:
>>>> - VSI please open source VMS
>>>> - someone please port GNAT to VMS
>>>> - someone please port Rust to VMS
>>>> - someone please port XYZ to VMS
>>>>
>>>> VMS need people that say:
>>>> - I have ported XYZ to VMS
>>>> - I have created ABC on VMS
>>>
>>> How, pray tell, is one going to cooperate in, say, porting GNAT
>>> or Rust or LLVM to VMS, when all that development is being done
>>> in a highly proprietary context that by its very nature
>>> precludes collaboration?
>>
>> Close source does not preclude collaboration.
> 
> How does one contribute to the work porting LLVM to VMS, then?

If someone has a strong interest in working with VSI on
LLVM on VMS, then I think they should contact John Reagan.

A more practical approach would be to look at one of other few
hundred thousand possible open source project and put LLVM
on hold until VSI release their changes (later this year or next year).

>>>                             Suppose somebody finds a latent bug in
>>> the OS that's tickled by the new compiler; how does one help get
>>> that fixed without the source code?  Sure, provide a really good
>>> bug report, but none of that helps people do what you claim VMS
>>> needs above.
>>
>> The people that actually do port open source to or develop
>> open source for VMS does not seem to have that problem.
> 
> You are not even consistent within your own post.  There are as
> you said several hundred thousand projects to port to VMS, and
> no one is doing that work, but that people that are doing the
> work don't have a problem, even though they aren't doing it.
> 
> Which is it?

The problem is that the statement "no one is doing that work"
is again pure fiction you behalf.

What I actually wrote was:

#I can tell you: two handful of people are doing all the
#work.

And while you fictitious "no one" can't contact VSI, then
the "two handful of people" certainly can in some cases do.

Arne