osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (05/19/84)
Are you tired of discussions about new, old, unused, elitist, etc., newsgroups? Well, a week ago rabbit!jj came up with a serious proposal to upgrade the news software. Here it is as extracted from the original article. > Whenever there are no active articles in any given newsgroup > at any give site, DELETE the directories, etc, for that newsgroup, > and put the newsgroup name and sequence number in a file called > "tiredgroups" <or something like that>. When and if a new article > comes up, take it OUT of "tiredgroups" and put it back in its usual > place. > > If creation or deletion messages go around, fine, just handle them as normal. > > That way, we won't HAVE to delete old [ed. unused] groups, since their only tracks > will be 30 bytes in one file in /usr/spool. > > In addition, people who introduce groups that die don't cost us all space, > speed, etc. > > Why insist on human discussion and moderation for this, anyhow, when > an automatic method could suffice, indeed work better? I second this proposal and I'm surprised that people haven't stopped to think about it and comment on it. One comment, though. Even if we liberalize the creation of new newsgroups, letting the 'tiredgroups' file take care of the many unused ones, the proponent of a new group should at least consult the "LIST OF ACTIVE NEWSGROUPS" distributed periodically to 'net.news.group'. No matter how good the news software is, there is no excuse for not consulting that list before proposing a new group. Flames to /dev/null. -- Orlando Sotomayor-Diaz/AT&T Bell Laboratories/201-949-1532 ....ihnp4!homxa!osd7 /Crawfords Crnr. Rd., Holmdel, NJ, 07733
alb@alice.UUCP (Adam L. Buchsbaum) (05/20/84)
That still does not mean we can loosen up at all on the requirements for a new group. If we have 300 active groups and 600 tired groups can pop up and down, we can still easily have the too many groups problem.
woods@hao.UUCP (05/21/84)
Although I agree with Orlando in principle, I would like to point out that
there is one big problem with his (and jj's) proposal: the lines for old
groups will still be in each user's .newsrc file. This will slow readnews
down (and possibly overflow some buffers) unless something is added to cause
readnews to automatically delete "tiredgroups" lines from a user's .newsrc
file when an update is done. How about it, news gurus? How difficult would
that be to implement?
GREG
--
{ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax}
!hao!woods
"Will we leave this place an empty stone?"alb@alice.UUCP (Adam L. Buchsbaum) (05/23/84)
Greg, I'm afraid you're wrong. 2.10 and after news removes newsgroups from the .newsrc if they are not in the active file.
osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/23/84)
Glad to hear to some comments on the 'tiredgroups' idea.
About readnews deleting groups from the .newsrc file if
they are not in the active file: That's fine.
Whenever the semi-active group (aka tired group)
is revived, we restart numbering articles with #1.
Since there were no articles and your .newsrc file doesn't
have memory of the group, it's perfectly logical to restart
numbering with 1.
I also realize that the 'tiredgroup' implementation should apply
to subgroups only. That way we all can discuss in more detail
the merits of a new high-level group. But allowing creation of
subgroups more freely, will serve us (users and administrators)
very well, since it will make the reading of news more compatible
with the user's interests in a convenient way, and save the traffic
generated by the eternal discussion of the merits of a new subgroup.
I believe, though I don't have the numbers, that the implementation
would be beneficial to the bottom-line.
To finish, I have strong reservations about the 'justification' idea,
especially for subgroups, and understand that it's just an argument
used to compensate for the non-dynamic nature of the news software.
How can a discussion be justified if people haven't found the right
forum to start it and keep it going in the first place? And in the
end, who is the Magister Ludi that must be convinced of such
'justification' ?
Keep the ideas coming. Flames to /dev/null.
--
Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Crawfords Corner Road
/Holmdel, New Jersey, 07733 (Room 3M 325)
Tel: 201-949-1532 /UUCP: {{{ucbvax,decvax}!}{ihnp4,harpo}!}hou2d!osdalb@alice.UUCP (Adam L. Buchsbaum) (05/23/84)
A problem with removing lines from .newsrc when groups go to tiredgroups and then putting them back is that all sense of unsubscription (via the U command) is lot for those groups, and the user will have to reunsubscribe to each group every time it goes to and comes from tiredgroups. There is almost always a suitable place to test-run a new discussion. If not, that's what net.misc is for.
salkind@cmcl2.UUCP (05/24/84)
The main argument against more dynamic newsgroup creation/deletion seems to be that the current B news software can't handle it. I will accept this argument as a short term explanation of why such a feature does not exist. But not as a reason for rejecting such a proposal out of hand. I agree that newsgroups should be deleted (expired) automatically by the software. Currently newsgroups, once created, hang around forever in B news. This is wasteful, annoying, and probably can be changed (for instance, notes already has an automatic expiration facility). --- How newsgroup creation should be handled is less obvious. The real problem here seems to be that the news organization method (using only newsgroups to classify articles) is not powerful enough. The notes system addresses this problem some what (by grouping responses within newsgroups), but there is still a long way to go here.
dman@homxa.UUCP (#D.ANDERSON) (05/24/84)
Adam > A problem with removing lines from .newsrc when groups go to > tiredgroups and then putting them back is that all sense of > unsubscription (via the U command) is lost for those groups, > and the user will have to reunsubscribe to each group every > time it goes to and comes from tiredgroups. Well, if we're going to suggest a tiredgroups, we might as well suggest a .newstr (tired .newsrc) file to keep track of tired group subscription status. And the best thing - it can be automatic. As long as things in the tired lists are kept sorted (simple and fast, like alphabetic), everything should stay fairly fast. Adam > There is almost always a suitable place to test-run a new > discussion. If not, that's what net.misc is for. Agreed, but seriously, does everyone who'd participate in a newsgroup read net.misc? If something "new" comes up, I'd like to give it a new "U" if I decide not to read it. New groups should spring up naturally, at least in the absence of discussion-oriented news. I don't mind typing a "U", but I'd hate to have to read alot of excess just to find new topics. By the way, there is NO reason we have to limit ourselves to 512 groups. Sure, its a nice round power of 2, but if we need more groups, we can certainly accomodate them. Processes are only getting bigger these days anyway. Using up additional memory to keep more groups when running checknews and readnews shouldn't scare anyone except those with systems without paging and small memories. "... and here's your I.D., your GUN, your TEAR GAS... EVERYTHING YOU NEED! It's Dave Anderson all in the bag! Now let's get to work!" 201-949-5552
werner@ut-ngp.UUCP (05/24/84)
RE: alb@alice: "There is almost always a suitable place to test-run a new discussion. If not that's what net.misc is for. " Not the first time that I see this argument, and repetition does not make it any better. net.misc is simply not a good forum to bring up anything, because most people don't read it. How the hell can you get a discussion started then, when you can't reach the people who'd be interested and generate "enough" volume to "justify" a seperate group or sub-group? And who dares to play "Authority" - who needs it, anyway? The argument: "Well, read net.misc then" stinks, so don't bring it up. The simple truth of the matter is, that we have no CONVENIENT mechanism to deal with the problem yet, and in our consumer-society, inconvenience tends to result in self-defeat. That's why "me and the gang of good guys on slow (<1200 Baud) lines" have to U all groups which contain a lot of "noise", and net.misc sure is that. There are ideas to improve things, but that takes code-hacking, and compatibility work, soooooo until then, let's make it easy on ourself, and, maybe create a mechanism for "TEMPORARY GROUPS" with an automatic sunset-provision, so that when I want to discuss the new Spielberg movies, I get the group "net.movies.gremlins" (or whatever) created with ease, with a built in time-bomb to self-destruct, after 3 months or 2 weeks without activity. And until this (minor???) code change can be implemented, let's just be real liberal with sub-groups, and not very tough with first level groups. werner @ ut-ngp
alb@alice.UUCP (Adam L. Buchsbaum) (05/24/84)
How do you then distinguish between a group that's no longer in the active file because it has really been removed for good and one that is just tired? You would see the .newstr file get endlessly large with groups that will never come back. What about those small machines? Why should thy be forced off the network because they can't run a readnews big enough to handle all the groups? Doesn't seem fair that piddly little groups that should never have come into existence be able to toss a machine off the net, does it?
osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (05/24/84)
In reply to some questions:
How do you then distinguish between a group that's no
longer in the active file because it has really been
removed for good and one that is just tired?
Read the original proposal. The system would have a tiredgroups
file to identify such groups. If a cancel group message comes,
the group would be deleted from the active file or the tiredgroups
file, depending on where it is.
The comment:
You would see the .newstr file get endlessly large with groups
that will never come back.
I'm not sure the .newstr file is really necessary. A change in the
way the unsubscribe group command (U) is implemented could be the
answer.
More questions:
What about those small machines? Why should thy be
forced off the network because they can't run a readnews
big enough to handle all the groups?
Most installations are selective in one way or another (and for
other reasons besides the number of groups) with regards to what
groups they decide to receive and forward. What may drive
many smaller machines out of the network is the amount of traffic,
not the number of groups. The amount of traffic, not
surprisingly, is not a linear function of the number of groups
so there are many ways to optimize the load you can handle in
your small machine.
Now a rhetorical question:
Doesn't seem fair that piddly little groups that should
never have come into existence be able to toss a machine
off the net, does it?
The question of fairness is unfair because
under the present method of creating new groups, who makes the
value judgement that a group should never
come into existence, even before giving the group a chance to
exist? It's not the network, but usually a very vocal and small group
of administrators that would resort to cancelling groups that
they think should never be created. Again, if a machine can't
handle all its news traffic, it now has ways (locally, or with
the cooperation of its news feed) to cut down the traffic, no
matter how many active or semi-active groups there are.
--
Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Crawfords Corner Road
/Holmdel, New Jersey, 07733 (Room 3M 325)
Tel: 201-949-1532 /UUCP: {{{ucbvax,decvax}!}{ihnp4,harpo}!}hou2d!osdrcd@opus.UUCP (05/25/84)
alice!alb: >> "There is almost always a suitable place to test-run a new discussion. >> If not that's what net.misc is for. " ut-ngp!werner: >Not the first time that I see this argument, and repetition does not make >it any better. net.misc is simply not a good forum to bring up anything, >because most people don't read it. How the hell can you get a discussion >started then, when you can't reach the people who'd be interested... The volume of material posted to net.misc and the lengths of some of the interchanges shows this not to be the case. The articles are coming from somewhere - and I don't think people post something and ignore the responses. Anyway, you seem to have missed Adam's point - net.misc only has to handle the new discussions that don't fit anywhere else, and he's correct that there are very few such discussions. -- ...Stop to smell the flowers. Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303) 444-5710 x3086
alb@alice.UUCP (05/25/84)
If you are going to be less willing to accept the software can't handle it as a long term excuse, you should be more willing to write code for it.
laura@utzoo.UUCP (Laura Creighton) (05/27/84)
Adding anything to news would be difficult. Read the code and you'll see what I mean. However, news 2.10.1 *already* deletes news groups from .newsrc's which are not found in the active file. This makes for endless hours of entertainment if something happens to your active file. -- Laura Creighton utzoo!laura
laura@utzoo.UUCP (Laura Creighton) (05/27/84)
If anybody ever wants to archive all of a tired news group on tape, and that newsgroup repeatedly comes back to life and gets restarted at newsarticle #1, that person is going to have a more difficult time maintaining and restoring his archives. -- Laura Creighton utzoo!laura
geoff@utcsstat.UUCP (Geoff Collyer) (05/28/84)
Dave Anderson says By the way, there is NO reason we have to limit ourselves to 512 groups. Sure, its a nice round power of 2, but if we need more groups, we can certainly accomodate them. Processes are only getting bigger these days anyway. Using up additional memory to keep more groups when running checknews and readnews shouldn't scare anyone except those with systems without paging and small memories. The attitude that ``Gee my VAX has a 6 megabyte data space, so no one needs to ever think about memory constraints'' is widespread and dangerous. It is possible to fill even a 6 megabyte data space. The advantage of facing memory constraints squarely is that your programs have a good chance of running on even quite small machines. Portable programs can not assume a 6 megabyte data space. B news is not wonderfully portable, but after delinting here, 2.10.1 now runs on at least the VAX-11, IBM 370 compatible machines and the PDP-11. There are an awful lot of PDP-11s still in use (utcsstat is an 11/70, utzoo is an 11/44) and they run a wide class of programs. If news programs won't run on PDP-11s, then you have split USENET into two pieces: PDP-11 and other small virtual address space machines vs. everybody else. The PDP-11-et-al half continues to run 2.10.1 and everybody else gets the latest whizzo, spiffo version. Now all the VAX snobs in the crowd (including the Utah Usenix program committee) can argue that PDP-11s are ancient and unfashionable and we should downgrade to a VAX. However, PDP-11/44s and /70s are VAX-11/750-class CPUs and clean the toy VAXes (730, 725, etc.) utterly. Our 11s continue to serve us well, *as long as people don't make their programs gratuitously unportable*. Again, some will say that if expanding news limits breaks PDP-11s, well that's not gratuitous, it's further justification for getting a machine with a bigger virtual address space. There certainly are legitimate needs for bigger virtual address spaces and people hereabouts are looking at machines with same, but in the case of news, I think the problem is poor design. News needs a re-write. It's over-engineered, over complex, too big, too slow and it tries to be a self-contained subsystem. The essential jobs of news can be done by shell programs; a few features such as posting to multiple groups add a great deal of complexity and likely make C programs necessary to get reasonable speed.
phil@amd70.UUCP (Phil Ngai) (05/28/84)
My machine is a PDP-11/70 and can be considered a "small" machine
because any process can only address 128Kb of memory. This is a
real limitation, I can't run vnews, for example. If you let the
number of newsgroups get too large my machine will start dumping
core. As a result of that the following sites:
fortune, dual, sco, onyx, resonex, visia, cae780, ubvax,
megatest, pyramid, zentec and several other machines
who get news from me will be unhappy. Likewise, if I cut back on some
newsgroups, all the above mentioned sites will be deprived.
That doesn't seem fair, does it?
(I only feed fortune,dual,sco,onyx,resonex,visia,and zentec
directly. The others are fed indirectly.)
--
Phil Ngai (408) 749-5286 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phildman@homxa.UUCP (#D.ANDERSON) (05/31/84)
>> By the way, there is NO reason we have to limit ourselves to >> 512 groups ... Using additional memory to keep more groups when >> running checknews and readnews shouldn't scare anyone except >> those with systems without paging and small memories. > The attitude that "Gee my VAX has a 6 megabyte data space, so no > one needs to ever think about memory constraints" is widespread > and dangerous. Very true. But it is the progressive view, and I'd rather push the limits than be forced to hang back. > It is possible to fill even a 6 megabyte data space. The advantage > of facing memory constraints squarely is that your programs have > a good chance of running on even quite small machines. Portable > programs can not assume a 6 megabyte data space. Why not? Paging allows an address space as big as the moon. If you worrying about the physical length of an address, well, I grieve for you. That's why we got rid of our PDPs. > B news is not wonderfully portable ... some will say that if expanding > news limits breaks PDP-11s ... it's further justification for getting > a machine with a bigger virtual address space. There certainly are > legitimate needs for bigger virtual address spaces and people hereabouts > are looking at machines with same, but in the case of news, I think > the problem is poor design. News needs a re-write. Yeah, news is due for a re-write. Version 3.0 should include screen control, user supergrouping, special bulletin boards, etc. We'll see 2.11 first. But as far as I know, nobody's out there writing it. The design of 2.10 is not poor - it is a product of software evolution. But the real question of virtual addressing will bite you in the end. Sure, you can still do alot without it. But the limitations are too great. Why isn't there anyone using PDP-8's to read news? or 8080's? I think that you ought to at least upgrade to a 32 bit machine. At least while you can still unload your PDP's; Soon nobody may want them. How long till we all need 64 bit addressing? Dave Anderson 201-949-5552
neal@denelcor.UUCP (Neal Weidenhofer) (06/02/84)
************************************************************************** >But the real question of virtual addressing will bite you in the end. >Sure, you can still do alot without it. But the limitations are too >great. Why isn't there anyone using PDP-8's to read news? or 8080's? >I think that you ought to at least upgrade to a 32 bit machine. At >least while you can still unload your PDP's; Soon nobody may want them. > Dave Anderson 201-949-5552 I know this isn't net.flame but this kind of "Well, I've got mine so you can just get one too" statement gets to me. I can't believe that I'm in the minority when I say that we don't decide what kind of machines to use by the requirements of net- news. I have enough trouble getting my employer to let me spend my time (time for which they pay me) and use the EXISTING resources to read the news. Now this bozo comes along and says I'm supposed to tell them to scrap all our PDP's and spend >$1E6 on VAXen so I can continue to do so. Regards, Neal Weidenhofer "The law is for protection Denelcor, Inc. of the people" <hao|csu-cs|brl-bmd>!denelcor!neal
chuqui@nsc.UUCP (Chuq Von Rospach) (06/03/84)
>But the real question of virtual addressing will bite you in the end. >Sure, you can still do alot without it. But the limitations are too >great. Why isn't there anyone using PDP-8's to read news? or 8080's? >I think that you ought to at least upgrade to a 32 bit machine. At >least while you can still unload your PDP's; Soon nobody may want them. > Dave Anderson 201-949-5552 Good grief. Let us face some facts here. First, PDP's are still being sold. PDP's run Unix. Usenet is basically a Unix based piece of software (with minor exceptions). The reason PDP-8's and 8080's don't run news is basically because they don't run Unix. If they did we'd probably try to support them as well. This is NOT VAXnet. This is NOT BSDnet. This is USENET. The software that we publish needs to be portable so that it can reach the widest possible audience. If it doesn't we are artificially crippling the network. What you are telling us to do is basically the same as suggesting that a person write a program for the IBM PC but require that the PC have 512K instead of 128K so that you can do everything. Any marketing person will tell you that you are cutting your own throat. True, if you DO have 512K you should be able to do more (or better), but you don't ignore the much larger market of 128K machines because of it. You figure out how to get the software to do it slower or with a little less functionality or something. You don't tell people to blindly upgrade unless you absolutely have to. (What you do is get them hooked onto the thing and then let them talk themselves into the upgrade after the fact). Anyone who honestly things they can ignored PDP's has no idea how many of them are still out there. They also seem to ignore the trend to workstations and smaller personal machines, not every one of which is going to try to simulate vaxes. Massive addressing spaces is for the lazy programmers who don't want to have to think about things like structure and efficiency (both of which are sometimes amazingly lacking in usenet software at times). chuq -- From the closet of anxieties of: Chuq Von Rospach {amd70,fortune,hplabs,ihnp4}!nsc!chuqui (408) 733-2600 x242 I'm sure I have my death ray in here somewhere...
bytebug@pertec.UUCP (06/04/84)
> I think that you ought to at least upgrade to a 32 bit machine. At > least while you can still unload your PDP's; Soon nobody may want them. Sure, with people like you around to make the PDP obsolete before it's time... Some people seem to have tunnel vision, and assume that what is good for them will be good for the rest of the world. Unfortunately, there are some basic constraints that the rest of us have to live with, like money. I'm sure if you'd be willing to donate a VAX to the local university, they'd be glad to accept. Until then, they're stuck with an 11/45. I would suggest that some of you people read Ian Darwin's "The UNIX File" column in the June issue of MICROSYSTEMS. Especially the part about "Generation Gap", in which he discusses a conversation with a colleague about the new generation of hacker who seems to want to butcher UNIX because they have no idea of why UNIX was successful in the first place.
mwm@ea.UUCP (06/07/84)
#R:homxa:-22100:ea:8700001:000:1685 ea!mwm Jun 6 17:34:00 1984 /***** ea:net.news / nsc!chuqui / 7:27 am Jun 4, 1984 */ >This is NOT VAXnet. This is NOT BSDnet. This is USENET. The software that >we publish needs to be portable so that it can reach the widest possible >audience. If it doesn't we are artificially crippling the network. So you will have us cripple our software instead? >What you >are telling us to do is basically the same as suggesting that a person >write a program for the IBM PC but require that the PC have 512K instead of >128K so that you can do everything. I have bad news, Chuqui - most IBM PC software needs more than 128K to run in. Most of it will run in 256K, but I suspect that the 8086's crippled addressing modes have more to do with that than anything else. >Anyone who honestly things they can ignored PDP's has no idea how many of >them are still out there. They also seem to ignore the trend to >workstations and smaller personal machines, not every one of which is going >to try to simulate vaxes. Massive addressing spaces is for the lazy >programmers who don't want to have to think about things like structure and >efficiency (both of which are sometimes amazingly lacking in usenet >software at times). I think you have that backwards. Those who insist that everything should run on 1970'ish hardware are ignoring the trend to personal workstations, most of which are based on the 68000. I don't know of *any* personal workstations based on machines with small address spaces; could you name some for me? As for structure and efficiency, some things just flat *will not* fit on a PDP-11. Examples upon request. >chuq >From the closet of anxieties of: Chuq Von Rospach /* ---------- */ <mike
alb@alice.UUCP (Adam L. Buchsbaum) (06/08/84)
My list does not account for local groups. While it may have less than 200 groups in it, with local groups here, our total is 275. Others may be higher or lower.
scw@cepu.UUCP (06/13/84)
In article <8700001@ea.UUCP> mwm@ea.UUCP writes: >/***** ea:net.news / nsc!chuqui / 7:27 am Jun 4, 1984 */ >>This is NOT VAXnet. This is NOT BSDnet. This is USENET. The software that >>we publish needs to be portable so that it can reach the widest possible >>audience. If it doesn't we are artificially crippling the network. Go get em!! >So you will have us cripple our software instead? No, how about writing good code instead. Contrary to popular belief the PDP-11 is becoming more and more common not rarer ( 11/23 and 11/74). > >>What you are telling us to do[...] the PC have 512K instead of >>128K so that you can do everything. > >I have bad news, Chuqui - most IBM PC software needs more than 128K to >run in. Most of it will run in 256K, but I suspect that the 8086's crippled >addressing modes have more to do with that than anything else. > So, the 8086 loses, the PDP-11 is still a *VERY* common machine on our net. And it can do an amazing amount of stuff in spite of its limited addressing capability. >>Anyone who honestly things they can ignored PDP's has no idea how many of >>them are still out there.[...]sometimes amazingly lacking in usenet >>software at times). Right on chuq!! > >I think you have that backwards. Those who insist that everything should >run on 1970'ish hardware are ignoring the trend to personal workstations, >most of which are based on the 68000. I don't know of *any* personal >workstations based on machines with small address spaces; could you >name some for me? > Micro 11/23, minc, minc/23 (this can support unix, sortof) and any number of PDP-11/23 systems in private hands. >As for structure and efficiency, some things just flat *will not* fit on >a PDP-11. Examples upon request. > Of course there are things that won't fit on a 11, there are things that won't run on a VAX too. What does that have to do with the price of tea in China? >>chuq >>From the closet of anxieties of: Chuq Von Rospach >/* ---------- */ > > <mike -- Stephen C. Woods (VA Wadsworth Med Ctr./UCLA Dept. of Neurology) uucp: { {ihnp4, uiucdcs}!bradley, hao, trwrb, sdcsvax!bmcg}!cepu!scw ARPA: cepu!scw@ucla-cs location: N 34 06'37" W 118 25'43"