At 06:08 PM 11/13/2000 -0500, Jordan Henderson wrote:
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>
>> Why do I now realize that I have apparently kicked over an
>> ant-hill? :-)
Congratulations to Hoff for stomping on so many ants in one message :-).
Jordan, it would certainly be nice to cross-pollinate the different porting
efforts but that may be much harder to do than you are allowing. Also, the
efforts to keep Perl up and running on VMS are not necessarily that
different from what's required on other platforms. There is talk of using
an stdio replacment library for Perl because the libraries of all the major
Unix vendors have stdio routines that are broken or incompatible in various
ways.
[snip]
>A lot of people are looking at the "nasty problems in VMS.C" and
>sometimes you hear people thinking aloud "if only I could change
>the way read() works or ...".
>
>The problem is that to work around limitations and deficiencies in
>the C RTL requires extensive infrastructure built on TOP of the
>current C RTL. This has led to lots of parallel efforts _already_.
Sometimes parallel and sometimes just different. All over the frontport
code you see comments to the effect that a particular jacket exists to
circumvent a particular problem that is unique to Mozilla. I'm in the midst
of trying to whack GNU patch into shape for the freeware CD, and I'm afraid
I've created some pretty nasty little jackets that make this utility happy
but wouldn't work anywhere else. Integrating and generalizing this sort of
stuff ain't exactly easy.
>I invite you to look at VMS.C.
But pour a strong drink first. There are some things that are pure cruft
now, or would be if everyone had this year's C RTL. But since VMS culture
hangs on to things that are working, there are a lot of systems with
five-year-old C RTLs and Perl works pretty well on them. There are also a
lot of things that make Perl be Perl and aren't simply Unix compatibility
enhancements in any generic sense.
>Anyone who was brave enough to actually attempt to maintain a "custom"
>C RTL would probably also have some good ideas and be able to actually
>contribute to the development. Compaq could choose to accept or reject
>any changes made in the community for inclusion into future supported
>releases.
This just might bear fruit in the long run, but I don't see it as a way to
avoid duplication of effort, at least not in the near term. In part open
source works by duplicating effort and then killing off the weaker children.
What I meant by "enlightened autocracy" in my earlier post was that some
central authority needs to strangle the weaklings and nurture the thrivers.
It takes both technical and management resources to do that. If you don't do
it that way you end up with diverging versions that create more problems
than they solve.
It is not unprecedented for a major vendor to open source the crown jewels;
Apple's Darwin project (the open source version of OS X) testifies to that.
I don't think Compaq should try it, though, if they aren't ready for it,
which it sounds like they aren't.
