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 505168
To read all comments associated with this story, please click here.
why not / instead of /usr
by gelendir on Mon 30th Jan 2012 21:16 UTC
Member since:

Fedora has the right idea in mind when they want to simplify the Linux hierarchy, but why put everything in /usr ? Historically /usr was for the user directories, but we've got /home that is now the de facto. Why not put everything back in /bin, /sbin, /lib, etc ? At least you wouldn't need to type 'cd /usr' everytime you need to go somewhere

Reply Score: 2

RE: why not / instead of /usr
by Aristocracies on Mon 30th Jan 2012 21:28 in reply to "why not / instead of /usr"
Aristocracies Member since:

Because that would be more work and less compatible. By putting everything into /usr, you have a *single* directory to concern yourself with when it comes to mounting, sharing and snapshotting an image of the current operating system's binaries.

By symlinking in /bin, /sbin, etc. from root into /usr, you also make sure that files automatically exist in both locations for free which actually increases compatibility with scripts and such that make assumptions about locations.

Doing the inverse of this means you have to not only deal with making sure /usr/* still exists in some form for compatibility reasons, you're also producing more clutter in root and you're adding to the overhead of attempting to manage a single image of the current OS state since they no longer could exist on the same separate file system.

Reply Parent Score: 5

phoenix Member since:

Uhm, why would snapshotting / be any harder than snapshotting /usr? Snapshots happen at the filesystem level, and if everything else is a separate filesystem (/home, /var, yadda yadda) then / is a filesystem all to itself ... so why would snapshotting it be hard?

And if you want to talk about polluting the / directory, have a look at all the virtual filesystems that need mountpoints. Just have a look at the output of "mount" on a Linux system these days. There's a good 8 or so virtual filesystems that all need mountpoints in / (/proc, /sys, /dev, various tmpfs, etc).

Edited 2012-01-30 21:33 UTC

Reply Parent Score: 2

RE: why not / instead of /usr
by phoenix on Mon 30th Jan 2012 21:30 in reply to "why not / instead of /usr"
phoenix Member since:

That would make more sense, in that the Linux initrd/initramfs has taken over the "goal" of the / directory (enough filesystem and utilities to boot the OS) which kind of makes / redundant. It would make more sense to move everything from /usr to /, then the other direction.

I can just see in Fedora 18 or 19 where the directories directly off / will be empty, which just seems pointless.

If they're going to "optimise" and "streamline" things, then at least do it right.

Of course, that would break just about every piece of software out there that expects to install to /usr. ;) But since when has Fedora ever worried about not breaking things needlessly?

Reply Parent Score: 3

RE[2]: why not / instead of /usr
by kragil on Mon 30th Jan 2012 23:56 in reply to "RE: why not / instead of /usr"
kragil Member since:

I don't think it makes a big difference wheter it is / or /usr, but I'll add my .02 cents anyway:

Long run / for real files (Fedora 18,19, maybe 20):


that looks pretty tidy _to_me_, but I'll admit it is not obvious what all the dirs do, but it can be explained in a few sentences if you are interested. People with no interest will never get any filesystem PERIOD
Cluttering that with runtime dirs and bin, games, include, lib, libexec, local, sbin, share, src and tmp really makes it a mess.
Everything else will be either not as flexible or will still need explaining.

Edited 2012-01-31 00:00 UTC

Reply Parent Score: 6

RE[2]: why not / instead of /usr
by jimmmy on Tue 31st Jan 2012 08:17 in reply to "RE: why not / instead of /usr"
jimmmy Member since:

Of course, that would break just about every piece of software out there that expects to install to /usr.

Which would be mostly proprietary software which can't be rebuilt. The bulk of open source software that I've seen can be fixed by telling the build system where to put it. I don't see much of any reason why software shipped with a distribution would be affected much at all by this change.

Most closed source software that I've encountered doesn't care where you run it from so long as it can find some libraries. A shell script wrapper to set LD_LIBRARY_PATH or whatever and off you go. It's probably more likely that your binary only software will break due to an ABI change.

At lest that's been my experience (happy go lucky as it may seem).

I'm neither for or against it. IMO there's bigger things to fret about.

Reply Parent Score: 3

RE[2]: why not / instead of /usr
by Lennie on Tue 31st Jan 2012 12:09 in reply to "RE: why not / instead of /usr"
Lennie Member since:

It would make more sense to move everything from /usr to /, then the other direction.

The idea is that you can snapshot /usr seperately from /var, /etc, /boot, etc.

Reply Parent Score: 2

RE[2]: why not / instead of /usr
by milki on Tue 31st Jan 2012 21:16 in reply to "RE: why not / instead of /usr"
milki Member since:

That's what I thought too. Consolidation makes sense, but why further the / root and /usr split, if that was the historic problem to begin with?

And if I have a look at my root directory:

bin cdrom hardy initrd.img.old lib64 media proc sbin sys usr vmlinuz.old
boot dev home lib lost+found mnt root selinux tftpboot var www
build etc initrd.img lib32 maverick opt run srv tmp vmlinuz

And then at my /usr:

bin etc games include lib lib32 lib64 local sbin share src

It's clear which the appendix is. And if you were to move the /usr stuff onto main (nowadays have only one partition anyway), then there would hardly be additions.

But it also becomes appearant that "/games" is kind of redundant. There's little point in having a separate binary directory for one type of applications. That is just other historic cruft (namely to shame those users who have games installed). Likewise should /include actually be part of /src. And I'm not entirely sure about /share, but that should probably go into /var anyway.

Reply Parent Score: 1