Lots of good things were originally unintended or semi-intended results of technical limitations. The /usr split is still a good idea today even if those technical limitations no longer exist. It’s not a matter of people not understanding history, or of people not realising the origins of things, but that things outgrow their history.
Rob’s email is, in my opinion, quite condescending. Everyone else is just ignorantly cargo-culting their filesystem hierarchy. Or perhaps not? Perhaps people kept the split because it was useful? That seems a bit more likely to me.
I’m not sure it is still useful.
In fact, some linux distributions have moved to a “unified usr/bin” structure, where /bin, /sbin/, and /usr/sbin all are simply symlinks (for compatibility) to /usr/bin. Background on the archlinux change.
I think there’s a meaningful distinction there, but it’s a reasonable decision to say ‘there are tradeoffs for doing this but we’re happy with them’. What I’m not happy with is the condescending ‘there was never any good reason for doing this and anyone that supports it is just a cargo culting idiot’ which is the message I felt I was getting while reading that email.
In fact, some linux distributions have moved to a “unified usr/bin” structure, where /bin, /sbin/, and /usr/sbin all are simply symlinks (for compatibility) to /usr/bin. Background on the archlinux change.
I’m not quite sure why they chose to settle on /usr/bin as the one unified location instead of /bin.
That wasn’t the argument though. There was a good reason for the split (they filled up their hard drive). But that became a non-issue as hardware quickly advanced. Unless you were privy to these details in the development history of this OS, of course you would copy this filesystem hierarchy in your unix clone. Cargo culting doesn’t make you an idiot, especially when you lack design rationale documentation and source code.
… it’s a reasonable decision to say ‘there are tradeoffs for doing this but we’re happy with them’. What I’m not happy with is the condescending ‘there was never any good reason for doing this and anyone that supports it is just a cargo culting idiot’ which is the message I felt I was getting while reading that email.
Ah. Gotcha. That seems like a much more nuanced position, and I would tend to agree with that.
I’m not quite sure why they chose to settle on /usr/bin as the one unified location instead of /bin
I’m not sure either. My guess is since “other stuff” was sticking around in /usr, might as well put everything in there. /usr being able to be a single distinct mount point that could ostensibly be set as read-only, may have had some bearing too, but I’m not sure.
Personally, I think I would have used it as an opportunity to redo hier entirely into something that makes more sense, but I assume that would have devolved into endless bikeshedding, so maybe that is why they chose a simpler path.
My guess is since “other stuff” was sticking around in /usr, might as well put everything in there. /usr being able to be a single distinct mount point that could ostensibly be set as read-only, may have had some bearing too, but I’m not sure.
That was a point further into the discussion. I can’t find the archived devwiki entry for usrmerge, but I pulled up the important parts from Allan.
Personally, I think I would have used it as an opportunity to redo hier entirely into something that makes more sense, but I assume that would have devolved into endless bikeshedding, so maybe that is why they chose a simpler path.
Seems like we did contemplate /kernel and /linker at one point in the discussion.
What convinced me of putting all this in /usr rather than on / is that I can have a separate /usr partition that is mounted read only (unless I want to do an update). If everything from /usr gets moved to the root (a.k.a hurd style) this would require many partitions. (There is apparently also benefits in allowing /usr to be shared across multiple systems, but I do not care about such a setup and I am really not sure this would work at all with Arch.)
Evidently, we also had an request to symlink /bin/awk to /usr/bin/awk for distro compatability.
This actually will result in more cross-distro compatibility as there will not longer be differences about where files are located. To pick an example, /bin/awk will exist and /usr/bin/awk will exist, so either hardcoded path will work. Note this currently happens for our gawk package with symlinks, but only after a bug report asking for us to put both paths sat in our bug tracker for years…
Sorry, I can’t tell from your post - why is it still useful today? This is a serious question, I don’t recall it ever being useful to me, and I can’t think of a reason it’d be useful.
My understanding is that on macOS, an OS upgrade can result in the contents of /bin being overwritten, while the /usr/local directory is left untouched. For that reason, the most popular package manager for macOS (Homebrew) installs packages to /usr/local.
I think there are cases where people want / and /usr split, but I don’t know why. There are probably also arguments that the initramfs/initrd is enough of a separate system/layer for unusual setups. Don’t know.
It’s nice having /usr mounted nodev, whereas I can’t have / mounted nodev for obvious reasons. However, if an OS implements their /dev via something like devfs in FreeBSD, this becomes a non-issue.
It is on FreeBSD, which is why I mentioned devfs, but idk what the situation is on Linux, Solaris and AIX these days off the top of my head. On OpenBSD it isn’t.
I dunno, hasn’t been useful to me in the last 20 years or so. Any problem that it solves has a better solution in 2020, and probably had a better solution in 1990.
The BSDs do have the related /usr/local split which allows you to distinguish between the base system and ports/packages, which is useful since you may want to install different versions of things included in the base system (clang and OpenSSL for example). This is not really applicable to Linux of course, since there is no ‘base system’ to make distinct from installed software.
I tend to rush for /opt/my-own-prefix-here (or per-package), myself, mainly to make it clear what it is, and avoid risk of clobbering anything else in /usr/local (like if it’s a BSD). It’s also in the FHS, so pedants can’t tell you you’re doing it wrong.
It does - this is generally used for installing software outside the remit of the package manager (global npm packages, for example), and it’s designated so by the FHS which most distributions follow (as other users have noted in this thread), but it’s less prominent since most users on Linux install very little software not managed by the package manager. It’s definitely a lot more integral in BSD-land.
[…] since most users on Linux install very little software not managed by the package manager
The Linux users around me still do heaps of ./configure && make install; but, I see your point when contrasted against the rise of PPAs, Docker and nodenv/rbenv/pyenv/…
Yeah, I do tons of configure make install stuff, sometimes of things that are also in the distro - and this split of /usr/local is sometimes useful because it means if I attempt a system update my custom stuff isn’t necessarily blasted.
That sounds sensible. Seems like there could be a command that tells you the difference. Then, a versioning scheme that handles the rest. For example, OpenVMS had file versioning.
With ZFS on FreeBSD we have the split, and if you corrupt zroot/usr somehow it would be nice to have the system in a state where you can still recover it.
It’s also why we have all those statically linked tools in /rescue which I find valuable.
In the age of destroy and redeploy I don’t think many people find it useful, but I’ve never bought into that cult mindset. It’s important to understand how or why something broke and to repair it.
edit: especially if the breakage is from a major security breach that went undetected
Lots of good things were originally unintended or semi-intended results of technical limitations. The /usr split is still a good idea today even if those technical limitations no longer exist. It’s not a matter of people not understanding history, or of people not realising the origins of things, but that things outgrow their history.
Rob’s email is, in my opinion, quite condescending. Everyone else is just ignorantly cargo-culting their filesystem hierarchy. Or perhaps not? Perhaps people kept the split because it was useful? That seems a bit more likely to me.
I’m not sure it is still useful.
In fact, some linux distributions have moved to a “unified usr/bin” structure, where
/bin,/sbin/, and/usr/sbinall are simply symlinks (for compatibility) to/usr/bin. Background on the archlinux change.I think there’s a meaningful distinction there, but it’s a reasonable decision to say ‘there are tradeoffs for doing this but we’re happy with them’. What I’m not happy with is the condescending ‘there was never any good reason for doing this and anyone that supports it is just a cargo culting idiot’ which is the message I felt I was getting while reading that email.
I’m not quite sure why they chose to settle on
/usr/binas the one unified location instead of/bin.That wasn’t the argument though. There was a good reason for the split (they filled up their hard drive). But that became a non-issue as hardware quickly advanced. Unless you were privy to these details in the development history of this OS, of course you would copy this filesystem hierarchy in your unix clone. Cargo culting doesn’t make you an idiot, especially when you lack design rationale documentation and source code.
Ah. Gotcha. That seems like a much more nuanced position, and I would tend to agree with that.
I’m not sure either. My guess is since “other stuff” was sticking around in
/usr, might as well put everything in there./usrbeing able to be a single distinct mount point that could ostensibly be set as read-only, may have had some bearing too, but I’m not sure.Personally, I think I would have used it as an opportunity to redo hier entirely into something that makes more sense, but I assume that would have devolved into endless bikeshedding, so maybe that is why they chose a simpler path.
That was a point further into the discussion. I can’t find the archived devwiki entry for usrmerge, but I pulled up the important parts from Allan.
Seems like we did contemplate
/kerneland/linkerat one point in the discussion.https://lists.archlinux.org/pipermail/arch-dev-public/2012-March/022629.html
Evidently, we also had an request to symlink
/bin/awkto/usr/bin/awkfor distro compatability.https://lists.archlinux.org/pipermail/arch-dev-public/2012-March/022632.html
And bug; https://bugs.archlinux.org/task/17312
Sorry, I can’t tell from your post - why is it still useful today? This is a serious question, I don’t recall it ever being useful to me, and I can’t think of a reason it’d be useful.
My understanding is that on macOS, an OS upgrade can result in the contents of
/binbeing overwritten, while the/usr/localdirectory is left untouched. For that reason, the most popular package manager for macOS (Homebrew) installs packages to/usr/local.I think there are cases where people want / and /usr split, but I don’t know why. There are probably also arguments that the initramfs/initrd is enough of a separate system/layer for unusual setups. Don’t know.
It’s nice having
/usrmountednodev, whereas I can’t have/mountednodevfor obvious reasons. However, if an OS implements their/devvia something likedevfsin FreeBSD, this becomes a non-issue.Isn’t /dev an own mountpoint anyways?
It is on FreeBSD, which is why I mentioned
devfs, but idk what the situation is on Linux, Solaris and AIX these days off the top of my head. On OpenBSD it isn’t.Linux has devtmpfs per kernel default.
The complexity this introduced has far outweighed any perceived benefit.
I dunno, hasn’t been useful to me in the last 20 years or so. Any problem that it solves has a better solution in 2020, and probably had a better solution in 1990.
Do you have a counter-example where the split is still useful?
The BSDs do have the related
/usr/localsplit which allows you to distinguish between the base system and ports/packages, which is useful since you may want to install different versions of things included in the base system (clang and OpenSSL for example). This is not really applicable to Linux of course, since there is no ‘base system’ to make distinct from installed software.Doesn’t Linux have the same
/usr/localsplit? It’s mentioned in the article.I tend to rush for
/opt/my-own-prefix-here(or per-package), myself, mainly to make it clear what it is, and avoid risk of clobbering anything else in/usr/local(like if it’s a BSD). It’s also in the FHS, so pedants can’t tell you you’re doing it wrong.It does - this is generally used for installing software outside the remit of the package manager (global npm packages, for example), and it’s designated so by the FHS which most distributions follow (as other users have noted in this thread), but it’s less prominent since most users on Linux install very little software not managed by the package manager. It’s definitely a lot more integral in BSD-land.
The Linux users around me still do heaps of
./configure && make install; but, I see your point when contrasted against the rise of PPAs, Docker andnodenv/rbenv/pyenv/…Yeah, I do tons of configure make install stuff, sometimes of things that are also in the distro - and this split of /usr/local is sometimes useful because it means if I attempt a system update my custom stuff isn’t necessarily blasted.
But the split between /bin and /usr/bin is meh.
That sounds sensible. Seems like there could be a command that tells you the difference. Then, a versioning scheme that handles the rest. For example, OpenVMS had file versioning.
With ZFS on FreeBSD we have the split, and if you corrupt zroot/usr somehow it would be nice to have the system in a state where you can still recover it.
It’s also why we have all those statically linked tools in /rescue which I find valuable.
In the age of destroy and redeploy I don’t think many people find it useful, but I’ve never bought into that cult mindset. It’s important to understand how or why something broke and to repair it.
edit: especially if the breakage is from a major security breach that went undetected