Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!hsdndev!wuarchive!cs.utexas.edu!bcm!tmc.edu!sob
From: sob@tmc.edu (Stan Barber)
Newsgroups: news.software.b
Subject: Re: (C News) limit filesize and inews
Message-ID: <3464@gazette.bcm.tmc.edu>
Date: 6 Jan 91 09:58:55 GMT
References: <1991Jan6.004313.8792@zoo.toronto.edu> <3463@gazette.bcm.tmc.edu> <1991Jan6.073729.21354@zoo.toronto.edu>
Sender: usenet@bcm.tmc.edu
Organization: Baylor College of Medicine, Houston, TX
Lines: 56
Nntp-Posting-Host: tmc.edu

In article <1991Jan6.073729.21354@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>Popularity has nothing to do with correctness, as various companies have a
>habit of demonstrating.

Correct is sometimes in the eye of the beholder. For example, where V7 and
POSIX disagree, which one is correct? How about 4.3BSD and System V?

>It is not a question of "they should fix their code so that mine will
>work":  they should fix their code so that *their customers'* code will
>work, because it is most unlikely that these bugs affect only my code.
>I don't care how popular these bugs are, they remain inarguably and
>unambiguously bugs.

If they are bugs, they are bugs. I agree with that. But, if they are
varients, then are they bugs? That is, if the documentation correctly
identifies how particular calls work, but this methodology is somehow
different than what is expected by people from a particular culture
(People who know System V trying to work with BSD as an example), is that
a bug?

>This is not an "ivory tower attitude".  Quite the contrary; I consider
>it an ivory-tower attitude -- thoroughly impractical and not reflecting
>the real world -- to say that "you should make your code work on every
>popular system, no matter how badly broken; the only excuse for failure 
>is not having had a system available for testing".  In the real world,
>there always comes a point where you have to say "Enough!  Munging my code
>to allow for these morons' mistakes is not worth the time and trouble.".
>The costs are real and must be taken into account.

Okey. We'll just disagree on this point. I guess I've just had to work
around more problems on more different hardware/software environments where
the people wanting the work done would not take "no, the computer OS is
broken, and I just refuse to make it work" as a valid answer. 

>(Stan, I don't understand why with one breath you agree with this, and
>then with the next breath you say "if it doesn't work, then either you
>didn't have one to test, or you have an ivory-tower attitude".  Whether
>I had one to test is utterly irrelevant to whether the changes are too
>costly to be worthwhile.)

Henry, how do you really know if the changes are too costly unless you have run
a test? I guess you could just RT*M and extrapolate, but you still really
don't know for sure.

Now, back to the original reason for my posting....[Yes, there really is
one!]

If the size of the dbz/dbm file is too large, you could import the (dreaded)
B-news USG history directory/file format. Odds are that none of those files
would be big enough. [Gasp...did he say that B news actually did somthing
right? Naw, he wouldn't say that....:-)]

-- 
Stan           internet: sob@bcm.tmc.edu         Director, Networking 
Olan           uucp: {rutgers,mailrus}!bcm!sob   and Systems Support
Barber         Opinions expressed are only mine. Baylor College of Medicine