Don Waugaman <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
