Incorrect order of /usr/bin and /usr/sbin in path

[Lennart Poettering]

On Mon, 05.05.14 11:32, Simo Sorce (simo at redhat.com) wrote:

> On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
> > On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle at redhat.com) wrote:
> > 
> > > On 05/05/2014 10:28 AM, Adam Jackson wrote:
> > > >On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:
> > > >
> > > >>however, the semantics of /usr/sbin is to contain superuser
> > > >>binaries which should not be overriden because a binary
> > > >>with the same name exists in /usr/bin
> > > >
> > > >My memory is that the "s" was more for "static" not "superuser".
> > > >There's some conceptual overlap, static binaries being there to recover
> > > >even if your shared libraries are hosed which is normally a "superuser"
> > > >kind of operation, but.
> > > 
> > > My recollection is that the "s" in /sbin and /usr/sbin was more
> > > "system" level management. Things an admin would need but would not
> > > usually be needed by an ordinary user.
> > > 
> > > Binaries in /bin and /sbin would have been statically linked to aid
> > > in recovering a system in single-user mode when /usr might not be
> > > mounted, in the days when disks were so small that /usr might often
> > > be a separate disk.
> > 
> > /usr/sbin is an invention of Linux.
> > 
> > The traditional SysV meaning is /sbin for static binaries, and /bin for
> > and /usr/bin for normal dynamic binaries. Linux then redefine "sbin" as
> > meaning "system binaries", but that's a concept that really doesn't make
> > much sense, as you can see for example by Fedora always placing both
> > /usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
> > in both places...
> > 
> > We really should get rid of the destinction, and make all of /bin,
> > /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> > about $PATH orders and namespace collisions...
> 
> Is there a description somewhere of why /usr/bin instead of ditching it
> and keeping just /bin ? Ie why the '/usr' prefix ?

Since the /usr merge we have the nice property that the entire vendor
supplied OS is in /usr, so we can instantiate 100x for 100 containers,
with leaving a private /etc and /var for each.

Lennart

-- 
Lennart Poettering, Red Hat