
Understanding the bin, sbin, usr/bin , usr/sbin split (2010) - kylerpalmer
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
======
m45t3r
For all people that think this is still a issue: it is not:

* Arch Linux: [https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc...](https://wiki.archlinux.org/index.php/Arch_filesystem_hierarchy)

* Fedora: [https://fedoraproject.org/wiki/Features/UsrMove](https://fedoraproject.org/wiki/Features/UsrMove)

* Debian: [https://wiki.debian.org/UsrMerge](https://wiki.debian.org/UsrMerge)

* Ubuntu: [https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMer...](https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMerge)

And this is true for quite a long time. I think the last distro that did /usr
merge is Debian and this is already 3 years ago. So I find surprising that
people still thinks that this is a issue.

The only thing that remains is the difference between bin and sbin that
Fedora/Ubuntu/Debian still maintain (Arch Linux simply merged everything).

P.S.: of course, there should be still distros that use a split /bin /usr/bin,
/lib and /usr/lib, etc. OpenWRT is one of them. However I think the major
distros already migrated.

~~~
adwf
Arch still occasionally has some packages installed to /opt. Annoying as hell,
but they expect to be there for some reason. Android-studio was the latest
unexpected surprise for me.

~~~
johnny22
I've seen distros choose /opt for software not built by the maintainers, but
simply repackaged in binary form. This would include software like oracle/sun
java.

------
bbanyc
Nitpicking:

If you look at the very early versions of the Unix manuals, before even /lib
was invented, there was a notion that /bin was the "system" (section 1) and
/usr/bin was "user software" (section 6). This fell by the wayside when they
ran out of disk space on / and started putting section 1 commands in /usr/bin.
At some point the system/user distinction was abandoned and everything but the
games got moved to section 1 of the manual.

(Back in those early days /lib files used to be in /etc. So did /sbin. There's
still a meaningful semantic difference between programs any user could run vs
programs only useful to root.)

On *BSD there is no initramfs equivalent and the / partition still serves its
traditional role of the minimal startup environment. And /home never existed
before Linux - it was always something like /usr/home as far as I can tell.

~~~
digi_owl
I can't help think that initramfs is a pox on Linux. It seems to lead to all
kinds of "solutions" that are bothersome at best to maintain unless you have
big dollars at your back.

~~~
kakwa_
I've never quite understood it myself.

It's far from mandatory (I've run Gentoo for years without it) and when you
have to fix stuff in the mkinitrd script, you just cry...

------
nickpsecurity
NixOS is one of the few distros that recognizes and solves this problem:

[https://nixos.org/nixos/about.html](https://nixos.org/nixos/about.html)

A solution like theirs should become the default. Their transactional, package
management too given the number of times my Linux packages got broken by some
ridiculous crap. That even a smaller outfit could knock out two problems, one
major, shows these bigger distros could be gradually knocking out such issues
themselves.

~~~
aidenn0
It's a lot more work to retroactively impose a new FS layout on an existing
distribution than to come up with a new distribution.

If e.g. Ubuntu did this then

1) They'd have to fix all of the packages in the main repository, and then
PPAs?

2) Lots of third party software targeted on Ubuntu would break; this would
cause a lot of users to want to stay on pre-change versions of Ubuntu, which
probably means it would get forked.

~~~
nickpsecurity
"They'd have to fix all of the packages in the main repository, and then
PPAs?"

The NixOS site made it look like they didn't have to do that with their
solution: just give a meta-view on what's already there for the users.

"Lots of third party software targeted on Ubuntu would break; this would cause
a lot of users to want to stay on pre-change versions of Ubuntu, which
probably means it would get forked."

This could happen with any number of changes. Might still be worth it for at
least major changes like making broken packages recoverable. I can't imagine
myself getting off Ubuntu just because package failures can't brick my system
anymore. Some developers might gripe about having to make changes but that
makes them look like assholes, not Ubuntu.

I mean, VMS had this feature in the 80's with their versioned filesystem and
transactions at app level. It's about time at least the package managers of
Linux can do same reliably for apps. At least one of them did to their credit.

------
ChuckMcM
Interesting.

First there was /bin for the things that UNIX provided and /usr/bin for the
things that users provided. Part of the system, it lived in /bin, optional? it
lives in /usr/bin.

In SunOS 4 (and BSD 4.2 as I recall) the introduction of shared libraries
meant you needed a "core" set of binaries for bootstrap and recovery which
were not dynamically linked, and so "static" bin or /sbin (and its user
equivalent /usr/sbin) came into existence. Same rules for lib. /lib for the
system tools, /usr/lib for the optional user supplied stuff.

Then networking joined the mix and often you wanted to mount a common set of
things from a network file server (saved on precious disk space) but there
were things you wanted locally, that gave use /usr/local/bin and
/usr/local/lib. Then in the great BSD <==> SVR3.2 merge AT&T insisted on
everything optional being in /opt which had a kind of logic to it. Mostly
about making packages that could be installed without risking system
permission escapes.

When Linux started getting traction it was kind of silly that they copied the
/bin, /sbin, /usr/bin, /usr/sbin stuff since your computer and you are the
only "user" (usually) so why not put everything in the same place, (good
enough for Windows right?)

File system naming was made more important by the limited permission controls
on files, user, group, and other is pretty simplistic. ACLs "fixed" that
limitation but the naming conventions were baked into people fingers.

The proliferation of places to keep your binaries lead to amazingly convoluted
search paths. And with shared libraries and shared library search paths even
more security vulnerabilities.

~~~
JdeBP
> _good enough for Windows right?_

Only in the minds of people who don't know much about Windows.

The Windows model is, after all, for globally installed individual packages to
be largely rooted at "/Program Files/%COMPANY_OR_PERSON%/%PACKAGE%/" with
"%USERPROFILE%/AppData/Local/%COMPANY_OR_PERSON%/%PACKAGE%/" as a root for
per-user data. The former dates all of the way back to Windows NT 3.5, the
latter "merely" dating back to Windows NT 4 (where it was "Application Data"
rather than "AppData").

* [https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-sho...](https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-should-i-write-program-data-instead-of-program-files/)

Unix and Linux people will recognize this as akin to NeXTSTEP's ~/Apps,
/LocalLibrary, /LocalApps, and so forth from the early 1990s; and to Daniel J.
Bernstein's /package hierarchy (for package management without the need for
conflict resolution) from the turn of the century.

* [http://cr.yp.to/slashpackage.html](http://cr.yp.to/slashpackage.html)

* [http://cr.yp.to/slashcommand.html](http://cr.yp.to/slashcommand.html)

And a few years after NeXTSTEP introduced its directory hierarchy, SunOS 5
(a.k.a. Solaris 2) introduced the System 5 Release 4 /usr merge.

------
IshKebab
I wonder what is more likely in our lifetimes - a sane Linux filesystem
layout, or viable fusion power. Honestly I'm not sure.

~~~
ploxiln
gobolinux - [http://gobolinux.org/](http://gobolinux.org/) \- has had a
completely different filesystem layout, for many years. It's languished in the
past few.

archlinux has for a couple of years symlinked /bin, /sbin, and /usr/sbin to
/usr/bin, and /lib, /lib64 to /usr/lib
[https://wiki.archlinux.org/index.php/arch_filesystem_hierarc...](https://wiki.archlinux.org/index.php/arch_filesystem_hierarchy)

If you make your own linux distro from scratch, you can get many of the open
source pieces of a linux distro to use whatever layout you want, while some
pieces do require patching and fixing ... but you do have the source :)

~~~
zanny
The problem with Gobo is that this progression never works:

New FS Layout -> User Adoption -> Profit

Because at the end of the day the layout of the filesystem is never the
selling point on any given distro. It _always_ comes down to the software -
either the amount of it, or the newness of it, and that is why people flock to
Ubuntu and Arch respectively.

It is much more prudent to argue for filesystem improvements in _those_
distros, and get them implemented there, than to fork it out. Gobo
demonstrated both the validity and the utility of the approach, but it is up
to distro makers to actually use the evidence given that the traditional Unix
layout is garbage.

------
dredmorbius
Reasons why you _still_ might want to keep / and /usr isolated:

1\. NFS mounts. Your local or initial BOOTP image has a minimal root, your
(non-root-writeable, BTW) NFS /usr has Other Stuff.

2\. Mount options. Root is often (and perhaps still _must_ be -- /etc/mtab for
example -- I've stopped closely tracking discussion to make root fully read-
only) writeable. It may also require other mount permissions, including device
files and suid. Other partitions _don 't_ require these permissions, and there
is some Principle of Least Privilege benefit to mounting such partitions
without them. /usr requires suid, but not dev, and may be nonwriteable except
for OS updates.

3\. Recovery partition. I'll frequently stash a second root partition, not
typically mounted. It has minimal tools, but enough to bootstrap the system if
the primary is hosed for whatever reason (more often myself than any other).
Without a clean / /usr split, this becomes more complicated.

~~~
majewsky
mtab is not a problem anymore. On Arch, /etc/mtab is just a symlink to
/proc/self/mounts.

As for the recovery partition, you don't need the split for that, either. Just
have a live system on the recovery partition that mounts the normal root FS.
Then you can chroot into there for recovery tasks.

~~~
dredmorbius
Right, that seemed to be the mtab solution Debian were angling toward. I think
there were some odd edge cases where it didn't behave well, though I don't
recall what those were. Perhaps the ability to specifically edit the contents
to allow fixing of fubared mounts -- almost certainly loopback or NFS, both of
which get quite twitchy at times.

I don't recall my precise thinking on a clean root vs. /usr split on the
recovery partition, though it may have avoided some confusion over binaries.
Or perhaps that you could mount the /usr partition itself independently if you
wanted, assuming primary root was hosed.

Not being able to mount a separate /usr would negate that option.

~~~
majewsky
> Not being able to mount a separate /usr would negate that option.

You can mount the root to e.g. /mnt and symlink (or bind-mount) /mnt/usr to
/usr, if that's what you need.

~~~
dredmorbius
Bind-mounting does give you some options. Still doesn't help if root's hosed.

And it _wasn 't_ an option when I'd first come up with this clever scheme.

One of my current challenges with Linux is identifying which
information/education of mine is wholly outdated. This will happen to you in
time as well....

------
Annatar
The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and
filesystem hierarchy specifications say that those locations are, and I quote,
"for third party and unbundled applications". Yet some distributions, like for
instance Debian or Ubuntu, do not even include them, precluding commercial
software vendors from ever delivering software for those operating systems
(no, an unbundled application can never be delivered into /usr, because that
is vendor's namespace, and an updated version from the vendor might very well
bring a production application down).

/opt: application payload

/etc/opt: application's configuration files

/var/opt: application's data.

For applications with more than two configuration or data files, it is a good
idea to create /etc/opt/application and /var/opt/application.

If your company is mature enough to understand what system engineering is, and
employs dedicated OS and database system engineering departments,
/opt/company, /etc/opt/company[/application], and
/var/opt/company[/application] become very practical. If this approach is
combined with delivering the application payload and configuration management
as operating system packages, one only need worry about backing up the data in
/var/opt, and that's it.

~~~
majewsky
> Yet some distributions, like for instance Debian or Ubuntu, do not even
> include them, precluding commercial software vendors from ever delivering
> software for those operating systems

What? Why should it be impossible for a third-party package to just create
/opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but
/etc/profile.d is very much standardized AFAIK.

~~~
dingaling
Indeed Adobe Reader for Linux used to land itself in /opt on Ubuntu.

The power of run-as-su installers...

~~~
Annatar
The FHS thing in Debian and Ubuntu must be relatively new, I certainly have no
recollection of it back then when we looked into delivering unbundled software
for it. And we did look for it, and we even combed through the Debian
packaging specification back then.

Whatever it might be, or has been, if Debian and Ubuntu did get /opt,
/etc/opt, and /var/opt and are now one small step closer to being System V
compliant (from which FHS stems), I for one am very glad for that.

------
josephscott
I like that FreeBSD dedicates a man page, HIER(7), on this topic -
[https://www.freebsd.org/cgi/man.cgi?query=hier](https://www.freebsd.org/cgi/man.cgi?query=hier)
\- "layout of file systems"

~~~
protomyth
The other major BSDs:

[http://man.openbsd.org/OpenBSD-
current/man7/hier.7](http://man.openbsd.org/OpenBSD-current/man7/hier.7)

[http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-
current](http://netbsd.gw.com/cgi-bin/man-cgi?hier++NetBSD-current)

[https://www.dragonflybsd.org/cgi/web-
man?command=hier&sectio...](https://www.dragonflybsd.org/cgi/web-
man?command=hier&section=7)

------
teamhappy
/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm,
ln, etc.)

/usr/{bin,sbin} is for stuff you can live without but expect to be there
(e.g., make, grep, less).

/usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh,
cmake).

Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but
don't want to install system-wide (single-file C utils that come without man
pages, stuff like that).

I'm not sure where the confusion comes from and I don't really see any
advantage in merging / and /usr. On the flip side, I do think there's value in
keeping /{bin,sbin} as small as possible (because that stuff _has to_ work).

~~~
nilved
Regarding your last sentence, why does having grep in /bin reduce the chance
of mkdir working?

~~~
teamhappy
I doesn't reduce the chance of mkdir working but it does increase the chance
of you missing a bug in the part of your source tree that needs to be rock
solid.

------
takeda
MacPorts use /opt/local :)

~~~
fit2rule
And, interestingly, HomeBrew uses /usr/local "because Apple left it for us
when they abandoned this whole mess" ..

~~~
justincormack
/use/local/bin has the big advantage that it is in the default PATH.

------
shirro
The /bin vs /usr/bin split makes perfect sense but I always thought /sbin was
superflous to happy to see it being deprecated by many distros.

I expect with the increasing moves towards app stores and sandboxing on all
platforms that the days of installing packages contents all over the
filesystem are limited and things like xdg-app are probably going to take over
with an app being mounted into the filesystem in a sandbox as it is run.

~~~
tremon
Funny. I always thought the /bin vs /sbin split made more sense than / vs
/usr. I very much prefer that my shell's autocomplete does not stop on
binaries that I have no business running as a normal user, so I like that
root-only tools are in /sbin.

------
RijilV
One outcome of this that drove me nuts back in the day on Debian system was
libpcre was installed in /usr and grep was in /bin. This meant perl regex were
not supported because the maintainers of Debian didn't want the dependency on
/usr from things in /bin, and didn't want to "bloat" / with something as
distasteful as libpcre.

------
SquareWheel
How badly would things break if we tried to "fix" this split today?

~~~
davb
Probably not too badly if we took a phased approach.

1 - Establish a new, consistent filesystem hierarchy. New code should use the
new hierarchy. Move the legacy stuff to the new hierarchy and symlink the old
locations to avoid breakage.

2 - After some time, make the legacy locations read-only. This will highlight
any non-conforming code.

3 - After even longer, delete the legacy paths.

It would maybe be even easier if we could redirect writes (I'm not too versed
in filesystem capabilities) from the legacy paths to the new ones.

~~~
arthur2e5
> Establish a new, consistent filesystem hierarchy.

systemd is kind of enforcing this already, preferring /usr (where most of the
packages go) over naked paths. This is the trend on relatively modern desktop
systems, which thankfully preserves standard fs hierarchy while mostly keeping
everything in one place. (Unfortunately there are bunches of non-desktop uses
for Linux out there.)

See also [https://freedesktop.org/wiki/Software/systemd/separate-
usr-i...](https://freedesktop.org/wiki/Software/systemd/separate-usr-is-
broken/).

> It would maybe be even easier if we could redirect writes (I'm not too
> versed in filesystem capabilities) from the legacy paths to the new ones.

Quite a few distros (and users like Rob Landley) use symlinks from /bin to
/usr/bin and the same goes for /lib. sbin is sometimes linked to bin. This
does some of the redirection.

(I am not aware of the /usr/tmp and /var/etc stuff mentioned in the message.)

> After even longer, delete the legacy paths.

Nah. Millions of scripts are writing she-bangs like #!/bin/sh and I don't
really expect to see this being changed...

Workarounds using `env` is kind of crippled since a.) it introduces an extra
level of dependency and indirection and b.) it stops the user from reliability
passing options to the interpreter (Linux only cut at the first space, with
all sorts of other *nixen doing different things with multiple spaces.)

~~~
Pxtl
Still, clutters and confuses new users. In wonder if some of the fs apis could
hide the silly/redundant directories?

~~~
yrro
I much prefer compatibility symlinks actually existing in the file system over
some complex, hidden pathname resolution override riles lurking in the kernel.
That way, Windows lies.

~~~
arthur2e5
> lurking in the kernel. That way, Windows lies.

Windows implements many overrides (e.g. "My Documents") as NTFS junctions with
some hidden (+ system?) property set. (Sometimes you will find a proper hidden
property handy, like in this case.)

Stuff like CON, NUL in non-UNC paths do hurt, though. Device files from an age
without directories....

~~~
yrro
Don't get me started on Windows' bizarre, barely-documented behaviour. Magical
filenames pointing to devices and file virtualization are bad enough... just
try to decipher whether a given registry path is what it appears, or is
redirected through yet more hidden virtualization magic some time. And we
haven't even come to the truly wondrous series of overrides that occur when
looking up names in the NT object namespace...

------
paxcoder
I want to react to the signature FUD: GPLv3 is clearly a superior copyleft
license to GPLv2 despite Linus' latently permissive opinion on the anti-
TiVoization clause.

~~~
eridius
It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you
to learn that different people value different things and have different
opinions, and so want different licenses. GPLv3 is really a pretty extreme
license that imposes a lot of restrictions that a lot of people simply don't
want. If GPLv3 does what you want, by all means use it, but don't denigrate
the choices other people make.

~~~
jordigh
I wonder if people even know what those restrictions are and how exactly the
anti-tivoisation clause works. It does not forbid anyone from running software
on tivoised devices, which is what some people seem to think it does. All that
it requires is that if you distribute the software primarily to be used on a
User Product (as GPLv3 calls it), then as part of the installation information
(which in GPLv2 used to just mean install and build scripts), you must also
provide the signing keys for the hardware.

This also does not mean that GPLv3 makes software signing impossible and that
you must forbid users from rejecting unsigned software if they so wish. It
doesn't mean that you have to distribute every secret key that you use for
signing software. It merely means that you have to give your users a way to
install software on the User Product as they see fit, if they see fit. It's up
to the user to decide to override any signing feature or not. It's very much
in spirit with GPLv2 that required installation scripts. As far as GPLv3,
hardware signing keys are just another part of installation scripts (the
actual term used in GPLv3 is "Installation Information").

[http://radar.oreilly.com/2007/03/gplv3-user-products-
clause....](http://radar.oreilly.com/2007/03/gplv3-user-products-clause.html)

[https://copyleft.org/guide/comprehensive-gpl-
guidech10.html#...](https://copyleft.org/guide/comprehensive-gpl-
guidech10.html#x13-820009.9.2)

~~~
eridius
Or to put it another way, GPLv3 mandates that your hardware be insecure
(because you cannot prevent a malicious actor from installing malicious
software on someone's device, which would normally be done by requiring all
updates to be codesigned by the manufacturer). And it's not just limited to
software that would be installed on the hardware; companies like Apple won't
even allow employees to install GPLv3 software on their work computer because
if a single piece of GPLv3-licensed code makes it into iOS, even completely
accidentally, the license demands that Apple release their root signing keys
to the world, completely destroying the security of hundreds of millions of
devices.

Also don't forget the patent stuff in GPLv3. That's not quite as scary as the
anti-TiVoization stuff, but it's still pretty significant for large companies.

~~~
gherkin0
> GPLv3 mandates that your hardware be insecure (because you cannot prevent a
> malicious actor from installing malicious software on someone's device,
> which would normally be done by requiring all updates to be codesigned by
> the manufacturer).

I think that's wrong: [http://www.gnu.org/licenses/gpl-
faq.en.html#GiveUpKeys](http://www.gnu.org/licenses/gpl-
faq.en.html#GiveUpKeys):

> I use public key cryptography to sign my code to assure its authenticity. Is
> it true that GPLv3 forces me to release my private signing keys?
> (#GiveUpKeys)

> No. The only time you would be required to release signing keys is if you
> conveyed GPLed software inside a User Product, and its hardware checked the
> software for a valid cryptographic signature before it would function. In
> that specific case, you would be required to provide anyone who owned the
> device, on demand, with the key to sign and install modified software on his
> device so that it will run. If each instance of the device uses a different
> key, then you need only give each purchaser the key for his instance.

It sounds like a manufacturer could ship a GPLv3-compliant User Product with
two signing keys: a secret one known only to the manufacturer, and a second
per-device key than can be used by the end-user to install modified software.
Such a manufacturer _wouldn 't_ be forced to disclose _their_ signing key
because the user already has access to an equivalent.

I also imagine it would be kosher for the device to provide the user the
_option_ , in the name of security, to permanently clear the second per-device
key, so only manufacturer updates can ever be installed.

> companies like Apple won't even allow employees to install GPLv3 software on
> their work computer because if a single piece of GPLv3-licensed code makes
> it into iOS, even completely accidentally, the license demands that Apple
> release their root signing keys to the world, completely destroying the
> security of hundreds of millions of devices.

If Apple is behaving that way, it's Apple's own fault, not the GPLv3's. They
could have chosen to design their software in a way that would have given them
better options if they are ever forced to comply with the GPLv3, but they
chose not to.

~~~
eridius
What you've just described is a completely insecure hardware platform. Giving
out a second private key that can still be used to install third-party updates
is just as insecure as giving out their normal private key, the only real
difference is if anyone actually looks at the code signature they can tell the
difference between third-party and first-party code. Allowing the user to lock
out that second key doesn't fix anything because 99.99% of users will never do
that, or even know it exists.

> _If Apple is behaving that way, it 's Apple's own fault, not the GPLv3's.
> They could have chosen to design their software in a way that would have
> given them better options if they are ever forced to comply with the GPLv3,
> but they chose not to._

That makes no sense. What you said is basically equivalent to "That's Apple's
fault, they could have just designed their hardware platform to be completely
insecure".

GPLv3 is fundamentally incompatible with having a secure hardware platform.
This is _absolutely_ GPLv3's fault.

~~~
dTal
>GPLv3 is fundamentally incompatible with having a secure hardware platform

That's funny because Chromebooks ship with GPLv3 code.

~~~
eridius
I'm not familiar with the security model of Chromebooks. How does it work?

~~~
dTal
Out of the box, they only accept Google OS updates. For reference, the OS is
basically Gentoo+Chrome.

If you've a mind to, you can put the Chromebook in "developer mode" with a
magic sequence of commands (requiring physical access as it's a boot
procedure). This gives you root. To protect naive users from being exploited,
a Chromebook in developer mode will display a nasty warning on boot. This
warning lingers on the screen for an annoying amount of time, accompanied by a
beep. The only way (and it's undocumented) of skipping the wait and the beep
is with Ctrl-D; pressing any other key while on this screen results in the
Chromebook being completely reset. All this is to ensure that it's virtually
impossible to run under developer mode unintentionally.

If all this gets too annoying and you want to use the Chromebook as a fully
general device, you can blow it away by replacing the bootloader. Doing this
requires disabling write-protection on the flash, which requires opening the
case.

Disclaimer: I own a Samsung ARM Chromebook. For all I know the precise details
may vary across the Chromebook line, though I believe they all work similarly.
Fuller details are here: [https://www.chromium.org/chromium-os/developer-
information-f...](https://www.chromium.org/chromium-os/developer-information-
for-chrome-os-devices/samsung-arm-chromebook)

~~~
eridius
Interesting, but from your description it sounds like if I can get my hands on
someone else's Chromebook I can still put it into developer mode and install
my own software on it, right? Sure, this mostly prevents someone from using a
Chromebook that someone else installed malicious software on, though if that
other person had time to open the case they could even get around that. But
this doesn't solve the case of I have a device with private info on it, you
get the device, and want to bypass the security measures on the device to get
at my data. Or in other words, it doesn't solve the situation seen in the
recent Apple vs FBI case.

------
rhabarba
Today I learned that /usr actually means user, not Unified System Resources.
Damn, one less thing I can nitpick about.

------
chrisamanse
I thought 'usr' stands for "Unix System Resources"?

~~~
dgemm
I think someone made that up retroactively.

------
chris_wot
Well this partially answers my question at
[https://news.ycombinator.com/item?id=11647487](https://news.ycombinator.com/item?id=11647487)

------
SFJulie
I love the quote in the signature :

GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.

