[sf-lug] the build-a-box project -- LIST

[Rick Moen]

Quoting jim stockford (jim at well.com):

> i'm gonna have to read that again. what a gold mine.  thanks! 

Yr. certainly welcome.

> Maybe I'll take the 500MB RAM sticks back for a couple of 1GB sticks.
> Julie claims that dual sticks is faster than a single stick, given the
> same total RAM.

She's right.  It's some interleaved-addressing thing or other.  Bear in
mind that 1GB of total RAM is nothing to sneeze at, and a lot more than
any box of _mine_ has.  The main reason you might consider that swap is
that, then, your motherboard can theoretically max out later at 4 GB
(four 1GB sticks), instead of 3 GB (two 512MB sticks, two 1GB sticks):
It's planning ahead for growth that may never occur.  Your judgement
call.

I didn't have anything to say about your 3GHz P4 Processor 531 because
it's a perfectly good EM64T chip, and fast but _relatively_ conservative
for this box (which also supports higher CPU clock speeds, with more cash
outlay) -- but it reminded me of two remaining issues I should address:


1.  64-bittedness vs. 32-bit code.   You're probably going to want to 
run a 64-bit distro because that gives slightly smarter / more-open
kernel and application access to larger RAM chunks, but ironically an
argument can be made that you'd be happier sticking to a 32-bit distro
for now.  (Either will run fine on any AMD or Intel chip whose
/proc/cpuinfo on Linux lists "lm" = long mode among the CPU flags.)

Why 32-bit, still?  Because we're in the middle of an awkward transition
to 64-bit on x86, and it's a little messy (but not bad).   The main
problem area is proprietary Linux code not yet available in a 64-bit
flavour, e.g., -- I dunno -- probably still Sun Java, Macromedia Flash,
things like that that have in many cases motivated people to run a bunch
of 32-bit apps (such as Web browsers) within otherwise 64-bit distros.

A 64-bit distro[1] runs 64-bit code natively, and also 32-bit apps that
have been compiled to reference their libraries in the right place _or_ 
are running in special chroot jails to compensate for library-location
problems.  The last significant _open source_ app to have a
64-bittedness a problem was OpenOffice.org, and that's now fixed (about
a year ago).  That leaves a small miscellaneous pile of proprietary
code, per my rather vague understanding.  (My personal machines are all
2001-and-prior antiques, with not a single EM64T or Opteron among them, 
so I know this topic mostly second-hand.)


2.  Heat/noise/power-draw.  Being relatively conservative, that 3GHz P4
won't be a _huge_ source of heat, but it'll be quite significant.   The
other big heat generator will probably be your Radeon 9500.  Heat is
proportional to power draw; it's nice to be environment-friendly, try to
help save the glaciers, and not have to sign over your first-born to
PG&E.  Heat also requires fans, because otherwise heat accumulation
kills your box's parts.  Fans are the main source of PC noise --
mitigated a bit by good case design; worsened by cheap case design
(vibration control, air routing).

You mentioned that you would be getting whatever case Julie included.
This is typical, and nothing to fret over -- but, if you're ever tired
of the box thrumming under your desk and screaming like a banshee all
the time, rebuilding the box with a _good_ case and _good_ fans can make
a huge difference in noise level, while at the same time doing a more
reliable job of keeping all the parts cool, making long parts life more
likely.

Good fans are quieter chiefly because they have good bearings, by the
way.  Cases and fans both have dbA noise ratings:  Those figures tend to
fib, but they're better than nothing.


[1] Nomenclature in this area is rendered peculiar by the existence of
Itaniums, an initial and incompatible 64-bit exotic design that nobody
cases about, any more (except me, because I helped build this puppy:
http://www.llnl.gov/linux/thunder/) that has already been assigned
the name "IA64" (in contrast to IA32) and thus prevents that name's
usage for the overwhelmingly more successful EM64T and Opteron 64-bit
CPU designs.  The latter thus get stuck with awkward names for their shared
semi-standard like "x86-64" and "AMD64".  Note that there is a very
minor difference between the AMD and Intel chips' instruction sets, but,
for most purposes, they're the same.