On Tue, 27 Aug 2002, Robert Elz wrote:

>     Date:        Tue, 27 Aug 2002 15:25:58 +0200 (CEST)
>     From:        Johnny Billquist <bqt@update.uu.se>
>     Message-ID:  <Pine.LNX.4.21.0208271524120.4775-100000@Tempo.Update.UU.SE>
> 
>   | I don't want it to access any other file, be dependant on any other files,
>   | or break when some other file is missing, that's all.
> 
> But why is it acceptable for /usr/bin/su or /usr/bin/gcc or
> /usr/bin/make or ... to break, and not the things in /bin ?

Because I don't need make or su to repair a broken system.
The things in /bin (and /sbin) should be the things needed as a bare
minimum to fix other things. The simple tools to setup, fix, and boot the
rest of the system up.

> If an important system file (of which there are hundreds, from /etc/passwd
> to /bin/sh and /dev/lots and ...) goes missing, then it needs to be
> recovered.   In some cases that is going to mean a single user boot
> from the console (in others, boot from a backup device - floopy, CD,
> or another drive).   The ability to do all of that remains.
> 
> So, once again, why?

I already said that I consider /recover (or whatever it was called) a bad
solution created to fix the fact that you are breaking /bin and /sbin.

Until now /bin and /sbin did hold the things needed to fix a very severly
broken system. About the only things totally unrecoverable is a broken
init, kernel or perhaps /dev.
If those are okay, and I have /bin and /sbin (or atleast most of them), I
can always fix myself up.

Have you never had a system go bad on you?

What you should be arguing (whould I really tell you this?) is why I
consider /rescue to be a bad solution, instead you're more or less asking
why I want to have tools to rescue a broken system.

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol