"Nat Gross" <address@hidden> posted
address@hidden, excerpted
below, on Sun, 03 Sep 2006 20:04:27 -0400:
>> As you may have read by now, 0.14.x is unmaintained now and is unlikely to
>> have further updates.
> Thanks for the detail. I need to work on that. Since I have always
> used yum to pull in the latest updates I am aurprised to hear that I
> don't have the latest. And I just ran yum and didn't find a later
> version of pan. I have many repos enabled in yum (Fedora 5) including
> livna and freshrpm's. So, questions:
> 1) Which repos should I point yum to, to get the latest.
> 2) Is it ok to upgrade in the position that I am now?
It's likely not in a repo directly, just yet. See, the deal is new-pan is
a totally new rewrite in C++, starting from 0.90 with betas. The first
ones were pretty rough, but along about 0.98 or so it started getting
usable, and we're getting pretty close to a stable release, which will be
1.0, now with 0.111. 0.111 was going to be rc1, but Charles decided there
were still a few too many bugs left for that (as you can probably see from
the announcement). Still, it's getting very close. We're still
targeting the end of this month for 1.0 I believe.
It's unlikely the repos will actually have the update until the 1.0
release, if they haven't been carrying them yet. You can however find
builds for various distributions at the usual pan home page at
http://pan.rebelbase.com. Or, you can simply build it from sources. With
gcc-4.x, it's not too bad, altho with the late 3.4 series it takes
something like 3 gig of memory and virtual memory (swap) in ordered to
compile. (With 4.x it's more like 2-300 meg, /much/ more reasonable!)
As far as switching, the new pan uses a different directory (~/.pan2
instead of the old ~/.pan, by default, but it'll look for the $PAN_HOME
env. variable and use that location if it can), so if desired (and allowed
by your package manager), you can even run both versions in parallel for
awhile, until you are comfortable with the new version.
The new version is QUITE different, in several ways. First, memory use is
VASTLY better on large to huge groups (millions of headers), and so is
performance. Pan no longer virtually grinds to a halt @ a couple hundred
thousand headers like it used to. As a result of the improvements, it
also loads far faster -- you can't go make coffee while you wait for it to
load, like you could do before, after it got a sizable database anyway. =8^)
The other BIG change is multi-server handling. This has been talked about
for a LONG time, but it finally got done. If you have only a single
server, you won't notice the difference. If you have multiple servers,
you certainly will, as instead of having each server's groups set up in
that server, there's now one big huge group list, with all groups from all
servers in it. There are server priorities as well. From the GUI the
choices are main (1) and backup (2), but you can set as many priority
levels as desired by editing the servers.xml file. (There are a number of
other settings that have more possibilities when editing the config files
directly, as well.)
There's a lot of other changes too, smaller ones, but many of them are
related to the new multi-server handling in some way.
In terms of config file compatibility, some are close, some not. Pan
tracks newsgroup activity with standard newsrc files now, one per server,
where it used to be an option. You may be able to export to rcfile in
old-pan and then replace the empty ones first created by new-pan when it
creates a new server. (Of course, do the replace when pan is shut down.)
The caveat there is that I don't remember how pan treated multiple servers
in terms of newrc file, with the old pan. As mentioned, the new one is
one per server.
The score file is nominally compatible as well, but new-pan is stricter to
slrn's scorefile standards, the biggest change being old-pan took regex
for the newsgroup lines in the scorefile, while new-pan uses *-wildcard
style newsgroup matching. Other matches remain regex however, except that
all matching (group and regex) is case insensitive. If you are going to
have to manually edit your score file anyway, you might as well do it
right and combine all the scores into compound versions, reducing the
number drastically, as I did here. From nearing 100 scores in old-pan (I
regularly weeded out the expired ones), I now have six scoring rules in
two sections, according to pan's log. Here's the reference URL:
http://www.slrn.org/docs/score.txt.
I /think/ the raw cache files are compatible too, as they're all simply as
taken off the wire, with message-ids as filenames, but I might be wrong on
that.
Everything else is pretty different: all the preference files, the
accels.txt because the names of all the entries are different (which you
can still edit manually but not in the PAN GUI any more), various other
metadata files, etc.
One thing interesting to note is that pan now stores its task list as a
standard xml formatted nzb file, making it easy to import into anything
else that takes nzbs. It's also possible to feed pan an nzb from the
command line and have it fetch the posts, so you can import nzb files into
pan.
One of the big issues people have been running into with the groups from
all their servers in one big list is that it gets too big to be
manageable. A lot of folks prefer to keep their text groups in one place,
and their binaries (which they may not want just anyone seeing) in
another. The big list isn't categorized, making that inconvenient.
However, I mentioned the $PAN_HOME var above. It's relatively easy to
have two or more separate instances of pan, running with different home
dirs as set in that variable. Here, I have three, a binaries instance, a
text-group instance (which has gmane as one of the servers, which is how I
follow this list =8^), and a "testing" instance, for visiting groups that
I probably won't be subscribing to, at least not for long. I may
eventually split up my binaries into two or more separate instances as
well.
That's a quick rundown. You may wish to upgrade now, or wait for 1.0.
Either way, this info will come in handy. You may have other questions
once you start running it. Go ahead and post them when you do. It's
possible you'll run into a few bugs, too. Testing and filing bugs is
pretty important right now, as we want to quash as many as possible before
1.0. 1.0 has been a very long time coming, so we want it to be a good
one! (That said, there are a few features that won't make it until the
pre-1.1 series. As an example, we have scoring in the new pan, but
nothing like the rules that were in old-pan, so it's impossible to
auto-delete killed posts as I used to, and auto-mark-read neg-score posts
as I used to as well. These features won't make it into 1.0, and may well
be implemented differently when the do appear.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
_______________________________________________
Pan-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/pan-users