Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Apr 1998 22:58:23 -0500 (CDT)
From:      "Matthew D. Fuller" <fullermd@futuresouth.com>
To:        Chuck Robey <chuckr@glue.umd.edu>
Cc:        chat@FreeBSD.ORG
Subject:   Re: asbestos suited static vi
Message-ID:  <Pine.BSF.3.96.980414224352.21670C-100000@shell.futuresouth.com>
In-Reply-To: <Pine.BSF.3.96.980414222640.26876L-100000@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Apr 1998, Chuck Robey wrote:

> You're completely missing a major point.  Your argument is that there
> are some good reasons for some of us to want it.  No argument.  If you
> want it adopted, you'd have to argue that your reasons are strong enough
> to override the equally good reasons some *don't* want it.
> 
> In other words, you want it, and you want to force everyone to have it,
> even though you can supply it yourself adequately.  Many disagree with
> that part of it.

Having calmed down enough to actually read some of the emails sent both
to the list and to me personally, I'm starting to agree that it might not
be the best idea to have a static vi as a default.  However, I still
believe strongly that it's a desirable option in some cases, and I think
it should be easier than digging through makefiles, moving a bunch of
files around, etc; a package-type deal could well be perfect.  And I've
heard interest from other people in static binaries as well.  Someone
(Greg?) mentioned bash.  And I'm sure there's others.  I'm looking to
establish a framework whereby these things that might well be Bad Things
(tm) in the default can be integrated easily in cases where they would be
wanted and counld be accomodated.

Who knows?  If we create such a package/patchkit and everyone starts
using it, maybe it will prove to be a good thing to set as a default.
Probably not, but this is the best way to test it; by not changing the
default, but making it easier to try the option.

It's interesting to see the range of opinions on this.  Some people say
'Yes, vi should be in /bin', some people say 'Hm, that might not be a bad
idea', some people say 'No, vi should be in /usr/bin', and every one of
the camps has at least a few compelling reasons.  I think that, at this
point, even IF /bin/vi had the best arguments (not saying it does, or
that it doesn't), /usr/bin/vi has the status quo; it IS in there for a
reason, which was completely valid when it was done, and still has
validity.  I think that there's enough weight on the /usr/bin/vi side to
keep it the way it is, but I also think there's enough weight on /bin/vi
to start taking a look at it, and a package/port/patchkit is an excellent
way to make it generally available without breaking the status quo.

OK, I've written enough.  Open season!

> 
> ----------------------------+-----------------------------------------------
> Chuck Robey                 | Interests include any kind of voice or data 
> chuckr@glue.umd.edu         | communications topic, C programming, and Unix.
> 213 Lakeside Drive Apt T-1  |
> Greenbelt, MD 20770         | I run Journey2 and picnic, both FreeBSD
> (301) 220-2114              | version 3.0 current -- and great FUN!
> ----------------------------+-----------------------------------------------
> 


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
|       FreeBSD; the way computers were meant to be       |
* "The only reason I'm burning my candle at both ends, is *
| that I haven't figured out how to light the middle yet."|
*    fullermd@futuresouth.com      :-}  MAtthew Fuller    *
|      http://keystone.westminster.edu/~fullermd          |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980414224352.21670C-100000>