Subject: Re: Graphical Sysinst in 2.0
To: Chapman Flack <>
From: Bill Studenmund <>
List: current-users
Date: 09/03/2004 18:04:50
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 03, 2004 at 04:39:16PM -0500, Chapman Flack wrote:
> Not long ago, Bill Studenmund wrote:
> > > It would have been worse with an X gui install because unless sysinst=
> > > sure to create an xterm just in case, there would be no place for
> > > unexpected messages to show up.
> >=20
> > 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 stu=
> on the website -
>   NetBSD focuses on clean design and well architected solutions. Because =
>   this NetBSD may support certain 'exciting' features later than other
>   systems, but as time progresses the NetBSD codebase is getting even str=
>   and easier to manage, while other systems that value features over code
>   quality are finding increasing problems with code management and confli=
> - and thought "I like the sound of that" and bought a CD, and inside my f=
> five minutes with the first NetBSD program I ever ran, sysinst, I'm looki=
> at a program that forked an important command, didn't check its exit stat=
> and reported a failure as success.  :/  Of course I wouldn't have seen th=
> if it hadn't been for the other problem, that sysinst picked the wrong si=
> 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.

Yeah, sysinst has been an ugly stepchild. It gets looked at usually just=20
after a release....

> 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 correctn=
> aspect is worthy of some attention.  Certainly somebody should go through=
> 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.

I gather that QUITE A LOT has been done to sysinst since then.

> > 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 =

I think this point is why the modular idea was broached. The code (module)=
that installs sets would be the same in each case, and the only difference=
would be how the user causes the module to be run (what you choose to=20
start it) and how the user sees the result.

> box of DECwriter paper and script echo on was that even if the programmer=
> 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.

Well, the same is true of sysinst on text. sysinst will quite happily not
show you anything of the install proceedings, if you tell it to. :-)

I agree that a graphical installer would have to be written well. That's=20
why I personally like the module idea. With it, we have one installer that=
has multiple UIs. Thus only one piece of code has to check error codes.=20
:-) I don't really care if it's TCL or sh or whatever; I'll leave that to=
whomever actually makes it. :-)

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)