Re: Reality check

[Gary Shea <shea@xmission.com> writes:]

>Andy, in order to decide whose changes my code should respond to,
>I need to know where you stand on changes that you have expressed
>differences with. What is going to happen if someone creates code
>which is not in accordance with your desires? I'd like a clear policy
>here.

Well, there's no easy answer. For instance, I had 0 interest in floating
point, but Dave Hudson wanted it. He did it, and gave me the diffs. I
delayed. He re-merged them, and did a bunch of other great stuff. So they
ended up in the system.

On the other hand, I've had a couple folks propose making the C library
thread-safe. I object on the grounds that it penalizes >99% of our code (the
single-threaded model) for the good of the < 1%. The <1% should bear the
cost. So if you add all the locks and semaphores and extra complexity for
resource allocation, I'm going to insist it goes to a secondary C library,
or be a wrapper, or something like that.

>My perspective is: It's your system, I'm happy to work within your
>preferences because I get a lot out of doing it. But there are
>competing influences at the moment, and while all will be resolved
>in time, I want guidelines to clarify what that resolution will look
>like, so I can avoid wasted effort now.

I value all contributions. This is a free system, and unless we're having
fun (at least most of the time), well, we all know how to do less fun stuff,
and make money to boot. Against this is the values which make VSTa stand
out: wherever possible, VSTa chooses the simple/elegant 75% solution against
the complex/bloated 99% solution. Where somebody *needs* the 99% solution,
I look for a way to localize the impact of meeting the 99% solution. For
instance, our "make" is tiny. Sometimes you need the full GNU make
semantics. So there's a port of GNU make "gmake". But the system standard
one remains the small/simple/fast one.

I've resisted moving forward to a newer GNU C compiler; they have gotten
amazingly huge. Then somebody came forward with lcc--which in some ways is
the "VSTa of C compilers", as it were (although we need to get the register
allocation working for i386). So now I can make *that* "cc", and have the
simple/efficient/small compiler, which makes me much happier to roll GCC
forward to its full/latest/greatest 2.X majesty.

So please don't take offense when I start dancing around while figuring out
how to handle a new issue. It's just that if you fiddle with an issue for a
while, you can usually find a better yet less obvious way to fit it into the
whole.

                                                Regards,
                                                Andy
Received on Tue Jan 10 17:45:13 1995