On 5 Mar 2000, Perry E. Metzger wrote:

# 
# Simon Burge <simonb@netbsd.org> writes:
# > How does the following look for a quick hack?  It adds a ``M'' flag
# > that says to keep temporary info in memory instead of on disk.  Note
# 
# How's this for a quick hack? The decision to replace gtar with pax on
# the install media was ill advised and not discussed with anyone. I say
# we move back.

...why?  pax is supposed to be the be-all end-all archiver with no GPL
attached to it.  I'd say it's a forward step, albeit we're having
some problems at the moment.

These are problems that could have been avoided if someone had tested
the install.  Considering that it fails on a 96MB i386 box, I'm not
at all convinced that someone did.  How is the size of the install
filesystem determined?  What governs its maximum size?  It's a ramdisk,
can't some directive somewhere just say "the data only takes up this
much space, but I want to allocate *this* much"?

We're supposed to be the folks who are "slow to release but we do it
correctly".  Well, we just shot that one out the window in the case
of sysinst on this last set of snapshots (post 1.4P).

Here's our choices:

1)	move back to gtar
2)	hack pax to keep stuff in core
3)	fix the sysinst script to designate a temporary directory
	and point the working /tmp there
4)	fix the install kernel to be able to make use of a mfs /tmp *

(1) seems like a step backward to me.  Is it just me who feels this way?
	I mean, yeah, it _works_, but I feel we should go the pax route
	sooner or later anyway.  We're here.  Let's bite the wax tadpole
	and make it work.  That said, it should be *tested* (but,
	then, the caveat for -current does come into play here
	("[snapshots] are not guaranteed to work or even compile on a
	 given day."  (I suppose "or install" should be implied...)).

(2) seems reasonable, albeit hackish.  In actuality, should there not
	be a fallback mechanism to handle this case automagically?

(3) Fixing the sysinst script to be a bit more robust, at least, would
	be a good idea.  I ended up suspending my install process just
	after the filesystems were made and mounted, mkdir /mnt/tmp,
	mv /tmp /otmp, ln -s mnt/tmp /tmp, fg.  Had no problems after
	that one (except that trying to add a filesystem which depended
	on another one caused the install to abort as well).

(4) This is tantamount to #2 except that no hackery is necessary to
	the pax code.

[*] While we're at it, could we *please* add the NIC drivers?!?  I was
	*seriously* hosed to the point that my only recourse was to burn
	myself a CD because the install kernel couldn't attach to my
	ethernet card ("not configured") (and I don't *have* forty or so
	floopies by which to do a floppy install).  I've seen remarks that
	we're approaching the space threshold.  Are we close enough that
	adding support for a couple of the more common ethernet cards
	(ex*!)  is out of the question?

# Perry

				--*greywolf;
--
If anyone requests a reason as to why Windows NT is inferior to UNIX,
refer them to the process scheduler, for starters.  Of course, users
don't care, and programmers try not to, even though they both should.
If that fails, reiterate that remote administration and control of a
node is a *good* thing, especially if network security is concerned.