Note that Trey said he wanted to run -current, not a release.

I'd suggest installing a snapshot.  -current is already diverging from
what 2.0 was cut from, though I'm not sure how big the difference
is at this point.  (I'm still basically running 1.6, except a couple
of machines that are running late 1.6-current userland with post-2.0
-current kernels.  I should organize myself and upgrade some of
the systems at least to 2.0...(^&)

-current snapshots are generated fairly frequently.  Go to
http://releng.netbsd.org for more info, and FTPable sets.
(I don't think that releng produces ISO images, but you
can make one for yourself if you like---or install via FTP
directly.)


The information for setting up a CVS checkout of -current sources
is covered in a FAQ.  These days, I use links, which makes it hard
to paste URLs to email, but it's not hard to find off of the
NetBSD home page.


Re. installing the NetBSD games set (which is part of the NetBSD base
system): There's little harm in installing it.  Trey will probably
wind up with the games set installed anyway, if he is going to
build and install -current.  It's more trouble to separate the
games set out than to just install it---especially if he starts
with an ISO image download of 1.6.2 or 2.0.  It's a little less
than 3MB in the most recent -current snapshot for NetBSD/i386, out
of what, around 100 to 150 MB?  (^&


I'd add ...pkgsrc/security/audit-packages as a program that Trey
should install.  I'm not sure if it fits well into the FreeBSD
paradigm he wants to emulate, but it's worth having.  Also,
pkg_comp sounds like a useful tool, though I haven't sat down
to play with it.


Installing -current, general policy: I tend to *not* use the
"-u" option to build.sh.  My CPU is fast enough that the extra
concern about occasional cruft just makes me feel happier using
build.sh without -u.  Trey has a P4, he says, so he probably
won't care that much about the -u.  (It makes more sense if
you have a more or less complete build, but then modified one
file and want a new version.  I.e., it makes sense for
developers.  If you have a fast CPU and just build from
sources to track system changes, from time to time, I'd not
push the -u option.  I *have* had, e.g., kernel builds wind
up with different sizes, or even fail to build, back in the
pre-build.sh days when I occasionally modified and rebuilt
kernels---even on non-current source trees.)

Some other considerations: Some people put the source tree on its
own filesystem and mount it read-only.  They direct object files
and binaries to other places.  (This makes it a lot easier to
clean up the source tree, since only CVS-checked-out files show
up in the tree.)

Also, the main reason that I'm running -current is for my AMD64
box.  I only have one of those, so I prefer to burn the release to
CD-R media.  If it works well, I can then come back to it as a
snapshot if the *next* update doesn't pan out so well.

Other people have suggested swapping physical drives.  (At least
one person was simply keeping two drives installed and selecting
at boot time.  Do note that if you disable or remove drive 0, then
drive 1 gets renumbered to drive 0, which will affect /etc/fstab
entries.)  One person in an off-list comment told me that he
invested in an IDE (I think) tray that let him front-load PC
drives.  Then swapping a spare drive in/out was quick and
simple.



Just some random rambles for Trey's contemplation.

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/