FreeBSD 中文社区
搜索 K

主题

1.4 FreeBSD 导论 ​

FreeBSD 的版本发布遵循 CURRENT → ALPHA → BETA → RC → RELEASE 的迭代周期，STABLE 分支的 ABI 则保持固定，各有明确的适用场景。

1.4.1 FreeBSD 版本概述 ​

FreeBSD 的版本管理体系包含两个开发分支（CURRENT 与 STABLE）和四个版本阶段（ALPHA → BETA → RC → RELEASE），其中 ALPHA 为创建 STABLE 分支之前的预分支快照。

具体流程：CURRENT → ALPHA → 分出 STABLE 分支 → BETA → RC → RELEASE。

RELEASE 版本经过完整的 BETA→RC 测试周期，发布后仅接受安全与稳定性修复，适用于生产环境。

FreeBSD 版本更迭

注意

该图展示的版本更迭关系较为简化，实际流程中 X.0-RELEASE 来自 X-STABLE 分支，而 X-STABLE 直接由 X-1.CURRENT 转化而来。

注意

只有 ALPHA、BETA、RC 和 RELEASE（且必须为一级架构）才能使用命令 freebsd-update 更新系统，其余版本需通过源代码编译或使用二进制的 pkgbase 更新。

1.4.1.1 CURRENT 分支 ​

FreeBSD-CURRENT 是 FreeBSD 最前沿的源代码，包含正在进行的工作、实验性变更和可能出现在下一个正式版本中的过渡机制。虽然许多 FreeBSD 开发人员每天都会编译 FreeBSD-CURRENT 的源代码，但有时会出现源代码无法编译的短暂时期。这些问题会尽快得到解决，但 FreeBSD-CURRENT 所带来的究竟是灾难还是新功能，取决于同步的源代码版本。

FreeBSD-CURRENT 主要面向三个兴趣群体：

  • 积极参与某部分源代码树的 FreeBSD 社区成员。

  • 积极的测试者，他们愿意花时间解决问题，提出关于变更和 FreeBSD 整体方向的建议，并提交补丁。

  • 想要关注 FreeBSD 状态，使用当前源代码作为参考，或偶尔发表评论或贡献代码的用户。

预发布功能尚未经过充分测试，且很可能存在缺陷，FreeBSD-CURRENT 不应被视为提前获取新功能的捷径。其他提交同样有可能引入新缺陷，而不是修复既有缺陷，所以它也不是获取缺陷修复的捷径。FreeBSD-CURRENT 并未得到“正式支持”。

使用 -CURRENT 的用户应跟踪 FreeBSD-CURRENT：

  1. 加入 FreeBSD-CURRENT 邮件列表 和 源代码仓库主分支提交信息列表。这是 必需 的，以便了解人们对系统当前状态的评论，并接收有关 FreeBSD-CURRENT 当前状态的重要公告。源代码仓库主分支提交信息列表 会记录每个变更的提交日志条目，以及关于可能副作用的相关信息。

    要加入这些列表，请访问 FreeBSD 列表服务器，点击要订阅的列表，并按照说明进行操作。如果要跟踪整个源代码树的变更，而不仅是 FreeBSD-CURRENT 的变更，订阅 所有分支的源代码仓库提交信息列表。

  2. 与 FreeBSD-CURRENT 源代码同步。通常使用 git 从 FreeBSD Git 仓库的 main 分支检出 -CURRENT 代码。

  3. 由于仓库体积较大，有些用户选择仅同步他们感兴趣的部分源代码或他们正在贡献补丁的部分。但计划从源代码编译操作系统的用户必须下载 所有 的 FreeBSD-CURRENT，而不仅是选定的部分。请阅读 FreeBSD-CURRENT 邮件列表 和 /usr/src/UPDATING 以保持更新，了解有时会成为必要的启动过程。

  4. 积极参与！建议 FreeBSD-CURRENT 用户提交增强功能或缺陷修复。附带代码的方案始终受到欢迎。

1.4.1.2 STABLE 分支 ​

FreeBSD-STABLE 是用于发布主要版本的开发分支。

与一般 Linux 发行版中的“稳定版”概念不同，其名称中的“稳定”指的是该分支的 ABI（Application Binary Interface，应用程序二进制接口）保持稳定，而非指系统整体稳定性，亦可理解为“固定”。在没有充分测试的开发或测试环境中，不应将任何生产服务器更新到 FreeBSD-STABLE。应使用 FreeBSD 的最新正式版本，即 RELEASE。

CURRENT 分支中的代码在经过充分测试后（需满足 MFC 最短三天的要求，MFC 指 Merge From CURRENT，类似于 backporting 即向后移植）会推送到 STABLE 分支，但这并不保证两个分支都没有重大缺陷。尽管 FreeBSD-STABLE 分支应该始终能够编译并运行，但这并无保证。

STABLE 仍然是一个开发分支，任何时候，FreeBSD-STABLE 的源代码可能都不适合普遍使用。它只是另一条工程开发轨道，并非面向终端用户。

更多用户运行 FreeBSD-STABLE 而非 FreeBSD-CURRENT，某些在 FreeBSD-CURRENT 中未发现的缺陷和极端情况会在 FreeBSD-STABLE 中暴露，故不能盲目地跟踪 FreeBSD-STABLE。

那些希望跟踪或参与 FreeBSD 开发过程，特别是与下一个 FreeBSD 发布相关的开发者，应该考虑跟踪 FreeBSD-STABLE。

要跟踪 FreeBSD-STABLE：

  1. 加入 FreeBSD-STABLE 邮件列表，以便及时了解 FreeBSD-STABLE 中可能出现的构建依赖或其他需要特别注意的问题。开发人员在此邮件列表中也会宣布他们正在考虑的有争议的修复或更新，用户可以在此期间回应并提出意见。

    加入相关的 git 列表以跟踪所选分支。例如，跟踪 15-STABLE 分支的用户应该加入 稳定分支提交信息列表。该列表记录每个变更的提交日志条目，以及任何可能副作用的相关信息。

    要加入这些列表，请访问 FreeBSD 列表服务器，点击要订阅的列表并按照说明进行操作。如果要跟踪整个源代码树的变更，订阅 所有分支的源代码仓库提交信息列表。

  2. 安装新的 FreeBSD-STABLE 系统，可以从 FreeBSD 镜像站安装最新的 FreeBSD-STABLE 发布版本，或使用基于 FreeBSD-STABLE 的月度快照。 如果要编译或升级现有的 FreeBSD 系统到 FreeBSD-STABLE，请使用 git 检出所需分支的源代码。分支名称（如 stable/15）在 https://www.freebsd.org/releng 上列出。

  3. 在编译或升级到 FreeBSD-STABLE 之前，请仔细阅读 /usr/src/Makefile 和 FreeBSD-STABLE 邮件列表 和 /usr/src/UPDATING 以保持更新，了解有时在向下一个发布版本过渡过程中所需的其他启动过程。

1.4.2 FreeBSD 项目宗旨 ​

FreeBSD 项目的宗旨是：使 FreeBSD 的代码得到最广泛的利用，让所有人，无论其目的为何，都能从中受益。这一宗旨可概括为“只求我为人人，不求人人为我”的开放共享理念。

FreeBSD 项目的源代码中包含部分受 GNU 通用公共许可证（GPL）和 GNU 宽通用公共许可证（LGPL）许可的软件，项目正在持续努力减少其所占比重。尽管这些许可证要求开源而非闭源，但它们仍带来一定的法律挑战和额外复杂性。为充分实现 FreeBSD 的宗旨，即尽可能提供无附加条件的软件以降低商业使用中的复杂性，FreeBSD 项目在可能的情况下更倾向于采用限制更少的 BSD 许可证。

思考题

BSD 2 条款许可证摘录：“在满足以下条件的前提下，允许在源代码和二进制形式中 重新分发 和使用本软件”

“你可以继续从上游获取 BSD 授权的原始源代码，但如果你使用了基于原 BSD 衍生代码但以 GPL 再授权的版本，则仍需遵循 GPL。这形成了一条从 BSD 到 GPL 的单向通道：一旦 BSD 源代码被并入 GPL 项目，就如同进入了‘黑洞’，即 BSD 代码的 GPL 化 是不可逆的。BSD 世界逐渐被 GPL 蚕食。但事实上，BSD 代码在开源和闭源世界都得到了最大程度的复用。”

  1. 除了可以将 BSD 许可的软件转为专有软件外，还能怎样理解这种“重新分发”？在满足条件（主要是一些免责和版权声明）后，能以何种许可证再分发和重许可？

  2. 为什么自由软件基金会称 BSD 2 条许可证和 GPLv2/GPLv3 兼容？如果 BSD 许可的软件 A 进入 GPLv2 项目 B 中成为其一部分。下游用户再分发时，在何种条件下，要求软件 A 也遵守 GPLv2 而非通过 BSD 协议转为专有软件？为什么？

  3. 站在许可证的感染性角度，再理解 Linux kernel 的 GNU 化以及 FreeBSD 基本系统的去 GNU 化。

  4. 怎样理解这种代码复用目的的成功达成？

1.4.3 FreeBSD 开发模型 ​

FreeBSD 的开发模型包含存储库、基金会、社区、提交者和核心小组等。

FreeBSD 开发模型

1.4.4 什么是 FreeBSD？ ​

FreeBSD 不是 Linux，也不是 UNIX 的克隆。FreeBSD 是一种自由软件，源代码公开且可自由使用、修改和分发。

什么是 FreeBSD？

FreeBSD 一词由两部分构成，即“Free”和“BSD”。

BSD 最初由加州大学伯克利分校（University of California, Berkeley）的计算机系统研究小组（CSRG）开发，这一工作被命名为 Berkeley Software Distribution（伯克利软件发行版）。FreeBSD 等 BSD 系统都是计算机系统研究小组（CSRG）工作的延续。

Free 包含自由（Liberty）和免费（Gratis）两种含义。

FreeBSD 日为 6 月 19 日。FreeBSD 基金会和社区在这天庆祝 FreeBSD 的生日。参考文献：FreeBSD Foundation. Join us to celebrate FreeBSD Day![EB/OL]. [2026-03-26]. https://freebsdfoundation.org/freebsd-day/.

1.4.5 谁在使用 FreeBSD ​

以下是一些典型的应用案例。

谁在使用 FreeBSD

图片来源 FreeBSD 基金会宣传图。

1.4.5.1 参考文献 ​

  • FreeBSD Foundation. Read how organisations are using FreeBSD across the globe[EB/OL]. [2026-03-25]. https://freebsdfoundation.org/end-user-stories/. FreeBSD 基金会官方版本，汇集了 FreeBSD 在各领域的典型应用案例。

1.4.6 为什么选择 FreeBSD ​

1.4.6.1 一句话原因：FreeBSD 能在这流变的世界中寻求理想的中道 ​

相较于大多数主流操作系统或内核，FreeBSD 的 Kernel API/ABI 比较稳定。

FreeBSD 项目相对保守。FreeBSD 项目奉行最小惊讶原则（Principle of Least Astonishment，POLA），即设计必须符合用户的习惯、期望和心智能力。FreeBSD 配置文件和系统组件不会频繁变化，在大版本变动时尤为如此。FreeBSD 也谨慎对待破坏性变化（Breaking change），要求在大版本内保持 ABI 的稳定。

FreeBSD 不仅在生命周期内不变，大版本更新也具有连贯性和稳定性，可便捷实现大版本间的迁移。FreeBSD 上的软件版本可以滚动更新，不会锁定特定版本（如 Python 等）。

1.4.6.2 选择 FreeBSD 的一般原因 ​

  • 追求软件的稳定性与新颖性，既需具备二进制源，又需支持编译安装。除了 FreeBSD 之外难以找到这样的开源系统（Void Linux 还是算了吧）。

  • BSD 赋予了更纯粹的自由：不以限制自由来保障自由，而以信任与开放成就真正的自由。

  • FreeBSD 是学院派工程实践的成果，也是 UNIX 哲学的现代延续。

  • 其他操作系统生态愈发碎片化，而 FreeBSD 的一体化设计避免了持续的选择困境，但这并非限制，如果有需求，也可以便捷修改。

  • BSD 是一款完整的操作系统，而不是内核。内核和基本系统作为一个项目整体维护。缺乏基本系统的概念，将带来持续的混乱与违背直觉的体验。

  • FreeBSD 社区是由核心小组领导的。

  • FreeBSD 无论社区还是开发者都秉持着“慢就是快，快就是慢”的哲学思想。我们的确需要花些时间慢下来，审视自己的一切，无论知识还是自我。花些时间在路旁的花朵石子上面，也许并不是浪费时间，无所事事。

  • 教育与研究：FreeBSD 项目将内核与用户空间整合在同一个代码仓库中，极大地方便了研究和学习，且代码注释清晰丰富。可便捷地查阅特定功能的实现方式。

技巧

还可以从更多视角审视选择 FreeBSD 的原因：

  • 从佛法来说，因为缘分。万物缘起性空，有缘相聚，会者定离。万般诸相皆如此。

  • 从基督教来讲，这是主的指引。上帝在永恒的现在中创世。就像《出埃及记》一样，看上去是自己的选择，实际上都是主的安排。

  • 从黑格尔来讲，由于辩证否定。FreeBSD 是 UNIX 的直接后裔，而很多协议又脱胎于 UNIX，所以注定了要来到这里。

1.4.6.3 选择 FreeBSD 的技术原因 ​

  • FreeBSD 基本系统的配置文件与第三方软件配置文件相分离，系统级配置文件与用户配置文件相分离。FreeBSD 的文件系统层次结构遵循明确的组织原则，参见 hier(7)。再也不用到处用 find 命令查找某个 .conf 文件到底安装在哪了。
  • 由于基本系统的存在，第三方的软件几乎不影响系统的稳定性。FreeBSD 在软件更新和系统稳定之间保持了平衡。
  • 通过 BSD 的 Ports 可以编译安装软件，自由配置。
  • 不会锁定软件版本。例如 Python、GCC 等常见的系统依赖软件。但所有的 FreeBSD 都共用相同的 Ports，无论新旧系统，其第三方软件的版本都是相同的；仅极个别软件和系统版本硬捆绑，其余所有软件都可滚动更新。
  • 由于 Ports 系统的存在，旧版 FreeBSD 系统仍能正常获取并编译软件，并非在达到生命周期终点（EoL）后便无法获得软件更新。
  • 在 FreeBSD 项目中，文档不再是附属品。FreeBSD doc 项目与 src 项目是同等地位的，不分高下。
  • 可便捷地为根分区（/）配置使用 ZFS 文件系统。ZFS 被公认为功能最为完备的文件系统之一。
  • 约 2 至 3 年的版本发布周期和 4 年的维护周期（自 FreeBSD 15 起由原先的 5 年调整为 4 年）保障了 FreeBSD 的稳定性。
  • Jail 与 bhyve 虚拟化不需要额外安装和维护底层虚拟化栈，也不需要为每个实例启动完整的操作系统内核和用户空间，节约系统资源。
  • 传统的 BSD init 引导，回归简单，回归真实可见的纯文本。
  • DTrace 框架与 GEOM 存储框架。
  • Linux 二进制兼容层可运行 Linux 软件，且运行性能通常不逊色于 Linux。
  • FreeBSD 的驱动大体上与内核解耦。
  • FreeBSD 秉持人人自由开发的理念，可以直接在 GitHub 上提交代码，或者注册账号在 https://reviews.freebsd.org/ 提交大规模变更。
  • FreeBSD 的代码风格是 Kernighan & Ritchie 经典著作《The C Programming Language》（中译本：Kernighan B W, Ritchie D M. C 程序设计语言[M]. 徐宝文，李志，译. 第 2 版. 北京：机械工业出版社，2019. ISBN: 978-7-111-61794-5.）中使用的风格。

1.4.6.3.1 参考文献 ​

1.4.6.4 选择 FreeBSD 的社会意义 ​

1.4.6.4.1 红帽公司影响下的 Linux 生态偏向 ​

GNOME、Xorg（X11）、D-Bus、systemd、PulseAudio、Wayland、PipeWire 等主流 Linux 项目实际上受到红帽公司（Red Hat）的显著影响，且大多难以完全适配其他类 UNIX 操作系统。

目前 FreeBSD 桌面部件缺失，很大程度上源于对 Linux 特有函数库的强依赖，例如包含 ip 命令的 iproute2 软件包。更主要的原因则是这些桌面或部件与 systemd 存在深度捆绑或强制依赖关系，比如 NetworkManager。而 Samba 开发者则说“We use Linux, we develop for Linux, all others please submit patches”（我们使用 Linux，为 Linux 开发，其他系统的用户请自行提交补丁）。FreeBSD 社区将此类现象称为“Linuxism”（Linux 主义/Linux 偏向）。

这种行为将导致何种后果尚不得而知，但此类程序正变得越来越多，并有成为主流的趋势。许多开发者开发程序（如 todesk）时也不再考虑对传统 init 系统的兼容。Java 程序亦逐渐丧失了可移植性；由于此类捆绑问题，FreeBSD 上的 Eclipse 近两年未获更新（D'Pong P. Bug 562443 - SWT spams temp folder with innumerable folders[EB/OL]. (2020-05-26)[2026-04-05]. https://gitlab.simantics.org/simantics/eclipse/eclipse.platform.swt/-/commit/19153b908d6d4cedcbd59824686717502cfde4f7.）如果此趋势持续，可运行在 Linux 上的程序的可移植性可能进一步降低。

目前 FreeBSD 所面临的困境，未来其他系统也可能会遇到。

  • 选择 FreeBSD，即选择保留自由软件的根基。
  • 选择 FreeBSD，即选择保留一份真正自由的操作系统。能够使开源事业继续坚持下去，并践行真正的 UNIX 哲学。

1.4.6.4.2 FreeBSD 基金会重大捐赠事件 ​

上周，我向 FreeBSD 基金会捐赠了 100 万美元，FreeBSD 基金会支持着开源操作系统 FreeBSD。FreeBSD 帮助了数百万程序员追随他们的热情、实现创意。我自己就是受益者。在 90 年代末，我开始使用 FreeBSD，那时我经济拮据，住在政府提供的住房中。在某种程度上，FreeBSD 帮助我摆脱了贫困——我能进入 Yahoo!（雅虎）工作的重要原因是他们使用 FreeBSD，而这正是我首选的操作系统。多年后，当 Brian 和我开始创建 WhatsApp 时，我们依然使用 FreeBSD 来支撑我们的服务器运营，直到今天也是如此。

我发布这项捐赠的消息，是希望让更多人看到 FreeBSD 基金会所做的有益工作，并激励他人也能支持 FreeBSD。我们大家都会受益，如果 FreeBSD 能够继续为像我一样的人提供机会，帮助更多的移民子女脱贫，帮助更多的初创公司取得成功，甚至是具有变革性的成果。

——WhatsApp 原 CEO 及创始人 Jan Koum（FreeBSD Foundation. Updated! – FreeBSD Foundation Announces Generous Donation and Fundraising Milestone[EB/OL]. (2014-11-17)[2026-04-05]. https://freebsdfoundation.org/blog/updated-freebsd-foundation-announces-generous-donation-and-fundraising-milestone/.）

1.4.6.4.3 诚实与可信 ​

像 FreeBSD 这样默默地在后台工作以至于几近被用户遗忘的系统，堪称久经考验。如果每日不时出现蓝屏报错、Kernel Panic 抑或“内部错误”、You are in emergency mode、BusyBox (initramfs)、grub rescue> 等，反而能提醒用户该系统的存在。

目前，部分将 Linux 用作专用设备操作系统，或基于其他 GPL 软件构建商业产品的公司，并未严格遵守 GPL 协议发布其修改后的代码。部分国内企业对 GPL 的含义认识不足，仅将“免费”视为唯一考量。那些为规避 GPL 强制开源规定而采取规避措施的企业产品，其合规性与技术可信度均存疑。抢注开源软件商标的现象也时有发生。相较而言，采用 FreeBSD 的公司在许可证合规方面更为规范、可靠，也切实推动了 BSD 代码的广泛复用。纵然有人认为 FreeBSD 已趋衰落，事实上，大量用户可能始终受益于 FreeBSD 技术的支撑。

1.4.6.4.3.1 参考文献 ​
  • 王波. FreeBSD 在中国的未来[M]//王波. FreeBSD 使用大全. 第 2 版. 北京: 机械工业出版社, 2002: 前言. ISBN: 978-7-111-10286-1. 探讨了 FreeBSD 在中国的发展前景与应用前景。

1.4.7 FreeBSD 项目治理结构 ​

1.4.7.1 源代码存储库 ​

FreeBSD 项目历史悠久，其版本控制工具历经 CVS、SVN、Git。多年来，FreeBSD 的中央源代码树由 CVS（Concurrent Versions System）维护。CVS 免费提供源代码控制功能。随着源代码树的快速扩张和已存储历史记录的大量增加，CVS 的技术局限性日益明显，项目于 2008 年 6 月切换至 SVN（Subversion）。文档项目和 Ports 集合的存储库也分别于 2012 年 5 月和 2012 年 7 月从 CVS 迁移至 SVN。2020 年 12 月项目完成 Git 仓库转换测试，2021 年 4 月正式将源代码和文档存储库迁移至 Git，Ports 集合也同步完成迁移。目前使用 Git 进行协作开发。

FreeBSD 项目的存储库分为三个：freebsd-src（源代码）、freebsd-ports（Ports 软件移植）、freebsd-doc（文档）。三个项目地位平等。

1.4.7.2 FreeBSD 基金会 ​

FreeBSD 基金会是美国科罗拉多州博尔德的一家 501(c)(3) 非营利机构，致力于在全球范围内支持和推广 FreeBSD 项目及社区。基金会通过项目资助为软件开发提供资金，并配备专职人员即时应对紧急问题、实现新功能。基金会购买硬件以改善和维护 FreeBSD 基础设施，资助人员以提高测试覆盖率、持续集成和自动化水平。基金会通过在全球技术会议和活动中推广 FreeBSD 来为其进行宣传。基金会还提供研讨会、教育材料和演示，以招募更多用户和贡献者加入 FreeBSD。此外，基金会还代表 FreeBSD 项目执行合同、许可协议及其他需要认可法律实体的法律安排。基金会的所有权力集中在董事会，董事由现有董事会成员选举产生（新董事仅限现任董事提名），每位董事任期 1 年，可连选连任。

在大部分国家，FreeBSD 商标由 FreeBSD 基金会持有。

1.4.7.3 FreeBSD 社区 ​

FreeBSD 项目通过网络进行远程开发。

FreeBSD 社区由来自世界各地的开发者和用户组成。FreeBSD 社区并非法律实体，也无固定办事处。FreeBSD 社区不仅是英文社区，还有中文、俄语、韩语、日语等社区。

1.4.7.4 提交者 ​

提交者是指那些有权力直接写入 FreeBSD 存储库的人。如果要成为提交者，需要通过导师机制，必须由已有提交者推荐。为了防范潜在的安全风险，提交者并非终身制：对于 freebsd-src 和 freebsd-doc，提交者在 18 个月内应有一次提交；对于 freebsd-ports 则是 12 个月。非活跃提交者的权限将被暂停，但可以申请恢复。

1.4.7.5 FreeBSD 核心小组 ​

FreeBSD 核心小组是 FreeBSD 项目的最高领导机构，按章程由 9 名成员组成，采取集体领导制度，每位成员分管不同的子项目。FreeBSD 核心小组负责授予或撤销提交者权限及账户、执行行为准则（CoC）、管理项目子团队等。

FreeBSD 核心小组选举每两年举行一次，成员可以连选连任。只有在过去 12 个月内有过提交的提交者（视为活跃提交者）才拥有选举权和被选举权。活跃开发者可以表决罢免 FreeBSD 核心小组成员。此外，核心团队还负责招募新的核心团队成员，以替代离任的成员。

历史上，核心小组从未出现全体轮替的情况，一位核心小组成员在实践中通常会连任两届或更多届。核心小组成员和 FreeBSD 董事会成员往往存在交叉任职的情况。

FreeBSD 核心小组成员并不直接从中获取任何利益，均为志愿者。有些成员可能会接受 FreeBSD 基金会的雇佣或赞助来参与特定项目的开发。

1.4.8 UNIX 之船：FreeBSD 是不是 UNIX？ ​

该问题远非表面所见那般清晰明确。诸多讨论者，甚至是那段岁月的亲历者，也难以给出明确回答或澄清。有观点认为，BSD 并未进行过任何 UNIX 认证，没有持有法律上的商标便简单定论；更有甚者只是笼统地说 FreeBSD 是 UNIX 的延续者与正统继承者，仅是“有实无名”；另有观点认为，BSD 之于 UNIX，正如 Linux 之于 UNIX。

上述回答存在分歧，原因在于该问题并非可简单套用法律商标归属或代码继承性来分析的纯粹技术性难题。这牵涉到深刻的本体论哲学问题，究竟是不能两次踏进同一条河流，还是一次也不能踏进同一条河流？（类似的问题如谷堆问题、秃头问题，感兴趣的读者可参见 SEP 条目 Identity Over Time[EB/OL]. [2026-03-26]. https://plato.stanford.edu/entries/identity-time. Sorites Paradox[EB/OL]. [2026-03-26]. https://plato.stanford.edu/entries/sorites-paradox/.）。如何回答这个问题，映射着哲学观与科学技术观。

忒修斯之船

忒修斯和雅典青年安全返航所乘的是有三十支桨的大帆船，雅典人把这只船一直保存到德米特里·法勒琉斯的时代。他们一次又一次地拆掉了朽烂的旧船板，换上坚实的新船板。从此以后，这只船就成为哲学家们就事物的发展问题展开争论时经常援引的实例，一派认为它还是原来那只船，另一派争辩说它已不再是原来的船了。

  • Plutarch. 希腊罗马名人传[M]. 黄宏煦，陆永庭，吴彭鹏，译. 北京：商务印书馆，1990：23.

思考题

  1. 如果这艘船替换了若干组件，这艘船是不是忒修斯之船？

  2. 如果有一天，这艘船原有的所有组件都被完全替换了一遍，这艘船还是不是忒修斯之船？

  3. 如果将所有替换下来的组件拼凑起来，组成一艘新船，这艘船是不是忒修斯之船？

BSD 操作系统并非复制品，而是 AT&T Research Unix 操作系统的开源衍生版本，与现代 UNIX® System V 同为 UNIX 的两大主要分支。在 4.4BSD 以前，BSD 全称为 BSD UNIX。

UNIX 之船：FreeBSD 是不是 UNIX？

最初，UNIX 是 AT&T 开发的操作系统。在 20 世纪 70 年代末，加州大学伯克利分校的计算机系统研究小组（CSRG）开始深入研究 UNIX，并为其开发了大量用户空间的程序，形成了新系统 BSD（Berkeley Software Distribution, 伯克利软件发行版）。随着时间推移，BSD 系统逐渐发展，加入了许多创新，比如实现了 TCP/IP 协议栈。到了 90 年代初，CSRG 开始重新实现 AT&T 专有代码，发布了 Networking Release 2（Net/2）。然而，Net/2 中仍残留少量 AT&T 代码，成为日后 USL 诉讼的导火索。直至 1994 年诉讼和解后发布的 4.4BSD-Lite，才彻底移除了所有 AT&T 代码。此后，BSD 系统分裂为多个项目：1993 年 FreeBSD 和 NetBSD 诞生，1995 年 OpenBSD 从 NetBSD 中复刻出来，2003 年 DragonFly BSD 从 FreeBSD 中复刻出来。

如果查阅 FreeBSD 的源代码，还会看到早期开发者在 1982 年留下的注释和版权声明：

C
/*-
 * SPDX-License-Identifier: BSD-3-Clause
 *
 * Copyright (c) 1982, 1986, 1993
 *	The Regents of the University of California.  All rights reserved.

 ……以下省略许可证原文……

 */

上面这段版权声明出自源代码文件 sys/sys/_timespec.h。

思考题

如何理解 FreeBSD 与 UNIX 的关系？

1.4.9 FreeBSD 当前的技术局限性 ​

FreeBSD 具有诸多优势，但也面临着现实的挑战。

  • 大型技术企业对 FreeBSD 支持不足，如未提供 GitHub Actions 原生支持，NVIDIA CUDA 亦未予支持，在 AI 与 LLM 时代存在滞后。
  • FreeBSD 项目缺乏对欧洲和北美以外地区的关注与投入。
  • 相比其他开源项目中“仁慈的终身独裁者”模式，集体领导在 FreeBSD 项目中并未显现出明显优势，有时甚至可能导致责任分散、效率低下的问题（即“集体行动困境”）。部分分管 FreeBSD 子项目的核心成员对项目本身的了解和关注尚有不足，面对若干问题亦难以有效决策和承担责任。
  • FreeBSD 项目整体风格偏于保守，新技术的引入往往需要数年，跨越多个大版本方能完成。通常需等待已有技术轮替一到两代后才会引入；引入后亦往往缺乏后续关注与维护开发。
  • FreeBSD 系统在部分方面尚欠现代化，缺少某些当代操作系统常见的特性。尤其是在嵌入式方面仍有较大提升空间。
  • FreeBSD 未在基本系统中提供预配置的桌面环境。
  • FreeBSD 的硬件驱动支持相对有限。
  • 关于 FreeBSD 的学习资料相对较少。
  • FreeBSD 的开发者数量较少，且对外部贡献者的反馈往往不及时。
  • FreeBSD 基金会、期刊、Bug 报告系统等对外部贡献者的反馈也常有不及时的情况。
  • FreeBSD 文档项目曾停滞多年，个人贡献者除季度报告外的提交事实上很难被接纳；src 和 Ports 项目也同样难以接纳新的个人贡献者。
  • 尚未完全支持安全启动（Secure Boot）。
  • 对 TPM 的支持有限。
  • 由于部分软件对 Linux 特有特性存在依赖（Linuxism），导致若干软件无法直接移植。
  • FreeBSD 支持的两款主要文件系统 ZFS 与 UFS，其存储空间通常只能扩大，难以直接缩小。
  • FreeBSD 在面向最终用户的上层应用生态方面有所欠缺，虚拟化技术 bhyve 也有待改进。

1.4.10 FreeBSD 重要历史节点 ​

  • 1961 年分时操作系统（Timesharing OS）

在 20 世纪 60 年代初，分时操作系统诞生了。1961 年 11 月，麻省理工学院的 Fernando Corbató 在 IBM 709 上首次演示了兼容分时系统（CTSS），即最早的分时系统之一。同期，英国曼彻斯特项目（Manchester Project in England）设计的 Atlas 计算机上也实现了 Atlas 监控程序，该系统于 1962 年 12 月正式投入运行，首次将虚拟存储器投入实际使用——虚拟存储器的概念则由德国物理学家 Fritz-Rudolf Güntsch 于 1956 年在其博士论文中率先提出（参见：Denning P J. Virtual Memory[J]. ACM Computing Surveys, 1970, 2(3): 153-189）。在那个时代，分时共享系统意味着两个人共用同一台计算机，通常需要安排一张小时时间表来规划他们使用计算机的时间。

  • 1964 年 MULTICS（多路复用 信息和计算服务）

Multics 最初的规划与开发始于 1964 年，地点位于马萨诸塞州的剑桥市。一开始，Multics 是由麻省理工学院（Fernando Corbató 领导的 MAC 项目）主导的项目；1965 年，通用电气公司和贝尔实验室加入，形成三方合作。Multics 在专为操作系统设计的通用电气 645 计算机上开发；首个完整的系统于 1967 年 1 月交付给麻省理工学院。

  • 1969 年 UNIX（UNIX 操作系统）

在贝尔实验室退出 Multics 项目前，Dennis Ritchie 和 Ken Thompson 已经意识到了 Multics 的潜力。1969 年，Ken Thompson 在一台闲置的 PDP-7 计算机上着手开发一款名为 Unics（Uniplexed Information and Computing Service，非复用 信息和计算服务）的新程序。随后在 1971 年，他们以开发文字处理系统的名义从贝尔实验室法务部门获得资金，购买了一台 PDP-11/20 计算机，将 Unics 移植到了这台性能更强的机器上。

  • 1973 年 UNIX 代码迁移到 C 语言

Dennis Ritchie 决定为 UNIX 开发一种高级语言，使其语句能编译成少数几条机器指令。这促使他开发了 C 编程语言。1973 年夏天，第四版研究 UNIX（Research Unix V4）使用 C 语言重写了内核（Thompson 曾在 1972 年做过尝试但放弃了）。这令 UNIX 具备了可移植性，从而改写了操作系统的历史。

  • 1974 年加州大学伯克利分校引入 UNIX

1974 年，加州大学伯克利分校的 Bob Fabry 教授从 AT&T 获得了 UNIX 的源代码许可证。Bob Fabry 此前在 1973 年的国际计算机学会（Association for Computing Machinery，ACM）操作系统原理研讨会上见过 UNIX 第 4 版，并有意引入加州大学伯克利分校。该校的计算机系统研究小组（CSRG）开始修改和改进 AT&T Research Unix，并将修改后的版本称为“BSD Unix”或“BSD”。

  • 1978 年 3 月 9 日 1BSD 发布

基于 UNIX 创建的伯克利软件发行版（1BSD）是 UNIX 第六版的一种附加组件，而非独立完整的操作系统。此版本发行了大约 30 份。

  • 1979 年 5 月 10 日 2BSD 发布

第二款伯克利软件发行版（2BSD）发布于 1979 年 5 月。涉及 1BSD 的软件更新，以及由 Bill Joy 新开发的两个至今仍在 UNIX 系统上使用的程序：vi 文本编辑器（ex 的可视化版本）和 Csh。2BSD 是 Bill Joy 参与 PDP-11 相关工作的最后一个 BSD 版本，发行了约 75 份。

  • 1980 年 4 月 DARPA 的赞助

在 1980 年初，美国国防高级研究计划局（DARPA, Defense Advanced Research Projects Agency）正在寻找一种有助于军事项目的操作系统。基于 3BSD 的成功，Bob Fabry 于 1979 年秋向 DARPA 提交了提案，建议伯克利为 DARPA 社区开发 3BSD 的增强版本。1980 年 4 月，DARPA 与伯克利签订了为期 18 个月的合同，开始赞助伯克利进行相关工作。

  • 1983 年 8 月 4.2BSD 发布

在 Bill Joy 离开伯克利并与他人创建 Sun Microsystems（太阳计算机系统公司）（1982 年）之后，4.2BSD 于 1983 年 8 月正式发布，这是此后的第一个版本。该版本也首次引入了 BSD 的吉祥物：出现在 John Lasseter 的画作中，并作为 USENIX 发行的纸质手册封面。该版本发行了 1000 余份拷贝，意味着已有大量计算机在使用。

  • 1988 年 6 月 4.3BSD-Tahoe

随着开发人员逐渐淘汰老旧的 VAX 平台，4.3BSD-Tahoe 发布了针对 Power 6/32 平台（TAHOE）的版本。因为它将 BSD 中的机器相关代码同机器无关代码剥离开来，从而提高了后续系统的可移植性，这次发布颇具价值。

  • 1991 年 386BSD 和 Net/2

Keith Bostic 发起了一个项目，旨在不使用 AT&T 代码的前提下，重新实现大多数标准的 UNIX 软件。最终发布了 Networking Release 2（Net/2）——一种几乎完全可自由分发的操作系统。在 Net/2 的基础上，BSD 为英特尔 80386 架构分别移植了两个版本：由 William Jolitz 开发的免费的 386BSD、由 Berkeley Software Design（BSDi）开发的专有 BSD/386（后来更名为 BSD/OS）。386BSD 本身昙花一现，但成为不久后启动的 NetBSD 和 FreeBSD 项目的代码基础。

  • 1992 年 USL 诉讼案

BSDi 很快就陷入了与 AT&T 的 UNIX System Laboratories（USL，UNIX 系统实验室）子公司的法律纠纷中，当时 USL 是 System V 版权和 UNIX 商标的所有者。USL 对 BSDi 的诉讼于 1992 年提起，并导致对 Net/2 的分发禁令。该诉讼于 1994 年 2 月达成和解。和解条件之一是加州大学伯克利分校承认 Net/2 中有三个文件属于“受限制代码”（encumbered code），因为这些代码归 Novell 所有（Novell 此前从 AT&T 处获得了这些权利），必须删除。作为交换，Novell“认可”了 4.4BSD-Lite 发布时将声明为不受限制的代码，并强烈建议所有现有的 Net/2 用户迁移至 4.4BSD-Lite。FreeBSD 也在此列，项目被要求在 1994 年 7 月底之前停止发布基于 Net/2 的产品。根据协议条款，项目被允许在截止日期前做最后一次发布，即 FreeBSD 1.1.5.1。在 BSD 的约 18,000 个文件中，仅需删除三个文件，并对另外 70 个文件进行修改以添加 USL 的版权声明。本次和解为首个基于 4.4BSD-Lite 的 FreeBSD RELEASE 的发布铺平了道路。

  • 1993 年 6 月 FreeBSD 的创建

FreeBSD 项目起源于 1993 年初，部分是来自非官方的 386BSDPatchkit 的最后三位协调人的创意：Nate Williams，Rod Grimes 和 Jordan Hubbard。他们最初的目标是制作一个 386BSD 的中间快照，以解决一些补丁包机制无法解决的问题。该项目早期的工作名称是 386BSD 0.5 或 386BSD Interim，正体现了这一事实。386BSD 是 Bill Jolitz 开发的操作系统。当时该系统问世已将近一年，但一直被严重忽视。随着补丁包日益膨胀，臃肿不堪，他们决定通过提供 386BSD 过渡项目来帮助 Bill 走出困境。然而，在没有明确提供备选方案的情况下，Bill Jolitz 突然决定退出 386BSD 过渡项目，他们的计划被迫搁浅。三人认为，即使没有 Bill 的支持，这个项目也是值得的，因此他们采用了 David Greenman 创造的“FreeBSD”这个名字。为了改善 FreeBSD 的发行渠道，Jordan Hubbard 随后联系了 Walnut Creek CDROM。Walnut Creek CDROM 不仅支持在 CD 上发行 FreeBSD，还为此项目提供了一台工作用机和高速互联网连接。如果没有 Walnut Creek CDROM 对这一当时完全未知项目的近乎前所未有的信任，FreeBSD 很可能无法如此迅速地发展至今天的规模。1993 年 6 月 19 日，该项目正式选择了“FreeBSD”这个名字。首个 FreeBSD RELEASE（FreeBSD 1.0）发布于 1993 年 11 月，基于 4.3BSD Net/2（“Net/2”）磁带，并包含 386BSD 和自由软件基金会提供的许多组件。

  • 1994 年 8 月 FreeBSD Ports

FreeBSD 的 Ports 和软件包为用户和管理员提供了一种简便的安装应用程序的方式。Ports 现在提供了多达 34,000 个 port。它们首次现身于 1994 年，当时 Jordan Hubbard 将“port make macros”提交到 FreeBSD 的 CVS 存储库中，目的是给他的软件包安装套件 Makefile 打补丁。

  • 1994 年 11 月 22 日 IPFW

ipfirewall（IPFW）随 FreeBSD 2.0-RELEASE 引入，这种采用“首次匹配（First Match）”规则的防火墙自此成为系统的重要组成部分。ipfw 曾作为 Mac OS X 的内置防火墙而广泛使用。

  • 1998 年 5 月软更新（Soft Updates）

1998 年 5 月，FreeBSD 采用了软更新依赖跟踪系统。软更新旨在通过跟踪并强制执行元数据更新之间的依赖关系来维护文件系统元数据的完整性，防止因崩溃或断电导致损坏。

  • 1999 年 10 月 17 日首届 BSD 大会

首届 FreeBSD 大会（FreeBSDCon'99）在加利福尼亚州伯克利举行。来自世界各地的 350 多名开发者和用户参加了此次活动，标志着 FreeBSD 受欢迎度和影响力的重要里程碑。

  • 2000 年 3 月 14 日 FreeBSD Jail

FreeBSD Jail 随 2000 年初发布的 FreeBSD 4.0 引入。Jail 是一种操作系统级虚拟化机制，允许管理员将 FreeBSD 系统划分为多个独立的子系统，各子系统之间相互隔离。

  • 2000 年 3 月 28 日 FreeBSD 基金会成立

FreeBSD 基金会是一家总部位于美国的非营利组织，注册为 501(c)(3) 机构，致力于支持 FreeBSD 项目、其开发和社区。资金来自个人和企业的捐款，用于赞助开发人员进行特定活动、购买硬件和网络基础设施，并提供开发者峰会的差旅津贴。该基金会由 Justin Gibbs 等人于 2000 年 3 月 28 日创立。

  • 2000 年 7 月 27 日 kqueue(2)

kqueue(2) 是取代 select/poll 的创新解决方案，于 2000 年 7 月 27 日随着 FreeBSD 4.1-RELEASE 引入。这一可扩展的事件通知接口后来启发了 Linux 的 epoll 机制。

  • 2000 年 9 月首次核心团队选举

尽管此前已存在自我推选产生的核心团队，但首次通过选举形式组建核心团队是在 2000 年 9 月。当时任命了由 9 名成员组成的团队，自此以后每两年举行一次选举。

  • 2001 年 11 月 EuroBSDCon

EuroBSDCon 2001 于 2001 年 11 月 9 日至 11 日在英国布莱顿举行（EuroBSDCon. Short History of EuroBSDCon[EB/OL]. [2026-04-18]. https://2024.eurobsdcon.org/history.html.）。随着全球社区的不断扩大，EuroBSDCon 的目标是聚集在 BSD 操作系统家族及相关项目上工作的用户和开发者。

  • 2004 年 1 月 12 日 5.2-RELEASE

在 5.1 版本实验性支持 amd64 架构后，5.2-RELEASE 正式提供了对 amd64 的支持。amd64 成为首个被列为一级（Tier 1）架构的 64 位平台。

  • 2004 年 3 月首届 AsiaBSDCon 和 BSDCan

在 EuroBSDCon 获得成功之后，首届 AsiaBSDCon 于 2004 年 3 月 13 日至 15 日在台湾“中央研究院”举办，紧随其后的是 BSDCan，于 5 月 13 日至 16 日在加拿大渥太华举行。随着 FreeBSD 社区的不断壮大，全球范围内对以 BSD 为主题的会议需求也随之增长。

  • 2005 年谷歌编程之夏

FreeBSD 基金会在首年度的谷歌编程之夏就参与其中。谷歌编程之夏始于 2005 年，为新的开发者提供了一个机会，使其参与开源编程项目。在项目结束后，许多参与该项目的学生成为了 FreeBSD 的贡献者。

  • 2004 年 11 月 6 日 5.3-RELEASE 移植 PF

PF（Packet Filter）最初设计用于 OpenBSD，于 2003 年 3 月移植到 FreeBSD，2004 年 2 月 26 日集成到基本系统，随 5.3-RELEASE 一同发布。

  • 2004 年 11 月 6 日 Libarchive

Libarchive 最初是为 FreeBSD 5.3 开发的，随该版本一同发布。它是一种用 C 语言编写的程序库，提供对多种不同存档格式的流式访问功能。

  • 2005 年 8 月首位执行董事

Deb Goodkin 于 2005 年 8 月加入基金会，成为基金会首位雇员，后担任执行董事。她之前在数据存储设备的市场营销、销售和开发领域有着 20 余年的工作经验。

  • 2005 年 11 月 1 日新的 FreeBSD Logo

项目举行了一项 Logo 设计大赛，由 Anton K. Gural 设计的 Logo 获胜（当前仍在使用）。

  • 2007 年 jemalloc

Jason Evans 于 2004 年初开始构思 jemalloc，2005 年 9 月集成到 FreeBSD 的 libc 中，2006 年正式作为 FreeBSD 默认内存分配器投入使用（Evans J. A Scalable Concurrent malloc(3) Implementation for FreeBSD[C]//BSDCan, 2006）。该工具改进了 FreeBSD 的可扩展性和碎片化行为。

  • 2008 年 3 月 ZFS

ZFS 由 Sun Microsystems 自 2001 年起开始开发，作为一种集成了文件系统和逻辑卷管理器的系统。该系统具有良好的可扩展性，并提供强大的数据完整性保护与高效的数据压缩功能。OpenSolaris 版本的 ZFS 于 2007 年导入 FreeBSD 源代码树，随 2008 年 2 月 27 日发布的 FreeBSD 7.0-RELEASE 首次进入 FreeBSD 系统。

  • 2009 年 1 月 4 日 DTrace

Sun Microsystems 开发了 DTrace，DTrace 可用于实时调试生产系统中的内核和应用程序问题。尽管该工具最初是为 Solaris 开发的，但它随 FreeBSD 7.1-RELEASE（2009 年 1 月 4 日发布）成为 FreeBSD 的标准组成部分，FreeBSD 为 DTrace 提供了全面支持。

  • 2010 年 8 月 Capsicum

Capsicum 是一种轻量级的操作系统能力和沙盒框架，可用于应用程序沙盒化、将大型软件架构分解为隔离的组件，并限制软件漏洞的影响范围。Capsicum 最初由剑桥大学开发，并首次作为可选功能发布在 FreeBSD 9.0 中，后来成为 FreeBSD 10.0 中的默认功能。

  • 2012 年 CHERI

CHERI（Capability Hardware Enhanced RISC Instructions）项目源于 DARPA 的 CRASH/CTSRD 计划，该计划于 2010 年 9 月启动，由剑桥大学与 SRI International 合作开展，主要研究者包括 Robert N. M. Watson 等（与 Capsicum 同一研究者）。2012 年 3 月，CHERI 首篇论文在 RESoLVE'12 研讨会上发表。CHERI 将混合能力模型引入 CPU 架构领域，实现在进程地址空间内的细粒度隔离，并支持当前软件设计。

  • 2012 年 Poudriere

Poudriere 是一种通过 Jail 测试 port，并构建 FreeBSD 镜像的工具，它已纳入 Ports 中。

  • 2012 年 4 月 12 日 Clang/LLVM

LLVM 项目是一组模块化和可重用的编译程序和工具链技术。Clang 项目为 LLVM 项目提供了 C 语言前端基础设施。这些程序目前是 FreeBSD 的编译基础设施。

  • 2012 年 11 月 11 日黑客入侵

FreeBSD 项目集群检测到黑客入侵，虽然未发现明显破坏，但项目仍花费数月进行审计与还原。

  • 2013 年 2 月 28 日完成 Ports 从 CVS 到 Subversion 的迁移

Ports 集合自 2012 年 7 月起进入 CVS 与 SVN 双轨运行期，项目于 2013 年 2 月 28 日正式关闭 CVS 访问，彻底完成了向 Subversion 的过渡。此后，FreeBSD Ports 不再使用 CVS。

  • 2013 年 9 月 17 日 OpenZFS 项目启动

OpenZFS 项目衍生于 OpenSolaris。2013 年 9 月 17 日，ZFS 开源项目宣布 OpenZFS 成为 ZFS 的继任者，并创建了一个正式的社区来维持开发和支持。但此时 FreeBSD 依旧使用的是最早的 OpenSolaris ZFS。

  • 2014 年 1 月 20 日 pkg 成为默认的软件包管理器

pkg 首次出现在 9.1-RELEASE 中。在 10.0-RELEASE 中，pkg 成为默认的软件包管理器，取代了 pkg_* 等一系列命令。

  • 2014 年 1-2 月 FreeBSD 期刊创刊号

作为 FreeBSD 社区的声音，也是跟进 FreeBSD 最新发布版本和新进展的最佳途径，FreeBSD 期刊的创刊号是 2014 年 1/2 月刊，重点关注 FreeBSD 10。最初是以付费订阅模式进行发行，直至 2019 年 1 月才将 FreeBSD 期刊转为免费出版物，随后同时在基金会网站上进行刊载（同时提供了 HTML 和 PDF）。

  • 2017 年 6 月 19 日首个“FreeBSD 日”

国际 FreeBSD 日是每年一度的庆祝活动，以赞扬 FreeBSD 对技术的开创性和持续影响，并纪念其传承的价值。

  • 2018 年 FreeBSD 中文社区（CFC）成立

在千禧年代曾存在多个中文社区，但后来逐渐衰落。这些早期社区的部分核心成员虽仍活跃于 FreeBSD 项目，但已不再专注于中文社区事务，转而投身于个人事业与家庭。FreeBSD 中文社区（CFC）最早由百度贴吧 FreeBSD 吧发展而来。

  • 2021 年 4 月 6 日从 Subversion 迁移到 Git

FreeBSD 项目从 Subversion 到 Git 的迁移始于 2019 年 5 月的 DevSummit，当时成立了一个 Git 工作小组。

  • 2021 年 4 月 13 日由 OpenSolaris ZFS 切换到 OpenZFS

在 13.0-RELEASE 中，由于 OpenSolaris 的继任者 illumos 开发基本停滞，FreeBSD 将 ZFS 实现切换到了 OpenZFS。该迁移计划最早于 2018 年提出。

  • 2024 年 9 月笔记本和桌面工作组 LDWG 成立

笔记本和桌面工作组（LDWG）如其名称所示，致力于通过一系列功能改进和新增，使 FreeBSD 在个人设备上实现“开箱即用”的体验。该工作计划为期 1 至 2 年。

  • 2024 年 8 月德国主权技术基金赞助 FreeBSD 项目实施基础设施现代化

该项目的主要目标是改进基本系统、Ports 和软件包的安全工具，更新项目基础设施以加快开发速度、增强构建安全性，并降低新开发者的参与门槛。预计于 2025 年底完成。

  • 2024—2025 Alpha-Omega 审计

Alpha-Omega 项目先后审计了 FreeBSD 的 bhyve 虚拟机监视器、Capsicum 沙盒框架以及基本系统中的第三方程序，以提升 FreeBSD 项目的安全性与合规性。

  • 2025 年 12 月 2 日引入 pkgbase

历经十年岁月磨炼，FreeBSD 终于在 15.0-RELEASE 中新增了 pkgbase 安装方式，以通过软件包来管理基本系统。这种方式最初源于 TrueOS 项目。

1.4.11 FreeBSD 的读音规范 ​

FreeBSD 的正确读法是新用户普遍关注的问题。目前社区共识和普遍的读法是：/ˌfriːˌbiːɛsˈdiː/，即读作“Free（/friː/）+ B（/biː/）+ S（/ɛs/）+ D（/diː/）”，类似“福瑞/必/哎司/地”。

即先读 Free，再逐字母拼读 B、S、D。

通常不会将 BSD 或 FreeBSD 视为一个词语连读。不会读作“百思得”或“福瑞百思德”。FreeBSD 基金会在中国大陆注册商标的机构中文译名为“福瑞百思德基金会”。

1.4.11.1 参考文献 ​

1.4.12 课后习题 ​

  1. 在 QEMU 中运行 FreeBSD 1.0 版本，记录启动过程中与当代 FreeBSD 的显著差异，分析这些差异反映出的系统设计演进。
  2. 分析 FreeBSD 的提交者（Committer）机制与核心小组选举制度，选取另一个开源项目（如 Linux 内核或 OpenBSD），从治理结构、代码审查流程和决策机制三个维度展开比较。
  3. 观看纪录片《操作系统革命》（Moore J T S, 导演. 操作系统革命[V]. 美国: Seventh Art Releasing, 2002.），结合影片内容与本章所述 UNIX/BSD 历史，分析开源运动对传统软件商业模式的冲击。