> "Peter Meric" wrote:
> > "What is bad about tin, that is worse than other news readers? What is better
> > about it?"
> A few points (I'm not sure how these apply to `nn', it's been so long
> since I've used it -- and no, I don't use emacs or pine either :-).
I assue that you are speaking in tin's support, not "What is bad about
> - `tin' can talk directly to an NNTP server without needing to maintain
> any local indexing or other information (except .newsrc) -- good for
> using news.socs during and since the great sequoia news drought of
> early '93.
Good and bad - good if your admin is incompetent, bad a nasty performance
hit. Assuming a well-administered system, nnmaster runs in the background
and saves significant network bandwidth.
> - `tin' is capable of dealing with multiple NNTP servers (not at the
> one instance) -- good for snarfing alt.* groups that haven't made it
> into aus.
Hmmm - I haven't looked into this - again, talk to your admin. Tell
INN to simply pick it up - again, network bandwidth optimisation is
somewhat better this way anyway.
> - `tin' can submit news _directly_ to the NNTP server, none of this
> `inews' crap -- good for immediate notification of a "too full"
> NNTP server.
Again - incompetent administration. What sort of idiot lets his news
spool get "full"?
The inews approach has its benefits - the analogy is poor but it's a
little like arguing for the use of rsh to direct deliver mail rather
than using SMTP. Yes, you get to find out all sorts of neato things
about the remote machine, but...
> - `tin' can do automatic unshar, unzip, uudecode and the rest (including
> concatenation of multiple articles) -- good for those pictures from
As can nn.
> I'd say that the onus is on those "bashing" to present a qualitiative
> arguement as to why tin or nn is disfunctional apart from subjective
Of for those arguing either way to work out what "better" means.
Ease of use, ease of learning to use, number of features,
consistency of menu choices...
Install them all...