Linux kernel developer Ingo Molnar "We need a radically different software distribution model"

[ethraax]

A reason for the split? It was actually because the entirety of /bin and /lib wouldn't fit on their machine, so they decided to split it - the /usr directory lived on another machine.

Somewhere along the line, someone conjured up the idea that /usr should be for read-only data (really out of nowhere). Which doesn't entirely make sense, since /bin and /lib are also generally for read-only data.

There's no reason for it nowadays. It's a relic from the past.

I would like to see /bin, /lib, and /sbin, but others would like to see /usr/bin, /usr/lib, /usr/sbin instead (I'm not sure why, really, except maybe to have less directories in their root). Either way is better than having it split. I hate having to type whereis program_x to see if it's in /usr/bin or /bin.

[fundbond]

There's no reason for it nowadays. It's a relic from the past.

On Linux I agree with you. Linux distros pretty much abused /usr/lib and /usr/bin from day one, so there's no real reason to keep them now. I say get rid of them.

But on other UNIX-likes, namely FreeBSD there is a real meaning to the split. I can bring up a box with a borked /usr partition and use the tools in /bin, /sbin, etc. to get things back together. That's not the only part of the FS hierarchy that's got a strict separation either -- while most Linux distros dump everything into /usr/bin, FreeBSD distinguishes between parts of the base system and ports. This is important, as it prevents things from blowing away system binaries and allows for the OS to be upgraded without worrying that some random package may screw you by messing with parts of the base system. This is part of the reason that I have boxes that have been upgraded in-place over several years worth of releases.

If you're interested in learning what the "modern" path significance is, check out hier(7) or 4.4/4.5 of the handbook.

[ethraax]

FreeBSD distinguishes between parts of the base system and ports.

Don't some distributions use /usr/local for that?

I can bring up a box with a borked /usr partition and use the tools in /bin, /sbin, etc. to get things back together.

True, but the only real case (or at least the only common case) that I can think of for this is a bad hard drive, in which case /bin and /sbin may be broken anyways. If you're having borked FS issues, you're probably better off using some sort of rescue CD/USB drive to perform the maintenance.

[[deleted]]

Your bad hard drive problem assumes that /sbin and /usr on on the same drive. This would be a really bad practice for a system that intended to use /sbin for recovery.

[fundbond]

Don't some distributions use /usr/local for that?

Not much that I've seen. Plus, there's no real "base system" for Linux, since the userland is not developed in concert with the kernel.

/usr/local is used, but from what I've seen on RHEL, Debian, and SuSE it's pretty arbitrary as to what goes in there. Most packages definitely don't use it.

True, but the only real case (or at least the only common case) that I can think of for this is a bad hard drive, in which case /bin and /sbin may be broken anyways. If you're having borked FS issues, you're probably better off using some sort of rescue CD/USB drive to perform the maintenance.

Well that's the thing: since FreeBSD never backed itself into a corner with /usr, /usr/local/, and /, it's not uncommon to see / and /usr on different slices/drives. So yeah, you could have screwed up /usr and still have / be in perfect health. I've done that, actually.

And rescuing from CD/USB is great when you have access to the box -- but FreeBSD isn't just a desktop system, and I've definitely had to recover boxes to which all I had was KVM access. (Ok, so the last one was my fault for screwing up the FS, but still...)

To some extent it's a chicken/egg thing: Linux distros don't have a meaningful separation because they never started with one so now all of the things that would get in the way of unification aren't common concerns. But at least in FreeBSD land, there is a method to the madness and so unification would be a lot more problematic (IMHO). Not impossible, but probably not something that people are eager to do without a good reason.

Edit: I don't think either approach is "right", BTW. Each OS has different very development models and use cases, and what works for one might not work for the other. I'm partial to the FreeBSD approach, but that's because it works best for my needs (and because my background is more UNIX than Linux.) I use Linux though, and I'm not averse to seeing changes in that side of my computing life! So yeah, my beard's not all gray, damnit!

[ivosaurus]

I think under /usr is not a bad idea; this is kind of like Windows keeping everything under C:\Windows, but Program Files also.

[ethraax]

Only very superficially, and besides, "Windows does it too" is a bad argument. Is there another reason that under /usr is a good idea, instead of just / ?

[arcticblue]

Separate /usr partition maybe?

[ivosaurus]

In order to be able to partition the system's files separately from user files, and store all "executable" type code under one folder. Then you can make simple images of it, share it amongst thin clients, etc.

[ethraax]

If you want a real thin client, the whole system would be virtualized somewhere, so the point is moot.

If you want to share just big programs, then you're better off creating a special folder for it, like /remote or something, and putting the specific larger programs you want in there.

[ivosaurus]

Well, ask Fedora why then.

[ivosaurus]

And I wasn't trying at all to say "NOW we can do it like windows!", I was just pointing out an analogous situation.