Subject: Re: gdb
From: "L. Peter Deutsch" <ghost@aladdin.com>
Date: Sat, 13 Dec 97 17:31 PST

> [re commercial tools:]
> How many mnoths of experienced programmer time have you lost to bugs
> and workarounds?  Is communication with the programmers good enough,
> that you're sure?  Many programmers put up with quirks and never truly
> realise how much time they are wasting working around them.

That is a very dangerous question, because if you asked that question about
freed tools, you might get some unpleasant surprises.  Your description of
problems fits some of my experiences with gdb, gcc, and GNU emacs quite
well.

> How responsive are the vendors to fixing the tools?

How responsive are freed software vendors to fixing the tools?  How much
will they charge to fix the tools?  How many times will they charge that
amount to different customers?  (cf the comment about FSF sometimes "lucking
out" and being able to charge a large amount for delivering something that
they had already done)

> Anyone who has had experience with Windows 95 and with Linux can tell
> you right away which system crashes an average of twice a day, and
> which one stays up and running for months at a time.

Make that "days, sometimes weeks at a time under heavy development use".  My
Linux system has two reproducible fatal failure modes: if a program runs
amok and fills up swap space, the entire system freezes up (which does not
happen with Windows 95, BTW); and sometimes when a program being debugged or
run under tcl or a shell script crashes, the code writing the 'core' file
*both* fills up swap space *and* tries to write an infinitely large file
(which also doesn't happen under W95: instead of trying to write a core
file, it simply suspends the process and brings up a dialog box).

I find any Unix superior to W95 as an OS for development, but in this
respect, as in the respect implied by Len's questions, I think we should be
careful not to look at freed software through rose-colored glasses.

I'm not familiar with most of the packages on Chris Maeda's list, but I do
know something about Purify (not Quantify, though).  I've chosen not to run
any of Pure's products because of their truly obnoxious use of patents as a
club against their potential competitors, but if I were in a more demanding
industrial environment, I would not be able to rationally defend doing this.
Now, their relocatable code massaging technology is not the only way -- or
even the best way -- to insert probe code: for example, especially on modern
RISCs, disassembling the code, inserting probes at the assembler source
level, and reassembling the result is a better way to go, since it allows a
suitable optimizing assembler (which is probably already available on the
platform) to reorder the instructions for better performance.  I believe the
same is true of the specific bookkeeping mechanism they use for recording
the status of memory locations.  So the patents need not be a barrier to a
creating a good freed competitor.  Is there one out there that I don't know
about?

This brings up another question.  Why does it seem to me to be so much
harder to find freed tools than commercial ones?  Is it, perhaps, because
vendors of commercial software can use their higher profit margins partly
for advertising, and advertising costs the same whether or not the product
being advertised is freed?

-- 

L. Peter Deutsch         |       Aladdin Enterprises :::: ghost@aladdin.com
203 Santa Margarita Ave. | tel. +1-650-322-0103 (AM only); fax +1-650-322-1734
Menlo Park, CA 94025     |        http://www.cs.wisc.edu/~ghost/index.html
*Oppose bulk-mail abuse of your mailbox and newsgroups: http://spam.abuse.net*