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 ] _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
