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

131–140 of 158 posts

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

#131

Post by elehack »

cbsmith wrote: post #66
sciurus wrote: post #46

Earlier quoted context omitted.

For those who haven't seen the proposal for the / /usr merge: "Fedora (and other distributions) have begun work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead" http://www.freedes…

Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?

The feature implementation and details have seen some refinement, so it's much less of a mess in its current state (e.g. the directories are symlinked, not the files): https://fedoraproject.org/wiki/Features/UsrMove

You get wins on packaging (don't need to worry about where to scatter executables, although this doesn't affect many packages), as well as "all software is under /usr", so everything the package manager touches except config file updates is under a single directory. This makes both centralized updates and pre-update snapshotting much more feasible.

I'm really looking forward to this feature. With appropriate support from the file system and yum, it seems like it brings us one step closer to truly transactional multi-package system updates/software installations. Yes, some of this was already possible with snapshotting support in a plugin for Yum, but I think the consolidation will likely make implementing such features simpler and more robust.

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

#132

Post by aangjie »

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…

Actually it reminded me of http://xkcd.com/981/

But i do remember seeing /usr/share/bin and /usr/share/local/bin and thinking wtf... But then i play around too much with my OS to reliably blame it on the distro...

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

#133

Post by aangjie »

el_presidente wrote: post #107
cbsmith wrote: post #66

Earlier quoted context omitted.

Thanks. These seems like one of those things that while it might be sensible, wouldn't provide much of a win, so why bother with the mess?

Probably because fedora has a six month release cycle and they feel the need to make some kind of revolutionary change on every release. Of course, /bin will never be removed since there are millions of scripts depending on /bin/sh in the wild. So they'll basically end up having to maintain this symlink spaghetti for a long time.

I agree with that symlink spaghetti for a long time comment.. It seems harsh to fedora to say they feel a need for a revolution.. i really don't follow release cycles/linux versions... close enough.. but my upgrade experiences so far(Fedora 8-13 vs Ubuntu 8-11.10) indicate it's ubuntu that feel a need to make revolutionary change.. i.e: to say, i have gone wtf more times searching for some custom setting on ubuntu menu's than fedora's

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

#134

Post by nathan_f77 »

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.

"The advent of sudo"...

As someone with only 2 years Linux experience, this blows my mind

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

#135

Post by joeyh »

dreamdu5t wrote: post #30

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.

Except for /dev/MAKEDEV (required to be there by the FHS and for hysterical raisins). And then there was all the crap udev used to put in /dev/.udev/, which has thankfully migrated to /run.

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

#137

Post by X-Istence »

lmm wrote: post #114
X-Istence wrote: post #76

Earlier quoted context omitted.

Packages/binaries/ports tree installs into /usr/local/. See man hier [1]. For example, on a FreeBSD install, it is perfectly safe to rm -rf /usr/local/. Your system will still boot without issues. [1] http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...

Which I find is actually quite problematic; "make install" by default puts things into /usr/local, and I would prefer to distinguish between things I've installed and things ports have installed. (Specifically, I need to build my own mplayer, but I also need the ports version installed as some other ports depend on it).

Feel free to change the prefix passed to the packages you install by hand. /usr/local is the default used by almost all packages I am familiar with, if for example you want /opt you have to modify that yourself.

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

#138

Post by X-Istence »

lmm wrote: post #113
X-Istence wrote: post #75

Earlier quoted context omitted.

/usr is maintained by the OS, and contains stuff that isn't required for boot but to round out the system. /usr/local is where local modifications to the OS go, these can be site-wide (company wide) and can be hosted on NFS for example for network boots. User installed stuff belongs in /usr/home/ /*. Users shouldn't have root access to install stuff in /usr/local.

Side point: it really bothers me that on freebsd the ports system takes over /usr/local. I expect /usr/local to consist of things that I as admin have installed by hand, and nothing else.

You can change where packages are installed using some make.conf flags. You can then install the software anywhere you want. Your users will need to add the new path to their PATH and you'll need to set some flags in rc.conf to pick up the new rc.d path as well (so software installed through ports gets auto-started).

Then again, when you install ports you as the sysadmin are installing those by hand ...

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

#139

Post by contextfree »

Florin_Andrei wrote: post #90
Osiris wrote: post #87

As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suite…

I learned Linux pretty well before I learned Windows (I was an early adopter) and I felt equally baffled by Windows at a time. I felt nothing made sense. :)

I don't think either make any sense. I guess you could give Windows the nod for not really even making any pretense of making sense (my favorite detail is how 64-bit system files go in "System32" and 32-bit system files go in "SysWOW64"). OTOH while I never got the /bin /sbin /usr/bin /usr/sbin thing, I always vaguely assumed there was some deep reason behind it that I just didn't understand.

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

#140

Post by [deleted] »

Florin_Andrei wrote: post #90
Osiris wrote: post #87

As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suite…

I learned Linux pretty well before I learned Windows (I was an early adopter) and I felt equally baffled by Windows at a time. I felt nothing made sense. :)

[deleted]
Post reply on HN