选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
由于送修 iPad 最终没有修好，因此店家给提供了一台二手的 iPad。作为不折腾就会死星人我觉得显然应该重刷一遍固件（卖家已经重新清空了数据），因此做了一次 DFU mode 固件更新。
具体做法是先把 iPad 接在 Macbook 上，同时按住 power 和 Home。等待大约10秒后屏幕變黑，此时按住 Home，等到 iTunes 上可以看到 Recovery 为止。
然后就是刷 iOS 和恢复数据了，此前过程中在网关听包未见明显异常。
Read more...这次 Heartbleed 安全漏洞之后，阿里巴巴集团的多个产品均迅速修复了漏洞（好事），但事后的公关处理做的却有待改进。
我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博，内容如下：
关于OpenSSL某些版本存在基于基础协议的通用漏洞，阿里各网站已经在第一时间进行了修复处理，目前已经处理完毕，包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。
大家可以放心了！
我并不是阿里巴巴/支付宝的客户，不过看到有人转发这条消息，我半开玩笑地 回了一句：
Read more...冲这句"大家可以放心了"就没法放心了……
又一次出手为民除害了！ Undeadly报道： OpenBSD has started a massive strip-down and cleanup of OpenSSL。
这次 Heartbleed 的事情搞的我十分不爽，这事固然不能全怪 OpenSSL 的开发者，但是整个过程非常的让人不舒服，具体的就不多说了。等过个几十年再回头看看这次这件事情再说吧。
OpenBSD 目前对 OpenSSL fork 的改进主要包括：
我个人非常希望 OpenBSD 的 fork 能够成功，那样的话我们就可以在几年以后（已经发布的版本还需要继续支持一段时间）彻底从 FreeBSD 基本系统中砍掉 OpenSSL 了。
Read more...去年第四季度的时候，在网上看到 华擎科技 推出了一款基于 Intel Atom C2750 SoC 的主板， Asrock C2750D4I，感觉很赞，于是立即和华擎科技取得了联系（当时这款主板还没进入量产），并着手开始了测试等工作。这张主板的重要特色包括：
此处强行插入一条广告： 我厂 目前这一代的 FreeNAS Mini 采用了这张主板，组装好的产品可以通过 Amazon 购买,我厂每年都会将一部分利润捐给 FreeBSD 基金会，如果先 在 smile.amazon.com 注册支持 FreeBSD 基金会，并使用前述链接， Amazon 公司还会再捐出 0.5% 的金额给 FreeBSD 基金会。
目前这张主板已经进入了量产阶段，因此也可以从其他零售渠道获得相关组件自行组装。
Read more...这是我加入 FreeBSD Release Engineering Team (re@) 之后，我们发布的第一个主要（X.0）版本。
这个版本对整个系统进行了大量的改进。其中的重要变化包括在基本系统中用 clang 取代了 gcc（所有 Tier-1平台）、新增了 unbound（用于取代BIND的部分功能，后者十分复杂，且支持计划经常与 FreeBSD 的发生冲突）、基本系统中提供了转码API iconv(3) （我在2010年指导的 Summer of Code项目）、使用了 PkgNG 包管理工具、BHyVe虚拟机、对于虚拟化支持的大幅改进（virtio(4)以及 Hyper-V支持）、ZFS新增了TRIM支持、ZFS的LZ4完整支持（我在去年新增的功能），等等。
这个版本的发布工程过程将发布日期推迟了总共三次（从2013年11月18日推迟到了2014年1月15日，大约两个月的时间）。我认为有很多需要改进和汲取经验教训的地方。总结如下：
由于这些问题，导致在 BETA2 之后增加了两个新的 BETA。RC1之后，开发节奏基本是按照计划进行的，但由于意外情况必须增加RC4（一个非常严重的 VM bug）。而此后又发现了一个 10.x 新引入的安全问题，因此不得不发布 RC5 以便对修正进行更充分的测试。这些延期导致的一项（我认为是好的）副作用是，原定 10.0-RELEASE 之后两周左右发布的一批安全公告的修正内容也在 10.0-RELEASE 之前得到修正和公布。
注意（此处大坑）：由于之前 freebsd-update 的 bug （EN-13:04 和 EN-13:05），在更新之前的版本可能无法直接通过二进制方式升级到 FreeBSD 10.0-RELEASE。这些版本的 FreeBSD 应首先用 freebsd-update 升级到 9.2-RELEASE-p2、 9.1-RELEASE-p9、 8.4-RELEASE-p6、 8.3-RELEASE-p13 或更高版本之后再使用 freebsd-update 进行升级。
Read more...先挖好坑，等有空了再填。
今天(2014/01/14)发了4个安全公告和2个勘误公告，其中 FreeBSD-SA-14:02.ntpd 是针对 NTP 的这种攻击的因应措施。
攻击的原理是通过发送一个小包（GET_MONLIST），得到大体积的回应。而由于 NTP 使用了 UDP 协议，因此攻击者可以伪造源 IP，从而，通过较小的流量代价，即可利用其他服务器作为杠杆来攻击受害者。
正确配置的 NTP 服务器并不受这个问题影响。所谓正确配置是指 NTP 服务器配置为只允许其他机器向其查询时间，具体做法是在 /etc/ntp.conf 中增加类似下面的设置：
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0
（说明：上述配置是推荐的配置，实际上起作用的是 noquery）
还有一种解法是仅仅禁止 monitor 功能：
disable monitor
FreeBSD 安全公告提供的补丁采取的做法是将 monitor 功能默认禁用。用户不需要对配置文件进行修改，只需更新软件并重启 ntp 服务即可防止自己的服务器成为别人的攻击杠杆。
Read more...因为家里最近发生了几次停电，我觉得 Enough is enough，决定还是再买一台 APC BE550G 来扛家里的网络基础设施。
配置和两年前在大河用的那台 一样。
Read more...今天去 San Francisco 的 Delphix 参加了 OpenZFS Developer Summit，今天这会太充实了，先记一笔。
ZFS Channel Program：目前的 ZFS 应用程序需要以多次系统调用来完成一项功能。为了实现原子性，用户态部分实现起来比较复杂，而且最终内核中的 sync task 可能会导致长时间的延迟。提出的解决方案是在 ZFS 内核部分引入一个 Lua 字节码解释器，用户态一次灌一个脚本进去，通过脚本逻辑实现原子性，从而减少上下文切换开销并极大地简化用户态部分。
分层的 ZFS 存储：希望将 ZFS 改造为能够适应冷热存储的结构，这样可以将冷数据部分固定下来之后脱机（例如置于待机状态），从而节省能源开销。(Nexenta)
对于 spacemap/metaslab 的改良：Delphix 通过 DTrace 观察发现了一系列性能瓶颈并进行优化的实例。这个已经在 Illumos 里了，今天主要是趁热讲解一下所做的改进。比如写带宽限制从原始的限时、限量、加延迟变成了按系统中未回写数据比例作为限制条件、当 I/O 持续到来时自动切换到吞吐量优先（多排任务）的模式、写入速度减慢时减缓接受写请求等的新一代写带宽控制，使得 ZFS 的写入延迟得到了极大的改善。Adam Leventhal （这位老大也是 RAID-Z2/Z3 以及 ZFS gzip 压缩支持的作者）分享了采用的方法、评估手段等等。
明天的活动是 Hackthon，又要起个大早。
Read more...早期 FreeBSD 文档采用 jadetex 等的工具集，对 UTF-8 的支持不好。最近， Gabor 等人完成了将工具集换成 TeX Live、Apache FOP，并使用 DocBook 5.0 的工作，所以趁今天编译代码的空挡，我把 FreeBSD 简体中文文档全部换成了 UTF-8 编码。
目前这个转换还有一些小问题需要修正，目前版本的 PDF 生成已经基本算是可以看了（之前有很多由于字体配置问题导致的汉字缺失）。还需要解决下面这些问题，但是我暂时没有太多精力去做，如果有兴趣请和我联系：
在 FreeBSD doc project 换成 svn 之后，FreeBSD 简体中文文档计划基本上处于停滞状态。现在的想法是将库挪到 github 上面，方便多人合作；FreeBSD 目前已经有了对应的 github 镜像：https://github.com/freebsd/freebsd-doc，如果未来按这个计划去做的话，我打算起一个新的github项目来做。
Read more...这个方法我最早是在 佐藤 広生 在 第13回 FreeBSD勉強会 上做的 《ZFSの活用とチューニング》 演示幻灯片上看到的，当时没想太明白，而后来想明白了也没记下来。今天想起来了就先记上一笔，备忘。
一般来说，如果有很多不同的资源，那么尽量让不相关的资源同时去完成不同的任务有助于改善系统的利用率并提高吞吐量。而 Unix 上的大部分工具在设计时都是设计成阻塞的，或者说它们很大程度上能够高效地利用一种资源，而在完成一系列相互关联的任务时往往就不那么有效了。
举例来说，发送 ZFS 快照到另外一个网络的服务器上，假定发送 ZFS 快照本身在本地可以以较快的速度持续进行，但带宽比较受限，那么很显然的一个想法便是引入压缩。另一方面，在接收一侧，解压缩之后的数据写盘的速度可能没那么快，而且让压缩程序直接挤牙膏似的吐出数据给 ssh 或者 nc 往往也不能十分有效地利用带宽。在这个场景中，在发送端我们可以看到以下几个任务：
对应的，在接收端我们也可以看到与之对应的任务：
在这样一个链条中，如果全部使用标准的 Unix 命令行工具的话，任何一个环节的阻塞都可能会直接向前反馈，从而影响整个系统的吞吐量。很明显，在对方由于任何原因暂时来不及接收数据的时候，压缩操作可以继续进行，这事通过编程不难实现，但实际上我们需要的只是引入两个 dd 进程，即将发送端变成：
在新的场景中，接收端的阻塞将导致第二个 dd 的输出阻塞，而此时第一个 dd 仍然可以再吃下 16MB 的数据流（这个 16MB 需要根据具体的应用来调整，原则上它应该大于远端一次阻塞到完全恢复这段时间上游能够产生的数据量）。通过 dd 所做的 reblock，也使发出数据采用较大的块尺寸，从而进一步节省带宽。
Read more...