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 505169
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Wow, That Was Simple
by Thom_Holwerda on Mon 30th Jan 2012 21:18 UTC 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[4]: Wow, That Was Simple
by lindkvis on Tue 31st Jan 2012 09:10 in reply to "RE[3]: Wow, That Was Simple"
lindkvis Member since:
2006-11-21


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

Then you fix the bloody bootloader.


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


Wherever you want. Seriously, you can create your own directory structure and put whatever you want there, and then you can add this to the users' PATH ahead of /bin. There is absolutely no reason for every Linux distribution coming with a predefined place for something which is actually a very rare occurrence.

Reply Parent Score: 4

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[4]: Wow, That Was Simple
by phoenix on Mon 30th Jan 2012 21:50 in reply to "RE[3]: Wow, That Was Simple"
phoenix Member since:
2005-07-11

Windows 7 is closer:
\Users
\Windows
\Program files
\Program files(x86)

Reply Parent Score: 5

RE[4]: Wow, That Was Simple
by leech on Mon 30th Jan 2012 23:15 in reply to "RE[3]: Wow, That Was Simple"
leech Member since:
2006-01-10

"/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'
"

Yeah, and those that actually have to dig through file locations occasionally find the "windows way" a nightmare! I need to find where a file is on Linux? There are a ton of ways. I need the actual location of an executable? Use 'which <program>' and it'll show you the full path. You need to know what package a file belongs to? dpkg -S <filename> (at least on Debian based distributions.)

The Windows way is a mess, because while you have Program Files or Program Files (x86), not all installers default to put things there, and even then you can change the default so not all systems will have files in the same place.... Then you have the fact that some installers want to put the company name in there, so you end up getting a huge mess. A good example is Steam. C:\Program Files (x86)\Steam\SteamApps\common\rainbow six 3 gold\Mods\ is where I have to install mods to. Not all mod installers detect where it is installed, so I manually have to drop files in there.

Far easer to have /usr/games/doom/ and throw the files in there, wouldn't you say?

Reply Parent Score: 5

RE[4]: Wow, That Was Simple
by dorin.lazar on Tue 31st Jan 2012 01:19 in reply to "RE[3]: Wow, That Was Simple"
dorin.lazar Member since:
2006-12-15

Is that a bad thing? Not if you ask me.

Reply Parent Score: 1

RE[4]: Wow, That Was Simple
by l3v1 on Tue 31st Jan 2012 07:01 in reply to "RE[3]: Wow, That Was Simple"
l3v1 Member since:
2005-07-06


That looks a lot like:

Documents and Settings
Windows
Program Files


Just sayin'


Well, then take a look under them. And you'll see how some of us take the linux "nightmare" anytime over the above.

Reply Parent Score: 4

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