[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] Re: Keeping settings when upgrading from 0.14.2.91 (Fedora C
From: |
Duncan |
Subject: |
[Pan-users] Re: Keeping settings when upgrading from 0.14.2.91 (Fedora Core 5) to 0.123 (Fedora Core 6) |
Date: |
Tue, 6 Mar 2007 11:30:03 +0000 (UTC) |
User-agent: |
Pan/0.125 (Potzrebie) |
Don Waugaman <address@hidden> posted
address@hidden, excerpted below, on Tue, 06 Mar 2007
00:55:21 -0700:
> I recently upgraded a system from Fedora Core 5 to 6 and was rather
> surprised to see pan start up as if it were a brand new installation,
> needing me to restore all of my settings. A little investigation showed
> that the old Fedora Core 5 pan (0.14.2.91) had been superseded by a
> newer C++-based version (0.123), which created a new directory (.pan2)
> for its configuration files.
>
> I'd really like to convert my old files under .pan automagically if
> there's a way - 'twould be rather a pain to do it all by hand. Can this
> be done, and what's the magic incantation to do it? Or should I go
> ahead and start keying in my server settings again?
Welcome! =8^)
In regard to new-pan vs. old-pan and upgrading, there's good and bad
news. The short version is that new-pan is a complete rewrite in (as you
mentioned) C++, and that as part of that rewrite, the way the config was
stored changed enough to make switching directories (to ~/.pan2 by
default) a very wise idea. Never-the-less, certain aspects of the
configuration are similar enough to port over.
The longer version... well, could be pretty long, as you can see if you
look in the list archives at my responses in the past. <g> So, here I'll
try for an intermediate length version, and you can check the archives or
ask as you have additional questions.
First thing upgraders should be aware of is that certain aspects of the
PAN GUI have changed in ordered to better support some of the newer
features. It **WILL** take a bit of getting used to, and advanced users
will find a couple things from the old version still missing in the new
version. If you wish, you can probably continue to run the old version
for some time, even alongside the new version if desired (basically,
rename the binary of the one, I named my old one pan.14, then install/
reinstall the new one, they use different config dirs as you know, so
this is possible). However, the old C version is effectively dead code
now, and no further upgrades will be made available, so it'll gradually
get more and more crufty and harder to keep running on your system as
everything else moves beyond it. Therefore, regardless of whether you
keep old-pan short-term, you should plan on eventually switching to the
newer version, or if it doesn't suit you for some reason, look for other
alternatives (or ask here if it's something that can be changed).
The two BIGGEST changes in new-pan, from a user perspective, is (1) that
it's MUCH more scalable now, and (2), that it's a true multi-server
client now, not just a single-server client (in interface terms) that
happens to let you configure several servers, but then you basically work
with them separately, as in the old version. Both of these changes had
far reaching effects on the configuration at the back end, while the
multi-server view on the front-end had serious implications for the UI
and the configuration UI. That said, you'll recognize the same "style"
in many of the details, and many of the same design philosophies and
goals apply, including both 100% GNKSA compliance and that pan ultimately
be a "Pimp-Ass Newsreader!" (aka PAN, tho for political correctness
reasons the acronym is seldom expanded any longer, and the lower-case
form has become predominant). You'll notice both of those right away as
you work with the new pan, and it helps to keep them in mind as you
explore new pan and the way it has changed, as the reasons for the detail
changes often become apparent if you do.
pan's better scaling, in particular, helps on large groups with more than
a few hundred thousand posts -- pan now starts to noticeably drag at say
a couple million posts, instead of the couple hundred thousand before,
and can handle over 5 million as compared to the say half a million
before, before things become /unbearable/. (It's likely more like 10
million now, as the 5 million figure was before some additional memory
tweaking and memory leak fixing took place.) If you like to keep around
quite a few headers and a large cache, you'll also notice that pan's
start time is better than it was. Where it used to take over a minute
here (from cold memory cache), it now loads several times the data in
only about 20 seconds. For those with less data, where there used to be
a noticeable delay (say 20 seconds), it's now much closer to normal/
instant. I used to keep pan loaded most of the time, simply to avoid the
reload time, but now I don't have to. =8^)
Single server users won't notice that change as much, but particularly
binary group users that used to pull from several servers to get
completion should find the new pan UI VASTLY easier to work with, once
they get used to it, anyway.
As I said, however, all that comes at a cost of a not fully compatible
config. Still, some things can be reused, making the switch easier. In
particular:
* The score file is nominally the same, tho it's a bit stricter to slrn
rules now, not taking the xnews variations it did before. Specifically,
the xnews regex newsgroup entries will need edited by hand to follow the
* wildcard newsgroup entry spec (doc URL below). I had been using regex
news entries here, so had to edit my score file to make it work on new-
pan. However, after reading the documentation and getting a better
picture of the file format, I took the opportunity to reorganize my
scorefile at the same time, and instead of hundreds of individual rules
as I had before, I now have, according to pan, "6 scoring rules in 2
sections", MUCH more efficient, and easier to manage for me as well. =8^)
SLRN scorefile doc (pan remains case insensitive, as that's normally
what's wanted anyway, and I don't believe it implements the advanced
stuff like includes or scores on anything but overview headers, yet):
http://www.slrn.org/docs/score.txt
* While old-pan could export standard *.newsrc format files, new-pan uses
them by default. It's therefore possible to start old-pan (if you still
have it around or reinstall it, and assuming you didn't have it setup to
export newsrc files automatically), export each server into its own
newsrc file, then use those with new-pan. The easiest way to actually
import them would be to setup each new server but DON'T download the
newsgroups list for it, quit new-pan, then overwrite the blank new
newsrc-* files with the appropriate newsrc files exported from old-pan.
New-pan should then use the "imported" files next time it starts.
* The cached posts themselves are I think compatible, as simply a direct
dump of what came down the wire. I didn't actually test this, however,
as I simply used old-pan and new-pan side by side for awhile, and still
have old-pan installed to answer questions against when needed, tho I've
not actually downloaded anything with it for months.
Everything else is I believe new configuration, tho some of it is sort of
similarly organized compared to the old configuration files. Setting
names and the like have changed, as well as file names, however, and it's
simply easier to reconfigure the settings than it is to try to match them
up manually.
One other point of significance to mention. New-pan has a number of
settings that were considered too advanced for pan's GUI config, which
Charles wants to keep simple and intuitive, but which never-the-less are
exposed for power users willing to edit their config manually. For
instance, while GNKSA requires that no more than four connections be
configurable to a server to avoid DoSing it, a common request has been
for additional connections, since some servers specifically allow them
(my pay server allows up to eight). The new-pan compromise is that the
GUI lets you configure up to four connections, but in the servers.xml
config file itself, it's a simple integer setting that one can set as
desired.
Likewise, pan's config GUI has no way to set cache size, with a default
of I believe 10 MB, suitable for some text and those that prefer to save
binaries directly, but not for those (like me) that prefer to download
binaries to cache and work from there, and/or to keep text group messages
around after they expire on the server (which is now possible). There's
a cache size setting in preferences.xml, however, which pan honors if you
change it, and which I use here set to 5 gig for my text group pan
instance, and 12 gig (on a dedicated partition) for my binary group pan
instance.
What's that, I can imagine you saying, pan does separate instances now?
Yes, and it actually comes in quite handy, since it's just one long list
of subscribed groups now, no way to separate it by setting up a separate
"server" just to group subscribed groups, as used to be possible. pan
looks in the environmental variable $PAN_HOME, if set, to see where its
config is stored. Thus, you don't have to use ~/.pan2 unless you want
to, and change it by setting and exporting this variable before starting
pan. I've taken advantage of this to setup three separate configs, text
for my text groups, bin for my binary groups, and test for just looking
around and visiting groups I may not want to subscribe to long term.
Where the settings are the same (as for the scorefile and accels.txt), I
simply symlink to a global config dir that has only the common config
files in it. I then use little shell scripts (pan.tst, pan.bin, etc) to
set the appropriate variables and do a couple other things before
starting the pan binary, and have my X menu (kmenu, in my case) entries
launch the appropriate shell script instead of the pan binary itself.
Thus, as mentioned above, the preferences.xml for my text instance has a
different cache setting than the preferences.xml for my binary instance,
because they are separate configs located in separate dirs.
--
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