Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jan 2012 14:36:29 -0800
From:      Devin Teske <devin.teske@fisglobal.com>
To:        "'Frank Shute'" <frank@shute.org.uk>
Cc:        'Chad Perrin' <perrin@apotheon.com>, Robison <daver@vicor.com>, freebsd-questions@freebsd.org, Dave
Subject:   RE: FreeBSD 9
Message-ID:  <04ff01ccd6fa$ca9a4e20$5fceea60$@fisglobal.com>
In-Reply-To: <20120119200106.GB88862@orange.esperance-linux.co.uk>
References:  <BLU160-W54C133B8003EF140C41EF7AE860@phx.gbl> <loom.20120119T094302-811@post.gmane.org> <4EFDA3B50040906E@> <20120119164234.GB21488@hemlock.hydra> <04db01ccd6df$a6ebe3f0$f4c3abd0$@fisglobal.com> <20120119200106.GB88862@orange.esperance-linux.co.uk>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help


> -----Original Message-----
> From: Frank Shute [mailto:frank@shute.org.uk]
> Sent: Thursday, January 19, 2012 12:01 PM
> To: Devin Teske
> Cc: 'Chad Perrin'; freebsd-questions@freebsd.org
> Subject: Re: FreeBSD 9
> 
> On Thu, Jan 19, 2012 at 11:22:14AM -0800, Devin Teske wrote:
> >
> >
> >
> > >
> > > On Thu, Jan 19, 2012 at 11:15:08AM +0100, Eduardo Morras wrote:
> > > >
> > > > I think that a full/complete update of the old installer to add it
> > > > support GEOM, ZFS, scripting and more newer features will consume
> > > > more manpower and resources than create a new one from scratch,
> > > > where the devs aren't chained by old code, backwards
> > > > compatibility, old restrictions and old point of views. This way,
> > > > is easier correct bugs, new features, simplify the installation
> > > > and even automate it to this new installer than try to add them to
> > > > the old one.
> > >
> > > I'm curious: Is this just speculation, or have you determined this
> > > by reading
> > the
> > > source of the old installer?  Old code means *tested* code, and when
> > > it is
> > well-
> > > maintained it often means easily extensible code.  Is that the case
> > > for the
> > old
> > > installer, or is the older installer a crufty mess of "temporary"
> > > fixes that
> > became
> > > permanent, as your statements seem to imply?
> > >
> >
> > I believe the "difficulty in maintenance" stems primarily from the
> > fact that the existing partition editor MAY have to be entirely
> > rewritten to accommodate other root filesystem types (but even that's
> > not entirely true -- if done right).
> >
> > Other than that, it's most likely just FUD and misperception that
> > sysinstall(8) is either (a) hard to maintain or (b) hard to extend.
> > -- Devin
> 
> To quote the manpage for sysinstall:
> 
> BUGS
> 
> <snip>
> 
>      This utility is a prototype which lasted several years past its expira-
>      tion date and is greatly in need of death.
> 
>      There are a (great) number of undocumented variables.  UTSL.
> 

Perspective.

Let's take a look at the commit history for this manual.

Try as you might, you can't go back far-enough to find when that message was
even added. However, you can see where the message was tweaked slightly by a
couple people:

SVN r49961 by mpp@ addressing PR docs/13148 and docs/13144

	Prior to-which the message said "3 years past" (s/3/several/)

SVN r40275 by jkh@ (no PR mentioned)

	Prior to-which the message said "2 years past" (s/2/3/)

So, literally for the past 15+ years, the man-page has said essentially the same
thing "prototype ... in need of death."

I raise the hypothesis that:

a. The "prototype ... in need of death" message in the man-page was added by the
original author, whom...

b. ...had self-esteem issues on that particular day (hence the self-denigrating
remark about one's code).

I further pontificate that once the original author relinquished control of
sysinstall(8) (whomever that may be -- since commit logs don't go back that far)
that one of the 2-dozen-plus committers should have removed that message to
quell evident propagation of FUD against sysinstall(8)).

Afterall, who's to say that sysinstall(8) was still a prototype when it was
being used for several major releases in production and enterprise environments.

But instead, this entry in the man-page was not removed, year-after-year, but
instead maintained (with no apparent rhyme or reason).

The situation is the exact opposite of what we're seeing with bsdinstall.
sysinstall(8) was added to the tree as a "prototype" yet was stable. Now we see
bsdinstall added to the tree as a NON-prototype yet is NOT-stable or free of
show-stoppers!


> I welcome the new installer. sysinstall was a piece of buggy garbage that gave
a
> pretty poor first impression of FreeBSD.
> 

I think we have some very different opinions of what "buggy" is.


> The new installer will get better with time.
> 

The new installer is buggy, and the above maxim is something I'd rather not have
to deal with when downloading RELEASE software.

RELEASE software shouldn't be released under the statement "it will get better
with time". Releasing feature-INcomplete software that is known to be broken
hurts the FreeBSD impression far more than sysinstall ever could/did. I feel
your argument is an attempt to justify the egregious offense of foisting
premature software on the community when in-fact it does NOT replicate even a
fraction of the abilities of sysinstall.

IMHO.
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?04ff01ccd6fa$ca9a4e20$5fceea60$>