FreeBSD 2016 年第二季度状态报告
引言
现在可以查看：2016Q2 版本的 FreeBSD 项目状态报告！
这一季度相比之前的版本带来了多个令人兴奋的改进。不同团队的贡献、像稳健互斥锁和对 GELI 完整磁盘加密支持这样的新功能得以引入。你还会发现图形支持的扩展，涉及芯片组层面和窗口管理器层面的改进，同时许多待处理功能也在持续开发中。
也许最令人兴奋的是，在项目背后你会发现一个全新的核心团队。
不要再等了，今天就体验一下 FreeBSD 吧。
——Michael W. Lucas
请在 10 月 7 日之前提交 2016 年第三季度的状态报告。
联系方式：IRC 管理团队 <irc@FreeBSD.org>
联系方式：Kubilay Kocak <koobs@FreeBSD.org>
联系方式：Eitan Adler <eadler@FreeBSD.org>
FreeBSD IRC 管理团队负责管理 FreeBSD 项目在 freenode IRC 网络上的存在，主要工作包括：
在官方命名空间内注册和持续管理频道 (#freebsd*)。
与 freenode 员工沟通。
为用户分配 freebsd 主机掩码 (hostmask)。
提供一般用户支持。
为了促进 FreeBSD 社区所有成员的建设性和积极环境，IRC 管理团队在过去 3-9 个月中确立并巩固了频道管理的一致基准。本报告总结了迄今为止完成的工作和未来的计划。
过去几个季度完成的工作包括：
注册了 FreeBSD 小组联系人 (GC) 与 freenode 员工。有关详情，请参见 小组注册页面。
创建了 FreeBSD NickServ 账户，作为
#freebsd*命名空间频道的主要所有者/创始人。主要频道由 FreeBSD 项目拥有并管理的通用 FreeBSD 账户拥有/创建。
在 Bugzilla 中创建了
Services::IRC组件，用于变更请求和问题报告。获取了所有匹配
#freebsd*命名空间的注册 freenode 频道报告，并评估了列表中的当前所有权和活动状态。为请求的用户分配了
freebsd/用户掩码。有关更多信息，请参见 IRC Cloaks。获取了所有现有
freebsd/*用户掩码的昵称和账户报告。与 freenode 员工沟通，了解即将对 freebsd 频道进行的更改。
接下来几个季度的目标是：
完成所有
#freebsd*频道创始人所有权的转移。我们将联系现有频道创建者——这些人中有项目成员，也有非项目成员——使用已知的联系信息或其注册 NickServ 账户中的联系信息，启动频道所有权转移。如果无法获取现有频道所有者的联系信息，或在适当时间内未收到回复，IRC 管理团队将与 freenode 员工合作完成所有权转移。注销不再使用或不活跃的
#freebsd*频道。那些没有明显活动迹象的频道（如最后活跃时间或注册所有者的最后出现），已被其他频道取代，或者没有其他办法完成所有权转移的频道，将被注销。对于可能需要“过渡期”的频道，将设置频道话题，并可选地设置转发频道，通知用户有关更改的情况，包括支持和联系方式。创建并记录基准程序和指南，包括：社区和用户指南、行为准则、操作员和版主指南与期望、滥用报告和争议解决指南，以及频道管理委派程序。
标准化并重新创建频道访问列表。所有
#freebsd*频道现有的访问列表和用户权限将保持在 FreeBSD 小组注册之前的状态，需要进行整合并重新分配给 FreeBSD 项目。为了确保未来官方 FreeBSD 频道的用户和社区体验一致，所有频道的访问列表将从头开始创建。对于已经有频道访问权限的用户，IRC 管理团队将根据其酌情决定，提供重新申请访问权限的机会，前提是符合适当的条件、条款或指南。确定告知项目成员和社区未来 IRC 服务、程序和政策变更的方法。
确定方法，将现有频道创始人指定为频道管理者或类似角色。
更新 Wiki 上的频道列表，区分官方和非官方频道。
为所有频道建立一致的模式、入口消息和话题。
用户被邀请加入 freenode IRC 网络上的 #freebsd-irc 频道。IRC 管理团队欢迎任何建议、建设性批评和反馈，帮助 FreeBSD 项目改善其为社区提供的服务和体验。
虽然更广泛的社区成员大多在 freenode IRC 网络上互动，但 FreeBSD 开发人员的参与度还需要大幅提高。
增加 FreeBSD 用户和开发人员之间互动的数量和质量，将为我们带来许多机会，既有助于开发人员保持与社区的联系，也能鼓励和培养更多长期为项目做出贡献的人员。
开发人员在用户中的存在至关重要，IRC 管理团队希望所有开发人员都能加入 FreeBSD freenode 频道，支持这种存在。我们是 FreeBSD 巨人，未来的贡献者将站在我们的肩膀上。我们要在那里，强势出现。
联系方式：Vladimir Krstulja <vlad-fbsd@acheronmedia.com> 联系方式：Kubilay Kocak <koobs@FreeBSD.org> 联系方式：Bugmeister <bugmeister@FreeBSD.org>
自从在 2015 年 10 月至 12 月报告中引入问题分类团队以来，团队已经在以下三个主要方面进行工作：
招募和培训更多用户协助问题分类。
识别问题领域，尤其是从新手的角度来看，揭示那些对有经验的贡献者不明显的问题。
提出改进问题分类流程的变更建议。
我们的努力几乎完全集中在“Ports & Packages”组件中的问题，因为这是最容易入手的起点。像“Base System”这样的问题类别需要更多的知识和对问题内容及工作流程的经验。
在此期间，由于 Rodrigo 没有空闲时间，他未能参与，Vladimir 在第一季度也未能投入足够的时间，但在第二季度做出了积极贡献。显而易见，问题分类团队在接下来的季度必须集中精力进行更多招募。
在过去两个季度，团队识别出多个问题，已形成的解决方案将在我们即将发布的 Wiki 页面上公布。以下是这些问题的总结：
问题分类，定义为“确保问题被总结、分类并分配给适当人员”，耗时过长。通过自动分配的 Bugzilla 自动化有所帮助，但仍然不足。如果分类过程扩展到包括“跟踪问题直到解决”，所需的时间和精力将呈指数级增长。幸运的是，社区可以做很多事情，通过最小的努力来大大帮助问题跟踪和问题解决。招募和教育过程的一部分是教育用户如何妥善处理自己和他们接触的其他问题，以最大化问题跟踪和解决的效率。
各种超时设置不足。例如，维护者超时设置过长，并未区分问题类别，如非安全性问题和安全性问题的超时。其他超时设置也没有覆盖，如分配者超时，指派问题后没有后续活动。另一个例子是当请求附加信息但未提供时的超时。我们将推荐几个变更，并将在我们的 Wiki 中记录这些内容。
部分由于超时设置不足和未能有效地跟踪问题整个生命周期的能力，许多问题的开放时间过长。我们已经识别出几类此类问题，并将在不久的将来记录每类问题的解决方案。
Bugzilla 并不完美，有时它会妨碍我们有效清晰地跟踪问题，以便快速解决。然而，改变问题追踪软件需要巨大的努力，因此我们将推荐技术和工作流程上的改进，以尽可能改善用户体验。例如，我们识别出额外的保存搜索，以帮助跟踪和快速找到问题类别， 更重要的是，它们的状态。另一个例子是确保各种标记和关键字不含糊，并且易于理解。例如，
patch和patch-ready经常被误解和错误应用。问题统计数据缺乏，下一季度我们计划改变这一点。统计数据有助于提供潜在瓶颈的洞察，并为问题追踪器和工作流程的改进提供优先级参考。
待办事项
向团队招募更多合适的问题分类人员，包括提交者和社区成员。
收集并展示下一报告中的一些有趣的统计数据。
设置 Wiki 页面，列出已识别的问题以及推荐的指南和政策。
寻找常见的使用模式，并向 Bugzilla 添加更多的保存搜索。
联系方式：FreeBSD 发布工程团队 <re@FreeBSD.org>
FreeBSD 发布工程团队负责制定和发布 FreeBSD 官方项目发布的时间表，宣布代码冻结，并维护相关分支等工作。
FreeBSD 发布工程团队在 4 月底完成了 10.3-RELEASE 的发布周期，由 Marius Strobl 领导。该发布比原定时间晚了一周，以解决几个临时的关键问题，这些问题在最终发布中必须修复。
FreeBSD 11.0-RELEASE 发布周期于 5 月底开始，比原定时间晚了一个月。发布延迟主要是为了适应将 FreeBSD 基本系统与 pkg(8) 工具打包的工作。然而，随着这一工作的进展，发现问题过多。因此，打包基本系统将作为 11.0-RELEASE 的 "beta" 功能，目标是在 11.1-RELEASE 中将其提升为一项一流功能。预计将采取措施，确保从较旧的支持版本无缝过渡。
尽管打包基本系统不会成为 FreeBSD 11.0-RELEASE 的主要功能，发布工程团队仍然感谢所有测试人员、提供补丁、提出想法和反馈的人员，甚至有些人在遇到 bug 时受到了影响。
该项目由 FreeBSD 基金会赞助。
联系方式：René Ladan <portmgr-secretary@FreeBSD.org> 联系方式：FreeBSD Ports 管理团队 <portmgr@FreeBSD.org>
2016Q3 版本的 Ports 当前包含超过 26,100 个 Port，PR 数量约为 2,000 例。其中，约有 425 个没有分配。活动有所下降，共有 125 名活跃提交者进行了 5,300 次提交。在上个季度，约有 1,760 个 PR 被关闭。
在上个季度，我们增加了两名新的提交者：Ben Woods（woodsb02）和 Torsten Zählsdorff（tz）。没有保留任何提交权限。
在管理方面，mat 接手了 cluster admin liaison 的角色，接替了决定从 portmgr 中辞职的 erwin；rene 接手了 port manager 秘书的角色，接替了 culot。没有其他变化。
大量工作已集中在现代化 Ports 的基础设施上，通过引入 6 个新的 USES 按钮、一个新关键字，并将 bsd.port.mk 中的大型目标拆分为单独的脚本。总共有 42 次 exp-run 验证这些和其他基础设施变更以及软件包更新。此外，还在 Poudriere 的质量保证阶段增加了检查，以检测缺失的间接依赖项，并取得了可重复软件包构建的进展。
一些显著的软件包更新包括：Firefox 47.0.1、Firefox ESR 45.2.0、Thunderbird 45.1.1、Chromium 51.0.2704.106、Ruby 2.2.5、Ruby Gems 2.6.2、pkg 1.8.6、gmake 4.2.1、KDE 4.14.10、Python 2.7.12、libc++ 3.8.0 和 binutils 2.26。
在幕后，antoine 确保了 exp-run 和软件包构建者始终保持最新。bdrewery 进一步自动化和加强了软件包构建基础设施。
在 BSDCan 期间，mat 完成了多项工作，包括更新 Porter 手册，portmgr 召开了会议讨论各种事项。
联系方式：FreeBSD 核心团队 <core@FreeBSD.org>
核心团队第二季度的亮点是定期的每两年一次的新核心团队选举。核心团队感谢 Dag-Erling Smørgrav 和 Glen Barber 负责投票事宜。尽管最初提名的反应较慢，但最终有十四名候选人参选，其中包括四名现任核心成员。第九届 FreeBSD 核心团队成员为：
John Baldwin
Baptiste Daroussin
Allan Jude
Ed Maste
Kris Moore
George V. Neville-Neil
Benedict Reuschling
Benno Rice
佐藤広生
新核心团队感谢即将离任的成员们多年的贡献。辞职成员包括：
Gavin Atkinson
Gleb Smirnoff
David Chisnall
Robert Watson
Peter Wemm
本季度第二个最值得注意的成就，是解决了多年来核心团队议程上的一项问题。随着 planet.FreeBSD.org 的创建，FreeBSD 项目终于有了一个官方的博客聚合服务。
核心团队花了大量时间审查许可，并确保 FreeBSD 源代码不受繁琐许可条款的限制。本季度批准了 Adrian Chadd 的计划，允许导入 GPLv2 许可的代码，使 bwn(4) 能作为可加载模块构建，并支持 802.11n 网络。这需要确认最新的 dummynet AQM 补丁的许可条款是可以接受的，并且其基于 BSD 2-clause 许可证的变体适合用于 FreeBSD 基本系统。
核心团队申请并获得了 JetBrains 静态分析工具套件的项目级许可，按 Mathieu Previot 的要求。
核心团队的另一个重要职能是确保开发人员之间的良好关系。为此，核心团队成员对撤销与 OpenSSH 相关的争议补丁提供了监督，并采取措施平息了矛盾情绪。
本季度，核心团队发出了通常的温和提醒，避免使用过激语言和其他不利行为。核心团队还对某些邮件列表上出现的死亡威胁做出了立即回应。肇事者立即被禁止访问邮件列表，并报告给了其邮件服务提供商。如果该人被发现重新加入并使用不同的别名，将会被再次移除。
其他活动包括：
与大学当局合作，试图获得证明一位有意参与谷歌编程之夏学生是否被合法允许作为在美国大学注册的外国学生为 FreeBSD 代码工作。最终，该问题通过该学生在暑假回国并从那里工作解决。
发布关于强制提交或使用琐碎更改作为修正提交信息的政策指导。在这些情况下，正确的方法是撤销提交并重新提交带有正确信息的提交。这确保了 svn blame 的持续有效性。
批准推迟计划中的打包基础引入，并确认这不需要对将随 11.0-RELEASE 引入的新支持政策进行任何变更。
本季度，共发放了四个新的提交权限，没有撤销任何提交权限。欢迎 Emmanuel Vadot、Landon Fuller、Mike Karels 和 Eric Badger 成为新的 src 提交者。是的，正是曾经是 Berkeley CSRG 成员并共同撰写《4.3BSD UNIX 操作系统的设计与实现》一书的 Mike Karels。
联系方式：Deb Goodkin <deb@FreeBSDFoundation.org>
FreeBSD 基金会是一家 501(c)(3) 非营利组织，致力于支持和推广全球 FreeBSD 项目和社区。资金来自个人和企业捐赠，用于赞助和管理开发项目、会议和开发者峰会，并为 FreeBSD 开发者提供差旅赞助。基金会购买硬件以改进和维护 FreeBSD 基础设施，并发布 FreeBSD 白皮书和营销材料，以推广、教育和倡导 FreeBSD 项目。基金会还代表 FreeBSD 项目执行合同、许可协议和其他需要合法实体的法律安排。
以下是我们上个季度帮助 FreeBSD 的一些亮点：
筹款工作
我们的工作完全由你的捐赠赞助。我们 2016 年的预算为 $1,250,000，到目前为止我们已筹集到 $265,000。我们的 Q1-Q2 财务报告将在 8 月 1 日之前发布。如你所见，我们需要你的捐赠来继续以当前水平支持 FreeBSD。请考虑在此捐赠：freebsdfoundation.org/donate。
操作系统改进
基金会通过赞助通过提案提交流程批准的软件开发项目以及我们内部的软件开发人员来改进 FreeBSD。两项由基金会赞助的项目在上个季度继续进行；一个项目旨在改善 vnet 网络堆栈虚拟化基础设施的稳定性，第二个是 FreeBSD/arm64 移植项目的第二阶段。
基金会工作人员负责了许多变化。Kostik Belousov 在上个季度完成了以下工作：实施了稳健的互斥锁支持，这是将我们的线程库带入 POSIX 合规性和功能完整性的持续努力的一部分；记录了线程库使用的内核接口，并生成了近 30 页的技术文档；完成并提交了从 amd64 pmap 中删除 pvh_global_lock 的工作，从而移除了一个热争用的锁；修复了帮助保持 FreeBSD 稳定和可靠的错误。
Edward Napierala 在上个季度完成了以下工作：为 RCTL 添加了文件系统吞吐量限制；提交了 iSER 启动器支持；添加了对 NFS 重新挂载的支持；并添加了 iscsictl -e，使其能够启用和禁用 iSCSI 会话。
我们的项目开发总监 Ed Maste 在上个季度完成了以下工作：调查了 Ports 中可重复构建的状态，并正在处理一些问题；更新了 ELF 工具链工具，修复了错误并改进了对格式不正确输入的处理；调查了使用 LLVM 系列的链接器 lld 来链接 FreeBSD 基本系统；报告并测试了发现的问题的补丁。他还管理了 arm64 开发项目，调查并修复了多个错误。最后，他导入了 LLVM 的 libunwind，并为在 FreeBSD 11 中使用做了准备，还调查并审查了 blacklistd 提案和补丁。
George Neville-Neil 继续主持每两周一次的传输会议电话（笔记在 https://wiki.FreeBSD.org/TransportProtocols）和每两周一次的 DTrace 会议电话（笔记在 https://wiki.FreeBSD.org/DTrace）。
Ed 继续促进每两周一次的图形会议，以协调 i915 驱动程序和其他图形堆栈的工作。
这些项目中的一些在本季度报告的其他部分有说明。
发布工程
基金会员工兼发布工程师 Glen Barber 与 Marius Strobl 密切合作，完成了 10.3-RELEASE 的工作，并于四月发布。Glen 还将 release-pkg 分支合并到 11-CURRENT，但这将在 11.0-RELEASE 中作为测试功能。最后，他与发布工程团队一起启动了 11.0-RELEASE 周期。有关更多信息，请参阅本报告中发布工程团队的状态条目。
“开始使用 FreeBSD”项目
我们聘请了一位暑期实习生，他没有 FreeBSD、Linux 及一切命令行操作系统的经验，独立研究如何安装和使用 FreeBSD。他正在编写易于跟随的操作指南，帮助让新用户的体验变得简便和积极。他还通过适当的渠道提交了 bug 报告和问题。你可以查看他编写的第一篇操作指南：https://www.freebsdfoundation.org/freebsd/how-to-guides/。
FreeBSD 倡导与教育
我们的大部分努力致力于为项目进行倡导。这包括推广其他人使用 FreeBSD 所做的工作；制作宣传材料以教授人们关于 FreeBSD 的知识，并帮助让开始使用 FreeBSD 或为项目做贡献的过程更容易；以及参加并鼓励其他 FreeBSD 贡献者志愿组织 FreeBSD 相关活动、管理 FreeBSD 展位、并做 FreeBSD 演讲。
我们上个季度支持 FreeBSD 倡导的一些工作包括：在我们的网站上创建了一个 FreeBSD 页面，以推广 FreeBSD 衍生项目并展示 FreeBSD 用户（https://www.freebsdfoundation.org/freebsd/），以及通过创建一个研究页面和会议手册来推广 FreeBSD 研究（https://www.freebsdfoundation.org/what-we-do/research/）。
我们创建了使用项目和基金会徽标的指南和一个代码库（https://www.freebsdfoundation.org/about/brand-assets/）。
为了展示 FreeBSD 贡献者，我们发布了两篇新的《FreeBSD 面孔》故事，分别是关于 Michael Lucas（https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-michael-lucas/）和 Kris Moore（https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-kris-moore/）。
我们发布了三月/四月和五月/六月的《FreeBSD 期刊》，并参与了编辑委员会的工作。Kirk McKusick 为三月/四月期撰写了关于快速文件系统的专题文章，其他团队成员帮助审查和编辑期刊文章。
我们还发布了每月通讯，突出展示了为支持 FreeBSD 所做的工作，告知你即将举行的活动，并提供其他信息，帮助你了解我们为支持 FreeBSD 项目和社区所做的努力。
George Neville-Neil 和 Robert Watson 继续在 teachbsd.org 开发和教授开源 FreeBSD 教学材料。
我们推出了首个托管合作伙伴聚焦，展示了 FreeBSD 项目与 NYI 的合作（https://www.freebsdfoundation.org/blog/hosting-partner-spotlight-nyi-at-the-heart-of-freebsd/）。
我们与微软合作，将 FreeBSD 带入 Azure（https://www.freebsdfoundation.org/blog/more-from-the-freebsd-foundation-on-the-projects-partnership-with-microsoft/）。
基金会在 Cavium 的 Thunder X2 新闻稿中被引用（http://www.prnewswire.com/news-releases/cavium-announces-thunderx2-300276536.html）。
George 与 ARM 合作协调即将在剑桥举行的 ARM 合作伙伴会议。
会议与活动
FreeBSD 基金会赞助了全球许多会议、活动和峰会。这些活动可以是与 BSD 相关的、开源的，或是面向弱势群体的技术活动。
我们支持 FreeBSD 相关的活动，帮助提供分享知识的平台，促进项目合作，并促进开发者与商业用户之间的协作。这一切都有助于提供一个健康的生态系统。我们也支持非 FreeBSD 活动，以推广和提高对 FreeBSD 的认知，增加 FreeBSD 在不同应用中的使用，并招募更多的贡献者。
在四月，Benedict Reuschling 帮助组织并主持了四月 22-24 日在埃森的黑客马拉松。随后，他与 Allan Jude 一起参加了在柏林举行的开源数据中心会议，并就“使用 ZFS 可以做的有趣事情”进行了演讲，重点介绍了 OpenZFS 特性以及它们在 FreeBSD 上的表现（https://www.netways.de/index.php?id=3445#c44065）。
我们在以下活动中推广了 FreeBSD：
Flourish — 四月 1-2 日在芝加哥（http://flourishconf.com/2016/）
LFNW — 四月 23-24 日在华盛顿贝灵汉（https://www.linuxfestnorthwest.org/2016）
OSCON — 五月 18-19 日在奥斯汀，德克萨斯（http://conferences.oreilly.com/oscon/open-source-us）
Deb Goodkin 和 Dru Lavigne 参加了五月 14-15 日在奥斯汀举办的社区领导力峰会（http://www.communityleadershipsummit.com/schedule/）。
Deb 在六月 22-23 日在科罗拉多州丹佛的 USENIX ATC 上推广了 FreeBSD。
我们的团队参加了 BSDCan 和渥太华开发者峰会。我们举行了年度董事会会议，投票选举官员和董事会成员，并进行战略规划工作。大多数成员参加了开发者/供应商峰会。Kirk McKusick 在 BSDCan 上做了题为“BSD 快速文件系统简史”的演讲（http://www.bsdcan.org/2016/schedule/events/654.en.html）。Ed Maste 做了题为“FreeBSD 中的可重复构建”的演讲。George 协助举办了供应商峰会。
我们赞助了五位 FreeBSD 贡献者参加 BSDCan。
法律/FreeBSD 知识产权
基金会持有 FreeBSD 商标，并且我们有责任保护这些商标。我们继续审查请求，并授予使用商标的许可。
FreeBSD 社区参与
我们启动了首次社区调查。目的是从社区获取反馈，了解他们为什么使用 FreeBSD，他们希望基金会支持哪些方面，以及其他有助于我们确定方向和如何支持项目的意见。
我们的市场营销总监 Anne Dickison 一直在监督项目行为准则的重写工作，旨在帮助使社区变得更加安全、包容和欢迎。
我们做的其他工作
上个季度，我们购买了一台服务器，部署在 NYI，以改进项目中的持续集成工具。
我们在上个季度举行了两次面对面的董事会会议，讨论战略规划并确定项目中需要支持的领域。
我们还首次举行了员工团建活动，地点位于科罗拉多州博尔德，给我们的小团队提供了一个亲自合作的机会。
我们聘请了 Sabine Percarpio 作为行政经理，她帮助我们管理捐款、会计、旅行赞助申请、处理基金会收到的问题，并确保组织的顺利运作。
项目
联系人：Konstantin Belousov <kib@FreeBSD.org>
这是关于我在 FreeBSD 基本系统中对 ASLR（地址空间布局随机化）支持工作的技术状态的临时报告。
proccontrol(1) 工具已编写完成，用于在每个进程基础上管理和查询 ASLR 强制执行情况。它对于分析特定程序中的 ASLR 故障是必需的。此工具利用了先前版本补丁中添加的 procctl(2) 接口，并进行了 bug 修复。
在 r300792 中，每当执行一个 setuid 二进制文件时，ASLR 设置会重置为系统范围的默认值。
命令语法如下：
其中可用的参数为：
-m（指定用于控制调试器附加的跟踪模式）-q（查询指定模式下的进程状态，通过-p选项指定 PID）-s（切换给定进程或自身的功能开关）
如果指定了命令，它会继承 proccontrol 中应用的设置。例如，要禁用 ASLR 并启动程序构建，可以使用 proccontrol -m aslr -s disable make。
进行了一个使用最激进设置调整 ASLR 的 Port 扩展测试。结果可以在 PR 208580 中找到。
案例研究：Lisp
SBCL 是一个有趣的案例，展示了几个要点。它比 JDK 小得多，且其构建系统更容易操作。该代码提供了一个非常非 C 风格的语言运行时，利用了许多边缘情况，并且以非常规的方式使用了虚拟机系统，至少从典型 C 程序员的角度来看。
SBCL 将 Lisp 表达式编译为机器本地代码，并管理自己的对象区域。预编译的 Lisp 运行时从核心文件中映射。SBCL 依赖操作系统的 C 运行时来加载 Lisp，并且需要一个功能齐全的 libc 来执行许多系统调用，包括系统调用，以及动态加载器。最终结果是，在启动和运行时存在未修复的 mmap(2) 调用，这会干扰其他的 MAP_FIXED mmap 调用。核心文件的加载和私有区域被硬编码为固定地址。
这在默认的地址映射中有效，因为该映射不常变化，所以 SBCL 选择的基地址得以生效。但是，任何对标准映射的显著扭曲都会导致 SBCL 的 mmap(MAP_FIXED) 请求尝试覆盖其他分配器的内存。
FreeBSD 使用 MAP_EXCL 标志进行 mmap(2) 调用，必须以 MAP_FIXED|MAP_EXCL 的形式使用，才能使 mmap(2) 在请求的范围已被使用时失败。我尝试强制 SBCL 的 MAP_FIXED 请求隐式设置 MAP_EXCL，但效果不佳，因为 SBCL 有时会预先分配区域以便后续使用 MAP_FIXED。因此，MAP_EXCL 映射失败，导致进程陷入 ldb。
在 Linux 上，如果检测到内核处于 AS 随机化模式，初始 SBCL 运行时会将其个人属性设置为非随机并重新执行。这个方法可能也适用于 FreeBSD，待 ASLR 补丁提交后，以便 procctl(2) 钮已正式可用。
即使在 Linux 上重新执行，SBCL 仍然存在问题，尤其是当应用了来自 PaX 补丁的更激进随机化时，如在 bug 1523213 中所见。
案例研究：Emacs
Emacs 构建过程涉及加载包含已编译 Emacs Lisp 文件的 temacs 镜像，然后转储其内存以创建一个包含预加载内容的映像，从而减少启动时间。
最近的 Emacs 源代码似乎通常避免使用 MAP_FIXED，除了在某些情况下。当 Emacs 确实使用该标志时，它会小心检查所选区域是否已经被占用。实际上，Emacs 如果使用 MAP_EXCL 会更有利。
我尝试了几次构建 Emacs 并运行转储的二进制文件，但未能重现任何问题。看来代码已经改进到足以在 Linux 和 NetBSD 上容忍 ASLR，而无需关闭它。
在我看来，解决内核中的问题是不合理的，因为大多数问题从内核侧无法修复。procctl(2) 接口和 proccontrol(1) 工具提供了必要时的覆盖机制，但这并非自动化。
结论
不能在启用 ASLR 的情况下构建的 Ports 应该是有限的但灵活的。然而，exp-runs 可能无法可靠地揭示所有由随机化引起的问题，如在 Emacs 示例中所见。在默认启用 ASLR（使用非激进设置）的过程中，Port 框架应该提供类似 ASLR_UNSAFE=yes 的选项，用于在不安全 Port 的构建阶段启动 proccontrol -m aslr -s disable make。用户仍然需要了解 proccontrol(1) 以便运行生成的二进制文件或提供的包装脚本。
推荐的方法是在 ELF 二进制文件中添加一个标志，标记该文件与非标准 AS 布局不兼容。这将免去用户使用 proccontrol(1) 的需要，但仍然要求修补应用程序的构建过程并将更改提交给上游。此方法也适用于 ASLR 以外的场景。然而，该机制尚未就绪，其开发工作量比 ASLR 本身还要大。
该项目由 FreeBSD 基金会赞助。
联系人：Willem Jan Withagen <wjw@digiware.nl>
Ceph 是一个分布式对象存储和文件系统，旨在提供卓越的性能、可靠性和可扩展性。它提供以下功能：
对象存储：Ceph 提供通过原生语言绑定或 radosgw 访问对象，radosgw 是与为 S3 和 Swift 编写的应用程序兼容的 REST 接口。
块存储：Ceph 的 RADOS 块设备（RBD）提供对跨整个存储集群条带化和复制的块设备映像的访问。
文件系统：Ceph 提供一个符合 POSIX 标准的网络文件系统，旨在实现高性能、大规模数据存储，并与遗留应用程序实现最大兼容性。
我开始研究 Ceph，是因为使用 HAST 与 CARP 和 ggate 无法满足我的需求。我的主要目标是运行一个 ZFS 存储节点的存储集群，客户端在 Ceph 中存储的 RBD 磁盘上运行 bhyve。
FreeBSD 构建过程可以构建 Ceph 中的大多数工具。然而，依赖于 RBD 的项目无法正常工作，因为 FreeBSD 目前尚不提供 RBD 支持。
自上次季度报告以来，取得了以下进展：
转向使用 CMake 而不是 Automake，结果开发环境更加简洁，测试输出更好。相关更改可以在 wip-wjw-freebsd-cmake 分支中找到。
对节流代码进行了重构，以防止死锁。这些问题主要出现在 FreeBSD 上，但在 Linux 上也有表现。
修复了更多的测试。在某次尝试中，我成功完成了整个测试套件，没有错误。
11-CURRENT 用于编译和构建测试 Ceph。Clang 工具集至少需要版本 3.7，因为 stable/10 上的 Clang 3.4 不具备编译所有内容所需的能力。
此设置将使 Ceph 在 FreeBSD 上运行：
安装 bash 并在 /bin 中创建链接（需要 root 权限）：
构建 Ceph：
参数 --deps 仅在初次安装时需要，用于拉取必要的依赖；后续构建时应省略。
现在，Ceph 在 FreeBSD 上使用 CMake 构建；不再使用旧的 Automake 方法。
尚未包括的部分：
RBD：Rados 块设备目前在 Linux 内核中实现，但曾有过用户空间的实现。ggated 可能作为模板使用，因为它提供了类似的功能，并且具有用户空间对应部分。
BlueStore：FreeBSD 和 Linux 有不同的 AIO API 需要进行桥接。曾有一些关于 FreeBSD 中 aio_cancel 无法适用于所有设备类型的讨论。
CephFS：Cython 尝试访问 struct dirent 内部字段，导致编译失败。
测试：验证这些功能是否正确的测试也被排除在测试套件之外。
尚未包括的测试：
ceph-detect-init/run-tox.sh：当前实现不了解 FreeBSD 的 rc 系统。
使用 nosetests 的测试无法正常工作，因为 nosetests 不在 /usr/bin 中，且调用
/usr/bin/env nosetests在 FreeBSD 上无法正常工作。test/pybind/test_ceph_argparse.py
test/pybind/test_ceph_daemon.py
待办事项
当前最紧迫的任务是使测试套件能够完成且无错误。
构建一个自动化测试平台，能够在 FreeBSD 上构建 ceph/master，并将结果报告给 Ceph 开发人员。这将增加 FreeBSD 端的可维护性，因为开发人员会意识到他们正在使用 Linux 专用的功能，这些功能无法在 FreeBSD 上编译或运行。Ceph 有多个项目支持这一点：Jenkins、teuthology 和 palpito。但即使是一个简单的编译循环，将构建数据报告到静态网页，也是一个不错的开始。
运行集成测试，查看 FreeBSD 守护进程是否能够与 Linux Ceph 平台一起工作。
使当前被排除的 Python 测试能够工作。
编译和测试用户空间 RBD（Rados 块设备）。
调查是否可以开发一个类似于 ggate 的内核中的 RBD 设备。
调查当前阻止 CephFS 构建的密钥存储系统和其他部分。
将 FreeBSD 的
/etc/rc.d初始化脚本集成到 Ceph 堆栈中，以便进行测试和在生产机器上运行 Ceph。
联系人：Eric McCorkle <eric@metricspace.net>
EFI 启动加载器经过了大量重构，以便更多地利用 EFI API。boot1 中的文件系统代码已被移除，现在一个统一的代码库用于 boot1 和 loader 的文件系统。这些代码围绕 EFI 驱动程序模型组织，现在应该可以将任何文件系统实现导出为独立的 EFI 驱动程序，且不需要过多的努力。
boot1 和 loader 都已重构，以利用 EFI_SIMPLE_FILE_SYSTEM 接口。在 loader 中，这是通过一个虚拟的文件系统驱动程序实现的，它只是一个在 loader 文件系统接口和 EFI_SIMPLE_FILE_SYSTEM 之间的转换层。一个反向转换层使现有的文件系统驱动程序能够作为 EFI 驱动程序运行。
EFI 的重构本身存在于一个 GitHub 分支中。
此外，使用 EFI 重构添加了 GELI 支持。这使得从 GELI 加密的文件系统启动成为可能。请注意，EFI 系统分区，其中包含 boot1，必须是一个明文的 msdosfs 分区。此补丁向加密框架添加了一个输入缓冲区，允许将密钥直接注入已加载的内核，而无需通过参数或环境变量传递。该补丁仅为 EFI GELI 支持使用输入缓冲区，因为遗留的 BIOS GELI 支持仍然使用环境变量。
EFI GELI 支持依赖于 efize 分支。
这些补丁已被测试并使用，应该能够处理早期采用者的使用。请注意，LOADER_PATH 变量已更改为 /boot/loader.tst，以便进行安全测试。
重要提示： 由于这是一个加密文件系统补丁，错误可能导致数据无法访问。强烈建议按以下步骤进行测试：
备份数据！
不要忘记备份数据！
在 EFI 系统分区（ESP）上安装 EFI shell。
将补丁后的 boot1 安装到 ESP，例如 ``/boot/efi/BOOTX64.TST`。
将补丁后的 loader 安装到机器上的
boot/loader.tst。在正常的启动分区外创建一个 GELI 分区。
首先，尝试启动
/boot/efi/BOOTX64.TST，确保它能够正确处理加密分区。将一个启动环境（包括补丁后的 loader）复制到加密分区。
使用 loader 提示符从加密分区加载内核。
待其他一切正常工作，尝试切换到加密的主分区。
待办事项
需要进行测试。
代码需要审查，并且在进入 FreeBSD 之前需要进行一些 style(9) 标准化。
联系人：Konstantin Belousov <kib@FreeBSD.org> 联系人：Ed Maste <emaste@FreeBSD.org>
现在，进程共享锁已经为我们的 POSIX 线程实现 libthr 实现，唯一缺少的主要特性就是健壮的互斥锁。健壮的互斥锁允许应用程序在修改共享状态时检测到崩溃，并在理论上从崩溃中恢复。支持的模型是通过 pthread_mutex 保护共享状态，并且在拥有该互斥锁时检测到线程终止。线程可能单独终止，或者由于包含的进程终止而被杀死。因此，健壮的属性适用于进程私有和共享互斥锁。
应用程序必须特别修改以处理和恢复故障。pthread_mutex_lock() 函数可能会返回一个新的错误 EOWNERDEAD，表示上一个锁的所有者在仍持有锁的情况下终止。尽管返回了这个非零值，但锁仍会授予调用者。在最简单的形式中，应用程序可以检测到该错误，并在持久共享数据恢复之前拒绝操作，例如通过手动重新初始化。更复杂的应用程序可以尝试自动恢复此状态，在这种情况下，必须在解锁之前调用 pthread_mutex_consistent(3) 进行锁的一致性检查。然而，这种恢复可以认为是非常困难的。尽管如此，甚至检测到不一致的共享状态也是有用的，因为它可以避免进一步的损坏和随机故障。
尽管这并不令人意外，但该接口并未被广泛使用。唯一在实际应用中使用该接口的应用程序是 Samba。在 FreeBSD 基本系统更新后，使用 Samba 揭示了 FreeBSD 健壮互斥锁实现和 Samba 本身的轻微错误。
相信 FreeBSD 11 中的 libthr 已经符合 POSIX 的主要特性要求。接下来的工作计划是查看将锁结构内联，以减少开销并提高库的性能。
健壮性功能的实现大部分涉及在 libthr 和 kern_umtx.c 中对锁定和解锁路径进行小的修改。这实际上要求阅读所有涉及互斥锁和条件变量的代码，这是我希望帮助未来开发人员的事情。最终，在 Ed Maste 的帮助下，为 umtx(2) 和所有 thr*(2) 系统调用编写并添加了 man 页面到基本系统的文档集中。
该项目由 FreeBSD 基金会赞助。
待办事项
在实际应用中使用该实现并报告问题。
联系人：FreeBSD 图形团队 <freebsd-x11@FreeBSD.org> 联系人：Matthew Macy <mmacy@nextbsd.org>
在 Ports 中，Mesa 已更新为 11.2.2。下一个主要版本 12.0.0 的发布候选版本 4 已准备好在我们的开发树中进行测试。
关于将 /dev 条目连接到 sysctl 节点的谷歌编程之夏项目取得了进展。经过在 freebsd-arch@ 邮件列表上的富有成效的讨论后，Kiloreux 完成了设计并正在实施解决方案。关于 libdevq 的 GSoC 项目已被放弃。
所有 Intel GPU，包括未发布的 Kaby Lake，都已得到支持。将很快更新 xf86-video-intel 驱动程序。更新此驱动程序需要更新 Xorg，而更新 Xorg 被 Nvidia 更新所阻塞。
仍然存在一些问题需要解决：
有时会出现视觉伪影，出现频率因工作负载而异。特别需要注意的是，当 Qt5 窗口部分被菜单遮挡然后再被揭开时，没有重绘。
WebGL 演示有时会由于可恢复的渲染环挂起而失败。
对于 Sandy Bridge 之前的处理器（2010 年之前），仍然存在一些已知的稳定性问题。
Matt Macy 希望能够通过更新 Linux 支持，使 Intel GPU 工具在 FreeBSD 上运行，从而诊断前两个问题以及其他问题。
Radeon AMD/ATI 驱动已更新至 GCN 1.0。这仅在 R7 240 上进行了测试。2D 加速的 X 工作正常。由于用户库支持方面的问题，X 无法识别 KMS 驱动为 3D 能力，并报告其为“非 DRI2 能力”。OpenCL 基准测试 clpeak 在 drm/ttm 中失败，因此可能存在底层 3D 支持的问题。
Amdgpu AMD/ATI 驱动已更新至 GCN 1.1 及更高版本。KMS 驱动在独立 GPU 上加载并附加，尽管在 Carizzo APU 上仍存在问题。由于 libdrm 中未实现的功能，X 无法启动。Koop Mast 正在积极处理这个问题，应该很快修复。
在 FreeBSD 11 中，尚未提交所有必需的 src/sys 补丁。虽然计划最终将 linuxkpi、drm、i915、radeon 和 amdgpu 更新作为 Port 提供，但这可能要等到开发放缓到可以经济地将它们回溯到 FreeBSD 的 svn 中时才能实现。在此之前，现代 GPU 支持将仅在 PC-BSD 快照和 GitHub 上的 drm-next-4.6 分支中提供。
联系人：Jared McNeill <jmcneill@FreeBSD.org> 联系人：Emmanuel Vadot <manu@FreeBSD.org>
Allwinner SoC 被广泛应用于多个爱好者开发板和单板计算机。最近，这些 SoC 的支持进行了许多更新。
2016 年第二季度期间完成的任务包括：
切换到上游 DTS
A83T SoC 支持
H3 SoC 支持
切换到新的时钟框架
将 A10 中断控制器转换为 INTRNG
OHCI 支持
通用的 ALLWINNER 内核配置文件
A20/A31 NMI 支持
AXP209 PMU 中断、GPIO 和传感器支持
A83T 热传感器支持
RSB（简化串行总线）支持
AXP813/AXP818 PMU 支持
A83T 安全 ID 支持
支持 Allwinner 在 H3/A83T/A64 中找到的千兆以太网控制器
USB OTG (审核中)
A10/A20 安全 ID 支持 (审核中)
A13 SoC 支持 (审核中)
正在进行的工作：
A64 支持
使用 U-Boot EFI 实现支持 ARM32/ARM64
待办事项
SPI 驱动程序
LCD 支持
任何可能感兴趣的未支持硬件设备
联系人：Sepherosa Ziehau <sepherosa@gmail.com> 联系人：Hongjiang Zhang <honzhan@microsoft.com> 联系人：Dexuan Cui <decui@microsoft.com> 联系人：Kylie Liang <kyliel@microsoft.com>
在 BSDCan 2016 大会上，微软 宣布 FreeBSD 10.3 镜像在 Azure 上的全球可用性。Azure 市场中有许多基于 FreeBSD 的虚拟应用程序，包括 Citrix Systems 的 NetScaler 和 Netgate 的 pfSense。微软还做了一个深入的技术演示，介绍了如何优化 Hyper-V 网络设备驱动程序的性能，使其在 10Gb 网络上达到满速，并在 40Gb 网络上取得了良好的性能。演示的幻灯片和视频可以从 BSDCan 网站 获取。
微软继续致力于进一步优化 Hyper-V 网络和存储设备驱动程序的性能。目前正在进行的工作包括：将 LRO 内核 API 中的内部数据结构从单向链表更改为双向链表，以加快通过哈希表查找 LRO，并评估 tcp_lro_queue_mbuf() 的性能。
在 Hyper-V 存储驱动程序中，增强了 SCSI 查询的处理，以确保磁盘热插拔和 smartctl(8) 能可靠工作。有关详细信息，请参阅 PR 210425 和 PR 209443。
BIS 测试用例可以在 GitHub 上找到，分别针对 Hyper-V 和 Azure。
该项目由微软赞助。
联系人：Bjoern A. Zeeb <bz@FreeBSD.org>
VIMAGE 是一个建立在 FreeBSD jail 之上的虚拟化框架，约八年前通过 vnet 虚拟化网络栈引入内核。
近年来，许多人开始在生产环境、类似生产环境的设置以及设备中使用 VIMAGE。随着这种应用的增加，迫切需要完成工作，避免在网络栈拆除时出现 panic 以及避免内存泄漏。
vnet 拆除操作已更改为从上到下，尝试逐层拆除。这比先移除接口然后清理所有内容更为理想，因为待接口被移除，数据包将无法再流动。与此工作一起，修复了可能导致内存泄漏的各种路径。最后，vnet 支持被添加到以前未虚拟化的组件中，如 pf 和 ipfilter 防火墙以及一些虚拟接口。
该项目由 FreeBSD 基金会赞助。
待办事项
请测试 FreeBSD 11.0-ALPHA6 或更高版本。当报告问题时，请在 FreeBSD bug 跟踪系统中使用 vimage 关键字。
联系人：Andrew Turner <andrew@FreeBSD.org>
arm64 pmap 代码已更新，以支持完整的 4 层页表。这使得我们能够将用户虚拟地址空间增加到 256TB，并相应地增加内核虚拟地址空间。它还允许将 FreeBSD 可处理的物理内存大小增加到最大 2TB。
在 arm64 上，已将中断框架替换为 intrng。这使得 arm 和 arm64 可以共享中断控制器驱动程序，正如 GICv2 驱动程序的情况一样。GICv3 ITS 驱动程序已重写，以更好地与 intrng 集成。
Busdma 已更新以处理缓存。更新后的代码假定设备默认是非一致性的，除非设备驱动程序在创建 DMA 标记时将其标记为一致性。当设备树将硬件标记为一致时，通用和 ThunderX PCIe 驱动程序已更新为创建一致性映射。此工作还修复了同步操作中发现的内存屏障缺失问题。
解决了多个 hwpmc 的问题。这改善了 arm64 上 hwpmc 的稳定性，目前没有已知的软件问题。然而，有一个已知的硬件相关问题，仍需进一步测试。
NEW_PCIB 已在 arm64 上启用。包括处理 PCI_RES_BUS 资源类型。
在 FreeBSD-11 之前被替换的旧接口已从 arm64 内核和库中删除。这包括对 11.0 之前版本 libc 的兼容性支持。brk 和 sbrk 函数也已被删除。这使得可以去除 arm64 C 运行时中对这些函数的临时解决方案。
loader.efi 已更新，以使用事件定时器来实现其内部时间功能。这是必要的，因为许多 UEFI 实现不支持 GetTime 运行时服务方法。这意味着 loader.efi 现在将在自动启动前正确倒计时。
为 ARM Juno 参考平台添加了初步支持。这种硬件在 ARM 中很常见，并且在查找 cpuids 假设时非常有用。在 Juno 上启动需要修复内核，以移除假设其从 CPU 0 启动的前提。这包括分配 cpuids，并修复 GICv2 驱动程序中的假设，即 cpuid 与 GIC cpuid 相同。FreeBSD 现在可以在 Juno 主板的 4 个 Cortex-A53 CPU 上启动。需要进一步调查，找出启用 2 个 Cortex-A57 CPU 时启动失败的原因。
已开始在 Pine64 和 Raspberry Pi 3 主板上启动 FreeBSD 的初步工作。这两个板可以通过非树补丁启动到多用户模式。进一步的工作需要将这些补丁合并到主树中，但预计在代码冻结结束后不久就会完成。
该项目由 FreeBSD 基金会和 ABT Systems Ltd. 赞助。
联系人：Ed Maste <emaste@FreeBSD.org>
可重复构建是一套软件开发实践，旨在创建从人类可读的源代码到计算机使用的二进制代码的可验证路径。简而言之，思想是从相同源代码构建相同的二进制文件、软件包、文档或其他二进制制品时，产生的输出是完全相同的。reproducible-builds.org 网站提供了关于如何使构建具有可重复性的背景信息和文档。
过去十年，许多人参与了 FreeBSD src 和 Port 中的可重复构建工作。可重复构建带来了许多实际的好处，例如节省带宽和存储空间。然而，开源和自由软件社区对其的兴趣日益增长，主要是从软件和工具链的完整性角度出发。近年来，Debian 项目的一些成员主导了一项全面而有结构的可重复构建工作。
Baptiste Daroussin 和 Ed Maste 参加了去年在雅典举行的第一次可重复构建峰会。从那时起，Ed 调查了 FreeBSD Ports 中的构建可重复性，并在 BSDCan 2016 上展示了《FreeBSD 中的可重复构建》演讲。通过一些正在进行的补丁，超过 80% 的 FreeBSD Ports 构建可以实现可重复性。
Diffoscope 工具进行深入的文件、归档或目录比较，以了解为什么二进制制品无法实现可重复构建。Ed 演讲中非可重复构建的 Diffoscope 结果可通过上面的链接查看。
该项目由 FreeBSD 基金会赞助。
待办事项
将 FreeBSD Port 构建集成到可重复构建组织的持续集成基础设施中。
将可重复构建补丁集成到 Ports 中。
调查单个 Port 中导致不可重复构建的原因。
联系人：John Baldwin <jhb@FreeBSD.org> 联系人：Luca Pizzamiglio <luca.pizzamiglio@gmail.com>
devel/gdb Port 已更新至 GDB 7.11.1。
系统调用捕获点的支持已提交到上游。通过 info auxv 来检查 ELF 辅助向量数据的支持已提交到上游。两项功能将包含在 GDB 7.12 中。
待办事项
查明为何 powerpc kgdb 目标无法展开初始栈帧之外的栈。
为更多平台（如 arm、mips 和 aarch64）添加对用户空间和 kgdb 的支持。
添加对调试 powerpc 向量寄存器的支持。
添加对
$_siginfo的支持。实现
info proc命令。实现
info os命令。
联系人：Rafael Espíndola <rafael.espindola@gmail.com> 联系人：Davide Italiano <dccitaliano@gmail.com> 联系人：Ed Maste <emaste@FreeBSD.org>
lld 是 LLVM 项目中的链接器，旨在成为一个高性能的链接器，支持 ELF、COFF 和 Mach-O 对象格式。在可能的情况下，lld 保持与现有的 GNU BFD ld 和 gold 链接器的命令行和功能兼容。然而，lld 的开发者并不受限于严格的兼容性要求，特别是在这会影响性能或所需功能时。
在过去的一个季度里，lld 项目实现了版本脚本支持，足以处理 FreeBSD 基本系统。这是将 lld 作为可行的系统链接器的一个重要里程碑。
然而，lld 仍然缺乏全面的链接脚本表达式评估支持，因此目前尚无法用来链接 FreeBSD 内核。
该项目由 FreeBSD 基金会赞助。
待办事项
在上游 lld 项目中开发链接脚本表达式的改进。
将更新的 lld 快照导入供应商区域，添加构建基础设施，并将其连接到世界构建，安装为 ld.lld。
请求 Port exp-run，使 /usr/bin/ld 成为 ld.lld 的符号链接。
进行广泛的测试。
联系人：Torsten Zöhlsdorff <tz@FreeBSD.org>
在 FreeBSD Ports 中存在了三个月后，GitLab 继续成熟并获得采用。大多数初始问题已经解决，目前只剩下一个已知问题：它无法在启动时启动。欢迎任何帮助解决这个问题。
与上游保持同步现在对于小版本来说很容易。然而，一些每月的主要版本通过引入大量新的依赖关系，造成了很大的工作量。这使得测试和更新成为一项昂贵的过程。
GitLab 项目本身现在提到了对 FreeBSD 的原生支持，这是一个很高的评价。
当前的工作旨在解决剩余问题，将最新的主要版本纳入 Ports，并为更新进度创建文档。
联系人：FreeBSD GNOME 团队 <freebsd-gnome@FreeBSD.org>
FreeBSD GNOME 团队维护着 GNOME、MATE 和 CINNAMON 桌面环境及图形用户界面。GNOME 3 是 GNU 项目的一部分。MATE 是 GNOME 2 桌面的一个分支。CINNAMON 是一个使用 GNOME 3 技术的桌面环境，但具有 GNOME 2 的外观和感觉。
GNOME 3.20 在 Ruslan Makhmatkhanov 和 Gustau Perez 的帮助下被移植。当前正在将 GDM 从旧的 3.16 版本更新到 3.20 版本。由于某些原因，Firefox 中的滚动条无法正常工作，但尚未进行调查。
随着 Gtk+ 3.20 的发布，主题支持再次发生变化，且这些变化不向后兼容。如果你的主题更新需要新的 Gtk+ 版本，请随时将其作为阻塞问题添加到 GNOME/Gtk+ 3.20 更新问题中。此问题将在 GNOME 3.20 准备好后用于 exp-run，并跟踪与主题相关的 Port。此外，存在一个问题，即打开和保存对话框中的内容变得不可见。
待办事项
完成 GDM 3.20 的移植。
调查为什么 Firefox 中的滚动条消失以及为什么打开/保存对话框中的内容消失。
联系人：Sergey Kozlov <sergey.kozlov@intel.com>
现在，多个适用于 Intel(R) 以太网产品的工具作为 Port 和包在 FreeBSD 上提供：
sysutils/intel-nvmupdate：用于更新基于 XL710 和 X710 网络设备的非易失性存储器的应用程序。
sysutils/intel-qcu：用于在基于 XL710 的网络设备上切换 QSFP+ Port 之间的 1x40Gbps 和 4x10Gbps 模式的应用程序。
net/intel-ixl-kmod：更新的驱动程序，使这些工具在 FreeBSD-10.x 上支持。
该项目由 Intel Corporation 赞助。
待办事项
FreeBSD 11 的支持正在开发中，将包含在下一个版本中。
联系人：Torsten Zöhlsdorff <tz@FreeBSD.org>
半年前，我启动了一个推广活动，旨在改善通过 IPv6 获取 Ports 的支持。2015 年 12 月的研究表明，在使用仅 IPv6 时，25,522 个 Port 中的 10,308 个无法获取，因为这些 Port 忽略了 FreeBSD.org pkg 镜像。
作为此次推广活动的成果，以下服务器现在成功支持 IPv6：
这使得可以通过 IPv6 获取 711 个更多的 Port。
我要感谢 Wolfgang Zenker，他在支持 IPv6 采用方面非常积极。在最近的 RIPE 会议上，他提出了不支持 IPv6 会妨碍商业发展的问题。我希望他的发言改变了一些人的看法，并有助于扩大对 IPv6 的支持。
联系人：KDE 在 FreeBSD 上的团队 <kde@FreeBSD.org>
KDE 在 FreeBSD 上的团队专注于为 FreeBSD 打包和改进 KDE 和 Qt 的用户体验。
本季度，许多更新已提交到 Ports 中，更多的更新已提交到我们的实验 Port 仓库。Tobias Berner、Adriaan de Groot 和 Ralf Nolden 负责了大部分工作。
本季度以下重要更新已进入 Ports ：
CMake Port 已更新到 3.5.1 和 3.5.2。
DigiKam Port 已更新到 4.14.0。
KDevelop Port 已更新到 4.7.3。
新增了 devel/qbs Port，这是 Qt 未来构建系统 QBS 的 Port。
Qt Creator 更新到 3.4.0、3.5.0、3.5.1、3.6.0、4.0.0、4.0.1 和 4.0.2。
新增了 misc/qt5-examples Port，包含 Qt 提供的项目示例，使 Qt Creator 更加实用。
新增了 misc/qt5-doc Port，提供 Qt 的 API 文档，供 Qt Creator 和其他程序使用。
基础 KDE4 Port 已更新到 4.14.10。
在我们的开发仓库中进行了以下工作：
创建了 Qt 5.6.1-1 Port (branches/qt-5.6)。
创建了 Qt 5.7.0 Port (branches/qt-5.7)。
plasma5 分支与 KDE 上游保持同步，包含 Frameworks 5.24.0、Plasma Desktop 5.7.0 和 Applications 16.04.2 Port (branches/plasma5)。
联系人：Torsten Zöhlsdorff <tz@FreeBSD.org>
Ruby on Rails 是 Ports 中大多数 Ruby gems 的基础。目前，Rails 3.2 和 4.2 共存。由于 Rails 3.2 即将停止支持，现在是切换到 4.2 的时候了。
尽管正在进行删除 Rails 3.2 的工作，但仍有一些 Port 存在需要进行重大更新的问题，这阻碍了整体进程。最近的阻碍因素是将 www/redmine 从 2.6 更新到 3.2 的工作。该更新已成功完成，因此我们现在可以继续进行其他工作。
如果你有助于移植和测试，欢迎与我或 ruby@FreeBSD.org 邮件列表联系。
最后更新于