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 505177
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Wow, That Was Simple
by saso on Mon 30th Jan 2012 21:24 UTC 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[5]: Wow, That Was Simple
by saso on Tue 31st Jan 2012 15:27 in reply to "RE[4]: Wow, That Was Simple"
saso Member since:
2007-04-18

Then you fix the bloody bootloader.

Easier said than done. There's a good reason why bootloaders have this limitation - they are meant to be simple. Higher-level raid volumes can have complicated geometries and be spread over a host of interfaces and buses. Trying to support all but the most trivial configurations will result in a serious set of problems in the bootloader stage (e.g. having to duplicate the entire volume+FS layer of the OS in a rather limited space) with little to no gain.

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.


Lots of systems I manage have site-local overrides and having them in custom locations, rather than a well defined one will result in more confusion than order. Arguably, the situation now isn't much better and could do with some improvement, but it's always about finding the proper mix of freedom and regulation.

Reply Parent Score: 1

jabbotts Member since:
2007-09-06

I rather like /boot mounted to seporate hardware. I tend to drop it on an SD since pretty much every machine now has an SD reader. If the machine is dualboot, I can pull the SD and leave the HDD MBA booting to a secondary OS. If the machine is encrypted, I can pull the SD and leave the machine without any boot partition; given that the boot partition is normally unencrypted that also means not having an unecrypted partition sitting on the HDD that's supposed to be fully encrypted.

There is also grief with Win7/Truecrypt and Debian/LVA-Enc dualboot. Truecrypt won't see the Debian bootup but will kick off the Win7 bootup. Debian's boot loader won't see Truecrypt/Win7 but will see Debian's encrypted LVA partitions. Rather than wait for the developers to "fix the boot loader" I simply boot Debian from an SD and use the bios menu to select the HDD boot when I want the Win7 environment.

I think the biggest pain in my years of dualboot systems has been working around an OS that imposes a single boot loader on the drive instead of allowing a boot partition from any mountable media. Heck, Win even gave grief when dualbooting NT/win98 let alone NT+non-MS-OS and you can always count on Windows overwriting the boot sector with it's own loader so you'd best have Grub/Lilo handy on a removable media or you'll be fiddling with SuperGrub trying to get back into and fix the proper multi-boot menu loader after Windows kindly screws it for you. (becaus in Microsoft's world, no one would ever dualboot a non-MS OS so may as well just kill off whatever the user had there already)

Reply Parent Score: 3