# BSD Now 与将来 * [BSD Now and Then](https://freebsdfoundation.org/our-work/journal/browser-based-edition/downstreams/bsd-now-and-then) * 作者：Benedict Reuschling BSD Now 播客最近庆祝了其第 600 集，这似乎是一个绝佳的机会，让 FreeBSD 期刊的读者深入了解这个长期运行的 BSD 节目的幕后故事。 ## 谦逊的开始 BSD Now 始于 2013，由 Allan Jude 和 Kris Moore 主持。当时我还是名普通听众，兴奋地等待收听 BSD 领域的最新消息。随着时间的推移，BSD 领域迅速变成了“BSD 之地”，正如 Kris 曾著名地说过的那样。这个节目提供了新闻和教程，其中后者是 Allan 单独录制的。他曾告诉我，这很困难，因为你不仅要打字，还要解释自己在做什么。打错字和其他意外的计算机故障意味着要么撤销更改并剪辑录音，要么完全重新开始。从一开始，节目就提供了一个反馈渠道，让听众通过电子邮件提交想法、节目内容和关于 BSD 领域的讨论，而这些反馈会在每集的结尾被读出。人们经常用这个渠道来询问关于安装或使用 BSD 的问题。有时，Allan 会提供他在 ZFS 方面的丰富知识，帮助用户在家构建 NAS 或理解一些难以理解的概念。 Kris 也分享了来自 PC-BSD 方面的视角，讲述了现代 Unix 桌面的一切。这种结合包含了我作为 BSD 用户所寻找的所有优点。因为你只需要等一周就能听到下一期 BSD Now，这意味着我的 BSD 电池（每次参加完会议后都会充电）不会很快耗尽。这种情况持续了好几年，而这简短的早期节目的描述并不能完全呈现其意义——Allan 和 Kris 还可以讲述更多那个时代的故事！ 我清楚地记得，BSD Now 对我来说不再仅仅是我收听的播客，而是变成了更多东西。我们当时在 FOSDEM，并且以小组的形式去了布鲁塞尔的一个餐厅。当我们坐在一张长桌子旁等待晚餐时，Allan 提到 Kris Moore 因为生活越来越忙而打算从播客中退出。他们正在寻找一位接替的主持人。听到这个消息，我天真地问了一句，这个过程是什么样的。我有时忍不住说话，而那时我甚至没考虑过自己要接手。Allan 简单地解释了这个过程，如何每周见面一个小时进行录音，以及节目的技术后勤工作。这一切听起来都很令人兴奋，而我一直愿意在有需要时提供帮助，所以我说我愿意加入。Allan 喜欢这个想法，我们在其他渠道上继续讨论（顺便说一句，晚餐已经上桌了）。 这个变化直到 2017 年 3 月 16 日在 AsiaBSDCon 会议的一个独立房间里进行的录音时才被宣布。第 185 集的交接节目给了 Kris 一个告别的机会，也让我有机会介绍自己。这些早期的节目确实有点坎坷，但最终我掌握了它。每周练习我的英语并与时俱进地了解 BSD 领域的情况，感觉非常好。 ## 独立之路 BSD Now 最初是作为 Jupiter Broadcasting 播客网络的一部分运行的。这意味着节目之间会有一些交叉推广，因为听众很可能也会尝试该网络下的其他节目。此外，自 TechSNAP 时代以来，Allan 一直是位受欢迎的人物，这可能帮助提高了听众数量。该网络还提供了大量后勤支持，如后期制作。对他们来说，这只是另一个要剪辑并按时发布的节目，这使我们能够完全专注于录制和内容。 播客领域近年来经历了一些并购整合。2018 年秋季，Linux Academy 宣布与 Jupiter Broadcasting 合并，随后又被在线教育平台 A Cloud Guru 收购。尽管这类并购通常伴随着业务重组，我们节目仍得以在新公司旗下继续制作。主持人 Allan 与 Jupiter Broadcasting 的创始团队——包括 2008 年创立该网络的 Chris Fisher 和 Bryan Lunduke——保持着良好关系。2020 年 4 月 23 日第 347 期节目中，我们宣布将从 Jupiter Broadcasting 独立（注：Chris Fisher 于 2020 年 8 月重启了独立运营的 Jupiter Broadcasting）。这一转变如同作家选择自出版，意味着我们需要处理大量节目运营事务。所幸我们留住了 Angela Fisher 负责幕后工作，包括将成品节目发布至各大播客平台，因此仍能维持每周正常更新。我们的制作人 JT 从第 100 期左右开始参与制作。他自 2013 年起就担任《Linux Action Show》的制作人，后因 Chris Fisher 调整节目方向不再需要其协助。恰逢 Allan 正在寻找接替原制作人 TJ 的人选——鉴于 JT 曾与 Ken Moore 共同开发 Lumina 桌面环境并参与 PC-BSD 项目，Allan 便邀请他加入。由此 JT 成为我们的常驻制作人，其精湛的后期剪辑技术（每期约一小时工作量）使 Allan 和我能专注节目内容创作，无需额外耗时。虽然我们从不依赖点击量或观众导向的营销模式获取资金，但支付团队报酬仍是必要开支。长期以来，Colin Percival 的 Tarsnap 备份服务始终是我们的赞助商，其优质服务也常被我们在节目中称道。这份稳定的赞助支持着我们这个小众播客保持独立运作，我们对其持续慷慨的资助始终心怀感激。 ## 节目制作内幕 每期节目的诞生始于两位主持人敲定录制档期。确定时间后通知制作人 JT，他会在共享文档中搭建节目提纲框架。我们通过多种渠道收集选题——科技新闻网站、论坛、个人博客、听众邮件投稿，以及那些常年产出优质内容的"老面孔"：要么是专注 BSD 的垂直媒体，要么是长期深耕 BSD 报道的独立平台。 JT 会根据多重标准筛选内容：新闻时效性、突发性、篇幅长短，以及下期录制人选——最后这点尤为重要，因为某些主持人更擅长特定领域（除了我......或许我的作用就是维持平衡？），能在相关环节提供深度解读。重大时事通常作为头条，短讯则归入新闻快报或 Beastie Bits 板块。所有内容都需精心编排以适应 45 分钟时长，若某则报道篇幅过长则需剪辑。为此我们严格把控时间，仅访谈和特辑会适当延长。 当提纲草案完成并上传至不断膨胀的节目文档库后，我会补充元数据：录制日期、基于新闻标签的关键词，当然还有标题。没错，那些让你在播客客户端里看到就皱眉的奇葩标题都出自我手。节目早期曾有条不成文规定：标题必须由三个单词组成（或许是出于营销考虑——短小精悍易传播）。这种限制如同双刃剑：简洁标题不易冗长且便于记忆，但要从节目内容提炼出妙题却非易事。比如报道 NetBSD 运行巨型摩天轮的新闻，该起什么标题？"命运之轮"？"NetBSD 巨轮"？还是"旋转的 NetBSD"？我常为此绞尽脑汁（不过至今没有同事在录制前抗议或要求修改）。 当这些筹备工作就绪，我们就拥有了一份可立即录制的完整提纲。理想情况下，提纲应提前足够时间供全员预习内容，但现实往往事与愿违——有时我们不得不在录制时才首次接触某些报道。虽非最佳状态，这种"初见反应"反而能带来最真实的即时反馈。 ## 录制现场 正式录制前，我们会协商分配报道板块，确保各自能负责最擅长的内容。通常采用轮换制推进流程——这种模式既能让他人从长篇解说中稍作休整，也为后续内容预留准备时间。 录制过程中，视频连线窗口始终开启着（尽管我们身处不同空间，也非专业录音棚），这种"视觉同步"被证明至关重要：能判断对方何时结束发言，通过点头、手势甚至举起正在讨论的资料进行无声交流。请注意，我们使用的虽是统一专业设备，意外仍可能随时降临——网络中断、窗外施工、飞机轰鸣、快递员按门铃都曾导致录制中断。所幸这些状况并不频繁，后期制作能修复部分音频故障，但绝非万能。若事故严重，我们不得不局部重录甚至推翻整期内容（最坏的情况）。这对连贯性创作是巨大挑战：我们采用一气呵成的录制模式，强行插入补录片段或复现原话都会让听众察觉不自然的断裂感。 音频问题可谓家常便饭，有时甚至需听众反馈才察觉异常。可能是某方音量过低、音轨错位导致串音，或是麦克风参数莫名改变。最近我才发现，从首期沿用至今的耳机竟早已单边失灵——最初还误以为是对方音量设置问题。更换新耳机后，搭档们的声音清晰得仿佛近在耳畔。音频工程这门学问，实在是门玄学！ ## 特别企划 Allan 在创办 BSD Now 之前就深耕播客领域，我们持续保持着采访 BSD 业界人士的传统。会议现场也是绝佳的录制场所——只需把采访对象拉进安静角落即可展开对话。这类即兴采访充满刺激与未知，因为我们无法预先准备完整的采访提纲。常规访谈会预先设计问题，但会议现场的采访必须根据受访者身份临时发挥。我们始终感激这些愿意即兴受访的嘉宾，他们通过我们的平台触及更广受众，分享项目进展、招募测试人员，并讲述与 BSD 结缘的故事——这永远是 Allan 和 Kris 开场必问的经典问题。 第 103 期对 Bryan Cantrill 的访谈令我着迷。尽管当时对他一无所知，但那些 Unix 秘辛与犀利观点让我反复重温这期"常青树"内容。众多听众的强烈反响促使我们在第 117 期安排了后续访谈。这些触及行业痛点的对话，如今回望竟与 IT 领域的发展轨迹形成了奇妙呼应。 多位业界翘楚也曾慷慨受访：Michael W. Lucas 堪称"年度最频繁嘉宾"，我们既追踪他书籍创作的博客动态，也总在新书发布时邀他畅谈。他的访谈为自出版行业提供了珍贵洞见，文字与语音在此形成了绝妙互补。 当主持人需要长期休假时（人生总有意外），我们会邀请客座主持。我曾与 BSDCan 创始人 Dan Langille（这只是他众多成就之一）合作过至少两期。第 404 期《BSD Now 主持人大失踪》堪称史无前例——全体常规主持被临时替换，这需要制作人 JT 提前数月筹划，而他似乎乐在其中。 某些特殊编号的节目也值得纪念：386、486 等极客数字自然要有特别安排。虽然对 666 期有些忐忑，但我已开始期待 686 期。最近我们还在讨论：999 期是否该为这趟漫长旅程画上句号？不过突破千期大关或许更有诱惑力——未来谁说得准呢？ 节目排期从非易事。节假日、会议行程、突发状况时常打乱计划。如今我们总会预留一期缓冲节目，圣诞新年等假期则提前录制特别内容——虽然节日期间加班制作，但换来的是与亲友共度的珍贵时光。 ## 人员更迭 随着生活日渐忙碌，Allan 需要从每周录制中抽身。我们首先调整为隔周双录模式，之后在第 400 期（注意到数字规律了吗？）迎来第三位主持人 Tom Jones。新模式下 Allan 和 Tom 每月只需参与一次录制，而我保持每两周固定出勤。Tom 带来的网络工程专长完美弥补了我的知识盲区。 颇具戏剧性的是，在轮休期间，早已是播客老手的 Allan 又创办了《2 1/2 admins》节目。若没有他当年勇敢尝试 BSD 主题播客，就不会有我们每周的精彩内容。作为创始团队最后留守的成员，他于 2023 年宣布将专注 Klara Systems 公司运营，并在 BSDCan 大会现场录制的第 512 期（数字玄学再现）公开这一决定。为确保节目延续，他推荐了资深播客人 Jason Tubnor 加入。如今 Allan 仍活跃在我们的内部制作频道，随时提供建议。制作人 JT 则全面接管了节目前后期制作及商业运营，包括建立 Patreon 赞助体系、整理历史节目库、维护网站等重任。 Jason 为节目注入了丰富的 OpenBSD/FreeBSD 实战经验，无论是系统安全、生产环境部署还是 bhyve 虚拟化，他总能提供深度解读。我尤其享受与 Tom 或 Jason 在正式录制前的闲聊环节——这些充满真知灼见的对话后来被制作成 Patreon 高级赞助者专属内容，涵盖项目进展、行业洞察、活动预告等精彩花絮。 ## 听众回声 每周稳定产出节目堪称壮举，听众反馈也令人欣慰：有人坦言追不上更新进度只能跳着听，有人发来对我们未解问题的补充解答，更有被报道的博主专程致谢。于我而言，推荐优质博客既能丰富节目内容，又能为创作者带去额外流量——这种良性循环或许能激励更多 BSD/Unix 主题的持续创作，甚至促成听众与作者间的合作契机。 多次在 BSDCan 被听众凭声认出，或是被大学里的学生提及节目，都让我倍感欣喜。虽然远未到名人级别（也未必向往），但知道有人每周期待我们的节目，那些技术问题解答确实推动了 BSD 的普及，这种价值远非收听数据所能衡量。 ## 未来之路 常有听众询问为何不恢复早期视频形式。除增加剪辑难度外（需同步口型、插入网页/视频素材），更重要的是许多通勤听众反馈 45 分钟的纯音频体验更为高效。作为折中方案，我们近期向 Patreon 赞助者开放了未剪辑原始视频源。 节目形式会否再有变革？正如 BSD 系统的独特气质，我们始终保持着灵活演进的姿态。六百多期走来，正是赞助者与听众的支持，以及广大 BSD 开发者、撰稿人的持续输出，才让这个小小播客在数字海洋中拥有专属坐标。只要这份热情不变，这里就永远是 BSD 爱好者的精神家园…… *** 作者 **BENEDICT REUSCHLING** 系 FreeBSD 文档提交者，曾任核心团队成员及 FreeBSD 基金会副主席，在德国达姆施塔特应用技术大学管理大数据集群八年余，现讲授《开发者 Unix 基础》课程，并担任 bsdnow\.tv 每周播客主持人。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.bsdcn.org/qi-kan/2025123-xia-you-xiang-mu/now.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.