亲爱的FreeBSD：
我仍是这里的初学者，正学习你的行事方式，偶尔被你的古怪之处绊倒，却又因发现那些让你与众不同的细微之处而会心一笑。你让我想起计算机世界尚未喧嚣时的模样——那没有炒作周期和性能表演的年代，没有每个工具都需插件系统和标识的时代。你始终保持着内在的连贯性。你深思熟虑，是无需喧哗便能彰显价值的系统。
你承载着伟大者的静默力量，如同密闭房间里低吟的主机，不争风吃醋，只默默运转，年复一年。你的基础系统仿佛出自注重全局而非零部件的匠人之手。你的启动环境如同老式IBM i的“A面/B面”IPL机制，内置的应急通道昭示着：我们已为你预先规划。你本应成为开源领域的基石：与三至五年甚至更长的硬件生命周期同步，为长期信任而生，成为人们押注系统持续运行时间的平台。你们的核心设计令我想起Solaris的黄金时代：一个稳定的基础，让商业软件和社区软件都能安心依托，无需担忧根基动摇。
请将运行时间设定为设计目标：千日不间断运行不应是传说，而应是常态。它不该是炫技的把戏，不该是炫耀的截图，而应是经久耐用系统自然而然的结果。大型机从不为以年计的运行时间道歉，你们也应如此。更新时无需顾虑，仅在内核真正需要时重启，让管理员将持久性视为特性而非赌注。
我知晓你们正深入桌面领域。我理解其动机，也明白这将拓展你们的影响力。但此刻我不禁思索：如何在拥抱现代桌面快速脉搏的同时，守护坚如磐石的服务器心跳？我不敢妄称掌握所有答案——毕竟对你而言我还太年轻——但直觉告诉我应依托既有优势：CURRENT与RELEASE版本间的天然隔离。让两个世界各自运转，无需彼此承担妥协的代价。
如今随着 pkgbase 的引入，软件包的稳定性已与基础系统同等重要。基础系统必须保持不可撼动的可靠性，但我憧憬着这样的世界：软件包生态能在清晰的稳定性通道中自由流动——从足以支撑企业运营的坚如磐石的“生产层”，到快速迭代的新功能流，让创新得以奔涌而不必担忧破坏关键任务系统。过去太多包突然消失或崩溃。我理解核心神圣不可侵犯，但若更广泛的生态系统也能获得同等呵护，我绝不会反对。
文化同样重要。我离开Linux的原因之一，正是那些喧嚣的争论淹没了构建的乐趣。请让FreeBSD保持这样的特质：欢迎深思熟虑的工程实践而非 ego 之争，让企业级关注与技术探索能同桌共议。正是这份精神——这份将Unix从PDP-11实验室推向互联网骨干的沉着共同目标——值得守护。
实际层面同样重要：保持与戴尔、惠普等硬件厂商的合作通道畅通，确保FreeBSD始终享有顶级公民地位。请提供无需借用Linux或Windows即可刷写固件的工具。让硬件生命周期适配成为你们的故事主线，重大版本与现实世界同步推进，小版本更新应是优化而非颠覆。
我的期望很简单：愿你们保持独特。不是那种喧哗博取眼球的独特，而是赢得信任的独特。若有人追求炒作或每月追逐新潮，他们已有Linux可选。若他们渴求一个能像经典Unix系统那样持续稳定运行的平台，便该知道这里正是归宿。我依然憧憬着未来出现专为“开源大型机”打造的系统：搭载FreeBSD的现代化可靠硬件，如当年Sun企业级10k服务器般静默而坚韧地运转。
或许某天，当有人走过服务器机架时，会听见FreeBSD系统持续运转的平稳节奏，嘴角不自觉扬起微笑——在这个潮流更迭的世界里，终究存在着为永恒而生的事物。
怀着感恩之心，
怀着长久驻留的愿望，
一位终于找到归属的新人。
本文文字及图片出自 A Love Letter to FreeBSD
FreeBSD 26载岁月，仍在延续…
依稀记得99年左右，我厌倦了Mandrake和RH RPM包依赖地狱，在一本《核桃溪》杂志里发现了FreeBSD 3光盘。Ports系统和BSD软件包堪称革命性突破，更不必说那套至今仍让它与混乱的Linux系统拉开差距的文档体系。
关于选用Supermicro这类优质服务器主板的建议非常中肯——我曾管理多台搭载FreeBSD的Supermicro服务器近15年，这些主板始终表现稳定。
目前我在多台家用设备上运行FreeBSD，包括改造为家庭媒体中心的旧款Mac mini。
这些设备运行Kodi+Linux Brave软件，可流畅播放各类内容，包括体育赛事直播。
另有一台防火墙运行OpenBSD，另一台则部署PFSense(基于FreeBSD)。
> 关于选用Supermicro这类优质服务器主板的建议非常中肯——我管理过大量搭载FreeBSD的Supermicro机房服务器近15年，这些主板始终表现稳定可靠。
我完全赞同。
在顶级数据中心环境下，Supermicro主板搭载服务器级元件配合强力散热风扇/散热器运行FreeBSD，两台生产服务器实现了超过3000天的连续运行。期间经历了数十次应用/监狱环境/端口更新(除内核外几乎所有组件都经历过更新)。
早年担任系统管理员时(约2007-2010年)，一位在我入职前就管理大量系统的同事(RIP AJG…)偏爱FreeBSD，我很快明白了原因。我们曾在6.x版本上运行Postgres作为大型Jira实例的数据库，而Jira本身据我记忆是运行在Linux上的——因为我选择了当时性能碾压所有JVM的jrockit。那些Postgres服务器在小型托管机房里持续运行多年，从未故障，甚至比最终被合并拆解的组织寿命更长。FreeBSD就是如此敏捷，永不停歇。同时我还在FreeBSD上运行ZFS作为NFS等服务的核心文件存储，涵盖快照、发送/接收复制等全部功能。
所有这些确实都部署在Supermicro服务器硬件上。
并行部署中，虽然路由设备主要采用思科，但我仍在网络前端部署了运行pfSense 1.2或1.3的透明桥接防火墙。那是个嵌入式设备，搭载威盛C3/尼希米处理器，内置pfSense支持的威盛Padlock加密引擎。其AES256加密性能碾压我们中端思科ISR路由器里的至强处理器和加密加速卡——那些卡的价格甚至超过这台C3设备本身。它还配备了断电自保的以太网直通功能，运行着FreeBSD系统。此后我便一直使用pfSense，尽管Netgate已商业化，但习惯使然。
虽然如今某些场景我更倾向OpenBSD，但FreeBSD始终可靠——近二十年来从未让我失望。正如人们所说，它也该成为你的选择。
> 连续运行超过3000天
噢，这听起来令人不安。我逐渐意识到高运行时间其实很危险……这意味着你从未充分重启设备，甚至不清楚重启时会发生什么(所有组件能否正常恢复？系统是否依赖某个仅靠手动启动才运行的进程？等等)
我认为服务器需要定期重启，才能确保重启不会破坏系统。
>> 运行时间超过3000天
> 我认为服务器需要定期重启，才能确保重启不会破坏系统。
担忧关键进程被手动启动后无法在服务器重启时自动恢复，其风险与这些进程在服务器运行期间崩溃的风险相当。最佳实践是利用FreeBSD内置的“服务管理”[1]功能部署特定关键进程。
若存在不遵从上述规范而手动启动守护进程[2]的违规人员，那么该组织面临的问题远比服务器重启更严重。
0 – https://www.gilderlehrman.org/history-resources/spotlight-pr…
1 – https://docs.freebsd.org/en/books/handbook/config/#configtun…
2 – https://docs.freebsd.org/en/books/handbook/basics/#basics-pr…
这取决于它们的构建方式。当然，许多嵌入式/实时系统也要求这种可靠性。
我曾参与开发的系统允许每年停机8小时——但除核爆或断电外，否则可永久运行…Tandem系统。运行中甚至能拔出CPU。
所以若讨论的是垃圾Windows服务器，确实如此。关键在于客户/用户能接受什么标准。
我曾参与维护的系统每年允许8小时停机时间——但除此之外，除非遭遇核弹爆炸或断电，否则它们本可永不停歇地运行……这就是Tandem系统。你甚至能在运行时拔出CPU。
Tandem服务器以可靠性闻名遐迩。多年前我认识的硬件支持工程师们，常讲述着与你描述相似的经历：拔插组件(如CPU)而不影响系统可用性。
没错。我曾为某处做过外包工作，那里的服务器连续运行超过1200天。人们不敢重启任何设备。人员流动率也极高。
至今我仍清晰记得AJG。他曾告诉我自己是FreeBSD的贡献者。
我的FreeBSD之旅始于4.5或4.6版本，在Windows的VMware中运行，通过XDMCP连接桌面。速度极快，几乎达到原生系统水平。后来尝试Red Hat 9，相比之下慢如蜗牛。对我而言，选择不言而喻。后来我在ThinkPad上运行FreeBSD，至今仍记得那些编程的日子：使用教授的线性/非线性优化库进行开发，调试wlan驱动和固件以支持无线网络，甚至在回家的路上把笔记本塞进背包里编译Mozilla。我的个人纪录是：从未搞砸过任何一次FreeBSD安装，即便是在酩酊大醉时也不例外。
更晚些时候，我需要监控关键性能/延迟代码的CPU和内存使用情况。在FreeBSD和Solaris上，POSIX API完全按文档描述开箱即用。Linux？不行。我不得不亲自解析/proc目录，简直一团糟。结构不一致，甚至在同个内核次版本中行为也会改变。有时进程的CPU时间包含所有线程，有时又包含不了。
直到今天，我仍告诉人们：FreeBSD(及其他BSD系统)像真正的操作系统，而GNU/Linux像玩具。
> 我的FreeBSD之旅始于4.5或4.6版本，在Windows的VMware中运行，通过XDMCP连接桌面。速度极快，几乎达到原生系统水平。
哇，这勾起了不少回忆。记得有次任务要求使用锁定的Windows笔记本，但VMware是被允许的。
于是我在VMware里启动FreeBSD，运行X窗口系统并采用fluxbox[0]作为窗口管理器。即便同时运行多个rxvt终端和Firefox，VMware占用的内存还不到运行单个空白文档的MS-Word！
0 – https://fluxbox.org/
向伟大的袋熊致敬！
“彻底醉醺醺”的评论让我忍俊不禁，太熟悉了…虽然选择糟糕，但那段时光真美好！
这虽更关乎OpenBSD，但值得一提的是tmux之父nicm也曾与我们共处那个奇特小镇的小办公室。
AJG还为Postgres作出过贡献，并为BIND DNS记录编写过功能完备的精美网页编辑器。可惜该工具随他隐退而逐渐淡出，最终连同其域名tcpd.net一同湮没于时光长河——该域名现已过期被他人接管。
Linux在相对随意的情况下取得如此成就，实在令人惊叹。
FreeBSD始终是我最钟爱的操作系统。
正如帖子作者所言，它更具连贯性与深思熟虑，浑然一体。
> 考虑到Linux相对随意的发展模式，它取得的成就确实令人惊叹。
这种随意性恰恰是成功因素之一，它允许多种实现方案并行探索。
深入研读《FreeBSD操作系统设计与实现》后，我深有同感。真该花时间长期运行它。
绝佳著作。尤其其中对ZFS的阐释堪称我读过最出色的印刷版说明。
Linux将随意性转化为优势，令人叹服。
我更倾向FreeBSD。
我欣赏这种随意性，但系统d已偏离太远，近乎达达主义。
说得太对了。和Mac上的launchctl一样糟糕。这是为解决虚构问题而制造新问题的方案——就像IPv6那样
> 为解决虚构问题而存在的方案
初始化系统(https://en.wikipedia.org/wiki/Init)存在两大明显缺陷：
– 无法处理服务并行启动(系统管理员可通过调整初始化脚本加速启动，但初始化系统本身不提供任何支持)
– 无法适应设备频繁连接/断开的情境(例如USB/蓝牙设备、WiFi网络)。
第二个问题在初始化系统中通过进化方式得到解决：让多个守护进程执行基本相同的工作——监听设备连接/断开并进行处理。我认为将这些功能整合到单一守护进程中是明智之举。若认同此观点，则将该守护进程设为 核心 初始化进程也合乎逻辑，因为这能解决第一个问题。
没错，“解决方案”。我们需要一个实体。Systemd就是这个实体。因此我们需要Systemd。
无意引发口水战，但我对systemd的99%不满在于：它不仅取代了init进程，还接管了NTP、DHCP、日志记录(后者虽有必要性，但其实现过于复杂，尤其当需要将日志发送到集中式远程位置或使用其他工具查看日志时)等功能。这破坏了Unix历史性的核心理念：专注做好一件事。
更糟的是，systemd创始人(Lennart Poettering)固执己见的态度，导致众多系统管理员在实际应用中屡屡受挫(例如systemd-timesyncd的SNTP客户端无法有效处理时间漂移，或systemd-networkd无法处理真实环境中的DHCP字段)。他回应道“别用时钟漂移的计算机”或“我们不支持多数DHCP服务器使用的非标准字段”，这种态度与现实世界格格不入。结果必然不堪。多数发行版最终捆绑chrony等工具也就不足为奇了。
>(此项虽可辩称必要，但实现过程被复杂化，尤其当需要将日志发送到集中式远程位置或使用其他工具查看日志时)
这完全不复杂。较新版本的systemd支持日志转发功能，即便没有该功能，配置rsyslog也极其简单：
1. 安装rsyslog
2. 创建文件 /etc/rsyslog.d/forwarding.conf
3. 重启 rsyslog
4. 搞定。
你不会当真认为IPv4没有问题吧
当然不是。
但IPv6根本无法解决IPv4的问题。
IPv6是完全不同的东西，事后才用情感化论调来辩护——比如“你正在从孩子手中抢走最后一个IPv4地址！”
– 双栈方案——冗余且臃肿 – 性能下降4倍以上 – 取消NAT或私有网络——本质不同。人们总爱抨击NAT，但我可不希望烤面包机带着唯一硬件序列号连上网。 – 协议内置硬件追踪机制——所谓的缓解措施纯属胡扯。- 地址构成认知障碍——迫使人们使用DNS(中心化服务)，使其沦为审查咽喉点。
我们真正需要的只是额外的前缀空间来设定地址范围——例如'0'代表旧互联网的0.0.0.0.10地址段。这样既能向后兼容，又无需双栈方案，更避免隐私噩梦等问题。
我曾编写过实现这种网络覆盖方案的代码项目——但尚未准备好公开。不过确实可行。
若让我设想自己参与IPv6标准制定会议，核心诉求必然是“随时随地追踪每个用户和设备”——若仅为扩展地址空间，IPv6简直是过度设计，即便为未来千年隐私侵犯做准备也属过度。
> 我们真正需要的只是额外的前缀空间来标识地址范围——例如'0'代表0.0.0.0.10的旧互联网，兼容向后，无需双栈，更不会引发隐私噩梦等等
这正是IPv6的设计初衷。你的方案在纸面上看似完美简洁，但当你审视实际网络部署时，就会发现这种方案根本无法实现。网络数据包必须遵循位与字节的物理法则，而在IPv4中根本无处容纳这个额外0：无论如何都必须创建新的IPv6地址。虽然存在将IPv4地址封装在IPv6中的标准方案，但未部署IPv6的节点无法使用该方案，因此必须采用双栈方案直至全面过渡。
其实是有位置可容纳的…本不想深入讨论，但既然你问了：
我的原型/思想实验称为IPv40——这是对IPv4的40位扩展。
IPv40地址通过IPv4选项字段(类型35)在传统网络中传输
传统路由器会忽略选项35，仅根据32位目标地址转发(实质上强制流量进入“空间0”)。而支持IPv40的路由器会解析选项35以切换网络空间。
该方案目前通过软件叠加层实现，尚未硬件化。
这只是我编程/思维实验的产物，过程相当有趣。
每当IPv6这类方案自上而下推行时，我的蜘蛛感就会警铃大作——它究竟在解决什么问题？答案绝非“缓解IPv4地址空间限制”，那只是营销话术。若你质疑，只会招致人身攻击和情绪操纵。
你什么都没保存，因为所有人都需要先了解新扩展名才能使用它。
硬件很重要——快速路由器无法在CPU上完成工作(90年代中期刚出现时情况更糟)，它们需要专门的硬件辅助。
各位观点都很中肯——但我的初衷是探索技术可能性。事实证明可行，而且充满乐趣！当然我清楚这会导致性能低下，毕竟硬件条件有限。
所以必须更新所有路由器才能正确转发“非传统”地址。这和IPv6有何区别？
这反而是简单部分——核心路由器大多已支持IPv6数十年，据我所知骨干网甚至多采用纯IPv6架构。真正困难的是：只要存在未更新的客户端，就无法使用新型非传统地址，因为它无法与你通信。
就像现在这样，多数客户端可能支持新地址，但ISP不会为你路由这些地址。
当然我清楚这些。这正是“覆盖优先”策略的核心要义——即先在现有网络上构建可运行的网络，再考虑增加专用硬件等准入门槛。
因此新八位组要么置于IPv40地址的最低有效位——这种方案对缓解IP短缺毫无裨益(现有IP地址块持有者仅能获得原有地址量的256倍)
或者，它位于最高位，这意味着每个 新的 IPv4地址都将位于对旧路由器而言如同黑洞的地址块中，或者它们只会将数据转发到丢弃第一个八位组后得到的(错误)地址。
更不用说它仍然不具备软件兼容性(无法适应32位系统，所有系统调用都必须改变等等)。
这些问题都比现已成熟运行的IPv6严重得多。
> 它位于最高有效位，意味着每个新IPv40地址都属于特定地址块，对旧路由器而言如同黑洞，或者它们会直接转发至丢弃首字节后得到的(错误)地址。
旧路由器的黑洞。你得先运行软件覆盖层，直到能运行硬件层。
我编写了Linux内核模块和运行于每台主机的节点/中继守护进程。
存在一个专用的(0.)0.0.0.0局域网空间自动分配IP，我称之为标准局域网派对 🙂 告别10.0/192.168等网段，网关固定为.1——合理默认值。
地址范围扩展至0-255，相当于新增255个IPv4互联网的地址空间。数十亿地址绰绰有余。
或许哪天我会穿上防火服，把方案贴在这里博眼球，看看能引爆多少骂声。
我几乎完全赞同你的观点，但IPv6不会消失——它是我们唯一的现实选择。任何其他新标准即使达成共识，也需要数十年才能实施。核心路由器需要更换为搭载ASIC芯片的新设备来实现硬件路由等功能。现在开始已经太迟了。
不过IPv6那种委员会主导的开发模式至今仍让我摇头。天啊，最初的RFC文档竟将IPSEC支持列为强制要求，自动配置机制却不支持新增字段(如DNS服务器等)。简直像委员会里全是网络工程师。当年SLAAC与DHCP6的争论闹剧简直令人痛心。
话虽如此，现代IPv6实现已不再从硬件MAC地址推导链路本地部分(况且如今许多设备如手机会随机化Wi-Fi/蓝牙硬件地址以防追踪)。因此隐私问题已不再是主要顾虑，JavaScript指纹识别才是更严峻的挑战。
> 不过IPv6这种委员会主导的开发模式至今仍令人摇头。天啊，最初的RFC文件竟将IPSEC支持列为强制要求，自动配置机制却不支持新增字段(如DNS服务器等)。简直像委员会里全是网络工程师。看着SLAAC与DHCP6的对决闹剧上演实在令人痛苦。
深有同感。
> 话虽如此，现代IPv6实现大多已不再从硬件MAC地址推导链路本地部分(况且如今许多设备如手机会随机化Wi-Fi/蓝牙硬件地址以防追踪)。因此隐私问题已不再是主要顾虑，JavaScript指纹识别才是更严峻的挑战
JS指纹识别确实是个大问题。
坦白说，若IPv6仅用于物联网领域，我本可置之不理。但既然它被强制部署到每台设备上——用户被迫使用却毫无直接收益——我对此深感不满。
所以严格来说你并不需要它，但它解决了某些对你而言并非问题的问题，同时恰好解决了地址空间问题。我认为IPv6的“修复方案”不足以解决我的隐私担忧，尤其面对资源雄厚的攻击者时。这些措施似乎只是稍微提高了攻击门槛。何必费这个劲？请告诉我必须使用它的理由，但别用“你将无法访问IPv6托管服务！”或“想想孩子们！？”这类情感操纵手段——这两者都是情感操控。
浏览器/JS指纹识别同样适用于IPv4。况且你整个IPv4家庭网络很可能通过NAT转发ISP分配的DHCP地址(该地址极少变更)，因此跨网站追踪整个家庭用户轻而易举。你是否认为这构成隐私隐患？若否，原因何在？
> 请告诉我必须使用它的理由，但请避免使用“你将无法访问IPv6托管服务！”或“想想孩子们！？”这类情感操纵手段。
您或许未直接感知，但IPv4地址正变得昂贵——AWS近期已开始收费。云服务商正大量消耗这些资源。发达国家用户可能未受影响，但亚洲和非洲许多ISP依赖多层NAT为用户服务——当您需要或希望连接家庭网络时，往往真的无法实现。这还会破坏某些协议，具体影响取决于ISP的NAT处理方式(例如当经历两次以上NAT转换时，IPSEC VPN等协议基本无法使用；BitTorrent在此环境下也存在问题)。由于ISP实施NAT需要状态跟踪，某些情况下会引发性能问题。部分ISP还以此为由强制用户使用其DNS基础设施，进而进行二次销售(不过现在可以通过HTTPS over DNS来缓解这个问题)。
当然也有好处。CGNAT意味着我的手机不会直接暴露在危险的互联网中，也不会因DDoS攻击而破产，但其实还有其他更优的解决方案。
再次重申，我理解你的立场。但我们确实需要告别IPv4；IPv6虽有缺陷，却是唯一真正的替代方案。
这太对达达不敬了。
Linux看似杂乱无章，实则仅核心系统如此。类似FreeBSD的存在，其实是红帽、Debian这类Linux发行版。事实上systemd的初衷正是要消除Linux的随意性…但众所周知，它确实引发了巨大争议。
我认为Linux早期成功归功于许可证。当你开始公开代码时，这是必须做出的首要抉择。
是也不是。FreeBSD 4.3曾涉及知识产权纠纷，随后发布的FreeBSD 5系列更是问题重重——他们最初尝试在内核中实现M:N线程模型，还遭遇了SMP相关故障。
这不就是“更差即更好”的又一例证？
妙极了。若BSD家族能获得更多关注和应用，整个行业将受益匪浅。
我为朋友们运营EVE Online服务器。官方为非容器用户提供了手动安装指南。我在FreeBSD上搭建环境耗费半天，主要归咎于自己打字失误和操作疏漏。庆幸自己避开了“docker compose up”这个陷阱。
作为EVE Online服务开发者之一：虽然你能靠随操作系统变动的安装指南勉强应付，但对许多人而言，这可是他们在类Unix系统上首次接触命令行界面。Docker极大减轻了我们技术支持渠道的工作量，因为它更易上手。
我理解这种想法，确实有道理。
但…
作为资深管理员，我厌倦了翻阅Docker配置文件来揣测原生部署方案。这些文件永远无法清晰传达开发意图——只能靠碰运气地猜测。
这太像“代码即文档”的思维了。
我完全接受手动安装步骤深藏于技术文档的“地牢”中，远离普通用户。
但请别用Docker兼容性取代Posix兼容性。
看看Immich这个不幸的例子。他们有精美的高级架构文档，但Dockerfile背后的“原理”却无处可寻。这种做法只迎合Docker用户群体，却让Posix用户陷入大量猜测，反而阻碍了贡献参与。
拥有30年资历的资深系统管理员…UNIX系统管理员兼开发者…
过去12年我始终使用docker+compose进行开发项目。在多层应用开发中，其效率优势难以超越。
对我而言，Dockerfile恰到好处地融合了领域特定语言(DSL)特性与高度灵活性——任何命令都能作为RUN指令执行，生成任意所需的镜像层。这种设计堪称完美。或许“无限制执行”看似缺陷，但善用此特性将彻底改变游戏规则。
Dockerfile也是向那些无法像你我一样管理系统、安装软件的人分发开源软件的绝佳方式——毕竟他们最终难免会搞得一团糟或迷失方向(比如初级开发者？)。
是否存在供应链风险？当然——就像许多软件包系统一样。我总是从头构建重要镜像来规避风险。若追求更开源友好但不够精致的方案，Podman配合Podfiles也是选择。
综上所述，我通常会将生产环境工作负载容器化，但不用Docker。开发项目若已准备就绪，我会直接迁移到Kubernetes。以前常用BSD Jails。
> Dockerfile也是向那些无法像你我一样管理系统、安装软件的人群分发开源软件的绝佳方式——毕竟他们最终总会搞得一团糟或迷失方向(比如初级开发者？)。
请审视你刚说的：
> …向那些无法像你我一样管理系统的人群…
这类人本就不该接触系统运维。
> 我总从零构建重要镜像…
我对此存疑，但假设属实，那你实属罕见——我的客户连这都做不到，而他们要么是资金雄厚的政府机构，要么是拥有六万员工的跨国企业。
操作系统的精髓及其管理之道已然失传。取而代之的，是为追求便利而引入更多安全隐患及其他问题的替代方案。
愿你一切顺利，朋友。
> 这些人根本不该负责系统运维。
这段让我笑出声 🙂 我只是想更包容些！效果参差不齐。
我确实从零构建系统镜像，但也清楚自己属于特例(就像HN社区的许多人)。随着年岁渐长，我意识到若生在别时别地，我本会成为截然不同的人——但命运将我置于互联网时代。不抱怨，现状还算不错。
也祝你一切顺利，朋友！
但你说的完全不是这么回事。
你这里的意思是：新手只需用Docker就能让一切正常运转。支持成本大幅降低(对你而言，不是对用户)，所以万事大吉。
正是这种心态催生了如今疯狂的僵尸网络——每秒数千兆字节的攻击源于用户启动虚拟机，敲下“docker compose up”就走人，因为“它就是能用”。现实是系统很快过时，漏洞被发现又修复，但补丁永远不会触及这些用户。
让用户快速上手固然出色，但实际维护服务器的繁重工作量，对试图运行ESI工具的普通《EVE Online》玩家而言实在难以承受。
那么人们该如何学习？
我个人最擅长实践学习。若先研究再尝试，效果往往不如反向操作。尝试→失败→理解→学习
这并非非此即彼的选择。
Dockerfile的更新频率取决于维护者，这与任何开源项目无异。
我们共享服务器运维知识并非导致僵尸网络泛滥的原因。僵尸网络的出现主要源于经济或政治动机——这与人类诸多行为的动机如出一辙。
你关于“运行EVE Online服务器这类操作超出非专业人士能力”的观点没错，但这不应成为禁止信息共享的理由。
脚本小子早已存在多年。他们借用优秀工程师的成果，为其不那么崇高的目标服务。
生产环境无法真正教会你。我们讨论的是运行生产级工作负载，而非本地化实验室环境。无论是否使用Docker等“简化”软件部署的工具，你都能在本地环境中顺利学习。但涉及生产环境时，必须对自身操作及真实生产系统的需求有清晰认知。
可悲的是，当人们习惯用“docker compose up”在本地学习时，这便成了他们的基准线和现实认知，以为所有后续工作都已代劳。实际上你仍在运行绑定网络端口的进程(只是因使用容器增加了步骤)，而围绕它的整个生态系统仍需安全防护。
这正是当下被忽视的关键所在 🙁
能否解释“Docker Compose”为何是陷阱？
依我之见，它阻碍了标准化进程。
若在裸机环境运行，项目构建说明要求“需安装libfoo-dev、libbar-dev、libbaz-dev”时，这些依赖仍来自已知的供应链，其生命周期和流程都可追溯。当libbaz出现CVE漏洞时，你很可能通过获取内核和Apache更新的同一邮件列表收到补丁和通知。
反之，若引入现成的Docker容器，它可能在您偏好的Debian或FreeBSD系统上运行完整的Alpine或Ubuntu发行版。原本用于维护软件包更新和漏洞监控的流程，现在必须扩展至覆盖额外的发行版。
您最初的表述更精辟：标准化。
Posix才是标准。
Docker只是构建在该层之上的工具。这毫无问题！
但你需要向底层进行文档化说明：使用了哪些库，它们如何相互连接。
Posix为你提供了这个共同基础。
我绝不会要求人们不提供Docker文件。但如果一个项目只发布apt包而没有其他文档，感觉就和只提供Docker文件一样糟糕。
手动步骤必须记录。不是为普通用户，而是为移植到其他系统的人。
我不喜欢黑盒子。
我放弃在自托管项目中使用Docker的原因是文档缺失，以及那些包含各种shell脚本服务配置的极其复杂的Dockerfile。有时感觉像在读autoconf生成的文件。我更愿意学习操作系统的打包方法并自己构建。
类似Harbor的工具能轻松集成，既可作为拉取缓存，又能充当漏洞扫描器。你甚至能限制仅允许X类或CVSS评分特定等级的镜像拉取。
你理应扫描容器，正如你理应扫描平台其他攻击面一样。
你在这话题的三条评论里都把那条命令加了引号。我觉得它没你描述的那么普遍。
好奇它在新近支持的podman/oci容器环境下效果如何？
FreeBSD在发烧友圈子中热度上升，似乎只是因为Linux如今更主流了——人们享受标新立异带来的快感，而非这两大操作系统本身发生了实质性变化。
最近我对此产生了浓厚兴趣。自90年代末起我便是Linux爱好者，这次重燃兴趣并非出于标新立异。
随着年岁增长，我愈发珍视软件栈的可组合性。虽不确定[Free]BSD能否重拾此特性，但Linux似乎正变得愈发复杂且难以组合。此处使用“组合性”一词虽不严谨，但主要指系统运作逻辑的可理解性与可类推性。我渴望在这样的环境中工作：操作系统工具箱里的每件工具都配有简明直白的man手册，而非像瑞士军刀那样，开发者/维护者为吸引社区眼球而不断堆砌“它还能做这个”的功能。
虽不能代表整个社区，但过去几年我对FreeBSD的兴趣已然重燃。它长期以来都是非常稳健的操作系统，内核与核心用户空间的紧密集成使其性能有时甚至超越某些主流Linux发行版。不过其用户体验并非始终出色，而近期这方面似乎有了显著改善。特别是ZFS文件系统和基于ZFS的根目录设计尤为出色。
我其实很想在生产环境中部署它，但这似乎与普遍采用Docker的部署场景相冲突。虽然已有将runc引入FreeBSD的尝试，但目前充其量处于alpha阶段。
不过若你只需SSH服务器、文件服务器或邮件服务器，它仍是绝佳选择——默认配置合理，升级周期可预测。
Docker本可运行。据我所知API接口已存在，只是需要有人挺身解决核心问题。
Jails和BHYVE虚拟机固然优秀——但我日常依赖Docker，若能用BSD作为Docker宿主机自然更佳。
幸好我的Docker服务器都通过Terraform构建，无需手动干预。
我特别指的是这个方案尚未成熟：https://github.com/samuelkarp/runj
FreeBSD上可以使用Podman，但CNI提供商还需要些时间来适配FreeBSD网络栈那些超赞/疯狂的功能。
将FreeBSD社区视为唱反调者未免刻薄。近期人气攀升至少还有以下因素：
Linux的普及扩大了对类Unix操作系统感兴趣的用户群体。其中部分熟悉Unix的用户真正青睐FreeBSD及其独特特性。
Docker的崛起与VMWare的衰落，推动了对FreeBSD Jails和Bhyve虚拟化管理程序的关注度提升。
搭建家庭实验室已成为流行爱好。ZFS在RAID领域广受欢迎，pf则在网络领域备受推崇。
Podman引入FreeBSD平台：(https://freebsdfoundation.org/blog/oci-containers-on-freebsd…)。
戴尔、AMD、Framework及FreeBSD基金会去年投入75万美元，致力于提升FreeBSD易用性：(https://freebsdfoundation.org/blog/why-laptop-support-why-no…
苹果宣布今年将Swift语言引入FreeBSD平台。
对我而言，Linux的种种变更令人困扰。每次升级后，原本正常运行的功能总会被改动。另一个问题是众多发行版强推其“原创”特性，如Canonical和Red Hat的做法。更令人担忧的是企业对Linux的巨大影响力。
FreeBSD基本摆脱了这些困扰。它将所有控制权交还给操作者，而非由发行版强制推行(Arch除外，但我对那里的社区并不欣赏)
不同意。Linux正随着systemd、snap、flatpak等技术的推进逐步改变。如今的FreeBSD与十年前甚至二十年前的Linux相似度，远高于当今的Linux。
> 当今的FreeBSD与十年前甚至二十年前的Linux更为相似，远胜于当今的Linux。
我不确定这是否如你所想那般值得庆幸。十到二十年前的Linux相当糟糕，至少在桌面领域如此。
虽然人人都讨厌systemd，但坦白说我认为这些抱怨实在被夸大了。我从2012年左右就开始使用基于systemd的发行版，虽然期间遇到过许多Linux问题，但实在说不出 任何 问题是由systemd引发的。systemd易于使用，journalctl查看日志很方便，而我看到的多数抱怨归根结底都是“万一…怎么办”这类 而这些假设性问题至今尚未发生。
FreeBSD固然出色，但运行时我偶尔会怀念systemd，纯粹因为它实在太 简单 。我知道FreeBSD圈曾对launchd表现出兴趣，但不知实际推进到何种程度或是否获得支持，我真心希望它能实现。
若耗费大量时间排查诡异的DNS故障，最终发现竟是systemd-resolved所致，着实令人沮丧。
更不愿提及为修正systemd单元文件耗费的精力。活跃的社区不断建议添加新功能，结果却以意想不到的方式破坏用户版本。纯属浪费时间。
我尤其喜欢BSD，因为它没有systemd 🙂
> 这未必是你想象中的优势。十到二十年前的Linux相当糟糕，至少在桌面领域如此。
尽管存在可用性问题，十到二十年前的Linux对特定用户群体而言仍具备值得付出的优势。坦白说，如今的桌面Linux堪称最糟糕的折中方案——既没有Windows或OSX的易用性与兼容性，也缺乏BSD的控制力、一致性和可靠性。
我认为这种评价相当不公。如今的桌面Linux对普通用户已相当友好，毕竟本地与远程软件的界限早已消失。Windows强行推送广告，MacOS则迫使用户为硬件支付溢价——普通人如今的消费重点在手机而非笔记本或台式机了。
我刚尝试在Ubuntu桌面安装Zoom，可选方案似乎是：
– 在软件包管理器中搜索Zoom(无法找到)
– 在软件包管理器中搜索zoom-client(能找到，但开发者似乎是个个人而非Zoom公司)
– 前往Zoom官网下载.deb包并执行命令
对我来说这没问题，但别假装普通用户安装Zoom这种基础软件会轻松。
多数基于Ubuntu的发行版支持双击deb文件直接安装。这与Windows系统的操作体验并无本质差异。
访问官网[0]或许能看出区别。
[0] https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti…
该页面预设了安装.deb包的图形工具未预装，但实际Ubuntu和Mint系统均已预装。若已预装，操作步骤仅需“双击图标并点击安装”。
RPM发行版同样如此。因此唯一关键在于明确需下载的包名称。
理论上镜像可自动检测操作系统(甚至自动识别是否存在包管理器)，提供统一下载选项或直接启动包管理器进入对应界面，这将使Linux与MacOS/Windows实现功能对等，但当前版本尚不支持。
实际操作难度远高于上述系统，许多普通用户在使用这些系统时仍会遇到困难。
我的意思是，要么通过“应用商店”，要么直接从厂商下载，不是吗？
顺便说下，我刚用工作用的Mac打开Zoom，居然出现了两个按钮：“下载Apple Silicon版”和“下载Intel版”。普通用户看到这儿怕是要崩溃了吧？
有趣的是，一年前那个OpenSSH/XZ漏洞其实是systemd漏洞[1]。
回想在systemd世界里度过的时光，我一点都不怀念。系统始终令人感到晦涩难懂，因为理解systemd的知识山脉似乎永远无法翻越。我必须记住太多东西——驱动systemd协调的无数事务所需的各种控制开关…而实际效果却微乎其微。我更喜欢系统透明化，不需要那些毫无意义的抽象层。自从远离系统d发行版后，我的系统可靠性显著提升，这绝非巧合。当我拿到Steamdeck时，这是我数年来的首次系统d配置，最先注意到的是曾经的卡顿问题又卷土重来了。这或许与Poetteringware无关，但很可能是系统复杂化引发的次级或三级效应。
[1] – https://www.fortinet.com/resources/articles/xz-utils-vulnera…
任何规模足够大的操作系统代码库终将出现安全漏洞，因此发现此类案例并不会改变现状。我确信FreeBSD过去也存在过安全问题。
我并非什么超级天才，但系统d对我而言并不难用——我想要实现的大多数功能都能轻松搞定。虽然大家都抱怨它复杂，但像我这样的笨蛋都能搞清楚如何创建自己的服务和定时器，设置启动优先级顺序，搞定这些有趣的东西。我真心觉得人们在夸大它的难度。
我认为你误解了讨论的核心问题，因此产生困惑。真正的“难度”不在于系统各部分的复杂性，而在于如何在不深入专研的前提下，穿透整个系统的晦涩表象。仅就初始化系统而言，systemd采用的配置DSL本身就充满怪异特性，这使得它占用的思维空间远超传统初始化系统的合理范围。例如必须记忆完全不同的字符串展开行为，以及由此在shell脚本边界引发的各种边界情况。这只是systemd初始化模块中微小切片的一个小例子。关于resolved、udevd、logind等组件的问题，我们能讨论一整天。
这些问题本身并不“困难”，或许正因如此，你才认为人们在“夸大其词”且别有用心。我对此提出质疑，并认为你尚未认真审视过反对systemd的立场其实根植于现实基础。你可曾问过“为什么”，并试图给出一个能合理解释该立场的答案？若找不到这个根基，你就永远无法理解这种立场。
systemd 解决了旧式 SysV init 难以应对的问题。例如当需要按特定顺序加载资源时，systemd 能轻松实现，而 SysV 则需通过复杂的符号链接操作才能达到相同效果。类似情况比比皆是。你可以轻描淡写地认为这无关紧要，但确保服务按正确顺序加载并能指定服务依赖关系，绝对可能至关重要。
当然我也用过非systemd发行版，比如Ubuntu(当年它还用upstart)、Gentoo，还有FreeBSD(我知道它不算Linux发行版，但讨论这个点足够接近)。所以非systemd系统对我来说并不陌生，只是我不认为它真的比其他系统更头疼。
> 任何足够庞大的操作系统代码库终将出现安全漏洞
确实如此，但运行时间更长的系统，其漏洞往往已被更充分地挖掘出来。
桌面Linux的巅峰期其实在20-25年前的Debian时代。Ubuntu后来风光了几年，但此后便陷入长期缓慢的衰退。
顺便说一句，Devuan的优秀程度足以让我不转向BSD阵营。不过那些大型企业发行版的破坏者们，似乎正开始从应用程序中移除X11支持——尽管Wayland至今仍未达到功能对等。
值得庆幸的是，上次我在FreeBSD虚拟机中运行Steam时表现尚可——尽管虚拟机缺乏显卡加速。这正是让我坚守Linux的主要应用。
我认为这正是小型社区纯粹为乐趣打造系统的魅力所在，而非大型企业利益集团间的争论。
若你整天与计算机打交道，那么作为业余爱好的计算机设备保持一定差异性也是合情合理的。
相比Linux，FreeBSD也极其保守。不仅是systemd的问题，整体变化更少，更接近老派Unix。有人因怀旧而钟爱它，有人则厌倦了不断被抽走地毯的感觉(这似乎是人们年长后常见的心态)。
FreeBSD用户显然已从Linux用户手中接过了操作系统传教士的衣钵。
我曾尝试在两个不同项目(NAS和路由器)中使用FreeBSD，结果发现它都不适用——切换到Linux后问题都解决了。尽管我的问题已解决，但FreeBSD的忠实信徒似乎认为使用FreeBSD本身才是目标，而非解决当前任务。
我感觉你可能从未真正使用过它。是这样吗？
这篇帖子散发着强烈的“我与众不同”气息。
这种心态确实存在，但沉迷于实际竞争本身并非最糟的理由。若没有好奇心的驱使，又如何能发现品质差异的真相？
说得好！我曾同时管理FreeBSD和Linux(Debian)服务器。它们确实不同，但我无法断言孰优孰劣。
有些人骨子里就渴望与众不同。
当科技领域充斥着人气竞赛时，这种反制力量恰是必需的。
这无可厚非。但关键在于：我用Linux时同样与众不同。所以不太理解为何要刻意强调FreeBSD的独特性。
在BSD家族中，我认为唯有OpenBSD凭借其安全特性拥有真正独特的卖点。当人们问“为何选择FreeBSD而非Linux”时，多数人无法在安全领域找到支持FreeBSD的有力论据。
首先，相较于典型Linux发行版，FreeBSD拥有诸多优势：
精简且高度集成的基础系统，配以完善的文档体系。Jails、ZFS、pf、bhyve、Dtrace等组件间协同性极佳——这与Linux形成鲜明对比：后者虽有Docker、btrfs、iptables、bpftrace及多种虚拟化方案可选，但这些组件源自不同项目，协同性远不及FreeBSD。
当需要自定义选项构建软件时，端口库(ports tree)表现尤为出色。
对于资深类Unix用户而言，其系统架构简洁易懂。Linux发行版持续迭代更新，我实在无暇追赶。我拥有二十余年每日使用Linux的经验，以及约三年每日使用FreeBSD的经历。然而上次遇到发行版安装彻底崩溃(pop os)时，我却束手无策——只因那套复杂的系统底层架构(systemd、dbus、polkit、wayland与X等组件交织成鲁布·戈德堡装置)，掩盖了本应易用的图形界面(此时界面已失效)。启动时系统直接抛出根终端，伴随着令人费解的systemd错误信息。启动日志里充斥着各种从未听闻的守护进程的乱码报错，我彻底迷失了方向。在现代Linux发行版上，我的丰富经验几乎毫无用武之地，但在FreeBSD中依然能发挥价值。
其次，关于OpenBSD的安全性是否其核心卖点，我并不完全认同。对我而言，OpenBSD的核心价值在于它是款“开箱即用”的服务器/路由器操作系统——手册页文档极其完善，所有基础网络守护进程均预装完毕，只需启用即可。其配置文件极其简洁，往往只需寥寥数行代码，且每个配置文件都有专属手册页详尽说明。对于“只需HTTP服务器提供静态内容”、“只需带dhcpd和防火墙的路由器”等场景，OpenBSD堪称完美。
OpenBSD倡导的简洁配置文件与安全默认设置理念堪称其最杰出的特性。
开箱即用的ZFS对我而言是重大卖点。Jails功能简直妙不可言。rc系统逻辑清晰易懂。我曾有过仅在FreeBSD上稳定运行的系统，在Windows或各类Linux系统中却频频崩溃。
ZFS令人惊叹，尽管存在众多仿制品，但真正的ZFS唯有此一。
我曾在所有可能的场景中使用(并推广)它，最初是在Solaris上接触到它，后来才用上FreeBSD。甚至在近18年前就把它装在Mac工作站上(虽未获官方支持)——顺带一提，我永远不会原谅那个混蛋Larry Ellison杀死OpenSolaris的行为。永远不会。
Systemd是史上最糟糕的垃圾。RC机制既高效又优雅。Systemd足以成为回避Linux的理由，但我仍不得不捏着鼻子使用它。
抱歉，能否具体说明Systemd的糟糕之处？我真心想知道它为何是“史上最烂的垃圾”。
我无法代表他人发言，但个人认为其文档编写糟糕，且极少能超越被取代的系统，更让数十年来那些 在互联网上 轻松可得的优质文档变得毫无价值。或许某天这种转型会有所回报——比如推出可媲美macOS的系统配置图形界面，但迄今为止尚未见其踪影。
尤其当对比BSD系统对初始化与配置系统那般精美且一致的文档规范时，这种差距尤为明显。再看Mac OS——其launchd系统至今仍更易于使用，真正实现了“设置后无需干预”的理念，避免了为网络接口、日志记录等无关功能添加复杂接口。不过这种优势向来如此。
其设计本身就存在不必要的复杂性。更糟的是，维护者历来对批评意见反应冷淡，甚至强行推动采用。例如Gnome如今对systemd产生了强依赖，导致在非systemd系统上部署Gnome极其困难——除非你愿意投入大量补丁。仅这种硬性绑定就足以让我永远拒绝依赖它。
完全同意。更何况它解决了什么问题？这些问题难道不能用RC脚本解决吗？后者可读性更高且结构更简单。增加这些复杂性究竟有何益处？更关键的是，在专业环境中它有什么商业价值？这个问题我纠结很久了。
作为想了解BSD系统的Linux用户冒昧插话，还请多包涵。
我钟爱systemd的一点是它能提供运行进程的实用统计数据，比如运行时长、累计磁盘/网络I/O、当前及峰值内存占用等。
进程管理功能(如重启规则和依赖链)也相当出色。
这些功能在RC(或其他BSD专属工具)中也能实现吗？
是否需要在初始化脚本中检查是否需先启动其他服务，这取决于你的需求。
至于运行时间、I/O等指标，这些数据本就可获取——无论是通过SNMP还是其他方式。比如在系统中启动nginx时，它会报告哪些网络和磁盘使用情况？仅主进程还是所有子进程？RC同样存在此问题。
但这恰恰是关键所在。初始化系统凭什么要提供磁盘使用率这类统计？这根本不是它的职责范畴。
若需内存占用、I/O使用率或运行时长等数据，系统已集成大量专用工具，初始化系统无需分心处理。
初始化系统只该关注启动、停止和重启服务。仅此而已。一旦超出这个范畴，就意味着背离了核心使命。
这番话可能比我本意更激烈，但观点依然成立。
BSD系统秉持“保持简单，保持单一功能”的理念，达到“我能接受这个程度”的境界。其成果是卓越的文档体系和高度易懂的组件设计。典范当属OpenBSD/FreeBSD的PF防火墙。其配置文件极易理解，文档清晰易读，且能满足防火墙99.999%的功能需求。
> 它报告的是哪个网络和磁盘使用情况？仅主进程还是所有子进程？RC中存在相同问题。
嗯，主进程及其完整层级结构——这不正是初始化系统监控服务应有的表现吗？而systemd的妙处在于，我只需简单执行
systemctl status my-service就能获取这些信息——当然我也可以部署完整的可观测性堆栈，但能避免的话当然更好。但没必要过度防御，RC能做到固然好，做不到也无妨。
> 系统已集成众多工具，初始化系统无需多费心思。
这正是我想了解的——BSD世界中有哪些等效方案？
最佳实践是将服务封装到监狱环境中，再用
ractl监控I/O。也可通过监狱环境的VNET套接字获取网络统计数据。或者直接获取进程ID进行监控。虽然更手动些，但具备组合性。
启动一台虚拟机(本地或云端均可)，安装OpenBSD或FreeBSD。若需邮件服务器、静态HTTP等功能，OpenBSD或许更合你心意。亦可尝试FreeBSD的监狱系统，其性能绝对出色。
抛弃大型语言模型(并非暗示你使用它们，但以防万一)，尝试使用手册和man页。
若你感觉服务间相互依赖过于复杂，需要超越RC的解决方案——坦白说，这可能意味着你的架构本身存在问题。
>若你发现服务间依赖关系过于复杂，以致需要超越RC管理机制的解决方案，坦白说这可能意味着架构本身存在根本性缺陷。
一针见血。
它能自动发现依赖链之类的东西吗？如果你有500多个需要协调的服务，那你面临的根本是完全不同的问题。
我超爱RC脚本的简洁性。易懂、易调试，就是他妈管用。
简单至上，因为它让人心领神会。像systemd这样的庞然大物，感觉需要博士学位才能搞懂。
systemd完全违背了Unix/Linux关于可组合性和单一功能的设计哲学。
在哪个离谱的世界里，RC脚本比systemd服务文件更容易理解？RC脚本根本谈不上简单。
若需确保网络堆栈在USB堆栈之后启动，USB堆栈又在PCIe堆栈之后启动，PCIe堆栈再在…之后启动——此时systemd比SysV init简单得多。
你轻描淡写地忽略了关键问题。尽管拥有500个服务本身就是问题，但这已是现实，即便在桌面操作系统中亦然。
数数看有多少服务不是系统本身按顺序定义的？所以去掉核心系统服务。系统本身就该确保USB在PCIe之后启动等等。
去数数所有非基础安装的服务有多少个，告诉我具体数量。
重点在于——Systemd完全违背了Unix/Linux关于可组合性与单一功能的核心哲学。
补充说明：这本质是“非我发明”症候群，总会催生针对虚构问题的复杂解决方案。
Linux“仅”是内核，各发行版总在所谓核心问题上另辟蹊径；而BSD拥有源自单一项目的完整基础系统，大幅降低了类似systemd的出现概率。两种方案各有优劣。
因为“单一程序承担过多职责违背Unix哲学”
实际上systemd由69个独立二进制程序构成(仅其中一个运行于pid 1)，它们在同一项目下开发，设计上相互协同。
既然有69个独立二进制程序，实在难以称其为“一个程序承担太多任务”。它们虽同属一个项目，但FreeBSD本身也是如此。
它们虽设计为协同工作，但据我所知，替换单个二进制文件并无技术障碍——尽管我从未实际操作过。
没错——正因“单一程序承担过多职责，违背Unix哲学”
系统d的隐私问题——DNS回退到Cloudflare——是值得关注的。我对Cloudflare并无恶意，尽管其商业模式涉及隐私问题，我依然欣赏他们。
但你应该知道存在不使用systemd的发行版吧？
是的。这些年来我几乎用遍了所有Linux发行版，从Slackware、RH到Nix+Arch，还曾在Solaris、IRIX、SCO、OS/400甚至Tandem系统上编程——查查吧，这系统相当冷门！不过现在主要用FreeBSD。
在FreeBSD上我几乎能完成任何Linux系统能做到的事。我对游戏兴趣不大，这或许也是原因之一。
Debian和Ubuntu开箱即支持。DKMS可用于其他发行版。核心ZFS代码与BSD相同。希望这些信息能帮助你了解情况。
我尝试过多数系统，但主要使用NixOS。至今未遇过比FreeBSD安装程序更流畅的ZFS部署体验。查阅Debian维基仍显示需依赖DKMS并手动分区。
咦？ZFS采用双缓存机制，除重建文件系统外并无整合扩展区的方法。
我曾用单条命令将FreeBSD系统从8版升级到12版。不记得是否重启过——可能需要重启。
你能帮我在Linux上试试吗？能否创建Ubuntu 14虚拟机，完整升级到24.04版且不出问题？告诉我结果。
我曾需要用户空间工具的帮助，手册直接解答了问题。更令人惊叹的是我与某位内核开发者的对话——他同时维护着用户空间工具，并非出于个人选择，而是架构决定了整个系统必须作为整体维护。
Linux能做到同样的事吗？你根本做不到。只有Arch和RedHat(若能突破付费墙)的文档能勉强接近FreeBSD手册的水准。
FreeBSD的优势显而易见：它只需静置运行，永不罢工。Linux同样能做到，前提是你愿意维护。而FreeBSD系统除了更新软件包外，几乎无需任何维护。
频繁使用容器的用户可能难以在FreeBSD中找到归属感，这无可厚非。我更希望容器技术永远别进BSD家族——多数公共镜像既臃肿又存在严重安全隐患。
但话说回来，大多数使用FreeBSD的人都知道，在同一操作系统上运行多个软件堆栈根本不需要容器——无论是否需要多个运行时环境或库版本。这种能力已成失传之技，因为如今只需敲一句“docker compose up”就能走人，所有事都有人替你搞定……对吧？各位？现在一切都很安全了吧？
> 我曾用单条命令将FreeBSD系统从8版升级到12版。
你很可能用的是freebsd-update[0]命令。虽然存在其他升级途径，但这是文档完善且普遍采用的方法。
> 不记得需要重启——可能确实需要。
跨主版本更新确实需要重启。这很正常，只是澄清一下。
> 频繁使用容器的人可能不会选择FreeBSD，这很正常。我希望BSD家族永远不要引入容器技术。
严格来说，FreeBSD并不需要Linux容器，因为jail提供了类似功能(个人认为更优，不过我对FreeBSD有 极强 的偏好) 。顺带一提，我首选的jail管理工具是ezjail[1]。
> 不过话说回来，多数FreeBSD用户都明白：在同一操作系统上运行多个软件堆栈时，无论是否需要不同运行时环境或库版本，根本无需依赖容器技术。
我完全赞同！
0 – https://docs.freebsd.org/en/books/handbook/cutting-edge/
1 – https://erdgeist.org/arts/software/ezjail/
感谢分享并澄清这些细节 🙂
没错，jails 确实更优，但现实就是如此。
我没试过，但听说 podman 能在 FreeBSD 上运行 😀
我觉得确实如此。
至少它有个像样的入门手册。
Linux根本算不上主流
要说主流系统，BSD才配得上这个称号——毕竟OS X就是BSD。
OS X是XNU架构。BSD代码存在于内核中，BSD工具链存在于用户空间，但内核在许可证和架构上都不属于BSD。
Linux在消费设备(Android)和服务器领域拥有压倒性的用户基数。
尽管我热爱FreeBSD，但其发布周期在生产环境中实属挑战：每次点发布版本仅支持约三个月。由于每次发布都包含所有端口和软件包，最终导致主应用程序需持续重新认证。
反观红帽：付费订阅虽昂贵，但其将安全修复回溯至原始代码，确保开源包更新不破坏应用程序，关键CVE漏洞仍能得到修复。
微软尽管存在诸多缺陷，却通过近乎荒谬的向后兼容性提供了惊人的稳定性。
FreeBSD是否卓越、稳定且是I/O工作马？绝对是——问问Netflix就知道了。但它是否适合通用型、应用导向(而非基础设施导向)的大规模部署？嗯，恐怕不是？
每次点版本发布仅支持约三个月
三个月的说法从何而来？通常是九个月，偶尔甚至长达十二个月。
此外，主版本支持周期长达四年，除非你修改内核API否则不会出现兼容性问题。(测试永远有益！但从14.3升级到14.4无需额外投入大量开发工作。)
我更正一下，官方当前发布计划是“…每个点版本仅在后续点版本发布后支持三个月”。
https://www.freebsd.org/security/#:~:text=on%20production%20…
近期小版本发布：
14.3 (2025年6月10日)
14.2 (2024年12月3日)
14.1 (2024年6月4日)
14.0 (2023年11月20日)
13.4 (2024年9月17日)
>> 此外，主版本支持周期为4年，除非您修改内核API，否则系统不应出现故障。
系统或许不会崩溃，但可能暴露于已公开的漏洞中，例如：
https://bsdsec.net/articles/freebsd-security-advisory-freebs…
要及时获取软件包/端口的漏洞修复(这类更新频率更高)，“简便”方案是使用最新的FreeBSD点版本。
没错，具体操作是运行
freebsd-update fetch后执行freebsd-update install；若需升级小版本则执行freebsd-update upgrade -r MAJOR.MINOR并重复上述步骤。小版本升级不会破坏现有环境，ABI等接口将保持不变。此类升级通常不会导致兼容性问题，但新版本可能引入功能变更。若存在特定场景需检查shell命令版本输出，则版本变更可能引发兼容性故障。我认为这是源于其他系统的重大误解。次要系统更新在许多其他系统中属于会静默推送的类型，而FreeBSD的主要版本发布更类似于OpenBSD的发布模式(其中次要版本号与主要版本号并无实质区别)。
在FreeBSD中，“次要”意味着更新不应破坏现有功能。它更接近“补丁级别”的概念。我总想拿Windows作对比，但想到Windows更新(包括服务包等)长期以来频繁破坏系统兼容性的历史就打消了念头。
或许换个角度解释更合理：FreeBSD因兼容性考量而拒绝更改各类默认配置——即使跨版本迭代时亦如此——因此饱受诟病。这些默认配置只需修改配置文件即可实现。虽然他们正在改进这方面，但确实非常重视兼容性，因为FreeBSD的使用场景就要求如此。
这与OpenBSD形成鲜明对比——不少用户运行-current分支，只因其足够稳定且能使用最新功能。他们仅支持最新正式版(即发布版+6个月)，但即便如此，通常也只需重新编译就能解决问题。所有系统都有自己的端口/软件包库，都希望软件能正常运行。而OpenBSD更倾向于“吃自己的狗粮”模式，这从其活跃的游戏社区可见一斑——尽管该系统“甚至”不支持Wine。
> 尽管我热爱FreeBSD，但其发布周期在生产环境中实属挑战：每个点发布版本仅支持约三个月。由于每次发布都包含所有端口和软件包，最终导致核心应用程序需持续重新认证。
你计划获得多少支持？旧版本并不会立刻变成南瓜。确实，每隔两三个大版本会发布小版本更新，其中libc库的变更会导致X.2的二进制包无法在X.1或X.0上运行。但只要遵循以下方案，这对服务器通常影响不大：
将FreeBSD作为稳定基础系统，但为主要服务/语言运行时自行构建二进制文件。若采用一次性构建并分发二进制文件的模式，请将构建机/构建根目录保持在机队中最旧的小版本号。安装新系统时，选用受支持的操作系统版本，并安装任何FreeBSD构建的二进制软件包。
你确实需要做好准备：审查更新内容以确认是否需要采取行动(若谨慎控制启用项，多数更新无需干预)，回溯修复程序，自行构建软件包，或在必要时紧急升级——但实际操作中很少需要这样做。
我认为这种策略不适用于桌面部署，因为变量太多。但对服务器非常有效。我工作中使用的多数FreeBSD服务器安装后从未升级操作系统，直到被更优硬件替换。我确实制定了升级流程，也偶尔使用：某些内核漏洞需要修复，有时新内核性能显著提升，此时固守旧系统实属不明智。此外我们安装的软件包也存在若干缺陷；通常这些问题同样无需升级操作系统，但有时升级少量旧服务器比全面修复更省事——懂得取舍很重要。
或者效仿Netflix的做法，尽可能运行接近-CURRENT的版本。
>> 或者效仿Netflix的做法，尽可能运行接近-CURRENT的版本。
关键在于，任何面向公众(互联网)的系统都必须及时更新CVE公布的已知漏洞。否则将成为安全攻击的首要目标。
FreeBSD维护者确实会修改系统以修复最新漏洞…但你必须接受每三个月发布新版本的节奏。
此外，这些版本不仅包含FreeBSD本身的变更，还包含发行版中所有第三方开源软件包的更新。每个软件包由不同个人或团队维护，其变更往往会改变软件运行方式，通常属于“破坏性变更”——即您需要更新应用程序代码才能保持兼容性。
> 此外，这些版本不仅包含 FreeBSD 的变更，还包含发行版中所有第三方开源软件包的更新
并非如此。仅重大版本更新(约每两年一次)包含此类变更。旧版本将持续获得支持直至下个重大版本发布。系统始终同时支持两个重大版本，因此总计约有四年过渡期。
关键在于，任何具有面向公众(互联网)部分的系统都必须及时了解CVE中公布的已知漏洞。若不这样做，系统将成为安全漏洞攻击的首要目标。
当然需要知晓这些漏洞，但对于类似[1]的情况，若未使用SO_REUSEPORT_LB功能，则无需采取进一步措施。
该缺陷可能存在于其他已停止支持的FreeBSD版本中，但只要不使用SO_REUSEPORT_LB功能，就无需更新。
若已启用该功能，对于未受支持的版本，可回溯应用修复程序或升级至受支持版本。也可通过临时禁用该功能来缓解风险，具体取决于禁用对您使用场景的影响程度。正如我所说，必须为此做好准备。
您也可进行部分更新：例如仅升级内核而不触及用户空间；或同时更新内核与用户空间，但不更新任何软件包/端口。
部分安全公告涉及基础用户空间或端口/软件包…我们可以分析其中一个案例，探讨针对此类情况的决策标准。
[1] https://www.freebsd.org/security/advisories/FreeBSD-SA-25:09…
您测量的仅是同一主版本内次版本间的重叠。若需微软类比，可将其视为服务包：每个次版本的支持周期持续至该主版本线出现新次版本并取代其三个月，或整个主版本线达到生命周期终止。
没错，但关键在于每次次要版本更新都会将所有第三方开源软件包/端口升级至最新版本，这必然包含破坏性变更。开源软件包常包含破坏性变更，几乎必然导致应用程序故障。而红帽Linux(付费版)会修改原始开源软件包来修复CVE漏洞。
> 通过将所有第三方开源软件包/端口更新至最新版本。
并非如此！
用户完全可以继续使用旧版软件包。系统并不强制要求升级第三方版本号。如其他讨论所述，我曾独立于操作系统升级Postgres版本。
实际更新的是操作系统中的用户空间，而非端口本身。根据最新FreeBSD 14.3版本的发布说明[1]，第三方应用程序中OpenSSL、XZ、file命令、googletest、OpenSSH、less、expat、tzdata、zfs和spleen均已更新。ps命令获得升级，并新增了用于筛选jail环境的sysctl标志。
此类更新属于点版本更新范畴，不会破坏现有系统。重大更新则纳入主版本发布，这也正是支持策略设定为“最新正式版+X个月且至少维持该时长”的原因。
[1] 稍往下滚动：https://www.freebsd.org/releases/14.3R/relnotes/
那为何不用jails？
> 尽管我热爱FreeBSD，但其发布周期在生产环境中实属挑战：每次点版本更新仅支持约三个月。
我认为点版本更新“不值一提”。点版本更新只需运行freebsd-update，重启系统即可完成。
而主版本更新通常也相当简单：运行freebsd-update，遵循提示操作，执行
pkg update -u即可。十多年来，我一直用这种方式维护着服务数十万用户的数据库集群(Postgres)，在其他场景中更是驾轻就熟。
当然需要规划和测试，但生产环境的数据库更需要如此。;)
这套系统每秒处理数千次查询，其中包含少量耗时较长的查询(使用PostGIS的GIS操作)。
需要说明的是：FreeBSD的向后兼容性常被误解。例如FreeBSD内核默认包含COMPAT_$MAJORVERSION模块以确保兼容性，因此关键场景通常不会出问题。
但请记住，您通常拥有极长的版本迁移窗口——从新主版本发布到旧次版本停止支持之间存在相当长的时间差。
回到Postgres配置问题。我无需同时升级数据库(+PostGIS)，因为我的构建服务器会为两个版本精确构建相同版本。不必担心那种“同时升级内核、操作系统、编译器等所有组件”的混乱局面。我实际经历过从FreeBSD 13迁移到14，同时将Postgres从14升级到18——再次强调，这包含PostGIS，在多数系统上会导致升级过程极其复杂——但整个过程毫无问题。仅通过pg_upgrade命令，并将旧版本软件包存放在临时目录中就完成了。
这只是个小插曲，但确实是真实生产环境中的部署案例，涉及众多付费客户。
我也接触过红帽系统，但红帽的长期支持最终总会变成“但愿升级时我已不在此任职”的境地。
不过请注意，我们讨论的是以年计的周期——在FreeBSD上这类问题往往微不足道，而红帽虽能长期支持旧版本，却意味着大量动态组件，因为运行的应用程序与发行版版本的绑定程度更高。
在FreeBSD上，即使使用旧版主分支，你完全可以运行最新版Postgres、nginx、Python、Node.js等软件。
例如刚发布的FreeBSD 15作为主分支版本，支持周期将持续至2029年底——你还想要更长的LTS支持吗？
次要版本的维护周期接近一年。这仅指基础系统层面。借助poudriere等工具，您还能轻松维护软件包和端口库。
关于向后兼容性：FreeBSD拥有稳定的向后兼容ABI。正因如此，您能在15.0主机上无缝运行11.0监狱环境。
反向操作则不可行。例如无法在11.0主机上运行15.0的jail。但向后兼容性绝对是存在的。
[1]: https://www.freebsd.org/releases/15.0R/schedule/
作为曾管理大量红帽服务器多年的Linux系统管理员，我必须指出“不破坏应用程序”的承诺纯属胡扯。他们的补丁多次导致应用程序崩溃，迫使我们暂停使用数月直至修复。
据我所知，唯一真正兑现该承诺的Linux发行版是Alpine。
将FreeBSD与付费版RedHat相提并论实属不公。绝大多数Linux部署并未采用付费版RedHat，自然也无法享受其极致的安全补丁回溯支持。
但这种选择确实存在，而FreeBSD则不具备。
顺便说一句，我25年前就从Debian切换到FreeBSD作为主操作系统。
> 但这种选择确实存在
是也不是。若你部署的服务器运行在某个Linux发行版的x.y版本上，且无法或不愿升级，那么绝大多数情况下你会陷入与FreeBSD同样的困境。若想享受红帽付费回溯支持，必须在部署首日就选择LTS版本的红帽系统——而绝大多数人并未如此选择。
> 微软尽管存在诸多缺陷，却通过近乎荒谬的向后兼容性提供了惊人的稳定性。
需要佐证。很久以前或许如此，但现在已非如此。
“若有人追求炒作或每月更新的炫酷新玩意，Linux正合其意。”
这种观点实在荒谬……他们究竟以为Linux是什么？或许对那些追逐最新炫酷窗口管理器的Arch爱好者而言是如此。但我们这些在生产环境运行Linux的人，使用的都是稳定版本——这些技术经过十余年验证，某些组件甚至更久未曾重大变更。
FreeBSD用户需要认清现实。他们对Linux的本质如此脱节，实在难以认真看待这类文章。
> 但我们这些在生产环境中运行Linux的人，始终依赖稳定版本和十余年未曾大幅变更的成熟技术。
我敢肯定防火墙命令在这期间至少更新过一次，设备层和初始化系统也可能变更过。听说近年首选音频系统也在再度更迭。
这副粉红眼镜戴得可真够厚。我在现代计算机/配置上尝试运行BSD系统时，只尝到苦涩滋味。
所谓“不同”有两种：一种是“另类/前卫”，另一种则是“拒绝实现/YAGNI”——后者纯属主观臆断。
我在虚拟机里用得挺好。桌面端用了一年也没问题。笔记本上也运行正常。
你可能碰上了超出支持范围的硬件兼容问题。这种情况时有发生。
>笔记本上运行正常。
是哪款笔记本？
是否使用了电池、触控板和无线网络？
我发现多数声称在笔记本上使用BSD的用户，实际上只是将ThinkPad这类笔记本形态的机器插上电源，99.9%时间都用有线鼠标而非触控板，并通过有线网络连接。这本身无可厚非，但与我理解的“真正使用笔记本”相去甚远。
我在笔记本上使用包括OpenBSD和FreeBSD在内的发行版时，体验始终糟糕。尤其OpenBSD在相同硬件上运行速度远逊于Linux，更别提其糟糕的触控板驱动和电池管理了。
目前我在多台笔记本上使用OpenBSD系统，包括戴尔X55、ThinkPad X230和ThinkPad X270。所有功能均正常运行——休眠、睡眠、WiFi、触控板、音量与亮度按键、CPU降频等。
其中一台使用创新BT-W2蓝牙适配器输出音频。由于安全考量，OpenBSD移除了软件层面的蓝牙支持。这些机型虽不支持最新WiFi标准，但对我影响甚微——网络价值不在规模，而在于如何运用！我并不在意缺少炫酷的新硬件，毕竟那些体验我都经历过了。
选购硬件时我必须审慎考量，但乐在其中，因为OpenBSD与我的核心诉求高度契合：简约性、安全性、完善文档，尤其是经得起时间考验的稳定性——我绝不愿每两年就因音频驱动、systemd、Wayland、二进制代码等组件的随意变更，被迫重构工作配置。
目前在戴尔Latitude 7490上运行OpenBSD，一切正常。
我钟爱BSD系操作系统的原因在于其易于理解。你尝试过排查ALSA故障吗？或者使用libvirt？Linux虽功能丰富，但多数特性对普通用户并无实际价值。它更像B2B SaaS服务——充斥着诸多令人费解的设计：这些细枝末节究竟为何存在？它们最初又为何被纳入系统？
不知为何，我在某台特定笔记本(Thinkpad E585，已将原装WiFi替换为英特尔网卡)上部署OpenBSD时轻松得多。许多Linux发行版会陷入怪异状态——忘记SSD位置，WiFi固件又陷入鸡生蛋蛋生鸡的困境。
至少OpenBSD能正常启动到足够深的阶段，让我能按需加载WiFi固件。我可能选错了Linux发行版，因为在该机器的替代机型(L13)上，我用Debian和Devuan都运行得不错。
这大概是因为OpenBSD开发者本身就使用笔记本电脑，所以他们经常将操作系统移植到笔记本上。
FreeBSD虽有少量笔记本开发者，但多数专注服务器领域。当前正推进一项重启笔记本支持的计划：https://github.com/FreeBSDFoundation/proj-laptop
联想T480s运行FreeBSD效果极佳。
另有一位评论者指出：“联想T480s运行FreeBSD效果极佳。”
确实是联想T480s 🙂
从未遇到过问题，不过我只在Supermicro主板上运行过它
从10版起，我个人笔记本基本都装这个系统。体验很像90年代末的Linux。具体效果取决于硬件配置和使用需求，但系统本身相当稳定。
若你曾驾驭过90年代末的Linux，这系统对你来说不成问题。
所以你是说KDE、Gnome、xfce、enlightenment、openBox等桌面环境都像90年代那样运行？这些现行版本以及更多版本都能在FreeBSD上运行。
不，我主要指的是硬件支持、包管理以及系统d之前初始化系统的使用体验。
但具体使用哪个桌面环境完全取决于你。我现在用FreeBSD搭配fvwm写这段话，笔记本上则用dwm。
另外：
> enlightenment
虽然没关注近期动态，但这绝对是史上最“九零年代”的窗口管理器。
当时太早没能想起所有桌面环境名称，于是我谷歌搜索“热门Linux桌面环境”，它给出了这个结果。看来Linux运行着“最90年代的窗口管理器”。
我个人一直渴望出现NixOS风格的BSD或Illumos衍生系统。目前主机运行NixOS，根目录基于ZFS，但更希望运行原生支持ZFS的系统——能使用dtrace、内核具备一流操作系统虚拟化能力等等。声明式包管理显然是未来趋势，可惜至今没有非Linux选项。
若真有此系统我定会采用——illumos的区域机制颇具吸引力，对ZFS的原生支持同样令人心动。
NixOS处理ZFS的方式显得过度设计，而在FreeBSD上甚至无需fstab配置。
BSD系统教会了我真正的Unix之道，这是Linux始终未能做到的。那是在RedHat 5.x早期，我深陷RPM包管理的痛点，更被不同软件包混乱的文件层次结构折磨。当尝试为办公室网络配置防火墙时，iptables(还是当时的ipchains？)的文档混乱让我苦不堪言。
我尝试用OpenBSD搭建防火墙系统后便深深着迷。一切都显得更合理、更协调。PF规则的语法操作起来轻松灵活得多。我钟爱其端口系统，以及对代码正确性和安全的重视。手册页简直是启示！我能在命令行中找到所有所需信息。
我尝试过所有BSD系统，它们各有优劣。FreeBSD拥有最丰富的端口库和出色的硬件支持，NetBSD兼容平台最广泛，DragonflyBSD专注于并行计算等等。它们彼此借鉴、相互学习。
BSD系统非常出色，我衷心推荐大家尝试。这篇《The Register》的文章也值得一读：
https://www.theregister.com/2024/10/08/switching_from_linux_…
并非“反对”FreeBSD，但我始终无法将其真正作为桌面操作系统使用。
别误会：ports系统相当出色，jails技术也很酷炫，但每次尝试在笔记本上运行FreeBSD时，我总要耗费整日解决驱动问题，或是调试亮度/音量控制等基础功能。简而言之，笔记本上的FreeBSD(至少我两年前最后一次尝试时)就像十五年前的Linux笔记本体验。如今的Linux笔记本至少在AMD平台上基本开箱即用。虽然我在当前笔记本上顺利运行了NixOS，但不确定FreeBSD能否达到同样效果。
不过服务器端的FreeBSD确实相当出色。极其稳定，端口管理功能更是出色。我曾在服务器上运行FreeBSD约一年时间。
考虑到Linux在企业用户和个人用户中的广泛关注度，FreeBSD终究是小众桌面系统。我们不能指望它完美兼容所有设备。最直接的改变方式，就是你我开始贡献力量，或许就能推动系统优化。
我对此不持异议，但不明白这为何影响最终用户体验。
上次接触大型机时，他们每六个月都会严格执行全系统重启。几年前某次紧急情况中备用电源故障，之后数月他们都在努力梳理系统运行状态及启动流程。通过定期重启，操作人员启动进程时会记得将其纳入启动序列——至少仅隔数月，他们仍能记得操作流程。
如今我将其用作家庭文件服务器，因FreeBSD最契合我的需求。
但回溯到2000年代初，我曾获得一个免费Unix shell账户，包含Apache托管和Perl支持。若记忆无误，该服务器运行在FreeBSD系统上，由英国某ISP托管，使用portland.co.uk和port5.com域名。
这段经历塑造了我：我是在那台服务器上掌握了Unix系统、Perl语言和基础CGI网页开发技能的。虽不知具体运营者是谁，也不确定他们是否与当前域名持有者有关联，但若您正在阅读此文——衷心感谢！对当时无力承担付费主机的高中生而言，能接触FreeBSD实属莫大助力。
“千日不间断运行不该成为传说”
我经常重启服务器。主要是想确保系统因任何原因重启后，所有功能都能恢复正常。我运营的网站负载极轻，重启造成的短暂(约一分钟)服务中断，恐怕没人会察觉。
对此我毫无愧疚。
人们对超长运行时间存在某种怪异的迷恋。我怀疑这种现象源于Windows系统在运行50天后就会彻底崩溃的糟糕年代。
在现代环境中，低负载(或至少稳定运行)的系统持续数百甚至数千天不崩溃也不需重启，本应是理所当然的基准预期——但这意味着你无需安全更新，即系统必须与互联网隔绝。
另一方面，每次软件更新都会使系统处于微妙的特殊状态，其运行状态可能与全新重启后存在细微差异——除非重启整个用户空间(但此时还不如直接重启)。
当然，FreeBSD尚未实现内核实时补丁——但这本就不是“长运行时间”的解决方案，实时补丁的意义在于让系统安全运行至下次维护窗口。
> 除非你重启整个用户空间(此时还不如直接重启)。
我无法代表FreeBSD发言，但在我的OpenBSD系统上，它托管着ssh、smtp、http、dns和聊天(prosody)服务，重启用户空间根本不是什么难事。这并非因为重启特定服务比Linux服务器更简单(
rcctl restart foovssystemctl restart foo)，而是因为后台进程数量极少且功能清晰可辨；系统结构更简洁透明，自然减少了对服务中断或遗漏的担忧。更何况init(1)本身极少受补丁影响，其余(rc)组件皆为非驻留式shell脚本；而面对systemd庞大的服务体系及其复杂的库依赖关系，谁又能保证重启时不会牵连其他服务？若你管理的是宠物级服务器而非牛群级系统，尽可能避免重启是明智之举。比如电容即将报废时，你宁愿在未来某个不恰当的时刻处理，也不愿延长当前这个不恰当的时刻。
> 人们对长时间运行存在某种怪异的迷恋。我怀疑这种观念源于Windows系统在连续运行50天后就会彻底崩溃的糟糕年代。
据我记忆，当时崩溃频率远高于此。所谓50天仅是系统保证崩溃的时间点(因计数器溢出所致)。
> 在现代环境中，轻负载(或至少稳定运行)的系统持续数百甚至数千天不崩溃或无需重启，本应是理所当然的基准预期——但这意味着系统无需安全更新，即必须与互联网隔离。
或者说，需要安全更新的系统组件必须与互联网隔离。除TCP/IP协议栈外，内核大部分组件无法从系统外部直接访问。
> 另一方面，每次软件更新都会使系统处于微妙异常的状态，这种状态可能与全新重启后的状态存在细微差异——除非重启整个用户空间(此时倒不如直接重启)。
其实无需软件更新。系统正常使用就足以使其逐渐偏离“干净”的启动状态。例如开机时清空/tmp目录，任何临时文件都已与全新重启后的状态存在细微差异。
个人认为，因安全修复甚至稳定性修复而强制重启就是失败。这意味着系统虽未实际崩溃或遭入侵，却始终处于可能崩溃或遭入侵的脆弱状态。我们理应追求更优解。
> 我记得实际崩溃频率远高于此。所谓50天仅是系统保证崩溃的时间(因计数器溢出所致)。
我曾遗忘此问题(Windows 9x从未能稳定运行数日)，显然是32位毫秒计数器在49.7天后会溢出：
https://www.cnet.com/culture/windows-may-crash-after-49-7-da…
大型组织中有大量必须在本地运行的运营技术(OT)和安全基础设施(SS)，这些系统需要达到99.99%甚至99.999%的可用性。支撑这些OT和SS解决方案的基础网络、存储及计算基础设施，大多运行基于BSD操作系统的专有系统。选择BSD系统正是看重其性能、安全性和稳定性，这类解决方案常能连续运行数年无需重启。若需通过补丁修复缺陷或漏洞，通常无需重启内核。即便需要重启，这些解决方案也通常具备高可用性/集群能力，可实现无中断升级(NDU)，确保IT基础设施零停机。
这属于过去的时代。那时若不手动点击文件->保存(或强迫症患者按Ctrl+S)，数小时工作成果便会付诸东流。重启意味着所有未保存至磁盘的工作和配置彻底丢失。当年计算机资源稀缺，家中仅有一台供全家共用的书房电脑。如今我拥有十几台设备，所有内容都自动保存。但这就是它的起源。
在我看来，如今家用电脑反而比25年前更稀缺。
诚然：人们拥有智能电视、平板等各类计算设备。口袋超级计算机的普及率也已趋于饱和。
但曾经走进商店就能看到琳琅满目的电脑专用家具，或是造访家庭时总能在书房发现半永久放置的PC设备——如今这些景象几乎绝迹了。
诚然：当今电脑价格低廉且性能尚可。你我随处都能获得计算设备。但大多数人呢？如今他们只用手机。
(重点？老兄，我有时根本没重点。有时，纯粹就是发发牢骚。)
> 然而，曾经走进商店就能看到琳琅满目的电脑专用家具，或是造访家庭时发现书房里半永久性摆放着类似PC的设备，如今这些景象似乎已几乎绝迹。
我的经历恰恰相反：随着PC游戏日益流行，家具店如今开始销售以前不曾经营的游戏专用桌椅。
定期(约每三年)使用搭载Supermicro主板的FreeBSD机架服务器实现1000+天不间断运行。
这些服务器由我亲手组装，随后运往地球另一端的机房。
有次运行超过1400天后才需添加新硬盘。这些服务器运行近13年，期间仅更换过硬盘、升级过CPU并扩充过内存。
真诚提问：
你们是否应用过内核补丁？我也运行FreeBSD，每次内核补丁都重启系统，因此无法达到1000天连续运行。
你是否刻意使用无安全补丁的旧版本？安全支持终止日期通常意味着我必须在1000天前升级。例如当前稳定版仅在2025年6月10日至2026年6月30日提供安全补丁，实际支持期仅360余天。
我明白FreeBSD能实现稳定运行和超长运行时间，若不升级同样能做到，但我不明白如何在不让机器暴露风险的情况下实现。或许仅适用于物理隔离的机器？
> 你会应用内核补丁吗？
个人设备上我直接运行GENERIC内核，它包含大量组件，因此需要频繁更新。每次系统更新(即使不涉及内核)我都会重启设备，确保重启无碍…不过我用carp和pfsync配置了防火墙，能逐台重启防火墙设备且影响最小。
工作机器则采用定制内核配置，仅包含实际使用的组件。目前通常所有设备共用一个配置文件，因其更简洁。若内核某部分的安全更新涉及我们未使用的内容，则无需更新；驱动程序的安全更新若不存在于系统中，同样无需更新；而TCP层的安全更新则通常需要部署。部分安全更新会提供替代缓解措施供考虑…有时这些方案也合理。但某些情况下确实需要全量升级。
当遇到既有用又提供有效缓解措施的更新时，我会先在所有机器实施缓解措施，在单台或少量机器运行更新并重启测试，随后通常在其余机器安装更新。若某台机器重启后不再需要缓解措施，则说明更新成功。若设备已退役且连续运行1000天，同时存在待处理的内核更新，这种状态也完全可以接受。
我不会仅因当前次要版本的维护周期结束就进行更新，除非存在实际需求——例如后续版本发现的安全漏洞可能影响旧版本，或至少无法排除这种可能性。没错，过期版本确实存在未公开漏洞的风险；但受支持版本同样可能存在未公开漏洞。
我托管的四台服务器中，有一台运行12-BETA版本已连续运行1200多天。
该服务器通过防火墙严格限制仅允许VPN访问，SSH仅支持证书认证。主机上没有任何允许用户上传注入代码的服务，攻击者最多只能发起DDoS攻击。
我将bHyve运行在监狱环境中，任何可能突破bHyve堆栈的遗留服务都会直接被监禁。
问题提得好！但为什么我在这条评论下被扣分？
风险具有相对性，并非仅关乎该项安全措施。我在杀毒软件厂商工作时，内部常戏称我们的安全威胁清单就是恶意行为者的记分板。但若询问销售人员，他们会说不及时更新系统的人就是不负责任的菜鸟。他们从不考虑真正能自己动手的人——那不是他们的客户。
没错，我过去常编译定制版FreeBSD内核。曾多次手动打补丁，也通过阅读安全邮件列表实施过诸多临时方案。确实有几次让系统远超支持终止期限运行。
始终置于防火墙后，工作负载始终运行在Jail环境中。
依稀记得十年前发布周期更长时，这类问题并不突出。有人能证实吗？
我遇到的停机问题大多源于数据中心供电故障或硬件升级需求。
部分大型机构拥有庞大的OT和ISS基础设施，这些设备完全不连接互联网。这类基础设施采用空气隔离设计，或部署在完全独立的物理局域网中——必须通过多重物理安全控制才能访问。
我用FreeBSD运行NAS和几个基于bhyve的Linux虚拟机。当初直接装Ubuntu搞定算了？大概吧。不过确实犯过些错误：比如设置了过小的交换分区，忘记把RAID控制器切换到IT模式导致必须重建raidz1存储池，还把bhyve切换到UEFI模式才让网络运行更顺畅。我确保为Plex搭建的Jail环境运行正常。整个过程充满乐趣。现在或许该彻底重建系统了，但我知道当前配置完全能稳定运行。
未来多年都无需更新这台设备，说真的。
自90年代中期便使用FBSD。它(及BSDi)常超越“主流UNIX”厂商，性价比遥遥领先…若当年有优质服务器级机架式x86硬件，我们定会更广泛采用。如今我重返此阵营处理服务器工作负载。其优势在于：文档完善、发布周期稳定、极端负载下仍可靠运行。
我个人更倾向于Net/Open系统，但前几帖提到的Qotom网络设备运行的是FreeBSD。我将其作为无线桥接器，通过家庭WiFi为办公室有线局域网提供回程链路。市面上虽有现成设备可选，但我更喜欢用原生FreeBSD加自定义配置的方案。
我长期以各种形式运行家庭服务器。早期短暂使用Win NT4，后转用FreeBSD，再用Win2k服务器一段时间，最后长期使用Linux。尝试过FreeNAS，但因其WebUI频繁更新和文档陈旧分散而厌恶，不过喜欢ZFS文件系统。后来转用Linux Mint(是的，选择有点奇怪…)，但遇到兼容性问题且硬件质量糟糕。为了使用ZFS，我决定回归初心重新运行FreeBSD。
我意识到正确起步的关键在于优质硬件。于是我上eBay淘货(我知道，我知道…)，淘到一块Supermicro uATX服务器主板和一颗65瓦四核至强处理器(1151接口？)，又配了套全新的金士顿16GB ECC内存条，外加4块8TB企业级CMR SATA硬盘。
我研读文档，参考了博客和个人站点的教程。一天之内就搞定所有配置：账户管理、Raid-Z5数据存储、Samba和NFS共享服务。简直简单得离谱。自此系统稳定运行，可靠得令人乏味。我甚至得提醒自己它的存在，才能记得去更新系统、检查设备是否积灰或爬满蛇之类的。
作为普通用户，我实在找不到需要BSD系统的场景。甚至在虚拟机里试装过GhostBSD，但感觉和Linux差别不大，实在看不出优势何在？
ZFS文件系统和jails隔离环境是FreeBSD的两大优势
Linux拥有btrfs文件系统及多种容器化方案与安全沙箱选项。ZFS和jails并非Linux的差异化优势。
就个人经验而言，FreeBSD与ZFS的集成表现远胜于BTRFS和Linux发行版，况且我读过太多关于BTRFS数据丢失的报告，实在不敢信任它。
但我坚信FreeBSD能实现的功能Linux同样具备。对我而言，FreeBSD的完整套件生态、手册页与指南文档的完善性才是核心价值。
如今Linux与BSD的ZFS共享同一代码库，希望这个信息有帮助。
确实如此，但ZFS在FreeBSD中的集成度更高。它原生支持根目录使用ZFS并配置启动环境。
运行Samba服务器时，FreeBSD在ZFS与SMB客户端之间支持NFSv4访问控制列表(ACL)尤为便利；而在Linux上，Samba需通过将ACL存储在扩展属性(xattrs)中来绕过NFSv4 ACL缺失的问题。
虽然Illumos发行版可能提供更优的ZFS与SMB集成，但对我而言FreeBSD恰好平衡了易用性与软件包库的完整性——既易于操作，又包含所需程序。
但在Linux上需要加载外部模块。升级或更换内核前必须确认ZFS是否支持该内核，滚动更新发行版尤其棘手。
>需要确认
这可通过内核更新机制实现自动化。
还有pf。
虽是细节，但将软件包打包成更大元状态的机械化方法(个人认为)优于apt/dpkg那种即兴编写和包含的处理方式。
若产品是python，它就是python本身。不存在python-additonal-headers或python-dev这类命名，更不会出现“恰巧是python却无从知晓”的捆绑包。
只有python本身，以及明确“调用”python端口的元端口。
最典型的例子当属X11。其子组件划分极具理性：字体即字体，库即库，drm即drm，驱动即驱动。
(没错，端口/包的混淆确实令人困扰。)
您无需在每次软件升级时重新安装。可靠性和长期运行时间才是常态。
这些描述同样适用于Linux、macOS甚至Windows系统。
90年代的怀旧情结。
期待某天https://github.com/nixos-bsd/nixbsd能被纳入NixOS上游，届时在Linux和FreeBSD间切换将变得轻松许多。
1999年我也有同样感受。
现在依然如此吗？
是的，不过我们曾多次分道扬镳。FreeBSD在7.x版本时期曾让我远离数年，但我始终会回归。
> 让管理员将持久性视为特性而非赌博
我明白你的意思。但……
老天保佑千万别这样。不可变镜像？服务器是牲畜而非宠物。
我偏爱宠物。我还给服务器取傻气名字。所谓“牲畜而非宠物”的论调，我认为在破坏计算乐趣方面难辞其咎。
我不以服务器为单位思考，而是以应用程序为单位
应用程序是我的宠物。服务器是关它们的围栏。宠物珍贵，围栏可替换。
FreeBSD项目为我提供了二十余年稳定可靠的计算环境，在此致谢。
我也非常喜欢FreeBSD。生产环境中我们使用Debian(不含systemd！)，以下是某台服务器的运行时长：
$ uname -a
Linux deb2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux
$ uptime
08:50:41 运行 2512 天 17 小时 15 分 1 用户，平均负载：18.70, 20.46, 21.43
所以最后一次安全补丁是7年前的事了？
什么是爱？宝贝别重启我，宝贝别重启我 🙂 确实是坚如磐石的操作系统，我用它搭建个人DNS服务器从未出过问题，它就是这样持续运行着，几乎没有冗余。我觉得它比Linux稳定得多，但显然还需要改进才能成为有竞争力的桌面系统。我最近形成了一套使用哲学：桌面系统用Omarchy，服务器用FreeBSD——除非遇到不适配的特殊场景。
对我而言FreeBSD最大的卖点是延迟滚动发布策略——每三个月批量更新大量软件包，期间持续推送安全补丁。真希望Debian也能这样。
我欣喜地注意到FreeBSD正重新受到关注，更期待即将发布的15.0版本。
我多么希望FreeBSD采用GPL许可证。我知道这观点不受欢迎，但我认为Linux的成功源于copyleft机制，而*BSD只是借了东风。
但我讨厌Linux。虽然每天使用，却始终厌恶它。真希望FreeBSD能取代Linux如今的市场地位，那才是天堂。
> 但我认为Linux的成功源于copyleft
不，Linux的成功在于它能在家用机器上运行，且极易上手尝试。
以我接触Linux的经历为例：最初使用DJGPP，却因其无法多任务处理而困扰(在Emacs等IDE中启动编译后，必须等待完成才能继续操作)。因此我渴望真正的Unix系统，或至少接近它的存在。
最终发现Slackware是最佳选择。当时它能直接安装在MS-DOS分区内(通过UMSDOS文件系统的魔力，位于C:LINUX目录)，并直接从MS-DOS启动(借助LOADLIN引导程序)。这意味着：如同DJGPP，它可被视为普通MS-DOS程序(唯一限制是需重启才能返回MS-DOS环境)。无需为其划分专用分区，无需占用主引导记录或启动加载器。即使硬盘使用Ontrack磁盘管理器时也能正常运行(年轻用户可能不知，早期BIOS无法识别大容量硬盘，因此新型硬盘会捆绑此类软件绕过BIOS限制；而Linux能透明识别Ontrack的特殊分区方案)。
它兼容我所有硬件设备，且运行性能优于MS-DOS；不久后我发现自己几乎全程运行在Linux系统中，这才为其划分独立分区(后来干脆占用整块硬盘)。当然，那时我早已习惯Linux环境，从此便扎根于Linux世界。
后来我读到(在几个HN评论中)提到，FreeBSD不仅缺少这些酷炫技巧(UMSDOS、LOADLIN、对Ontrack分区的支持)，对硬件选择也相当挑剔。我不确定当时的硬件能否获得完整支持，即便支持也需占用整块硬盘(或至少整个分区)，且其启动流程(可能与Ontrack存在兼容性问题)会完全接管系统启动过程。
FreeBSD对硬件选择也相当挑剔。我不确定我当时的硬件能否获得完整支持
去年关于FreeBSD的评论复制粘贴如下：
1994年秋天我安装了Linux。当时也考虑过FreeBSD/NetBSD，但在Usenet的BSD论坛上，他们竟嘲讽我那台全新的3500美元PC不够格。
核心问题在于IDE接口存在缺陷。Linux在数日或数周内就找到了解决方法。
https://en.wikipedia.org/wiki/CMD640
BSD用户建议我购买SCSI卡、SCSI硬盘和SCSI光驱。当时我还是大学二年级生，省吃俭用攒了2000美元买这台PC，剩余费用由父母承担。我根本无力承担这些费用。
声卡又是另一个难题。
我记得当时有基于软件的“WinModems”，但Linux为其中部分设备提供了驱动。基于软件的“Win打印机”也是如此。
直到1998年左右终于毕业有钱购买SCSI设备时，我尝试了FreeBSD，它看起来只是另一个Unix系统。我用过Solaris、HP-UX、AIX、Ultrix、IRIX。FreeBSD完全没问题，但它提供的功能Linux早已具备。
我认同你的观点。但为何Linux能在所有硬件上运行？我认为若将这种思路推向极致，答案在于GPL许可证。
许多个人和组织将BSD移植到自家硬件上，但他们没有义务将驱动程序贡献给上游。而Linux强制要求贡献(如果你想向用户分发驱动程序)。
GPL并未强制要求贡献驱动程序。
它强制要求在分发时提供源代码供上游使用。
确实如此，若想分发Linux兼容驱动，就必须允许任何人将其上溯至Linux内核。
GPL或许确实促使设备制造商和开发者为Linux创建开源驱动，但我认为这并非主要因素。
就现代硬件而言，像第11代及以上英特尔处理器集成的Xe显卡这类硬件，驱动支持往往很快到位。某些设备如瑞昱2.5Gb网卡整合耗时稍长，不过瑞昱似乎提供了内核模块。记得1999-2000年我刚接触时，网卡兼容性还相当有限。真正让我头疼的是GNU与FreeBSD工具的命令行参数差异——记得有次从跳板机用错误的数据包间隔参数操作Colo服务器，直接搞死系统。
显然许多人不知晓FreeBSD曾因AT&T诉讼陷入长期停滞的历史。你们需要了解这段背景——这与copyleft毫无关联。
若FreeBSD采用GPL会怎样？你明天就能分叉它并发布FreeGPL版本(除ZFS外，但该组件属于contrib)。
部分FreeBSD用户追求超越GPL的自由度。贡献者不应因提供更多自由而却步。
我曾供职的机构向FreeBSD和Linux提交过改动，动机基本相同——无论是否需要按许可分发代码，保持分支与上游紧密关联更理想，而向上游提交改动正是维系这种关联的有效方式。
本人非法律专家，但即便采用BSD类许可，也无法随意更改代码许可。实际可行方案是仅发布二进制代码而不提供源代码。
没错，可以在基础上添加GPL代码，但底层仍保持BSD许可。
我不理解这种思路。GPL比FreeBSD许可证更具限制性。使用FreeBSD许可证比使用任何版本的GPL都享有更多自由。
> 但愿FreeBSD能占据如今Linux在市场中的地位，那将是天堂般的景象。
不过Linux兴起时，BSD正深陷AT&T的诉讼泥潭，因此虽历史更悠久，却可谓起步较晚。
这种信念对某些人或许美好，但与历史事实和背景完全脱节。
GCC与LLVM之争。关键不在于许可证。
这话我不敢苟同…LLVM直到2003年才诞生。BSD和Linux在此之前都已存在多年，且Linux当时已积累了更强大的发展势头。
当Linux起步时，BSD深陷部分代码的诉讼风波，相关恐慌情绪让Linux抢占了BSD原有的先机。因此无法透过这层迷雾推断Linux早期胜出的真正原因。倘若Linux遭遇与BSD相同的困境，如今BSD的地位几乎必然取代Linux。
短短几年后，Linux就遭遇了SCO的诉讼。还有一段时期，微软也曾试图摧毁Linux。
区别在于，当SCO/微软诉讼发生时，Linux已获得企业界的广泛支持。
我认为这与其说是因为许可证问题，不如说是因为人们发现修改gcc补丁实在太麻烦。
公平地说，GCC的设计初衷与许可证精神如出一辙。开发者刻意避免模块化设计，正是为了防止非自由代码使用GCC。
> 任何能让GCC后端在脱离前端的情况下更易使用的方案——或直接使GCC更接近便于此类使用的形态——都将危及我们推动新前端开源的筹码。
https://gcc.gnu.org/legacy-ml/gcc/2000-01/msg00572.html
没错，问题不在于许可证。
> 但愿FreeBSD能占据如今Linux在市场上的地位。那简直是天堂。
我不这么想。那样会毁掉我钟爱的一切。若它像Linux般庞大，就会充斥企业西装客的影响力、持续不断的改动、不断追求“主流化”的驱动力等等——这些正是我厌恶Linux的地方。
Linux还行。比起BSD它确实混乱，但勉强可用。这是懒人解决方案，主要服务于只想“docker compose up”后就走人的用户。操作系统的艺术已然失传。人们认为操作系统是需要尽可能抽象化的存在，认为它邪恶且难以保障安全。可悲。
我愿提出反驳：Linux是为高效完成任务而生，而BSD似乎更适合将操作系统本身视为爱好的群体。
我对折腾操作系统毫无兴趣。我只希望它别碍事——而Linux95%的时间都做得很好。
我无需频繁折腾，因为没有发行版维护者不断改动系统。
初始配置确实耗时，但运行稳定后便无忧。我不把操作系统当作爱好，但渴望完全掌控它并理解其运作原理。我不愿被迫信任商业公司会为我谋利——因为他们从不如此。当前Windows系统的混乱状态就是典型例证：充斥广告和无用的人工智能垃圾，强制遥测数据收集，强制更新推送，不断兜售云服务等等。而FreeBSD完全没有这些问题。
大多数Linux发行版也避免了这些问题，但企业影响依然存在。我感觉它正沦为科技巨头的玩物。只需看看Linux基金会董事会里有多少企业高管，有多少补丁是由企业员工作为工作职责提交的，就能明白。我不愿让这些势力如此掌控我的操作系统。我根本不相信企业参与开源能实现双赢。
FreeBSD也存在类似问题(Netgate彻底搞砸的WireGuard就是例证)，但教训已被吸取。
>没有哪个发行版维护者会频繁改动核心功能。
这是Linux圈内人常有的误解。过去十年间确实存在争议性变更(如systemd和Wayland)，但坦白说，那些把“拒绝使用systemd”当作个人标签的人实在令人尴尬。
即便在Fedora这类滚动更新的尖端发行版上，实际变化也微乎其微。
>我不把操作系统当作爱好，但渴望完全掌控它并理解其运作原理。
FreeBSD对系统运作的控制权限与Linux并无本质差异。
> FreeBSD 赋予你的系统控制权限与 Linux 并无二致。
然而我在 Linux 桌面端总要不断打补丁、绕过库文件问题，FreeBSD 却从未如此。这正是关键所在。Linux是众多组件拼凑而成的系统，运行效果确实出色；而FreeBSD则是精心挑选并统一维护的组件集合，绝大多数情况下运行得极其稳定。
若Linux能满足需求，请继续使用。没人试图说服你转换阵营。
>mom-Linux
显然指非Linux系统。无法编辑。
这曾是Windows胜过Linux的论点。
但FreeBSD始终比Linux需要更少的调试和维护。
最近频繁看到这种观点。
个人认为英特尔早期对Linux的投资起到了关键作用。他们还销售编译器，并向购买芯片的实验室等机构进行营销。因此Linux兼容性对决策者至关重要。
作为弱势方的AMD在Linux兼容性方面投入更多，这或许是商业决策使然。
说不清，也许GPL的影响更多体现在开发者市场份额上，而非版权左倾理念本身。
附注：我确实热爱copyleft理念，并为所有个人项目采用AGPL许可协议
Linux与BSD的较量发生在NVIDIA与AMD之争成为热点之前。
FreeBSD缺乏Linux那样的硬件支持基础，当x86对称多处理硬件普及时，其架构重构遭遇了巨大延迟。(当时内核中仅能存在单核CPU，即“bkl”机制，这在21世纪初构成重大阻碍)。尽管FreeBSD当时拥有更优的资源调度和备受推崇的网络栈，但Linux通过cgroups等技术迎头赶上。我认为Linux某种程度上也是潮流先锋——当世界通过互联网认识开源软件时，它恰逢其时。
我深有同感，因为如今似乎只有GNU/Linux是符合GPL许可的桌面级操作系统，但它如今显得过于臃肿(更不用说Linux实际上被GPLv2许可束缚)。像FreeBSD这样的系统则轻量得多，且依然具备桌面级适用性。Hyperbola团队似乎也持相同观点，因此他们正在开发HyperbolaBSD。顺便一提，GNU Hurd虽有进展，但距桌面化仍遥遥无期。
技术讨论社区亟需新规：禁止那些仅靠“过于臃肿”“感觉轻便许多”这类空洞评论。纯属毫无价值的浮夸描述。
不，这只是你对这些词汇抱有奇怪偏见(很可能源于对某些过度炒作技术的盲目信仰)，还是去好好监管你偏爱的回音室吧。
不，这是基于二十多年来的观察——那些鼓吹此类废话的人，其论断始终无法得到现实世界的验证。
纯属发烧友的幻想谈资。
GNU Hurd的“进展”实在令人发笑。这种说法我从九十年代就听腻了
他们现在至少能提供勉强能用的x86_64镜像。一个90年代启动的项目直到2020年代才支持x86_64固然可笑，但相对而言还是有进步的。
绝无可能。ZFS无法在GPL许可下分发
Debian和Ubuntu提供二进制形式。我可通过DKMS将其添加至任何发行版。核心ZFS代码与BSD完全一致。
坦诚提问——若以二进制形式提供，如何确保其核心代码与BSD版本一致？
与其他二进制包安装逻辑相同：信任打包/提供二进制文件的团队。若不信任，可自行编译。源代码已公开。
或者你自己编译并验证是否得到相同的校验和。
https://reproducible-builds.org/
Debian仅以DKMS形式分发，不提供二进制形式。
同意。不过在FreeBSD案例中，我认为问题远不止于此。这纯粹是无法改变的理念问题。
能否详细说明FreeBSD与Linux的差异？
超爱这个Sun E10k的典故！！
– 前Sun员工
E10k让我想起Bryan Cantrill讲述dtrace研发动机的轶事。Sun工程师们日夜奋战，试图在E10k机器组成的基准测试集群上调试Solaris内核网络漏洞。结局很精彩就不剧透了：
https://www.youtube.com/watch?v=wTVfAMRj-7E&t=2640s
是啊，若Sun公司能延续至今，我们该拥有多少惊艳之作！
但甲骨文触碰的一切都会毁于一旦。
除了Netflix、PlayStation这类小众领域，甚至还有人常拿MacOS举例夸耀它的优秀…
确实如此。
BSD/Illumos操作系统常被用作高端商用/企业网络、存储区域网络(SAN)、网络附加存储(NAS)等解决方案的基础系统。它们因卓越性能、稳定性和高可用性特性而被选中。
还有那个小众应用Whatsapp
Reddit最初也是“几台BSD服务器”。问题在于项目规模扩张时，迟早需要“通用型”系统管理员，因此直接转向Linux更省事。
随着项目规模扩大，总会有人提出迁移到Linux的建议。
若我没记错，他们已经迁移到Linux了
我本想继续使用它，但NVIDIA已放弃支持，所以无法继续。真希望他们能为现代CUDA提供些支持。
我知道这是新手视角，但他们应该尝试(是的，我已知晓GhostBSD)让桌面环境更易上手——对新手而言，从零开始学习系统配置实在太困难了
安装基础系统后，只需执行“pkg install
<你喜欢的桌面环境>”即可安装心仪的桌面环境。这有什么难的？
在FreeBSD能够呈现图形环境之前，它需要一个内核模块来驱动图形处理器。图形驱动程序是一个快速发展的跨平台目标，因此它与FreeBSD基础系统分开发展和分发。
“要启用驱动程序，请通过执行以下命令将模块添加至/etc/rc.conf文件：…”
https://docs.freebsd.org/en/books/handbook/x11/
我明白这不算什么高深技术。但拜托
再说一次，“pkg install
<你喜欢的桌面环境>”就搞定。别在不懂原理时胡编乱造。真相是FreeBSD本就不欢迎普通用户。
Linux(Ubuntu等)的安装流程能直接进入可用桌面。天啊，安装盘启动后直接就是可用的桌面环境。
况且普通用户压根不知道自己喜欢的桌面环境叫什么，甚至不知道什么是桌面环境。
要求用户进行文本登录并执行命令行操作——哪怕只是“pkg install KDE”这么简单的命令——对当今的普通用户来说都是高门槛。况且这条命令很可能执行失败。:)
我写这些话时可是FreeBSD的超级粉丝！我认为不迎合普通用户确实让FreeBSD保持了更纯粹的技术定位，但Linux显然更受欢迎。这种差异也存在风险。
实际上pkg install kde正是正确操作方式，只是不该用大写字母。
不过在FreeBSD 15中它将被纳入安装程序。但即便安装程序对当今主流用户而言也过于复杂。我并不希望FreeBSD成为主流系统——尤其是因为主流用户追求的(由厂商全权决定一切)模式，与FreeBSD的理念及我的期望完全背道而驰。
普通用户会成长为资深用户，进而成为贡献者
我并非主张“让一切变得简单”。若存在不提供简易X11入门方案的正当理由，若FreeBSD确实定位为专家级操作系统(基于诸多历史原因，我理解这种定位)，那也无可厚非。
直接链接文档算空谈？
在我看来Linux在这方面同样失败。GNOME和KDE都糟糕透顶——或许“糟糕”都算轻描淡写，我认为两者都存在严重缺陷。
但请注意，这并非说它们无法使用——GNOME成功地将操作简化到连60岁老奶奶都能操作(直到她们误点鼠标，瞬间弹出20个并排窗口)。而KDE提供了高度的定制灵活性(若忽略Nate的捐赠小工具的话)。但它依然复杂得离谱，操作流程错综复杂。与其在烦人的小工具里摸索半随机的新设置 (或者根本找不到设置项，就像GNOME那样)。真希望我们能从上游开发者及其专制统治中解放这些桌面环境。我的意思是，我们当然可以补丁移除不该存在的代码(比如Nate的罗宾汉小工具)，但我是指在整体层面上彻底改变现状。作为用户，我们应当掌控一切——每个控件、每个控件的功能，以及当前缺失却理应具备的功能。比如evince里无法使用标签页的设计就让我抓狂。我知道libpapers能解决这个问题，但天啊…试着和GNOME开发者讨论这事简直是浪费时间。我要求掌控所有决策权——上游开发者绝不能以任何未经我许可的方式瘫痪或干预我的系统。
我热爱KDE，尤其欣赏它赋予我的自主权。不像GNOME那样强加开发者的主观选择，我不会被动接受。而且KDE的界面设计清晰直观，不易令人困惑。
它或许不适合老奶奶用，但我不在乎。它本就不必如此。对我而言，软件越迎合主流，就越不符合我的需求。
不明白你说的捐赠小工具指什么，我在FreeBSD上用KDE当日常系统(还是最新版本)，从未见过这种东西。我每月都向KDE捐款，但它根本无从得知。
我不喜欢KDE，更倾向使用Gnome，但KDE在4K和高DPI显示器上的比例缩放效果确实远胜一筹。
嗯…你的YAML配置文件恐怕也难令祖母满意。总之若你抗拒变化，除这两者外还有更合适的桌面环境。试试XFCE或Mate吧，配置完成后数年间界面与行为都不会改变。
> 若有人每月都想追逐炒作或最新炫酷功能，Linux正合他们心意。
直接。用。Debian。
FreeBSD的软件包更新策略与Debian截然不同，本质上是延迟滚动发布。唯一能想到的类似系统是OpenSUSE慢速滚动版。
然后安装Postgres
致最后一个不试图操纵你的操作系统的爱情信函。FreeBSD确实是反炒作的选择：没有吉祥物服务，没有季度性身份危机，只是一个默默运转直至宇宙热寂的系统。
说到更好的厂商支持，为何至今不支持苹果硅？显然朝日团队已率先实现，其m1n1引导程序可开箱即用。但OpenBSD支持苹果硅已三年之久。
原因很简单：没人愿意为此付出开发精力。否则它早就存在了。
FreeBSD向来就是那个不支持移植的系统。
为什么要支持？为什么所有东西都必须支持所有东西？为什么一个项目不能专注于服务器领域，以此作为其特色？
况且这是开源软件——如果你对此如此热衷，就贡献支持代码吧。
祖帖的原始未编辑版本是在哀叹FreeBSD缺乏厂商支持，因此父帖的评论在上下文中才显得合情合理。
是的，抱歉删除了那部分。发帖几分钟后就改变了主意，因为我真的很喜欢FreeBSD，而我的批评听起来有些过于严厉。
> 以上所有
首先，FreeBSD早已支持x86架构的Mac Mini。服务器？M系列Mini和Studio本就是优秀的服务器平台。最后，FreeBSD确实存在Apple Silicon移植版本，只是目前进展停滞。
https://wiki.freebsd.org/AppleSilicon
最后一点恕不回应。
唉。没错。这选择虽然乏味，但多数时候反而更稳妥。并非永远如此，但绝大多数情况下确实如此。
正是由于缺乏耐心和技能流失，它才无法成为主流玩家。
> 文化因素同样重要。我离开Linux的原因之一，正是那些喧嚣的争论淹没了构建的乐趣。
完全听不懂他在胡言乱语。LFS/BLFS项目活跃着，FreeBSD可没有。抱歉，Linux才是更好的DIY玩具。我明白这会让BSD阵营不快，但事实就是如此。诚然，systemd和企业化对Linux生态造成重创，即便如今它已显颓势(KDE开发者近期宣布将终结Xorg并强制迁移至Wayland)，作为“玩物”的活跃度仍远超其他系统。这就是现实。
多年前NetBSD邮件列表就有人指出：如今Linux运行的烤面包机比NetBSD还多。这正是“玩物精神”的强大之处。
> 请让FreeBSD保持开放包容的工程氛围，远离个人恩怨
K——全球三四个用户请注意。
> 还有实际考量：要保持与戴尔、惠普等硬件厂商的合作通道畅通，确保FreeBSD保持核心地位。
但现实是Linux支持更多硬件。抱歉FreeBSD同仁——这就是现实。我们无法回避或忽视它。
> 我的期望很简单：保持独特性。不是那种喧哗博眼球的独特，而是赢得信任的独特。
TempleOS同样存在。
我认为它比任何BSD系统都更具独特性。
> 若有人追求炒作或每月更新的炫酷功能，Linux已然满足。
没错——但你也不必走这条路。想象Linux上存在选择：我完全可以不用systemd运行Linux，这毫无问题。我也不需要GNOME或KDE那些乞讨捐款的开发者来摧毁xorg。(诚然，GTK和QT似乎是仅存的老牌桌面GUI，而GTK如今已难用。)
> 正如Unix最优秀的传统所示，他们应当知道这里能找到它。
是啊…500台超级计算机中有500台运行Linux…
> 或许某天，有人路过服务器机架时，会听见FreeBSD系统仍在稳定运转的悠然节拍
我曾使用FreeBSD一段时间，直到某件事迫使我重返Linux——回家时发现电脑已关机。离开时明明还在运行。那台机器装的是FreeBSD。这当然是个例，但Linux从未出现过这种问题。
我认为FreeBSD用户需要承认某些方面Linux做得更好。
我同时使用FreeBSD和Linux，对任何操作系统都不抱执念。
奇怪的是，每当FreeBSD获得好评时，总有大量Linux(且仅限Linux)用户要贬低它。
我不理解这种心理现象，若能探究其中缘由倒颇有意思。
我也是如此。
三十年来我始终同时使用FreeBSD和Linux，因为两者各有优劣。
在笔记本和台式机上我使用Linux，因为某些硬件设备可能无法获得FreeBSD支持，或者需要与某些难以移植到FreeBSD的应用程序保持软件兼容性。
我还在某些计算服务器上使用Linux系统，因为需要兼容FreeBSD无法支持的软件，例如NVIDIA CUDA。(尽管CUDA不支持FreeBSD，但当FreeBSD计算机需要图形显示时，NVIDIA显卡仍是正确选择——因为NVIDIA为FreeBSD提供驱动程序，而AMD则没有。)
我在承担网络或存储功能的各类服务器上使用FreeBSD，最看重的是其最高可靠性和最简化的管理特性。
我认为这是在努力推广Linux，以获取更多市场份额。
Linux用户不愿看到潜在用户选择BSD而非加入他们的阵营。
每个论坛、每场讨论中，总有人炫耀“我在Linux上运行了某游戏”，或宣称“其他系统不如Linux”，或声称“这类问题在Linux上绝不会发生”…
说到底，这不过是营销手段罢了…
我认为这纯粹是喷子和死忠粉在搞事。
每个操作系统都有死忠粉群体，就像足球迷或宗教狂热分子一样。
> 哦对…500台超级计算机中有500台运行Linux…
那又怎样？了不起嘛。