2016 年，我们团队抛弃 Linux，前瞻性地在全美知名物流平台 PkgRun 项目中全线部署 FreeBSD 环境，距今已有整整三个年头。从发布之初的 10.3-RELEASE 一路无缝升级到当前的 12.0-RELEASE，坚如磐石的 FreeBSD 给每个人留下了深刻印象。

  • PkgRun API 开发环境
pr_api_dev: ============================================================
pr_api_dev: =====         PkgRun API dev server provision!         =====
pr_api_dev: ============================================================
pr_api_dev: Updating FreeBSD repository catalogue...
pr_api_dev: FreeBSD repository is up to date.
pr_api_dev: All repositories are up to date.
pr_api_dev: The following 18 package(s) will be affected (of 0 checked):
pr_api_dev:
pr_api_dev: New packages to be INSTALLED:
pr_api_dev: 	doas: 6.0p3
pr_api_dev: 	bash: 5.0.7
pr_api_dev: 	vim-console: 8.1.1439
pr_api_dev: 	git-lite: 2.22.0
pr_api_dev: 	htop: 2.2.0_1
pr_api_dev: 	python37: 3.7.3_1
pr_api_dev: 	postgresql11-server: 11.4
pr_api_dev: 	redis: 4.0.14
pr_api_dev: 	curl: 7.65.1
pr_api_dev: 	libnghttp2: 1.39.1
pr_api_dev: 	ca_root_nss: 3.45
pr_api_dev: 	pcre: 8.43_1
pr_api_dev: 	lsof: 4.93.2_2,8
pr_api_dev: 	readline: 8.0.0
pr_api_dev: 	libffi: 3.2.1_3
pr_api_dev: 	icu: 64.2,1
pr_api_dev: 	postgresql11-client: 11.4
pr_api_dev: 	perl5: 5.28.2
pr_api_dev:
pr_api_dev: Number of packages to be installed: 18
pr_api_dev:
pr_api_dev: The process will require 331 MiB more space.
pr_api_dev: 62 MiB to be downloaded.
  • PkgRun API 生产环境
[si@pkgrun-prod ~]$ uname -a
FreeBSD pkgrun-prod 12.0-RELEASE-p7 FreeBSD 12.0-RELEASE-p7 GENERIC  amd64
[si@pkgrun-prod ~]$ freebsd-version
12.0-RELEASE-p7

身为资深 Linux 用户和 AUR 曾经的维护者之一，虽然早在 2012 年就已经使用 Arch Linux 部署了 PkgRun 的前身「神医网」（Linux 老手应该了解用 Arch 做服务器需要怎样的运维能力），同时由于工作原因也天天与 Ubuntu 打交道（硅谷互联网行业几乎被 Ubuntu 与 Debian 垄断），但我必须要理性、客观、坚定且负责地指出，FreeBSD 才是未来绝佳的 *nix 物联网操作系统。

在可预见的 IoT 井喷期，FreeBSD 将与开源指令集 RISC-V 携手迸发出惊人的活力。

Linux 的 IoT 困境

Linux 是一个采用 GPL 许可证第二版 (GPLv2) 的操作系统内核。由于它只是一个操作系统内核，其生态系统的完善必须依靠东拼西凑。举例来讲，Ubuntu、CentOS、Arch 等发行版都是 Linux 内核 + GNU 套件（有时也会称为 “base” 或者 “userland”）+ 应用软件的组合。普通开发者以及用户所理解的「能干活」的最小系统，至少需要 Linux 内核 + GNU 套件。当然 GNU 套件理论上并不是必须，例如嵌入式领域常用 BusyBox 代替 GNU 套件，另外还有 Android 这类默认不需要 shell 交互的 Linux 发行版存在。Linux 用户可以自行脑补一下从开机引导到进入 shell，再运行几个基本命令比如 ls、cd、cat 等这套完整流程。

Linux Tux

  • 传染的 GPL 许可证

由于历史局限性，GPL 许可证在发布当年并没有覆盖云服务的使用场景，使得云服务可以合法绕过其强制开源条款向用户提供服务，间接促成了 Linux 在服务器领域的繁荣。十余年后出现了试图亡羊补牢却于事无补的 AGPL 许可证，此乃后话，按下不表。

然而，在方兴未艾的 IoT 领域，物联网设备的物理分发必要性使得采用 Linux 的嵌入式产品面临严峻的许可证问题。与云服务不同，嵌入式设备的使用场景通常会触发 GPL 的强制开源条款。尽管这个笼统的描述在法律上并不简单等同于「设备使用了 Linux 就必须开源」，但是 GPL 的传染性无疑会极大增加技术选型以及合规成本。

不谈法律细节，许可证是非常严肃的问题，忽视许可证风险将给产品和公司带来巨大的不可控因素。GPL 许可证造成的著名纠纷案例可以参考被强制开源的 Linksys WRT54G 无线路由器固件（后来发展成为 OpenWrt），在此不予赘述。

同样由于历史原因，在某些忽视版权的国家和地区，Linux 在嵌入式领域曾经大行其道。然而随着全球化进程的加深，越来越多的公司意识到版权问题的重要性。在特殊时期，知识产权陷阱更会成为遏制公司甚至是国家发展的武器。基于 Linux 的物联网设备极有可能深陷 Linksys WRT54G 那样的 GPL 合规泥潭，轻则付出合规与罚款代价，重则被强制开源并丧失商业机密，甚至遭遇全面禁售。

  • 混乱的发行模式

看似百花齐放，实际上 Linux 各发行版的区别并不大。除去技术细节，各发行版最主要的差异在于社区性质（用户数量及质量）、技术支持水平（与社区相关）以及不同偏好，例如包管理系统等。

几乎所有的 Linux 发行版都将 Linux 内核、GNU 套件以及应用软件混为一谈，也就是采用同样的包管理器管理所有组件。这三个部分本来分属若干独立团体，彼此之间并无强耦合关系，却常常被强行锁定版本捆绑在一起发布（特别是非滚动更新发行版）。与系统稳定性紧密相关的核心组件往往和应用软件享有同样的优先级，例如全部配置文件都被塞到 /etc 下，无原则混用 /usr 与 /usr/local 等。

云服务常用的 LTS (Long Term Support) 发布模式 Linux 系统中，为了「稳定性」，很多被业务重度依赖的应用软件偏偏被锁定在当前 LTS 版本发布时的低版本，并且在今后的 LTS 生命周期（一般是好几年）内得不到任何新版本更新（只会获得重要的安全更新）。这就是将所有组件混为一谈的恶果。

在实际生产环境中，为了某些应用软件只有新版本才有的新功能，运维不得不开启非官方仓库以求获得新版本支持。更有甚者不惜触犯运维大忌，干脆人为绕过包管理系统，采取自行编译并「山寨」安装的下下策。

这种一刀切的粗粒度发行模式本身就是极其不合理的奇葩设计，由此产生的各种丑陋的变通方案更是折射出 Linux 社区的精分、痛苦、纠结与挣扎。人人都不满意，人人都想要「更合理」的方案，这也是为什么 Linux 发行版层出不穷的原因。一次次重复发明轮子的行为，使得 Linux 的碎片化问题日益严重。

xkcd 927
xkcd 927

近年来兴起的容器技术（例如 Docker）可以部分看作是对以上粗粒度发行模式的反抗：既然每次吃饭都会无可避免弄脏手，我们不妨吃完饭就砍掉脏手，再等新的长出来，这样不至于因为弄脏手而把整个人埋掉。

可是，难道就没有人能体面一点使用餐具么？？？

生态高度统一的 x86 市场尚且如此艰辛，更何况是生态多样的 ARM 移动设备市场。Google 使劲浑身解数，仍然无法遏制住 Android 的碎片化趋势，这些都是历历在目的前车之鉴。可想而知，在目前几乎呈现原生态的广阔 IoT 市场，选择 Linux 就注定选择了混乱和颠沛流离。

你们听，嘤嘤嘤，那是 Linux IoT 开发者们绝望的啜泣声。

FreeBSD 的 IoT 逆袭

与东拼西凑的 Linux 发行版不同，源自 BSD 的 FreeBSD 是一套完整的操作系统。FreeBSD 可以说是正统的 Unix，比 Linux 的历史更为悠久。FreeBSD 在今天不如 Linux 流行，是因为若干年前那场 BSD 与 AT&T 的版 (sī) 权 (bī) 纠 (dà) 纷 (zhàn)。待到几年后尘埃落定，FreeBSD 也遗憾地错过了服务器市场爆发的黄金时期。

风水轮流转，在当前 IoT 市场高速发展的新时期，FreeBSD 正以全新的姿态强势回归。

FreeBSD Beastie

  • 宽松的 BSD 许可证

FreeBSD 采用的两句版 BSD 许可证不要求衍生作品开源，除了保留原始版权声明的要求之外，没有其他的限制，因此对商业使用场景来说非常友好，特别是在物联网设备的嵌入式应用场景下。

  • 严谨的发行模式

FreeBSD 内核与基本系统 (base system) 作为一个整体绑定发行（以下简称「系统」），有三个发行分支，分别为 CURRENT、STABLE 以及 RELEASE，在升级路线上也高度一致。其中 RELEASE 分支采用二进制升级方式，剩下两个分支采用源代码编译升级方式。整体发行的好处在于提高系统一致性、健壮性与稳定性。

FreeBSD 的应用软件采用独立于系统的包管理方案。还能提供同一软件的不同版本选择，不需要像非滚动更新的 Linux 发行版常见的错误做法那样粗暴地将应用软件版本与整个系统锁定。

以 Python 为例，在 FreeBSD 下不仅有 2.7，还有 3.5、3.6 和 3.7 一共四个版本：

[si@sys ~]$ pkg search python | grep Interpreted
python27-2.7.16_1              Interpreted object-oriented programming language
python35-3.5.7_2               Interpreted object-oriented programming language
python36-3.6.9                 Interpreted object-oriented programming language
python37-3.7.3_1               Interpreted object-oriented programming language

类似的，Node.js 也有 6.x、8.x、10.x 以及 12.x 这四个版本可供选择：

[si@sys ~]$ pkg search node | grep V8
node-12.4.0                    V8 JavaScript for client and server
node10-10.16.0                 V8 JavaScript for client and server
node6-6.17.1                   V8 JavaScript for client and server (6.x LTS)
node8-8.16.0                   V8 JavaScript for client and server (8.x LTS)

多版本共存的理念贯穿大多数对版本敏感的软件，比如 PHP、MariaDB、PostgreSQL 等。Linux 发行版（特别是 CentOS）如同噩梦般的软件版本问题，在 FreeBSD 下竟然完全不存在。

系统与软件的清晰隔离也体现在 FreeBSD 的文件组织结构上。例如，/usr 与 /usr/local 有严格区分，前者为系统文件路径，后者为软件文件路径，根据路径可以直观地识别出用户自行安装的部分。

不难看出，FreeBSD 这套强大的系统管理方案同时兼顾稳定性、易用性与定制性：

  1. freebsd-update: 管理内核与基本系统的二进制升级
  2. pkg: 管理使用默认参数编译好的二进制软件包
  3. Ports: 管理软件包源代码以供自定义编译

熟悉 Linux 的人也许会发现，FreeBSD 的包管理方案实际上大约等于以下两大 Linux 发行版包管理器的完美合体：

  1. Arch: pacman，对应 pkg（秉承同样 KISS 理念）
  2. Gentoo: Portage，对应 Ports（Portage 本身就是 Ports 的仿制品）

然而，Linux 发行版并没有类似 freebsd-update 那样的系统二进制升级方案。

比较而言，FreeBSD 的发行模式更类似于 Windows。FreeBSD 的版本号对应 Windows 版本号，例如 Windows XP、Windows 7、Windows 10 等；FreeBSD 的基本系统对应 Windows 默认安装（包含内置工具与程序，例如控制面板、记事本、画图等）；而 FreeBSD 的应用软件则对应 Windows 上由用户自行安装的第三方程序。

  • 低调的巨人

令人惊奇的是，与日常认知不同，FreeBSD 并不小众，在很多商业产品里都能看到 FreeBSD 的身影。以下是几个著名产品的例子：

公司产品备注
苹果 (Apple)macOS、iOS、iPadOS、tvOS、watchOS 等基于 FreeBSD
微软 (Microsoft)Windows基于 FreeBSD 与 OpenBSD（部分代码）
索尼 (Sony)CellOS (PS 3)、Orbis OS (PS 4)基于 FreeBSD 与 NetBSD
任天堂 (Nintendo)Switch基于 FreeBSD
网飞 (Netflix)Open Connect Appliance基于 FreeBSD
瞻博网络 (Juniper Networks)Junos OS基于 FreeBSD
iXsystemsFreeNAS基于 FreeBSD
NetgatepfSense基于 FreeBSD
FacebookWhatsApp 服务器运行 FreeBSD

这些产品的成功在一定程度上都归功于 FreeBSD 出色的性能以及商业友好的许可证。

FreeBSD 与 RISC-V 的 IoT 生态系统

RISC-V 是一个基于精简指令集 (RISC) 原则的开源指令集架构，与 FreeBSD 均出自美国加利福尼亚大学伯克利分校。同属 RISC 阵营的 ARM 已经在移动端处理器市场获得巨大成功，而 2010 年以 BSD 许可证开源的 RISC-V 架构，即将成为 ARM 在 IoT 领域的强有力竞争者。

RISC-V Logo

  • RISC-V 的先天优势

RISC-V 完全开放和免费。使用 RISC-V 不需要缴纳专利费，也没有硬性限制。现有的 x86、ARM 等历史架构不得不考虑向前兼容，而全新设计的 RISC-V 具有明显的后发优势，那就是没有任何历史包袱，指令集非常精简，性能也非常优秀。

历史经验证明，成熟市场最后总是呈现马太效应。需要向前兼容的历史包袱虽然对先行者来说有不少成本，但在客观上能起到护城河的作用。在传统 PC 以及服务器市场，x86 的优势地位几十年来无人能撼动，尽管这个古老的架构有很多不足之处。之后，在移动端（主要是智能手机）市场的增长阶段，ARM 开始与 x86 站在同一条起跑线上竞争，而那时 ARM 相对 x86 的优势就发挥得淋漓尽致，从而帮助 ARM 最终统治了移动端市场。

当前，RISC-V 之于 IoT 市场就类似当年的 ARM 之于移动端市场。尽管还有相当长的路要走，但 IoT 市场的井喷一定是非线性的，只有抢先布局 RISC-V IoT 生态系统，才能在即将到来的下一轮洗牌中生存下去。

  • FreeBSD 的积极态势

FreeBSD 社区积极参与 RISC-V 生态系统建设。早在 2016 年初，FreeBSD 在 RISC-V 架构上的初始移植工作就已经完成，使其成为全世界首款官方支持运行于 RISC-V 架构之上的操作系统。可以预见的是，伴随着 RISC-V 硬件的逐渐丰富，FreeBSD 也会流畅运行在越来越多的 RISC-V 上，成为 IoT 生态系统不可或缺的一员。

  • 生态系统的演进挑战

当然，一个生态系统的成功演进，一定需要足够的时间以及经过市场的检验。历史上不乏优秀产品遭遇叫好不叫座命运，最终只能湮没于时代洪流的案例。

开源软件运动近三十年的星火燎原历史告诉我们，IoT 生态系统演进的核心是开源社区的繁荣，其初期的攻关重点一定是面向开源界的工具链与软硬件平台解决方案，而这些需求仅靠几家各自打着小算盘的大公司闭门造车是不可能搞成的。

微软当年将开源软件定性为癌症，而现在不得不被迫参与开源建设，这个大转变是被开源社区一巴掌一巴掌狠狠打脸打出来的。真香。

时势造英雄，FreeBSD 已经与 RISC-V 联手吹响了进军 IoT 的号角。

你准备好了吗？