Hubbard Demands FreeBSD Overhaul to Avert Obsolescence in Mobile Era

哈伯德呼吁彻底改革 FreeBSD 以避免在移动时代被淘汰 除非开发者大刀阔斧地精简传统架构、替换静态初始化脚本，并将该平台重新设计为适用于电池供电设备的模块化组件，否则该操作系统将面临被边缘化的风险。 在 FreeBSD 1.0 发布 21 周年之际，乔丹·哈伯德（Jordan Hubbard）回顾了该操作系统的演进历程：它已从 20 世纪 90 年代为互联网服务提供商（ISP）提供支持的显性平台，转变为消费级设备、游戏主机和移动设备内部隐秘的基础管道层。他指出，现代操作系统必须摒弃静态假设，重新设计为适应动态、电池供电硬件的模块化“乐高积木”。为了保持生命力，FreeBSD 必须统一其碎片化的配置格式，实现异步通知与进程监管架构，引入健全的远程遥测技术，并果断精简诸如 32 位 x86 等传统架构。 FreeBSD 已从部署在物理 ISP 和 SOHO 服务器上的显性操作系统，转变为支撑各类设备、游戏主机和移动设备的隐秘基础管道层。 (10:08) 企业法务对 GPLv3 的担忧意外成为了商业推广的助力，促使企业工程团队重新评估并采纳宽松的 BSD 许可证。 (5:54) 为了针对电池驱动、移动及云环境实现现代化，FreeBSD 必须用统一的首选项 API、异步事件总线和按需进程监管来取代零散的配置文件与静态初始化脚本。 (21:27) 工程领导层敦促 FreeBSD 社区精简传统的 32 位架构和单体基础软件包，转而采用可向下扩展至嵌入式控制器的模块化、基于清单的“乐高积木”形态。 (42:28)

Looking ahead from FreeBSD's 21st anniversary, co-founder Jordan Hubbard argues that the project must shed historical baggage, unify its system configuration and process models, and restructure into modular building blocks to remain relevant across modern cloud and battery-powered embedded hardware. From Visible Servers to Covert Appliances (4:39) FreeBSD's primary operational context shifted dramatically between 1993 and 2014. In its early years, FreeBSD served as a highly visible, overt operating system deployed primarily on AC-powered x86 servers by internet service providers, web hosts, and early internet firms like Yahoo and Hotmail. Over two decades, deployment migrated inside specialized appliances such as firewalls, storage filers, network routers, and gaming consoles like the PlayStation 4, where the underlying OS is entirely covert. Meanwhile, the broader Unix center of gravity shifted to battery-powered mobile devices and dynamic, automated cloud instances managed by orchestration tools like Puppet, Chef, and SaltStack. Unifying Configuration and Asynchronous Event Handling (21:27) Modern deployment workflows are impeded by FreeBSD's fragmented configuration architecture, which maintains five to ten disparate formats across /etc. Rather than endlessly debating serialization syntaxes like XML, JSON, or YAML, Hubbard contends the operating system must introduce a standardized preferences API within system libraries—drawing on the precedent of OS X's unified property list architecture—so automation tools can programmatically read and write system state without ad-hoc parsing scripts. Operating systems must also adapt to intermittent, dynamic runtimes characterized by multihomed radios, sleeping hardware, and moving IP environments. Traditional static caches lead to silent failures, such as stale Active Directory credentials. Hubbard points to Apple's notifyd as an architectural model for asynchronous event distribution, replacing continuous polling with shared-memory cache invalidation, which previously eliminated hundreds of redundant stat calls per second on /etc/localtime. Reimagining Process Supervision for Battery Life (27:14) FreeBSD's legacy rc.d init model relies on static dependency graphs that cannot dynamically register runtime hardware arrivals, hotplugged devices, or on-demand socket activations. Hubbard advocates for event-driven process management where services launch only when requested via IPC, timers, or network traffic, and terminate when idle. In mobile and low-power systems, having dozens of uncoordinated background daemons each waking up once per second generates persistent CPU wakeups that rapidly deplete battery power. Consolidating the fragmented responsibilities of cron, inetd, and devd under a centralized process supervisor enables aggressive resource management, behavior policing, and runtime power savings. Ruthless Culling and Modular Architecture (42:28) To build an OS that operates like adaptable Lego blocks, FreeBSD must aggressively remove legacy debt. Hubbard highlights the need to prune dead architectures—pointing out that FreeNAS 9.3 dropped 32-bit x86 support entirely—and eliminate packaging artifacts originally created to split files across 235 KB floppy disks. Instead of compiling all pet features into a rigid base system by default, Hubbard endorses using release manifests and profiles to assemble minimalist configurations, allowing developers to discard unneeded components like Perl depending on target constraints. While Hubbard urges the FreeBSD community to rally behind an ambitious reference platform in the mobile or hacker-board space, participants noted that severe technical gaps—including missing display stacks, framebuffers, and sophisticated power management—must be resolved before portable hardware bring-ups are viable. Hubbard acknowledges that volatile hardware lifecycles complicate target selection, leaving open how the project will balance long-term foundational work against rapidly churning commercial devices.

Jordan Hubbard回顾了FreeBSD自1993年1.0版本发布以来的演进历程，指出该系统已从早期的显性物理服务器转变为嵌入式设备、网络设备和移动硬件中的隐性基础设施。他认为FreeBSD若要在未来十年保持竞争力，必须摆脱过时的历史负担，将自身重构为高度模块化的“乐高积木式”底层组件，并建立现代化的系统事件管理与配置体系。 从软盘时代到隐性部署架构的转变 (0:00) Hubbard回顾了1993年FreeBSD 1.0发布时的极端硬件限制：系统安装包必须切割为230KB至235KB的分卷，以便装入1.2MB或1.44MB的软盘；整个Ports集合仅有约70个软件包；一台50MHz的486 DX2开发机配备的1GB硬盘花费了1600美元。在20世纪90年代中期，FreeBSD作为显性的物理服务器操作系统，主要运行在由交流电供电的桌面机和塔式机上，驱动着早期互联网服务提供商（ISP）以及Yahoo和Hotmail等旗舰客户的网页服务器与DIY防火墙。 到了2014年，计算环境发生了根本性逆转。低成本硬件与云计算虚拟机普及，GPLv3许可协议的发布也因企业对法律合规的顾虑，促使诸多商业工程团队转向宽松的BSD许可证。更为关键的变化在于，FreeBSD已转变为隐性的管道层：它被深度集成在pfSense、FreeNAS等专用网络存储设备、商用路由器乃至PlayStation 4等消费级硬件内部。与此同时，Unix世界的核心运行平台已迁移至依靠电池供电的手机、平板电脑、穿戴设备以及内置微型ARM处理器的智能转接线缆中，呈现出高度隐性与边缘化的特征。 电池供电与动态环境下的系统核心缺陷 (24:04) Hubbard强调，早期FreeBSD建立在硬件静态连接与持续交流电供电的假设之上，而现代移动与边缘设备则高度依赖直流电池，并在复杂的无线电环境中运行。例如，现代智能手机往往同时搭载蜂窝网络、Wi-Fi、蓝牙和NFC等四至五种无线电组件，导致网络接口频繁切换、路由震荡以及Bonjour主机名动态变更。静态操作系统假定在动态网络环境下会暴露出严重弊端，其中最突出的是由于缺乏失效触发机制而导致的缓存失效难题，例如Active Directory在网络变动后常因本地守护进程持续缓存旧数据而导致权限和文件归属错误。 针对动态硬件事件，传统的轮询式架构不仅缺乏效率，而且极度损耗移动设备的电池寿命。例如，五十个独立的后台守护进程若各自每秒唤醒一次轮询状态，就会在CPU上产生累积50Hz的持续唤醒开销。此外，Unix传统服务分散注册于`cron`、`inetd`、Mach IPC和`devd`等多重管理器中。Hubbard以苹果系统中的`notifyd`为例，说明操作系统需要统一的异步事件通知总线与共享内存机制；同时，系统管理必须由静态的`rc.conf`依赖模型，转向基于IPC请求、定时器或硬件热插拔事件驱动的按需激活与资源回收机制。 统一配置抽象与模块化乐高架构 (21:27) 现代云原生与自动化运维工作流使得系统管理员不再手动修改单机配置文件，而是通过Puppet、Chef等自动化工具在咖啡馆即可调度数百台云端虚拟机。然而，FreeBSD系统内部存在五到十种以上互不兼容的`/etc`配置格式，迫使工程团队编写大量脆弱的胶水脚本来进行解析。Hubbard指出，社区多年来纠缠于YAML、XML或JSON等序列化语法的争论脱离了重点，真正的解决方案是在系统底层库（如`libc`）中实现统一的偏好设置API，将数据序列化与配置访问彻底解耦，正如苹果在iOS和OS X中通过统一的偏好设置API支撑底层配置一样。 面对多样化的硬件形态，Hubbard主张FreeBSD必须放弃将所有特性堆入基础系统的单一单体结构，转向“乐高积木式”的松耦合设计。操作系统应当由极小化、可组装的标准化基元构成，允许构建者根据微控制器、移动平板或多插槽服务器的特定需求自由裁剪与重组。这要求发布工程引入清晰的配置清单机制，打破传统基础系统（Base）与用户态软件包（Ports）之间僵化的界限，并果断淘汰缺乏长期维护价值的陈旧代码。 淘汰过时硬件架构与落地工程实践难题 (41:12) 在问答环节中，Hubbard与现场参会者探讨了推进这一愿景所面临的现实阻力。他主张坚决剥离无法跟上时代步伐的过时平台，并以FreeNAS 9.3完全废弃32位x86（`i386`）支持为例，指出维护陈旧硬件会拖累整个项目的演进速度，用户若坚持使用老旧设备应留在归档版本。然而，FreeBSD在进军移动与平板领域时仍面临严重的工程基础短板：操作系统目前尚缺乏完善的电源管理、帧缓冲（Frame Buffer）显示栈以及传感器遥测支持，这导致系统在开源硬件开发板（如树莓派）或移动参考硬件上难以达到可用状态。 关于硬件参考平台的选择，Hubbard坦承存在两难困境：白牌及低成本平板硬件生命周期极短，厂商数月内即可更改板卡设计导致兼容性断裂；而生命周期较长且稳定的设备（如苹果硬件）又面临封闭限制。此外，参会者提出新贡献者进入社区时面临较高的流程摩擦与心理门槛。Hubbard总结认为，降低准入门槛与提供清晰的文档固然是基础设施，但更重要的是为社区树立具有感召力的远大技术目标，明确系统“为何而建”，才能吸引新一代系统工程师共同推进演进。 Hubbard总结指出，FreeBSD的未来取决于能否在消除历史包袱的同时，重新确立清晰的核心发展目标。尽管通过统一API抽象、事件驱动架构和模块化分发可以解决大部分结构性缺陷，但如何选择具备稳定生命周期的参考硬件、补齐低层电源管理与显示子系统，以及在保持开放治理的同时降低新人协作门槛，仍是社区有待解决的关键挑战。

## Background 该视频由 iXsystems 官方频道于 2014 年 11 月 17 日在 YouTube 平台发布，记录了 MeetBSD California 2014 大会上的主题演讲。页面描述指出，iXsystems 作为开源服务器与存储解决方案提供商，积极参与 FreeBSD、FreeNAS 和 PC-BSD 等项目的贡献，本场演讲幻灯片同步收录于 SlideShare。 ## TL;DR FreeBSD 联合创始人 Jordan Hubbard 在项目诞生 21 周年之际，回顾了系统从软盘切片、早期物理机到现代云计算与移动设备的发展历程。他直言传统显性操作系统已被虚拟化与自动化流水线颠覆，FreeBSD 必须将自身重构为高度模块化、通用且可任意裁减的“乐高积木”。为此，他主张冷酷剔除过时架构与历史技术包袱，推动统一配置文件 API、异步事件通知（如类似 launchd/notifyd 架构）、系统级遥测及基于 IP 的外场调试。最后，他强调社区既需要确立具有吸引力的远大技术目标以激励下一代工程师，也必须大幅降低新人参与贡献的门槛。 ## Atmosphere & style 整场演讲洋溢着硬核老派黑客聚会特有的轻松幽默与坦诚自嘲，开场穿插着对早期硬件与停水喝啤酒趣事的调侃，迅速拉近了与台下老战友的距离。随着话题转入现代计算与移动生态的激烈竞争，Hubbard 的语调变得极为严肃且充满危机感，言辞犀利、毫不留情地针砭社区的因循守旧与技术负债。现场既有对过往辉煌的温情致敬，更有倒逼底层革新的紧迫号召，互动环节思辨激烈，让人切实感受到一个老牌开源项目在十字路口求新求变的务实与激情。 ## Bulletin - [07:50](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=470s) FreeBSD 走过 21 年历程，其生态已从最初仅包含 70 个软件的 Ports 树扩展到超过 24,000 个软件包，部署形态也从早期的物理 PC 与 ISP 服务器全面退居为路由器、NAS、安全硬件及游戏主机等底层不可见的实现细节。 - [15:53](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=953s) 面对云计算与自动化运维抹杀单机个性的趋势，Jordan Hubbard 呼吁将操作系统重新定义为“乐高积木”，提升核心组件的通用标准化与灵活裁剪能力，以适应从智能数据线到云端集群的全阶梯硬件形态。 - [21:52](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1312s) 针对系统配置严重碎片化的问题，Hubbard 建议摒弃无休止的格式之争，建立统一的配置解析库与 Preferences API，并借鉴 macOS 与 launchd 拥抱基于事件驱动和 IPC 唤醒的现代化守护进程管理。 - [31:20](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1880s) 为避免被时代淘汰，FreeBSD 必须果断淘汰 i386 等过时架构与历史包袱，集中攻坚确立移动参考硬件，并补齐电源管理、帧缓冲、基于 IP 的崩溃调试与系统级遥测框架。 ## Key takeaways - [01:35](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=95s) 早期的技术限制会深远束缚后来的系统设计，例如 FreeBSD 1.0 为兼容 1.2MB 与 1.44MB 软盘而切分成 230KB 的分卷碎片长期残留在系统中成为历史负债。 - [05:54](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=354s) 20 年前主流观点曾预言 Windows 将彻底占领桌面与主流硬件，但如今基于 Unix/BSD 机制的 macOS 及移动操作系统已成为主流开发和消费设备。 - [07:50](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=470s) GPLv3 许可证带来的合规风险促使各大商业公司重新评估并倒向采用宽容型开源许可的 BSD 阵营，为 FreeBSD 带来关键的工业界支持与基金会资金保障。 - [11:40](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=700s) 嵌入式计算已渗透至智能线缆等微型部件中，由于开发成本与现成库生态的考量，厂商倾向于直接嵌入完整 Unix 软件栈而非自研 RTOS。 - [14:48](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=888s) 云计算与 Puppet、Chef 等配置自动化工具彻底消灭了传统手工维护主机的个性，操作系统不再面向人工键盘交互，而是转变为自动化流水线调度消费的无状态原料。 - [17:12](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1032s) 移动计算的电池供电与多无线电动态网络环境彻底打破了单机稳态假设，要求操作系统建立主动遥测机制与高层级调试诊断体系。 - [19:23](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1163s) FreeBSD 社区不能沦为仅凭兴趣编码的松散业余社团，必须确立宏大且具有吸引力的“登山目标”来凝聚并吸引下一代年轻开发者。 - [21:52](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1312s) 系统内部充斥着多种私有配置文件格式，社区亟需敲定统一的规范与 lib 解析 API，而不是放任各工具私自发明 ad-hoc 格式。 - [24:04](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1444s) 操作系统必须建立中心化的异步事件通知框架与主动缓存失效机制，避免组件通过高频轮询文件状态白白耗尽移动端电量。 - [27:14](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1634s) 守护进程应摒弃静态显式依赖与全量常驻模式，转向类似 launchd/systemd 的异步按需唤醒与空闲回收机制。 - [31:20](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1880s) 针对移动设备缺乏物理串口调试的痛点，FreeBSD 必须建立系统级远程 IP 崩溃转储抓取与遥测 API 框架。 - [32:56](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1976s) 进军移动与平板平台的核心阻碍不在于芯片选型，而在于电源管理、frame buffer 引导等底层基础设施的严重缺失，社区亟需集中攻坚单一参考平台。 - [42:28](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2548s) 开源项目必须具备坚决淘汰过时架构的勇气，正如 FreeNAS 9.3 彻底放弃 32 位 i386 镜像，主干开发绝不能因向后妥协而拖慢演进步伐。 - [44:40](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2680s) 官方发布工程应当引入“发布配置文件（Release Profiles）”，使 Base 基础系统与外部软件能够像乐高积木一样按需模块化裁剪和组装。 - [46:15](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2775s) 降低新成员准入门槛、提供无阻力的参与途径（How）至关重要，但为社区明确阐明“为什么要做（Why）”的战略愿景同样不可或缺。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=0s) 开场：不可预测的未来与历史的起点 Jordan Hubbard 在演讲开场时幽默地向刚刚参加过 EuroBSDcon 的听众致歉，表示如果有人觉得内容重复请多包涵。他直言这次演讲的标题《FreeBSD: The Next 10 Years》其实很糟糕，因为“这听起来好像我不仅知道未来 10 年会发生什么，甚至还知道未来 20 年的走向，但我实际上根本不知道。”不过，他希望通过梳理过去五六年中观察到的趋势与事件，推导和判断 FreeBSD 在未来 10 年的发展方向。现场调试麦克风增益后，Hubbard 开始带领听众回顾 FreeBSD 的历史起点。 他展示了一封来自自己位于爱尔兰的个人机器的早期邮件，时间标记为格林威治标准时间（GMT）14:51。换算为修正后的 GMT 日期后，那一刻是 1993 年 11 月 1 日，也就是 FreeBSD 1.0 的第一个正式发布日。演讲当天正好是 2014 年 11 月初，意味着 FreeBSD 刚好迎来了 21 岁生日。Hubbard 开玩笑说，由于时区换算的问题，如果想完全稳妥，大家大可以等到明天再正式庆祝系统 21 岁成年。 - 演讲者：Jordan Hubbard（FreeBSD 联合创始人之一，时任 iXsystems 首席技术官） - 会议背景：MeetBSD California 2014 - 关键历史节点：FreeBSD 1.0 发布于 1993 年 11 月 1 日 - 演讲时项目年龄：已走过整整 21 年历程 --- ### [01:35](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=95s) 软盘分卷、极简 Ports 与 1600 美元的 1GB 硬盘 Hubbard 调侃道，系统的最初分发介质“显然是穿孔卡片”，但实际上使用的是 1.2 英寸/3.5 英寸软盘。当时系统发布包被切成一个个约 230KB 或 235KB 大小的小文件。之所以选用这个极其别扭的切片尺寸，是因为它是 1.2MB 和 1.44MB 软盘格式的最大公约数划分方案。Hubbard 强调，这种“过去的技术限制深远影响甚至束缚当下设计”的现象，将贯穿整场演讲。 ```mermaid flowchart LR accTitle: FreeBSD 1.0 软盘分卷打包逻辑 accDescr: 展示早年为了兼容 1.2MB 与 1.44MB 软盘而切分成 230KB 块的分卷打包机制 subgraph Source["发布文件"] ISO["FreeBSD 1.0 原始镜像"] end subgraph Split["分卷切片"] Chunk["切片为 ~230KB / 235KB 文件块"] end subgraph FloppyMedia["物理分发介质"] F12["1.2MB 5.25 英寸软盘"] F14["1.44MB 3.5 英寸软盘"] end ISO --> Chunk Chunk -->|"写入"| F12 Chunk -->|"写入"| F14 ``` 随后他展示了一张早期的 Ports 软件包列表截图。在那个整个 Ports 树还极为简单的时代，总共只有大约 70 个移植软件，其中包括一个带 Bug 的 Bash。回顾硬件时，Hubbard 提到虽然当年那台用于构建 FreeBSD 的机器早已报废，但他清楚记得当时为了编译系统，咬牙花掉了 1600 美元才买下一块 1GB 容量的硬盘。他打趣道，幸好自己当时在做独立技术顾问才能负担得起。那台顶级编译机是一台 Intel 80486 DX2 处理器、主频仅为 50MHz 的电脑，在当时已是绝对的前沿生产力工具。 - 软盘切片设计：约 230KB–235KB 的分块是为了兼容 1.2MB 与 1.44MB 软盘的存储格式 - 初始生态规模：FreeBSD 1.0 时期 Ports 树仅收录约 70 个软件 - 早期编译机配置：Intel 486 DX2（主频 50MHz），配售价 1600 美元的 1GB 硬盘 --- ### [03:19](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=199s) 索尼 VAIO 与第一届会议的啤酒狂欢 画面切换到一张 Hubbard 与 Warner Losh 在日本的旧照。照片中他们十分年轻，Hubbard 怀里抱着当年的梦想笔电——索尼 VAIO（Sony VAIO）。VAIO 在当时是人人都渴望拥有的顶级笔记本，然而出厂预装的毫无例外全是微软 Windows 系统。 接着，Hubbard 展示了 1999 年在加州伯克利 Waterfront Radisson 酒店举办的第一届 FreeBSD 会议老照片。他笑着指出有些传统至今未变：照片里的 Kirk McKusick 捧着一大扎啤酒笑得合不拢嘴；David O'Brien 站在后排，怀里甚至揣着两扎啤酒；前排还有人举着一个空扎啤杯。Hubbard 回忆道，那天早晨酒店由于管道故障断水，导致所有参会者都无法洗漱，一身邋遢怪味地坐在一起开会，但大家依然沉浸在极度纯粹的技术快乐之中。 - 早期移动计算基准：索尼 VAIO 为顶级硬件代表，但全系默认绑定 Windows - 社区聚会轶事：1999 年 Berkeley Radisson 会议突遇清晨停水，参会者在无法洗漱的情况下边喝啤酒边交流 --- ### [04:39](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=279s) 20 年前商用生态：物理机、ISP 与显性的 Unix Hubbard 概括了 20 年前 FreeBSD 的商业版图。当时 FreeBSD 最核心的支撑场景与商业标杆是互联网服务提供商（ISP），无论大中小规模的 ISP，都是 FreeBSD 的立足之本与衣食父母。此外，大量爱好者和小型工作室热衷于 DIY：插上两块 ISA 网卡，配上一台小主机，就能自行攒出一台 SOHO Web 服务器或硬件防火墙路由器。 在企业级客户方面，FreeBSD 既有 Yahoo 这样一路陪伴至今的忠实大型旗帜客户，也有 Hotmail 这种特殊案例。谈及 Hotmail，Hubbard 调侃道：“我们还曾拥有 Hotmail，但对他们而言我们就像个尴尬的秘密，于是一旦有机会他们就以最快的速度把我们彻底换掉了。”在个人使用上，当时主要是极客开发者在自己的台式 PC 上安装 FreeBSD 做本地开发。Hubbard 总结了那个时代最核心的物理与心理特征：绝大部分运行 FreeBSD 的设备都是依靠交流电（AC）供电的物理 PC，而且它的存在感极高——每个人都清清楚楚地知道自己眼前跑的就是 FreeBSD。 “当时的商业世界完全不同，支持 FreeBSD 的主力就是各类 ISP；而无论用于什么场景，大多数机器都是插着交流电的物理 PC，FreeBSD 的角色是非常外显且为人所知的。”Hubbard 如此回顾道。 --- ### [05:54](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=354s) 硬件红利、移动革命与主流桌面系统的颠覆 将目光拉回 2014 年的当下，Hubbard 拿出兜里的闪存盘对比：这个可以挂在钥匙链上的小部件容量是他当年花 1600 美元买的硬盘的 64 倍；而一块售价仅 50 美元左右、带存储卡的微型单板电脑（如树莓派类设备），其计算能力已经远超当年那台 486 DX2 工作站。虽然现代开发者常常抱怨它们速度太慢——毕竟现代软件功能暴涨，Emacs 变得越发臃肿——但这标志着计算权力的普及。Hubbard 认为这是一个极其美妙的先兆：经济欠发达地区的开发者也能用极低成本获得硬件，并在上面刷入真正的 Linux 或 BSD 等原生 Unix 系统，他们起步时拥有的计算资源远胜当年项目的开创者。 随后 Hubbard 指了指自己台上的 MacBook 笔记本。与当年的索尼 VAIO 相比，它不仅拥有 16GB 内存和极其强悍的处理器，最本质的变化在于它内置了 BSD 内核机制而不是 Windows。Hubbard 指出，尽管有人争辩 OS X 是多种技术交织的混合物，但它默认自带 Terminal 终端，开箱即是极其完善的 Unix 开发环境。 Hubbard 强调，这彻底击碎了 20 年前的预言：“20 年前所有人的预测都是微软 Windows 将取得彻头彻尾的全面胜利，在主流设备上你将永远看不到 Unix 的身影——结果事实证明并非如此。” --- ### [07:50](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=470s) 基金会成熟、GPLv3“背摔”与走向幕后的 FreeBSD 从 FreeBSD 1.0 演进到当时的 10.1，Ports 数量从最初的 70 个激增至超过 24,000 个，代码提交者（committers）扩充至数百人。开发主力也从最初以学术界为主（当时商业公司参与者常被视作“怪人”），演进为商业力量与学术力量平分秋色、商业实体居多的健康格局。更重要的是，FreeBSD 获得了长期稳定的资金支持。Hubbard 自嘲道，自己过去尝试把 FreeBSD 进行商业实体化运作以失败告终，而 Justin Gibbs 创办的 FreeBSD 基金会（FreeBSD Foundation）则取得了巨大的成功，得以全职资助专职员工做琐碎脏活，或资助那些充满奇思妙想却缺乏资源的独立开发者。 商业诉求的另一大结构性转变源于开源许可协议的演变。Hubbard 形象地将其比喻为“柔道背摔”：企业界原本以为遵循开源规则即可，结果 GPLv3 的发布让很多大公司的法务与工程团队猝不及防，深感恐惧。虽然 Linus Torvalds 出于充分的理由公开拒绝将 Linux 内核升级为 GPLv3，但 GPLv3 带来的法务合规风险依然促使大量商业公司调转方向，开始极为严肃地重新评估采用宽容型协议的 BSD。Hubbard 带着一丝调侃向理查德·斯托曼致谢，直言是 GPLv3 将庞大的商业客户推向了 BSD 阵营。 ```mermaid flowchart TD accTitle: 现代 FreeBSD 的嵌入式与隐藏化落地 accDescr: 展示 FreeBSD 从前台显性系统向底层技术栈及各类隐性终端设备演进的过程 subgraph CoreOS["FreeBSD 底层核心"] FBSD["FreeBSD 10.1 内核与系统层"] end subgraph Appliances["专用网络与存储设备"] PFS["pfSense 防火墙"] FNA["FreeNAS / TrueNAS 存储"] RTR["商业路由器 / 负载均衡器"] end subgraph Consumer["消费电子与新型终端"] PS4["主流游戏主机 (PlayStation)"] PHN["智能手机 / 平板设备"] EMB["智能手表 / 智能连接线缆"] end FBSD --> PFS FBSD --> FNA FBSD --> RTR FBSD --> PS4 FBSD --> PHN FBSD --> EMB ``` 最后，Hubbard 揭示了一个根本性的模式转变：现代 FreeBSD 正在“转入地下”，从过去的显性操作系统变成了底层不可见的“实现细节”。无论在 pfSense 路由防火墙、FreeNAS 存储系统，还是高端网络负载均衡设备中，厂商都会对其进行重新包装，赋予全新的产品身份，普通用户根本感觉不到 FreeBSD 的存在；FreeBSD 甚至成为了主流游戏主机（如索尼 PlayStation 4）的底层操作系统底座。 与此同时，Unix 设备的最大出货形态已演变为数以亿计的智能手机（iOS 与 Android）、平板电脑，以及即将到来的智能手表乃至带有微芯片的智能数据线。FreeBSD 的生存状态已经从台式 PC 时代的“外显系统”，彻底蜕变为广泛渗透在各类消费电子与网络设施内部的“隐形基石”。 - 系统版本跨越：从 FreeBSD 1.0 到 FreeBSD 10.1 - 软件生态扩张：Ports 树软件数量突破 24,000 个 - 治理与商业变革：FreeBSD 基金会实现常态化资金运转，资助底层基础研发 - 许可协议影响：GPLv3 的严苛限制促使各大商业公司重新倒向 BSD 协议 - 部署形态演进：从物理机前端转向路由器、NAS、安全硬件、游戏主机及移动设备底层实现细节 ### [11:40](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=700s) 隐形计算无处不在：连数据线里都跑着 Unix Jordan Hubbard 揭示了一个令人震惊的现实：计算的“无处不在”（Ubiquitous）已经渗透到了普通人根本无法察觉的角落。如今很多连接线的两端各集成了一个小型 ARM 处理器，内部运行着一套完整的软件栈。之所以这么做，纯粹是因为“这样更容易”——线缆若要处理视频转码、DRM 版权控制等复杂任务，工程师就必须依赖大量既有的软件库。摆在面前的选择只有两个：要么自己从零写一个微内核或嵌入式实时操作系统（RTOS），去吃力地模拟能够支撑这些库的整个用户空间（userland）；要么干脆把整套 Unix 直接塞进线缆里。结果显而易见，Unix 成为了最经济省事的方案。 - 现代线缆两端内置微型 ARM 处理器，靠运行完整软件栈来实现视频转码与 DRM 加密。 - Jordan Hubbard 强调：“So, like I say, I say ubiquitous, you don't even realize how ubiquitous.”（所以就像我说的，我说它无处不在，你甚至都意识不到它有多么无处不在。） --- ### [12:22](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=742s) 企业 IT 的剧变：BYOD 浪潮与云端全自动流水线 回到企业级市场，过去二十年同样发生了翻天覆地的转变。首先是“自带设备办公”（BYOD, Bring Your Own Device）彻底颠覆了企业与 IT 部门的运作方式。十年前，如果有员工把个人设备带到公司说要接入企业内网，IT 部门会大喊“安全违规”，随后该员工轻则被 HR 严厉谈话，重则被保安直接请出大楼；但现在，连 CEO 自己都在带个人设备上班，IT 部门别无选择，必须保证这些手机和平板能够与企业系统无缝互操作。这逼迫市场打开了前所未有的局面——过去“只要兼容 Windows 就足够了”的时代一去不复返。与此相伴的是云计算对传统数据中心的毁灭性打击，初创公司不再费时费力自建机房，全面转向云端租赁。 Hubbard 分享了一个极具画面感的真实故事：他的一位老牌 Solaris 圈内好友最近加入了一家旧金山初创公司，当场被眼前的工作流震得目瞪口呆。这家公司的两位创始人就坐在咖啡馆里抱着笔记本写代码，只需随手按下保存提交代码，后方的自动化流程便瞬间激活：云端立刻动态拉起大量虚拟机（VM），自动化回归测试全面铺开；不久后，暂存服务器（staging server）部署完毕并发出通知，测试人员上线把玩验证；确认无误后，系统甚至会自动进行 A/B 测试，直接向一定比例的真实线上用户灰度推送新版本。 ```mermaid flowchart TD accTitle: 现代云端持续集成与自动化发布流水线 accDescr: 描述创始人从咖啡馆提交代码到自动化测试、灰度发布的全流程架构 subgraph Dev["开发端（咖啡馆）"] A["创始人笔记本提交代码并保存"] end subgraph CI["自动化与验证环境"] B["云端动态创建虚拟机 (VMs)"] C["执行自动化回归测试"] D["部署至暂存服务器 (Staging)"] E["测试人员介入或触发 A/B 测试"] end subgraph Prod["生产环境与监控"] F["灰度暴露给部分线上用户"] G["自动化系统监控崩溃率与业务指标"] H["通过 Puppet / Chef / SaltStack 管理数以百计的主机"] end A --> B B --> C C --> D D --> E E --> F F --> G G -.-> H ``` 整个过程中，自动化系统会实时追踪用户是遇到了崩溃还是顺利完成了业务目标。在流量峰值期间，这套系统调用了多达数百台机器，生产环境常驻机器也有几十台——然而掌管这庞大舰队的，竟然只是坐在咖啡馆里的两个人，依靠 Puppet、Chef 或 SaltStack 这类自动化配置工具调度一切。那位有三十年工作经验的传统系统老兵看呆了三四个小时后感叹，自己从业三十年来根本无法想象系统能这样运转。 - 过去企业 IT 严格由 Windows 主导并封杀外部硬件，如今 BYOD 强制驱动了多平台异构兼容。 - 两位创始人仅凭笔记本与配置管理工具（Puppet、Chef、SaltStack），即可在咖啡馆内自动化操纵数百台云端虚拟机。 --- ### [14:48](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=888s) 虚拟化与“抹杀个性”：配置自动化重塑操作系统角色 虚拟化技术彻底重构了操作系统的存在形态。Hubbard 指出，除开手机、线缆里那些“隐性”（covert）运行的系统外，绝大多数显性（overt）部署的操作系统已经不再跑在物理裸机上；如果去统计全网运行的 BSD 机器数量，“肉眼可见”的物理机绝对只占极小一部分。更重要的是，管理大型虚拟机集群的自动化运维工具正在不遗余力地抹杀主机的“个性”（host personality）。 传统 Unix 管理员习惯把机器当作独一无二的个体，手工精调 `/etc/rc.conf` 或各种 dotfiles 配置文件。但现代运维工具极度厌恶这种独特性，它们把所有配置信息剥离到集中式数据库中，以便一次性批量铺设数百甚至数千台完全一致的无状态机器。在这种自动化浪潮下，操作系统不再是让人类敲键盘维护的对象，而是机器自动调度消费的原料。 - 显性运行的操作系统绝大多数已实现虚拟化，物理裸机部署退化为极少数。 - 自动化运维工具通过剥离本地配置文件至数据库，全面消灭单机配置的个性与独特性。 - 对此，Jordan Hubbard 总结道：“And of course because all this stuff is being pushed by automation, it's not humans editing RC comp files anymore or dot files. It's automation.”（当然，由于所有这些东西都是由自动化推动的，不再是人类在编辑 rc.conf 文件或各种点文件了，而是自动化系统在接管。） --- ### [15:53](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=953s) 操作系统即乐高积木：重新定义什么是“酷” 面对底层逻辑的剧变，Hubbard 抛出了一个核心拷问：在当今时代，究竟什么才是操作系统？他给出的最佳答案是——“操作系统是一套乐高积木”（A set of Lego blocks）。它本质上就是一堆模块化组件，供人们以各种有趣的方式拼装起来，去解决特定的显性或隐性问题。现实中，每个人都渴望去做那些肉眼可见、一眼看上去就很酷的项目，但 BSD 社区必须彻底转变对“酷”的定义。 社区应当学会享受打磨乐高积木的过程，因为这正是外界所渴求的。工业界需要更灵活、更通用、更标准化的积木块，以便随意重组其组件，向上向下任意伸缩：既能裁剪出极简微型系统塞入数据线或智能手表，也能平滑扩展装入手机、平板或大型服务器。随着硬件形态呈现阶梯式剧变，细分市场瞬息万变，操作系统的首要价值在于能够让开发者迅速拼装出对应场景的方案。 - 操作系统演化为可复用的组件库，核心竞争力在于灵活裁剪与通用标准化。 - 硬件形态涵盖从数据线、智能手表到平板与云主机的全阶梯跨度，要求系统积木能随需应变。 - Jordan Hubbard 向现场的 BSD 核心开发者提出号召：“So what this means to me for this room is that we have to change our definition of what's cool. We have to enjoy the process of making Lego blocks because that's essentially what people want.”（因此对我而言，这对在座各位的意义在于，我们必须改变对‘酷’的定义。我们必须享受制作乐高积木的过程，因为这本质上就是人们所需要的东西。） --- ### [17:12](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1032s) 移动设备的新物理定律：电池供电、多无线电与动态网络 移动计算环境给操作系统带来了全新的挑战。回顾 21 年前，绝大多数 FreeBSD 机器都插着交流电（AC）插座稳稳运行在机房，而如今绝大多数运行 FreeBSD 系内核的设备都是直流电（DC）供电、靠电池维持生命。实体线缆正在全面消失，操作系统必须对功耗极度敏感。 以一部现代 iPhone 为例，机身内部塞入了四到五种不同的无线电模组（Radio）——除最新加入的近场通信（NFC）外，还包含蓝牙、Wi-Fi、蜂窝网络等。这些无线接口随时都在开启或断开，路由状态瞬息万变，连接时刻在震荡（flapping）。这种极度动态的环境彻底打破了传统系统对“网络连接持久性”以及“单机配置稳态”的底层假设。为了在移动世界生存，系统不能再指望管理员在机器穿行全美时连上去开个 Shell 终端调试，而是必须建立全套遥测机制（Telemetry）和高层级诊断工具。 - 运行形态从稳态 AC 交流电、有线网络转向电池 DC 供电、无线动态环境。 - 现代移动终端（如 iPhone）多无线电共存（NFC、蓝牙、Wi-Fi、蜂窝），导致网络路由与连接频繁动态波动。 - 传统的本地 Shell 运维失效，系统设计必须向高密度遥测与高层级调试诊断体系转型。 --- ### [18:30](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1110s) 环顾竞争对手：Linux 与 Ubuntu 的追球策略 Hubbard 建议大家抬头看看竞争对手在做什么。打开 Ubuntu 的官方网站，导航栏的顺位清晰地揭示了其战略重心：排在第一位的是 Cloud（云），其次才是 Server（服务器）、Desktop（桌面）、Phone（手机）、Tablet（平板）和 TV（电视）。整套官网高调宣示着他们对智能手机的就绪度以及在云端排名第一的野心，同时还推出了像 Juju 这样旨在提供统一运维管理界面的工具。 Hubbard 借用冰球名言点评道，虽然 Linux 阵营并不总能真正“滑向冰球即将到达的位置”（skate to where the puck is going），但他们至少“看到冰球飞过去了，并且正在拼命追赶上去”。这种不沉溺于二十年前旧问题、全力跟进新前沿的姿态，本身就非常明智且值得警醒。 - Ubuntu 官网将“Cloud”列为第一优先级，随后依次为 Server、Desktop、Phone、Tablet 和 TV。 - 借助 Juju 等云管理界面，Linux 阵营正在全面抢占云与移动终端场景。 - Jordan Hubbard 评价 Linux 社区的战略敏锐度：“As I've said before, they're not really skating to where the puck is going, but they saw it go past and they're trying to catch up to it. And I think that's actually pretty smart of them.”（正如我之前所说，他们其实并没有真正滑向冰球将要去的地方，但他们看到球滑过去了，并且正试图追上去。我认为他们这样做其实非常聪明。） --- ### [19:23](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1163s) 突围之路：无情剔除技术包袱，确立新的“登山科考目标” 面对眼前的生存与发展问题，Hubbard 给 BSD 社区开出了开诚布公的药方。首先，社区思想必须保持开放，接纳全新的方法来解决经典问题；更重要的是，必须“冷酷无情地剔除历史包袱”（ruthlessly cull legacy stuff）。他举例指出，安装镜像里甚至还留有当年为了兼容软盘容量而强行切分成 235KB 的碎片文件，这类纯粹因循守旧的陈旧代码与技术负债若不坚决清除，系统就根本无法完成现代进化。 此外，社区无需凡事闭门造车从零手写，而应毫无心理负担地（shamelessly）借用外界已被验证行之有效的开源技术，充分调动在场各大商业公司贡献的成果来巩固基础组件。 最后，Hubbard 提出了最核心的号召：为社区确立宏大的“登山科考目标”（mountaineering expedition）。21 年前，FreeBSD 一无所有，但大家拥有一个极其明确且凝聚人心的山峰——“杀入机房，成为企业后台的首选解决方案”。为了攻克那座高山，所有人齐心协力适配大量驱动、大幅提升系统稳定性，即便攀登过程中充满艰难险阻甚至牺牲，也是一场令人心潮澎湃的冒险。而眼下，虽然山峰变得更多、前路更加分散，但社区绝不能退化为纯粹松散的业余爱好者俱乐部（hobbyist activity）；大家必须坐下来共同选定几座核心山峰并达成共识，唯有清晰统一的远大目标，才能重新吸引并激励下一代顶尖工程师。 - 必须果断清理诸如“为兼容软盘切分成 235KB”等僵化的历史遗留代码与过时机制。 - 摒弃“非我所创”（Not Invented Here）偏见，善用外部开源成果与企业力量，不重复造轮子。 - 确立明确的“登山目标”，避免社区沦为单纯凭兴趣敲代码而缺乏工业凝聚力的业余社团。 - Jordan Hubbard 警示纯业余化开发的局限性：“Now it's getting a little bit more difficult. There are multiple mountains, but we have to pick at least a small handful of them and agree that that's where we're all going because if it's just a hobbyist activity and people are just hacking for the sheer fun of it, I don't know that that focuses the next generation of engineers.”（现在情况变得更加困难了。眼前存在着多座大山，但我们至少得挑选其中的一小部分，并达成一致共同向那里进发；因为如果这仅仅是一项业余爱好活动，大家只是为了纯粹的好玩而写代码，我不知道这是否还能把下一代工程师的精力聚焦起来。） ### [21:27](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1287s) 吸引下一代开发者：需要“性感”的技术愿景 Jordan Hubbard 环顾在场的与会者，感慨地回忆起 FreeBSD 的早年岁月。当年他和同伴创立 FreeBSD 时，台下的一些人还在念高中；老一辈核心开发者悉心指导他们，而如今这些当年充满激情与抱负的年轻人都已成长为 FreeBSD 项目的领军人物。然而，面对未来的发展，Jordan 提出了一个亟待解答的问题：下一代的高中生和年轻开发者到底想要什么？他们对什么感兴趣？正如 Jordan Hubbard 所指出的那样：“To attract those people, you need a sexy goal or a series of sexy goals.” 要想让 FreeBSD 在未来十年继续保持活力，社区必须树立具有强烈吸引力的技术目标。 随后，Jordan 停止了宏观层面的务虚探讨，将话题切入到现场工程师能够付诸行动的具体技术需求上。他强调，如果希望机器能够实现自动化配置、让系统组件像乐高积木一样可组装，首先就必须解决系统底层混乱分散的痛点。 --- ### [21:52](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1312s) 统一配置文件格式与标准化 API 长期以来，FreeBSD 以及广义的 BSD 系统中充斥着多达五到十种甚至更多的配置文件格式，这种碎片化导致系统自动化配置极其繁琐。每个系统管理员或自动化工具不得不编写一套自制的 Perl 脚本去到处修改零碎的文件，试图在自己理想的配置管理模型与系统现存的混乱状态之间做“阻抗匹配”。Jordan 直言这种做法糟糕透顶，因为缺乏统一的标准，社区在配置系统该如何构建上根本无法形成有效协作。 在配置格式的选型上，社区里年复一年地争吵不休——有人主张用 YAML，有人主张用 XML，有人跳出来说 XML 太烂应该用 JSON，随后又引来另一波反驳。Jordan 认为格式之争无关紧要，核心在于达成 API 和统一解析库的共识：选定一个足够好的格式，提供一个标准的底层库，哪怕让它同时兼容两三种格式，最终社区也必须敲定单一标准，并对 `/etc` 下那些私自发明怪异格式的传统工具进行彻底重构改造。有了统一的标准，`lib` 库中才会首次出现一套标准的配置读写 API，后续新工具的开发者便无需再重写自己的配置解析逻辑。 为了证明这一理念的可行性，Jordan 搬出了苹果的成熟范例。无论是 iOS 还是 macOS（OS X），整个系统都统一建立在基于 XML 的 Property List（`.plist`）DTD 规范之上，并通过标准 Preferences API 进行交互。Jordan Hubbard 强调这种做法已经在极其庞大的系统中得到了验证：“Whether it's system preferences, whether it's per application preferences, user preferences, it doesn't matter. It all goes through that mechanism. And guess what? It works.” ```mermaid flowchart TD accTitle: Configuration Unification Architecture accDescr: Comparison between legacy fragmented configuration scripts and modern unified configuration API. subgraph Legacy["传统模式：碎片化严重"] A1["自定义 Perl 脚本"] --> B1["/etc/rc.conf"] A1 --> B2["/etc/resolv.conf"] A1 --> B3["私有 ad-hoc 格式文件"] end subgraph Unified["现代化统一方案"] C1["应用程序 / 自动化工具"] --> D1["统一 Preferences API (lib)"] D1 --> E1["单一配置格式规范 (如 plist / JSON)"] end ``` --- ### [24:04](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1444s) 适应移动环境：异步事件驱动与主动缓存失效 现代计算环境发生了剧烈变革。在 20 世纪 70 和 80 年代，机房里的 VAX 小型机从不拔掉交流电源，如果机柜断电，那绝对是一场灾难，大学管理员会雷霆震怒并对当事人严加惩戒。然而在当今移动计算时代，设备在电池供电和交流电源之间来回切换是家常便饭；Wi-Fi 掉线并迅速无缝切换到蜂窝移动网络也是随时发生的物理事件。更典型的是主机名变更：设备加入 Bonjour 网络后，如果局域网内存在重名冲突，系统便会自动协商变成 `foo-1`、`foo-2` 甚至 `foo-4`，如果开发者还假设系统的 hostname 从启动后就恒定不变，程序逻辑必然会崩溃。 与事件感知缺失同样严重的问题是混乱的系统级缓存失效机制。计算机科学中有一条公认的铁律：“绝不要缓存任何你无法主动使其失效的数据。”但在 Unix 系统中，开发者违背该原则的情况比比皆是。例如在修改了 Active Directory（AD）之后，由于查询 AD 服务器延迟较高，系统就把权限和所有权缓存在本地，且没有任何反向通知机制去清除脏缓存。当用户发现权限依然错误时，系统给出的解决方案往往是极其荒唐的“去点这个按钮”或“手动运行一下这个刷新命令”。 Jordan 借此阐明，操作系统必须建立一套中心化的异步事件处理机制。在苹果期间，团队花费了三到四周的时间反复辩论并设计出了 `notifyd` 的 API。以时区变动通知 `com.apple.system.timezone` 为例，当时工程师发现 `libc` 每秒钟居然调用 `stat()` 检查 `/etc/localtime` 上百次，原因是各个应用程序和底层库每次被调用时都在确认用户是否因为旅行跨越了时区。面对这种低效操作，苹果团队实现了一个基于共享内存与信号量的机制，并将时区变更纳入 `notifyd` 订阅链，彻底消除了频繁轮询对系统资源的浪费。 --- ### [27:14](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1634s) 守护进程管控变革：从 rc.conf 到现代化按需启动 谈到守护进程的调度与管理（Daemon Wrangling），Jordan 甚至当场打趣说老朋友 Devin 肯定不会赞同他接下来的观点。Jordan 回忆当年正是自己亲手提交了第一版 `rc.conf`，在那个时代，这确实是一大进步，结束了把所有脚本和配置杂乱无章硬编码写在 `/etc/rc` 或 `/etc/rc.local` 中且没有任何控制旋钮（knobs）的历史。然而，随后的演进并未解决本质缺陷。正如 Jordan Hubbard 所讽刺的：“All we've done is you know there's there's an old saying you can't polish a turd, but you can paint it. And all we've done is painted a number of times.” 无论社区后来给它刷了多么鲜艳的漆、无论如何将配置文件拆分到 `/usr/local` 等目录，其底层的致命短板始终未变： - **静态显式依赖（Static Explicit Dependencies）：** 启动脚本必须预先声明复杂的依赖关系，且这种拓扑一旦声明就是静态的，极易陷入无法维护的混乱。新安装的组件无法灵活报告“我五分钟前刚被安装，我依赖某某服务，当那些事件发生时请拉起我”。 - **全量常驻与电量消耗：** 守护进程启动后便常驻在后台做无意义的低频轮询（Polling）。即使一个进程每秒只轮询一次，系统中如果有 50 个这样的服务，就会产生 50 Hz 的唤醒中断，迅速耗光移动设备的电池。 - **调度机制多头割裂：** 早期系统同时存在 Mach IPC 激活、`inetd` 监听激活、`cron` 定时唤醒以及设备热插拔（`devd`/hotplug）等多种服务拉起通道。服务为了确认自己是否已被其他机制拉起，甚至需要依赖信号量进行多重登记，逻辑错综复杂。 Jordan 指出，尽管 Linux 社区围绕 `systemd` 经历了激烈的争吵，但 `systemd` 以及 macOS 的 `launchd` 其背后的核心理念是完全正确的：摒弃显式依赖，全面拥抱异步启动。守护进程应当基于 IPC 消息到达、硬件事件或定时器按需唤醒；当没有请求访问时，管理器应当能主动将其终止（shoot down）以节约资源。通过统一的守护进程管家，系统能够集中检测异常行为、治理耗电流氓进程，并统一管理网络套接字、USB、蓝牙等所有外设事件接入。 在结束这部分讨论前，Jordan 顺势引出了下一个移动化时代不可或缺的核心主题：系统遥测（Telemetry）与远程调试技术。正如 Jordan Hubbard 所斩钉截铁断言的那样：“Telemetry and remote debugging are huge you cannot live in the mobile space without these things period.” ### [31:20](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1880s) 远程遥测与 IP 崩溃调试的紧迫需求 Jordan Hubbard 首先澄清了社区中可能存在的一种误解：他并不是主张让每一台 FreeBSD 设备都向 freebsd.org 发送电子邮件或网络数据包来通报自身的存在。他风趣地调侃道：“美国国家安全局（NSA）根本不需要我们的帮助，他们早就在上游把这事给办了，而且他们的聚合节点比 freebsd.org 强得多。”但他严肃指出，FreeBSD 真正欠缺的是一套统一的遥测（Telemetry）API 和后台守护进程（daemon）来进行系统运行状态的注册与上报。现有的 syslog 根本算不上遥测，它充其量只是“系统里发生了某件事，你爱管不管”。 在移动设备上，调试往往是极具挑战性的痛点。Jordan 提到自己在 Mac 开发中最钟爱的特性之一就是基于 IP 网络的崩溃调试（debug over IP）：只要在系统内核崩溃（panic）时设置好了对应标志位，无论机器身在何处，工程师都可以直接通过网络远程接入，甚至可以配置自动化服务器去抓取所有关键日志并直接填入缺陷报告（bug report）。这种无需物理连接的调试机制，远比传统的串口（serial）或现已基本被淘汰但曾经因支持 DMA 而颇受欢迎的雷电接口（Thunderbolt）更为强大。在实验室环境中，开发者固然可以通过 JTAG 物理接线进行硬件级调试；但在实际的外场环境中，用户所能提供的至多也就是一个 IP 地址，而在无线 Wi-Fi 环境下甚至连 IP 都难以稳定维持，但具备网络调试能力无论如何也比两眼一抹黑要强得多。 - **syslog 与 Telemetry 的本质区别**：syslog 只是事件发生后的被动日志记录，缺乏结构化状态采集与分析能力；现代系统需要具备主动注册、监控和收集运行指标的遥测框架。 - **外场远程调试方案对比**：实验室高度依赖 JTAG 或专用线缆，而外场环境只能依赖 IP 网络进行调试信息的抓取与崩溃转储（crash dump）收集。 ### [32:56](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1976s) 移动参考硬件的抉择与“吃自己的狗粮” 随着 FreeBSD 社区在邮件列表中频繁讨论进军移动平台，核心痛点随之而来：什么是 FreeBSD 的参考硬件平台（Reference Platform）？Jordan 回顾历史，指出当年 PC 时代极其单纯，“只要弄一台 386 或更好的机器，带个内存管理单元（MMU）和区区 512MB 内存，你就能成为 FreeBSD 总监”，整件事非常直截了当。然而在当下的移动设备领域，选择却是一片混乱。去一趟上海，只要花 20 美元就能买到一台能跑的平板电脑，甚至有人买回一堆当圣诞礼物发给不知情的小孩。但廉价往往意味着硬件极其劣质，直接选择最低端设备注定是死路一条。Jordan 认为，FreeBSD 社区急需在平板或移动领域寻找一个类似于 BeagleBone Black 级别的中端标杆平台，集中力量攻坚，否则整个生态就像各自为政的“巴别塔”（Tower of Babel）。 更深层次的原因在于，将日常软件跑在真实硬件上能够倒逼底层架构的技术演进。Jordan 结合自身的经历指出，当年在 Linux 早期移动设备上摸爬滚打时，团队遇到了数不胜数的难题，而如果不去亲自使用、随身携带这些设备，工程师甚至根本无法意识到这些痛点的存在。日常使用真实硬件会强迫团队全面审视软件栈：从调试机制、遥测、守护进程，到为了改善糟糕的电池续航而必须调整的内核电源管理逻辑。面对台下可能出现的畏难情绪，Jordan 模仿社区惯有的退缩心态打趣道：“大家看到这里可能会说：‘天哪，Jordan，这听起来太难了，我们到底该怎么搞？算了吧，我们还是滚回去继续折腾 rc.d 脚本吧！’”但紧接着他严肃地发出警告：“不直面这一挑战的惩罚就是我们会被彻底淘汰，因为这正是时代的大势所趋。” > “真实硬件会强迫你去思考软件栈，去思考调试、遥测、运行在上面的守护进程，以及如何让电池寿命不那么糟糕。” —— Jordan Hubbard ```mermaid flowchart TD accTitle: 移动硬件平台倒逼软件栈重构 accDescr: 展示从选定移动参考硬件到倒逼底层内核、守护进程和调试机制改进的演进逻辑 subgraph Hardware["硬件平台选择"] H1["确立中端参考硬件<br/>（移动领域的 BeagleBone）"] H2["日常随身使用<br/>（真实场景试炼）"] H1 --> H2 end subgraph PainPoints["暴露系统核心瓶颈"] P1["电池续航极差"] P2["崩溃无法现场抓取"] P3["网络与状态频繁变更"] H2 --> P1 H2 --> P2 H2 --> P3 end subgraph Solutions["倒逼软件栈演进"] S1["内核级电源管理与调度重构"] S2["基于 IP 的调试与自动化遥测 API"] S3["事件驱动型守护进程与协同总线"] P1 --> S1 P2 --> S2 P3 --> S3 end ``` ### [35:23](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2123s) 像乐高一样积木化，拥抱时代主流 在总结演讲时，Jordan 呼吁 FreeBSD 必须全面贯彻“像乐高积木一样”（Lego-like）的系统理念，深入审视系统的核心构建块，并使它们能够以多种多样的形态被灵活组装。在工程哲学层面，他提出了衡量一名工程师成功与否的标准：“任何工程师用来衡量自己作品的根本尺度，应该是人们能否用它做出你从未想象过的东西。你应该为自己的造物感到惊喜与欣慰。”这种意外的扩展性不应当是第三方拿大铁锤硬敲进去的偶发事故，而应是高模块化、高可定制性以及高度灵活的发布工程所带来的自然涌现（emergent property）。 与此同时，社区必须果断精简支持的硬件架构，坚决淘汰那些在真实世界中仅剩几台老旧机器苟延残喘、却对维护者造成沉重技术包袱的平台，转而全面拥抱主流市场硬件。Jordan 强调，FreeBSD 完全没有必要闭门造车：无论是 OS X 还是 Linux，早在这个领域趟过了无数的坑并解决了海量问题，它们甚至在诧异 FreeBSD 为何动作如此迟缓。最后，Jordan 鼓励全场开发者，FreeBSD 依然具备广泛的生命力，只要愿意主动革新就能保持核心地位，并以一句铿锵有力的座右铭为演讲画上句号：“如果我们想要，未来就是属于我们的。”（“The future is ours if we want.”）现场随即响起了热烈的掌声。 > “任何工程师用来衡量自己作品的根本尺度，应该是人们能否用它做出你从未想象过的东西；你应该为自己的造物感到惊喜与欣慰。” —— Jordan Hubbard ### [37:16](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2236s) 现场问答：系统管理组件、接口解耦与平台基础设施困局 演讲结束后进入提问互动环节。现场观众首先抛出了一个历史技术趣梗：驱动程序里的私有数据结构名称 `softc` 到底源自何处？Jordan 坦言自己完全不知道，转头询问台下的 Adrian，引发了全场的轻松哄笑。紧接着，一位提问者直奔核心技术议题，询问 iXsystems 目前是否有团队正在研发类似于 OS X 中 `launchd`（服务管理）、`notifyd`（事件通知）或配置管理 API 的对应组件，以及外部开发者应如何参与。 Jordan 回应称，虽然眼下这一瞬间还没有立项产出，但这绝对是 iXsystems 势在必行的方向。他提到自己最近与 Outback Dingo 交流其移植的 launchd 项目时，就犀利地批评了其中的设计决策：为什么非要把 XML 格式硬编码进 `launchctl` 工具内部？这种设计极其愚蠢，当初就不该放进去。他指出，架构设计的核心原则是**绝不能把配置文件格式写死在工具内部**，格式应当在工具外部完成转换；工具底层只需要通过网络套接字接收通用的结构化字典（structured dictionaries）协议，前端无论输入的是 YAML 还是 CSV，都可以通过轻量转换器统一吐出合规数据。针对提问者提及的 `libplist` 以及正在热烈讨论的 `libxo`，Jordan 强调了统一事件协同框架对存储产品的致命重要性：在统一存储设备上，NFS、SMB 和 AFP 等不同协议的文件服务器同时运行，一旦主机名等全局配置发生变化，由于缺乏跨进程的协同通知机制，各个服务经常陷入混乱无序的状态。 随后，资深开发者 Alfred 就硬件平台选型提出了尖锐质疑：过去 20 年间社区多次押注于“今天还在、明天就死”的短命硬件；既然苹果设备的生命周期相对漫长稳定，FreeBSD 为何不直接针对苹果硬件平台进行支持？现场随即有人就 iPad 2 等设备的生命周期进行了调侃。对此，在场开发者与 Jordan 共同点明了问题的关键症结：当前限制 FreeBSD 进军移动和平板领域的根本阻碍，其实并不在于某一款具体的芯片或主板，而是**在此之上的整套基础设施完全处于缺失状态**——从进入帧缓冲（frame buffer）显示之前的引导，到通用的电源管理子系统，底层基础尚未打牢，此时无论选择哪块开发板（哪怕是 Raspberry Pi）都会被死死卡在半路。 > “你绝不能把配置文件格式直接写死进工具里面，你应该把它置于工具外部。” —— Jordan Hubbard ### [41:12](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2472s) 参考硬件与移动设备支持的现实困境 现场观众探讨了 FreeBSD 在参考平板电脑与移动硬件上的开发难点。有参与者指出，目前在树莓派（Raspberry Pi）等平台上，团队甚至连电源管理、帧缓冲（frame buffer）等核心底层功能都无法正常跑通；只有当把其中一个平台的底层软硬件彻底打通之后，移植第二个平台才会变得相对容易，后续端口的迁移阻力才会降低。然而目前整个项目在这类基础设施上依然严重缺失。对此，Jordan Hubbard 表示认同，直言在缺乏底层基础的情况下空谈高级功能实属“甚至消费不起的奢侈”，因为根本无法落地。 针对建立参考硬件平台的话题，现场进一步探讨了消费级硬件生命周期过短的痛点。消费级平板和廉价山寨设备在市场上的迭代极为动荡，往往几个月就会推出改款并改动硬件设计。有人反驳称 Apple 产品的生命周期很长，Jordan Hubbard 幽默地回应自己至今还留着一台第一代 iPad（虽然已经不用了），但同时也指出，若针对联想或市面上的山寨平板投入大量精力适配，开发者往往刚在论坛上发帖抱怨，厂商就已经推翻改版，导致系统在新设备上再度失效。面对这种硬件剧烈变动的生态，FreeBSD 目前尚无完美的应对策略。 ```mermaid flowchart TD accTitle: 移动硬件支持路径 accDescr: 展示 FreeBSD 在移动设备上实现可行运行的阶段性瓶颈与解决依赖 subgraph Phase1["基础能力缺失阶段"] A["缺少电源管理"] B["缺少 Frame Buffer"] C["设备生命周期极短/频繁改版"] end subgraph Phase2["首个参考平台突破"] D["打通单一参考硬件全套驱动"] end subgraph Phase3["横向扩展阶段"] E["移植第二个设备难度骤降"] F["实现模块化支持多种移动端"] end Phase1 --> D D --> Phase2 Phase2 --> E E --> F ``` --- ### [42:28](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2548s) 果断淘汰过时架构与历史包袱 与会者谈到了技术架构演进的规律，指出正如 Bill Joy 早年做未来十年预测时也会看漏互联网的崛起、误判可插拔智能 CPU 的趋势一样，预测技术本就极具风险；同时，系统中堆积了许多已无实际价值的架构（如 32 位的 x86 或过时的 Itanium 架构），理应被清理。Jordan Hubbard 借此呼应了他此前主张的“无情精简（ruthlessly cull）”，强调项目必须学会主动放弃毫无前景的历史包袱。 Jordan Hubbard 拿 FreeNAS 的实际决策为例，说明了告别陈旧硬件的坚决态度。他直言在 FreeNAS 9.3 中已经彻底剔除了 i386（32 位）架构的安装包，不再提供任何 32 位版本。面对部分用户想要在旧笔记本上运行系统的需求，他表示历史版本均有存档，用户大可留在旧系统里，但主干开发不能为了兼容老古董而拖慢前行的步伐： > “We're just saying the train is going that way and you can stay back in your warm cozy, you know, antediluvian world if you really want to using software to match it, but don't hold the train back from going as fast as it can possibly go.”（Jordan Hubbard 强调） - **FreeNAS 9.3 架构精简**：彻底淘汰 32 位 i386 镜像，仅保留 64 位支持。 - **历史归档政策**：旧设备用户可以使用旧版本归档，但新功能主干开发绝不向后妥协。 --- ### [44:40](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2680s) 基础系统的积木化与发布配置文件 现场一位女性开发者提出，回顾 FreeBSD 1.0 的代码树，系统比现在简洁得多；多年来，商业界和学术界为了各自的利益不断往基础系统（Base System）中强塞私有特性，且默认启用、无法关闭，导致体积臃肿。她建议应当重新审视基础系统，允许更灵活地裁减和组合。Jordan Hubbard 赞同该看法，并透露他与 Colin Percival 等人已经讨论过引入“发布配置文件（Release Profiles）”或依赖清单机制。 Jordan Hubbard 解释道，随着系统发展，基础系统（Base）与外部扩展（Ports）之间的界限已经逐渐模糊。项目需要建立一套像“乐高积木（Lego blocks）”一样的构建机制，允许通过轻量化的清单来选择要打包进 ISO 的组件集合。这种思想类似于现有的 NanoBSD 工具，但应该更深度地集成进 FreeBSD 官方的发布工程（Release Engineering）流程中。如果开发者想要在构建中彻底扔掉 Perl 或其他组件，系统理应原生支持这种高度模块化的定制。 --- ### [46:15](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2775s) 降低社区参与门槛与“为什么（Why）”的意义 在问答环节的最后，观众席中一位名为 Jennifer 的新成员向全场发问：“有多少人加入社区还不到 6 个月？”在得到热烈回应后，她提出了关于社区文化与准入门槛的建设性意见。她指出，FreeBSD 目前的官方网站缺乏清晰的新人指引；新手想要参与贡献时，只能看到邮件列表，或者在 ideas 页面看到诸如“做任何事前请先联系我们”的警示，让人无所适从。相比于专注于“让系统变性感（sexy）”或“淘汰旧代码”，社区更应该明确列出新成员可以从哪些积极、具体的步骤切入，以吸引更多元化的人才，而不是陷入像某些 Linux 社区那样动辄训斥新人的不良氛围。 Jordan Hubbard 对此表示完全赞同，承认社区确实必须在“如何参与（How）”上下功夫，把贡献流程打磨得尽可能清晰、低门槛和无阻力（frictionless）。但他同时也总结道，“为什么要做（Why）”与“怎么做（How）”同等重要；如果团队没有明确的战略方向和愿景，再顺畅的入门途径也会失去目标： > “I think the how certainly needs to be there and it needs to be clear and it needs to be, you know, as frictionless as possible. But I have to say also why is pretty important because without a why, how is kind of irrelevant, right?”（Jordan Hubbard 总结） ## Notable quotes > [35:23](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2123s) 任何工程师用来衡量自己作品的根本尺度，应该是人们能否用它做出你从未想象过的东西。你应该为自己的造物感到惊喜与欣慰。 — Jordan Hubbard > [32:56](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=1976s) 真实硬件会强迫你去思考软件栈，去思考调试、遥测、运行在上面的守护进程，以及如何让电池寿命不那么糟糕。 — Jordan Hubbard > [37:16](https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=2236s) 你绝不能把配置文件格式直接写死进工具里面，你应该把它置于工具外部。 — Jordan Hubbard ## Mentioned Jordan Hubbard, Warner Losh, Kirk McKusick, David O'Brien, Justin Gibbs, Linus Torvalds, Richard Stallman, Devin, Adrian, Outback Dingo, Alfred, Bill Joy, Colin Percival, Jennifer, FreeBSD, FreeBSD Foundation, FreeNAS, TrueNAS, PC-BSD, iXsystems, NanoBSD, Sony VAIO, Intel 80486 DX2, Yahoo, Hotmail, Solaris, Puppet, Chef, SaltStack, Ubuntu, Juju, iOS, macOS, OS X, Apple, Active Directory, launchd, notifyd, systemd, BeagleBone Black, Raspberry Pi, PlayStation 4, pfSense ## Video description Slides: http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years iXsystems is a leading provider of Open-Source server and storage solutions. Some of the projects we contribute to are FreeBSD, FreeNAS, PC-BSD, etc. The content in this video may not reflect the views of iXsystems as a whole. To learn more about our company, head on over to our website: http://www.ixsystems.com MeetBSD California is the premier BSD conference in the San Francisco Bay Area. Since its inception in 2008, MeetBSD California has been held every two years in Silicon Valley, bringing together BSD community members from all over the region and around the world. For more information visit http://www.meetbsd.com [Source](https://www.youtube.com/watch?v=Mri66Uz6-8Y)

[35:23] Jordan Hubbard: 任何工程师用来衡量自己作品的根本尺度，应该是人们能否用它做出你从未想象过的东西。你应该为自己的造物感到惊喜与欣慰。 [32:56] Jordan Hubbard: 真实硬件会强迫你去思考软件栈，去思考调试、遥测、运行在上面的守护进程，以及如何让电池寿命不那么糟糕。 [37:16] Jordan Hubbard: 你绝不能把配置文件格式直接写死进工具里面，你应该把它置于工具外部。

[35:23] Jordan Hubbard: I think you know the fundamental yardstick that any engineer should hold their creation to is if people can do things with it that you never even imagined, you're a success. [31:20] Jordan Hubbard: syslog is not really telemetry. It's more something happened and maybe you care, maybe you don't. [27:14] Jordan Hubbard: Have nothing depend explicitly on anything else. Just let the fact that I asked you for something cause you to start. And then if no one's asked you for a while, I can shoot you again.

[0:00] Eurobd con. So if you were there and you [0:02] are bored, I'm sorry. [0:05] But uh this is actually a sucky title [0:07] for a talk because it's you know suggest [0:09] that I somehow know what's going to [0:11] happen in the next 10 years uh much less [0:13] the next 20 years and I have no clue. [0:15] But I'm going to I'm going to try and [0:17] talk about some trends and things that [0:19] uh have been going on in the last, you [0:22] know, five or six years that I think are [0:23] informing where we're going to go over [0:25] the next 10. So [0:26] yeah, [0:28] how about that? Okay, there we go. Can [0:30] you turn the gain up at all? Yes. No. [0:33] Don't really want to eat. Okay, I'm [0:35] going to eat the microphone. All right. [0:36] So, [0:38] but uh let's talk about to put this in [0:41] context kind of where we came from a [0:43] little bit here. Uh, and [0:46] I think [0:48] this date here is kind of interesting [0:51] because you see uh an email from my uh [0:55] personal machine uh in Ireland dated [0:58] November 2nd uh 1451. This of course is [1:01] in GMT. So the geeks among you will say, [1:04] "Wait a minute. Let's do the math [1:06] because we're in GMT minus 7 right now." [1:08] Blah blah blah. Forget it. It's all [1:09] right. Uh in fact you see here the [1:11] adjusted uh GMT date is actually the 1st [1:13] of November 1993. So that was the first [1:16] release of FreeBSD 1.0 [1:19] and so we are now 21 years old today. [1:30] But just to be sure wait till tomorrow [1:31] because you know time zones. [1:35] So our first distribution media was [1:36] obviously the punch card. [1:41] This is our actual distribution media, [1:43] the 1.2 in floppy. And the reason why [1:46] this is kind of interesting and relevant [1:47] is a lot of you will remember that [1:50] that's what the uh distributions used to [1:53] look like chunked up into these little [1:54] 230K files or 235K according to that [1:58] listing. Uh and why was that size [2:01] chosen, you might ask? as well because [2:03] that was the uh best advisor into either [2:06] 1.2 megabytes or 1.44 megabytes which [2:09] was the floppy distribution the formats [2:12] of choice at the time and um this meme [2:16] will continue to repeat throughout my [2:18] talk where we talk about sort of things [2:20] from the past affecting things in the [2:22] present. [2:24] This was our ports collection. [2:27] That's the entire porks collection [2:31] back when it was manageable. [2:34] So, uh, but you know, we have bash on [2:37] there. It had a bug in it. [2:44] And this was this was not my actual [2:46] FreeBSD build machine. I don't have any [2:49] pictures of that left. That machine has [2:51] been scrapped a long time ago. But, uh, [2:53] it looked something similar to that. And [2:56] I I paid uh I remember buying the first [2:58] 1 gigabyte hard drive and it cost me [3:00] $1,600 [3:02] to do builds. It was good thing I was a [3:04] consultant. Um [3:07] and of course it was a DX2 486 entire 50 [3:12] megahertz [3:13] and that was that was uh like cutting [3:16] edge for the time. [3:19] My laptop this is my dream laptop. Here [3:22] I'm in Japan with uh Warner. [3:27] You notice we look a little different [3:29] today. [3:32] That's that's a Sony bio. That was that [3:34] was the premier laptop that you could [3:36] you could want. And it of course shipped [3:38] with Windows by default. [3:41] Yes. [3:44] We'll get to that. [3:46] This was our very first conference. [3:49] Uh, as you can see, some things have not [3:51] changed. [3:54] There's Kirk with a picture of beer uh [3:57] and a very pleased looking expression on [3:59] his face. And there's David O'Brien in [4:01] the back with a very pleased expression [4:03] on his face. Two pictures of beer. [4:08] And I think that might be Doug White in [4:09] the foreground. I'm not entirely sure, [4:11] but uh yeah, that was a 199. [4:14] Was it? No, that's not Doug White. [4:18] I have no idea who that is. [4:21] He's hosting an empty picture, so I [4:23] don't know what he's trying to achieve. [4:26] Showing he won. [4:28] Yes. Uh yeah, Berkeley Rison. Uh right [4:30] on the waterfront there. Uh the water [4:32] wasn't working that morning. So we were [4:34] all funky and it was good times. Um [4:39] so 20 years ago, the commercial uh world [4:42] was also very different. Uh pretty much [4:45] our number one, you know, poster child [4:47] for FreeBSD at least was the ISP and uh [4:51] you know big ones, small ones, mediumsiz [4:53] ones. Those were our bread and butter. [4:56] Um a lot of people were also building uh [5:00] small, you know, sort of Soho web [5:01] servers and routers. You know, get a [5:03] couple of ISA nicks and boom, you have [5:06] yourself a firewall. Uh and you know, [5:08] very DIY. you just kind of pieced these [5:11] bits together and uh did your best and [5:14] um obviously we did have a couple of [5:16] large poster children and some at least [5:18] one of which we still have today which [5:20] is Yahoo. We also had Hotmail but we [5:23] were an embarrassment to them and they [5:25] got rid of us as soon as they possibly [5:26] could. U and then of course you had a [5:29] lot of uh desktop machines that [5:30] developers just put together for [5:32] themselves to to do software [5:33] development. And uh the the one key [5:37] characteristic of this time was that the [5:39] majority of FreeBSD machines were [5:40] physical PCs and they ran out of AC. So [5:44] we'll get we'll get to that in a minute. [5:46] But uh it was a fairly overt role for [5:48] FreeBSD and it was really clear that you [5:50] were running FreeSd [5:52] running it. [5:54] So that brings us to the present day. [5:57] Uh, that drive there is 64 times bigger [6:00] than the thing I paid $1,600 for uh, 21 [6:04] years ago, which is still astounding. [6:07] You can stick it on your keychain and [6:08] carry it around. [6:10] That there uh, for about 50 bucks with [6:13] the storage card is far more powerful [6:16] than my first 486 DX2. [6:19] And uh you know, of course, it's still [6:21] considered too slow now because we do a [6:23] lot more stuff and Emacs has gotten [6:25] bigger, but still [6:28] still that's a pretty impressive thing. [6:30] And what I find really really neat about [6:32] that and kind of a har what I hope is a [6:33] harbinger of things to come is that now [6:35] these machines uh this class of machine [6:39] is re is within the reach of people [6:41] without much money. And so you're going [6:43] to hope that we're going to see a lot [6:44] more developing countries buying these [6:46] things, sticking a real Unix [6:49] distribution on uh their thing, whether [6:51] it's Linux or BSD. Uh they have far more [6:55] to work with than we ever did. [6:58] So yes, I got a Mac. It's right here. [7:02] Um, but one key difference uh other than [7:05] the fact that it's got 16 gigs of memory [7:07] and a processor that's many many times [7:10] more powerful than anything that ever [7:12] shipped in a bio uh is that it's got BSD [7:15] in it instead of Windows. And I know uh [7:18] you know some folks think OS 10 is not [7:19] really BSD. Well, yeah, it is a hybrid [7:21] of a lot of different technologies, but [7:23] there are terminal windows by, you know, [7:25] in the default install and and you can [7:28] use it as a a Unix development device. [7:32] So, that I think is is pretty [7:34] interesting, completely contrary to what [7:37] everybody predicted 20 years ago. The [7:39] prediction 20 years ago is that Windows [7:41] would win completely and utterly and you [7:44] would never see Unix on a mainstream [7:46] device ever. Ha. [7:50] Other things that have changed obviously [7:52] from 1.0 0. We're now up to 10.1, which [7:55] is kind of symmetrical if you look [7:57] backwards. Uh there are over 24,000 [8:01] ports. There were 70 in that first [8:03] screenshot I showed you. And there are [8:05] hundreds of committers. Uh even more [8:08] evenly spread out now between academia [8:10] and commercial. Uh I think I can say [8:13] safely that in the very beginning days [8:14] of FreeBSD, most folks were from [8:17] academia. There were a few commercial [8:19] interests here and there, but they were [8:20] kind of the weird people. Uh now the [8:23] weirdos have taken over and it's largely [8:26] commercial which is actually good. Um we [8:29] have sources of long-term funding. Uh a [8:32] few of us myself included tried to to [8:34] make a go of uh creating sort of you [8:36] know pseudo legitimate enterprises [8:39] around FreeBSD. I totally screwed up. [8:42] Justin did a really nice job with the [8:45] foundation by contrast. And uh and this [8:48] is this is pretty awesome now because [8:49] now you can start funding the uh the [8:53] sort of the staff positions and the the [8:55] grunt work, the things that nobody [8:57] really wants to do too much. Uh or if [8:59] you have some, you know, wildass [9:00] experiment that somebody is really [9:03] talented and wants to do but doesn't [9:04] have the resources, you can fund those [9:06] sorts of things. Um but what's most [9:09] interesting is that the commercial [9:10] interests and the overall market have [9:12] changed almost completely from 20 years [9:15] ago. And one of the reasons is this guy [9:19] and the the GBL experience really has [9:24] turned into kind of this weird uh you [9:26] know judo thing where everyone thought [9:28] that they were making this kind of deal [9:30] and then they got flipped on their backs [9:31] by the GPLV3. [9:33] Uh and it's actually driven a lot more [9:35] commercial interest in our direction [9:37] because uh the GPLv3 is scary. It is a [9:41] very scary thing. uh it hasn't [9:43] completely taken over uh you know Lin [9:45] Star Tarbals has quite famously refused [9:47] to adopt it for you know a lot of good [9:50] reasons but uh it's made a lot of uh [9:53] legal departments and a lot of uh [9:55] engineering departments give BSD a [9:57] really strong second look so we have him [9:59] stallman to thank for that [10:04] sorry RMS but you did it anyway um so [10:08] the other thing that's interesting is [10:09] that now EST FreeBSD any flavor of BSD [10:14] is being kind of put more under the [10:16] covers. It's it is just an [10:18] implementation detail. So routers, load [10:20] balancers, security monitoring devices, [10:23] file servers, uh software appliances, [10:26] pfsense, fre um they're actually [10:29] rebranding it. They're calling it [10:31] something else like pfsense or freen. [10:34] And it's that thing that has an [10:36] identity. It isn't freest so much. uh [10:40] you as you'll hear later on today, it's [10:41] even the base operating system for a [10:43] popular gaming console. Um and of course [10:46] the embedded market is is exploding. So [10:49] the takeaway there is that FreeBSD is [10:52] now more covert. It's you don't [10:54] necessarily know you're even running it [10:56] anymore. [10:59] So kind of to riff on that, the biggest [11:01] Unix deployments we have now are phones [11:05] by sheer numbers. [11:08] uh whether it's Android or or an iPhone. [11:12] Uh tablets obviously [11:15] wristwatches someday soon uh which is to [11:18] me bizarre. I I've never imagined I'd [11:20] run a BSD on a wristwatch. That's really [11:24] really would have been cool but it's [11:26] it's interesting development. Uh and [11:29] obviously all these things are kind of [11:30] integrated together. They talk to each [11:32] other. So there's a lot more interesting [11:33] challenges of integration there. And of [11:36] course you have PSD in your cables. So [11:38] um what [11:40] uh yeah actually it turns out a lot of [11:44] cables now at each of the ends is a [11:46] little ARM processor and it runs a [11:49] complete software stack. Why? Because [11:51] it's easier. It's just if you're doing [11:54] video transcoding in the cable or you're [11:56] doing DRM enforcement or something [11:59] clever like that, once you start pulling [12:01] on all the various libraries that you [12:03] need to do those things, you very [12:05] quickly realize, well, I could either [12:06] create a little arts and emulate all the [12:08] userland bits that I need to support all [12:11] these libraries and all this code that [12:12] I've already got written or I could just [12:15] put Unix in there. So, uh, like I say, I [12:18] say ubiquitous. you don't even realize [12:20] how ubiquitous. [12:22] So just switch gears for a minute to the [12:25] enterprise. What's also kind of been a [12:27] fascinating observation over the 20 [12:29] years is this whole bring your own [12:31] device movement has completely [12:32] transformed the enterprise and it's [12:34] completely changed the way the IoT [12:36] departments work. uh 10 years ago if you [12:39] brought your own device and you said hey [12:40] I want to hook this to the corporate [12:42] network they would say security and then [12:44] you know you'd be escorted out of the [12:46] building or at least you know have HR [12:48] talk to you very sternly now of course [12:51] since the CEO is one of the people [12:52] bringing in the device it has to work [12:55] now it has to interoperate with us so [12:57] all those phones and tablets u they're [13:00] really forcing uh a play that never [13:03] happened before you again if it was if [13:06] it was Windows that was that was good [13:07] enough. Uh but now we're we're we're [13:10] getting in there in in routes that [13:11] nobody predicted. Uh the other [13:13] interesting thing of course is that [13:14] cloud computing has just about killed [13:16] the whole data center. U a lot of uh uh [13:20] small companies that used to build their [13:22] own infrastructure just don't even [13:23] bother. They just rent it. Um, and [13:27] what's also interesting in in my third [13:29] bullet here is uh I had a one of my Olar [13:32] friends talking to me about how he had [13:34] just joined this San Francisco startup [13:37] and he was completely amazed by the fact [13:40] that the founders just sat in a coffee [13:42] shop on their laptops and they would [13:44] commit some code and they'd hit save and [13:46] then all this automation would kick off [13:49] and VMs would be spun up in the cloud [13:52] and regression tests would start running [13:54] And at some point a staging server would [13:56] have the bits and they'd get a little [13:58] notification and they'd go to the [13:59] staging server and they'd play with it [14:00] and testers would mess with it for a [14:02] little while and then they'd say, "Yep, [14:04] it's good." Or they'd do AB testing and [14:06] it would just keep, you know, right on [14:07] its merry way and some percentage of the [14:09] of the user base would be exposed to the [14:11] new version. The automation would see [14:13] whether they were crashing or happy or [14:16] reaching their destination on the [14:17] website. And all of this would happen [14:19] with, you know, up to several hundred [14:21] machines at the very peak. Not to [14:23] mention the dozens that were actually [14:25] running the production versions. These [14:27] two guys in the coffee shop are running [14:28] all of them. And they're all doing it [14:30] via puppet or chef or salt stack or [14:33] something. And that's uh he he was very [14:36] dubious when he when he was first [14:37] introduced to this. And after about uh [14:39] you know three or four hours of watching [14:40] how it all worked, he said, "Wow, you [14:42] know, I never could have imagined [14:44] something like that when I first started [14:46] doing this 30 years ago. [14:48] So obviously virtualization is the other [14:51] huge thing that has changed and uh I [14:54] think it's it really is worth saying [14:56] that most OS deployments the overt ones [15:00] not the covert ones running in your [15:01] phone or your cables uh are they're not [15:04] physical. They're if you count noses for [15:08] all the BSD machines out there I'm sure [15:10] a very small percentage would actually [15:11] be physical machines. And if you look at [15:15] the automation tools that are used for [15:17] for administering these big VM clusters, [15:20] they do everything possible to erase the [15:22] host personality. They don't like all [15:24] those configuration files that [15:26] essentially make the host unique. They [15:29] try and put all that information [15:30] somewhere else in some database and then [15:32] provision hundreds of machines at once [15:34] or thousands even. So that's really [15:38] changing the game in terms of, you know, [15:39] how unique you even want to be. Um, and [15:43] of course because all this stuff is [15:44] being pushed by automation, it's not [15:46] humans editing RC comp files anymore or [15:50] doc files. It's automation. [15:53] So this really calls us to, you know, [15:56] makes me question is what is an [15:58] operating system anymore? And the best [16:01] answer I can come up with is it's a set [16:02] of Lego blocks. It's just uh it's just a [16:05] bunch of pieces that people put together [16:07] in various interesting ways to create [16:09] solutions uh either overt or covert. [16:13] What everyone wants to work on is [16:15] something more like that. Something [16:17] that's that's visibly and obviously [16:19] cool. So what this means to me for this [16:22] room is that we have to change our [16:25] definition of what's cool. We have to [16:27] enjoy the process of making Lego blocks [16:29] because that's essentially what people [16:30] want. They and they they want the wet [16:32] Lego blocks to be more flexible and to [16:34] be more universal and more standardized [16:36] so they can reshuffle the components [16:37] around and make really tiny versions of [16:40] an operating system to fit into a cable [16:42] or slightly larger ones to fit into a [16:43] wristwatch or slightly larger ones again [16:45] to fit into a phone or a tablet. As the [16:47] as the hardware's capabilities kind of [16:50] kind of staircases up, they want to be [16:52] able to easily create a solution for [16:54] that particular niche and that niche is [16:56] going to be constantly changing. So you [16:59] know the the challenge I put out to all [17:01] of you is that we need to become much [17:03] more interested in crafting you know the [17:06] the fundamental bits and and looking at [17:08] the roles that that the operating [17:09] systems are now playing in our lives. [17:12] So the other interesting things about [17:14] mobile is that um you know remember I [17:17] said earlier that at 20 years ago or 21 [17:19] years ago the majority of of freeb [17:22] machines were plugged into to AC power. [17:25] That is not true anymore. Majority of [17:27] free boosting machines are DC uh and [17:30] they're running off of a battery. They [17:32] are talking to cables. Wires are [17:35] disappearing. They are uh hugely [17:38] sensitive now to power consumption and [17:41] interfaces that come and go that I think [17:44] there are now four or five different [17:46] radios in a in a iPhone these days. I [17:49] mean the near field communication stuff [17:50] is just the newest, but there's [17:52] Bluetooth, there's Wi-Fi, there's [17:53] cellular radios. All of those things are [17:56] dynamic. Routes are flapping all the [17:58] time. Connections are coming and going. [18:00] And that really uh really screws with [18:04] your assumptions in terms of of [18:06] connection persistence and and just even [18:08] how the how the host is configured from [18:10] any given uh point in time. So to make [18:14] that work, you need a lot more telemetry [18:16] information from the devices. You need a [18:19] lot more highle debugging tools. You're [18:21] not going to get a shell prompt on a [18:22] phone as it's traveling across the [18:24] United States, but you might, but only [18:26] for a very brief window of time. [18:30] What's also kind of interesting is [18:31] looking at our competition a little bit. [18:34] If you look at Ubuntu's website, uh not [18:36] that many of you do, but uh you'll [18:39] notice that uh cloud is the very first [18:42] thing on there. Then server, whatever [18:44] that means to them, then desktop, then [18:46] phone, then tablet, TV, and of course [18:48] looking at the the bigger thing you're [18:50] getting now from the menu bar, they're [18:52] all about ready for smartphones, number [18:54] one for cloud. Uh, so and obviously I [18:58] don't even know what Guju is. I assume [18:59] it's some sort of casual plane of pane [19:02] of glass management interface, but the [19:05] Linux folks are already moving this way. [19:07] Uh, as I've said before, they're not [19:09] really skating to where the puck is [19:10] going, but they saw it go past and [19:12] they're trying to catch up to it. And I [19:15] think that's actually pretty smart of [19:17] them. They're not focusing on the [19:18] challenges of 20 years ago. They're [19:20] trying to get ahead. [19:23] So what this means to the BSD community [19:26] is that we really need to be open to to [19:28] some fundamentally new approaches to [19:30] solving sort of these classic problems. [19:32] Uh we also need to be willing to to [19:34] callull uh ruthlessly if necessary stuff [19:37] that's just legacy things like those [19:39] 235k files in a distribution because of [19:42] floppiness, right? Anything that's [19:45] that's ruthlessly legacy, you need to [19:47] logistically call. And I I I just think [19:50] that's the only way you can evolve. you [19:51] have to get rid of, you know, some of [19:53] the the obsolete DNA. Um, I also think [19:57] that rather than doing all this [19:59] ourselves, we need to be willing to to [20:01] shamelessly uh borrow other technologies [20:03] that that appear to be working well. We [20:05] don't have to do it all ourselves. We [20:08] can we can leverage open source and some [20:11] of the work of all these different [20:12] corporations who are represented in this [20:14] room to to make the fundamentals better [20:16] and we don't have to write it all from [20:17] scratch. Um and and finally I think and [20:21] this is really vital. We need to pick [20:23] some new big picture challenges. I call [20:26] this climbing the mountain [20:27] mountaineering expedition. [20:30] Having one of these things, having an [20:32] expedition focuses your efforts. It [20:34] gives everybody a visible goal. We are [20:36] going up there and it's going to be [20:38] hard. A few of us will die along the [20:40] way, but it will be exciting and it will [20:43] be an adventure. Um 21 years ago we were [20:48] nothing and we wanted to be in the [20:50] server room. We wanted to be the back [20:52] office solution of choice and that was [20:54] our mountain and we had to do a lot of [20:56] things. We had to support a lot of [20:58] devices. We had to be far more reliable [21:01] than we were when we started to climb [21:02] that mountain. But it was a mountain and [21:04] we were all you know more or less [21:06] committed to that destination. [21:09] Now it's getting a little bit more [21:10] difficult. There are there are multiple [21:11] mountains, but we have to pick at least [21:14] a small handful of them and agree that [21:16] that's where we're all going because if [21:17] it's just a hobbyist activity and people [21:20] are just hacking for the sheer fun of [21:22] it, I don't know that that focuses the [21:25] next generation of engineers. There are [21:27] folks in this room who were in high [21:30] school when uh I and other people [21:33] started FreeBSD and we mentored them and [21:36] you know they were promising and they [21:37] were eager, they were enthusiastic and [21:38] now they're the project leaders. And I [21:41] think that's awesome. But what are the [21:43] next generation, what do the next high [21:45] school students want to do? Right? To [21:47] attract those people, you need a sexy [21:48] poll or a series of sexy goals. [21:52] So to stop waving my hands a little bit [21:55] and and get more specific for this room, [21:57] you know, one of the things I talked [21:59] about in in terms of provisioning [22:01] machines automatically and and being [22:03] more Legoike uh is we need to unify our [22:07] configuration file formats. We need to [22:09] pick one and a single library for [22:11] accessing it. You need to be able to [22:13] pretty much drive the box around using a [22:15] single way of doing it because if as [22:18] long as there are five or 10, there's [22:20] probably more than that in the average [22:22] FreeBSD box or BD box in general, it [22:24] becomes so annoyingly hard that [22:27] everybody is just going to craft their [22:28] own collection of Pearl code that just [22:31] goes and stomps on all these things and [22:33] impedance matches between their [22:34] idealized view of configuration [22:37] management and yours. And that sucks [22:40] because there's no unity there. there's [22:41] there's there's no uh no collaboration [22:44] around what it really should look like. [22:46] So, I've been watching the debates for [22:49] years. It should be YAML. It should be [22:50] XML. No, XML sucks. It should be JSON. [22:53] No, what are you talking about? So, [22:57] just agree on the API. Maybe agree on [22:59] the library and have it eat a couple of [23:02] formats, but ultimately you're probably [23:04] going to need to settle on just one and [23:06] accept that it's good enough. And then [23:08] you're going to need to go back and [23:10] retrofit all the existing tools that are [23:11] reading their private files on our SL [23:13] Etsy in some weird ad hoc contrive [23:16] format. And guess what? What you'll also [23:18] get with this is for the first time [23:20] there'll be a set of APIs in lib for [23:22] reading and writing configuration data. [23:23] And the next tool won't have to write [23:25] its own because that's exactly what you [23:27] have to do today. If I write a tool from [23:28] scratch right now and I say where's my [23:30] API for doing preferences, everyone will [23:32] just look at me blankly. And so, you [23:35] know, here's a working example. Again, [23:38] it's XML. I don't care. Everything in [23:42] iOS and OS 10 are unified behind the XML [23:46] pedless DTD. And everything has been [23:49] made to speak that thing through the the [23:52] preferences APIs. Whether it's system [23:54] preferences, whether it's per [23:55] application preferences, user [23:57] preferences, it doesn't matter. It all [23:59] goes through that mechanism. And guess [24:01] what? It works. [24:04] So, another thing that comes up is we [24:08] need to be more asynchronous. We need to [24:10] be able to deal with things like radios [24:12] coming and going, events happening that [24:14] are outside of our control. Back in, you [24:17] know, the 70s and 80s, nobody unplugged [24:19] the vac. The racks never had to leave [24:22] ACR. They did. Really bad things [24:24] happened and university administrators [24:25] descended upon you with great wrath and [24:28] you never did that ever again. Well, [24:30] today people unplug devices all the [24:33] time. They go between battery and AC and [24:35] back and forth and back and forth. [24:37] That's an event. The the Wi-Fi leaving [24:40] and the cellular modem coming up is [24:42] another event. I I could sit here for [24:44] three hours talking about all the [24:46] diverse events that you can you can deal [24:48] with. The fact is they're they're [24:50] they're what are we we're dealing with [24:52] today. And so, um you know, even your [24:54] host name can change. That really messes [24:57] with people heads. Why would my host [24:59] name change? Because you're on a bonjour [25:00] network and they go and all fight for [25:03] the name foo and now it's foo one, foo [25:06] 2, foo 3, foo 4. They'll sort it out, [25:08] but if you think your machine is named [25:10] foo, you should go look again. So, you [25:12] know, there's that. And then finally, [25:14] and this one really really pees me a lot [25:17] because I see so many examples of this [25:18] done so badly. People cache information [25:21] all the time that they have no idea how [25:23] to invalidate. And you know there's some [25:25] axiom in computer science never cach [25:27] anything you can't invalidate. Well [25:28] people forgot that one because they do [25:30] it all the freaking time. And so you end [25:32] up with a lot of Unix systems where hey [25:34] I changed my active directory thing and [25:37] uh my permissions are still wrong my [25:39] ownerships are still oh yeah it's [25:41] because we kept the cache in that [25:42] because it's really kind of slow to [25:44] query the active directory server. Do [25:46] you have any notification for invalid? [25:48] No no just go push this button. Go run [25:51] this command. Right. It's just it's just [25:53] stupid. [25:54] Um, so again, we need a centralized mech [25:57] mechanism for dealing with that. And [26:00] because I spent 12 years at Apple, I'm [26:01] going to keep using Apple examples. [26:03] Sorry. Uh, you know, this is notif ID. [26:06] And, you know, we probably spent three [26:08] or four weeks just debating what the API [26:10] should look like. And then once we come [26:12] up with a way of getting every possible [26:14] thing that needed notification to work, [26:16] then we designed the tools and we [26:18] designed the demon. uh and if you you [26:20] know if you send a sig user one to notif [26:23] ID on a Mac you'll see that uh there's a [26:26] huge number of things subscribing to it [26:28] um in fact one of the biggest [26:30] subscriptions is the time zone variable [26:32] com.applesystem apple.system.time [26:33] timezone. And that came about because we [26:36] saw that lib C was checking Etsy local [26:38] time, stating it to see if somebody had [26:40] changed their time zone because they're [26:42] traveling. They was doing it hundreds of [26:44] times a second. Uh because all these [26:46] different applications, every time [26:48] they'd spin up a lip routine, they'd [26:50] say, "Uh, what time zone am I in?" That [26:52] was stupid, right? But again, there was [26:54] no way to to watch it or to to [26:56] invalidate a special lip cache of time [26:58] zone information. So we came with a [27:00] little shared memory 74 thing and that's [27:03] one of the notifications you you can [27:04] subscribe to. You can subscribe to your [27:06] host name hasn't changed. So again it's [27:10] really easy to do. We should do it. [27:14] And finally one of my favorite topics is [27:16] demon wrangling. Uh Devon's not going to [27:19] agree with anything I'm about to say but [27:21] um basically you know I I remember [27:25] committing I think the first rc. Comp [27:27] file. It seemed like a really good idea [27:29] at the time. Lots of knobs. We'll put a [27:32] bunch of things into a directory and [27:34] they can look at the knobs and it'll be [27:36] awesome. And it was better than what we [27:38] had. Basically, you'd hack everything [27:40] into NCRC or RC.local uh until and there [27:43] were no knobs to configure any of the [27:45] things in there. But all we've done is [27:48] is you know there's there's an old [27:49] saying you can't polish a turd, but you [27:51] can paint it. And all we've done is [27:53] painted a number of times. And we put, [27:56] you know, quite quite colorful paint on [27:58] it from time to time. And we've we've [27:59] extracted it out into user local and [28:01] other side directories where you might [28:03] want to put other configuration files. [28:06] But the real fundamental problem with [28:08] this approach is that dependencies are [28:12] explicit. You have to know what depends [28:14] on what and that becomes really rapidly [28:18] intractable. Uh and it's static. You [28:22] declare that set of dependencies once, [28:23] but things can't kind of check in later [28:25] and say, "Hey, I just arrived and I was [28:28] installed five minutes ago. I depend on [28:31] these things. Start me up when those [28:33] things happen or don't start me until [28:35] this other thing happens." It's really [28:38] hard to do that. Again, you can do it [28:39] manually. You can do service blah start [28:41] and you you can you can do anything [28:43] manually. Question is, do you really [28:45] want to? [28:47] So I'm you know trying not to suggest [28:51] launchd but uh you know even the Linux [28:53] die hards they've got systemd they've [28:55] had their huge debates about it they [28:57] seem to have mostly died down but the [28:59] the fundamental concept behind both even [29:02] if you were to come up with freebsd and [29:05] say that that was far better I'd be [29:07] totally cool with it as long as you [29:09] followed the same basic outlines which [29:11] is check in use IPC or timers or [29:15] hardware events to start things and have [29:18] everything completely asynchronous. Have [29:20] nothing depend explicitly on anything [29:23] else. Just let the fact that I asked you [29:25] for something cause you to start. And [29:28] then if no one's asked you for a while, [29:29] I can shoot you again. And that kind of [29:32] meta layer of demon wrangling turns out [29:34] to be incredibly important for power [29:37] consumption because a lot of people [29:39] write crappy code that just starts up [29:41] and then sits around doing stupid things [29:45] frequently. Oh, not even frequently. [29:47] Say, I only check once a second. Don't [29:49] look at me. Yeah, well, there are 50 of [29:51] you, right? So, now it's 50 hertz worth [29:53] of stuff happening and my battery is [29:56] going. [29:57] Plus, I have no way of even monitoring [29:59] you because you all started up via via [30:01] some ad hoc mechanism. So, I can't even [30:02] really tell that's why my battery is [30:04] doing that. But if they're all started [30:06] by a common agent, it can it can detect [30:09] stupidity and it can it can shoot you [30:11] down or refuse to start you anymore or [30:14] you know you know watch started because [30:16] we just looked at two different service [30:17] starting mechanisms. the Mach one for [30:20] starting things based on Mach IPC and [30:22] Inet based on starting things on other [30:25] IPC and we said we have to double [30:27] register things that listen on both and [30:29] oh and some people start that via cronh [30:32] now we have to have a some sort of [30:34] semaphore check to see am I already [30:36] running did someone start me already via [30:38] some of these other mechanisms we triple [30:41] and quadruple entry bookkeeping for some [30:43] things that could be started in a [30:44] variety of ways and we said this is [30:47] insane let's just merge it all together [30:49] and then at some point we looked at the [30:51] net and said there's hctis we forgot [30:54] about that and just went in there and [30:57] now all the USB stuff and Bluetooth [30:59] stuff and everything is all plug the [31:00] same mechanism there's one way of doing [31:02] that so I cannot speak highly enough to [31:05] how much that improves your life [31:09] I've mentioned this before but telemetry [31:12] and remote debugging are huge you cannot [31:14] live in the mobile space without these [31:16] things period and So, I'm not saying [31:20] that every FreeBSD device should send [31:22] email or packets to freebd.org and [31:26] declare its existence. Uh, as I say, the [31:28] NSA don't need our help. They already do [31:30] this upstream. They have better [31:32] aggregation points than freebd.org. [31:35] But what we do need is we do need at [31:37] least some API and some demon that you [31:40] can register information with. It's [31:43] better than syslog because sislog is not [31:45] really telemetry. It's more something [31:47] happened and maybe you care, maybe you [31:49] don't. Um, and of course debugging is is [31:54] hard on, you know, mobile devices and [31:56] uh, you know, one of the things I really [31:58] loved still love about the Mac is that [32:00] if it panics and I got the right flag [32:02] set, I can debug it over IP. I can just [32:05] connect to it remotely from wherever it [32:07] happened to be. I can set up servers [32:09] that do nothing but go and connect to [32:11] one for me and scrape it of all the [32:13] important information and stick it into [32:14] a bug report. And I can automate all of [32:17] that stuff if I don't have to rely on [32:19] physical connectivity of some other sort [32:22] like serial or Thunderbolt is dead now, [32:25] but that was kind of also a very popular [32:28] option because you could do DMA over it. [32:30] Again, if it's if it's in your lab and [32:32] it's under your physical custody, you [32:34] can do uh some some new things. how you [32:37] can JTAG debug your device that it's [32:39] under your physical custody, but it [32:41] doesn't tend to be the case in the [32:42] field. People are running the software [32:44] in scenarios where the best they can [32:46] give you is an IP address. And guess [32:48] what? On Wi-Fi, yeah, not even that, but [32:50] it's better than nothing. [32:54] So, [32:56] another thing that that that keeps [32:57] coming up in the mailing list is if [32:59] we're going to go in the mobile space, [33:01] what are the reference platforms? Right? [33:03] Back with the PC, it was pretty easy. [33:05] You just get a 386 or better. It's [33:08] anything with an MMU and [33:11] whopping 512 megs of memory and you are [33:13] a frequency director. And uh it was it [33:16] was pretty straightforward. I not [33:18] honestly this is where I'm at. I'm not [33:20] sure what the reference tablet is going [33:22] to look like. You can go to to Shanghai [33:25] today and buy a usable tablet for like [33:28] 20 bucks. I know people who go over [33:30] there and buy them as stocking stuffer [33:31] stuffers and then come back and hand [33:33] them out to uh poor children who don't [33:35] know what they're getting. Um but you [33:38] know they are pretty cheap. Um I'm sure [33:41] there are phones out there that are in [33:43] the same price bracket. Maybe the [33:44] cheapest won't be the best target. In [33:46] fact, I can pretty much guess by looking [33:48] at this town that crowd that it won't be [33:50] because they'll be too crappy. But [33:52] something in the middle sort of, you [33:54] know, the beagle bone black of the of [33:55] the mobile or or or or tablet space, I [33:59] think would be a very interesting thing [34:01] to determine and then get a certain [34:03] number of them and start working on them [34:05] so that we can actually collaborate [34:06] because right now it's a tower of babel [34:08] in that space. You want to pick a [34:10] platform, good luck. There's so many to [34:13] choose from. Um and and where I think [34:15] this is really pertinent is that having [34:18] this d this hardware that people [34:19] actually use and carry around and and [34:21] try to live on uh focuses your efforts [34:25] wonderfully because you very quickly [34:27] realize how much your life sucks and you [34:31] know I speak from personal experience [34:33] right we went through some of the first [34:34] mobile devices with Linux on them and [34:36] there were a lot of challenges that had [34:38] to be overcome but you won't even know [34:40] what those challenges are until you're [34:41] trying to trying to address them. So, as [34:44] I say, real hardware forces you to think [34:45] about the software stack versus thinking [34:48] about debugging, telemetry, the demons [34:50] that run on it, how you're going to make [34:52] battery life not suck. There are kernel [34:54] changes involved. It's just a whole [34:55] bunch of stuff that rolls out of that. [34:57] And, you know, we can all look at this [34:59] slide and go, "Man, Jordan, this sounds [35:01] really hard, and how the hell are we [35:02] going to do that?" And, yeah, let's go [35:05] back to hacking on RC.D. Um [35:09] the penalty for not grappling with this [35:12] is that we'll be left behind because [35:13] this this that's just where the puck is [35:16] going. Every you know these these mobile [35:18] devices are not only our future but are [35:20] our present. [35:23] So just to summarize all of it we need [35:25] to get more Legoike. We need to embrace [35:27] the notion of being Legoike and and look [35:29] at the fundamental building blocks and [35:31] how they're aggregated in different [35:32] ways. Uh I think you know the [35:35] fundamental uh yard stick that any [35:37] engineer should hold their creation to [35:38] is if people can do things with it that [35:40] you never even imagined, you're a [35:42] success. You should be surprised and [35:44] delighted by your own creation. Wow, I [35:47] never imagined somebody would stick that [35:48] in a cave. That should be cool, right? [35:51] So, but you'll feel better if it wasn't [35:53] an accident that happened and somebody [35:55] had to pound it into there with a [35:56] mallet. You'll feel a lot better if it's [35:58] like, yeah, actually that's an emergent [36:00] property of of us making it that [36:02] divisible and that customizable and [36:04] having the release engineering process [36:05] be something that have to be targeted to [36:07] so many different things. So, you know, [36:10] those are examples. Uh, you know, again, [36:13] just to to to to beat the dead horse, we [36:15] have to look at which hardware reference [36:17] platforms we support. Call the ones that [36:20] just, you know, have five examples [36:22] running in the wild today and are [36:23] burdening us with support and go after [36:26] the ones that are actually mainstream. I [36:28] can't say that strongly enough. And [36:31] again, there's no reason for us to do [36:33] this alone. There are lots of uh people [36:35] in the space, the OS 10s, the Linuxes of [36:38] the world uh who who've solved a lot of [36:41] these problems already and in fact are [36:43] looking at us and going what's taking [36:45] you guys so long or you're not even [36:47] relevant anymore because you don't have [36:49] any of the stuff and you're not even [36:50] thinking about and that's that's totally [36:53] unnecessary. We we can be absolutely [36:55] relevant and we are still relevant to a [36:57] large extent. We just need to get even [36:58] more relevant. So [37:02] I will leave you with this little maxim. [37:04] The future is ours if we want. Thank [37:06] you. [37:10] [Applause] [37:16] Thank you very much. Uh Jordan, that was [37:18] awesome. Um so right now we're uh [37:22] closing a little early. So would you [37:24] like to take some questions just about [37:25] your experience? [37:26] Sure. Approach it at me. [37:27] All right. Is that [37:29] a painted ship? [37:32] There you go. [37:33] Where does soft sea come from? Where's [37:35] that name? Soft sea. [37:37] Soft [37:37] in drivers. Yeah, there's that private [37:39] data in drivers. I was hoping you would [37:42] know. [37:42] I have no idea. Adrian, do you know? Why [37:44] do I know, dude? I [37:49] Yeah, but you but you follow more than I [37:58] Yeah. context or context. Okay, [38:00] there you go. [38:06] Ask the guy with gray hair. [38:08] He was first. [38:09] Um do you have any projects at um ex [38:13] working towards implementing a launch [38:16] the analog, a notify the analog, a [38:18] configuration management API? And if so, [38:20] how can I jump on board? [38:22] Um the answer is um not at this exact [38:26] moment but yes we I mean that's [38:28] absolutely something we want to do. [38:30] I was just talking to Outback Dingo [38:32] about his launch deport and going can [38:33] you get the XML out of launch detail? [38:35] It's really stupid. It shouldn't have [38:37] never shouldn't have gone in there but [38:39] you know it was like an expedient thing [38:41] right and you know again it's one of the [38:43] things that I was you know arguing about [38:44] in the list is you don't put the [38:46] configuration file format into the tool. [38:48] You put it external to the tool. You [38:50] have a little translator that just says, [38:51] "I speak something to you that has [38:52] nothing to do with XML." You know, [38:54] structured dictionaries over the wire. [38:56] Fine. I could have eaten YAML. I could [38:58] have eaten a CSV file and given you the [39:01] right thing. You know, that that's [39:02] that's how you architect it. So, [39:04] that just for people who are interested [39:06] that there's lib lists that JD did and [39:10] there's also lib xo which is being [39:11] talked about. Yeah, I've heard I like [39:13] I've been following the Lubeexo [39:14] discussions, but but to kind of answer [39:15] your meta question, [39:17] Systems needs all the things that we've [39:19] talked about to make a more robust [39:20] product to make something where NFS and [39:23] SMB and AFP and other file servers can [39:26] live on the same box and not fight and [39:28] because, you know, unless you can [39:30] coordinate certain events with all of [39:31] them, they're all just sitting there [39:32] going, "Whoa, whoa, my host name [39:33] changed. Uh, I'm out to lunch now." [39:36] Right? You we we need all those things. [39:38] And yes, absolutely. We we have we have [39:41] inside Iselon we have a sort of we have [39:44] internal versions of some of those [39:45] things. Um we would prefer to be using [39:48] something that other people are using as [39:49] well. [39:50] Send me email [39:52] Alfred. [39:52] So you're talking about targeting [39:55] hardware platforms. Yeah. And having [39:57] been for almost 20 years um I've seen us [40:00] target hardware platforms that are here [40:02] today gone tomorrow. one of the harder [40:05] platforms. The problem is that tablet [40:07] space is locked down with Apple. But I [40:10] always wonder if we targeted Apple [40:12] products because they have such a long [40:14] life cycle, it would give us something [40:16] that you could buy over and over again. [40:18] They do. [40:19] They do. [40:21] I'm being some somewhat physicious about [40:23] the long life cycle of Apple, but yes, [40:25] please continue to point the iPad 2 gone [40:28] forever and ever and now it seems iOS 8 [40:30] is completely under. [40:33] So, so let me answer the underlying [40:35] question. I think you're asking as I [40:36] said that was one of the slides where [40:38] I'm saying we need to do this and I'm [40:40] not sure how yet because because it's in [40:43] flux. [40:44] I'm I'm saying that we if we're going to [40:46] pick hardware platforms, we need to pick [40:47] hardware platforms that have a known [40:49] long life cycle that we want to do. [40:51] So one [40:52] so to answer that question what we're [40:53] actually actually missing isn't [40:55] supporting a particular hardware [40:57] platform for something like phone tablet [40:59] it's all the infrastructure that's [41:01] missing that we don't have because the [41:03] the the end point to bring up on an [41:05] onboard is just before frame buffer and [41:08] power management so it doesn't matter [41:10] which platform you pick even Raspberry [41:12] Pi the fact is right now we can't [41:15] actually bring up power management or [41:17] frame buffer or or anything to do with [41:19] that once we've done one of those, [41:21] right? [41:22] And then the second one will be less [41:23] complicated and then doing more ports is [41:26] less of a pain. But right now, we're [41:27] missing all of that, [41:28] right? Right. So So what you're saying [41:29] is basically it's a luxury we can't even [41:31] afford yet because it doesn't matter. [41:34] It's a moot point. And and I would agree [41:36] with you. And I mean, you know, we talk [41:37] about telemetry and stuff. We we can [41:39] build we can build a lot of the building [41:40] blocks that will allow us to run on a [41:42] reference tablet once that market stops [41:45] fluxing quite so terribly because it [41:48] does. Right now, Alfred, there isn't a [41:50] device that you can say that has a [41:51] threeyear lifetime. No, [41:53] there is. You can you can look at any [41:56] any Apple product. [42:01] Okay. I mean, you know, I'm not going to [42:02] argue against that. I think that's why I [42:05] still have a first generation iPad. I [42:07] don't use it, but I have it. [42:08] If you do happen to target one of those [42:09] knockoffs, they are cool devices. Are [42:11] they going to be there three months from [42:13] now or or not? We target Lono and Shin [42:18] post about how gosh darn it the new one [42:20] that just came out like like they just [42:22] revved it now working again. [42:25] It's a very legitimate point you make. I [42:26] I don't have a good answer right now. [42:28] Jim, [42:29] um a couple things. One like [42:32] those things as well. So we're on board. [42:36] Second thing sort of [42:39] in the room there are also architectures [42:41] that aren't doing anything for us [42:42] anymore. Nobody 32 x86. [42:47] I challenge you to buy [42:53] titanium would have been a better [42:54] example. [42:58] That was the second [43:05] hotel too. What I'm saying is that [43:07] you're not buying them now really [43:12] Intel and bless you. The third thing is [43:15] Bill Troy used to do this the next 10 [43:18] years and he missed some stuff like the [43:21] internet [43:26] be shipping people smart CPUs to plug [43:28] into their spare socket. [43:30] Uhhuh. [43:30] Right. So careful of [43:32] I I told you at the very beginning this [43:34] was a sucky title for a talk. [43:37] So, uh, but I mean Joe's point is is [43:40] valid, right? I mean, at some point you [43:41] do, I didn't use the words ruthlessly [43:45] callull together for no reason, right? [43:47] You do have to at some point say screw [43:49] it. We are not doing that anymore. Yes, [43:51] I know you have one under your desk. I [43:53] don't care. Moving on. Right? Because [43:55] here's where the mainstream is. I mean, [43:57] honestly, in Freen 9.3, I kicked the [44:00] i386 uh distributions out. There are no [44:03] 32-bit versions of Freenaz anymore and I [44:07] don't care. Yes, there are people who [44:09] want to run Freenaz on their 32-bit [44:11] laptop. I don't care. Run an old [44:13] version, right? They're archived. You [44:15] can still get the old stuff if you got [44:17] the old stuff. It's not like we're [44:18] screwing you retroactively. We're just [44:21] saying the train is going that way and [44:23] you can stay back in your warm cozy, you [44:27] know, antid-dolivian world if you really [44:29] want to using software to to match it, [44:33] but don't don't hold the the train back [44:35] from going as fast as it can possibly [44:37] go. And then she Sorry, she's been [44:39] having her hand up for a while. [44:40] Yeah. Um, one thing kind of talking [44:44] about pulling things from the base [44:46] system and everything like that is that [44:48] if you go back, as you obviously know, [44:50] to the 1.0 source tree, it's [44:52] considerably simpler. [44:54] Um, there are a lot of different [44:56] interests of course in the commercial [44:58] space and academia where everybody's [45:00] thrown in their favorite feature, [45:02] enabled it, and made it so they're not [45:05] optional by any means. Um, I think one [45:09] thing that we also need to do kind of [45:11] thinking about small footprint and [45:13] things like that. I know everybody loves [45:15] source.com, [45:16] but people need to go back through and [45:19] actually add those things into the base [45:21] system. Glenn and I have talked, you [45:23] know, first off, yes, absolutely. uh Con [45:26] and I've talked about the notion of [45:27] release profiles or some way of [45:29] basically saying this release is based [45:30] on these base components and these ports [45:33] components because at some point the [45:35] line blurs to to the point of [45:37] meaninglessness and if you can generate [45:39] an ISO with all the things you want very [45:42] easily with a kind of a manifest. This [45:44] is very much what Nanobsd does in a [45:46] little bit more convoluted a fashion. [45:48] It's not built in, right? But if you [45:50] could make the release engineing process [45:52] be able to subset or or expand the group [45:55] of software that you build, then yes, [45:57] you would have exactly that. And and [45:59] yes, it should be more Lego. That's why [46:00] I keep using the Lego analogy, right? It [46:02] should be the smallest number of blocks [46:04] that you can make. And if you want to [46:05] toss Pearl overboard, fine. We endorse [46:08] that idea. But I think I'm out of time [46:12] as well. So, uh, okay, one last [46:14] question. [46:15] Hi, I'm Jennifer. I have one question [46:18] before I make about it. How many people [46:20] uh are have been part of the community [46:24] less than 6 months? [46:27] I didn't hear that. [46:28] How many people have been part of the [46:29] community for less than six months? [46:33] Wow. [46:33] Awesome. So, what what I want to say [46:36] here is I think there's a missing sort [46:38] of goal. Uh you mentioned about making [46:41] it sexy. I would like to propose not so [46:44] much that, but if you go to the 3DSD [46:47] site and you are to look for how do I be [46:49] part of not just use FreeBSD, but part [46:52] of the community, there's mailing lists. [46:55] Uh the idea section basically says [46:58] before you do anything, here's some [46:59] ideas, but before you do anything, uh [47:02] talk to us. And I think that the [47:04] stepping stones into getting involved in [47:06] the community and being part of the [47:08] community um is missing a big portion of [47:12] like how do you do that? What are the [47:13] first steps? Um so there's a gap there [47:16] of like entryway into being part of the [47:19] community and actively doing something [47:21] not just using it. And then second, uh [47:25] the diversity in terms of ideas, um by [47:29] making it the door more easily [47:31] accessible, we'll get a lot more [47:33] different ideas. So it won't be so much [47:35] of a let's throw away things, but like [47:38] we're because that's like a like focuses [47:40] on the negative aspect, but on the [47:42] positive aspect of what are we building, [47:44] where are we going to so I totally agree [47:46] with the whole goals and ideas. I think [47:49] there's some missing aspects on focusing [47:51] on like here are the instead of not the [47:54] sex things work on but here are the [47:55] positive things what you can build on [47:57] what what you can work on um I think [48:00] here's a lot of negative associations [48:02] with some of you know like with Linux [48:04] like getting involved you know what's [48:06] the barrier to entry do you want to get [48:07] yelled at versus like you know previous [48:11] being more open right so that's just my [48:13] my two cents [48:14] so so I don't disagree with you I I [48:16] think the how certainly needs to be [48:18] there and It needs to be clear and it [48:19] needs to be, you know, as frictionless [48:22] as possible. But I I have to say also [48:24] why is pretty important because without [48:25] a why, how is kind of irrelevant, right? [48:28] Why are you even asking what's what's [48:31] what are we here to do? So they're both [48:33] they both they they fit together like [48:35] that, right? And they both have to work. [48:37] Anyway, thank you [48:41] [Music]