Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
General Unix Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.
Thread beginning with comment 505167
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Wow, That Was Simple
by kenji on Mon 30th Jan 2012 21:13 UTC in reply to "Wow, That Was Simple"
kenji
Member since:
2009-04-08

This also vindicates my first thought when I started using *nix - that "/usr" looks and sounds like "user". That name never made sense to me.

/usr _IS_ (mostly) for user stuff, it just mostly became obsolete with the advent of /home. FreeBSD actually puts home in /usr/home but links it to /home for compatibility.

It makes sense to have separation between root and user, even Windows has been set up this way since ... forever. Third party software belongs outside the 'core' of the OS, in my opinion. In Linux the lines are very blurry and not so intuitive but that does not make it unjustified.

Edited 2012-01-30 21:16 UTC

Reply Parent Score: 4

RE[2]: Wow, That Was Simple
by Thom_Holwerda on Mon 30th Jan 2012 21:18 in reply to "RE: Wow, That Was Simple"
Thom_Holwerda Member since:
2005-06-29

/users
/system
/programs (or /Apps, in this day and age).

More is not needed at root.

(although I personally would like to see a /settings as well, as I argued in my proposal: http://www.osnews.com/story/19711/The_Utopia_of_Program_Management/... ).

Reply Parent Score: 10

RE[3]: Wow, That Was Simple
by saso on Mon 30th Jan 2012 21:24 in reply to "RE[2]: Wow, That Was Simple"
saso Member since:
2007-04-18

/users
/system
/programs (or /Apps, in this day and age).

More is not needed at root.

What if your boot process forces you to put the kernel and base module on a separate volume? (e.g. you keep most of your OS on a RAID-5/6 volume, but most bootloaders have trouble loading from anything other than a plain or RAID-1 volume).

Also, where do you put site-local overrides for distribution maintainer tools (e.g. a custom version of some libraries)?

Reply Parent Score: 6

RE[3]: Wow, That Was Simple
by kenji on Mon 30th Jan 2012 21:33 in reply to "RE[2]: Wow, That Was Simple"
kenji Member since:
2009-04-08

/boot or something similar would also be necessary to have it mounted read only.

The problem with dumping files into a less 'structured' hierarchy is that you limit versatility and customization options. Is it better to have 500+ executables in one directory rather than ORGANIZING (ie compartmentalizing) them?

I think the best solution lies somewhere in between over simplifying and over complicating.

Edited 2012-01-30 21:35 UTC

Reply Parent Score: 6

RE[3]: Wow, That Was Simple
by giffypop17 on Mon 30th Jan 2012 21:48 in reply to "RE[2]: Wow, That Was Simple"
giffypop17 Member since:
2009-03-09

/users
/system
/programs (or /Apps, in this day and age).

More is not needed at root.



That looks a lot like:

Documents and Settings
Windows
Program Files


Just sayin'

Reply Parent Score: 15

RE[3]: Wow, That Was Simple
by laffer1 on Tue 31st Jan 2012 04:05 in reply to "RE[2]: Wow, That Was Simple"
laffer1 Member since:
2007-11-09

Looks like Mac OS X mixed with OpenStep to me. I actually prefer /Users to /home, and love having GUI apps installed in /Applications on OS X, but moving /bin /sbin and so forth is just going to cause problems with shell scripts and other apps that expect things to be in certain places.

Reply Parent Score: 1

RE[3]: Wow, That Was Simple
by Elv13 on Tue 31st Jan 2012 14:53 in reply to "RE[2]: Wow, That Was Simple"
Elv13 Member since:
2006-06-12

/users
/system
/programs (or /Apps, in this day and age).

More is not needed at root.

(although I personally would like to see a /settings as well, as I argued in my proposal: http://www.osnews.com/story/19711/The_Utopia_of_Program_Management/... ).

Add /config, /logs /services to that (aka, srv, what var have been renamed too some time ago).

You don't want service data (database, upload, VMs, repositories...) to be with the program data. Those subvolumes/partitions/disks have different backup policy, mount options and SELinux policies. Merginf the two would be a security issue. It would also make impossible to use alternative medium like SAN or NAS.

As for config, you don't want them to be spread across the system. /etc is a terrible name, but the concept is good.

/logs is quite obvious (it fit in no categories you described above, it would be stupid to force it into one).

Reply Parent Score: 2

jabbotts Member since:
2007-09-06

I'd actually include /opt or /optional or /thirdparty.. whatever name makes sense.

You have /system stuff that is core OS/distro.

You have /programs stuff that is user application level stuff not core but still delivered through the distribution.

You have /opt stuff that is completely third party; not delivered through the distribution.

and of course /home for your users and maybe /root cause root should still be segregated.

Between tarball installs and third party distro package installs, it's nice to have an opt tree to dump it under instead of mashing it in with system/apps managed by the distribution repositories. An example would be Splunk installing under /opt because it's installer is provided by the company directly not through a distribution repository.

Reply Parent Score: 2