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

21–30 of 158 posts

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

#21

Post by koenigdavidmj »

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?).

The particular way traceroute runs is implementation-defined. Some use ICMP echo request packets (ping), which you have to be root to send on most Unices. Most of them, however, use UDP packets instead.

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

#22

Post by triffidhunter »

nailer wrote: post #18
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.

There are plenty of good reasons to make a /boot. Encrypted laptops for example.

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

#23

Post by calloc »

I still have various partitions: /, /var, /usr, and /tmp (on a single slice). When I am in single user mode the only binaries I have available are in /bin. Unless I mount /usr that is all I have access to, so the split still makes perfect sense.

A lot of Linux distributions by default suggest using the entire disk and creating a single partition named /. In that case it doesn't make sense to have the various different locations since mounting / means you have /usr/bin as well.

I don't want a user being able to fill up the hard drive stopping me from writing my logs, stopping me from logging in or various other things (yes, i've filled up my / partition at one point and was unable to log in because SSH was failing to log something or other). There are also security reasons and being able to set various security flags on mount makes it easier to secure a machine as well (such as noexec on /tmp and or /var).

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

#24

Post by tmhedberg »

hollerith wrote: post #17
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).

I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.

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

#26

Post by calloc »

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.

It would break FreeBSD's single user mode when using the defaults during installation for partitioning.

FreeBSD's default install creates: /, /usr, /tmp, /var and swap space.

When you boot in single-user mode all you get is / and nothing else. If everything was in /usr you wouldn't be able to mount /usr ... :P

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

#27

Post by kstenerud »

tmhedberg wrote: post #24
hollerith wrote: post #17

Earlier quoted context omitted.

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).

I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.

Because everyone's idea of what "makes sense" is different. Thus:

/bin

/usr/bin

/usr/share/bin

/usr/share/local/bin

/usr/local/bin

/usr/local/share/bin

/opt/bin

/opt/some/clever/path/system/bin

Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's considered "essential" on some systems but not others.

It reminds me of this: http://xkcd.com/927/

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

#28

Post by jonhohle »

kstenerud wrote: post #27
tmhedberg wrote: post #24

Earlier quoted context omitted.

I'm curious, what is your opposition to `/usr/share`? It seems quite logical to me as a place to store non-executable, read-only, shareable data like man pages and other documentation, fonts, keymaps, color profiles, game data, etc. Where else would you propose to store this sort of thing? I can't really think of a different location in the hierarchy that would make sense.

Because everyone's idea of what "makes sense" is different. Thus: /bin /usr/bin /usr/share/bin /usr/share/local/bin /usr/local/bin /usr/local/share/bin /opt/bin /opt/some/clever/path/system/bin Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's consid…

Perhaps you have some misbehaving software, but I've never seen /usr/share/bin, or /usr/local/share/bin or a lib directory in either of those locations. I just checked FreeBSD boxes (which, admittedly, follow their own standards closely), and a Redhat box.

var is a directory which may be found under /usr or /usr/local, but won't contain a local directory.

Think of it as 3 roots: / is required for boot, /usr is stuff maintained by an administrator (say, company wide), /usr/local is where files installed by local users go. Within each of these 3 roots, you'll have some subset of bin, etc, lib, libexec, sbin, and var. The root directory has some additional singleton directories which don't make sense in the other directories: dev, root, mnt, boot, proc, rescue.

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

#30

Post by dreamdu5t »

Directories that are based on objective criteria don't have this problem.

For example /dev is defined by objective criteria, and thus there's not much argument to what goes into /dev. We should only have core directory structure defined by objective criteria.

Post reply on HN