Not long ago, Bill Studenmund wrote:
> > of 'disk full' messages zip by, messing up the sysinst form,
> > just before sysinst refreshed its form and reported the extraction was
> > *successful* (!).
> >
> > It would have been worse with an X gui install because unless sysinst made
> > sure to create an xterm just in case, there would be no place for
> > unexpected messages to show up.
> 
> Seems to me that the main problem is that the errors/messages were
> unexpected. :-) sysinst should have noticed/been told that the install
> didn't work, and acted accordingly. A GUI can do the same.

I agree with your point in principle, but it cuts more than one way.

Yes, sysinst should have noticed the pax extract failed.  It was my first
taste of disappointment with NetBSD, y'know, I'd just read this nifty stuff
on the website -

  NetBSD focuses on clean design and well architected solutions. Because of
  this NetBSD may support certain 'exciting' features later than other
  systems, but as time progresses the NetBSD codebase is getting even stronger
  and easier to manage, while other systems that value features over code
  quality are finding increasing problems with code management and conflicts.

- and thought "I like the sound of that" and bought a CD, and inside my first
five minutes with the first NetBSD program I ever ran, sysinst, I'm looking
at a program that forked an important command, didn't check its exit status,
and reported a failure as success.  :/  Of course I wouldn't have seen that
if it hadn't been for the other problem, that sysinst picked the wrong size
for /usr - *when I made the standard, non-custom selections* (!).  Hmm, a
program that we all agree only does about 4 significant things, and does
about 2 of them wrong.

So, two observations ....

developing a gui-er interface takes development effort, but so does moving
further along the correctness front, and maybe sysinst has been greatly
cleaned up since 1.6.2, I don't know, but from my experience the correctness
aspect is worthy of some attention.  Certainly somebody should go through for
the places where exit status is ignored (or does pax not return proper
status?) - being able to detect failure is prior to most everything else.

> unexpected. :-) sysinst should have noticed/been told that the install
> didn't work, and acted accordingly. A GUI can do the same.

... is an idealistic point I agree with but we've just seen that real code
by real people doesn't always consistently do that.  The saving grace of the
box of DECwriter paper and script echo on was that even if the programmer had
completely forgotten to even think about checking something, you still had
what you needed to reconstruct what happened.  Sure, a GUI installer can be very
conscientiously written, check everything, log comprehensively, and report
useful status in all cases ... but that requires a blistering attention to
detail and the failure mode is less desirable when some detail has been
overlooked - you may just not see anything except that your system doesn't
work.

-Chap