wmartin@brl-tgr.ARPA (Will Martin ) (12/19/84)
> > I feel that there is a need for a newsgroup which can be used by those > who wish to ask questions and give answers, ESPECIALLY recurrant > questions and answers. Perhaps there is a need for a net.audio nettiquette > document that lists the 25 most common questions (or something like that) > that is always put at the beginning of the net.audio articles, and that > doesn't expire, thus providing a set of answers for the newcomer. (Query to > nettrash hackers--It that possible? I know that there are some > newuser announcements, but I don't know if we can put one in net.audio.) > This request brings up a concept I have long felt is needed in many news groups -- permanent postings. There are things that occur recurringly in practically every group, which should sit on each host as postings numbered 1 through 10 or something, never expire, and be viewed by each newcomer when they start reading news and when they subscribe to or begin reading that particular group. For example, the "net.announce.newusers" messages shouldn't have to be sent out anew each month; they should be postings #1-4 in that group and never expire, but only be replaced by a new edition when changes are made. In net.music.classical, the "list of composers" posting should remain as #1, and always be there, perhaps being edited and expanded but replaced in place. In net.jokes, the "canonical light-bulb joke" list, and similar collections, should remain unexpired as the low-numbered items. In every group, each recurring topic should produce a posting with the definitive collection of contributions/answers/explanations, which should always be there. Also, we often see suggestions that each group should have a "statement of purpose" or definition of limitations, which new users will see when they first see the group. What better candidate for permanent posting #1 in each group? I realize that implementing this will require software changes. Not only will the concept of "permanence" be needed, so the expire process will ignore these items, but a methodology for replacement-in-place will be needed, so a revised "statement of purpose" will go in as the new #1 instead of just being added as the next latest posting (though it wouldn't be a bad idea for this sort of thing to go in BOTH places -- as the replaced permanent #1 and also as an ordinary eventually-expired new posting; thus both new readers and old readers will see it). Also, a software change to override the automatic assignment of new numbers for items which are edited versions of permanent postings will be needed. It would be nice if this was universal net-wide; that is, net.audio #4 is the same notice on every machine that gets net.audio. Of course, this does mean that someone has to have the authority to generate these special articles and also be the reviewer of submitted revisions or suggested enhancements or additions. Maybe the moderators can do this for the "net" groups related to their fields of expertise? This still leaves a number of groups with no current moderator affiliation; perhaps the longest-lived major participant in each group could be the one who would maintain such permanent postings for that group? It shouldn't be difficult; after the initial set-up, there would be little revision or additions, I would think. Unfortunately, I doubt that we could leave such permanent postings alterable by anyone; there is too much potential for abuse there (someone making a 2000-line posting permanent, eating up space all over the net, for example). This appears to be worthwhile to me, but, since I'm no software type, I wouldn't be doing the work, so I leave it to the net wizards to assign a value to this. It looks like it would solve a few problems and eliminate a number of recurring complaints, though. Discussion? Will Martin USENET: seismo!brl-bmd!wmartin or ARPA/MILNET: wmartin@almsa-1.ARPA
dmmartindale@watcgl.UUCP (Dave Martindale) (12/20/84)
In article <6662@brl-tgr.ARPA> wmartin@brl-tgr.ARPA (Will Martin ) writes: >This request brings up a concept I have long felt is needed in many news >groups -- permanent postings. There are things that occur recurringly in >practically every group, which should sit on each host as postings numbered >1 through 10 or something, never expire, and be viewed by each newcomer >when they start reading news and when they subscribe to or begin reading that >particular group. > Will then lists a set of potential problems with this. There is another one, though, that he didn't mention. Older versions of news used a fixed-size bitmap to keep track of unread articles, limiting the maximum possible article number to some value. 2.10.2 news has changed the algorithm so that the first bit in the bitmap corresponds to the first unexpired article, meaning that there is only a limit on the difference between the smallest and largest article number. As long as all articles expire on a regular basis, this works fine. But if you have a low-numbered article that never expires, readnews will eventually overflow the bitmap and blow up. When I installed 2.10.2 on machines at Waterloo, I had to remove several such articles. Fixing this will require a change in the bitmap algorithms.
msc@qubix.UUCP (Mark Callow) (12/21/84)
> This request brings up a concept I have long felt is needed in many news > groups -- permanent postings. There are things that occur recurringly in > practically every group, which should sit on each host as postings numbered > 1 through 10 or something, never expire, and be viewed by each newcomer > when they start reading news and when they subscribe to or begin reading that > particular group. > > For example, the "net.announce.newusers" messages shouldn't have to be sent > out anew each month; they should be postings #1-4 in that group and never > expire, but only be replaced by a new edition when changes are made. This is a good idea indeed. The hardest part of implementation seems to be the replacement in place. I think we should do it. -- From the TARDIS of Mark Callow msc@qubix.UUCP, qubix!msc@decwrl.ARPA ...{decvax,ucbvax}!decwrl!qubix!msc, ...{amd,ihnp4,ittvax}!qubix!msc
gregbo@houxm.UUCP (Greg Skinner) (12/21/84)
If you use cron jobs to expire news, you can always have the first few files
ignored.
--
Baby tie your hair back in a long white bow ...
Meet me in the field, behind the dynamo ...
Greg Skinner (gregbo)
{allegra,cbosgd,ihnp4}!houxm!gregbodmmartindale@watcgl.UUCP (Dave Martindale) (12/23/84)
In article <1039@houxm.UUCP> gregbo@houxm.UUCP (Greg Skinner) writes: >If you use cron jobs to expire news, you can always have the first few files >ignored. I don't understand this comment at all. The article I wrote (to which Greg is referring) was trying to point out that if you have articles that never expire, eventually readnews will die of a "bitmap too small" error while trying to look at that group. The problem is that the span in article numbers between the oldest unexpired article and the most recently arrived one is limited to a fixed manifest constant. If you leave the old articles around forever, and have the "least article number" field of the active file remain at its small value, you will eventually exceed this constant and readnews will simply quit, without even allowing you to go on to another group. If, on the other hand, you have expire update the active file as if the ancient articles did not exist, then readnews will never find them (even for new users) and so they might as well have been deleted.
mark@cbosgd.UUCP (Mark Horton) (12/23/84)
It's an interesting idea, but in effect, posting an article with an expiration date 5 years in the future has the same result using today's software. The following two problems are not dealt with by the current scheme, and probably not with any reasonably simple scheme for permanent postings: (1) People who use "find . -mtime +14" to remove old news. If expire didn't have any bugs I would never do this, but in practice I seem to have to do it every once in a while. (2) New sites that were not on Usenet when the articles were posted. Statements of charter for a newsgroup, commonly asked questions, and rules usually need to be updated regularly anyway. It's not hard to set a medium term expiration date and repost an updated version at a regular interval. Of course, we have to be sure that these regular postings don't significantly increase the amount of traffic on the net. Mark Horton
chip@t4test.UUCP (12/26/84)
> From: wmartin@brl-tgr.ARPA (Will Martin ) > Date: 19 Dec 84 16:48:19 GMT > > This request brings up a concept I have long felt is needed in many news > groups -- permanent postings. Our experience tells us it is a nice idea, but tough to implement. Locally we have two kinds of newsgroups: one type (loc.all) is exipred regularly, and another (info.all) is never expired. The info newsgroups are moderated locally and contain reference information and documentation. However, this presumes that the information does not require revision. That assumption is a good and reasonable one--for a few weeks :-) Maintanance of such is non-trivial. Even though I see problems with administering a permanent-article system, the hooks are already there. Rather than creating magic article numbers which aren't removed (as Will suggested), an absurdly long expiration time creates the same effect. After a few weeks all other articles will expire normally, and the unexpired articles would be the first ones a new user would see. -- Chip Rosenthal, Intel/Santa Clara {cbosgd,idi,intelca,icalqa,kremvax,qubix,ucscc} ! {t4test,t12tst} ! {chip,news}
gregbo@houxm.UUCP (Greg Skinner) (12/26/84)
> From: dmmartindale@watcgl.UUCP (Dave Martindale) > In article <1039@houxm.UUCP> gregbo@houxm.UUCP (Greg Skinner) writes: >>If you use cron jobs to expire news, you can always have the first few files >>ignored. > I don't understand this comment at all. Let me clarify. If you want to have articles that *never* expire, you can use cron to keep them around. We do nightly expires of netnews. The lines in crontab are something like: touch /usr/spool/news/net/announce/newusers/* cd /usr/spool/news find . -mtime +14 -exec rm {} \; Before executing these two lines, the desired files which can be kept are just touched, thereby the find ignores them. I've seen it posted by Mark Horton that the find(1) method of expiring news articles is nonstandard, but it seems to work for us pretty well. We are pretty much forced to do this, otherwise /usr tends to run out of space on our machines. -- Baby tie your hair back in a long white bow ... Meet me in the field, behind the dynamo ... Greg Skinner (gregbo) {allegra,cbosgd,ihnp4}!houxm!gregbo
dmmartindale@watcgl.UUCP (Dave Martindale) (12/27/84)
In article <1043@houxm.UUCP> gregbo@houxm.UUCP (Greg Skinner) writes: >Let me clarify. > >If you want to have articles that *never* expire, you can use cron to keep them >around. We do nightly expires of netnews. The lines in crontab are something >like: > >touch /usr/spool/news/net/announce/newusers/* >cd /usr/spool/news >find . -mtime +14 -exec rm {} \; > >Before executing these two lines, the desired files which can be kept are just >touched, thereby the find ignores them. I've seen it posted by Mark Horton >that the find(1) method of expiring news articles is nonstandard, but it seems >to work for us pretty well. We are pretty much forced to do this, otherwise >/usr tends to run out of space on our machines. Ok, now I see that you didn't understand what I was talking about, so I'll expand a bit: With older versions of news (before 2.10.2) there was an "expire" program that most sites used to delete old news articles. If an article lacked an "Expires:" header line, it was deleted after a certain default expiry period; if the Expires header was present, that date was used instead. This is generally a useful feature, since it allows you to have articles that expire when they are really no longer useful (the announcement about the birthday tomorrow can expire tomorrow night, while the film schedule for the local repertory cinema can remain around for the whole month it covers). And expire performs a housekeeping task too - it cleans up the "history" file, deleting entries for articles that have expired. The method of using "find" as you have certainly does delete old news, and probably runs faster than expire since it doesn't need to open every article looking for an Expires: line, but you lose the housekeeping functions. In 2.10.2 news, you simply must use "expire". As well as housecleaning the history file, it also updates the active file, which has been expanded to include a field which is the article-number of the lowest- numbered unexpired article in the newsgroup. If you don't run expire, (or if you do run it and some article never expires, which is what my original article was about) the numerical distance between this lowest-article-number and the number of the most recently-received article eventually reaches the point where "readnews" will become upset and quit if you ever try to read that group. The reason for the difference in behaviour is that older versions of news used a large bitmap (8K bits) with an origin of 0 or 1 to keep track of articles that have been read, and thus couldn't handle article-numbers greater than 8192 at all. 2.10.2 news uses a smaller bitmap (2K bits I think) but with an origin of the first unread article present in the group, which is obtained from the active file. So, it can handle almost arbitrarily-large article numbers, but only if the difference between the oldest and newest unexpired article numbers is under 2K. Does this make sense now? By the way, our crontab entry for expiring news looks like: 30 6 * * * su news -c "exec /usr/lib/news/expire -e 14 -v >! /usr/tmp/expire" >/dev/console 2>&1 where the useful part is the "expire", "-e 14" sets the default expiry for this machine to 14 days rather than the campus-wide compiled-in value of 28, and the -v just produces a listing of what it did in /usr/tmp/expire so I can look at it later if I want. The other stuff makes sure it is run as a non-root process and sends any error messages to a place where they may be seen.