[ On Wed, December 3, 1997 at 21:48:44 (-0800), Jonathan Stone wrote: ]
> Subject: Re: 1.3Beta 
>
> Sorry?  The development work did not start during the release phase.
> AFAIK it must've started early in summer at the very least, possibly
> earlier.  I'd prefer to it to the primary author to answer, but why
> did you think sysinst started *during* the release?

It's just that 99% of the visible development (at least from my POV) has
seemed to happen on the release branch (it's certainly gone from a near
prototype to what it is now during the release phase).  This doesn't
seem like sound software engineering to me.  Of course there's a lot of
other things I could say about NetBSD and release management in general,
but I'm not sure I want to get into that just now.

> Sorry, I don't understand.  I think gettnig installation documents and
> tools right are a big part of putting a release together. Don't you?
> Also, the BETA period officially is *for* polishing installation docs
> and tools (though clearly sysinst is taking that down to the wire.).

Nope, I don't agree.  Installation tools should either be an integral
part of the system (i.e. just as well thought out and well maintained
and integrated) or be left out all together (i.e. left for some
integrator to develop separately from the main OS release).

Of course documenation should always be kept up to date!  ;-)

Yes of course there's always last-minute polishing on the docs, but
there shouldn't be anything major to update, should there?  ;-)

> I think it depends very much on the comparison. Are you talking about
> sysinst in general? Or about sysinst on i386?

I've only seen it used on the i386, but I'd probably also use it at
least once or twice on sun3s, alphas, pmaxen, and sparcs myself.  I
confess I'm not aware of just where the platform differences might be,
though I have my own ideas of where I would expect them to be....

> My perspective is that the i386-specific code for sysinst is fairly
> closely based on the existing scripts.  Any shortcomings (and they
> *are* there, no question, i've been pointing them out for weeks)
> simply makes the existing bugs in the NetBSD install procedure more
> visible.

I think one of the biggest problems is that when a tool like this starts
to get a "GUI" (or at least menu based) interface then most people will
assume that it gains all kinds of smarts and does all kinds of data
validation too.  Sysinst didn't and doesn't so it's going to get slagged.

> Or are you one of those lucky enough to have instlaled NetBSD on an
> i386 without ever having disklabel trash the MBR?

Well I have, but that's besides the point.  The fact I've managed this
so far is only the result of having installed dozens, if not hundreds,
of unix and unix-like OS's on at least half as many different kinds of
hardware over the years!  ;-)

> On i386, perhaps that's a fair comment.  on pmaxes, sysinst is pretty
> reliable and far, far better than the alternatives, and slicker
> than the competition.

First off I should repeat that I've only seen sysinst run on the i386
and I may be making a whole heap of assumptions about just how MI it
is, though I hope not.

In that light I don't think that in this case the platform type is
important to what perception people will have of it.

It won't matter what the native Digital install script does -- NetBSD's
install will get painted with the same brush and compared against the
best of the Linux and FreeBSD attempts regardless of the platform.

> There's no ncurses in our tree, which tends to come up pretty early in
> any such discussions. And it was pretty clear it wouldn't be in the
> tree for 1.3.  And the linux tools I've seen are not _at all_ amenable
> to running on monochrome displays or ASCII terminals.

Some of us have been waiting for ncurses for *years* now!  ;-)

True enough about some of the "PC" tools not working on TTYs.  But it's
not necessarily the GUI details that count, but rather the "script" they
follow and the smarts behind them.
 
> Speaking only for myself, sysinst *was* in our tree, offered a much
> more promising UI than the existing scripts, and so I've tried to
> improve it.  (Especially on pmaxes.)

I sure don't want to stop you, and I hope the other port maintainers can
find time, and/or other helping hands, to do the same when appropriate.

> I guess the bottom line is those willing to do, or pay for, the work
> made the decisions.  That wasn't me (at least not initially), and it
> certainly wasn't you. There's an obvious way to fix that though:
> volunteer to help out...

Me?  ;-)

I'm more likely to lay out disk labels by hand!  ;-)

Seriously though the reason I wanted to poke into this discussion was to
point out that a whole lot of effort was going into something at the
last minute which would likely only result in a less than mediocre
result.  I think that effort could be better spent working on more
serious O/S issues that would better meet the stated goals of NetBSD.
(I do agree there's this little issue of maintaining enough popularity
to make it a serious platform for people to consider working with....)

In terms of examples for those who want to work on better user
interfaces to OS tools, well I'd much rather see a fancy user interface
to a SCSI mode page editing tool and block remapper, and/or a more
powerful and less cryptic fsdb, or even a run-time kernel analysis tool
that understands kernel data structures like sysV's 'crash'.

Perhaps NetBSD does need an entrepreneurial integrator to take it on
just like some of the Linux distributions and even FreeBSD have been
given more commercial integrator support.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>