From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/11522 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus v5.4.62 is released Date: 08 Jul 1997 01:28:25 -0400 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035151218 30852 80.91.224.250 (20 Oct 2002 22:00:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 22:00:18 +0000 (UTC) Return-Path: Original-Received: from sandy.calag.com (root@sandy [206.190.83.128]) by altair.xemacs.org (8.8.6/8.8.6) with ESMTP id XAA03221 for ; Mon, 7 Jul 1997 23:33:43 -0700 Original-Received: from deanna.miranova.com (root@deanna [206.190.83.1]) by sandy.calag.com (8.8.6/8.8.6) with ESMTP id XAA10757 for ; Mon, 7 Jul 1997 23:28:44 -0700 Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by deanna.miranova.com (8.8.6/8.8.6) with ESMTP id XAA13018 for ; Mon, 7 Jul 1997 23:28:54 -0700 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with SMTP id BAA16757 for ; Tue, 8 Jul 1997 01:27:53 -0500 (CDT) Original-Received: from atreides.eng.mindspring.net (atreides.eng.mindspring.net [207.69.183.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 8 Jul 1997 07:28:56 +0200 Original-Received: (qmail 30317 invoked by uid 52477); 8 Jul 1997 05:28:25 -0000 Original-To: ding@ifi.uio.no In-Reply-To: Hrvoje Niksic's message of "08 Jul 1997 06:01:30 +0200" X-Mailer: Gnus v5.4.62/XEmacs 20.3(beta7) - "Oslo" Original-Lines: 54 Original-Xref: altair.xemacs.org dgnus-list:1912 Xref: main.gmane.org gmane.emacs.gnus.general:11522 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:11522 Hrvoje Niksic writes: > Jens Lautenbacher writes: >> > Logical behaviour includes not creating a 100K or so .newsrc.eld >> > by default. >> >> I beg to differ. from the beginners point it's still a bit difficult >> to set up a gnus environment. > Exactly. Which is why Gnus should provide the most palatable > behaviour by default. And I still think this category includes /not/ > creating 100K+ .newsrc.eld by default. FWIW, I'm totally with Jens here. A lot of the listing/jumping/subscribing commands work off of the killed list, as does newsgroup name completion. It is highly disconcerting to request some subset of the group list only to be presented with the few you're subscribed to. Especially when one is told that Gnus' startup performance is directly proportional to how many groups have been killed. Most commands do not have the intelligence to fetch the active file to flesh out a slimmed down killed-list when they're invoked -- a good thing, IMO, since the latency for a complete active file download (we have ~30K entries in our active file, for eg.) and the accompanying memory/cpu usage as Gnus parses it is quite daunting even on a fast box. I quickly learnt to set save-killed-list to t when I left OSU with it's small active file to a server with a reasonable number of groups. Downloading the active file over a 28.8 link (or even 10Mbps ethernet at work, given our active file) is simply not viable for most operations where it's necessary. The loss of functionality annoyed me *hugely*. For instance, I had to guess at and type in the names of groups I wanted to subscribe to -- a show stopper. And I'm not a new user and even understood why things seemed so broken. Finally, I do not understand why disk space is the critical resource in this instance. The resources we'd sacrifice to gain disk space would be latency, bandwidth and DTRTness. Currently, disk space is a lot cheaper than either network latency or bandwidth -- for me, anyway. OTOH, the thing about save-killed-list that annoys me most is the additional time taken to save .newsrc.eld. We can address that in other ways than to default to not saving killed-list. Since it's largest component is the list of killed groups, and since that list is changed infrequently, it could be split out to a separate file (which could even be loaded only on demand, if needed). -Sudish