Linux /usr 目录真的不是 User 的缩写吗？
50年前的“硬件事故”产生的蝴蝶效应
当你使用 Linux 或 Unix 系统时，可能也会想过这个问题。
"到底
/usr是什么的缩写？"
乍一看，像是把 User 去掉了 e。
如果真是这样，为什么不直接写成 /user 呢？
- 只是打字不方便？
- 还是有字符长度限制？
- 但像
/boot、/home、/proc这样的四字目录也都存在。
如果真的是“用户（user）”，那就直接写 /user 了。
之所以会模糊地写成 /usr，背后隐藏着我们不知晓的历史。
今天，我们来揭开这 /usr 目录背后的故事，讲述一段 50 年前的“可笑却悲伤”的硬件趣闻，让开发者们在阅读时不禁会心一笑。
1. 结论：现在的 /usr 并不是 “User”
在当前的 Linux 文件系统标准（FHS，Filesystem Hierarchy Standard）中，/usr 被定义为：
系统全局使用、（大多）只读的程序、库、共享数据所在区域
这就是我们常见的结构：
/usr/bin– 大多数用户级可执行文件/usr/sbin– 系统管理级可执行文件/usr/lib*– 这些可执行文件使用的库/usr/share– 手册、图标、语言包等与架构无关的数据
无论从哪个角度看，/usr 与“用户个人文件”相距甚远。
主目录（~/...）以及文档、照片等都在 /home 之下。
从今天的视角，用一句话定义 /usr：
/usr= “不是 User，而是 OS 与应用的‘公共系统资源仓库’”
那问题就来了：
“那
usr不是 User 的缩写吗？”
这里就出现了趣味的转折。 最初的确是 User 的缩写，但随后 50 年的演变彻底颠覆了它的含义。
2. 早期 Unix：/usr/用户名 是主目录
让我们把时间倒回到 1970 年代初期，回到 Unix 的起源。
当时 Unix 系统中的：
- 用户的主目录不是现在的
/home/alice，而是 /usr/alice这样的形式，直接放在/usr之下。
也就是说，当时的 /usr 真正是：
“与用户相关的东西存放的目录”
那时的计算机是 PDP‑11 等设备，磁盘容量比今天小得多。 “几十 KB/MB 的容量就能让人惊叹”的时代。
- 根磁盘（
/） – 只容纳 OS 核心文件的狭窄空间 - 第二个磁盘（
/usr） – 相对宽裕的空间，用来放置用户主目录
这种结构在当时是合理的。 问题是…… Unix（以及开发者的野心）发展得太快了。
3. “磁盘满了” → 把系统文件挤进 /usr
Unix 持续增长，新的命令和功能不断加入。
问题是 根磁盘（/）的容量保持不变。
最终有一天，情况变成了：
“根磁盘已经没有空间放程序了……”
于是开发者们做出了现实的选择：
“既然第二个磁盘（
/usr）宽裕， 把不必在启动时立即使用的程序直接搬过去。”
于是，最初是“用户主目录”的 /usr，
开始慢慢被 程序、库、数据 逐步填满。
最终形成了我们今天所知的结构：
/bin– 必须在启动时使用的“最小”命令（原本在根磁盘）/usr/bin– 其余普通命令（迁移到第二个磁盘）/lib与/usr/lib也遵循相同逻辑
也就是说，
原本是用户住宅的
/usr， 由于“空间剩余”这一原因，系统文件像搬家一样被搬进去。
这就是 “磁盘容量不足导致的权宜之计”。
随后 Unix 继续发展：
- 用户主目录迁移到
/home等更直观的目录 /usr完全转变为“共享程序/库区域”
到此，情形已相当滑稽：
- 名称：
usr（user） - 实际内容：系统·应用专用文件
房主搬走了，房子里只剩下系统文件。
4. “Unix System Resources”？那是后来才造的说法
这种矛盾的情况持续了很久，后来有人开始这样说：
“现在
/usr可以叫做 Unix System Resources 的缩写。”
你可能在某些文档里见过 “/usr = Unix System Resources” 的写法。 但关键是：
这是一种 后期插入的 backronym（反向首字母缩写）， 并非最初 Unix 设计时的官方含义。
从早期 Unix 文档和证词来看：
/usr原本是 user 的缩写/usr/用户名用来放置主目录- 随着磁盘容量问题，内容从“用户相关”扩展到“用户使用的程序”再到“程序·库全体”
这更符合历史脉络。
但随着时间推移，人们把现实总结成：
“现在它是系统资源的存放地，叫做 Unix System Resources 就行。”
这就是所谓的 backronym：先有缩写，再给它一个后来的解释。
在开发者圈子里，这种现象相当常见：
- 临时的命名与结构
- 记录在文档
- 成为标准
- 最后被解释为“本来就是这样”
5. 50 年前的结构至今：Usr Merge 的故事
听到这里，你可能会想：
“如果磁盘宽裕，为什么现在还要把
/bin、/usr/bin分开？”
实际上，现代 Linux 发行版（Ubuntu、Fedora、Debian 等）正在整理这段历史遗留， 这就是 /usr merge（UsrMerge）。
在最近的发行版中，试着执行以下命令：
$ ls -l /
lrwxrwxrwx 1 root root 7 ... bin -> usr/bin
lrwxrwxrwx 1 root root 7 ... sbin -> usr/sbin
lrwxrwxrwx 1 root root 7 ... lib -> usr/lib
大多数系统都会这样。
/bin并不是实际目录，而是 指向/usr/bin的符号链接/sbin、/lib同理
也就是说，今天的实际结构是：
“大多数程序、库都在
/usr之下”
为什么要合并？原因多种多样，主要包括：
- 简化包管理/移植
- 在容器/镜像部署中，把
/usr当作一个“系统镜像”更方便 - 过去硬件限制导致的划分已不再必要
有趣的是，所有这些起点都来自：
“1970 年代，磁盘太小，程序被挤进
/usr的选择”
这正是“临时方案永远不会真正永久”的典型例子。
6. 那么今天我们如何理解 /usr？
在实际操作 Linux 系统时，记住以下划分会更方便：
“这是系统共享的程序、库、共享数据所在的区域”
相反：
- 个人文件 / 设置 →
/home/你的账号 - 经常变动的数据（日志、缓存、数据库等） →
/var - 非发行版包的手动安装应用 → 通常放在
/opt或/usr/local下
也就是说：
/usr是 OS 与应用的世界/home是 用户个人的世界
这样划分后，混淆就大大减少。
结语：一个目录名背后的开发妥协
/usr 目录里蕴藏着：
- “磁盘容量不足的早期 Unix 开发者的现实考量”
- “先这样做，后面再整理” 的常见妥协
- 以及数十年后围绕它的标准化与整理工作（UsrMerge）
与其单纯记住：
- “
/usr= Unix System Resources” - “
/usr不是用户目录”
不如了解这段历史，
在终端看到 /usr/bin、/usr/lib 时，
会有一种“这可是 50 年前硬盘满了的结果”的感悟。
“啊，原来这就是 50 年前有人因为磁盘不足而搬来的产物。”
即使是黑色终端中的一个目录，也承载着那个时代硬件极限与开发者妥协的故事， 这不正是技术史的魅力所在吗？
目前没有评论。