[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: why are there /bin and /usr/bin...

On August 10, 2010 04:18:10 am Stanislav Maslovski wrote:
> On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote:
> > /sbin and /usr/sbin, /lib and /usr/lib directories?
> >
> > AFAICT, the reason is so that a minimal but functional system is
> > guaranteed to exist so long as a local HDD with a root filesystem
> > is available (which doesn't necessarily include /usr); and that is
> > a good thing to have because it gives developers a core set of
> > software tools they can count on to always exist and facilitates
> > troubleshooting or repairs if something breaks (e.g., bug# 592361,
> > where I've worked around the problem by using /bin/nano to
> > reconfigure the box with a static IP address).
> Not just to repair. First of all, / must have enough tools to
> bring the system up to the point where the other file systems can be
> mounted (i.g., over the network).

Ya, I consider that to be the main use for the `core set of tools that 
can be counted on'.

> > If that is a good reason, perhaps even The reason, for having both
> > /bin and /usr/bin, etc., then doesn't it follow that all files
> > required by executables residing in /bin and /sbin should also be
> > available so long as a local HDD with a root filesystem is
> > available (otherwise those executables are either broken or
> > crippled)?
> All files that a tool requires to operate must be there, for sure.
> > I suppose there could be cases where the broken or crippled
> > functionality is not useful or required when a properly populated
> > /usr doesn't exist, but I expect those would be "special" cases,
> > because, generally, crippled or broken programs are a bad thing.
> > ya?
> Can you give examples of such special cases?

Nope, it just seemed short-sighted to ignore the possibility. Simon 
McVittie mentioned an even better/plausible situation where some 
crippling wouldn't really matter...
>  (For instance, if /bin/vi is vim, it's OK if it can't do syntax
>  highlighting until /usr is mounted, as long as it can edit text.)

> > I'm trying to understand the logic behind it not being an automatic
> > bug (i.e., something which is a good candidate to check for at
> > build-time) for stuff in /bin and /sbin to require stuff in /usr;
> > and I've gotten onto this because of bugs like #592361 and #589123,
> > and the observation that over the last couple/few years I seem to
> > be running up against problems related to this issue more and more
> > frequently.
> This is an unfortunate consequence of the fact that less and less
> developers separate /, /usr, /var, etc. partitions on their machines.
> In the past I always did it on my workstations, however, stopped
> doing it around the time of lenny's release.

Hehe... never run into a process that starts filling up the HDD, or 
perhaps had to use an HDD small enough that the possibility even 
existed. <shrug>

> > With bugs in scripts (e.g., #589123) it should be good enough that
> > a text editor is available, but with broken binaries (e.g.,
> > #592361) the potential to be put in a not-so-easy-to-fix situation
> > is pretty high (remember, dpkg is not around when /usr is missing
> > and the fix is going to arrive in a .deb)--so maybe that one should
> > generate a warning of some sort.
> Well, just the other day I was helping a user on #debian to repare
> his Debian installation, using mostly sed to edit the config files.
> Nano was not functional without /usr and it seemed he did not have
> any other editor.

Hmm, /bin/nano worked for me. It spit out a screen full of warnings 
about stuff from /usr it couldn't find, then asked if it should 
continue. I don't know what it was missing but it worked well enough to 
edit /etc/network/interfaces.


- Bruce

Reply to: