Subject: Re: 1.3Beta
To: Greg A. Woods <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 12/03/1997 21:48:44
[ On Wed, December 3, 1997 at 05:52:59 (GMT), Jonathan Stone wrote: ]
> Subject: Re: 1.3Beta
> The bottom line here is that the name 'sysinst' is _not_ going to
> change for the 1.3 release. It's far too late for that.
>Perhaps things would have been different if these tools had been
>developed long before someone thought it critical to start development
>of them during a release phase?
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?
>Given the way things have gone my personal feeling is that all work on
>sysinst should have stopped before it started and all attention
>concentrated on polishing the release without worrying about some GUI
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.).
>Yes hindsight is 20/20, but it's my guess that no
>matter what happens the current effort is going to look really bad in
>comparison to what many perceive as the competition
On x86es? Possibly so. I think sysinst is comparable to, say, the
old Linux SlackWare 3.0 install scripts. ``really bad' is in the eye
of the beholder. (Pencil and paper to compute disklabels?)
But see below...
>effort is put into sysinst alone it won't come anywhere close to being
>really cool -- we can only hope that it'll work well enough to be
>generally useful. I don't mean to point any blame or to criticise those
>working on sysinst -- only to say that I don't think such work should be
>done as part of the release polishing.
I think it depends very much on the comparison. Are you talking about
sysinst in general? Or about sysinst on i386?
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
Or are you one of those lucky enough to have instlaled NetBSD on an
i386 without ever having disklabel trash the MBR?
>While the whole OS has hopefully
>reached "beta" I don't think I'm alone in saying that sysinst is barely
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.
It's obviously not complete; see the TODO list. That doesn't
_necessarily_ make it `alpha' quality though.
>BTW, I think a *lot* could be learned about making system installation
>easier by looking at many of the other commercial and non-commercial
>system installation tools. FreeBSD is so easy to install these days
>it's just not funny, and some of the semi-commercial Linux packages make
>one green with envy. Even the old SunOS install tools have many
>advantages over what I've seen so far of sysinst (my knowledge of it is
>a week old now). Why not pick the best of the freely available ones
>after the 1.3 release is frozen and hack it to be MI? Surely there's
>something appropriate out there that would save a whole lot of start-up
>effort.... Pardon me if I'm covering well worn ground, but I don't
>recall any real discussion about this issue in recent times.
Now, *these* sound like good points. I don't know the answers to them all.
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.
I think these are very relevant issues for NetBSD; don't you? (as I
said the first time, port-i386 is *NOT* the right place to be
second-guesssing design decisions with MI implications.)
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.)
Discussions about the paucity of installation tools on NetBSD is
nothing new (pencil and _paper_? As we approach the Millenium? Get
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...