[sf-lug] upgrading versus wiping and installing new

[Rick Moen]

Quoting Jim Stockford (jim at systemateka.com):

> I've interspersed my comments below.

Not a complaint, but you might find that whitespace makes things more
legible.

> Excellent idea, thanks for the suggestion. I think I'll do
> that and see if it has room for more RAM, too: Zareason has
> great customer support

There's often a trivially accessible door where you can get access to
the RAM slots.  Also, the tiniest amount of research based on probing
your system using lspci and dmidecode will typically let you figure out
what OEM system your retailer has sold you, which lets you look up specs
(including max. RAM) by yourself.

> Your report on the sweet spot surprises me. Per Zareason's prices, it
> seemed that 120G was the sweet spot: 250GB sported a higher price per
> GB (in September 2013 or whenever I bought the new box).

Well, check NewEgg.  I could be misremembering.

> I've set up server boxes with multiple 2 GB swap partitions
> distributed across the used storage. Red Hat docs of 2008 or so state
> that swap parts greater than 2 GB are inefficient (or partly unusable,
> I forget) because of kernel code design limits.

There's a funny story I'll have to tell you about that, some time.
For now:  Yes, back _then_, there were real seriosu problems using swap
partitions sized over 2GB per filesystem.

> For my personal computer I usually have a 50 GB or greater part for
> /home/. 

I'm just curious, your rationale for separate /home is...?
(I can think of reasons, but was curious about yours.)

> For server hosts I've got a part for /home/ and a part for /var/. When
> I re-do things, I'll make a part for /srv/ and maybe for /opt/ and-or
> /data/.

Again, I can imagine reasons for some of those being separate, but am
curious about yours.  (I have some thoughts of my own, but wanted to
start by learning what others think.)

Anyhow, ever considered custom boot flags or custom filesystem types
for, say, /var -- or others?

> Ken Shaffer suggests using ext2 for SSD devices such as thumbdrives
> along with noatime (avoids journaling and inode table updates, which
> makes things easier for SSD leveling).

Definitely a logical thought, though the payback would depend very much
on how you use the thumbdrive.

Me, I mostly use thumbdrives to moved tar.gz, zip, or similar files
between computers, which means there's very little wear (which results
from read/write cycles on affected 512-byte blocks) and choice of
filesystem makes very little difference over the long term, really.  I'd
argue that, in that case, whatever filesystem type's most convenient is
the right one, on balance.

> JS: Holy Moly! I thought memory leaks were a thing of the past!

Use ps to watch process stats for a while.

Mozilla XULRunner having memory leaks is, for me, reasssuring, because
it's a sign that some things never change.  (Netscape Navigator always 
had memory leaks, all the way through its history.)

> I am keeping all emails for a few LUGs, including SF-LUG, BALUG,
> Conspire, and SVLUG (in mbox format up until late February 2014). 

Just a reminder:  Conspire is a mailing list, for a LUG whose name is
CABAL.  The group's name is not Conspire.