[Pan-users] Re: Where does Pan keep its cache files... retrieved headers, articles, etc.?

[Duncan]

walt <address@hidden> posted
address@hidden, excerpted below, on  Sat, 20 Jan 2007 00:59:44
+0000:

> On Sat, 20 Jan 2007 00:00:09 +0000, Charlie Wilkes wrote:
> 
>> I am new to Linux (Ubuntu)
> 
> Welcome to the un-Windows world.

Continuing this subthread.  Probably the single most helpful
recommendation I asked for and got when I got serious about Linux, and
consequently one I pass on as often as possible, is to pick up a copy of
the following two books.  Together they run $70-80 USD, but the one saved
me literally a minimum of 500 hours screwing around unproductively on my
own trying to figure things out, and the other I've bought an updated
version of and likely will by another pretty soon as well, so you tell me
whether it was worth it. =8^)

Both books are published by O'Reilly.

Running Linux is a 600-ish page tome in tutorial or textbook format,
designed to be read more or less front to back, generally simple stuff
(like Linux file permissions and the basic commands for working with files
and directories in Linux) at the front, more complex stuff at the back. 
Until I read this book I was more or less lost on Linux, tho I had played
around with it some.  When I got serious, I asked for book recommendations,
and this and the following one came up repeatedly, so I got them, and it
made a world of difference. =8^)

Linux in a Nutshell is as are all the O'Reilly "Nutshell" series books,
intended as a reference for someone already familiar with the basic
concepts, but needing help with specific commands and their options from
time to time.  The best description I've seen for it was an excerpt from a
review that was included on the back cover of the third edition, something
to the effect of "Like a stack of manpages but far easier to carry
around."  However, it's more helpful than some manpages, listing options
and what they do in somewhat less obtuse language, while omitting detailed
descriptions of the "expert" options especially, that only confuse the
ordinary user.  This is the one I bought an updated edition of, and plan
on buying another soon, as it's one book I keep within reach at the
computer and continue to use (as it's more convenient than the manpages,
as well as clearer and more concise in many cases) even several years
later.

Both books take a generally distribution agnostic approach, preferring the
mostly universal command line tools and text editor config file editing,
to distribution specific tools that are often somewhat limited in their
flexibility in addition to being parochial.  However, don't less this
scare you as particularly Running Linux does do a really good job of
teaching you exactly what you need to know to do what you want and need to
do.  Still, for things like printing, you may want to use your desktop or
distribution specific configuration tools and just skip or skim that part
of the book, knowing its there if/when you do decide to learn how to
/really/ configure that part of the system.

Anyway, if there's one thing I could point to to say this is what helped
me succeed in becoming a Linux power user, it's those books.  Just as it
was passed to me, I'm happy to pass it on, if it can help someone else
begin to appreciate just all Linux has to offer, while providing some sort
of map or guide in what can otherwise be a very strange and bewildering
world, at first.  If others find the books even a tenth as helpful as I
did, they'll still be thanking me for passing on the recommendation.

FWIW, when I originally bought them, both books were new in their third
edition.  I bought the fourth edition of Linux in a Nutshell as my upgrade
copy, and now I believe both are in their fifth editions.

As for finding stuff, file system layout, here's a brief overview of the
way /most/ Linux (and indeed, with some minor variation, Unix in general)
distributions lay things out:

/etc         system basic/boot services configuration

Basically, anything that you run "one" of, for the entire system, normally
has its config here.  /etc is assumed to be on the root partition, thus
making its configuration files and scripts available from early startup.

/usr         the "guts" of the system

The majority of a system's executables and libraries live in /usr, along
with the /default/ configuration for per-user run or configured apps and
services, such as your desktop of choice (KDE, GNOME, whatever).

It should be noted that on a multi-partition system, /usr may live on a
partition other than /, and extra partitions aren't normally mounted until
about the middle of the startup process. Thus, anything necessary to the
boot process /before/ the mounting of most partitions can't live on /usr,
as it's often not available early in the startup process.

Thus we have...

/bin, /sbin, /usr/bin, /usr/sbin    executables live here

The "s" is short for "superuser", so sbin contains system administration
tools not normally executable by or of interest to ordinary users.

As mentioned above, the /usr location can't be assumed to be available
early in the boot process, so anything that's necessary for early boot,
and system recovery tools that may be used to fix a /usr that won't mount,
live in the /bin and /sbin dirs, located on the root partition.

/lib, /usr/lib, /lib64, /usr/lib64   shared libraries and executables
normally called from other executables, not directly, live here.

On biarch installations such as amd64, 64-bit libraries usually go in the
lib64 location, while "legacy" 32-bit libraries and stuff like python
scripts that are independent of arch normally find themselves in lib. 
(Some distributions have a lib32 for 32-bit specific stuff.  This is also
common on archs such as ia64 where 64-bit is the primary arch and 32-bit
may be emulated or otherwise is considerably de-emphasized.  In such
cases, lib may symlink lib64, or lib64 may symlink lib.)

/usr/local      packages installed manually usually live here

By "manually", I mean not using the distribution's package manager system.
If you get the pan tarball and install it, it'll install pan to
/usr/local/bin by default, for instance.  This is also a good place to
store any sysadmin utility scripts you come up with on your own, as
it is what it says, the domain of "local".  /usr/local therefore normally
contains the usual subdirs, (s)bin, lib(64), sometimes games, whatever
else you put there.  Many installations make it a separate partition,
making it easier to backup on its own and to keep around during system
reinstalls.

/usr/share      documentation and the default config for user apps

/var            service data (mail, news, ftp, web, print servers, logs)

The various service spools and data dirs live here.

/var/log        virtually all system logs live here

Both /var and /var/log are often kept on separate partitions.  Among other
things, that limits the damage if for some reason a log or spool suddenly
sees a lot of activity and gets very large, taking all available room,
since "bad things" (TM) happen if there's suddenly /no/ room left on
partitions such as root, for instance.

/tmp, /var/tmp  system temporary file locations

Sometimes, /var/tmp may be a symlink to /tmp, but there's often a
distinction in how they are used.  However, that's rather more
distribution specific than the rest of this, and hard to explain in a
coherent fashion, so I'll leave it alone.  These are frequently their own
partitions (one reason for the symlink, when the admin doesn't want two
partitions when one will do), since they can be quite active and open
files at the time of a crash are frequently corrupted.  Since it's all
throw-away data anyway, it can be easier to just wipe it and start over.

In fact, as I've 8 gigs of memory here, I keep /tmp (symlinked from
/var/tmp so they are both on it) on a tmpfs in RAM, thus keeping it both
super-fast and eliminating any need to worry about cleaning it up at boot,
since it's wiped clean. =8^)

/opt            "optional" packages.

Many binary-only or larger packages install to /opt by default.  This is
sort of the equivalent of /usr/local but for binary only stuff like games
and large stuff like KDE by default, when it's installed on its own, that
is, not using your distributions regular packages of it.  (Most
distributions install KDE to /usr if the package manager does it.)  Since
I won't install binary-only software, aka "slaveryware" as opposed to
Linux's "Free software" or "freedomware", and I use my distribution's
version of KDE, /opt is empty, here.

/mnt, /media       mountpoints for dynamically mounted filesystems

mnt is older, media is newer and not used everywhere.  Some usages mount
new filesystems on /mnt directly, therefore making it
inconvenient/impossible to properly mount several different ones at once,
thus the /media location.  Others use mountpoints such as /mnt/cd,
/mnt/dvd, /mnt/floppy, /mnt/usb, /mnt/usb2, etc, instead of having the
same mountpoints under /media, and never mount anything directly on /mnt
itself.  These generally won't have a /media.

/home, /root       user's personal configurations and data lives here.

/root is the home dir for the root user, thus giving it access to its
personalized config before the other partitions are mounted.

Since /home contains all that valuable personal data that's hard to
replace if it gets list, it's often kept on its own partition, making
backup and restore that much easier.

Some further notes, mostly on the organization of home dirs:

A shortcut notation for an individual's home dir is ~/ .

As someone already mentioned, just as MSWindows has the hidden file
attribute available to keep files from being displayed by default, Linux
(well, Unix in general) uses a leading dot to indicate a hidden file.

Since there's often a lot of config files and subdirs in a user's home
dir, and these would clutter things up when a user is looking for that
jpeg or whatever they just saved, by tradition, all the config files and
directories in a user's home dir are hidden.  If you turn on display of
hidden files, you'll see them all and probably understand why they are
usually kept hidden -- there can be a LOT of them.

pan is no exception, thus its config and data dir is by default ~/.pan2.

It's quite common for a user to have either a ~/bin or ~/.bin directory, in
which he keeps his own little scripts and executables, and add that to his
$PATH (set or added to from the default in ~/.bashrc or the like), so he
can run them without typing out the full path, only the name.

If you run KDE, you'll notice that it keeps most of its personal
configuration under ~/.kde/share (there may be a version number after
kde, as in .kde3.5, or not). This mimics the location under /usr/share
where the system-wide config is stored.

That should provide at least /some/ sort of orientation and idea of where
to look for stuff on your disk, now. =8^)  However, get Running Linux. 
Really.  It's /full/ of practical information like this!  As I said, I
figure it save me literally hundreds of hours of feeling dumb poking
around not being able to do much but make mistakes, so it was easily worth
the money many times 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