Beartooth via Pan-users posted on Fri, 29 May 2026 19:04:24 -0000 (UTC) as
excerpted:

> Hail Duncan! Long time no read. But your post is typical of you:
> eminently readable, lucidly organized, and full of useful detail.
> (Yes, that's my professional opinion as a literary scholar.) Thank you,
> as always, profusely!

Thanks.  We've had a bit of this discussion before, and I know you're 
ahead of me on this road, but as I'm turning 60 next year the next decade 
definitely has some big changes ahead for me, which has me thinking more 
about what I'm leaving behind.

As I've thought about that I've recognized that while I'm single so don't 
have family to continue my legacy, and I don't have wealth so can't buy a 
legacy.  But one thing I *do* have is all those posts over the years; all 
those people I've helped and the stack of thanks telling me that it's not 
all just wishful thinking.

I know you were in library work so I'm sure you have a similar stack of 
people you know you've helped, and can appreciate just how much that means 
to a person as they consider their legacy, answering for themselves the 
questions: "What sort of eternal bank balance am I going to leave behind?  
Am I satisfied with that?  What might I (continue to) do to improve it?"

> On Tue, 26 May 2026 05:59:02 -0000 (UTC), Duncan wrote:
> 
>> Do note, however, that pan doesn't actually email anything itself --
>> pan only directly sends to news.  Instead, pan hands off email
>> (regardless of what address is in the Mail To line) to the configured
>> email client, so you must have pan configured appropriately for that
>> (see pan preferences, applications tab).  That works, but if you have
>> both pan and your email client configured to add a signature, for
>> instance, you can end up with both signatures unless you delete one or
>> the other.
> 
>       You just gave me a nice piece of news (no pun intended). I didn't
> know (though I should've guessed) that pan could append a sig file.
> Where do I tell it to?

The signature is part of the posting profile.  Edit, Edit Posting 
Profiles, select the appropriate profile and hit Edit (or Add a new one).  
There's a signature section.  Check the appropriate box, and choose the 
type -- pan actually has several choices there, including running a 
command and using the result as a sig, using a text file as the sig, or 
simply typing or copying your sig into a text box.

Then, it's a matter of choosing the appropriate posting profile if you 
have more than one configured.  First, each group has a default posting 
profile which is set in group preferences (select a group, then edit, edit 
selected group's preferences, or context/right-click on a group and select 
edit selected group's preferences there).

Then for particular posts, the first line in the headers area at the top 
of a post/reply lets you choose a posting profile (from a drop-down list) 
if you want to use one different than the default set for that group.

>> Or... entirely in pan, just act as if you're followingup/replying and
>> then save it to drafts instead of actually sending.  That effectively
>> stores it locally and should prevent pan clearing it from cache as it
>> normally eventually would if it's left in the newsgroup (unless like me
>> you have a text-only pan instance with a multi-gig cache that's way
>> bigger than the size of the messages you have saved, and have expiry
>> turned off).
> 
>       Another nugget! How do I configure the cache?

The cache settings are in preferences (Edit, Preferences), behavior tab, 
toward the bottom under Article Cache.

IIRC Clear article cache on shutdown is checked by default so unchecking 
that is the first thing to do if you want it saved across sessions.  

The size of the cache is also configurable (in the same place).  I don't 
remember what pan's default is, but IIRC it was big enough that if you're 
doing primarily text groups (including gmane), it normally took several 
sessions to fill up before it would start deleting the oldest messages 
from cache.  Binary groups are an entirely different story, however, and 
one of my first frustrations with pan back in the day was that because I 
was trying to download to cache and then read or save later (a method I 
brought across from MS Outlook Express, my first news client back in the 
day...), and I was downloading more than the cache size, it was deleting 
messages it had just downloaded before I even had a chance to read them!

Skimming readers note that while I discuss cache size in some detail here, 
there's another critical cache-management detail several paragraphs down!  
Look for the paragraph beginning with **.

So I had to set pan's cache size bigger and I did so... as big as it'd let 
me set it back then, IIRC 1 GiB (1024 MiB).  Of course that wasn't /too/ 
long after 1 GB (note: smaller than 1 GiB) disks were considered "big" and 
I'm sure some people still had them, so that wasn't an entirely 
unreasonable max setting back then, but I remember well when Charles 
bumped the max to 4 GiB, as that was one of the first bugs I had reported 
against free software after switching to Linux from MS Windows, and I was 
amazed that "mere users" could actually talk to the actual devs and get 
things changed... quite a difference from the commercial MS Windows 
software I had mostly used previously.  (Altho I was part of the public 
betas for IE4/OE4 and in fact, first began reading and replying to posts 
on the associated IE4/OE4 beta newsgroups on the MS news server.  But even 
running the public betas, as users we didn't interact directly with the MS 
developers, so being able to do so with Free software developers was quite 
something!!)

Later the max cache size setting was eliminated entirely, so now you can 
set whatever size you want, 100 gig, 1 TiB?  Go for it if you have the 
space and want to.  But do be aware than currently (until DD's sqlite 
database changes land, something Charles considered near 20 years ago but 
never landed so it'll be a big deal when it lands), pan loads posts into 
memory in ordered to properly construct the thread tree when it starts, 
and particularly if your storage isn't SSD yet, the bigger that cache the 
longer pan is likely to take to start!  I remember pan taking 10 minutes 
to load here, before I switched off of spinning rust, because my cache was 
so big and pan was having to load it all off the spinning rust!

OK, so size-wise, for my pan text instance I have pan's cache set to 5120 
MiB aka 5 GiB here.  I actually have it on a dedicated 5 GiB partition 
too, btrfs, with compression turned on so the files use less space than 
the actual file size because they're compressed.  I have literally 
/decades/ of cached messages for some groups, going back to 2002 in some 
cases, and btrfs filesystem usage says I still have over 3 GiB free.  
Compsize (a tool for btrfs that reports on compressed vs uncompressed 
size) says:

Processed 283321 files, 185121 regular extents (185121 refs), 99678 
inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       47%      1.0G         2.1G         2.1G
none       100%       14M          14M          14M
zstd        47%     1019M         2.0G         2.0G

So that's actually a bit over 2 GiB of files compressed to a GiB, 47% of 
original size as you can see above, not unreasonable for text-data 
compression when it's set to favor speed over compression size (mount says 
I'm using btrfs' compress-force=zstd:3 on that partition, which BTW is 
btrfs raid1 so duplicated to two different physical ssds for data safety, 
in addition to having backups).

du reports similar usage, ~2.1 GiB of file data (uncompressed size of 
course, for du, since the compression is transparent at the filesystem 
layer).

**  So we've discussed clear-cache on shutdown and cache size, but there's 
another critical detail left that can still screw up efforts to retain 
cache indefinitely, if desired, that being expiry!

Expiry is a news servers setting, so under Edit, Edit News Servers.  IDR 
for sure what pan's default is, two weeks maybe?  Obviously if your intent 
is to archive the messages, however, you'll want to set it to never 
expire, which is what I've done, certainly for my pan text instance.

For binaries full archiving, actually /never/ expiring, still isn't 
practical for most users with any level of ongoing binary activity at all 
(tho with multi-TB drives it's somewhat possible now, for still-image and 
audio groups at least, arguably less so for full video groups).  However, 
depending on downloading and usage style preferred, setting never expire 
even for binary groups so you can download messages to cache and go 
through them after download without fearing they'll disappear on you, then 
manually delete the cache on the filesystem when you've gone through and 
saved off what you want and are ready for the next batch, can still be a 
valid strategy.

The alternative (still talking about binaries) is I believe what pan's 
developers must have originally intended, that being read the headers and 
selecting to save the desired binaries directly to file (*not* just cache 
the messages first), in which case cache size doesn't matter so much 
(really only for recovery of partial downloads in case of a crash), so a 
smaller cache that expires sooner, say two weeks for the headers, less 
than a full session for the messages themselves as the binaries from them 
will already be saved, works fine.

With those three pan settings managed, uncheck clear cache on exit, set a 
sufficiently large size (and ensure you actually have that room on-disk so 
you won't be filling /it/ up), and set expiry to never, it's possible to 
have pan archive messages, at least text messages, for decades even, as 
I'm doing here.  Of course if you really /are/ intending to archive them, 
you'll need to ensure that you have proper backups as well, in case the 
storage itself dies, taking the messages with it if you don't have 
backups.

-- 
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]
https://lists.nongnu.org/mailman/listinfo/pan-users

Reply via email to