lenny@icus.islp.ny.us (Lenny Tropiano) (03/13/89)
After getting over 12.3MB of compressed news to unbatch in two days, and
my two hard drives on my UNIX pc chattering 48 hours continuously, I decided
to try to recompile my news, and hopefully optimizing the new unbatching.
I've noticed since I have the 3 weeks worth of history files (non-DBM compiled)
on one hard drive, and my news spool directory on the other drive, that all
the disk I/O is really the searching of the history/[0-9] files, and a
minimal amount is placing the unbatched/uncompressed file in the news spool
directory tree.
Figuring I would recompile news (something I don't care to do much), I thought
I would add the 3 patches that came over sometime in January to bring my
news to the 2.11.17 patchlevel. Going even one step further, adding some
public domain dbm routines (mdbm), and compiling it with the super optimization
of the current gcc1.34. Firstly, am I taking on more than I should at
once? I really don't want to *BREAK* anything, especially since I feed a
few sites, and do get a lot of news fed to me.
Can someone give me a few pointers on how to go through an easy transition
from non-gcc compiled, non-DBM news (2.11.14) to gcc compiled, dbm news
software (2.11.17)? I know this is a big question ... but even a few pointers
on experiences with dbm-routines (which I have no experience with), how
to convert the old history (news already unbatched on the system) to
a dbm-history file (does expire -R do this)?
Furthermore, if anyone has tried this on an AT&T UNIX PC (probably unlikely),
I'd be interested in hearing from you... Thanks again,
-Lenny
--
Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525
lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny
ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752dave@dms3b1.UUCP (Dave Hanna) (03/18/89)
In article <633@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: |Figuring I would recompile news (something I don't care to do much), I thought |I would add the 3 patches that came over sometime in January to bring my |news to the 2.11.17 patchlevel. Going even one step further, adding some |public domain dbm routines (mdbm), and compiling it with the super optimization |of the current gcc1.34. Firstly, am I taking on more than I should at |once? I really don't want to *BREAK* anything, especially since I feed a |few sites, and do get a lot of news fed to me. > >-Lenny With your experience and history, I have no doubt that you'll be successful, but I want to wish you good luck, and do let us know how it works out. -- Dave Hanna, Infotouch Systems, Inc. | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |
ignatz@chinet.chi.il.us (Dave Ihnat) (03/21/89)
In article <633@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >... Going even one step further, adding some >public domain dbm routines (mdbm), and compiling it ... Well, Lenny, this has been discussed before, but unless you're an AT&T site, or a BSD source license site, you really can't use mdbm. It seems that it was pretty well decided that the hash functions of dbm were from the original AT&T sources sent to Berkeley, and the mdbm routines are just a rehash (pardon the pun) of the original dbm routines. So, technically--until they release the code--the hashing part of dbm/mdbm belongs to, and is proprietary code of, AT&T. When these routines were posted to the net, this came up and the upshot was that it's not to be redistributed or used except by such sites, and of course everyone who has a copy that was posted deleted it. (Uh-huh.) There was some discussion about re-writing this part of the code--I was volunteered, but never got time--and another soul mentioned that it had been distributed in X-windows, which may release it--or at least, release our responsibility to treat it as proprietary--but no further information ever surfaced on that, either. G'luck, Dave Ihnat Analysts International Corp. ignatz@homebru.chi.il.us