From owner-freebsd-chat Tue Apr 14 20:58:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08720 for freebsd-chat-outgoing; Tue, 14 Apr 1998 20:58:40 -0700 (PDT) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA08706 for ; Wed, 15 Apr 1998 03:58:28 GMT (envelope-from fullermd@futuresouth.com) Received: from localhost (fullermd@localhost) by shell.futuresouth.com (8.8.8/8.8.8) with SMTP id WAA23263; Tue, 14 Apr 1998 22:58:23 -0500 (CDT) Date: Tue, 14 Apr 1998 22:58:23 -0500 (CDT) From: "Matthew D. Fuller" To: Chuck Robey cc: chat@FreeBSD.ORG Subject: Re: asbestos suited static vi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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