Re: Gnus v5.4.62 is released

[Sudish Joseph <sj@eng.mindspring.net>]

Hrvoje Niksic writes:
> Jens Lautenbacher <jens@metrix.de> 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