FreeBSD 中文社区
搜索 K

主题

4.2 Linux 用户迁移指南 ​

Linux 与 FreeBSD 同属类 UNIX 操作系统，但二者在内核架构、包管理哲学、系统设计理念等方面存在根本差异。

4.2.1 遗失的世界 ​

许多 Linux 世界的核心概念与技术实践，最早由 BSD 系统提出并实践，包括：

  • 容器技术的原型可追溯至 FreeBSD Jail 机制；
  • 发行版概念框架；
  • Gentoo 采用的 Ports 包管理方法论，技术渊源可追溯至 BSD Ports 框架；
  • BSD 是最早的开源理念实践者之一，BSD 许可证也是历史上最早出现的自由软件许可证之一。

思考题

“一切真历史都是当代史”。

读者如何理解这句话？如何定义“真”与“非真”？

4.2.1.1 参考文献 ​

  • FreeBSD Foundation. FreeBSD: The Torchbearer of the Original Operating System Distribution[EB/OL]. [2026-04-04]. https://freebsdfoundation.org/blog/freebsd-the-torchbearer-of-the-original-operating-system-distribution/. BSD 最早提出并实践了“发行版”概念框架。
  • Linux Foundation. A Brief Look at the Roots of Linux Containers[EB/OL]. [2026-04-18]. https://www.linuxfoundation.org/blog/blog/a-brief-look-at-the-roots-of-linux-containers. 该文指出：“In 2000, FreeBSD extended chroot to FreeBSD Jails”，容器技术原型可追溯至 FreeBSD Jail。
  • Phull R, Bhatt D. Portage: Bringing Hackers' Wisdom to Science[EB/OL]. arXiv preprint arXiv:1610.02742, 2016. [2026-04-18]. https://arxiv.org/abs/1610.02742. 该论文指出：“Portage, written in Python and inspired by the ports system from FreeBSD”及“Portage is a GPLv2 package management system based on FreeBSD's ports collection”，Gentoo Portage 技术渊源可追溯至 BSD Ports。
  • FreeBSD Project. Why you should use a BSD style license for your Open Source Project[EB/OL]. [2026-04-18]. https://www.freebsd.org/doc/en/articles/bsdl-gpl/. 该文记载了 BSD 许可证自 20 世纪 70 年代末起即以源代码自由分发的方式实践开源理念，早于 1985 年的 GNU Emacs 许可证和 1989 年的 GPL。
  • Red Hat. 什么是 Linux 容器？[EB/OL]. [2026-04-04]. https://www.redhat.com/zh/topics/containers/whats-a-linux-container. 介绍 Linux 容器的基本概念与技术原理。
  • Open Source Initiative. The Open Source Definition[EB/OL]. [2026-04-17]. https://opensource.org/osd. 虽然“开源”（Open Source）一词直到 1998 年才由 Christine Peterson 正式提出，但 BSD 许可证自 20 世纪 80 年代起便以源代码自由分发的方式实践了这一理念。
  • Croce B. 历史学的理论和历史[M]. 田时纲,译. 北京: 中国社会科学出版社, 2018. 提出一切真历史都是当代史的核心命题，探讨历史认识的当代性。

4.2.2 理解 FreeBSD 的操作系统本质：并非发行版 ​

FreeBSD 是完整的操作系统，包含相互独立的两大部分：基本系统（用户空间 + 内核）和 Ports 框架。

4.2.2.1 独立自存的基本系统 ​

freebsd-src = 基本系统存储库 = 用户空间 + 内核。

FreeBSD 版本分支分为三个主要系列：

  • CURRENT：开发版，对应 main 分支；
  • STABLE：固定分支，对应 stable/15 等分支；
  • RELEASE：正式发布版本，对应 releng/15.0 等分支。

新特性首先提交到 CURRENT，根据需要回溯到 STABLE，再回溯到点版本的 RELEASE。RELEASE 大版本由 CURRENT 经由短期的 STABLE 发展而来。

pkgbase 直接由 freebsd-src 构建：

sh
# cd /usr/src # 需要预先拉取 freebsd-src 到该路径
# make -j8 buildworld # 世界即用户空间
# make -j8 buildkernel # 内核
# make -j8 packages # 构建 pkgbase 二进制包

4.2.2.2 安装第三方软件的 Ports 框架与 pkg 包管理器 ​

freebsd-ports = 第三方软件集合（单个称为 Port）= Ports 框架存储库。

Port 是若干文件的集合，由源代码包校验和、说明文件、补丁等构成，其中 Makefile 是核心。Arch 的 PKGBUILD 或 Gentoo 的 ebuild 与此类似，事实上它们衍生自 Ports 框架。

pkg 包直接由 freebsd-ports 通过 poudriere 构建系统构建而来。

freebsd-ports 的 main 分支即 latest 源，形如 2026Q1 的分支（最新的那个季度）即 quarter 分支。季度分支直接从 main 按季度切出。

默认基本系统不含任何 Port 软件，甚至不含 pkg 包管理器本体（传统安装模式）。大多数硬件固件也已从基本系统移至 Ports。

4.2.2.3 init 系统 ​

FreeBSD 使用 BSD init 而非 systemd；BSD init 与传统的 SysVinit 也有所不同，BSD 没有运行级别（runlevel），也没有 /etc/inittab，均由 rc 系统控制。

以用户进程身份运行 init，可模拟 AT&T System V UNIX 的行为：超级用户可在命令行中指定所需的运行级别，该 init 进程向原始（PID 为 1 的）init 进程发送特定信号，以执行相应操作。例如，在 FreeBSD 中执行 init 0 发送 SIGUSR1 实现停机。

4.2.2.4 Shell ​

FreeBSD 所有用户的默认 shell 均为 sh（14 之前 root 默认为 csh），而非 Bash（如有需要亦可切换）。

4.2.2.5 基本系统去 GNU 化 ​

FreeBSD 基本系统几乎不含任何与 BSD 协议不兼容的软件。

4.2.2.6 参考文献 ​

4.2.3 基本对比 ​

操作系统发布/生命周期（主要版本）主要包管理器（命令）许可证（主要）工具链Shell桌面
Ubuntu2 年/5 年（LTS 标准支持），10 年（需 Ubuntu Pro）aptGNUgccBashGNOME
Gentoo Linux滚动更新Portage（emerge）GNUgccBash可选
Arch Linux滚动更新pacmanGNUgccBash可选
RHEL3/最长 12 年RPM（yum、dnf）GNUgccBashGNOME
FreeBSD约 2/4 年（FreeBSD 14 及以前为 5 年，自 FreeBSD 15 起缩短为 4 年）pkg/PortsBSDclangsh可选

Linux 广泛使用 GNU 工具，因此理论上，凡不依赖特定 Linux 函数库者，均可在 FreeBSD 上运行。

Linux 命令/GNU 软件BSD Port/命令作用说明备注
lsusbsysutils/usbutils显示 USB 信息也可粗略使用 cat /var/run/dmesg
lspcisysutils/pciutils显示 PCI 信息也可粗略使用 cat /var/run/dmesg
lsblksysutils/lsblk显示磁盘使用情况/
freesysutils/freecolor显示内存使用情况free 命令依赖 Linux 特性（通常由 procps 包提供），因此 FreeBSD 未提供。如确实需要 free，可使用 https://github.com/j-keck/free，其他替代命令包括 vmstat
lscpusysutils/lscpu显示处理器信息/
glibcFreeBSD libcC 库/
GCCLLVM + Clang编译程序、编译链工具如有特殊需要也可以安装 devel/gcc
vimeditors/vim文本编辑器FreeBSD 的 vi 不是软链接到 vim，而是早期的 nvi
wgetftp/wget下载器系统默认的下载工具是 fetch
bashshells/bashShell系统默认的 shell 是 sh（非软链接）。可自行修改。
NetworkManagernet-mgmt/networkmgr网络连接工具NetworkManager 因其单体架构（monolithic architecture）及对 Linux 系统调用的广泛依赖而无法直接移植至 FreeBSD
lsmodkldstat列出已加载的内核模块/
stracetruss跟踪系统调用/
modprobe加载内核模块：kldload；卸载内核模块：kldunload加载内核模块、卸载内核模块/

4.2.3.1 参考文献 ​

4.2.4 FHS 与 FreeBSD 目录结构 ​

文件系统层次标准（FHS）由 Linux 基金会 Linux 标准基础工作组（Linux Standard Base, LSB）维护，定义了类 UNIX 操作系统中目录结构和目录内容的规范，当前版本为 FHS 3.0，发布于 2015 年。

FreeBSD 的目录层次由 hier(7) 定义。与 FHS 相比，FreeBSD 的目录结构存在以下差异：

项目FHSFreeBSD
/usr/local供管理员本地安装软件时使用，初始为空pkg/Ports 安装第三方软件默认路径
配置文件第三方 /etc/opt，建议使用子目录第三方 /usr/local/etc，系统 /etc
/bin、/sbin、/lib独立目录，与 /usr 分离独立目录，与 /usr 分离
/libexec可选，与 /usr/lib 二选一，存放内部二进制/ 和 /usr 下均有，系统辅助程序
/rescue未定义静态链接紧急修复工具
/srv系统提供的服务数据（ftp、www 等）未定义
/media可移动介质挂载点由 automount(8) 或 bsdisks(8) 管理
/opt必选，/opt/软件包未定义，统一用 /usr/local
/mnt临时挂载点临时挂载点
/run必选（3.0），PID 文件及 UNIX 域套接字无，沿用 /var/run
/sysLinux sysfs（§6.1.7）无，用 sysctl(8)
/procLinux procfs（§6.1.5）procfs(4) 已废弃，仅出于兼容目的保留，默认不使用
共享库/lib 关键库，/usr/lib 非关键及编程库，/lib 兼容/lib 关键库，/usr/lib 共享/ar 库，/usr/lib32
内核/ 或 /boot/boot/kernel/，备用 /boot/kernel.old/
/home可选，用户主目录用户主目录
/var/empty未定义由 sshd(8) 特权分离 chroot 使用
/nonexistent未定义无主目录账户的占位符

FHS 按可共享/不可共享、静态/可变两个维度将文件分层：/usr 可共享只读，/var 可变，根文件系统仅需满足引导、恢复、修复的最低需求。FreeBSD 遵循此原则，基本系统限定在 hier(7) 定义目录，第三方软件限定在 /usr/local。

POSIX（IEEE 1003.1）/SUS（UNIX 03）对目录结构无类似要求。POSIX.1-2008 明确删除了 /bin、/usr/bin、/lib、/usr/lib 等描述——理由是对应用程序并无用处。POSIX 仅要求 /、/dev（含 /dev/null、/dev/tty、/dev/console）、/tmp 存在，临时文件建议通过 TMPDIR 环境变量定位。FHS 仅在个别条目中注明与 POSIX 一致，其余目录规范均属 FHS 自身定义，不在 POSIX 范围内。

4.2.4.1 参考文献 ​

  • Linux Foundation. Filesystem Hierarchy Standard 3.0[EB/OL]. (2015-06-03)[2026-04-23]. https://refspecs.linuxfoundation.org/fhs.shtml. Filesystem Hierarchy Standard, 文件层次标准包含一套关于类 UNIX 操作系统文件和目录放置的要求和指南。这些指南旨在支持应用程序、系统管理工具、开发工具和脚本之间的互操作性，增强上述系统文档的一致性。

4.2.5 BSD 风格的 make/grep/sed/awk ​

4.2.5.1 make(1) 命令 ​

FreeBSD 的 make（bmake）与 GNU make（gmake）语法与内置变量差异显著。FreeBSD make 不支持 GNU make 的许多高级特性，如 $(wildcard ...) 的某些用法、条件语句语法等。FreeBSD make 使用 .include 而 GNU make 使用 include；变量赋值语法 ?=、:= 的行为也不同。在 FreeBSD 上，可安装 devel/gmake 以获得 GNU make。

4.2.5.2 sed(1) 命令 ​

FreeBSD sed 基于 4.4BSD lite sed，与 GNU sed 在正则表达式语法、一些扩展命令（如 \l、\u、\L、\U）、地址范围语法上有差异。GNU sed 支持 \w、\W、\b、\B 等字符类，而 FreeBSD sed 需要使用 [[:alnum:]] 等 POSIX 类。

与 GNU sed 最显著的差异是 -i 选项语法：FreeBSD sed 的 -i 必须有后缀参数，即使是空字符串（-i ''），最常见的跨平台兼容性问题即在于 GNU sed 的 -i 后缀是可选的（-i[SUFFIX]）。

示例：

sh
sed -i '' 's/quarterly/latest/g' /etc/pkg/FreeBSD.conf

必须提供一个空参数 ''，且不能省略。

4.2.5.3 awk(1) 命令 ​

FreeBSD 默认的 awk 是 nawk（New AWK），基于 Aho、Kernighan、Weinberger 的原始实现，与 GNU awk（gawk）有许多差异。GNU awk 有大量扩展，如：多维数组、网络操作、时间函数、length(array)、gensub()、strftime() 等，这些在 FreeBSD nawk 中不可用。在 FreeBSD 上，可安装 lang/gawk 获得 GNU awk。

4.2.5.4 grep(1) 命令 ​

FreeBSD 基本系统的 grep 是 BSD grep（基于 GNU grep 2.0 的旧版分支），与 Linux 上的 GNU grep 在正则表达式语法和选项上基本兼容；但 BSD grep 不支持 GNU grep 的 -P（Perl 正则表达式）选项，需安装 textproc/gnugrep 以获得 PCRE 支持。

4.2.6 附录：GNU/Linux 发行版比较 ​

GNU 开源运动的大规模开展与 Linux 的蓬勃发展，使多数人对开源的理解囿于 GPL 协议与 Linux 系统，对 FreeBSD 等 BSD 世界则接触较少。一些以开源为旗号的社区组织，其活动也主要围绕 Linux 领域展开，鲜有超越这一范畴的探索。

这并非说这些用户或团体有何不妥。无可指摘，“时来天地皆同力，运去英雄不自由”。李白永远无法成为盛唐的政治家，他自幼习剑道，好修仙，年少时意欲成为“十步杀一人，千里不留行”的江湖侠客；后又想成为匡扶社稷的朝廷重臣。但太白终究“剑非万人敌，文窃四海声”。操作系统的命运与时代发展的脉搏紧密相连，市场的需求也在不断塑造着今日习以为常的功能与交互模式。

思考题

心知不得语，却欲栖蓬瀛。

弯弧惧天狼，挟矢不敢张。

揽涕黄金台，呼天哭昭王。

无人贵骏骨，騄耳空腾骧。

乐毅倘再生，于今亦奔亡。

读者如何理解李白与 FreeBSD 项目及相关社区、人员在经历上的相似点。读者是否有一刻也曾感慨个人在时代面前的无力感。

本附录对比分析主流 GNU/Linux 发行版，帮助读者更全面地了解各发行版。

4.2.6.1 何以称为 GNU/Linux 发行版 ​

GNU 本身并无独立内核，而以 Linux 为其内核——GNU Hurd 是例外，目前仍在开发中。

不同的操作系统/发行版，不同的世界观。对“发行版”下一个精确而统一的定义并非易事。

思考题

如何理解“不同的操作系统/发行版，不同的世界观”这句话？

有观点指出，“看似纷繁复杂的 Linux 发行版，不过是假象。它们甚至可能缺乏自主决策权。例如，上游若采用 systemd 初始化系统，发行版通常也会跟进。否则可能无法继续使用部分第三方软件，后果即是自身遭消灭。Linux 发行版从未真正存在过。”

思考题

“Linux 发行版从未真正存在过。”这种说法固然存在一定的局限性，但它给出了一个重要启示，该如何理解？

常见的 Linux 发行版及若干基于 Linux 的国产操作系统，其维护工作的重心何在？它们通常并非文件系统、Linux 内核、GNU C 库（glibc）、systemd、桌面环境等上游项目的原始维护者，对大量第三方软件包通常以集成和适配为主。即便是包管理器和软件源，也大多基于上游工具和社区资源配置与管理。

红帽企业 Linux（Red Hat Enterprise Linux，RHEL）为长期支持与稳定性投入了大量资源。这是其区别于许多其他发行版的重要特征。RHEL 保证应用二进制接口（Application Binary Interface，ABI）和内核应用二进制接口（Kernel Application Binary Interface，kABI）的长期稳定性，提供最长可达十年的支持周期，这与许多其他发行版的支持策略存在明显差异。相关参考如下：

许多发行版并不直接维护或对上述软件和工具进行全面测试，也不一定持续编写补丁或文档。直接将修改回溯并贡献至上游的发行版相对较少，Ubuntu 是其中典型的例子。同时，即使发行版维护者有意向上游贡献代码，也因其对上游项目并无直接决策权，可能面临补丁难以获上游接受的挑战。

许多商业发行版（如 RHEL）确实向上游项目（例如 Linux 内核）贡献了大量代码，这是客观事实。然而，这并未完全解决基础工具维护资源不足的广泛问题。同时，基于提交量的分析表明，商业公司在代码贡献中占据较大比重，红帽是其中的重要贡献者之一。这反映出社区与商业组织在项目贡献与治理上的结构性变化，也揭示了开源社区对开源项目主导权的实质性转移。这一现象常以 Xorg 项目作为讨论案例，目前其维护和发展方向主要由少数核心维护者和相关组织主导，项目整体重心逐步转向 Wayland 等新的显示技术路线。商业发行版对 Linux 生态的影响并非在所有情况下都是积极的，其商业目标与部分开源项目的发展方向之间可能存在张力——在这一背景下，GPL 的制度设计产生了自我消解的效果。

思考题

严肃的商业发行版力求稳定压倒一切，要求集中式的统一管理；而大多数 Linux 基础工具都强调敏捷开发策略，稳定性往往不是最高优先级，并且这些工具的控制权是极度分散的。

商业发行版对开源项目的贡献，根本上看，是为了发展项目，还是为了彻底消灭项目？为什么？

用户看似有多种发行版可选，但在兼容性、依赖和生态约束下，实际可选择的范围远比表面所见更为有限。某些场景下，甚至毫无选择余地。用户所做的选择看似自主，但可选项往往由他人预设。大多数读者有能力、甚至已在维护自己的发行版——那么，究竟在维护什么？从技术实质看，几乎不存在可独立维护的组成部分。此乃当前生态结构所决定的现实。

思考题

自由意志和上帝的预定并不冲突。这信仰无关，是一个逻辑问题。

请读者讨论个人选择与社会生产力的制约关系。

分析：为什么看似自由的选择，其实也可能早已“预定”。

4.2.6.2 Ubuntu ​

部分用户反馈 Ubuntu 系统中会出现“内部错误（internal error）”提示。有观点认为这是 Ubuntu 对错误信息的统一提示方式。需要注意，Ubuntu 在开发过程中会阶段性引入 Debian SID（不稳定分支）的软件包，这可能导致其稳定性在特定阶段出现波动（无论普通版本还是 LTS）。例如，跨大版本或小版本升级时，部分用户反馈存在升级失败的风险——即便初始环境干净，也仍有可能发生。

以下命令可用于查询 Ubuntu 24.04 与 Debian 版本的关联信息：

bash
ykla@ykla-ubuntu:~$ cat /etc/debian_version	# 查看当前 Debian 系统的版本号
trixie/sid # trixie 即 Debian 13。在当前时间点，Debian 最新的稳定版本是 12 bookworm
ykla@ykla-ubuntu:~$ cat /etc/lsb-release	# 查看当前 Linux 发行版的详细信息
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04 LTS"

在 VMware Workstation 17 Pro 虚拟机上测试 Ubuntu 24.04 LTS 版本（发布于伦敦当地时间 2024 年 4 月 25 日），发现其整体使用体验相较于之前版本有所下降。安装过程中即出现错误提示，且后续使用中遇到了窗口显示异常、鼠标光标消失、输入框无法获取焦点等问题。安装完成后，系统在开机后频繁弹出“内部错误”提示。

Ubuntu 24.04 内部错误

Ubuntu 24.10

4.2.6.3 Fedora Linux ​

Fedora 在部分社区中存在非正式的称呼“地沟油”。

Fedora 是 Red Hat Enterprise Linux（RHEL）的上游发行版，其定位侧重于技术验证和前沿特性测试，根本目的是作为 RHEL 系统新设计和新架构的试验平台（该社区由 Red Hat（红帽）公司完全主导）。特性稳定后，会引入到 RHEL 中。

因此，稳定性并非该发行版的主要设计目标。Fedora 直接跨大版本升级的失败率较高。这意味着长期使用后，用户可能需要全新安装并重新配置环境。用户难以在该发行版上获得长期的稳定性支持。与基于 Debian 的发行版不同，由于软件依赖关系变动频繁，Fedora 不同大版本之间的软件源通常无法通用。其各版本在定位上更接近于持续迭代的开发分支。其所有版本均包含大量新特性，稳定性表现与持续集成的 nightly 版本较为接近，差异不大。其稳定性特征与滚动更新发行版有相似之处。在部分测试场景下，其稳定性表现可能不及 Ubuntu。例如，在关闭屏幕保护与锁屏休眠功能后执行长时间高负载编译任务时，Fedora 系统可能在数小时后出现界面无响应，而在相同条件下，Ubuntu 系统运行正常。

部分开源软件项目采用“社区测试，成熟后进入商业或企业级产品”的开发路径，例如 Wine 与 CrossOver。

思考题

如何看待这种始终由开源社区测试和反馈，待稳定后引入其商业产品，同时再引入新一轮待测试项目或组件的开发模式？这是否是一种形式主义的开源——即开源社区付出了实质性劳动力，但成果却遭资本攫取，社区用户得到的始终是残次品，且得不到任何报酬和荣誉。商业公司通过该模式将应承担的测试和客服等成本都转嫁给了开源社区。

近年来，Fedora 对系统资源的需求有所提升。在 VMware 虚拟机环境中，仅分配 4 GB 内存可能无法顺利完成安装，需要分配 6 GB 至 8 GB 内存才能避免安装过程停滞。

4.2.6.4 CentOS/Rocky Linux/RHEL ​

CentOS 已从原先基于 RHEL 源代码重建的稳定发行版，转变为 RHEL 的中游开发与测试分支（即 CentOS Stream），其定位与 Fedora 有相似之处。其替代品较多，其中包括华为商业发行版 EulerOS（其开源社区版为 openEuler），EulerOS 曾通过 The Open Group 的 UNIX 03 规范认证。Rocky Linux 也是其中一个替代方案。

这类系统在服务器领域被广泛部署，其特点是以牺牲软件版本的新颖度来换取稳定性，因此所包含的软件版本通常较为陈旧。同样，它们通常不支持直接跨大版本升级，并且在安全更新策略上相对保守。

4.2.6.5 Debian ​

Debian Logo，图片来自 https://www.debian.org/

Debian 的名称及 Logo 在中文语境中偶有基于谐音的非正式调侃“大便”（谐音“/ˈde.bi.ən/”）。

如果在 Debian 安装过程中设置了 root 密码，系统默认可能不会安装 sudo 工具。这一设计通常出于安全性考量。但这可能与 GNOME 等桌面环境及大多数显示管理器默认禁止 root 账户直接登录的惯例存在张力。

同时，在部分版本（如 Debian 12.6）中，虽然会安装 sudo，但创建的第一个普通用户默认未加入 sudo 组。这在实际使用中会带来不便，例如该普通用户无法直接通过 sudo 命令重启网络服务。用户需要切换到 tty 控制台登录 root 账户操作，这在一定程度上降低了图形界面（GUI）默认安装环境下的使用便利性。

sh
ykla@debian:~$ sudo su # 切换到 root 用户
[sudo]ykla 的密码：
ykla 不是 sudoers 文件。
ykla@debian:~$ id # 显示当前用户的 UID、GID 及所属组信息
uid=1000(ykla) gid=1000(ykla) 组=1000(ykla),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),111(bluetooth),113(lpadmin),116(scanner)
ykla@debian:~$ hostnamectl # 显示或设置系统主机名及相关信息
Static hostname: debian
      Icon name: computer-vm
        Chassis: vm
     Machine ID: 9b3107b788dd461f94ca93150474946e
        Boot ID: 081c39d5ac4748fa9ec0b2157c9a5beb
 Virtualization: vmware
Operating System: Debian GNU/Linux 12(bookworm)
         Kernel: Linux 6.1.0-22-amd64
   Architecture: x86-64
Hardware Vendor: VMware, Inc.
 Hardware Model: VMware Virtual Platform
Firmware Version: 6.00

上述问题在实际安装和使用过程中较为突出。例如，安装程序在配置软件源时可能不会同步更新 debian-security 源，却默认尝试联网进行系统更新（此问题在 Ubuntu 中也存在，在 Debian 高级安装中可绕过该问题），有时会导致安装失败。

另外，其网络管理工具 NetworkManager 与 systemd 的部分功能集成可能存在冲突。类似的设计在实际使用中容易引发用户困扰。

普通用户向 Debian 社区提交 Bug 报告并获取及时反馈的流程较为复杂。Debian 的 Bug 报告流程 相比一些更注重用户友好性的开源项目，对普通用户来说门槛较高。

Debian Stable 发行版的软件包策略以稳定为主，大部分软件在发布后，其主版本号在生命周期内通常不会升级，软件版本会锁定，因此应将 Stable 同时理解为“稳定”与“固定”。如果需要获取更新的软件版本，则需切换到 Testing 或 Unstable（Sid）分支，但这会牺牲系统的整体稳定性。

Debian Stable 发行版以系统稳定为特点，其软件包版本也相对较旧。在追求稳定性和软件包陈旧度方面，它与 RHEL 有相似之处。

4.2.6.6 openSUSE ​

在物理机上安装完整的 openSUSE 后，部分用户反馈系统会出现卡顿现象。相关性能问题可能与默认使用的 Btrfs 文件系统的某些特性或配置有关。在多台不同代际的英特尔平台物理机上测试，均观察到了卡顿现象。安装后短时间内可能出现系统响应迟缓的情况。因此，不同用户对其使用体验的评价可能存在分歧。有用户通过将根文件系统从 Btrfs 切换为 ext4 来规避此问题。在网络上搜索“openSUSE btrfs hang”可以发现类似反馈，表明这可能并非个别现象。

openSUSE 因其 Logo 形象，在社区中被昵称为“大蜥蜴”。

其版本号命名曾有一段趣事：为纪念英国作家道格拉斯·亚当斯在《银河系漫游指南》中提到的数字“42”（被誉为“生命、宇宙以及一切事物的终极答案”），openSUSE 将版本号从 13.x 跳跃至 42.x，随后又下调回 15.x。这造成了版本号逻辑上的问题：由于 42 大于 15，从 42.x 升级到 15.x 时，包管理器可能因 15 < 42 而误判为降级，从而拒绝操作。这种版本号跳跃再跌落现象在发行版中实属罕见。

openSUSE 有时会在稳定版的软件包中引入实验性功能，且可能没有明确的提示（参见：Bugzilla – Bug 1213157 repo http://download.opensuse.org/update/leap/15.5/oss. metadata expired[EB/OL]. [2026-03-26]. https://bugzilla.opensuse.org/show_bug.cgi?id=1213157 .）。这可能导致用户视其为软件缺陷（Bug）反馈。用户可能需要提交问题报告后，才能从维护者处得知该行为是实验性功能所致。

思考题

在严肃的商业发行版中，允许出现此类版本异动和未经用户明确批准的测试行为吗？请读者思考。

这是否可以用以论述，社区发行版仅仅是企业发行版的试验田。

openSUSE 原生的包管理器是 zypper。有用户与 Fedora 的 dnf 对比，认为 zypper 在交互响应速度或某些场景下的性能表现有待优化 比如你数数这有几个字母？，zypper 相比 dnf 存在明显的卡顿和延迟。且这两个包管理器在某些情况下存在竞争关系，参见：Bug 1213158 - Packages install failed with ndb backend[EB/OL]. [2026-03-26]. https://bugzilla.opensuse.org/show_bug.cgi?id=1213158。

4.2.6.7 Gentoo Linux ​

Gentoo 自称是“元发行版（Metadistribution）”。其传统安装方式是从源代码 编译 所有软件。虽然近年提供了官方二进制包支持，但在依赖管理方面仍有一定复杂性，且二进制包通用性极为有限。

Gentoo 包管理系统的缺点在于，若某个软件包编译失败，则无法安装，且编译失败的情况时有发生。如果系统长时间不更新，再次更新时可能会遇到复杂的 循环依赖 问题。同时，Gentoo 难以大规模标准化部署，在服务器环境中的应用也相对较少。

Gentoo 的 Portage 包管理器主要由 Python 语言编写。计算大规模软件集（如 KDE 桌面环境）的依赖时，可能会耗费较长时间。在性能有限的处理器上，此计算过程可能需要数分钟至数小时不等，性能开销较为明显。由于可能存在循环依赖等问题，依赖解析过程往往需要多次迭代计算，有时甚至无法自动解决，导致安装操作失败。随着系统中安装的软件包数量增加，包管理操作（如依赖计算）所花费的时间将呈几何增长。

Gentoo 的包管理器设计理念独特，但学习曲线较为陡峭，对普通用户而言使用门槛较高。Gentoo 的包管理器好玩但是不好用——这应该是最有趣的包管理器了。

总体而言，Gentoo 高度灵活的 USE 标记系统和从源代码编译的机制，在给予用户极大控制权的同时，也带来了较高的复杂性。依赖问题（包括循环依赖）可能影响系统稳定性，并使软件的安装、升级和卸载变得困难。

Gentoo 的高度定制化哲学要求用户投入更多精力进行系统管理和维护。

如果说 Arch Linux 可能在滚动更新中遇到问题，那么 Gentoo 则可能因为依赖冲突等问题，导致更新过程本身难以进行。如果系统长时间未更新，再次尝试更新时可能会因依赖地狱而无法继续任何软件包管理操作。复杂的 USE 标记系统，即便是经验丰富的 Gentoo 用户也需日复一日地应对这套哲学体系带来的复杂性。依赖问题的解决是 Gentoo 社区中常见的技术讨论话题。

Gentoo 哲学与 C++ 哲学有异曲同工之妙：

“C++ 是一种语言，而不是一个完整的系统。为每种应该支持的风格提供全面支持，不试图去强迫别人做什么。”

“如果工具 强迫用户 按照特定的方式操作，那么工具实际上是在与用户对抗，而非为用户服务。我们都经历过工具强加自己意愿的情况。 这是错误的，违背了 Gentoo 的哲学。”

正如世界上无人敢声称自己熟练掌握 C++ 一样，Gentoo 亦如此。自由的选择固然是人类向往的本性，但也带给人们无尽的焦虑和抑郁。

思考题

强迫自由究竟是实现自由的一种可行手段，还是一种形式主义和法西斯主义？

在此基石上，请读者再理解 GPL 许可证与 BSD 许可证。

Gentoo 平台的 Bug 跟踪与反馈流程可能对普通用户不够友好。在个别情况下，相关问题可能在较长时间后，随软件移除而标记为不再适用。其 Bug 报告平台的搜索与使用体验有待优化。有时通过外部搜索引擎（如 Google）使用“site:bugs.gentoo.org”语法进行搜索，可能比直接使用平台内置搜索更为有效。高级搜索 功能的使用也较为复杂。

4.2.6.8 Deepin/UOS/中标麒麟 ​

UOS 和 Deepin 的关系类似于 Red Hat Enterprise Linux（RHEL）与 Fedora 的关系，前者基于后者的社区版本商业化和深度定制。

Deepin 系统因部分更新包测试不充分而受到用户较多批评。有反馈称，某些存在问题的更新在推送后未及时撤回，官方仅通过发布修复教程应对。这种处理方式影响了用户体验。例如，有用户反馈在全新安装系统后立即升级，即遭遇了系统崩溃。

早期版本中，Deepin 系统在执行如复制文件等基础桌面操作时，曾出现界面卡顿或无响应的情况。

类似更新测试不充分的情况，在 UOS 系统中也有用户反馈。此类情况并非偶发，用户曾遇到 UOS 更新服务器宕机或配置错误导致客户端异常（如浏览器无限弹窗打开数十乃至上百个 UOS 主页）的情况，而官方状态通告有时不够及时。

UOS 服务器承载能力有限，因此 UOS 对镜像下载方式进行过限制，导致普通用户无法使用迅雷下载。有用户测试反馈，其下载服务器带宽有限，且某些网络运营商（如中国移动）的用户可能难以连接。

问题在于 UOS 的许多系统功能（如开发者模式激活）需要在线账户登录并与服务器交互，若服务器连接不稳定，则会直接影响这些功能的使用。从技术角度来看，通过采用更高效的镜像分发方式（如 BitTorrent），有可能改善下载体验。官方也偶尔提供了百度网盘供用户使用。这就看你是选择 100 K/s 还是 101 K/s 了……

思考题

“从技术角度来看，通过采用更高效的镜像分发方式（如 BitTorrent），有可能改善下载体验。”明明有更高效的分发方式（发生在 PCDN 投毒之前），为何难以推动技术兑现？

如何理解现代企业中，个人对企业是否存在一种虚无的责任感和职业道德？

归根结底，二者只是雇佣关系。职业道德与荣誉光环究竟是一种社会建构，还是人类文明不可或缺的精神支撑。倘若将一切拉平，反而有悖于常识。

怎样理解？

从默认配置策略也可观察到这一问题：UOS 早期版本的默认安装方案仅为系统盘分配约 20 GB 空间，日常使用中容易快速耗尽。用户通常需要自行研究如何自定义分区，往往在获取设备不久后即需重装系统。而剩下 50% 的未分配空间设计用于系统备份与还原功能，其机制更接近于完整的系统镜像恢复。若用户采用自定义分区方案，则可能失去原厂提供的系统还原功能。这是一个两难选择。后续版本虽已支持调整系统分区大小，但默认安装方案在较长时期内仍未改变。

中标麒麟系统曾因未及时修复诸如 ZIP 压缩包解压乱码等常见基础问题而受到用户批评。

对于需要离线部署的内网机器，及时安装安全补丁可能存在困难。由于 Linux 系统更新（尤其是涉及底层库时）常存在复杂的依赖关系，在内网固定版本环境中单独安装某个安全补丁，可能会遇到依赖不满足的问题。这是离线环境软件维护中普遍存在的挑战，在现有依赖管理模式下较难彻底规避。其安全漏洞公告页面的呈现格式经过多次迭代才趋于规范。

思考题

什么是 Linux 操作系统根社区？

  • 从 Linux kernel 和其他开源组件而构建，不依赖上游发行版社区

  • 采用开源社区运行模式，有大量的外部个人贡献者与企业参与

  • 被广泛认可，衍生出不同分支或下游社区

  • 与各开源组件社区沟通畅通，并持续回馈自己的能力

——white777. 深度社区全新规划：打造中国主导的桌面系统根社区！[EB/OL]. (2022-05-19)[2026-04-04]. https://bbs.deepin.org/post/237175.

① 如果一个操作系统，长得像 Debian，运行的软件也都来自 Debian，内核也一模一样，那么凭什么说它是 Ubuntu？

② 根社区的“根”到底在哪？他们究竟维护着什么“根”？他们的“根”遵循 GPL 了吗？

4.2.6.9 Arch Linux/Manjaro ​

Arch Linux 在中文社区中存在一些非正式的昵称：“邪教”和“洗发水”。这是一款以滚动更新模式著称的 Linux 发行版，因其高度的可定制性和软件的新颖度吸引了许多用户。

然而，滚动更新模式也意味着系统可能面临更高的不稳定风险。随着系统中安装的软件包数量增加，因依赖冲突或版本不兼容导致问题的概率也可能上升。有观点认为，通过仔细阅读官方更新公告可以规避多数问题。但这要求用户具备较高的主动维护意识和排查能力。

Arch Linux 的主要优势在于软件包版本非常新。但并非所有软件都如此，部分特定领域的工具包（如某些 R 语言包）可能不如其他发行版（如 FreeBSD）更新及时。Arch Linux 在技术社区中拥有很高的知名度。

Arch Linux 官方仓库（Official Repository）的软件包数量有限，用户通常需要启用 Arch 用户软件仓库（Arch User Repository，AUR）来获取更丰富的软件。而 AUR 源是未经过任何代码审查的。实际上缺乏系统性的集中审查机制：恶意或高风险脚本常被提交至其中。虽然构建过程在受限环境中执行，但无法保证生成的软件包本身是安全的。这类似于任何未经严格审核的软件来源（包括部分官方应用商店）都可能存在恶意软件。

这并非危言耸听，AUR 中确实曾存在恶意软件包。

正如 FreeBSD 开发者 Warner Losh 所说，“如今，开源项目的工作环境日益严峻，一些看似多余的步骤却往往是必要的。”

4.2.6.10 NixOS ​

首先，读者无须因 NixOS 提出的一系列术语而感到困惑，其中部分概念在实际使用中容易产生误解。

其核心理念并非简单的“OS as Code”，其包管理与配置方式在某些方面与 Node.js 的依赖管理有相似之处。它并不是什么“OS as Code”，而是“OS as Node.js”。

对于熟悉声明式配置和函数式包管理理念的用户（尤其是有 Node.js 生态经验者），该系统的使用较大多数 Linux 发行版更为简单，而不一定如部分宣传中所描述的那样晦涩难用。

本质上，NixOS 将声明式和函数式的依赖管理范式应用到了整个操作系统层面。NixOS 就是把 Node.js 做成了一款系统。

NixOS 强调可重现的系统构建。其配置文件（如 /etc/nixos/configuration.nix）、依赖锁定（如 flake.lock 文件）等机制，在理念上与 Node.js 的 package.json 和 package-lock.json 有相似之处：在某些情况下，错误提示并不能直观反映问题本身，例如将依赖缺失提示为语法错误。

  • 声明式配置：系统的所有配置集中在一个声明式文件中（如 /etc/nixos/configuration.nix），类似于 Node.js 项目中的 package.json。
  • Flakes：这是一个实验性功能，提供了更可重现的依赖管理和项目结构，其锁定文件（flake.lock）的作用类似于 package-lock.json。
  • 可重现性：基于声明的配置和锁定的依赖，可以精确地复现整个系统环境。
  • 无依赖冲突：通过为每个依赖创建独立存储路径来避免冲突。但这可能导致存储占用较大，且旧版本包需要手动清理。存在较多类似 node_modules 的冗余存储，清理成本较高。
  • 可回滚：每次系统更新（通过 nixos-rebuild switch）都会生成新的系统代际（Generation，即新的启动选项），允许用户轻松回滚到任意历史版本。切换后通常需要重启以完全生效。

Node.js 的依赖存储在 node_modules 目录，而 Nix/NixOS 的所有包则存储在 /nix/store 目录下。

与 Node.js 生态存在多个包管理器（如 npm、yarn、bun、pnpm）类似，Nix 生态中也出现了不同的工具和前端（如 Nix、NixOS with Flakes、Nix with Home Manager），带来了选择的多样性，也可能造成一定的生态碎片化。从现状看，NixOS 正在重走 Node.js 的老路。

因此，喜欢 Node.js 的人肯定很喜欢这个系统，讨厌 Node.js 的人自然也喜欢不起来 NixOS。

4.2.6.11 参考文献 ​

4.2.7 课后习题 ​

  1. 在 FreeBSD 中构建一个简单的 Port，编写 Makefile 使其能下载、编译并安装一个最小化程序，验证 Ports 框架的完整构建流程。
  2. 使用 tree 或 find 命令遍历 FreeBSD 的目录树结构，与 Ubuntu 最新 LTS 版本在 /etc、/usr、/var 三个目录的组织方式上进行对比分析。
  3. 从技术本体论角度分析：当 Linux 发行版的各组件（内核、包管理器、桌面环境等）均可独立替换时，“发行版”这一概念的同一性依据是什么？