> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20140506-wang-luo/this-month-in-freebsd.md).

# FreeBSD 本月动态

* 原文：[This Month in FreeBSD](https://freebsdfoundation.org/our-work/journal/browser-based-edition/networking/this-month-in-freebsd/)
* 作者：**Dru Lavigne**

FreeBSD（以及其他 BSD）社区中的许多人会把 5 月标在日历上，作为每年一度远赴加拿大渥太华参加 BSDCan 的时刻。这场会议如今已步入第 11 个年头，多年来已扩展为两天教程、两天三轨演讲、开发者峰会、供应商峰会、文档冲刺、基金会会议，以及一次取得 BSD 认证的机会。

我最近请 BSDCan 的组织者 Dan Langille 谈谈 BSDCan 缘何而起、如何成形，以及一路走来他对 BSD 社区的体悟。

Dan 写道：

> 我首次接触 BSD 会议是 1999 年 10 月在伯克利举办的 FreeBSDCon。那时我用 FreeBSD 已经将近 18 个月。翻看当年的笔记（<http://www.freebsddiary.org/freebsdcon99.php>），我看到自己被那场会议的社交氛围所打动——它与其他会议形成鲜明对比。次年，我参加了同一会议——此时已更名为 BSDCon——2000 年在蒙特雷举行。我又一次度过了一段美好的时光，学到了新东西。
>
> 当时我住在渥太华，活跃于本地 Linux 用户组 OCLUG，曾帮他们组织过相当成功的 OSW（Open Source Weekend）。如果我没记错，BSDCon 后来停办，留下一片空白。我知道有 Andrew Hutton 主办的 Ottawa Linux Symposium。我和 Andrew 吃过几次午饭，谈论办会议的事。他的会议与 BSDCan 截然不同（比如预算惊人）。作为对比，当年他们的一场派对花费就超过 BSDCan 2014 全部预算。正是这给了我信心去和渥太华大学商谈承办会议。我算过，就算最坏的情况发生、无人到场，我也不过损失大约 2,000 美元。2003 年 8 月我注册了 `bsdcan.org`，一切由此展开。
>
> 公告于 2004 年 1 月发出（<http://lists.freebsd.org/pipermail/freebsd-announce/2004-January/000934.html>），几个月后，BSDCan 的传统由此开启。
>
> 最让我意外的是会议如此受好评，以及会议结束后我如释重负的感觉。闭幕场开始时那阵掌声令人震撼，让我热泪盈眶。大家说会议办得很好，还评论说我在会议期间看上去多么放松。他们问我有什么秘诀。我没什么秘诀。我只是按照自己希望的那种会议体验来组织罢了。
>
> 多年来情况不断变化。一开始我们去本地酒馆吃午饭，但很快超出他们的接待能力。如今午餐包含在会议中，大家留在会场。这给了我们更多的面对面时间，而正是我在 FreeBSDCon 上看到的社交互动，在 BSDCan 上延续了下来。
>
> 第一届会议时，我写了一套注册软件和一个简易调度系统。注册软件沿用至今，但 2007 年我们转向 Pentabarf 来处理演讲提案并生成日程表。那一年我还开始办 PGCon，时间在 BSDCan 之后一周。
>
> 2006 年，FreeBSD 项目在 BSDCan 上举办了开发者峰会，此后每年延续。它已发展到超过 120 名与会者，他们的参与也助推 BSDCan 成长。
>
> BSDCan 与 PGCon 的若干对比：尽管两场会议规模大致相当，但 PGCon 收到的演讲提案大约是 BSDCan 的三倍。
>
> 今年我得到 Jennifer Russell 的大力协助。她一直是收集和安排差旅的主要人员。这一做法非常成功，因此我希望继续让更多人参与到 BSDCan 的组织中来，主要出于两个原因：一是减轻我的工作量；二是确保 BSDCan 能延续下去（我不会永远做下去）。
>
> 组织会议时我始终牢记一点：保持核心。不要卷入任何非会议核心活动的事。保持专注。例如，有人想做视频，就让他们做。不要插手。
>
> 会议组织中最令人意外的方面是必须保持乐观态度。善待你的赞助商。他们是会议的生命线。没有他们的贡献，BSDCan 不会有今天的成功。
>
> 如果你从未参加过 BSD 会议，挑一个去参加。你对自己所选的工具充满热情。去参加会议，结识志同道合的人。你建立的关系对你和你所选的项目都极有益处。没有什么能替代面对面的交流。

关于 Dan 的最后一点，我再赞同不过。参加 BSDCan 这样的会议所建立的关系，在你亲身体验之前很难完全理解其价值。许多用户对参加会议有所迟疑：有时他们觉得内容会超乎自己理解，或担心开发者会因为他们只是用户而看不起自己，或担心如果在社区里撞见某位名人不知该说什么。但新与会者很快会发现什么？把过去只通过 IRC 昵称或电子邮件地址打交道的人对上脸，是一件非常酷的事；而当你坐下来共进一餐或面对面聊天时，你会发现自己之前想象的性格其实大不相同。你会发现那些所谓的名人其实非常随和，也就是另一个可以聊天的友善朋友。你会发现在不经意间提到自己遇到的一个问题，几小时后另一位与会者就提交了修复，这真是太酷了。你会发觉连续几天和一群不必向其解释 FreeBSD 是什么的人待在一起，会令人神清气爽；你会意识到，尽管你可能是你家乡唯一认识的 FreeBSD 人（不算那些你向其解释过 FreeBSD 的人），但你并不是世上唯一的 FreeBSD 人。而且可能最令人意外的是：尽管你可能觉得自己对 FreeBSD 的使用和贡献微不足道，但你真的是更大社区的一分子，其他人也真心关心你如何以及为何使用 FreeBSD。这正是大多数与会者年复一年期待参会的理由。

## 关于彩蛋的更多讨论

> Dru Lavigne 的 3/4 月专栏提到了彩蛋。其中有一句“more is less than less and less is more than more.”（more 比 less 少，less 比 more 多）。我虽同意后半句，但 **more(1)** 至少比 **less(1)** 早 4 年问世。
>
> 翻找一番后，我注意到我手上最早的 Unix **more(1)** 来自 3BSD，日期为 1979 年 11 月。最早的 **less(1)** 则发布在 mod.sources（comp.sources.unix）第 3 卷，其 `changelog` 中最早的条目为 1984 年 1 月。
>
> 我起初以为 **more(1)** 是对 AT\&T **pg(1)** 工具的谐音双关，但 3BSD 手册页中提到“MIT ITS 系统的‘more’特性”，所以这个名字可能与后者有关。
>
> ——Peter Jeremy，FreeBSD 提交者（<peter@rulingia.com>）


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20140506-wang-luo/this-month-in-freebsd.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.