Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the bin, sbin, usr/bin , usr/sbin split

lists.busybox.net

Post reply on HN
Print view View original

11–20 of 158 posts

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#11

Post by jrockway »

saulrh wrote: post #2

There's an interesting piece of advice at the bottom of this post - the author symlinks /bin, /sbin, and /lib to /usr/whatever. Anybody else have an opinion on that practice? It's kind of unnecessary, but it also doesn't break anything.

There are a variety of tools that live in /bin but are symlinked in /usr/bin, at least on my 10.04 LTS box:

  $ for f in /bin/*; do [ -e "/usr$f" ] && echo /usr$f; done;
  /usr/bin/dumpkeys
  /usr/bin/ksh
  /usr/bin/less
  /usr/bin/lessecho
  /usr/bin/lessfile
  /usr/bin/lesskey
  /usr/bin/lesspipe
  /usr/bin/loadkeys
  /usr/bin/mail
  /usr/bin/nano
  /usr/bin/tcsh
  /usr/bin/touch
  /usr/bin/which
  /usr/bin/zsh
This has the potential to blow something up during the installation procedure if it is not carefully crafted to realize that these files are the same and to ignore link's failure.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#12

Post by tmhedberg »

The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be mounted, say, from a network share. This is useful because then network admins can install software to the common `/usr` share and make it immediately available to all machines which mount that share.

The `/sbin` and `/usr/sbin` directories are for commands needed only by administrators, which will not normally be used by regular users.

Most systems don't really require this separation, but it does make sense. Perhaps the historical reason for doing it is no longer a factor, but that doesn't mean it's perpetuated merely because of tradition.

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#13

Post by wmf »

rcthompson wrote: post #8
bebop wrote: post #7

Earlier quoted context omitted.

My understanding is that bin is used for programs that do not require super user privileges, where as sbin programs do.

And the reason for splitting them is so that normal users don't have the super-user programs in their $PATH, since they would be useless there. Of course, this is arguably obsolete now since the advent of sudo, policykit, and so on.

For some reason traceroute is in /sbin, but it works for normal users. Probably another historical accident (did it used to require root?).

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#14

Post by rachelbythebay »

Let's not forget the whole partition split situation due to the 1024 cylinder limitation. Once upon a time, you couldn't get to certain parts of the disk from your bootloader (using BIOS calls), so you had to make something like a tiny /boot which would hide This situation has only improved a little. There are still lingering bits of it here and there, depending on how deeply you poke and which distribution you have installed.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#15

Post by triffidhunter »

The Fedora changes are bikeshedding. They start with wanting to change something, and then find a justification. Why not just put all the executables files in /Program Files/?

All this to save a few bytes in $PATH, to avoid problems with systemd, and to avoid fixing udev.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#17

Post by hollerith »

tmhedberg wrote: post #12

The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be m…

I know about FHS and the rationale FHS uses for the continued existence of /usr, I just do not agree with it (nor with the existence of /usr/share).

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#18

Post by nailer »

rachelbythebay wrote: post #14

Let's not forget the whole partition split situation due to the 1024 cylinder limitation. Once upon a time, you couldn't get to certain parts of the disk from your bootloader (using BIOS calls), so you had to make something like a tiny /boot which would hide This situation has only improved a little. There are still lingering bits of it here and there, depending on how deeply you poke and which distribution you have…

It annoys the hell out of me that people are still imposing the 486-era 1024Cyl and 8GB limitations in 2012.

ArchLinux, for example, still really, really wants you to make a /boot.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#19

Post by ChuckMcM »

Wow. As someone who was there (I know dating my self here) reading this is kind of like that scene in Sleeper where the person from the future is trying to understand artifacts from the past.

So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem was introduced as a way to keep 'packages' separate from 'system'. The difference between /bin and /sbin was that sbin was 'static-bin' which is to say everything in it was statically linked and could run without any libraries being available.

The fact that Linux starts up differently is because Linux never was UNIX they are two different OSes, pretty much from the ground up. They use similar concepts, processes, file descriptors, Etc, but they are two different species. FreeBSD on the other hand is a derivative of UNIX and last time I checked it started up in a similar way.

The lack of space on the RK05s was indeed the reason for the addition of /usr/{lib, bin} and the general consensus at Sun and AT&T in the 80's was that the root file system contained the system, and the /usr file system contained stuff that was not-system.

AT&T (the guys that 'owned' UNIX) had some pretty detailed specifications about what lived in what directory and why. It was a "BigDeal" (tm) to add a new directory in the root file system so new directories, when they were proposed, appeared under /usr. And once /opt existed it gave people free reign to create their own trees. Early package managers would build /opt//{bin/lib/share/man} and the downside was that ones path variable got longer and longer, and there arguments about if there should be more constraints on opt.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split

#20

Post by gchpaco »

wmf wrote: post #13
rcthompson wrote: post #8

Earlier quoted context omitted.

And the reason for splitting them is so that normal users don't have the super-user programs in their $PATH, since they would be useless there. Of course, this is arguably obsolete now since the advent of sudo, policykit, and so on.

For some reason traceroute is in /sbin, but it works for normal users. Probably another historical accident (did it used to require root?).

Conventional (that is, without capabilities) traceroute and ping were setuid root because it there was no provision for emitting ICMP packets in the network APIs and only root could assemble raw packets.
Post reply on HN