Re: HEADS UP: /bin and /sbin are now dynamically linked

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