From owner-freebsd-hackers Tue Apr 14 18:14:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06533 for freebsd-hackers-outgoing; Tue, 14 Apr 1998 18:14:52 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06513 for ; Wed, 15 Apr 1998 01:14:45 GMT (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id SAA01687; Tue, 14 Apr 1998 18:11:58 -0700 (PDT) Message-Id: <199804150111.SAA01687@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: rotel@indigo.ie cc: freebsd-hackers@FreeBSD.ORG Subject: Re: the place of vi In-reply-to: Your message of "Wed, 15 Apr 1998 01:43:45 -0000." <199804150043.BAA01063@indigo.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Apr 1998 18:11:57 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is a thread that some people want killed, but as far as I can > see they are the same people who want to keep vi in /usr/bin; given That's because these are the people that have seen this thread (possibly many) times before. They have seen that moving vi is not worth the effort, and really don't want to hear the same arguments reach the same conclusion all over again. > that there are still a significant number of people, myself included, > who strongly disagree with this view and given that the issues > haven't been thrashed out fully I don't think we should kill it > just yet. I suggest that if you're not willing to listen to us, you should start by re-reading the argument as it has been played out numerous times in the FreeBSD mailing list archives. After you've digested the written record, and if you still have objections at that point, feel free to raise those issues again. > Several points have been made against moving vi to /bin, I don't > think any are valid: > > a) just mount /usr and use it -- jb@cimlogic.com.au > > Well, it's already been pointed out that this is not viable if /usr > is broken or corrupted. I think the point is that if you can get > the system to mount the root partition then you should have a > useable editor. How is vi going to help you resurrect a corrupted filesystem? Vi is a text editor, not a filesystem repair tool. > b) just make it yourself -- mcdougall@ameritech.net > > This is always an option with any UNIX given the free availability > of nvi, vim, etc., however it's too easy to forget to do. I believe > it's the kind of thing that the maintainers of FreeBSD should look > out for, if you want to ship a reliable system then you want to > reduce the amount of customisation needed to make it foolproof. Putting vi on the root filesystem is not going to make the system "more reliable". > c) it's too big -- chuckr@glue.umd.edu > > The stripped statically linked binary from -stable is only 466944 > bytes, 230238 bytes more than the dynamically linked version - is > that big? Yes. > d) you would need to move termcap too -- winter@jurai.net > > This is not true, given that you are only going to be in single > user mode at the console when in this kind of situation simply > executing something like: > > TERM=cons25 tset -s > /etc/termcap.cons25 > TERM=pcvt25 tset -s > /etc/termcap.pcvt25 > > during make install of vi would suffice, then to setup your > environment before editing: Another useless file in /etc. Termcap was moved from there for a good reason. > f) learn to use ed -- helbig@Informatik.BA-Stuttgart.DE, etc "Learn to use a smaller editor. Install it yourself." > What have you got to lose by putting vi in /bin? 400K of space on > your root partition? Gimme a break! If it bothers you that vi isn't on your root filesystem, perhaps you should put it there. Save yourself the effort of squeezing things though; try a 400M / filesystem without a separate /usr. This has many more benefits than just getting you vi, it means that /tmp is less likely to overflow, and all your other favorite tools are available too. If you have any sense, nothing outside /tmp on this filesystem will normally be modified anyway. Look at the big solution, rather than ranting about just one trivial issue. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message