Merging /usr/bin and /bin would bring a load of security issues. There's a reason why kernel and user land utilities are kept segregated. Security. Its all permissions.

1 members found this post helpful.

Sorry, don't see it. Our $PATH already contains both /bin and /usr/bin so I really don't see how a unified directory would be in any way worse than what we already have.

Note: I'm not saying bin and sbin should be merged (which I believe Fedora were actually considering at one point), which would be IMO idiotic.

2 members found this post helpful.

i'm not that experienced


if you make it so a user with some pseudo sudo can only install to /usr/bin

a binary is first checked in /bin, then /usr/bin
so there is no way for that user/package to override it for others
(i know users should install extra/unnecessary programs to opt)

hier(7) is a good read on this. You will notice, that libexec is still there and they never had a /var/lib. Sometimes it doesn't harm to look at a real Unix implementation. :-)

4 members found this post helpful.

Indeed. OpenBSD's hierarchy is much cleaner too. The /usr/lib and /var/lib thing we see on linux is definitely a deviation from traditional UNIX.

P.S. I don't mind deviations as long as they make sense.

1 members found this post helpful.

Slackware has this. Since when is it deprecated? Or is it planned? Would be a pity, I even have SlackBuilds that install additional executables there...

1 members found this post helpful.

I think current practice with Slackware is to configure using: --libexecdir=/usr/sbin

Some certainly do, though I think /usr/lib/$appname is a more common place and if I'm remembering rightly what the FHS mandates for indirectly executed executables.

I'm a bit of a neat-freak when it comes to the filesystem. Though I'd rather see .../libexec used for the purpose, I can tolerate putting app specific subdirectories in /usr/lib${LIBDIRSUFFIX/ but when stuff just gets dumped directly into /usr/lib$LIBDIRSUFFIX such as xml2Conf.sh and tkConfig.sh and the like, well, that's just messy.

But, I suppose those of us who care about such things are in the minority. I suspect the vast majority of linux users never look outside of their home directories.

1 members found this post helpful.

Well, it wasn't so much that it was explicitly 'deprecated'. The FHS decided to take an alternative approach rather than use the BSD style /libexec that older distros were already supporting, and package maintainers have just drifted in that direction. The default libexecdir setting of ./configure on linux is probably a big factor in the migration to the FHS way of doing things.

Some of that mileage variance is "I'd like to mount /usr on its own logical volume.".

I like it, and if I had to choose between to otherwise identical distros for my workstations I would choose the one laid out like gobo. I'm gonna look at gobo in more detail, but truth be told there is more to a distro than the file system layout, so I might not switch over my production systems yet ^^

PS: and thanks to ruario for reminding us about the origin of some design decisions made at the dawn of UNIX. It never ceases to amaze me how standardisation organsiations and corporate concrete heads turn arbitrary and outdated design decisions into the gospel. On the other hand I do see the value of standardisation, and I realize sometimes it is better to live with a suboptimal standard than with none at all. That's where standardisation organisations could help by slowly introducing a standard B while standard A is still in operation.

Yep, some folks like to do that, and I ran with a separate /usr for a long, long time, but I stopped a few years back when it occurred to me to ask myself, "Why am I doing this?" and the only answer I came up with was "tradition". I wonder how many of the people who still do this would come up with the same answer if they asked themselves that same question.

I have separate /var, /tmp, /home and even /usr/src filesystems on my system (using LVM), so I'm not against the principle of using separate filesystems where there's benefit to be gained from it.

In the early days I had a simple setup with only / and /usr separated on BSD, which makes perfect sense:

/ on a faster smaller disk contained performance-relevant stuff including /var and /tmp and everything required for a fast boot like /bin/sh, /etc/rc and so on.

/usr on a slower but larger disk contained third party packages, sources, home directories and everything else (/opt doesn't exist, packages install into /usr/local, /usr/pkg or something like that.)

The advantage over a single / was better performance and more reliabilty. There was no need to separate /var or /home (and run into space issues), both installed applications and home directories (including apps installed into $HOME) could make use of the full available disk space on /usr. Back then I had only disks with a few GBs, so that was important.

It is not possible to reproduce this setup on Linux. The Linux /usr equivalent is / now, so you basically end up with a single /.

My guiding principle is to separate predominantly 'rw' filesystems from predominantly 'ro' filesystems, which is why I'd never leave /tmp, /var or /home in the rootfs. And while / is still subject to a little writing even after separating those 3 filesystems, write activity will be minimal, so I see no value in separating /usr from it. Coincidentally, it also results in a pretty clean split between what can be considered 'system' and 'data' which is also nice.


I understand what you're describing above, but those sorts of hardware optimisations are a thing of the past. Large memory, VFS Cache, faster devices with on device buffers/cache/abstraction/virtualisation have pretty much negated many of the choices we used to have to make. I suspect a lot of newer admins will just give you a blank stare if you ever talk about 'inner-edge', 'outer-edge' or 'middle'.

Anyway, we're starting to get seriously off-topic here, so I'll leave it there.

I've often seen people trying to save / from write accesses, but they never tell a technical reason for it. I can see the point of having a separate /var on a heavy-loaded server, so now we need a /run directory, because /var/run isn't available at boot. But sometimes you want to keep things simple and don't create dozens of partitions, only two or three. BTW: Separating /home is only needed, because it contains the home directories instead of /usr. It was never meant to be left on /.

As I said, Red Hat Linux now treats / as /usr (UsrMove).

Of course not, today we have devices with small fast embedded flash memory and a slow SD card. And the well-organized BSD filesystem hierarchy is still able to adapt to that much better.

This is still a thing with hard disks, they are faster on the outside (smaller LBA numbers).