gam@amdahl.UUCP (G A Moffett) (01/28/86)
The map postings to mod.map are made with extended expiration
dates -- 30 days, to be exact -- so they don't get expired (erased)
as soon as other postings are. The consequence of this is that they
take up a lot of disk space for a longer than usual time. They are
valuable, but they also take up a lot of space.
I sent a letter to the Usenet/UUCP map posters suggesting that
it would be best to leave off the extended expiration date
and allow individual sites to decide how to handle these
articles (if they immediately archive them, for example, and
thus have not need for them on-line).
Mark Horton suggested I bring my case to the public, so I am.
Please keep in mind that while *you* may have a particular procedure
for handling mod.map that does/doesn't require extended expiration
dates, the question we are asking is: what should the default be
for the *vanilla* package?
(While this article is being posted to net.news and net.news.config,
followups are directed to net.news only.)
Here is my original letter, which states the case pretty well:
------------------------------------------------------------------------
I question the extended expiration dates for the uucp map data
postings. It appears they are specified to expire, by default,
after 30 days. That is, a site that runs the default
"expire -n 14" still won't expire the maps older than 14 days!
I appreciate how valuable the map information is and how important
it is to keep the net informed of the current shape of things,
and these postings do accomplish this, but I think having such
an extension on expiring such *large* articles takes away
the democratic choice of news administrars to expire things
(hopefully big things) as soon as they would like.
"Well," you would say, "they could always use the expire option
to *ignore* the 'Expires: ' line. Then the maps would be expired
as they would like."
This would have nearly dismissed my complaint, except that
I don't think that sites should have to [1] force all their
articles to be expired regardless of 'Expires: ' date; or
[2] have to run expire once more, for the special case of
mod.map (this is especially a burden to small machines,
or machines without much spare time...). I think that
extended expiration dates should be used with discretion,
for articles whose content bears hirer that usual importance,
especially where net matters are concerned. The maps
are of higher than usual importance, and are of almost fundamental
value to the net. I feel, however, that their size is enough
to exclude them from extended expiration dates.
Perhaps sites should be warned that the maps are posted only
once a month, and that these postings will normally expire
after 14 (or whatever default) days. But let them deal with
that situation as *they* would like.
Gordon
------------------------------------------------------------------------
[ end of letter ]
Well, how *would* they (that's you) like to deal with that?
--
Gordon A. Moffett ...!{ihnp4,cbosgd,seismo,hplabs}!amdahl!gam
~ See the soldier with his gun ~
~ Who must be dead to be admired ~clewis@mnetor.UUCP (Chris Lewis) (01/30/86)
I hadn't noticed the Expiry before. Thanks for pointing it out.
I'd also like to point out:
- with sites running uuhosts daily (like us), the expiration
can be as quick as a couple of days without losing anything.
- I have a tendency to think that the map items themselves are
too awkward to use directly. So why leave 'em around beyond
normal expiry?
I'd strongly suggest leaving the Expiration off, and let the individual
sites take the responsibility for snatching them (via uuhosts or some
other /usr/lib/news/sys tie-in) before they expire IF a site wants to
do anything with them. With uuhosts or some other thingie, there is no
need to have the full maps database concurrently resident within the
default 14 day expiry (except for the people trying to build their first
maps database - even then, they might pick up the current maps from
a neighbor.)
--
Chris Lewis,
UUCP: {allegra, linus, ihnp4}!utzoo!mnetor!clewis
BELL: (416)-475-8980 ext. 321carl@bdaemon.UUCP (01/30/86)
> The map postings to mod.map are made with extended expiration > dates -- 30 days, to be exact -- so they don't get expired (erased) > as soon as other postings are. The consequence of this is that they > take up a lot of disk space for a longer than usual time. They are > valuable, but they also take up a lot of space. ... etc., etc. > > Well, how *would* they (that's you) like to deal with that? > -- > Gordon A. Moffett ...!{ihnp4,cbosgd,seismo,hplabs}!amdahl!gam The answer is easy. Leave things as they are and let those, like us, put the following lines into a file that is executed by cron every night: ... lots of stuff and then # clean up news /usr/lib/news/expire -I -e1 -n net.games -n mod.politics /usr/lib/news/expire -I -e3 -n mod.map /usr/lib/news/expire -I -e5 N.B. We get only a limited amount of news, but the above lines let us read (and possible save) the map, yet do not fill up our 30M disk. In other words, let each site use the available tools to their advantage.
laura@hoptoad.uucp (Laura Creighton) (01/30/86)
What's to stop people from cd'ing to $news/mod/map and rm'ing the stuff they don't want if they are tight on disk space? -- Laura Creighton sun!hoptoad!laura (note new address! l5 will still ihnp4!hoptoad!laura work for a while....) hoptoad!laura@lll-crg.arpa
gam@amdahl.UUCP (G A Moffett) (01/30/86)
It may not have been clear from my previous posting, but, yes,
I am taking a poll. Please sent me your opinion on the matter.
Polls are open daily 24 hours. All opinions must be postmarked
by 12 midnight February 11th/12th, and received by 12 midnight
February 18th/19th.
Currenty, the vote is 3 to 1 -- and I'm not telling who's winning
until the polling ends!
--
Gordon A. Moffett ...!{ihnp4,cbosgd,seismo,hplabs}!amdahl!gam
Her name was McGill, and she called herself Lil, but everyone
knew her as Nancy...msb@lsuc.UUCP (Mark Brader) (01/31/86)
I don't think that extended expiration dates should be allowed at all. I think that new versions of news should only act on Expires values that are SHORTER than the time specified in the expire command or by default. A posted article normally hogs space on thousands of systems for a couple of weeks, and it seems to me that that's quite enough for a poster to demand. Mark Brader
david@ukma.UUCP (David Herron, NPR Lover) (02/01/86)
In article <2658@amdahl.UUCP> gam@amdahl.UUCP (G A Moffett) writes: >The map postings to mod.map are made with extended expiration >dates -- 30 days, to be exact -- so they don't get expired (erased) >as soon as other postings are. The consequence of this is that they >take up a lot of disk space for a longer than usual time. They are >valuable, but they also take up a lot of space. My first thought was, of course it needs to be kept around that long. But then I remembered all the details of how I use them here. I don't use the copy that's in the spool directory, instead I use a hacked copy of uuhosts, unpack them into another directory, and run pathalias over there. So really, I could live with shorter expire times. But we have enough disk space that it doesn't matter (barely). The only reason I have left for keeping them around is because I edit a couple of the files because of known problems. So I might want to refer to the original piece at some time. In fact. I can't think of any other way to use the data. In it's form as an article it's not very useful. So you want to unshar it into another directory for dealing with it. And uuhosts is a fine program for dealing with the data... And if you're really tight on disk space, you could always delete the comments... That's my opinion. -- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, soon, david@uky.csnet. Experience is something you don't get until just after you need it.
page@ulowell.UUCP (Bob Page) (02/11/86)
Yes, they are important, and should be kept around a while. But... kept around as what? Most of us probably unpack them asap. After that, the _articles_ aren't much good to anybody. I suggest a default expiration date on the map postings, and let the individual administrator decide. Of course, you could take my advice with a dash of salt, as I have not run expire in over three months :-) ..Bob -- UUCP: wanginst!ulowell!page Bob Page ARPA: page@ulowell.CSNET University of Lowell BIX: page Computer Science Dept VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA
jeff1@garfield.UUCP (02/13/86)
I have another suggestion: how about expiring map entries?
A little grepping around in the map directory used by pathalias
gave the following information:
Year Sites %
85 2272 79.7 (I realize that this is more than 100%,
84 565 19.8 but how accurate could I get using only
83 30 1.0 grep and wc?)
82!! 1 0.0
Notice that more than 20% of the information is more than a year out
of date. I say that we should remove these sites from the map database, and
contact the people listed for new, hopefully up-to-date information.
Maybe there should be a 6 month expiration on map entires. When the
time comes near, send out letters requesting new information. This probably
means a lot of work for the map maintainers, but not much for site maintainers.
How long does it take for someone to gather the information pertinent to their
site? Not much, but it will make the map a lot more useful and accurate.
Think about it.
Jeff Sparkes
jeff1%garfield.mun.cdn@ubc.csnet <- preferred path
{allegra,seismo,psuvax1,utcsri}!garfield!jeff1 <- avoid ihnp4!
Can you say Newfoundland? I knew you couldn't!cmf@happy.UUCP (Carl Fongheiser) (02/24/86)
I have tried sending my map entry to cbosgd!uucpmap several times, but for some reason, it never shows up! If putting it here helps its chances for getting in the map, here goes: #N happy #S AT&T 3B2, UNIX System V Release 2 Version 2 #O CWRU PC Lab #C Carl Fongheiser #E ...!decvax!cwruecmp!happy!cmf #T (216) 368-5066 #P 10900 Euclid Avenue, Cleveland, OH 44106 #L 081 36 35 W / 41 30 15 N #R #U cwruecmp #W cwruecmp!happy!cmf; 29-Oct-85 18:10 EST # happy cwruecmp(DAILY),grumpy(LOCAL), dopey(LOCAL),sleepy(LOCAL) ------------------------------------------------- Carl Fongheiser ...!decvax!cwruecmp!happy!cmf cmf%happy%case@CSnet-relay