https://feng.si/posts/2019/06/freebsd-and-risc-v-the-future-of-open-source-iot-ecosystem/

[utterances-bot]

FreeBSD and RISC-V: The Future of Open Source IoT Ecosystem :: I can I up 🙃 — feng.si

2016 年，我们团队抛弃 Linux，前瞻性地在全美知名物流平台 PkgRun 项目中全线部署 FreeBSD 环境，距今已有整整三个年头。从发布之初的 10.3-RELEASE 一路无缝升级到当前的 12

https://feng.si/posts/2019/06/freebsd-and-risc-v-the-future-of-open-source-iot-ecosystem/

[balthild]

FreeBSD 的优点的确是实打实的，但列举的 GNU/Linux 的两大缺点却站不住脚。

1. GPL 的「传染性」是有限制的，它不会从内核态代码扩散到用户态代码，甚至在内核态代码之间也不一定会扩散。比如嵌入式上常用的 musl libc 就是 MIT License 的；Android Framework 也是一个很常见的例子。抛开立场（我个人支持激进的自由许可证）讲，业界早就总结出了大量隔离许可证的方式，因此 Linux 内核的许可证已经完全不是商业应用的阻碍。
2. 软件发行方式的混乱不是 GNU 和 Linux 的责任，因为它取决于发行商，而不是 FSF 和 LF（不过反过来说，这点本身也是 GNU/Linux 相对于 FreeBSD 的缺陷）。
3. 论点 2 的推论：IoT 业界的开发者不需要关心 GNU/Linux 的碎片化。开发者仅需要考虑适配自己 target 的硬件上运行的系统，而硬件开发商对该系统的软件发行方式有绝对的控制权，因此它的包管理机制就是确定的，不存在碎片化问题。不像 Android 应用开发者，他们无法枚举出所有可能运行自己编写的软件的场景，因为他们并不 target 某个特定的厂商的设备。
4. 软件多版本共存在 Linux 上不是什么稀奇操作，但在发行版层面上做的的确不多。目前我知道的一个叫做 Nix OS。

[floating-cat]

1. 同一软件的不同版本共存在 Linux 上已经不是什么事情了。在较低的层面，Fedora Modularity 之类的方案已经可以做到了多软件版本共存了，（Fedora 做到了，也就等于新版本的 RHEL 和 CentOS 已经可以了），再更高一点的场面，docker、Flatpak 和 Fedora Toolbox 都可以实现类似的功能。 我不太懂 IoT，不过在服务器场面从低层面考虑不同软件共存已经没人关心了，因为现在是容器化的时代了。一些桌面环境的用户可能会用到类似的功能，但是高阶的用户（包括很多开发者）用 Docker 启动 pg 之类的情况也很多了。
2. 系统和软件层面的清晰隔离也有很多 Linux 发行版本做了各种的尝试。比如说 SilverBlue、Intel's Clear Linux。比如说 SliverBlue，系统层面都是 immutable，然后传统的软件都是 layer 到上面的。这些系统很多功能都是基于更彻底的层面分离系统和软件的设计或者容器化/沙箱化做的。

其实楼主写了很多内容，只有 license 才是唯一的问题。如果 license 不是问题，Linux 就不是问题（从我的层面来看）。

[fengsi]

@floating-cat 容器化例如 Docker 的实质是共享同一个 kernel 给不同的 userland（包含基本系统及最终需要的程序，一般常用作提供单一服务的容器），因此可以做到一定程度上的与 host 发行版无关（只要 host 的 kernel 可以运行容器内的 userland 即可）。容器不好的地方是目前还是比较重（尽管相对虚拟机来说已经轻了很多），为了达到共享一个 kernel 的目的，image 里不得不包含整个 userland（相当于一个完整的只是没有 kernel 的 Linux 发行版），即使 image 可以增量制作。这个粒度仍然是很粗的，有点像本来只为了喝一杯牛奶（运行某一程序），却不得不买下整个牧场（附带整个 userland）。

容器并不是什么新东西。FreeBSD 早在 2000 年就有了 Jails 这个容器技术，只是在易用性上没有做到 Docker 那样方便，没有什么生态。常见的例如 iocage 等采用 Jails + ZFS 的方案，利用 ZFS clone 实现了和 Dockerfile 的 FROM 一样的功能（重用 base image），只不过前者直接实现在 ZFS 文件系统层面而已。

比 Docker 更轻量级的容器以及原生软件多版本共存方案具有现实意义，因为应用场景复杂，粒度不厌多。举例来说，Python 的环境，从细粒度的 virtualenv / venv，到管理多版本的 pyenv，到系统级的多版本共存（例如 FreeBSD），再到粗粒度的容器级的隔离（Docker、Jails 等）都有，每个粒度都有各自的应用场景。Node、Ruby 等也有类似的不同粒度方案。

Docker 有被滥用的趋势，一个重要原因就是天下苦秦久矣，很多 Linux 发行版根本就没有任何粒度可言，所以不管实际需要什么粒度，最后都干脆逮着一个 Docker 来提供。

Clear Linux 的方案对于长期以来 Linux 发行版混乱的系统与软件管理有积极的探索意义，希望在不久的将来可以看到更多的发行版意识到清晰隔离的重要性。

[XiaYeYue]

Windows 基于 FreeBSD 与 OpenBSD（部分代码）[来源请求]

[fengsi]

@XiaYeYue Windows 2000 / XP 有不少 .exe 文件包含 BSD 的版权声明，grep 一下就能出来。另外这里有一个讨论： https://www.neowin.net/forum/topic/381190-windows-tcpip-stack-based-on-unix/

下面这两个 Wiki 条目也有提到 Windows 使用 BSD 代码： https://en.wikipedia.org/wiki/Berkeley_Software_Distribution https://en.wikipedia.org/wiki/OpenBSD

Windows 10 使用 OpenSSH 和 LibreSSL，这两个都是 OpenBSD 的东西（LibreSSL 是 OpenSSL 的 OpenBSD fork，OpenSSH 是 OpenBSD 的原生贡献）

当然微软是不会直接承认的

[lifehz]

从Linux的起步和发展可以看出来，开源社区支持是最重要因素。而基于freebsd做的东西可以不开源，造成开源社区无法跟进。这可能是一个造成freebsd无法流行起来最大的bug。

[fsckzy]

很多年前玩的，那会FreeBSD 8刚出来。后来发现国内根本没公司招聘看重这玩意，放弃了。

[willww64]

各有优缺点吧，根据自己需求选择，多个选择是好事。 好奇博主的博客用了什么技术和什么主题，能简单介绍一下吗？我只根据 js 文件找到一个 Termynal.js 。

[fengsi]

各有优缺点吧，根据自己需求选择，多个选择是好事。 好奇博主的博客用了什么技术和什么主题，能简单介绍一下吗？我只根据 js 文件找到一个 Termynal.js 。

用 Hugo 搭的，主题是 Terminal，加自己的一些修改

[gunofmoon]

freebsd的代码也非常优美规范。不过就是核心开发者没linux那边多。最新的ebpf移植到freebsd，进度很缓慢。

[MikuMikuMe]

所以FreeBSD入门的教程有什么推荐的吗。想学学。

[tabris17]

freebsd缺硬件驱动的话真的就没法搞了

[TurnOffNOD]

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

这个不尽然，linux的升级，apt也好，yum也好，pacman也好升级的都是二进制文件，gentoo的portage才是源码编译，aur好像也是源码编译。

如果说是这种系统内核和关键组件分开升级的话，一模一样的确实没有，之后近似的：apt系的普通upgrade不升级内核，full-upgrade才升级内核；pacman是有命令行可以先升级glibc之外的包，再单独升级glibc。这个可能做的还不够，不过思路是近似的。

[panqiincs]

感谢你的文章，让我更深入了解了FreeBSD系统。

[anonsaber]

Linux 最大的问题难道不是 Linus 过世后谁又能统一 Kernel 的代码合并吗？Linux 内核的开发工作本质上是独裁的。

[TurnOffNOD]

从Linux的起步和发展可以看出来，开源社区支持是最重要因素。而基于freebsd做的东西可以不开源，造成开源社区无法跟进。这可能是一个造成freebsd无法流行起来最大的bug。

这就是为啥需要那些gpl这种激进、“传染性”的势力

[Virus-V]

如果感兴趣的话，可以关注下我的项目：https://github.com/Virus-V/freebsd-bl808