> 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/2014-0304-pkg-8/this-month-in-freebsd.md).

# FreeBSD 本月动态

* 原文：[This Month in FreeBSD](https://freebsdfoundation.org/wp-content/uploads/2014/03/this-month-in-freebsd.pdf)
* 作者：**Dru Lavigne**

FreeBSD（和其他 BSD）社区的许多人都会在日历上把五月标记出来，作为一年一度前往加拿大渥太华参加 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 的组织，主要出于两个原因：
>
> 1. 减轻我的工作量
> 2. 确保 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 卷，其变更日志中最早的条目是 1984 年 1 月。
>
> 我起初以为 `more.1` 是对 AT\&T 的 `pg.1` 工具的谐音双关，但 3BSD 的手册页中提到“the ’more’ feature of the ITS systems at MIT”（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/2014-0304-pkg-8/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.