Post by Arne VajhøjPost by Simon ClubleyPost by Arne VajhøjIt 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.
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.
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.