Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!uokmax!rmtodd
From: rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd)
Newsgroups: comp.unix.aux
Subject: Re: uuxqt. The Mother of Invention. Fixed, at last.
Message-ID: <1990Oct2.192645.10844@uokmax.ecn.uoknor.edu>
Date: 2 Oct 90 19:26:45 GMT
References: <1990Sep30.195238.28564@panix.uucp> <1990Sep30.233245.22073@uokmax.ecn.uoknor.edu> <1990Oct2.062017.5787@panix.uucp>
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Lines: 56

alexis@panix.uucp (Alexis Rosen) writes:

>Unless I'm missing something (like a bug in my wrapper), it seems to me that
>this strategy is distinctly inferior to the wrapper. (On the other hand, it's
>a dramatic improvement over 20-30% of your inbound news :-)...)  The problem
>is that uuxqt will still fail, and then the rest of your stuff will just sit
>in the spool until uuxqt fires up again- typically, for some more incoming
>batches. In fact, on a busy system like ours, you'd never catch up, and you
>would eventually run out of disk space. You could of course tell cron to fire
>up a new uuxqt every half hour or so, but that's so inelegant... Of course,
>that's exactly what I did before I realized exactly what was going on (i.e.,
>that my news was getting munched).

Well, on my system, an outbound uucp poll (uucico -r1 -suokmax) is being run
once every half hour. If a previous uucp to uokmax is still running, the new
poll dies immediately, but it does go ahead and execute uuxqt.  So, in effect,
uuxqt is being run every half hour.  (It also helps that I'm only getting
news at 2400 bps, so it's rather difficult to get 15+ batches inside of 
a half-hour period.  I gather you're getting news at Trailblazer speeds, 
so this is more of a problem.  Hmm..have you considered having your feed 
site send you larger batches?  Not only does this cause a lower load of
batches for uuxqt, but it makes transfer more efficient -- at Trailblazer
speeds, the time spent waiting for the other side to start sending another
file is a significant fraction of the time it takes to send a ~50K file.  I
gather a good many Telebit sites are running 500K news batches.)

>[somebody else:] >>Altogether now: I want my HDB!
>>Well, I'd settle for just a fixed version of uuxqt; having grown accustomed 
>>to old-UUCP, I really don't want to start learning about HDB's bugs....

>Really? I'd much rather a subdirectory-based uucp of any sort, HDB, Duke, or
>whatever. It's really a pain to mess around in a directory with 1500+ files
>in it. Not to mention the speed problem... In this case, I'd be willing to
>pay the price of progress. Anything to get all those non-critical programs
>like uulog (?!) working. :-(

I'd love to see BSD-style subdirectory-based UUCP, too.  But given the massive
mania for SysV-compatibility, we'll probably get either HDB or old-UUCP, and
given the choice, I'll settle for old-style UUCP.
  BTW, what's wrong with uulog? 

>Nope. News uses more descriptors than mail.
 I suspect that this varies a good bit with the MTA.  I wouldn't be surprised
if smail/deliver together eat up as many file descriptors as rnews does.  

>>  Given the description of the problem, it shouldn't be too difficult for
>>someone at Apple to fix this bug.  Any takers?  Ron?  You listening?  

>I think it's safe to say that they're not unaware of this problem... I'd be
>really surprised if it persisted in 2.0.1.

Assuming there is a 2.0.1.  Personally, I'm hoping for a fixed binary on
aux.support.apple.com.  
-- 
Richard Todd   rmtodd@chinet.chi.il.us  or  rmtodd@uokmax.ecn.uoknor.edu  
"MSDOS is a Neanderthal operating system" - Henry Spencer