tlug: Seeking advice on ZIP drives & such w/ Linux

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Matt" == Matt Gushee <matt@example.com> writes:

    Matt> Well, I'm starting to see too many 8's and 9's when I run
    Matt> 'df'. Time to think about more storage space. Unfortunately
    Matt> I'm using a notebook PC, so installing another internal hard
    Matt> disk isn't much of an option. I'm thinking about buying a
    Matt> removable-media drive,

I assume this is the only machine you have available.  If not,
Ethernet + NFS is working quite well for me.

    Matt> * One of the major things I am thinking about doing with my
    Matt> new storage device is to move all my development stuff
    Matt> (i.e., '*.a' libraries &/or source trees) off the hard
    Matt> disk. Since I'm not a developer--I just compile programs
    Matt> occasionally for my own use--it's not a big problem if
    Matt> compilation takes more time due to slow disk access. I'm
    Matt> just wondering if there's any reason why this might be a Bad
    Matt> Idea.

Sounds sensible to me.  Think a little bit about what else might go
there, and what that implies about what a good mount point would be.

One caveat is non-Info, non-man docs.  RedHat (I think) and Debian
(for sure) are quite careful about moving all README*, ToDo*, NEWS*,
Change*, etc into an appropriate place in /usr/doc.  I strongly
suggest doing this with your own add-on packages as well.  Design
flaws are sometimes documented in the man page, but most bugs aren't.

Don't put your current kernel source on the removeable medium; it's
common enough to want to refer to your configuration (eg, which things
are actually modules and which are built in---many modules in my
/lib/modules are stale, referring to long-dead kernels), and when your
collection of sources starts to span several disks, your kernel
headers themselves will have to be on some always available file
system.

Don't put your compilers and stuff on the slow medium; you'd be
surprised how often some stupid little program calls various
interpreters and compilers (the most common one is cpp; many X
programs use it for resource customization).  Evidently you don't plan
to do that, but better safe....

Learn about the VPATH capability of GNU make.  It is often possible to
have your sources in one place and do the build in another.  Many GNU
packages allow the --srcdir option to configure.  (I don't do this---
it's really designed for cross-compiling environments---but if you try
it and want some company, I'd be happy to go at it with you, could
come handy some day ;-)  Another trick is to do something like

	ln -s /slowdrive/src/program/* /internaldrive/playpen/

This is also useful if you're going to play with the sources for some
reason, sort of like a "poor man's CVS".  (If you edit one of the
files with Emacs, it renames and then deletes the symlink, not the
linked file; so the original never gets changed.  This is not
reliable---I don't think vi does it that way, for example, but
occasionally it's been useful to me.)  The symlinks can take up a fair
amount of space for a big program, of course.  But the speed is much
greater than for doing compiles on the slow medium, and the space is
much less than the files themselves would be.

HTH
---------------------------------------------------------------
TLUG Meeting: To be announced
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096