FreeBSD 9

[Devin Teske]

> -----Original Message-----
> From: 'Frank Shute' [mailto:frank at shute.org.uk]
> Sent: Thursday, January 19, 2012 4:52 PM
> To: Devin Teske
> Cc: 'Chad Perrin'; freebsd-questions at freebsd.org; Dave Robison
> Subject: Re: FreeBSD 9
> 
> On Thu, Jan 19, 2012 at 02:36:29PM -0800, Devin Teske wrote:
> >
> >
> >
> > > >
> > > > 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.
> 
> Let's not. Let us discuss the merit of what the manpage says.
> 
> "There are a (great) number of undocumented variables."
> 
> From my reading of postings to this list and stable@,

yet not -sysinstall@ (?!)

> it was felt that sysinstall
> couldn't be extended without a total re-write, that seems to suggest that the
> manpage is right and is not FUD.
> 

I disagree. Just because you document something doesn't make it true.

I've already discussed the fact that the first line you quoted ("in need of
death") is 15+ years old and we have no way of tracking its origin and thus
can't extrapolate why on-Earth it was put into a "release-quality product" in
the first place.

The second line you quote (which was added 2 years 10 months ago via SVN r189754
by grog@) has everything to do with highlighting the fact that sysinstall(8) is
highly scriptable through a large number of under-documented dispatch keywords
and nothing to do with the "total re-write" issue you're discussing.

Plus, the keywords are a lot more documented than you think. If a dispatch word
is not documented, there's probably good cause (a great number of the dispatch
keywords are meant for internal use only and their documentation would merely
invite strangeness only reserved for people that know what they're doing -- i.e.
they can read the code to learn what their function is).

However, I will concede to the fact that the number of dispatch keywords that
are documented versus ones that CAN be used is only about 33%.

Here's how I generated that number...

awk '/VAR_/{sub(/[^"]*"/,"");sub(/"$/,"");print}'
/usr/src/usr.sbin/sysinstall/sysinstall.h | sh -c 'while read var;do zgrep -q
"\<$var\>" /usr/share/man/man8/sysinstall.8.gz &&
varcount=$((${varcount:-0}+1));done;echo $varcount'

This returns the number of variables -- as-defined-as a dispatch keyword in
sysinstall.h -- are present in the manual.

In 9.0-RELEASE, it returns "33" for me.

In contrast with the number of dispatch keywords, obtainable by:

awk '/VAR_/{print}' | wc -l

which returns 105 for me ... minus the "markedly internal keywords" which begin
with "_"...

awk '/VAR_/{print}' | grep -vc '"_'

We see 101 supposedly-usable dispatch keywords which brings us to about 33%
documentation.

However, I will re-iterate...

The first quote you pulled from the man-page was made 15+ years ago, the second
quote you pulled was from 2+ years ago and the two are not related. The first
declares some inferred quality about the code itself and the second simply
states that the variable keywords are under-documented. One not-necessarily
imply the other or vice-versa.
-- 
Devin



> >
> > 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.
> 
> It didn't do what you asked it to do on occasion. It violated pola wholesale.
> 
> That didn't bother me much. I'd become familiarised with it and could work
round
> all that to get a minimal system installed but it was a pretty poor experience
for
> newbies.
> 
> >
> >
> > > 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.
> 
> I don't doubt that the new installer may be buggy in parts but so was
sysinstall
> and nobody was tempted to fix it. At least with bsdinstall people are actively
> developing it.
> 
> >
> > 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
> 
> It's a chicken/egg situation. Eventually you have to release software that is
> possibly buggy/feature incomplete or nobody tests it and files pr's.
> 
> Arguments can be had about whether it was released too soon but I'm not
> tempted to get into them.
> 
> It's odd that sysinstall should get support now, it got bugger all support
when it
> was alive.
> 
> 
> Regards,
> 
> --
> 
>  Frank
> 
>  Contact info: http://www.shute.org.uk/misc/contact.html
> 


_____________
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.