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

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to