On Thu, Apr 30, 2015 at 10:32:54PM +0200, Joerg Reisenweber wrote:
> On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
> > - Made sense at the time, doesn't make sense today: the separation between
> > administrator commands (/sbin, /usr/sbin) and user commands (/bin,
> > /usr/bin). Back then, filesystems were slow and scaled badly, caches were
> > small, and it was costly (time-wise for lookups) to have too many binaries
> > in a single location. Segregating admin-only binaries in a separate
> > location avoided clogging /bin and /usr/bin, and was a simple solution to
> > gain a factor of 2 or so, which apparently was enough. There certainly were
> > other reasons for that choice, but this is the only one that stands
> > examination
>
> quote from most recent OpenSuse (yes, with dang systemd :-S ):
>
> jr@saturn:~> ntpdate
> Absolute path to 'ntpdate' is '/usr/sbin/ntpdate', so running it may require
> superuser privileges (eg. root).
>

If I can add my 2 cents to the discussion, I would point out that in
the whole history of unix and unix-like systems there has never been a
common "standard" in terms of filesystem hierarchy. Apart from some
basics "common sense" usages (e.g. having all the essentials for boot
in /bin and the configuration filed in /etc), the hierarchy of any
unix and unix-like fs has always varied a lot across platforms and
time.

And also FHS is no more that a union of a bunch of common practices in
different unix-like systems, and in particular in different GNU/Linux
distributions. It is sufficient to run "man hier" in three or four
different distros (and even in different versions of the same distro)
to reckon that FHS is not carved in stone and, as a matter of fact,
does not represent a standard at all (look for instance at the
definition given by FHS for /sys and have a good laugh...)

I personaly believe that the motivations behind some of the
"classical" choices in terms of fs hierarchy made a lot of sense and
still make sense today (e.g., having the essential boot tools in
/bin), if we take into account that unix-like systems cover a wide
veriety of applications, from embedded systems to control washing
machines to internet routers.

What I don't understand is making "changes" to an existing hierarchy
by having in mind just one or a few possible use cases (e.g., "Linux
desktops" or "Linux mobile users", whatever these locutions might mean
to you). This is truly and essentially anti-unix, since it goes
towards forcing unnecessarily restricting policies. And this is
definitely alien to the unix philosophy....

My2cents

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]