pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: FQDN and hostname


From: Duncan
Subject: [Pan-users] Re: FQDN and hostname
Date: Sat, 23 Sep 2006 19:36:31 +0000 (UTC)
User-agent: pan 0.113 (0.113 is one of Nakata's favorites)

Thufir <address@hidden> posted
address@hidden, excerpted below, on 
Sat, 23 Sep 2006 09:30:36 +0100:

> [Off topic] Why fedora can't simply copy, and maybe improve, gentoo
> e-builds, being, of course, an homage to the BSD port system, is a
> mystery to me. Pride?

FWIW... I'm a Gentooer myself, so I obviously think it's the best solution
for me. =8^)  However, I recognize that compiling from source isn't
everybody's idea of fun, or what they want to spend their time on, and
indeed, that for users with a single core/cpu of less than say 2 GHz, it'd
be a rather huge burden, both for the time compiling and the fact that a
single core simply can't multitask as efficiently as two or more, so for
such a user there WILL be a major tradeoff in terms of time spent keeping
the system updated.

The problem is, and I didn't really understand the full implications of
this until I had spent some time on Gentoo and could actually /see/ them,
once one decides to go with a primarily binary (that is, upstream
compiled) solution, HUGE compromises must be made in terms of dependency
flexibility vs. supported options.  Where compile time choices must be
made in what one supports and therefore what one depends on, no matter
WHICH way one goes, there are serious tradeoffs.  Either one supports all
sorts of stuff but ends up bringing in all sorts of bloat for those that
don't use it all -- and few actually use it /all/, the problem is the part
that gets used depends on the deployment, or one seriously limits support
for optional features by choosing not to depend on them and thereby not to
have that bloat.  There's no single right answer, nor /can/ there be. 
Gentoo's answer is to leave the compiling to the end user/sysadmin, who
can then choose his own balance on the continuum between lean but spartan
and supporting everything but hugely bloated.  However, that has its own
tradeoffs, namely all the time spent compiling by all those end users, vs
centralizing the compiling (and the dependency/support choices).

That's why you don't normally see a binary distribution choose to support
KDE and GNOME equally.  They standardize on one or the other, building in
full support for it, and for the other, omit some of the advanced support
and the dependencies it would require.  Even that is incredibly bloated
however, for end users who choose say xfce, and even worse for those
running servers or whatever who don't want X installed at all. It's simply
impossible to be all things to all people, so the distributions
specialize.  That's a /good/ thing, and remains a /good/ thing whether you
agree with the specialization of an individual distribution or not,
because there are bound to be other choices out there better matching your
specific needs! =8^)

So... we have Fedora, which as with many distributions, has chosen to
target the primarily binary installing end user.  It's certainly a
legitimate choice, but as with any alternative at that level, it comes
with its own set of costs as well as benefits.  The biggest of these costs
is that by definition of being a binary distribution, it limits itself to
a particular feature set and emphasis in terms of what it chooses to
support.  However, Fedora being quite popular, it has developed an entire
ecosystem of alternative repositories, each emphasizing its own angle, if
you don't happen to like the particular angle Fedora main and extra has
chosen to implement.  By definition, some of these repositories will be
incompatible with others, due to their differing emphasis leading to
different compile-time choices and therefore differing dependencies. 
That's just the way things are -- there's no way around it except by going
the Gentoo route and leaving all those choices along with the job of doing
all that compiling, to the end user sysadmin, and that choice as well has
serious negatives.

Fedora /could/ copy and possibly improve on Gentoo and the BSD ports
system.  However, that would either be an exercise in futility, if they
tried to retain their primary prebuilt binary focus, or would be a
/dramatic/ change from what RH/Fedora had done traditionally, with a
switch to a source based, compiled at the end user end, focus.  I don't
believe most Fedora users would want the latter, or they'd already be
Gentoo users, not Fedora users, right now.

Indeed off topic, but perhaps it'll enable a better understanding of the
dynamics of this particular part of the FLOSS ecosystem, for more than
just one person on the list.

> on topic:  if I upgrade, or run two versions of pan, it won't make a
> difference because pan is just connecting to leafnode, yes?
> 
> Things like, which messages are read, or not, or which groups are marked
> "subscribed", can that info carry over to the updated version of pan?
> The messages themselves are in leafnode, of course (as is the
> "interesting.groups" directory, which is related to the subscribed
> groups in pan).

It depends on the versions you have in mind.

Old-pan, 0.14.x, and new-pan, >=0.90, use entirely different directories by
default, which is a good thing since their configuration files are quite
different.  Thus, you can run them in parallel with no interference, but
no, they won't be picking up each other's settings, including each other's
tracking of read messages (except if you directly enable that, see below).

With two versions of new-pan, >=0.90, it's possible to run separate
directories as well, if desired, setting the $PAN_HOME variable
separately for each, but I'm not sure why one would /want/ to run two
different new-pan versions. Either the latest works and one will want to
run it, or it doesn't for some reason, and one wants to stick with a
slightly older version until the problem is resolved.  (OTOH, the separate
dirs ability comes in handy for running separate instances of the same pan
version, say one for binaries and one for text, if desired. That's one way
of working around pan's inability to categorize and group newsgroups.  It
also allows one to have different binary group settings, say a larger
cache and different expiration, than for text groups.)

As for the differences between old-pan and new-pan configurations, similar
and partially compatible formats are used in some cases, but not all.  In
particular, the score file and newsrcs are similar.

For the score file, new-pan is stricter in the slrn format than old-pan
was, as old-pan allowed the xnews variant format while new-pan doesn't so
much.  Specifically, slrn (and new-pan) treat newsgroup matching in the
score file as * wildcard type, while xnews treated them as regular
expressions.  Old-pan tried to figure out which was being used and
match accordingly, a strategy that's certainly going to be complex and
fraught with the possibility of misinterpretation.  The one xnews thing
that new-pan retains is case insensitivity, where slrn's score format is
case sensitive both in the regex matches and the newsgroup/*-wildcard
matches, xnews and pan (both old and new) are case insensitive by default.

Thus, if you used regex newsgroup matching in your old-pan scorefile (as
I did), you'll have to redo it for new-pan.  That isn't all bad, however,
as I took the opportunity to reorganize and drastically simplify my
scorefile.  It now has only six scores in two sections, according to the
pan event log, altho both the scores and the sections are compound --
multiple individual matching tests per entry.

Scorefile documentation resources (see the xnews one for how to make the
regex matching case sensitive if desired, otherwise, pay more attention to
the slrn one):

slrn: http://www.slrn.org/docs/score.txt

xnews: http://xnews.remarqs.net/scoring.txt

The newsrc file format is I believe unchanged, but new-pan uses different
filenames.  Symlinking (or simply copying/moving it over if you are
switching, not intending to run both) should work, however, tho I'd ensure
I had backups during initial testing in case the newsrc for one server
gets accidentally used for a different one, and therefore screwed up.

I /think/ the cache is the same format, but I'm not sure on that and
didn't try using the same cache here, so can't verify it.

The accels.txt is a similar format, but of course with different entries,
so don't try to share it between old and new pan.

Most other files are different.  Certainly the tasks list is different, as
the new format is simply an nzb file.  The preferences file like
accels.txt is a similar format (xml based) but with enough different
settings I'd not try to copy it over.

-- 
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]