A newsreader is a program that users invoke to view, store, and create news articles. Several newsreaders have been ported to Linux. We will describe the basic setup for the three most popular newsreaders: tin, trn, and nn.
One of the most effective newsreaders is:
$ find /var/spool/news -name '[0-9]*' -exec cat {} \; | more |
This is the way Unix die-hards read their news.
Most newsreaders, however, are much more sophisticated. They usually offer a full-screen interface with separate levels for displaying all groups the user has subscribed to, an overview of all articles in each group, and individual articles. Many web browsers double as newsreaders, but if you want to use a standalone newsreader, this chapter explains how to configure two classic ones: trn and nn.
At the newsgroup level, most newsreaders display a list of articles, showing their subject lines and authors. In big groups, it is difficult for the user to keep track of articles relating to each other, although it is possible to identify responses to earlier articles.
A response usually repeats the original article's subject, prepending it with Re:. Additionally, the References: header line should include the message ID of the article on which the response is directly following up. Sorting articles by these two criteria generates small clusters (in fact, trees) of articles, which are called threads. One of the tasks of writing a newsreader is devising an efficient scheme of threading, because the time required for this is proportional to the square of the number of articles.
We will not go into how the user interfaces are built here. All newsreaders currently available for Linux have a good help function; please refer to it for more details.
In the following sections, we will deal only with administrative tasks. Most of these relate to the creation of threads databases and accounting.
The most versatile newsreader with respect to threading is tin. It was written by Iain Lea and is loosely modeled on an older newsreader named tass (written by Rich Skrenta). It does its threading when the user enters the newsgroup, and it is pretty fast unless you're getting posts via NNTP.
On a 486DX50, it takes roughly 30 seconds to thread 1,000 articles when reading directly from disk. It would take more than 5 minutes over NNTP to reach a loaded news server.[1] You may improve this time by regularly updating your index file by invoking tin with the –u option, so that when you next start tin to read news the threads already exist. Alternatively, you can invoke tin with the –U option to read news. When invoked this way, tin forks a background process to build the index files while you are reading news.
Usually, tin dumps its threading databases in the user's home directory below .tin/index. This may be costly in terms of resources, however, so you should keep a single copy of them in a central location. This may be achieved by making tin setuid to news, for example. tin will then keep all thread databases below /var/spool/news/.index. For any file access or shell escape, it will reset its effective uid to the real uid of the user who invoked it.[2]
The version of tin included in some Linux distributions is compiled without NNTP support, but most do have it now. When invoked as rtin or with the –r option, tin tries to connect to the NNTP server specified in the file /etc/nntpserver or in the NNTPSERVER environment variable. The nntpserver file simply contains the server's name on a single line.
| [1] | Things improve drastically if the NNTP server does the threading itself and lets the client retrieve the threads databases; INN does this, for instance. |
| [2] | This is the reason why you will get ugly error messages when invoking tin as superuser. But you shouldn't do routine work as root, anyway. |