From owner-freebsd-current@FreeBSD.ORG Sun Nov 23 18:00:42 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49B9816A4D4; Sun, 23 Nov 2003 18:00:42 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C99443FEC; Sun, 23 Nov 2003 18:00:38 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id hAO20bkX045016; Sun, 23 Nov 2003 18:00:37 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3FC16644.7070005@acm.org> Date: Sun, 23 Nov 2003 18:00:36 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <3FBE8D92.6080205@acm.org> <20031123012222.GB11523@dragon.nuxi.com> <20031123042635.GB677@saboteur.dek.spc.org> In-Reply-To: <20031123042635.GB677@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: /bin and /sbin are now dynamically linked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 02:00:42 -0000 At 5:22 PM -0800 2003/11/22, David O'Brien wrote: >Please, NO. There wasn't an FTP client available for this type of >recovery pre-/rescue, there shouldn't be one now. "This type of recovery" (repairing a system with a trashed /bin) wasn't possible at all pre-/rescue. Had it been possible, /rescue wouldn't be needed. Bruce M Simpson wrote: > I think David has valid concerns here about feeping creaturism. fetch > has a whole load of library dependencies which go with it, making it > unsuitable for inclusion in /rescue in the base system. Fetch requires libfetch (45k). I've not tested, but I expect it adds less than 64k to /rescue. Scenarios that require /rescue are ones in which /bin and /sbin are unusable, which is almost always going to imply a trashed file in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to involve locating a good copy of a trashed file to replace a damaged local copy. I can only think of a few places where that "good copy" can come from: * CDROM: requires a CD-ROM drive, and a suitable CD. * floppy: requires a floppy drive * NFS: requires a local network and an NFS server * An HTTP or FTP server: requires a network connection and 'fetch.' I don't think we can safely assume that everyone has access to one of the first three options here. Given the choice between 'vi' and 'fetch,' I'd definitely choose the latter. ('vi' is useful for repairing config files; errors in config files are not generally going to break /bin.) > I don't see fetch as a requirement for diskless clients. This is a red herring: diskless clients don't need /rescue since any "recovery" necessary can be done on the server. Whether or not diskless clients require fetch has therefore no bearing at all on the question of whether fetch should be in /rescue. Tim Kientzle