• 原文地址：FreeBSD 13.4: What’s new, and how did we get here?

• 作者：FreeBSD 基金会

• 原文发布时间： 2024 年 10 月 4 日

简介

长期以来，要寻求现代企业级开源操作系统，FreeBSD 始终是首选。FreeBSD 宽松的许可证、卓越的安全性、出色的性能和坚如磐石的稳定性使其成为各类企业和组织的不二选择。

FreeBSD 13.4-RELEASE 在基础设施、硬件兼容性和安全性方面有了重大改进，进一步证明了 FreeBSD 在业内的价值。此版本在 13.x 系列先前版本的坚实基础上进行了扩展，并与 2023 年 11 月推出的 FreeBSD 14 分支的开发时间表相一致。

FreeBSD 13.x 概览

创新的基础

FreeBSD 13.0-RELEASE 有重大改进，设定了新的系统稳健性和性能标准。包括工具链的战略性调整，全面过渡到 LLVM/Clang，使其作为默认编译器，这简化了开发过程并增强了系统稳定性。此外，作为一种现代 VPN 协议，WireGuard 显著增强了 FreeBSD 的网络安全，为 IPSec 和 OpenVPN 提供了一种更简单、快速的替代方案。

随着 13.x 系列的推进，每个版本都在用户空间和内核中引入了重要的增强功能，解决了重大的安全漏洞，并确保系统在面对不断演变的威胁时依然岿然如山。13.x 系列扩展了硬件支持和网络功能，进一步巩固了 FreeBSD 项目对适应性和前瞻性的承诺，满足了从服务器管理员到桌面用户的普遍需求。

FreeBSD 13.x 中的主要增强功能

网络改进

普通网络改进

• mbuf 类型增强： 引入了一种新类型的 mbuf，能够将多个未映射的物理页面作为一个缓冲区来表示。这一增强由 Netflix 赞助，提升了 sendfile 操作的性能，突显了 FreeBSD 对网络性能的重视。

• 安全内存回收（SMR）： 将 SMR 集成到内核中，改进了多线程环境中的内存管理，优化了系统整体性能。

增强传输层安全（TLS）

• 基于内核的 TLS： 实现了基于内核的 TLS 数据帧和加密功能，支持 TCP 套接字上的 TLS 1.0 到 1.3 版本。包括通过内核加密驱动程序进行 AES-CBC 和 AES-GCM 密码套件的发送卸载，以及 TLS 1.2 中的 AES-GCM 接收卸载。这些增强功能由 Netflix 和 Chelsio Communications 赞助，进一步强化了 FreeBSD 在安全和高效数据传输方面的承诺。

比例速率降低（PRR）

• TCP 改进： 在 TCP 中启用了 PRR 功能，以增强在突发丢包和 ACK 削减场景下的丢包恢复性能。此功能改进了丢包恢复表现，并防止了超时重传（RTO）阻塞，提供了更强大的网络体验。

路由栈重构

• 重写的路由栈： 引入了一种基于“下一个跳点”（nexthop）的新路由栈，持有所有必要的状态信息，能高效地将数据包路由到目的地。这使得路由操作更加高效和可扩展。

• 增强的多路径路由支持： 重新设计的多路径路由支持，支持 64 宽的多路径路由和 O(1) 查找时间，在多路径路由场景中显著提高了可扩展性和性能。

• 自定义路由查找算法： 支持自定义路由查找算法，将控制平面和数据平面操作解耦，从而在负载下实现更快速的查找和更好的收敛时间。

服务质量（QoS）与拥塞控制

• QoS 增强： 现在，工具 ping 能使用 IP DSCP 和以太网 PCP 设置网络服务质量（QoS），方便进行更精细的流量管理和优先级排序。 (在 FreeBSD 13.3 中引入)

• 拥塞控制算法改进： cc_cubic TCP 拥塞控制算法已更新，与 RFC 8312 中的标准更加一致，优化了 TCP 拥塞控制行为。 (在 FreeBSD 13.3 中引入)

流控制传输协议（SCTP）与高级网络功能

• SCTP 作为可加载内核模块： SCTP 支持已迁移到新的内核模块 sctp.ko，使其变为可选功能，不再默认编译进 GENERIC 内核，从而提供了更灵活的部署场景。

• 堆叠 VLAN（802.1ad）支持： 引入对堆叠 VLAN 的支持，增强了在复杂网络环境中 VLAN 配置的灵活性和可扩展性。

• 高级网络功能： 对 TCP/IP 栈的增强，如为改善 SACK 丢包恢复引入 PRR，展示了 FreeBSD 在保持网络性能和可靠性竞争力方面的承诺。

存储与虚拟化改进

存储增强

• ctld 中的网络 QoS： 工具 ctld 现在支持使用差分服务代码点和以太网优先级代码点（Ethernet PCP）设置网络 QoS，进一步提升了 FreeBSD 在高性能存储解决方案中的表现。 (在 FreeBSD 13.3 中引入)

• 更新的 NFS 支持： NFS 客户端和服务器已更新，以支持 NFSv4.2，包括扩展属性，展示了 FreeBSD 在兼容性和功能丰富性方面的持续承诺。

• 基于 TLS 的安全 NFS： FreeBSD 支持通过 TLS 配置 NFS，专注于提供安全存储解决方案。

• 迁移到 OpenZFS： ZFS 作为 FreeBSD 存储能力的基石，现在是 OpenZFS 2.1.14，确保了 FreeBSD 享受该强大文件系统的最新发展成果。

虚拟化增强

• Bhyve 中增强的虚拟机支持： 内核模块 vmm 现在支持的虚拟 CPU 可大于 16 个，使得虚拟机能够更有效地使用主机的 CPU 资源。此外，Bhyve 还引入了对 virtio-input 设备仿真的支持，通过支持将键盘和鼠标输入事件注入到虚拟机中，改善了与虚拟化环境的交互。

用户空间与内核增强

用户空间改进

• 进程管理增强： 用户现在能直接从 ~/.login_conf 设置进程优先级和 umask 值，更精细地控制进程管理和文件权限。 (在 FreeBSD 13.3 中引入)

• 报告与配置增强： 对定期输出的流线化和对 head、tail 等工具的更新，确保了参数 -q（安静模式）和 -v（详细模式）的一致性，同时采用 SI 后缀表示数值参数，提升了系统可用性和配置灵活性。 (在 FreeBSD 13.3 中引入)

• 增强的认证： libtacplus 库现在符合 POSIX shell 语法规则，提高了 TACACS+ 认证的安全性和可配置性。 (在 FreeBSD 13.3 中引入)

内核增强

• 安全性改进： 实现了针对 64 位可执行文件的地址空间布局随机化（ASLR），通过随机化内存地址空间提高安全性，可有效缓解某些类型的攻击。此外，还针对特定英特尔 CPU 的硬件页面失效问题提供了变通解决方案，强调了 FreeBSD 对安全性的重视。 (在 FreeBSD 13.3 中引入)

• 调试增强： 新的配置参数 SPLIT_KERNEL_DEBUG 能分别处理内核和模块的调试数据，优化了调试流程，而不影响系统性能。

加密框架与驱动程序更新

• libmd 提升加密多样性： 增加了对 SHA-512/224 的支持，这是一种截断版的 SHA-512 哈希函数，提供了紧凑而安全的哈希替代方案。 (在 FreeBSD 13.3 中引入)

• 全面改进的加密框架： 内核中的加密框架经过了大幅度改进，增强了对现代加密算法的支持，并简化了设备驱动程序和框架消费者的接口。废弃的算法已被移除，以提升安全性。

• 驱动程序支持增强： 将 aesni 驱动程序添加到 GENERIC 内核中，支持 AMD64 和 i386 架构，通过硬件加速的加密功能提升软件加密和安全性。

硬件支持改进

• 以太网控制器支持： 引入了驱动程序 igc，支持 Intel I225 以太网控制器，支持各种速度及高级功能，如校验和卸载和多队列操作。

• 驱动程序更新： 驱动程序 ice 已添加固件日志记录和初步的数据中心桥接（DCB）支持，进一步提升了 FreeBSD 在管理和优化网络接口方面的能力。 (在 FreeBSD 13.3 中引入)

• 处理器支持： 完善对英特尔 Alder Lake（12 代）CPU 的支持，并整合进 hwpmc 框架，以充分利用 CPU 的新特性。

13.x 中已弃用功能和删除的支持

在 FreeBSD 13.x 系列中，多个功能和支持被弃用/移除，反映了 FreeBSD 项目面向未来的理念，致力于采用现代技术和标准。

用户空间与内核更改

• 工具链现代化： 过时的 binutils 2.17 和 GCC 4.2.1 已被移除，标志着所有受支持的架构全面过渡到了 LLVM/Clang 工具链。这一变化强调了 FreeBSD 在提升系统稳定性和开发灵活性方面，致力于利用现代工具链的承诺。

• 许可证与软件更新： GPL 许可证版本的 dtc 被 BSD 许可证版本取代。此外，BSD 版本的 grep 取代了 GNU 版本。工具 bc 和 dc 被 Gavin D. Howard 开发的版本所替代，这些版本不依赖外部的大数库，并提供了 GNU bc 的扩展功能。 (在 FreeBSD 13.3 中引入)

• 弃用的工具： 像自动挂载守护进程 ctm 和 amd 等工具已被移除，现代替代工具如 autofs 已取代其功能。 (在 FreeBSD 13.3 中引入)

网络驱动弃用

• 过时的网络驱动： 一些不再使用的过时网络驱动被移除，以简化对较新和更常用硬件的支持。这使得可以更加专注于提升对现代网络接口的支持。

虚拟化弃用

• Bhyve 精细化改进： FreeBSD 对其本地虚拟化管理程序 Bhyve 进行了精细化改进，移除了已弃用的设备模型，并支持更新的功能，如 VirtIO-9p 文件系统共享和虚拟机快照。

面向未来的更改

• CPU 类型更改： i386 架构的默认 CPUTYPE 从 486 变更为 686，要求使用 686 类 CPU。这与行业标准一致，i686 已成为基准。 (在 FreeBSD 13.3 中引入)

FreeBSD 13.4-RELEASE 亮点

FreeBSD 13.4-RELEASE 是 13-STABLE 分支的最新版本。它包含了错误修复、安全补丁和更新的驱动程序，以增强用户体验和系统稳定性。

从先前版本升级

从早期版本升级的用户将发现升级过程非常顺利，升级过程有详细的文档支持。建议在进行安装前，先查阅发布说明中的勘误表，以了解任何最新的紧急问题。

安全性与 Errata

安全公告

该版本解决了若干个重要的安全漏洞：

勘误表

重要修复包括：

用户空间应用程序更改

• 性能改进： libcapsicum 已改进，缓存了更多的时区信息，减少了对 tzset(3) 的调用，提升了性能。

• 贡献软件更新：

  • SQLite3： 升级到版本 3.46.0。

  • OpenSSH： 升级到版本 9.7p1。此次发布重点修复了 bug，并将 DSA 签名算法支持设为编译时参数，计划在今年稍晚禁用该算法，并在 2025 年完全移除支持。

  • LLVM/Clang： 升级到版本 18.1.5。

  • bc： 升级到版本 6.7.6。

  • atf： 升级到 0.22 快照 55c21b2c。

  • libarchive： 升级到版本 3.7.4。

  • capsicum-test： 升级到快照 eab7a83b。

设备和驱动程序

• 驱动程序更新：

  • irdma 和 ice： 这两个驱动已更新，以提高性能和稳定性。

  • u3g 支持： 增加了对设备 SIM7600G 的支持，扩展了移动网络的硬件兼容性。

  • 无线驱动程序： 对原生和基于 LinuxKPI 的无线驱动进行了多个稳定性修复，提升了 FreeBSD 的无线网络性能（由 FreeBSD 基金会赞助）。

网络更新

• SCTP 改进： 增加了对环回接口上 SCTP 校验和卸载的支持，同时对 SCTP 堆栈进行了性能提升和 bug 修复。

硬件支持

• 处理器支持： 为 AMD Ryzen 7 “Phoenix” 处理器增加了对驱动程序 amdsmn 和 amdtemp 的支持，可以通过 sysctl 获取温度读取值。

文档更新

• 手册页： 删除了对旧工具 disklabel 的引用，改为使用 gpart。后续的 FreeBSD 版本将完全移除该工具，推广现代的磁盘管理方法。

Ports 和软件包基础设施

• 软件包变更：

  • 现代化的 DVD 软件包集： 反映了当前的软件包装趋势。

  • 已移除的 Port：

    • archivers/unzip（现在已包含在基本系统中）。

    • emulators/linux_base-c7（没有其他 Linux 软件包时不再有用）。

    • ports-mgmt/portmaster（不推荐使用，推荐使用 pkg 和二进制包）。

    • x11-drivers/xf86-video-vmware（在当前版本的 xorg-server 中不再有用）。

  • 已替换的 Port：

    • devel/git 被 devel/git@lite 替换，后者足以满足大多数需求。

  • 新增的 Port：

    • sysutils/seatd 和 x11-wm/sway 用于 Wayland 支持。

关于未来版本和开发战略

随着 FreeBSD 的不断发展，项目的开发战略和未来版本的路线图反映了其致力于拥抱现代计算架构的同时，确保广泛的兼容性和支持。FreeBSD 15.0 将是这一旅程的一个重要节点，多个关键决策将塑造操作系统的发展方向：

• 逐步淘汰 32 位平台支持： FreeBSD 15.0 预计不再支持 32 位平台，除 armv7 外，这标志着战略的转变，重点将转向 64 位计算。armv6、i386 和 powerpc 平台将被废弃，并计划移除，尽管 64 位系统仍将保留运行旧版 32 位二进制文件的能力。

• armv7 架构状态： 预计 armv7 架构将在 FreeBSD 15.0 和 stable/15 分支中作为二级架构提供支持。然而，预计 armv7 支持可能会在 FreeBSD 16.0 中被取消，关于 armv7 支持的状态将在 15.0 版本发布时提供更新。

• 继续支持 32 位二进制文件和应用程序： 尽管有向 64 位平台转型的趋势，FreeBSD 将继续支持在 64 位平台上执行 32 位二进制文件，至少在 stable/15 和 stable/16 分支中以参数 COMPAT_FREEBSD32 提供支持。此外，stable/15 分支将继续支持编译单个 32 位应用程序，确保与广泛的软件兼容性。

• Ports 和软件包基础设施： 从 FreeBSD 15.0 开始，后续版本将不再支持为已废弃的 32 位平台从 Ports 构建软件包。这一决定反映了行业趋势，即逐步淘汰 32 位架构，并将开发精力集中在更广泛使用的 64 位平台上。

• 32 位支持的生命周期结束（EOL）： stable/14 分支将继续支持 32 位内核和用户空间，以及 Ports 系统对 32 位系统的支持，直到 FreeBSD 14.0 发布五年后达到生命周期结束（EOL）。这一时间表为依赖 32 位平台的用户和开发者提供了过渡期，便于迁移到支持的架构。

• 社区反馈和未来决策： FreeBSD 项目重视社区反馈，承诺在形塑废弃平台的支持策略方面做出努力。社区的需求和贡献将对是否在 FreeBSD 15.0 或更高版本中扩展某些平台的支持产生影响。

结论

FreeBSD 13.x 系列展示了该项目在持续改进、安全性和现代化方面的承诺。FreeBSD 一直在增强系统的健壮性、安全性和硬件兼容性，跟上并有时超越其他操作系统的技术进步。FreeBSD 13.4-RELEASE 是 FreeBSD 不断适应用户需求的坚定体现，巩固了其作为开源操作系统之一的领先地位。

参考资料

对于那些有兴趣深入了解 FreeBSD 13.x 系列详细演变的用户，官方的 FreeBSD 文档和发行说明提供了对每个版本的进展和改进的全面见解。

• 官方发行说明：

  • FreeBSD 13.4-RELEASE 发行说明

  • FreeBSD 13.3-RELEASE 发行说明

• 其他资源：

  • FreeBSD 手册

原文地址：

2024 年 8 月 26 日

投资将加速零信任构建、软件物料清单（SBOM）、安全工具和开发者体验的提升

2024 年 8 月 26 日，科罗拉多州博尔德市 致力于推动开源 FreeBSD 操作系统发展及支持社区的 FreeBSD 基金会宣布，德国主权科技基金（Sovereign Tech Fund，STF）已同意向 FreeBSD 项目投资 68.64 万欧元，以推动改进基础设施、安全性、合规性及开发者体验。

由 FreeBSD 基金会组织和管理的这一工作将于 2024 年 8 月开始，并持续到 2025 年，主要涉及以下五个关键项目：

• 零信任构建：改进工具和流程

• 自动化 CI/CD：优化软件交付与操作

• 偿还技术债务：实施工具和流程以减轻技术债务

• 安全控制：现代化、加固安全工件，如 FreeBSD Ports 和软件包，助力合规性

• 改进 SBOM：优化和实施 FreeBSD 软件物料清单（SBOM）的新工具和流程

开发者是每个开源项目的核心。主权科技基金对 FreeBSD 基础设施的投资将确保开发者的一流体验，同时维护和扩展 FreeBSD 以其闻名的安全性和数字主权。

德国主权科技基金委托的工作与美国国家网络总监办公室（ONCD）于 2024 年 8 月 9 日发布的密切相关。该报告整合了 2023 年有关加强开源软件生态系统安全的关键优先事项的反馈意见。通过增强安全控制和 SBOM 工具，FreeBSD 基金会帮助确保 FreeBSD 在改进漏洞披露机制和软件安全基础方面处于前沿。

“主权科技基金很高兴赞助 FreeBSD 项目，”德国主权科技基金联合创始人 Fiona Krakenbürger 表示。“这一针对关键数字基础设施的投资将加速 FreeBSD 的现代化，提升安全性并改善开发者体验。FreeBSD 的广泛应用意味着这些改进将在全球公共部门、研究领域以及商业用户中产生深远影响。我们很高兴为其持续现代化做出贡献，以更好地服务于公共利益和 FreeBSD 社区。”

“我们非常感谢主权科技基金的这笔重要投资，这将进一步提升 FreeBSD 开发者和用户的安全性及基础设施。”FreeBSD 基金会执行董事 Deb Goodkin 表示，“在过去的 30 年中，FreeBSD 项目始终处于开源安全性、兼容性和可靠性的前沿。各国政府越来越认识到开源项目如 FreeBSD 在共享数字基础设施中发挥的重要作用。这项主权科技基金委托的工作将为面临新法规的商业用户，以及公共部门、学术界和个人用户，提供必要的透明度、可审计性和信任。”

关于主权科技基金（STF）

主权科技基金（）支持开放数字基础设施的开发、改进和维护，以服务公共利益。其目标是可持续地加强开源生态系统，关注安全性、兼容性、技术多样性以及代码背后的人。主权科技基金由德国联邦经济事务和气候行动部（BMWK）资助，并由德国联邦颠覆性创新署（SPRIND）主办和赞助。

如何参与：

FreeBSD 基金会承诺保持透明和协作的沟通。将通过已建立的公共渠道发布全部公告和更新。如有问题或者希望参与潜在的咨询委员会，为主权科技基金资助的工作提供反馈和指导，请联系 partnerships@freebsdfoundation.org。

关于 FreeBSD 基金会

• 原文链接：

• 作者：Jason Perlow

• 原文发布时间：2024 年 9 月 17 日

在不断发展的开源软件世界中，稳定性和可预测性往往是稀缺资源。最近，红帽企业版 Linux（RHEL）生态系统的变化，包括限制访问源代码，激起了社区的反应，并导致了开放企业 Linux 协会（OpenELA）的成立。

在这场动荡之中，自 1993 年以降， 始终作为一致性和可靠性的典范脱颖而出。本文将探讨 FreeBSD 的稳定开发模型与即将变化的发布计划，如何与 Linux 社区面临的挑战形成鲜明对比。

FreeBSD：稳定与创新的传承

FreeBSD 是一款开创性的开源操作系统，继承了由加州大学伯克利分校计算机系统研究小组（CSRG）在 1970 和 1980 年代开创的原始伯克利软件分发（BSD）遗产。同模块化和碎片化的 Linux 发行版不同，FreeBSD 采取整体方法进行系统开发，提供了包含内核、用户空间、实用程序、库和文档的统一软件包。这一原始概念为向最终用户交付完整的开源操作系统设定了标准。

RHEL 和 CentOS 现状简述

红帽企业版 Linux（RHEL）长期以来一直是企业级 Linux 部署的基石。2023 年 6 月，，这一决定显著影响了下游项目，如流行的免费开源 RHEL 克隆项目 。根据他们对 和 的解读，红帽通过按要求提供源代码履行了义务，但并不一定以易读和可复现的格式提供。作为回应， 成立，旨在提供开放和免费的企业 Linux 源代码。OpenELA 已经自动化其流程，使得每次 RHEL 新版本发布后的几天内，新版企业 Linux 源代码便能提供，确保其他发行版可以继续基于当前的 RHEL 代码构建。

开源操作系统开发的集中化与去中心化方法

在比较开源软件时，FreeBSD 和 Linux 有着显著的不同。Linux 提供数百个适应特定需求、偏好和哲学的发行版。这种去中心化方法允许高度定制和专业化，但也可能引发碎片化和不一致性。而 FreeBSD 则独树一帜，它是一款单一的、完整的且完全可定制的操作系统。其集中化的开发模型确保了统一的软件包，能提供系统一致性和可靠性，并促进了更统一、稳定的环境。

去中心化方法（如 Linux 发行版）与集中化方法（如 FreeBSD）并没有固有的优劣之分。每种方法都有其优劣。然而，最近的 RHEL/CentOS 代码可用性事件突显了当供应商仅按照其对版权和 GPL 的解释履行义务时，可能对社区利益产生的影响，与从社区最佳利益出发的做法之间的对比。

FreeBSD 的开发方式

对 BSD 许可证的深厚承诺

FreeBSD 的核心理念是坚守 BSD 许可证，这反映了项目在自由与开放创新方面的基本原则。这一宽松的许可证几乎不限制软件的使用、修改和分发。FreeBSD 力求减少 GPL 许可证组件的使用，展示了其致力于保持尽可能开放和自由的基础系统，促进创新和协作的环境。

FreeBSD 基金会与 FreeBSD 项目的角色

安全的构建环境

FreeBSD 的新季度和双年度发布计划

上游贡献的广泛影响

未来方向与如何参与

展望未来，FreeBSD 将继续适应和发展。转向双年度发布周期以及引入四年支持期限是确保项目继续与时俱进、响应用户需求的重要步骤。这些变化，加上 FreeBSD 已经建立的稳定性，使其在开源生态系统中继续成功发展的前景广阔。

结论

FreeBSD 在开源世界经历重大变化与挑战的时期，依然屹立不倒，成为稳定性和可靠性的灯塔。其集中化的开发模型、宽松的许可证以及对一致性发布的承诺，提供了引人注目的替代方案，展现了与其他项目中动荡局面相对立的优势。随着 FreeBSD 开启加速发布计划，它继续展示着稳定且可预测的开源操作系统的持久价值。

Jason 是一位拥有超过 25 年开源经验的作家和内容制作人，专注于分布式系统和企业架构等技术话题。曾担任 Linux 基金会的编辑总监，目前是 FreeBSD 基金会的高级撰稿人，亦为 ZDNet 的高级特约撰稿人。他的作品遍布于各大平台，涉及人工智能、云计算、网络安全和 Linux 等领域。

原文地址：

2024 年 9 月 24 日

（2024 年 9 月 20 日，科罗拉多州博尔德市）FreeBSD 基金会宣布与 Quantum Leap Research（量子跃迁研究）建立战略合作伙伴关系，共同投资总额达 75 万美元，用于增强对 FreeBSD 在笔记本电脑和通用平台的支持。Quantum Leap Research 是一家专注于为国家安全威胁提供解决方案的公司，承诺捐赠 25 万美元，而 FreeBSD 基金会将投资 50 万美元。

整个计划的预算估计为 100 万美元，基金会欢迎其他组织提供资金支持，以填补资金缺口 25 万美元。

该计划将专注于笔记本电脑和通用计算的关键可用性功能，包括现代 WiFi、完整音频支持、现代化的待机和恢复功能、改进显卡性能、蓝牙以及其他已确定的功能。

“FreeBSD 是一款高性能、安全的操作系统，可支持 Dell ThinOS 等笔记本电脑以及多种流行桌面设备。我们最近的 FreeBSD 社区调查显示，43% 的受访者将 FreeBSD 用作日常使用的系统。Quantum Leap Research 和 FreeBSD 基金会的投资将明显丰富 FreeBSD 平台的支持范围，使其成为那些重视稳定性、安全性、简洁性和性能的用户的绝佳选择。”——FreeBSD 基金会高级技术总监 Ed Maste 表示。

FreeBSD 基金会执行董事 Deb Goodkin 补充道：“这一举措是 FreeBSD 的重大进步，尤其是对于依赖笔记本电脑完成日常计算任务的用户而言。通过增加硬件支持和改进可用性功能，我们正在使 FreeBSD 对更宽泛的受众更加友好。此项投资不仅强化了 FreeBSD 生态系统，也符合我们推广 FreeBSD 作为稳健、安全和多功能操作系统的使命。”

增强 FreeBSD 在笔记本电脑上的支持和可访问性将有助于实现基金会的战略目标，即加速开发者和企业的采用。确保 FreeBSD 在多种个人计算设备上“开箱即用”表现良好，不仅会吸引开发者使用、测试和为 FreeBSD 项目做出贡献，还将扩大企业的应用范围。

“Quantum Leap Research 认为，FreeBSD 是新一代安全计算计划的绝佳基础，得益于其在安全性和稳定性方面的悠久历史。”Quantum Leap Research 总裁 Jim Miller 表示。Quantum Leap 计划在现代笔记本电脑上运行 FreeBSD，作为一种类似虚拟机管理程序的解决方案，利用 Bhyve 来虚拟化其他操作系统，如 Linux 和 Windows。

关于 Quantum Leap Research

Quantum Leap Research, LLC 为美国政府开发符合未来需求的技术，专注于解决国防部和美国情报界面临的一些最复杂的问题。更多信息请访问 。

关于 FreeBSD 基金会

FreeBSD 基金会是一家 501(c)(3) 非营利组织，致力于支持 FreeBSD 项目及其社区。基金会接受来自个人和企业的捐赠，用于开发新功能、雇佣软件工程师、改进构建和测试基础设施、通过线下和在线活动宣传 FreeBSD，以及提供培训和教育材料。基金会还代表 FreeBSD 项目处理法律事务，是合同、许可和其他法律安排的公认实体，完全依赖捐赠支持。了解更多信息，请访问 。

• 原地址：

• 作者：FreeBSD 基金会

• 原文发布时间：2024 年 8 月 28 日

是一款稳定可靠的开源操作系统，历史悠久，已成为一些全球关键基础设施的支撑平台。FreeBSD 以其稳定性、安全性和卓越性能著称，服务于广泛的用户群体，从寻求大规模部署可靠基础的经验丰富的系统管理员，到重视良好文档和社区驱动环境的开源新手。

治理与社区

FreeBSD 受益于一种协作开发模式，这与其他某些由单一独裁式人物主导的操作系统不同。这种模式促进了平衡的决策过程，确保操作系统的发展方向能够反映其多样化用户群体的需求。一支由选举产生的，经验丰富的开发团队负责该项目，提供了长期的稳定性和清晰的发展路线图。

此外，FreeBSD 拥有庞大而友好的社区，以乐于助人和响应迅速而闻名。新用户可以利用广泛且组织良好的文档资源，这些资源涵盖了从安装到高级配置的各个方面。 是一本全面的指南，而在线论坛、邮件列表和用户制作的内容提供了额外的故障排除和学习途径。强大的社区感促进了合作，确保用户有一个可靠的支持网络来解答他们的问题并应对各种挑战。

宽松的许可证

FreeBSD 采用的宽松许可证——BSD 许可证，与 Linux 使用的更为严格的 GNU 通用公共许可协议（GPL）截然不同。BSD 许可赋予了用户极大的自由，可自由使用 FreeBSD：哪怕用于商业应用，亦无需支付许可费和版税。此外，用户可以自由修改源代码以满足他们的特定需求，如果选择分发修改后的软件，他们亦无需公开这些更改。这种灵活性使 FreeBSD 成为企业和开发人员的理想选择，尤其是在需要可定制且具有成本效益的基础平台时。公司可以利用 FreeBSD 的稳定性和性能来支撑其基础设施，而不受 GPL 的约束；开发人员则可以自由修改代码，创建定制化的解决方案，而不必担心许可的限制。

卓越性能

FreeBSD 在网络密集型环境中表现优异，提供了高效的网络性能和出色的 CPU 利用率的结合。这使其成为需要最大网络吞吐量和响应性的应用程序和部署的理想选择。

经 FreeBSD 优化的 TCP/IP 堆栈是其强大性能的核心。其简化的设计提供了低延迟和卓越的响应时间，特别是在网络流量和输入/输出（I/O）操作方面。这转化为实际应用中的优势，如更快的数据传输、更流畅的流媒体播放和更灵敏的 Web 应用程序。

进一步提升性能的是 FreeBSD 的轻量级和可扩展的基本系统。与一些体积较大的操作系统不同，FreeBSD 仅包含核心功能所需的基本组件。这种精简的方法带来了几项优势：

• 启动时间更快： 由于需要初始化的组件较少，FreeBSD 启动速度很快，特别适合需要高可用性和快速恢复的环境。

• 缩减攻击面： FreeBSD 通过最小化安装的组件数量，缩小了潜在攻击者的攻击面。这减少了系统遭受攻击和恶意软件的风险。

• 易于定制： 用户可以根据特定需求轻松添加/删除组件。这使得 FreeBSD 可以针对不同的使用场景进行定制，从最简化的服务器安装到具有更广泛应用的功能齐全的桌面环境。

• 高效的硬件利用率： 精简的基本系统确保了硬件资源的有效利用。这意味着在现代和旧版硬件上都能获得更好的整体性能，使 FreeBSD 成为更多部署场景下的多功能选择。

Z 文件系统 (ZFS)

ZFS 是一款大容量、容错的文件系统，为 FreeBSD 带来了多个性能优势。ZFS 的一些关键特点包括：

• 池化存储：通过将多个磁盘合并为一个存储池，简化了存储管理。

• 数据完整性：通过端到端的校验和确保数据完整性，能够检测并修正静默数据损坏。

• 快照与克隆：支持快速高效的文件系统快照和克隆，用于备份和复制目的。

• 可扩展性：能够有效扩展以支持大量数据和存储设备，适用于企业环境。

bhyve 虚拟化

bhyve 是 FreeBSD 原生的虚拟化程序，为用户提供了一种强大而高效的虚拟化解决方案。bhyve 的主要特点包括：

• 轻量级与灵活性：设计轻量且高度灵活，适用于多种虚拟化需求。

• 虚拟机支持多种操作系统：虚拟机可以运行多种操作系统，包括 FreeBSD、Linux 和 Windows。

• 高效的资源利用：优化资源使用，确保虚拟机以最低的开销高效运行。

• 与 FreeBSD 的集成：与 FreeBSD 基础系统无缝集成，提供一致的虚拟化体验。

海量的软件包 Port

通过 Port 软件包，FreeBSD 为用户提供了海量的软件应用。Ports 由 FreeBSD 项目自己维护着，有 30,000 款余应用，涉及包括 Web 服务器、数据库、桌面环境和开发工具等多个类别。

安全性与稳定性

安全性是 FreeBSD 哲学的核心原则之一。开发者在设计和开发过程中优先考虑安全性，以最小化攻击面并实施强大的访问控制。以下几个关键特性有助于 FreeBSD 强大的安全性：

• 最小特权：服务以最小权限运行，限制了安全漏洞发生时可能带来的损害。这种隔离方法限制了被攻破服务对系统其他部分的影响。

• 单一代码库开发：FreeBSD 项目将整个核心操作系统开发在单一的代码库中。这种集中式方法简化了安全维护，减少了必须监控和修补的外部组件数量。

• 关注代码质量：FreeBSD 开发者在开发过程中高度重视代码质量和安全最佳实践。这种主动的方法有助于在漏洞被利用之前识别并缓解潜在的安全问题。

除了核心安全措施外，FreeBSD 还提供了一些独特的功能，进一步增强了系统安全性：

• Jail：Jail 提供了一种强大的机制，可以在操作系统内创建隔离的虚拟环境。这些环境作为独立的服务器运行，具有有限的资源和文件系统访问权限。隔离性有助于防止安全漏洞蔓延到系统的其他部分或危及主机操作系统本身。Jail 为需要强隔离的场景提供了传统全虚拟化的轻量级替代方案。

• Capsicum：Capsicum 为开发者提供了一个有价值的安全框架，允许他们创建在受限沙箱环境中运行的应用程序。Capsicum 强制执行安全策略，限制应用程序的功能，从而大大减少了代码中漏洞可能带来的影响。

• CheriBSD：CheriBSD 是 FreeBSD 的扩展，提供了先进的内存保护功能。通过实施硬件辅助的内存保护机制，CheriBSD 使得攻击者更难以利用系统漏洞。这种增强的保护级别对于安全关键的应用程序尤为重要。

FreeBSD 采用严格且安全的构建过程，以确保操作系统的完整性和可信度。这个多方面的方法包含了几个关键原则：

• 隔离与封闭：构建环境与外部网络及其他潜在干扰源隔离。这有助于防止在构建过程中注入恶意代码，并确保系统的完整性。

• 最小外部依赖：构建过程主要依赖内部工具和资源，减少了通过第三方软件引入的漏洞风险。

• 源代码验证：所有进入构建过程的代码都经过严格验证，以确保其真实性和完整性。这有助于识别并防止未经授权的修改或恶意代码的加入。

• 一致性与可重现性：构建环境设计为稳定和可预测的。能检测到任何异常或不规则性，从而识别潜在的安全问题。可重现的构建过程还确保源代码始终生成相同的二进制输出，便于验证和审计。

稳定性与进步的完美结合：可预测的升级

FreeBSD 在稳定性与进步之间达到了完美的平衡。新特性会谨慎地集成到版本中，并经过严格的测试，确保在生产环境中的完美运行。这种对稳定性的承诺使 FreeBSD 成为开发和部署关键系统的可信选择。

最小惊讶原则（POLA）是这一方法的指导思想。POLA 确保系统升级和变更不会破坏现有的功能或工作流程。在 FreeBSD 中，这一原则的应用方式如下：

• 一致的用户体验：升级旨在保持熟悉的用户体验。用户可以期待最小的工作流程中断，避免由于不可预见的变化而浪费时间进行适应。

• 可预测的系统行为：系统组件和工具遵循既定的约定，始终如一。这种可预测性使得用户更容易理解系统的行为，并有效地与系统进行互动。

• 清晰的沟通：FreeBSD 开发者重视清晰透明的沟通。详细的发布说明和文档会通知用户即将发生的变更及其潜在影响。这种透明度使得用户能够做好升级准备，并进行必要的调整。

• 以用户为中心的设计：FreeBSD 的开发过程积极寻求用户反馈，确保变更与用户的期望一致。这种关注最小化了在升级过程中用户遇到的不必要的复杂性和惊讶。

FreeBSD 的升级过程简单且无痛，即使是重大版本升级也是如此。系统设计上确保升级过程流畅，最小化停机时间和复杂性。以下是 FreeBSD 升级过程中非常友好的几个特点：

• 可预测且一致：升级旨在可预测且一致，确保系统功能在整个过程中保持不变。

• 最小的停机时间：升级过程优化了最小的停机时间，非常适合那些需要持续运行的生产环境。

• 简单执行：通常升级仅需执行几个命令即可完成。丰富的文档和用户指南可以在整个过程中为用户提供帮助。

• 向后兼容性：FreeBSD 优先考虑向后兼容性。现有的应用程序和配置在升级后依然可以正常运行，减少了系统管理员的中断和重复工作。

• 严格测试：每个版本都会经过广泛的测试，确保在问题进入用户环境之前就被发现和解决。

• 快照与回滚：通过 ZFS，用户可以在升级前创建系统快照。如果在升级过程中出现不可预见的问题，可以轻松回滚到之前的状态。

• 安全更新集成：升级机制无缝集成了定期的安全补丁和更新。这确保了系统在引入最新功能和改进的同时，也能防御最新的安全威胁。

总结

FreeBSD 提供了性能、安全性、稳定性、灵活性和支持性社区的完美结合。其宽松的许可使其成为各类企业和开发者的成本效益高的选择。无论你是寻求大规模部署可靠基础的经验丰富的系统管理员，还是寻求强大、安全操作系统的开源新手，FreeBSD 都值得考虑。凭借其对安全、稳定性和对用户社区的强烈承诺，FreeBSD 成为其他操作系统的可行替代方案，并继续为全球关键基础设施提供动力。

为 FreeBSD 项目做贡献

关于 FreeBSD 基金会

在线浏览地址：

• 原文地址：

• 作者：Michael Plura

• 发布时间：2024 年 6 月 7 日上午 10:07

他在 BSD-Unix 开源项目中发挥了重要作用，BSD 许可证正是由他一手创建，他一直致力于 FreeBSD 的发展。让我们一起追忆永远离开我们的 Michael J. Karels 先生。

(图片：FreeBSD 基金会)

Michael J. Karels 曾在加利福尼亚大学伯克利分校（University of California, Berkeley）攻读分子生物学学位，那是他首次接触到伯克利软件发行版计划（Berkeley Software Distribution，BSD）。他所在的实验室涉足了两个领域：研究细菌基因的遗传学，他曾说那里的高科技设备是由牙签和培养皿构成的。另一个领域是分析细菌基因的子部分，该部分提供了某种特定酶的建模说明。实验室有许多专业设备，其中就包含了一台用于数据收集和数据分析的 PDP 11/40。

Unix V6/V7: 从 0 开始

这台机器上运行着第六版 Unix（V6 Unix），附带了一些来自 2.8BSD、2.9BSD 的增强功能。PDP11/40 引起了他的兴趣，为了科学评估，他编写了个 Fortran 程序。在系统发生错误后，一位员工将 V6 Unix 替换为第 7 版 Unix（V7）——他就是于 2022 年 3 月去世的 Bill Jolitz。Bill 和他的妻子在 386BSD 的开发中发挥了重要作用。Unix V7 并不能完美运行在 PDP11/40 上，技术仪器的设备也无法正常驱动。在对计算机几乎一无所知的情况下，Michael J. Karels 开始研究这个问题，并在 Bill Jolitz 的帮助下适配了 V7 Unix 的软件和驱动。

计算机系统研究小组（CSRG）

1974 年，加州大学伯克利分校的 Bob Fabry 教授从 AT&T 获得了 UNIX 源代码许可证。他与同事开始修改 UNIX，并将修改成果以伯克利软件发行版（BSD）的名义进行销售。 1980 年 4 月，为了满足 ARPAnet（美国国防部高级研究计划局）的特殊需求，Fabry 与 DARPA 签订合同，以继续开发 UNIX。在此资助下，Fabry 成立了计算机系统研究小组（CSRG）。

Michael J. Karels 也早早加入了 CSRG，成为负责 BSD TCP 堆栈开发的一员。BSD4.2 中并没有版权声明，但许多美国公司在略微修改后却加入了自己的版权信息，Karels 对此感到不满。因此，他与律师合作，创造了如今在每个源代码文件中都存在的版权声明，该声明随 4.3BSD 分发。随着时间的推移，FreeBSD、NetBSD、OpenBSD、DragonFly BSD 和 Sun Solaris 等系统因此而诞生。

转职为 BSDi 的首席系统架构师

1992 年 2 月，Karels 转职到 BSDi（伯克利软件设计公司），参与 BSD/OS 的开发。BSD/OS 曾是多年唯一在英特尔平台上提供的商业化类 BSD Unix 操作系统。BSDi 的所有软件资产于 2001 年 4 月被凤河收购，Karels 随后成为风河的首席技术专家，负责 BSD/OS 平台。

2003 年，Karels 转职成为 Secure Computing Corporation 的高级首席工程师，该公司以 BSD/OS 作为 SecureOS 的基石。在这，他主要开发的产品是 Sidewinder 防火墙，后来被称为 McAfee Firewall Enterprise（即臭名昭著的迈克菲防火墙企业版）。由于 BSD/OS 的开发逐渐停滞，Karels 提议将 SecureOS 从 BSD/OS 迁移到 FreeBSD。多年来，该项目中的许多重要成果都回馈给了 FreeBSD。Karels 在 2017 年被正式任命为 FreeBSD 的提交者。退休后，他继续在业余时间为 FreeBSD 做贡献。

奖项、书籍和演讲

1993 年，USENIX 协会为加利福尼亚大学伯克利分校计算机系统研究小组授予终身成就奖，以表彰包括 Karels 在内的 180 位人士，他们为 CSRG 发布 4.4BSD-Lite 做出了贡献。

Michael J. Karels 与 Marshall Kirk McKusick 合著了多本关于《4.3BSD UNIX 操作系统设计与实现》的书籍。去年五月，Karels 在渥太华举行的 FreeBSD 开发者峰会 2023 上谈到了他在 BSD 生态系统内的职业生涯。

原文链接：https://it-notes.dragas.net/2023/04/03/make-your-own-vpn-wireguard-ipv6-and-ad-blocking-included/

VPN 是连接到自己的服务器和设备的基本工具。许多人出于各种原因使用商业 VPN，从不信任其提供商（尤其在连接到公共热点时）到希望使用不同 IP 地址（也许是其他国家的）在互联网上“活跃”。

无论出于何种原因，解决方案都不会匮乏。我一直在设置管理 VPN，以允许服务器、客户端使用安全通道进行通信。最近，我在所有设备上（包括桌面/服务器和移动设备）启用了 IPv6 连接，我需要快速创建一个节点，集中一些网络并允许它们在 IPv6 网络上出站。我使用并将要描述的工具是：

• VPS——在这种情况下，我使用了基本的 Hetzner Cloud VPS，但所有提供 IPv6 连接的提供商都可以：如果您需要 IPv6 的话。

• OpenBSD——一款干净、稳定且安全的操作系统。

• Wireguard——轻量级、安全，同时也不会“唠叨”，因此对移动设备电池也很友好。在没有流量时，它不会传输/接收任何内容。被所有主要的桌面和服务器操作系统以及 Android 和 iOS 设备广泛支持。

• Unbound——可以直接向根域名服务器发出 DNS 查询，而非转发器。还允许插入阻止列表，类似于 Pi-Hole 的结果（即广告拦截）。

• 列表——立即阻断与黑名单用户之间的连接。

第一步是激活 VPS 并安装 OpenBSD。在 Hetzner 云控制台上，没有有预置的 OpenBSD 镜像，只有 Linux 发行版可选。别怕，只需选择其中一个 Linux 并创建 VPS。创建完成后，OpenBSD ISO 镜像将出现在“ISO 映像”中。只需插入虚拟光驱，重启 VPS，OpenBSD 安装程序就会出现在控制台中。

我就不细说了，操作简单明了。唯一的注意事项（对于 Hetzner Cloud VPS）是使用“自动配置”进行 IPv4 设置，但暂时别配置 IPv6。稍后再配置。

使用 syspatch 命令安装所有 OpenBSD 更新并重新启动，内核将被重新链接。

在 OpenBSD 上，Wireguard 完全集成到了基本系统中，无需安装外部软件包。这是一个重大优势，因为随着时间的推移，所有与 Wireguard 相关的支持将由主要的 OpenBSD 开发团队直接管理。

第一步是在 VPS 上配置 IPv6。在 Hetzner 下，不幸的是，他们只提供 /64 的地址，因此需要对分配的网络进行分段。在这个例子中，它将被划分为 /72 子网络 - 可以使用计算器来查找有效的子类。

文件 /etc/hostname.vio0 应该看起来如下：

inet autoconf
inet6 2a01:4f8:cafe:cafe::1 72 
!route add -net ::/0 fe80::1%vio0

简而言之，保留 Hetzner 分配的基地址，但将子网掩码改为/72 - 从而可以使用其他网络。

sh /etc/netstart vio0

它将重新配置网络接口并允许 IPv6 开始工作。要测试它：

ping6 google.com

若一切配置正确，可执行 ping 命令且 google.com 将回复。

现在需要为 IPv4 和 IPv6 启用转发。在文件 /etc/sysctl.conf 中输入以下内容：

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1

要应用这些更改，您可以重新启动或直接输入：

sysctl net.inet.ip.forwarding=1
sysctl net.inet6.ip6.forwarding=1

配置 Wireguard，需要进行一些步骤。首先，需要创建私钥：

openssl rand -base64 32

会出现类似以下内容：

YUkS6cNTyPbXmtVf/23ppVW3gX2hZIBzlHtXNFRp80w=

现在创建一个名为 /etc/hostname.wg0 的新文件：

172.14.0.1/24 wgport 51820 wgkey YUkS6cNTyPbXmtVf/23ppVW3gX2hZIBzlHtXNFRp80w=
inet6 2a01:4f8:cafe:cafe:100::1 72

正在创建一个新的 Wireguard 接口，名为 wg0。它将拥有 IPv4 地址“172.14.0.1”，Wireguard 将监听端口 51820，并使用稍后创建的私钥。它还将在供应商提供的子类别之一上拥有 IPv6 地址。

保存并激活该接口：

sh /etc/netstart wg0

如果所有内容都正确输入，它应该会启用接口。现在：

ifconfig wg0

将返回类似这样的内容：

wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
	index 5 priority 0 llprio 3
	wgport 51820
	wgpubkey xxxxxxxxxxxxxxx=
	groups: wg
	inet 172.14.0.1 netmask 0xffffff00 broadcast 172.14.0.255
	inet6 2a01:4f8:cafe:cafe:100::1 prefixlen 72

记录下 wgpubkey——它将用于配置客户端。

就防火墙而言，OpenBSD 带有基本的 pf 配置。在我的设置中，我倾向于阻断不需要的内容，并允许可能有用的内容。但是，我喜欢把“坏人”挡在门外，所以我使用黑名单。pf 允许在运行时向表中插入和移除元素，因此防火墙可以相应地进行配置。

要下载并应用 Spamhaus 列表，我使用在互联网上找到的一个简单而有效的脚本。

所以在/usr/local/sbin/spamhaus.sh 中创建脚本：

#!/bin/sh
#
# this is normally run once per day via /etc/daily.local.
#
echo updating Spamhaus DROP lists:
(
  { ftp -o - https://www.spamhaus.org/drop/drop.txt && \
    ftp -o - https://www.spamhaus.org/drop/dropv6.txt ; \
  } 2>/dev/null | sed "s/;/#/" > /var/db/drop.txt
)
pfctl -t spamhaus -T replace -f /var/db/drop.txt

使其可执行并运行：

chmod a+rx /usr/local/sbin/spamhaus.sh
/usr/local/sbin/spamhaus.sh

配置 pf 的方法很多。一个相当简单的例子可能是这样的：

这是一个非常简单的配置：它阻止了来自 Spamhaus 下载列表中的所有内容，允许 Wireguard 网络到公共接口的 NAT，允许 IPv6 中的 icmp 流量（这对网络正常运行至关重要），同时阻止了针对 Wireguard IPv6 LAN 的传入流量（请记住，IP 地址将是公共的且可直接到达，因此我们不希望默认情况下公开我们的设备）。允许 Wireguard 接口上的所有流量通过。然后将阻止所有流量并指定异常，即允许 ssh 和 Wireguard 连接（当然）。还将授权允许流量从公共网络接口流出。

重新加载 pf 配置:

pfctl -f /etc/pf.conf

倘若一切正常，防火墙应该已加载新的参数。

现在是配置 Unbound 来实现 DNS 查询缓存和相关广告拦截的时候了。一段时间前，我找到了一个脚本，稍作调整后使用。我记不清楚原始作者是谁了，所以我只在这里贴出来脚本。

创建一个脚本来更新 /usr/local/sbin/unbound-adhosts.sh 中的 unbound 广告拦截。

类似地，使脚本可执行并运行它：

chmod a+rx /usr/local/sbin/unbound-adhosts.sh
/usr/local/sbin/unbound-adhosts.sh

现在，可以修改位于 /var/unbound/etc/unbound.conf 的 Unbound 配置文件如下：

在启动 unbound 之前，必须给予适当的权限：

chown -R nobody:nobody /var/unbound

现在可以启用并启动 unbound。由于需要加载（长）阻止列表，这将需要几秒钟：

rcctl enable unbound
rcctl start unbound

如果一切都正确，unbound 将能够响应来自各自 LAN 的请求，位于 172.14.0.1 和 2a01:4f8:cafe:cafe:100::1 上。

现在可以配置 Wireguard 客户端了。每种实现都有其自己的过程（Android、iOS、MikroTik、Linux 等），但基本上只需在服务器和客户端上创建正确的配置即可。例如，在 OpenBSD 服务器上输入“ifconfig wg0”命令可查看服务器的公钥，应将其插入到客户端上将创建的“peer”配置中；而客户端的公钥则将在服务器上这样使用：

重新打开文件 /etc/hostname.wg0 添加：

172.14.0.1/24 wgport 51820 wgkey YUkS6cNTyPbXmtVf/23ppVW3gX2hZIBzlHtXNFRp80w=
inet6 2a01:4f8:cafe:cafe:100::1 72
wgpeer *client's public key* wgaip 172.14.0.2/32 wgaip 2a01:4f8:cafe:cafe:100::2/128

重新加载配置：

sh /etc/netstart wg0

在客户端上，通过在本地 IP 地址中插入“172.14.0.2/32, 2a01:4f8:cafe:cafe:100::2/128”（在主机名为 wg0 的对等配置中输入的）创建一个新配置。将 DNS 服务器地址设置为“172.14.0.1”及/或其对应的 IPv6 地址（在本例中为 2a01:4f8:cafe:cafe:100::1 - 您的将会不同）。在对等端，插入服务器的数据，包括其公钥、IP 地址:port（在示例中，port是 51820），以及允许的地址（设置“0.0.0.0/0, ::0/0”意味着“所有连接将通过 Wireguard 发送” - 所有流量将通过 VPN 传输，无论是 IPv4 还是 IPv6）。

也可以将 VPN 仅用作广告拦截器，只通过其路由 DNS 流量。要实现此结果，只需配置客户端，使得唯一允许的地址是刚配置的 unbound 的地址（在本示例中，172.14.0.1 或 2a01:4f8:cafe:cafe:100::1） - DNS 解析将通过 VPN 进行，但浏览将继续通过主提供商运行。

如果您希望垃圾邮件和广告屏蔽列表能够自动更新，创建/etc/daily.local 文件并添加以下行：

#!/bin/ksh

/usr/local/sbin/unbound-adhosts.sh
/usr/local/sbin/spamhaus.sh

所有这些都可以通过简单安装 OpenBSD 来实现，无需安装任何额外的软件包。这既有助于更新管理，也有助于安全性。

点击此处可以观看弥撒的录制视频。

• 原文位于 https://www.gearty-delmore.com/obituaries/michael-mike-karels（网上扫墓）

Michael "Mike" John Karels（1956 年 8 月 2 日 - 2024 年 6 月 2 日），享年 67 岁，来自伊甸草原。

Michael 于加拿大渥太华因突发心脏病猝然离世。仅余他挚爱的妻子 Theresa “Teri”（娘家姓 Spartz）仍在人世间；女儿 Sarah 及其男友 Ivan Munkres、姐妹 Colleen (Stuart) Lind、Mary Beth (Brad) Schleif 和 Katherine Karels、兄弟 Eugene (Ann) Karels 以及许多家人和朋友，包括他的父母 Patricia 和 Charles Karels 都在他之前去世了。

Michael 毕业于圣母大学（即诺特丹大学），取得微生物学学士学位，并在加州大学伯克利分校完成了研究生学业。在攻读博士学位期间，他接触到了计算机，使他的兴趣发生转向。他最终成为了一名软件工程师，并在 BSD UNIX 历史上扮演了重要角色，这是现代计算史上一个重要的里程碑。通过在伯克利大学的工作，他为早期互联网的实现做出了贡献，为现代网络奠定了基础。他是《4.4 BSD 操作系统的设计与实现》的作者之一，这是该领域的重要著作。”

在完成伯克利的学业后，他曾在多个组织担任高级首席工程师，包括风河公司、安全计算公司、迈克菲、英特尔和 Forcepoint。2021 年他退休了，并将时间和才能倾注于为 FreeBSD（一款免费操作系统）做志愿工作。尽管他在相关领域取得了成功并占据重要地位，但 Michael 被人描述为是一个非常谦逊、有耐心和善良的人，并且乐于与他人分享知识。”

除了在工作上取得的成功，Michael 还是他的家庭中的关键一员，他是个乐于奉献，能支撑的儿子、兄弟、丈夫及父亲。从小，他就承担着额外的责任，在许多方面带领、帮助和指导家庭成员，但他总是以善良、坚持和智慧来面对这些。

Michael 也是一位热情的环保主义者。他对自然的热爱始于早年与家人的野营之旅，其中在冰川国家公园独自过夜的经历成为他成长中的深层记忆。这份热情随着时间的推移而增长，成年后的他成为了许多环保组织的积极支持者，致力于对抗气候变化，并在当地参与清除植物入侵物种的工作。他和妻子最后一次同游国家公园是在 2023 年秋，他们观光了大峡谷和锡安国家公园。

多年来，他的爱好各异，比如音乐和摄影。他的音乐品味多样，从杰思罗·塔尔乐队到贝多芬再到戴夫·布鲁贝克。他对摄影的兴趣始于高中时期，他在其童年卧室里搭建了自己的暗室，并随之进入了现代摄影和数码单反相机时代。在圣母大学就读期间，他担任了校园广播电台的站长，白天播放古典音乐，晚上拍摄巡演的摇滚乐队。

Michael 原本期盼着在退休后的余生中进行编程、改善家居环境，并见证女儿从医学院毕业并成家。他的离世使家人和朋友乃至整个科技界都倍感遗憾。

6 月 18 日（周二）上午 11:00 在 Pax Christi 天主教社区举行基督葬礼，地址：Eden Prairie，12100 Pioneer Trail。

Michael 将安眠在 Pleasant Hill 公墓。

6 月 17 日（星期一）下午 5:00 至 8:00 在 Gearty-Delmore Park 殡仪馆（地址：St. Louis Park，3960 Wooddale Avenue South）举行追思会，其中包括下午 6:30 的回忆时光（弥撒前一小时在教堂举行）。

祭奠活动请优先考虑捐赠至 Free BSD 基金会；3980 Broadway Street; STE #103-107; Boulder, CO 80304 或捐款至环境保护基金会（EDF）。

• 原文链接：https://qiita.com/belgianbeer/items/8df197588462cd7f6b45

• FreeBSD

• RAID

• 硬盘驱动器

• ZFS

• ZFSonLinux

上次更新于 2023 年 07 月 16 日发布于 2023 年 06 月 24 日

ZFS 镜像池的磁盘更换与容量扩展

开始

自家服务器的硬盘使用量即将超过 80%^ 1^，再加上使用已经超过了 10 年，因此判断还是该更换硬盘了。于是我购买了新的硬盘并进行了更换。本文记录了实际进行硬盘更换的过程。

尽管本文作者的服务器操作系统是 FreeBSD，但是即使在 Linux 上使用 ZFS 的情况下，ZFS 相关操作也是类似的（作者也在 Linux 上使用 ZFS）。

服务器存储配置

目标服务器的操作系统是 FreeBSD，作为系统存储有一台 256GB 的 SSD，作为数据存储有两台 2TB 的硬盘，全部使用 ZFS 配置。为了数据保护，两台硬盘配置为 ZFS 镜像，因此尽管有两台硬盘，但容量上等同于一台。本次将两台 2TB 的硬盘更换为各自 6TB 的硬盘。

更換操作前的檢查

在實際進行更換操作之前，請確認當前狀況。使用 zpool list 來確認硬碟的使用量等信息如下所示。

$ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot   228G  16.8G   211G        -         -    12%     7%  1.00x  ONLINE  -
zvol0  1.81T  1.49T   333G        -         -     5%    82%  1.00x  ONLINE  -
$

zroot 是用於系統的 SSD。而 zvol0 是此次更換的硬碟目標，可以看到 ZFS 鏡像配置的使用量達到了 82%。

配置的详细信息可以在 zpool list -v 和 zpool status 中查看。

$ zpool list -v zvol0
NAME             SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  
zvol0           1.81T  1.49T   333G        -         -     5%    82%  1.00x    ONLINE  -
  mirror-0      1.81T  1.49T   333G        -         -     5%  82.1%      -    ONLINE
    gpt/ndisk2      -      -      -        -         -      -      -      -    ONLINE
    gpt/ndisk1      -      -      -        -         -      -      -      -    ONLINE
$

$ zpool status zvol0
  pool: zvol0
 state: ONLINE
  scan: scrub repaired 0B in 05:36:58 with 0 errors on Tue Jan 17 08:40:57 2023
config:

        NAME            STATE     READ WRITE CKSUM
        zvol0           ONLINE       0     0     0
          mirror-0      ONLINE       0     0     0
            gpt/ndisk2  ONLINE       0     0     0
            gpt/ndisk1  ONLINE       0     0     0

errors: No known data errors
$

从这些信息我们可以看出，ndisk1 和 ndisk2 的磁盘分区已经设置成了镜像。实际上，这 3 个存储设备分别是 ada0（固态硬盘）、ada1（硬盘）、ada2（硬盘），硬盘分区的配置如下。

$ gpart show ada1 ada2
=>        40  3907029088  ada1  GPT  (1.8T)
          40  3907029088     1  freebsd-zfs  (1.8T)

=>        40  3907029088  ada2  GPT  (1.8T)
          40  3907029088     1  freebsd-zfs  (1.8T)

$ gpart show -l ada1 ada2
=>        40  3907029088  ada1  GPT  (1.8T)
          40  3907029088     1  ndisk1  (1.8T)

=>        40  3907029088  ada2  GPT  (1.8T)
          40  3907029088     1  ndisk2  (1.8T)

$

可以看出 ada1 和 ada2 都是采用 GPT 格式，ada1 的用于 ZFS 的分区命名为 ndisk1，ada2 的分区则命名为 ndisk2。

使用镜像配置更换硬盘的步骤

不仅限于 ZFS，对于镜像（RAID 1）配置的两个硬盘都需要更换的步骤，大概有以下两种方法。

• 使用新硬盘准备镜像，然后从现有镜像复制数据，复制完成后再进行更换。或者先更换再从原始硬盘复制数据。

• 更换一侧硬盘，使用镜像功能同步数据，完成后再更换另一侧硬盘重新同步数据

使用前一种方法，数据复制只需一次，但同时需要连接 3 台或 4 台硬盘，还需要考虑 SATA 接口数量等。在这种情况下，虽然硬盘可以使用 USB 连接，但由于 USB 2.0 传输速度慢，复制所需时间较长，因此最好使用 USB 3.0。

作者选择了后一种逐一更换的方法。这种方法在更换硬盘时可能会有些影响，但即使在同步期间（性能会有所降低），也能像平常一样继续使用服务器，这是其优点。

硬盘更换和数据同步

注意：在 ZFS 镜像中更换驱动器时

在更换 ZFS 镜像中的驱动器时，请注意在执行任何操作（如 zpool detach zvol0 gpt/ndisk2 ）之前最好不要从 ZFS 池中移除 ndisk2。因为一旦使用 zpool detach 命令将 ndisk2 从池中移除，ndisk2 中的数据将被视为已清除。如果在数据同步到新硬盘时发生 ndisk1 读取错误，并且需要用 ndisk2 重新进行同步，那么一旦 ndisk2 被移除，就无法再次使用它进行同步了。如果只是关闭电源并移除 ndisk2，那么 ndisk2 中的数据将保持与 ndisk1 相同，这样即使发生意外，也可以使用 ndisk2 进行重新同步。

更换第一台硬盘

首先更换第一台硬盘，将包含 ndisk2 分区的硬盘取出进行更换。关闭服务器并切断电源，取下旧硬盘，连接新硬盘后通电。

启动后确认 zvol0 的状态。

$ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zroot   228G  16.8G   211G        -         -    12%     7%  1.00x    ONLINE  -
zvol0  1.81T  1.49T   333G        -         -     5%    82%  1.00x  DEGRADED  -
$

$ zpool status zvol0
  pool: zvol0
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-2Q
  scan: scrub repaired 0B in 05:36:58 with 0 errors on Tue Jan 17 08:40:57 2023
config:

        NAME                      STATE     READ WRITE CKSUM
        zvol0                     DEGRADED     0     0     0
          mirror-0                DEGRADED     0     0     0
            12897545936258916783  UNAVAIL      0     0     0  was /dev/gpt/ndisk2
            gpt/ndisk1            ONLINE       0     0     0

errors: No known data errors

两个硬盘应该构成镜像，但其中一个 gpt / ndisk2 不见了，只剩下一个，因此在 HEALTH 或 STATE 方面显示为 DEGRADED。另外，在 zpool status 中，显示了 gpt / ndisk2 所在位置的 config：部分中不见了，而是显示为“12897545936258916783”，并以“was /dev/gpt/ndisk2”结尾。稍后将使用此 ID。

创建备用分区

为备用硬盘准备工作，要进行 GPT 初始化，并准备用于 ZFS 的分区。

首先，使用 GPT 初始化硬盘。

$ gpart show ada1
gpart: No such geom: ada1.
$ gpart create -s gpt ada1
ada1 created
$ gpart show ada1
=>         40  11721045088  ada1  GPT  (5.5T)
           40  11721045088        - free -  (5.5T)

$

然后为 ZFS 分配分区。我将新分区命名为 sdisk1 以区别于旧分区。

$ gpart add -t freebsd-zfs -a 4k -l sdisk1 ada1
ada1p1 added
$ gpart show ada1
=>         40  11721045088  ada1  GPT  (5.5T)
           40  11721045088     1  freebsd-zfs  (5.5T)

$ gpart show -l ada1
=>         40  11721045088  ada1  GPT  (5.5T)
           40  11721045088     1  sdisk1  (5.5T)

$

同步第一台数据

由于已准备好新分区，因此将用 sdisk1 替换旧 ndisk2。为此操作使用 zpool replace 。

通常情况下，您需要指定构成池的设备作为 zpool replace 的源设备，但是在这种情况下，由于设备已被取下，因此没有这样的设备。在这种情况下，请指定显示的 ID，即 zpool status zvol0 。

$ zpool replace zvol0 12897545936258916783 gpt/sdisk1
$

这将开始同步来自 ndisk1 的镜像到 sdisk1。

同期在后台进行，如前所述，在此期间通常可以正常使用服务器。由于数据量大约为 1.5TB，因此同步需要相当长的时间，而在此期间如果无法了解进展情况，可能会感到有些不安。在 ZFS 中可以通过 zpool status 确认同步进度，从而获得结束时间的大致参考。

$ zpool status zvol0
  pool: zvol0
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sat Jan 28 14:25:44 2023
        12.8G scanned at 596M/s, 600K issued at 27.3K/s, 1.49T total
        0B resilvered, 0.00% done, no estimated completion time
config:

        NAME                        STATE     READ WRITE CKSUM
        zvol0                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            replacing-0             DEGRADED     0     0     0
              12897545936258916783  UNAVAIL      0     0     0  was /dev/gpt/ndisk2
              gpt/sdisk1            ONLINE       0     0     0
            gpt/ndisk1              ONLINE       0     0     0

errors: No known data errors
$

在 status: 下显示 One or more devices is currently being resilvered 和 resilver^ 3^ 中（同步中）的状态。在 action: 下显示指示等待 resilver 完成。而在 scan: 中显示处理量和预计时间，但正如 no estimated completion time 所示，同步刚开始时由于无法预知时间，因此不会显示。

过一段时间，将会显示预计完成时间，但根据经验，在这个阶段这些时间通常不可靠。

$ zpool status zvol0
===== <省略> =====
  scan: resilver in progress since Sat Jan 28 14:25:44 2023
        265G scanned at 664M/s, 6.51G issued at 16.3M/s, 1.49T total
        6.51G resilvered, 0.43% done, 1 days 02:27:43 to go
===== <省略> =====
$ 

进一步确认后，显示需要大约 14 小时才能完成。

$ zpool status zvol0
===== <省略> =====
  scan: resilver in progress since Sat Jan 28 14:25:44 2023
        289G scanned at 488M/s, 18.6G issued at 31.4M/s, 1.49T total
        18.6G resilvered, 1.22% done, 13:38:30 to go
===== <省略> =====
$

一小时后再次确认时，显示时间已减少到约 6 小时，但第一台镜像的同步最终花了约 15 个半小时。以下是第一台同步完成时检查到的 zpool list 和 zpool status 的结果。

$ zpool list -v zvol0
NAME             SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zvol0           1.81T  1.49T   333G        -         -     5%    82%  1.00x    ONLINE  -
  mirror-0      1.81T  1.49T   333G        -         -     5%  82.1%      -    ONLINE
    gpt/sdisk1      -      -      -        -         -      -      -      -    ONLINE
    gpt/ndisk1      -      -      -        -         -      -      -      -    ONLINE
$

$ zpool status zvol0
  pool: zvol0
 state: ONLINE
  scan: resilvered 1.49T in 15:34:45 with 0 errors on Sun Jan 29 06:00:29 2023
config:

        NAME            STATE     READ WRITE CKSUM
        zvol0           ONLINE       0     0     0
          mirror-0      ONLINE       0     0     0
            gpt/sdisk1  ONLINE       0     0     0
            gpt/ndisk1  ONLINE       0     0     0

errors: No known data errors
$

HEALTH 和 STATE 均为 ONLINE，无错误发生，第一台同步顺利完成。

第二个硬盘的同步

由于第二个硬盘的更换和同步步骤与第一个完全相同，因此只记录命令的执行和结果。

更换第二个硬盘并启动。

$ zpool status zvol0
  pool: zvol0
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-2Q
  scan: resilvered 1.49T in 15:34:45 with 0 errors on Sun Jan 29 06:00:29 2023
config:

        NAME                      STATE     READ WRITE CKSUM
        zvol0                     DEGRADED     0     0     0
          mirror-0                DEGRADED     0     0     0
            gpt/sdisk1            ONLINE       0     0     0
            13953654332474917058  UNAVAIL      0     0     0  was /dev/gpt/ndisk1

errors: No known data errors
$

镜子用隔板准备

# gpart create -s gpt ada2
ada2 created
# gpart show ada2
=>         40  11721045088  ada2  GPT  (5.5T)
           40  11721045088        - free -  (5.5T)

# gpart add -t freebsd-zfs -a 4k -l sdisk2 ada2
ada2p1 added
# gpart show ada2
=>         40  11721045088  ada2  GPT  (5.5T)
           40  11721045088     1  freebsd-zfs  (5.5T)

# gpart show -l ada2
=>         40  11721045088  ada2  GPT  (5.5T)
           40  11721045088     1  sdisk2  (5.5T)

#

启动第二台同步

$ zpool replace zvol0 13953654332474917058 gpt/sdisk2
$ zpool status zvol0
  pool: zvol0
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sun Jan 29 13:38:15 2023
        12.8G scanned at 692M/s, 492K issued at 25.9K/s, 1.49T total
        0B resilvered, 0.00% done, no estimated completion time
config:

        NAME                        STATE     READ WRITE CKSUM
        zvol0                       DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            gpt/sdisk1              ONLINE       0     0     0
            replacing-1             DEGRADED     0     0     0
              13953654332474917058  UNAVAIL      0     0     0  was /dev/gpt/ndisk1
              gpt/sdisk2            ONLINE       0     0     0

errors: No known data errors

第二台同步大约需要 14 小时。

$ zpool status zvol0
  pool: zvol0
 state: ONLINE
  scan: resilvered 1.49T in 14:11:00 with 0 errors on Mon Jan 30 03:49:15 2023
config:

        NAME            STATE     READ WRITE CKSUM
        zvol0           ONLINE       0     0     0
          mirror-0      ONLINE       0     0     0
            gpt/sdisk1  ONLINE       0     0     0
            gpt/sdisk2  ONLINE       0     0     0

errors: No known data errors
$

容量扩展

交换和数据同步已顺利完成，但仍有一些工作要做。因为仅仅更换了硬盘，2TB→6TB 的容量扩展还没有生效。

再次确认 zvol0 的容量时，SIZE 显示为 1.81T，与更换前相同。但仔细观察到 EXPANSZ 显示为 3.62T，可知有 3.62TB 的扩展空间。

$ zpool list zvol0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zvol0  1.81T  1.49T   333G        -     3.62T     5%    82%  1.00x    ONLINE  -
$

这个容量扩展的设置是 ZFS 池的 autoexpand 属性。首先检查当前的 autoexpand 值，通常默认为 off。

$ zpool get autoexpand zvol0
NAME   PROPERTY    VALUE   SOURCE
zvol0  autoexpand  off     default
$

尝试将 autoexpand 设置为 on。

$ zpool set autoexpand=on zvol0
$ zpool get autoexpand zvol0
NAME   PROPERTY    VALUE   SOURCE
zvol0  autoexpand  on      local
$

但仅仅将 autoexpand 设置为 on 并不会改变容量。

$ zpool list zvol0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zvol0  1.81T  1.49T   333G        -     3.62T     5%    82%  1.00x    ONLINE  -
$

为了扩展容量，您需要设置 autoexpand=on 并执行 zpool online -e 。

$ zpool online -e zvol0
missing device name
usage:
        online [-e] <pool> <device> ...
$

由于忘记指定设备名称导致错误😅，但在正常情况下，指定设备名称是必需的。当使用 -e 选项时，好像可以不指定设备名称。无论如何，在 zpool online -e 中，只需指定池内的任何一个设备名称即可解决问题。

如果重新指定设备名称并执行，容量增加到了 5.45TB^ 4^。

$ zpool online -e zvol0 gpt/sdisk1
$ zpool list zvol0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zvol0  5.45T  1.49T  3.97T        -         -     1%    27%  1.00x    ONLINE  -
$

这次在更换硬盘后，我们修改了 autoexpand 属性，如果在更换之前设置好，那么在第二台同步完成后容量将会自动扩展。此外，autoexpand 不仅在镜像中可以使用，在 raidz 等配置中也同样适用。

2023 年 07 月 16 日添加：收到关于使用 zpool online -e 进行扩展时不需要设置 autoexpand 属性的指示。autoexpand 属性被用于自动扩展容量的设置。

更换完成后

由于新硬盘的传输速度提高，我能感受到整体性能有所提升。虽然 CPU 已经使用了 10 年以上，但主要用途是文件服务器，所以似乎可以继续使用。

1. 因为在 ZFS 中采用写时复制的方式进行数据更新，当剩余空间不足时，与其他文件系统相比性能会急剧下降(在硬盘上更为明显)，因此不建议使用到容量的极限。使用到什么程度会导致性能下降取决于工作集的配合，因此不能简单地说清空容量是否会对 ZFS 的性能造成影响，就算是其他文件系统中不受影响的剩余空间，在 ZFS 中也可能导致性能下降。

2. 即使将 ndisk2 分离，使用 zpool import -D 可以恢复数据，但我没有尝试过。

3. 「resilver」这个词是我开始使用 ZFS 时了解到的，原意是指擦拭银饰品，但在 ZFS 中表示 RAID 正在进行恢复。

4. 硬盘的 TB 容量以十进制表示，所以 6TB 相当于 6,000,000,000,000 字节，而以二进制表示的 1TB 是 1,099,511,627,776 字节，因此是 5.45TB。

FreeBSD 中如何指定 CPU 类型

• https://qiita.com/nanorkyo/items/e0417d8c1388750cb72c

• FreeBSD

• CPU

• 编译器

• 优化

发布于 2021 年 03 月 11 日，最后更新于 2021 年 03 月 18 日

开始

在查找如何指定 CPU 型号时^1^，突然想起自己好像没有看过日文文档…于是我下定决心进行调查备忘录。

这个规定基本上是追加的，所以我打算查看每个操作系统版本之间的差异 bsd.cpu.mk ^ 1 ^。我会先查找版本的差异并告诉你。请注意，区分大小写。

如果你使用的是最新的 CPU，并且未在此列表中，那么请指定最接近的 CPU 类型。大多数 CPU 都继承了之前架构的功能^ 2 ^，所以不应该会输出错误的代码。

现在让我们来谈谈 CPU 类型是什么，通过在 /etc/make.conf 中指定正在使用的 CPU，编译时将生成针对该 CPU 优化的代码，这就是所谓的 CPU 类型。对那些使用包管理系统的人来说，这是无关紧要的^ 3 ^。

注意事项

• 这里列出的内容不能保证适用于旧的 CPU 架构进行编译。

• 特别是在编译器从 GCC 4 切换到 LLVM 时，可能会导致之前可用的 CPU 类型不再被支持。

• 正在调查１０．０－Ｒ。不调查比这更旧的版本。

• 怎么处理其他的架构呢。有些复杂的和前后关系不明确，难以解释。

• 在其他架构中，一些消失了（ＩＡ６４，ＳＰＡＲＣ６４），一些增加了（ＡＡＲＣＨ６４，ＲＩＳＣＶ），各种各样。

CPU 类型（amd64 环境和 i386 环境）

※调查版本：13.0、12.2、12.1、12.0、11.4、11.3、11.2、11.1、11.0、10.4、10.3、10.2、10.1、10.0

• 尽量确保最新的项目排在前面进行调查

• 希望将 amd64/i386 双用 CPU 和仅 i386 的 CPU 进行区分

• 当搭载 SSE3 的时期， Opteron 是什么来着？还有， Blue Lightning 和 Cyrix 之类的，还有 NexGen ，所有的回忆都飘到哪里去了！...

1. /usr/share/mk/bsd.cpu.mk

2. 偶尔会回归到原点的架构存在。 ↩

3. 因为在包构建系统内指定了 CPU 类型而进行编译。 ↩

4. 向后和向前的兼容性。

使用 BIOS 引导和 UEFI 引导的 GPT 分区的区别和制作方法

• 原文链接：https://qiita.com/nanorkyo/items/429d7382a418b38de4d3

• FreeBSD

• BIOS

• UEFI

最后更新于 2020-11-11 发布于 2018-12-13

近年来在 FreeBSD 中，“分区”几乎总是使用 GPT（GUID Partition Table）无论磁盘大小如何，这几乎是不言而喻的选择。但是，“BIOS 引导”和“UEFI 引导”在分区方案上有细微差异^1^。本文将阐明两者之间的区别，并展示可用于引导的分区配置示例。

前提条件

本文假定操作的是 SATA 硬盘，设备名称表示为（/dev/）ada0。如果操作的是 SAS/USB 硬盘，则设备名称应为 daｎ；对于 NVMe 硬盘应为 nvdｎ；对于 eMMC 存储则为 mmcsdｎ（其中ｎ为 0 或更大的整数）。

共同事项

因为它是 GPT 分区，所以在任何步骤中，都有一些必须执行的命令^ 2^。

gpart create -s GPT ada0

为了简化讨论，假定要划分如下所示的分区。

在本次講話中，ada0p2 和 ada0p3 被視為相同的共同步驟。換句話說，執行以下命令在「當前時刻無實際用處」^4^^5^^6^。

gpart add -t freebsd-ufs  ada0
gpart add -t freebsd-swap ada0

BIOS 启动的情况下

gpart add -t freebsd-boot -b 40 -s 984  ada0

• 定义“freebsd-boot”分区作为引导分区。如果不是“freebsd-boot”，引导程序将无法找到该区域。

• 从逻辑块地址（LBA）40 处开始，指定起始位置为 40 个扇区（LBA 40）。

  • GPT 分区头大小（GPT 头大小）为 34 扇区^ 7 ^，但对于 4KiB 扇区兼容磁盘，扇区起始位置将被舍入为 8 的倍数。

  • 可能为了考虑这一点，最近 GPT 头大小变成了 40 扇区（从哪个版本开始尚未确认）。

• 个人建议指定区域大小（ -s ）为 984 个扇区。

  • 下一个区域（freebsd-ufs）从 512Kib 起始位置开始有好处 ^ 8 ^。

  • 由于引导加载程序的限制，必须将大小限制在 545Kib 以下（本次大小为 492Kib）。

  • 因此，缩小没有意义，也没有必要进一步扩大。

gpart bootcode -b /boot/pmbr -p /boot/gptboot    -i 1 ada0
        または
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

完成引导加载程序的安装。引导加载程序将在ＦｒｅｅＢＳＤ分区^ 9^^ 10^上搜索，并将控制转移到 /boot/loader 或 /boot/zfsloader。

对于ＵＥＦＩ启动

gpart add -t efi -b 40 -s 409560 ada0

• 定义一个名为「efi」的分区作为引导分区。如果不是「efi」，ＵＥＦＩ将无法检测到这个区域。

• 从扇区 40（LBA40）指定开始位置（ -b ）。

  • GPT 分区标头大小（GPT 标头大小）为 34 个扇区^7^，但是对于 4Kib 扇区对齐的磁盘来说，扇区起始位置会被舍入到 8 的倍数。

  • 最近，为了考虑这一点，GPT 标头大小可能变为了 40 个扇区（版本未知）。

• 领域大小的指定（ -s ）建议指定为 40960 个扇区。

  • 对于这个设置，freebsd-ufs 的下一个区域的起始位置将从 200 MiB 的边界开始 ^ 8 ^。

  • 领域大小严格来说略小于 200 MiB（少了 40 个扇区，即 20 KB），不过这个误差可以忽略。

  • 目前（11.2-R 版本）/boot/boot1.efifat 引导区的大小为 800KiB。

  • 在 10.4-R 或 11.1-R 版本中，建议将此区域保留 200MiB，考虑到与其他操作系统（如 macOS）的兼容性设置，因此如果单独启动 FreeBSD，当前的 800KiB 大小是没有问题的。

  • 在 bsdisnstall: increase EFI partition size to 200MB 的讨论中，认识到对于类似固件更新工具的 EFI 应用程序还需要空间，因此认为 800KiB 的大小实在是太少了。

newfs_msdos -F 32 -c 1 -L EFISYS /dev/ada0p1
mount -t msdosfs /dev/ada0p1 /mnt
mkdir -p /mnt/EFI/BOOT
cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
umount /mnt
        または
gpart bootcode -p /boot/boot1.efifat -i 1 ada0

到此为止，启动加载程序的安装就完成了。启动加载程序会查找 FreeBSD 区域^ 11^ 来继续引导过程。

常见问题及解答

问：怎么跟 Bootable UEFI U 盘或硬盘上的步骤不一样啊？

一切都好。沒問題。時代已經追上我了。

問：經過一番調查，似乎對於在 /boot/boot1.efifat 目錄中寫入內容，有許多不同的步驟，哪一個才是正確的？

一切都好。沒問題。但是不建議使用任何這些步驟。

/boot/boot1.efifat 是分区镜像本身。极端来说可以认为是 dd if=/dev/ada0p1 of=/boot/boot1.efifat 的内容。实际在构建时正在做类似的事情。

因此，无论是使用 dd(8)还是 gpart(8)写入都是一样的。但毫无疑问，更智能的选择是使用 gpart(8)。

但最好不要使用/boot/boot1.efifat。关于之前提到的 200 MiB 扩展的问题，使用它会将 200 MiB 区域中的 800 KiB 变成只能访问的区域。

尽管已经保留了 200 MiB 的空间，但却无法运行 EFI 应用程序。

在新安装中没有问题，但如果想要更新，可能会走入不必要的方向而消失。

在进行操作系统更新时，是否需要更新引导分区？

常常需要但并非总是必要。然而…

1. 如果从 UFS 启动，由于 UFS 格式的稳定性，bootloader 代码没有更改，因此几乎不会出错。如果出现问题，可能是在从 UFS1 升级到 UFS2 时。因此，即使未更新，也不会出现问题，或者可能不会被发现。

2. 如果从 ZFS 启动，由于 ZFS 格式的不稳定性，bootloader 代码会发生变化，因此需要经常维护，否则可能无法启动。在这方面， /usr/src/UPDATING 的 ZFS notes 中提到了“当升级启动的 ZFS 池版本时，需要更新 bootloader”的说明。

从这个角度来看，更新引导程序的步骤也应该进行系统化。

对于 freebsd-boot 分区，只需使用 gpart bootcode -p 进行覆盖即可，但对于 efi 分区，则需要在挂载后，使用 cp 进行覆盖（详见后文）。

问：如果分区号不是 1，那么任何号码都可以吗？

不要紧，最好不要做。

MBR 有 2 TiB 的限制，如果使用后续区域，BIOS 可能无法找到引导加载程序（freebsd-boot）。此外，如果分区编号与区域顺序不匹配，将会变得很麻烦。

我们处理的是 GPT，所以 MBR 应该不相关。

很遗憾。因为 GPT 是 MBR 的更高兼容性版本，所以别想了。

就 UEFI 启动来说，GPT 会被解释为 GPT，所以可以断然地说“无关紧要”。

但对于 BIOS 启动，GPT 会被看作 MBR 来操作。因此，在前 2TiB 的区域内需要存在引导加载程序（freebsd-boot）。不过，仅仅存在是问题的关键，并不关心分区号是多少。

问：系统是 UEFI 启动还是 BIOS 启动我不知道！

答：启动 Live CD 后执行 sysctl machdep.bootmethod 命令，可以确认是 UEFI 启动还是 BIOS 启动。

【附录】更新引导加载程序

BIOS 启动时

gpart bootcode -p /boot/gptboot    -i 1 ada0
        または
gpart bootcode -p /boot/gptzfsboot -i 1 ada0

UEFI 启动时

首先，在 /etc/fstab 中添加以下设置。

# Device    Mountpoint FStype  Options Dump Pass #
/dev/ada0p1 /boot/efi  msdosfs rw      0    0

接下来创建 /boot/efi 目录。

mkdir -p /boot/efi

手动挂载一次，当然也可以忽略重启后的问题。

mount /boot/efi

以后的更新如下。

cp /boot/loader.efi /boot/efi/EFI/BOOT/BOOTX64.efi

参考文献

• gpart(8)的手册

• FreeBSD 的启动过程

• UEFI - FreeBSD 维基

• FreeBSD 10.4 发布说明

• FreeBSD 11.1 发布说明

• bsdinstall：将 EFI 分区大小增加到 200MB

• GPT 和 MBR 有什么区别？

• 通过命令行创建 FreeBSD 启动分区等

• 有关 FreeBSD/UEFI

1. 在 BIOS 中通常被称为“MBR（Master Boot Record）引导”，但由于 2TB 限制和几乎消失了多重引导需求，现在已经统一为 GPT 启动（？）

2. 此命令的执行无需任何更改。从兼容性的角度看，根本不应修改默认值。

3. 虽然有时可能想将 freebsd-ufs 更改为 freebsd-zfs，但本次讨论将略过此内容。

4. 实际上，需要使用 -s サイズ 选项来指定大小。如果未指定，则表示将剩余的全部内容作为意味着不能分配交换空间。

5. 注意执行顺序。如果继续进行，将无法分配启动区域（分区编号将错一位）。

6. 尽管可以使用 -i パーティション番号 或 -b 開始位置 -i パーティション番号 选项进行控制，但作为基本说明，我们愿意放弃。

7. LBA 0 到 LBA 33 是 GPT 头区域。

8. 近来，各种媒体（包括 4Kibytes HDD 和 NAND Flash 等）中充当边界的最小公倍数（即使有 512KiB，也适用于任何媒体）并不是一个糟糕的数字（应该）。

9. gptboot 在 freebsd-ufs 区域中查找 /boot/loader，gptzfsboot 在 freebsd-zfs 区域中查找 /boot/zfsloader。 ↩

10. 仅与存储着"/boot/(zfs)loader"的领域的文件系统相关联，因此在引导时会被视为 UFS，而在根目录中会被视为 ZFS，因此对于混合环境中的解释将作为"UFS"来处理。

11. 尽管在搜索 freebsd-ufs 或 freebsd-zfs 领域时，它们的优先级和控制在这里很难解释，因此请参考参考资料。虽然并不复杂。但是由于需要对文件系统级别进行调整，因此需要深入了解一下。

• 原文地址：Apple’s Open Source Roots: The BSD Heritage Behind macOS and iOS

• 原作者：Jason Perlow

• 原文发布时间：2024 年 7 月 8 日凌晨 5:00

认识到 BSD 在苹果成功中的重要性，有助于我们更好地理解开源贡献在塑造我们日常使用的技术中之价值。

想一想：苹果时尚且易用的设备，如强大的 MacBook 和无处不在的 iPhone，它们的可靠性和性能，在很大程度上得益于开源操作系统。那么，苹果究竟使用的是哪款开源操作系统呢？尽管常有人说，苹果的 macOS、iOS、iPadOS、watchOS、visionOS 和 tvOS 直接源自 FreeBSD，但其实这是一种误解。

这些操作系统的真正基石在于苹果较早期的操作系统技术与 NeXTSTEP 的结合，而 NeXTSTEP 本身是 Mach 和 BSD 的混合体——早于 FreeBSD。尽管多年来，FreeBSD 的一些用户空间元素被整合进上述操作系统，但苹果的内核（XNU）并不直接来源于 FreeBSD。然而，它们确实共享一脉共同的 BSD 传统。

图片来源

理解 BSD 各版本

要了解苹果操作系统的发展，理解不同版本的 BSD（伯克利软件发行版）及其影响至关重要：

伯克利的原始 BSD

BSD 起源于 1970 年代末的加州大学伯克利分校。作为对 AT&T 原始 UNIX 操作系统的增强，BSD 引入了许多成为现代操作系统标准的创新。第一个版本 1BSD 发布于 1977 年，随后是 1978 年的 2BSD。重要版本包括 4.1BSD（1981 年）和 4.2BSD（1983 年），它们引入了快速文件系统（FFS）、TCP/IP 网络和套接字 API，这些基础要素至今仍在使用。

FreeBSD

FreeBSD 是从原始 BSD 衍生而来的，以其出色的性能、先进的网络功能和广泛的硬件支持而著称。它源自 1993 年的 386BSD 项目，至今广泛应用于服务器、桌面和嵌入式系统。FreeBSD 强大的性能和可靠性使其成为高可用性应用和互联网基础设施的首选。

NetBSD

NetBSD 以其在多种硬件平台上的可移植性而闻名。其座右铭“Of course it runs NetBSD”（它当然可以运行 NetBSD）体现了它在各种硬件架构上运行的能力，从服务器和桌面到嵌入式设备和大型机。自 1993 年成立以来，NetBSD 一直是 BSD 系列中可移植性和简洁设计的典范。

OpenBSD

OpenBSD 是于 1995 年，从 NetBSD 复刻出来的，重点关注安全性、正确性和代码简洁性。它以严格的安全实践而闻名，并且是许多安全技术的先驱，如 OpenSSH、PF（包过滤器）和安全内存管理技术。OpenBSD 对安全性的承诺使其成为那些安全至关重要的应用程序的首选。

其他衍生 BSD

出现了几款衍生的 BSD，每款变种都有其独特的重点和增强功能。例如，DragonFly BSD 注重性能和可扩展性，而 Darwin 则是苹果 macOS 和 iOS 的内核。

Darwin 和 XNU：苹果操作系统的内核

macOS 的核心是 XNU 内核，这是一款混合内核，结合了 Mach 微内核、BSD 组件和 I/O Kit（设备驱动的面向对象 API）。这种集成确保了 macOS 受益于 BSD 类 Unix 的强大稳定性，同时利用了 Mach 微内核的灵活性。

Darwin 是苹果操作系统（macOS、iOS、watchOS、tvOS 和 iPadOS）的开源基石，它包括了 XNU 内核、各种 BSD 组件和其他开源项目。Darwin 的起源可以追溯到 NeXT，这是一家由史蒂夫·乔布斯在 1985 年创办的公司，他离开苹果后创办了这家公司。NeXT 开发了 NeXTSTEP，这是一种基于 Mach 微内核和 BSD 的操作系统。它发展成为 OpenStep，并最终在史蒂夫·乔布斯回归苹果时演变成 Darwin，带回了 NeXT 的技术。

2000 年，苹果发布了 Mac OS X 的一些核心组件（现在的 macOS）作为开源项目，采用 Apple 公共源代码许可证（APSL），允许更广泛的社区受益并为其开发做出贡献。这些组件包括 launchd、Grand Central Dispatch 和 Core Foundation，其中一些后来在更宽松的 Apache 许可证下重新授权，以促进更广泛的应用。然而，高级组件如 Cocoa 和 Carbon 框架仍然是专有的，以保持苹果的竞争优势。GPL 和 BSD 许可的组件未重新授权，保持了其原有的开源许可证。

详细时间线

• 1969 年：AT&T 贝尔实验室开发了 UNIX 操作系统。

• 1977 年：加州大学伯克利分校发布了 BSD 的首个版本（1BSD），作为对 AT&T 原始 UNIX 操作系统的增强。

• 1978 年：2BSD 发布，继续在 1BSD 的基础上进行改进和工具开发。

• 1980 年：3BSD 发布，加入了更先进的特性和改进。

• 1983 年：4.2BSD 发布，包含了像快速文件系统（FFS）和 TCP/IP 网络这样的重大创新，这些成了未来操作系统的基础元素。

• 1985 年：史蒂夫·乔布斯在离开苹果后创办了 NeXT 公司。

• 1989 年：NeXTSTEP 发布，它基于 Mach 微内核和 BSD，结合了先进的功能和面向对象设计。

• 1993 年：FreeBSD 和 NetBSD 从 386BSD 衍生出来，分别专注于性能、安全性和可移植性。

• 1995 年：OpenBSD 从 NetBSD 复刻出来，强调安全性和代码正确性。

• 1996 年：苹果收购 NeXT，带回了 NeXTSTEP 技术，为 Mac OS X 奠定基础。

• 2000 年：苹果发布了基于 Darwin OS 的 Mac OS X 第一版。这个操作系统结合了 Mach 微内核和来自 BSD 的组件，成为苹果现代操作系统的核心。

• 2006 年：OpenDarwin 停止发布，标志着苹果不再提供可独立安装的 Darwin OS 版本。

BSD 组件在 macOS 中的演变与整合

苹果的 macOS 是一款混合化的操作系统，集成了来自不同 BSD 变种的各种组件，形成了一个强大且多功能的平台。macOS 的内核是 XNU，它是一款混合内核，结合了来自 Mach、NeXTSTEP 和 OpenStep 的元素，并且加入了来自 BSD 的其他组件。这一基础架构利用了每个系统的优势，提供了一款可靠且高性能的操作系统。

网络栈：macOS 的网络栈源自 FreeBSD 和其他 BSD 变种，集成了它们可靠和高效的网络功能。早期的网络元素，如 TCP/IP 栈，受 FreeBSD 设计的影响，因其性能和可靠性而闻名。包括最初为 FreeBSD 开发的 kqueue 事件通知接口，也增强了 macOS 处理 I/O 事件的能力。苹果的实现结合了来自 BSD 和 FreeBSD 的代码，但也包含了像网络内核扩展（NKE）、面向对象的设备驱动系统（IOKit）以及磁盘仲裁层等独特机制。这些组件与传统 BSD 实现有所不同。

虚拟文件系统：macOS 的虚拟文件系统组件来自 FreeBSD 和其他 BSD 系统，确保了稳定和安全的文件管理系统。

内存管理：macOS 的内存管理系统主要来源于 Mach，并受 NetBSD 的影响，特别是在共享/合并缓冲区缓存方面。

进程模型：macOS 的进程模型基于 Mach，使用 Mach 系统线程作为进程子系统的基础层。

Mach IPC 和安全性：Mach IPC 广泛应用于 macOS 和 iOS 的内核及用户空间，引入了进一步的差异。例如，Mach Security Trailers 是受信任的 IPC 的基础部分。应用程序沙箱中使用的强制访问控制（MAC）机制也与 *BSD 系统中的机制大相径庭。

随着时间的推移发生的分歧：由于 FreeBSD 不愿意整合 UNIX03 兼容性更改，导致了分歧，尽管有一些混合的努力，像 libc 和 libm 这样的库还是出现了复刻。此外，像 NeXTBSD 项目这样的倡议，旨在将像 launchd、Mach IPC 和 Grand Central Dispatch 等苹果的技术带到 FreeBSD，但这些努力未能得到普遍支持。结果，代码库继续出现分歧，尤其是在苹果推进定制芯片支持和优化时，进一步拉大了它们之间的差距。

已知的集成和贡献：macOS 在很大程度上受益于 FreeBSD，尤其是在网络概念上。尽管 macOS 并未完全采用 FreeBSD 的网络栈，但它集成了几款 FreeBSD 衍生的组件，经过调整以满足其独特的需求。macOS 中的早期网络元素，如 TCP/IP 栈，受 FreeBSD 设计的影响，以其性能和可靠性而著称。此外，像最初为 FreeBSD 开发的 kqueue 事件通知接口也被集成到 macOS 中，增强了它处理 I/O 事件的能力。

对苹果产品的影响

苹果对 BSD 代码的采用遍及其整个产品线。macOS 驱动着 Mac 台式机和笔记本，iOS 运行在 iPhone 上，iPadOS 运行在 iPad 上，watchOS 运行在 Apple Watch 上，visionOS 运行在 AR/VR 设备上，tvOS 运行在 Apple TV 上。每款操作系统都包含了 BSD 组件，突显了 BSD 在苹果生态系统中的广泛影响。

BSD 的稳健性、安全性和性能特点在塑造苹果操作系统的稳定性和效率方面发挥了重要作用。集成 BSD 衍生的网络概念和组件，使得 macOS 能够提供高性能的网络功能，使其成为消费者和企业应用的可靠选择。BSD 的先进内存管理和进程调度也对 macOS 的响应能力和多任务处理能力作出了贡献。

通过将 BSD 的强大特性与其专有技术相结合，苹果创造了一系列稳定、高效、创新且功能强大的操作系统。这种共生关系凸显了开源贡献在苹果软件生态系统持续演变中的重要性。

苹果对开源的贡献与利用

苹果公司在高度依赖 BSD 的同时，也积极参与着开源社区。公司通过其开源网站和 GitHub 发布了多项 Darwin OS 组件，包括 XNU 内核、各种用户空间工具和库。这些贡献确保了开源社区能够从苹果的创新和改进中受益。

苹果会定期更新其开源项目，发布 Darwin OS 组件的新版本。这些更新通常与新的 macOS 和 iOS 版本发布同步，体现了苹果对开源社区的持续承诺。通过共享其改进和增强功能，苹果推动了开源软件开发，为开发者和用户带来益处。

Darwin OS 的现状

Darwin OS 是苹果操作系统的开源核心，目前已不再作为完整的、可安装的系统发布。苹果将 Darwin 的各个组件分开发布，例如 XNU 内核仓库在 GitHub 上，用户空间工具则发布在苹果的开源网站上。这种分散的发布策略使得从苹果的官方渠道组装完整的 Darwin OS 变得困难。

通过 OpenDarwin 项目，苹果曾使这些组件能够单独安装并作为独立系统存在。然而，由于开发的兴趣有限和分歧逐渐加大，OpenDarwin 于 2006 年停止发布。苹果当时的目标值得称赞，但随着复刻过多，最终无法维持该项目，导致了当前的碎片化分发方式。

尽管从苹果处获得完整的 Darwin OS 存在挑战，开源社区仍尝试将这些组件整合为可安装的操作系统，取得了一定的成功。像 PureDarwin（以及之前的 OpenDarwin）这样的社区驱动项目，旨在通过整合苹果发布的各种开源组件，提供可用的 Darwin OS 版本。这些项目展现了开源开发的合作精神，并证明了 Darwin OS 作为独立操作系统的潜力。

苹果与 BSD 的现有关系

苹果与 BSD 代码的关系仍然相当神秘。尽管苹果在开源方面作出了重大贡献，但该公司在操作系统中 BSD 代码的具体使用程度仍然较为模糊。这种封闭的开发过程使得很难准确指出 macOS、iOS 及其他苹果系统中有多少部分仍依赖于 BSD 基石。BSD 许可证的宽松性允许苹果使用并修改代码，而无需公开其使用方式和位置，这与 GPLv2 的“传染性”要求有所不同，后者要求修改后的代码必须共享。

苹果的开源软件策略随着时间的推移发生了变化。公司将焦点从 CoreOS 的开源组件转向了其他领域，如编程语言和编译器技术。苹果投入大量时间和精力开发项目如 Swift、clang 编译器和 LLVM 运行时。这些项目代表了苹果对开源社区的主要贡献，并展示了苹果与 BSD 之间的技术转移，尤其是在编译工具链方面。

此外，随着苹果对原始 BSD 组件的大量修改，传统 BSD 代码与现代改编之间的界限变得模糊。苹果在不断修改和扩展这些组件后，已经很难区分哪些部分是直接继承自 BSD 的，哪些是苹果的创新。这种不透明性限制了我们对 BSD 在苹果产品中全貌的理解，也突出了 BSD 的宽松许可证与 GPL 的传染性要求之间的差异。

有证据表明，苹果仍在其操作系统中使用着当前的 BSD 组件。最近，2024 年 6 月的提交由 Klara 公司提交，该公司代表多个客户（如 NetApp）向 FreeBSD 项目提交代码，这表明 FreeBSD 代码的持续集成和使用，证明了尽管苹果的开发过程封闭，BSD 代码（尤其是 FreeBSD）仍然是其操作系统的重要组成部分。

市场影响与采用

苹果在其产品中使用 BSD 对消费电子行业和创意内容行业产生了重大影响。BSD 的稳健性、安全性和性能使得苹果设备对消费者和专业人士极具吸引力。电影、音乐制作、图形设计等创意领域的行业尤其青睐苹果产品，因为它们可靠且功能强大。

BSD 的先进内存管理、进程调度和高性能网络能力确保了苹果的桌面和笔记本电脑为高要求的应用提供所需的性能。这使得 macOS 成为视频编辑、音乐制作和图形设计的优秀选择，在这些领域，稳定性和性能至关重要。

其他行业利用 BSD

虽然苹果集成 BSD 对其成功起到了关键作用，但 BSD 的特性也使其成为其他各行各业供应商的首选。例如，NetApp、Netflix、Juniper（均为 FreeBSD 用户）等公司，利用 BSD 的先进功能应用于不同的领域：

• 安全性： BSD 强大的网络功能和安全措施使其在安全通信和数据保护领域尤为适用。

• 互联网流量管理： BSD 可靠的 TCP/IP 栈确保了高数据量的有效处理，使其在互联网流量管理中大有作为。

• 嵌入式系统： BSD 的先进内存管理和进程调度提高了嵌入式系统的效率和可靠性。

• 存储解决方案： NetApp 等公司利用 BSD 提供强大而高效的存储解决方案。

通过认识到 BSD 的广泛应用，我们可以更好地理解 BSD 对苹果产品以及广泛行业的影响，彰显了这一开源操作系统的多样性和稳健性。

产品数量与市场覆盖

苹果发布了多款运行 macOS、iOS、iPadOS、watchOS、tvOS 和 visionOS 的产品。因此，全球许多设备中都包含 BSD 代码。这些设备的出货量和运行数量，包括嵌入式设备、桌面/笔记本电脑，甚至苹果公司数据中心内的服务器计算机，可能与运行 Linux 的设备和系统数量相当，甚至更多。这强有力地证明了 BSD 在苹果生态系统中的广泛采用与影响。

苹果的设备遍布各行各业，满足不同消费者群体的需求。这种广泛的市场覆盖展示了 BSD 对苹果操作系统成功和可靠性的贡献。来自 BSD 的无缝用户体验、强大性能和安全性使得苹果产品成为全球数百万用户的首选。

展望

苹果在开发其操作系统（包括 macOS、iOS、iPadOS、watchOS、visionOS 和 tvOS）时，极度依赖 BSD 代码。通过集成 BSD 组件，苹果为创新、稳定性和性能奠定了坚实的基础。尽管苹果系统中 BSD 代码的具体使用程度不透明，但显然，BSD 在苹果产品的设计和功能中起到了重要作用。

展望未来，苹果可能会继续利用 BSD 的优势，并为开源社区作出贡献。BSD 和苹果操作系统的不断演进，暗示了开源合作在技术进步中的重要性。认识到 BSD 在苹果成功中的重要性，有助于我们更好地理解开源贡献在塑造我们日常使用技术中之价值。

参考文献与进一步阅读：

• Apple Open Source

• Apple GitHub

• FreeBSD Project

• PureDarwin Project

Jason Perlow 是一位技术专家，拥有超过二十年的经验，曾在财富 500 强公司中整合大型异构多供应商计算环境。他曾担任 Linux 基金会的前编辑总监。目前，他在佛罗里达州科勒尔斯普林斯经营着自己的技术媒体咨询公司——Argonaut Media Communications LLC。

通过为 ZFS 池配置镜像来消除无效数据的影响

上次更新于 2022-12-26 发布于 2022-12-23

开始

在之前发布的“尝试破坏 ZFS 池”的文章中，我们发现 ZFS 能够正确检测到磁盘上的非法数据。

能够检测到非法数据要比读取无法检测到非法数据的文件系统并导致错误操作要好得多。但是如果能够检测到非法数据，那么是否无法恢复它呢？这种想法也是很自然的。

如果配置冗余池，则即使存在非法数据，也可以获得正确的数据。具体来说，使用镜像、RAID-Z、RAID-Z2 等池。

在这里，将尝试使用镜像配置的 ZFS 池进行类似于破坏 ZFS 池的实验。

在 2022-12-26 进行 scrub 后，补充了磁盘状态。

准备 ZFS 镜像池

为实验准备两台 USB 连接的硬盘，分别创建一个 4GB 的分区，并准备一个镜像配置的 ZFS 池。

硬盘为/dev/da1，/dev/da2，在 GPT 下创建分区，并分别创建标记为 tt1 和 tt2 的分区。

这样，两个 HDD 上的每一个都创建了一个用于镜像的分区。

将这两个分区组合起来创建一个 ZFS 镜像池。当然，就像上次实验一样，不会进行 ZFS 压缩。

如下所示，已经完成了镜像配置的 ZFS 池。

写入虚拟数据

现在使用 dd 命令以零数据填充文件系统，就像上次的实验一样。

破坏写入的数据

然后强行写入垃圾数据，故意制造 ZFS 错误。这是为了验证镜像冗余和 ZFS 修复功能，因此仅在 da1 侧写入垃圾数据。

通常从镜像配置的磁盘读取时，为了负载平衡和加速，会交替访问两个磁盘。在 ZFS 镜像配置下也会有类似的行为。因此，与上次一样破坏一个块是无法访问到该块的正常驱动器侧的，而是会访问到另一个正常的驱动器侧。因此，这次我们将写入约数十 MB 的数据，更大的区域数据将会引起错误。正好内核接近 30MB，我们将写入它并试图破坏它。

读取损坏数据部分

为了确认是否发生错误，仅使用 da1 一侧进行导入。由于这是 USB 硬盘，因此物理上拔掉 da2 会更容易。

无法访问 da2 侧的 gpt/tt2。将继续导入 ztest。

只有一个驱动器，但/ztest/dummy 确实存在。那么让我们实际读取它。为了使数据内容可见，我们将使用 hd 命令进行读取。

无法读取文件，发生了错误。

镜像配置下的读取

尝试重新配置为镜像并进行相同操作。

在这里连接已拆下的 DA2 端的 USB HDD。

GPT / TT2 端目前处于在线状态。现在将导入 ztest。

导入成功，现在让我们像刚才一样读取/ztest/dummy。

能够正常读取，并确认所有内容都为 0。检查 ztest 的状态后，似乎没有问题。

使用 scrub 检查磁盘完整性

因为 ZFS 可能存在无法读取的部分，所以执行 scrub 以确认完整性。

等待 scrub 完成后，再查看状态。

可以看到 da1 侧的 tt1 出现了大量的校验和错误。

再次读取数据

最后再次尝试读取数据。为了排除操作系统磁盘缓存的影响，先导出再导入后再执行。

尽管发生了错误，但由于镜像配置的帮助，成功读取了正确的数据。

【补充】执行 scrub 后的 da1 状态

文章发布后，我们收到了一个问题：“通过 scrub，da1 侧是否被修复并可读取？”实际上，scrub 执行后显示 scan: scrub repaired ，因此我进行了确认。

尽管实验环境已被销毁，我会重新进行部分内容的省略，破坏 da1 侧数据并进行 scrub，然后尝试读取 da1 侧数据。

从创建 ZFS 镜像池到破坏 da1 侧数据，执行 scrub，然后将池导出。

由于导出成功，我将物理地移除 da2 端口，尝试导入并读取 da1 端口。

我成功无误地读取了被破坏的 da1 端口的全部数据。也就是说，通过 Scrub 写回并修复了数据。而且实际导入后检查 status，CKSUM 的值也是 0(截屏失败…)。

再次尝试，将 da2 连接到导出的 ztest 并进行导入。

这样错误已被清除。

汇总

通过在 ZFS 中将磁盘配置为镜像或 RAID-Z，我们确认可以避免部分数据错误。此外，通过执行 scrub 可以修复数据，我们也发现修复后的数据可以恢复到原始状态。

无论是 ZFS 还是其他卷管理器或 RAID 系统，正确地配置镜像或 RAID 可帮助规避部分数据错误。修复能力可能取决于具体实现。

FreeBSD ports 开发技术研究

发布于 2024 年 01 月 07 日

开始

当我试图创建ports时，我参考了模板和手册进行工作。在这个过程中，我遇到了一些不符合模式的情况，或者一些特殊行为的情况。我不知道如何跟踪这些情况，如何巧妙地处理它们，这让我感到很困惑。

例如，如果要从ports进行安装（ make install ）的话，通常会按照以下顺序进行。

另外，通过将 pre- 和 post- （以及 pre-fetch 和 post-patch 等）作为每个目标的前缀，可以在所需执行的目标前后注入希望执行的操作。此外，通过指定（覆盖） do- 前缀，甚至可以控制 ports 的默认行为。这些顺序和控制如下所示。

实际上，对于每个 ports ，有各种情况，例如希望禁用该目标的情况（ NO_BUILD / NO_INSTALL / NO_TEST ，每个 make build ， make install ， make test 都被禁用），或者明确希望启用目标的情况（ HAS_CONFIGURE / GNU_CONFIGURE ，均启用 make configure ）。情况千差万别。

实际上，还有更多细节的地方，发生了各种各样的挂钩。要完全列出它们太困难了，因此在调查要点中也要做笔记。

目标阶段

如前所述，众所周知的目标是

• all

• fetch

• extract

• patch

• configure

• build

• install 可能会发生这种情况。对此

• config/showconfig/rmconfig

• package/repackage

• test

• clean

• deinstall/reinstall

• makesum / makepatch 等，将添加一些要了解的目标。

在上述目标中，在ports构建中执行的一系列目标通过 _TARGETS_STAGES 变量进行定义。当然，这是在 bsd.port.mk 变量中定义的变量，不希望被覆盖。通过在适当的ports目录下运行 make -V_TARGETS_STAGES ，可以了解其中包含 SANITY PKG FETCH EXTRACT PATCH CONFIGURE BUILD INSTALL TEST PACKAGE STAGE 的内容。

根据上述变量的内容，在每个阶段都使用 _ステージ名_SEQ 变量详细设置顺序，并使用 _ステージ名_DEP 定义依赖关系。特别是以 _SEQ 结尾的变量被定义为 優先順位:ターゲット ，即使稍后添加也会被控制以顺序执行。

例如，对于 Go 语言应用程序，将执行特定于 Go 的 go mod download 检索。

如果在非常特殊的时机想要插入，请根据这个流程进行必要的准备。

使用 make 命令进行调试

当 ports 的情况下，为实现各种简化表示，表面上变得相对简单。 但是，结果是实现变得非常复杂。 对于前面的目标阶段，可能可以大略理解，但要调查实际发生了什么错误是非常困难的。 这就是 make 命令的调试选项（ -dＸ / Ｘ 是另外的功能选项）的出现。

特别是 -dl 选项会显示在 Makefile 中包含 bsd.port.mk 等的命令执行，而它们一直隐藏在 @ 中。

或者也许是 make -de 吧。 这会仅显示执行失败的命令。 如果构建失败，想知道执行了哪些命令导致失败，首先检查 make -de ，然后在 make -dl 中查看整个流程是发生了什么，以便更容易地掌握问题。

再次 make -dx 的情况下，调用的 shell 命令将使用 -x 选项调用，因此在 shell 脚本中执行的内容将显示出来。当然，每次命令调用时... 所以有时候可能无法区分 make -dl 。

常见问题及其答案

Q. 虽然不太整理，但为什么要写这个？

A. Maven 或者 Gradle 有问题。这些家伙像 Go 语言一样频繁预取，就算能容许这一点，但它们没有很好地缓存，所以我在疯狂地调查该怎么办。

Q. 那问题解决了吗？

A. 详细内容请查看网页！

FreeBSD Bhyve PCI 直通

最后更新于 2023-01-27 发布于 2022-12-18

1.首先

我想在 Bhyve 的 Windows 宾客中使用主机设备，因此尝试设置 PCI 直通。我使用 vm-bhyve 作为管理软件，基于这一前提，我将进行以下说明。关于 vm-bhyve，您可以在搜索时找到相当多的解释，请参考那些解释。

这些硬件是我去年购买的，就是这篇文章中提到的硬件。https://qiita.com/yshdsnd/items/e8ba8d417851ae56f2fc 但是，内存已扩展到 128GB。我正在使用 FreeBSD 13.1-STABLE。

2. 主机端(硬件)设置

PCI passthrough 需要使用 VT-d 功能。由于通常情况下默认是禁用的，所以请进入 UEFI 菜单启用 VT-d。

虽然本次不使用，但同时也启用了 SR-IOV。

3. 主机端（软件）设置

首先查找要使用的设备 ID。 尽管可以使用 pciconf，但 vm-bhyve 的 vm passthru 命令更简单。

→ 我想在 Windows 上使用最后的这个 NIC（Killer E3000 2.5GbE 控制器）和 xhci1 设备。

然后在/boot/loader.conf 中写下要作为传递设备保留的设备。

/boot/loader.conf：

pptdevs 现在会记录刚才在 vm passthru 中显示的 ID。此外，必须在此处明确加载 vmm 模块。否则，xhci 驱动程序将首先识别设备，导致设备无法被预留为透传设备。如果只想使用没有 FreeBSD 驱动程序的 Killer E3000 2.5GbE Controller，则无需明确编写 vmm 模块。它将在启动 bhyve 时自动加载。

编辑 loader.conf 后，重新启动操作系统后再次运行 vm passthru。

指定的设备已被注册为 ppt0、ppt1 并作为透传设备。

4. 客人的启动设定

在 vm-bhyve 的设定文件中注册透传设备。因为已经创建了名为 Windows 的客人，所以使用 vm config windows 来编辑设定文件。

以 "passthruX="BUS/SLOT/FUNC"" 的形式进行记录。只需直接记录 vm passthru 显示的内容即可。 虽然与透传无关，但最近的-STABLE 版本增加了通过 VNC 连接时指定键盘映射的选项（-K），因此即使通过日本键盘使用，也不会出现无法正确输入符号的情况。我已将该选项指定为 bhyve_options。

5. 尝试启动客户端

到这一步只需启动即可。

虚拟机启动窗口

在 Windows 设备管理器中确认是否已添加。如有需要，请安装驱动程序。

如果一切正常识别就是这样。ASMedia USB 3.1 eXtensible Host Controller 是透传设备，其下的 Intel xhci 控制器是 Bhyve 的虚拟设备。再往下的 Killer E3100G 也是透传设备。

6. 但是问题是...

在 Windows 端安装驱动并重启后，bhyve 进程异常终止。无论启动多少次都不行。查看日志显示，以 status 4 结束。

在日志中如下所示。

从配置文件中删除 passthru 后，可以正常启动。此外，重新启动主机然后启动可以正常运行。然而，如果重新启动来宾，则无法再次启动。

我认为可能有某种问题导致无法重新初始化 passthrough 设备，无法解决。每次重新启动来宾都需要重启主机，来宾重启没有意义，让我很困惑...如果有人知道解决方案，请告诉我。

*添加于2023年1月27日

由于 13-STABLE 源代码树中 bhyve 命令和内核的 vmm 相关部分有重大更改，因此我怀疑并尝试更新到最新的 13-STABLE 后，成功地使客户机可以重新启动。现在可以放心地充分使用了。

portsnap 被淘汰了，本应由 git 代替，但结果我发现自己用的是 got

最后更新于 2023-12-02 发布于 2023-12-02

开始

介绍了一个名为 Ｇｏｔ 的由ＯｐｅｎＢＳＤ项目衍生出来的 Ｇｉｔ 替代品。虽然它是一个 git 命令的替代品，但对于那些对 git 命令的使用没有疑问，并且对其许可证没有疑问的人来说，这是一个完全不必要的工具。由于开发者是开发者，因此其用途非常独特。

据说它的目标是支持 Ｇｉｔ 的裸仓库兼容^ 1^。对于裸仓库的操作是兼容的。但是在所谓的工作目录（包括索引）级别上不兼容。因此，需要根据工作流程切换命令。

既然开始写一个泛论的介绍，最近的 FreeBSD 中删除了 portsnap 命令，看到使用 Git 的建议^ 2^，对于那些希望使用 portsnap 而不是 git 的人来说，可能有点不情愿……

由于 Got 专注于实现 OpenBSD 开发的工作流程，因此其代码量非常少，几乎没有依赖。它被宣称为轻量级、紧凑且不会造成头痛的工具。然而，关于其轻便性能的评价，我就不发表评论了。另外，由于要求独特的使用体验，我认为在需要严格使用 Git 的情况下最好不要使用它。

以下用例将描述目标作为 portsnap 的替代。

尝试安装

这周围也没有变化。由于没有依赖项，因此不会安装其他软件包。

通过 GOT 的版本验证为 0.93 。由于版本升级，此处记录的内容可能不再适用。

首先尝试克隆

got clone 和 git clone 之间的区别如下。

• 仅克隆裸库（相当于 git clone --bare ）

• 无法指定来源（裸仓库指定来源没有意义？）

• 可以指定分支，默认好像是单分支

• 但是好像不能进行浅克隆

• 存在镜像模式（无法向克隆的存储库提交更改的模式）

• 支持的模式较少 ※ 详见下文

• 非常慢（在多线程下不执行解析差异） 详见下文

克隆案例

与上述命令相对应的是 got 命令，具体如下。首先需要展开裸存储库的区域。由于这个过程非常耗时（后文将介绍），如果有余地的话，可能最好直接使用 git 命令。

支持的模式

• git://

• git+ssh:// （或 ssh:// ）

不支持的模式

• git+http:// （或 http:// ）※错误（策略上不打算支持）

• https:// ※未实装错误（待办事项）

• ftp:// ※那是什么？（确认存在与否）

• ftps:// ※那是什么？（确认存在与否）

克隆所需的时间测量

git clone 的消息

got clone 的消息

git clone 和 got clone 的执行时间

• 执行环境大约 5 分 37 秒与 14 分 1 秒的差异，有 2.5 倍的差距。

• 另外，Git 的 CPU 使用率较高，表明处理效率偏向于 CPU 带宽（由多线程处理产生的效果）。

• 相反地，GOT 具有較高的系統使用率，可以看出瓶頸往往偏向 I/O 帶寬。

關於克隆時的選項指定造成的容量差異

※单分支： git clone --single-branch 或 got clone ※多分支： git clone 或 got clone -a

一応通过选项指定确认了容量的变化。此外， git 和 got 之间的差异很大，尽管为什么会出现这种差异尚不明确。可能是某种开销导致的……。

更新工作树

对上述命令的执行相当于下面的 got 命令。

本案例中的大致用法如下。有关在开发流程中可能需要的用法，请参阅命令对应表以及其他参考文献。

关于 tog 命令的额外内容

这是一个基于 ncurses 的日志查看器。它可以显示一行日志，同时在选择该日志（按下回车键）时，会显示详细日志和修改内容，非常实用。据说类似于 Git 的第三方工具中的 tig 命令。

信息

在 gotadmin 和 got 命令应用于存储库和工作树时有所不同。具体而言，安全使用的子命令大约是 info 。根据存储库或工作树的状态，显示内容会有所变化。

在 git clone --bare 目录中运行 gotadmin info 并比较，显示增加了 remote 行。查看存储库下的文件时，发现不是 remote "origin" 文件中的 config ，而是 got.conf 中的 remote "origin" 设置。实际上，创建了 got.conf 文件后，显示了 remote 行。

另外，如果在工作树上运行 gotadmin info ，将显示存储库的状态。此外， got info 的执行结果将提供有关工作树的信息。

常见问题及其答案

问： https 模式不可用吗？

Ａ． 可能是因为它不依赖于 curl 。在普通的 HTTP 通信实现中，可能会遇到无法进行并行处理的问题……这只是我的猜测。如果使用 ssh:// ，那里到处都安装了 ssh 命令，感觉很安心【需要出典】。

Ｑ． got update ／ got merge ／ got rebase ／ got integrate 有什么区别？

Ａ． 未调查。可能情况与 Git 类似。

Ｑ． 如果 got clone ... /usr/ports/.git ，就可以创建与 git clone 完全相同的情况了！

Ａ． 我已验证。 got clone 可成功，但 got checkout 将失败。

Ｑ． 嗯？ /usr/ports/.git 是什么意思？

即是说实际上是个裸仓库的目录！ 做完 git clone 后接着做 gotadmin info 就会得到惊人的结果。

问：做完 git status 就会得到惊人的结果！

答：处理 .gitignore 文件时出现了一个错误，这是个 bug。按照正常情况 .gitignore 文件指定的目录或文件等不会显示。轻轻地调查了一下，应该并不是没有处理 .gitignore 文件。所以这就是 bug 所在。

Ｑ．别名功能呢？

Ａ．没有。希望有这个功能。请有心人实现。

Ｑ．这么好用了，加到基础系统里也可以吧？

Ａ．好好使用并报告。在当前时点可能无法评价基础系统的质量是否足够。至少在我所接触的范围内，似乎还未达到那种质量水平。

参考文献

1. 从 Game of Trees Goals ↩

2. Ports Collection 的安装 ↩

FreeBSD pkg 命令概述

最后更新于 2023-12-28 发布于 2023-12-25

开始

通过改进第三方工具安装机制（ports 和 packages），FreeBSD 中的二进制包使用已经得到改善。特别是引入了 flavors 功能，尽管安装的内容是相同的，但由于依赖的包版本变化，可能会导致组合变得复杂的情况，现在可以简单地准备包。只要针对所有被依赖的包的版本都有适合的包... 这里总结了经常使用的命令，以享受二进制包带来的好处。然而，细致到每个选项会很麻烦，所以只明确列出常用选项。另外，大多数命令都会询问是否执行。因此，几乎所有命令都有一个常见的 -y 选项，但在这方面的说明将省略。熟悉后再使用。此外，我没有写太多执行示例。如果不清楚如何使用等问题，请告诉我。我会补充详细说明。

常用的 pkg 命令

在这里，我们为命令名称（子命令名称）添加 [R] 和 [L] 符号。具体如下。

• [R] ：引用外部包／存储库中的信息。

• [L] ：查看已安装或存在于本地文件系统中的软件包的信息。

• [RL] ：根据环境表现出与 [R] 和 [L] 相适应的行为。

软件包更新 [R]

用于收集软件包元数据的命令。首先需要收集元数据，这在某种程度上类似于 yum check-update 。 值得一提的是，并非总是需要运行的命令，因为有一些命令会自动更新元数据后再执行，如果这不是问题的话，就无需运行。具体来说，以下子命令将根据最新的元数据执行。

• pkg install

• pkg upgrade

• pkg version

• pkg search

• pkg fetch

• pkg rquery

软件包安装 [R]

进行软件包安装。与前述 pkg add 的区别在于，使用关键词进行特定及通过网络获取软件包安装。

软件包添加 [L]

执行指定软件包文件的安装。与前述 pkg install 不同之处在于，明确指定软件包文件名进行安装。

pkg 删除 [L]

删除指定的软件包。

pkg 删除 -ayf

将无情且毫不留情地删除所有（ -a ）软件包。直观来看，只需使用 -ay 选项就足够了，但由于依赖关系的原因，可能需要使用 -f 选项来处理无法删除的情况。如果打算全部删除，就毫不犹豫地全部指定吧。

pkg 版本 [RL]

将进行软件包版本比较。简单来说，由于它有些古怪，我们将分解用例并进行解释。

将与名为 /usr/ports/INDEX-ＯＳメジャーバージョン 的元文件进行比较。如果该文件不存在，则将参考每个ports的源（目录）（相当于指定 -P 选项）。如果该目录不存在，则将参考远程存储库（相当于指定 -R 选项）。

在前两种情况下，相当于 [L] ，在后一种情况下相当于 [R] 。

包版本 -L =

通常使用 -L 选项进行比较已安装的软件包，并显示等于「不存在」的内容。惯用法上，只指定 = 就足够了。除了参考 = 之外，还可以指定 > 、 < 、 ? 和 ! ，但所有这些字符都需要用引号括起来。

各个字符的含义如下，对于 -L 选项，意味着除了该字符以外的所有内容。反过来，如果需要该字符的含义，则使用 -l 选项。

• ：如果发布了比当前安装的更新版本

• = ：如果发布了与当前安装的相同版本

• < ：如果发布了比当前安装的更旧版本，通常在更新元数据不完整、新 ports 测试安装等情况下发生

• ? ： 由于当前安装的软件包的源已不存在（已删除或重命名），无法进行版本比较

• ! ： 无法与当前安装的版本进行版本比较

包版本 -t

指定任意版本号（即普通字符串）进行比较，并返回结果。这不仅仅是针对软件包的功能，而是为了测试多种版本号而设计的功能。与其他子命令相比，这是一种不同的功能。特别是在替换版本指定如α版、β版时，用于尝试和错误解决不确定哪个更大（最新）、哪个更小（最旧）的情况。有关版本比较规则，请参阅 FreeBSD Porter's Handbook - 5.2.2. Versions, DISTVERSION or PORTVERSION。

包升级 [R]

更新指定 更新指定的软件。如果没有特别指定，将会检查并更新所有包。

包信息 [L]

指定されたパッケージ情報を表示します。指定されない場合、全てのパッケージの概要を一覧表示します。

包信息 -a

显示指定的包信息。如果没有指定，将列出所有包的概览。

包信息 -l

显示安装了指定软件包的路径列表。

软件包信息 -D

显示与指定软件包相关的注意事项。可能包含设置提示信息。

锁定软件包 [L]

锁定指定软件包，以防止其更新。此锁定的影响优于防止软件包本身的更改。

• 锁定的软件包阻止重新安装、升级、降级或删除

• 如果依赖于锁定的软件包的其他软件包依赖于锁定的软件包的另一个版本，则阻止该软件包的升级或降级

• 阻止依赖于锁定软件包的软件包的删除、升级或降级

• 对于与上述间接有依赖关系的情况，也将被阻止

解锁软件包 [L]

解除指定软件包的锁定。

软件包搜索 [R]

不区分大小写，通过正则表达式搜索软件包名称。您可以使用 -e 选项进行严格搜索，但这将包括版本号搜索，因此并不是很用户友好。 -g 选项允许进行 shell glob（通过 ? 或 * 进行模糊搜索）。但是，由于包含版本号搜索，实际上最后需要 * 。

软件包定位 [L]

显示所属于指定文件、目录等的软件包名称。您可以使用 -o 选项来显示原始位置。

很少使用但最好知道的 pkg 命令

软件包审计 [RL]

报告已安装软件包与脆弱性信息的比对结果。由于需要从外部获取脆弱性信息，因此这有些像 [R] ，但如果您没有紧急需要立即更新信息，不必指定 -F 选项来获取脆弱性信息。这通常是因为每天有一个脆弱性信息自动获取脚本在取得脆弱性信息。

软件包检查 -s [L]

检查指定的软件包是否被篡改，以确保一致性。通常与 -a 选项一起使用。

软件包检查 -d [L]

检查指定软件包的依赖项是否损坏，以确保一致性。通常与 -a 选项一起使用。

软件包自动移除 [L]

删除孤立的软件包。所谓“孤立”是指由于其他软件包的依赖关系而安装的软件包，随后该软件包被删除，或者（通过更新等方式）不再被依赖，不再被使用。

可能有一些情况下，实际上会使用到“孤立”的软件包，但这并不能从软件包依赖信息中读取出来，因此在使用时需要格外注意。例如通常使用 bash ，但由于某些依赖关系安装了 bash ，因此直接使用它可能需要注意。可以明确安装 bash ，或者通过后续的技巧来解决。

对于 ports 系统而言，在构建时需要的主要软件包（如编译器等）可能会被删除。

包更新[L]

显示软件包更新时需要注意的步骤（手动更新指示）。具体来说，通过阅读 /usr/ports/UPDATING 并与已安装的（或指定的）软件包信息匹配，以显示可能需要的部分。这个文件主要面向人类阅读，因此存在相当的启发式设计，严密性可能有所欠缺。同时，需要这个文件的情况下，特意下载它也有些微妙。

包设置[L]

更改指定软件包的元数据（数据库）。通常情况下，这是基于 pkg updating 信息执行的操作，因此不应该由用户主动操作。

包设置-A

使用 -A 选项并指定以下值，以更改指定软件包的元数据。此更改将影响 pkg autoremove 的结果。

• 0 ：将指定的软件包排除在 pkg autoremove 的范围之外。

• 1 ： 指定的软件包将定制为 pkg autoremove 的目标。

对于对此项感兴趣的人，可能会关心 pkg autoremove 的工作原理，但由于此标志必须有效且不受其他软件包依赖的影响，因此仅靠此标志无法使 pkg autoremove 成为目标。

同样，直接由 pkg install 或 pkg add 指定的内容将在安装时设置为无效此标志。此标志仅对通过依赖关系安装的软件包有效。

pkg set -o

通过 -o 旧オリジン:新オリジン 的形式，修改依赖于旧原始包的所有软件包的元数据中的原始信息。

pkg set -n

通过 -n 旧パッケージ名:新パッケージ名 的形式，修改软件包名。不过，由于软件包名中是否包含版本号存在争议，因此这存在一些不确定性。

过于偏门，不知道也没关系的 pkg 命令

pkg alias [L]

在 /usr/local/etc/pkg.conf 中显示定义的别名信息。

包查询 [L]

以指定的格式显示软件包的元信息。如果未指定软件包名称，则将显示所有软件包的信息。可以使用以下格式字符串：

• %n ：软件包的名称

• %v ： 软件包版本

• %o ： 软件包来源

• %p ： 软件包前缀

• %m ：软件包的维护者（电子邮件）

• %c ：软件包的注释

• %e ：软件包的描述

• %w ： 软件包的网站

• %l ： 软件包的许可逻辑（无、单一、和、或）

• %sb 或 %sh ： 软件包的大小（以字节为单位或易读的单位）

• %a ： 软件包自动安装标志

• %Q ： 软件包架构支持候选

• %q ： 软件包架构（操作系统、版本、CPU 架构）

• %k ： 软件包的锁定标志

• %M ： 软件包的消息

• %t ： 软件包安装时的时间戳

• %R ：软件包安装来源存储库

• %X ：软件包检查和校验和

• %?Ｃ ： Ｃ （具体是 d / r / C / F / O / D / L / U / G / B / b / A ）中指定情况下的标志（说明略）

• %#Ｃ： Ｃ（具体的には d/r/C/F/O/D/L/U/G/B/b/A・説明は省略）として指定された内容の数

• %dＣ ： 定制的依赖包列表，通过 Ｃ （具体的には n / o / v ）获取 N 名称、 O 来源、 V 版本信息

• %rＣ ： 包的反向依赖包列表，通过 Ｃ （具体的には n / o / v ）获取 N 名称、 O 来源、 V 版本信息

• %C ： 软件包类别列表

• %FＣ ： 软件包文件列表， Ｃ （具体是 p / s ）通过 P ath 或 S um 获取

• %D ： 软件包目录列表

• %OＣ ： 获取软件包选项列表，通过 Ｃ （具体地说，通过 k / v / d / D ）获得 k ey、 v alue、 d efault value、 D escrition

• %L ： 获得软件包许可证列表

• %U ： 获得软件包用户列表

• %G ： 软件包组列表

• %B ： 软件包程序使用的共享库列表

• %b ： 软件包提供的共享库列表

• %AＣ ：包的注释标签列表，通过 Ｃ （具体地说是 t / v ）获取 t ag、 v alue

包查询 -e

缩小到与指定查询匹配的包。如果心情好的话，会详细写的。

包 r 查询 [R]

对远程元数据的 pkg query 进行操作。这里暂时不详细说明。

包注释 [L]

为软件包添加、修改或删除“注释信息标签”的命令。您可以使用 pkg info -A 查看显示效果。没有特别说明注释标签的含义和使用方法。

包 shell [L]

直接访问管理软件包元数据的数据库（即 SQLite3）的命令。大概只有 pkg shell VACUUM 这么一点点用途。如果想要利用查询， pkg query 就足够像找零钱一样的工具。

便利的别名命令

自动安装标志相关

以下别名参考自动安装标志，返回自动安装标志为 0 的明确指定安装的命令。

• pkg prime-list [L]

• pkg prime-origins [L]

• pkg noauto [L]

包叶 [L]

显示依赖树中叶子节点的软件包。不包含在 pkg noauto 中但属于 pkg autoremove 的对象。

软件包列表 [L]

指定的软件包安装路径列表。

语法糖

仅仅是可供任选调用的别名。甚至可以用类似 pkg vanish 这种充满中二病氛围的 神圣而强大的词汇来定义子命令，也是毫无问题的。系统会默认定义一些安全的值。

• pkg remove ＝ pkg delete

我不知道这个 pkg 命令。

这些命令大多用于内部，或者被其他工具调用（例如从其他软件包管理系统到 FreeBSD pkg 系统的注册等），即使不了解也没有问题。

• pkg stats ：显示统计信息。

• pkg clean ：清除软件包缓存。

• pkg config ：引用设置为 /usr/local/etc/pkg.conf 的内容（不区分大小写）。

• pkg create ：创建软件包...尽管在ports构建时经常使用，但单独使用的情况并不常见。

• pkg fetch ： 获取软件包。 pkg install = pkg fetch + pkg add 的关系。

• pkg register ： 将软件包注册到本地数据库。这完全是内部使用的东西。

• pkg repo ： 创建软件包存储库目录。在此处，请参考 pkg-repository(5) 创建存储库。

• pkg shlib ：显示提供的共享库以及依赖于该库的其他软件包。这主要用于安全诊断。

• pkg ssh ：这是为完全内部使用而不是为人类使用的命令，因此略过。

• pkg triggers ：延迟触发的执行。由于涉及内部使用，因此省略了谁延迟了这个问题？

起源

起源是 TODO。想写的话会写。

常见问题及其答案

Q．pkg 命令是一个软件包吗？

A．是的。pkg 命令是一个软件包。

Q．哦？/usr/sbin/pkg 是什么？

A.这只是一个安装 pkg 软件包的引导。然后调用 pkg 软件包（ /usr/local/bin/pkg-static ）。

问：噢？这不会包含在基本系统中吗？

答：由于旧软件包系统给我们带来了许多麻烦，因此演变成了这种形式。如果 pkg 命令没有进步，我们将一事无成（即使发布新版本也会被迫使用旧功能）。

Ｑ．pkg 命令和 pkg-static 命令有什么区别？

它们完全相同。pkg-static 在执行一些微妙操作，比如删除自身时才会需要。通常情况下，使用 pkg 命令即可。在某些内部处理中，为了安全起见才会使用 pkg-static。

Ｑ．如何删除通过 pkg update 获取的仓库信息？

Ａ．自己也对此感兴趣，正在进行调查。

Ｑ．使用 pkg query 时无法有效筛选结果。在需要输出最近安装的软件包列表的情况下，应该如何处理？

Ａ．让我们尽力而为吧。尽管我们不谈什么“让我们 SQL 吧！”，但确实如你所说，pkg query 没有输出顺序或汇总功能。或许可以考虑通过管道连接其他工具（例如 sort、awk、grep 等）来解决问题。

Ｑ．这些你真的都记得吗？

Ａ．常用的我记得。我自己以为记得的可能就数个，但实际上大约有十几个左右，所以还是得依赖记忆写下来，觉得值得去记忆。有些细微的差别可能有点微妙，那就得仔细查阅手册了。总之，平常不使用的东西就放在记忆的深处也没问题。

Ｑ．pkg update/upgrade/updating 有点难理解。

Ａ．很遗憾，请记住，这是另一个包系统， update 和 upgrade 可能是相同的，但很不幸，消息在这里中断了

Ｑ．WITH_PKGNG 或者 pkg2ng 是什么？

这是非常古老的事情（在 10.0-RELEASE 之前），请忽略这部分内容。它只有历史价值，对设置和运营毫无价值。

愚痴

列出了这些我都知道的东西后的绝望感。日常使用是什么？但如果不列出这些的话……地狱感。并且在读手册时发现了一个 bug（pkg-query(8)：重复的%#b）。orz

参考文献