On Mon, 05.05.14 11:32, Simo Sorce (simo@xxxxxxxxxx) wrote: > On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote: > > On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
