选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
帮人发的。北京某公司，地点在中关村。
要求：熟悉Windows Server，独立管理过ExchangeServer半年以上，独立管理过Windows Active Directory半年以上，熟悉网络基础知识，对IOS有初步了解（非背题通过CCNA者尤佳），在生产环境或桌面环境或实验环境使用过Unix类操作系统三个月以上，对Unix类操作系统感兴趣，对系统运营工作感兴趣。
预期年薪6－9万，文化程度等不限。能抬起25公斤物体者优先。
有意者请用简历轰炸 laypeople@hotmail.com。
Read more...我这次不铁口直断了，估计明年见了，如果这周能够RC2的话，最终RELEASE估计要到明年的1月5日左右。
这次FreeBSD 7.1在软件工程角度是相当失败的案例，我想我们应该从里面总结一些教训出来。
首先，我们的目标是什么？
我想，用户对于一个发行版本的期待是：一个经过了大量测试的、阶段性的稳定版本。而开发人员对于发行版本的期待则是尽可能地将可用的功能交付给用户。作为OS，我认为这应该包括自动化的回归测试、性能改进、更新的驱动程序、文档的修订，以及更新的第三方软件等等。
FreeBSD目前的开发模式，是将分别开发的三大模块，即内核与基本系统(src/)、文档(doc/)、第三方软件(ports/)的人在一定的时候聚集在一起，通过代码冻结的方法来使他们从增加新功能转移到集中去修bug，最后发布一个版本。这个模式在过去运转的相当好，以至于我们没有发现其中存在的问题。
这次FreeBSD 7.1暴露出来了这个模式存在的很多问题。例如，由于安全小组发现了很多安全漏洞，而另一方面，安全小组的人手不够，限制了修正这些问题的速度。我本人撰写的一个安全公告等了一个月才在今天最终公之于众，而另一方面，安全小组对于发行版本拥有一票否决的绝对权力，导致6.4和7.1的发布都一再推迟。
而作为非常快节奏的开发的 ports/ 维护者，则对不断的推迟感到相当不满。FreeBSD目前只维护 ports/ 的 -HEAD，也就是说，在正式发行 -RELEASE 之前，ports/ 不能进行大量的、破坏性的修改。例如，我本人维护的 OpenLDAP 现在就必须等待 -RELEASE 之后才可以进行升级。不断地推迟新的发行版本，会导致 ports/ 的开发继续延迟。
Read more...说明：这个实际上是一个workaround，不过我暂时没时间修这个bug。这是一个作弊条，主要目的在于解决这一特定问题而非阐述其背后的原理和最佳实践。
方法：通常启用/上面的SoftUpdates（默认情况下FreeBSD并不启用/上面的SoftUpdates，因为/通常容量很小，开启SoftUpdates意义不大）。正常启用/上面SoftUpdates的方法是启用到单用户模式，然后用tunefs -n enable /来启用SoftUpdates，然后立刻重启。
远程启用SoftUpdates，因为通常无法让机房或机器旁边的人操作，因此进入单用户模式是不实际的；另一方面，如果以读写方式重新挂载 /，则会导致SoftUpdates设置被覆盖，因此不能通过写文件来标记。
具体的做法是使用下列 /etc/rc.early 脚本。注意：这个并不是最简/最优的方案，只是一个能用的方案。
#!/bin/sh
mount -o rdonly /usr
( /sbin/dumpfs / | /usr/bin/head -n 20 | /usr/bin/grep soft-updates > /dev/null 2>&1 ) || (tunefs -n enable / && reboot)
umount /usr
操作成功之后删除 /etc/rc.early 即可。
Read more...在Hotmail里面收到了很多假开心网的邀请信。点开一看，恶心的来了：填好了MSN地址，然后让你填密码。
这家公司真恶心。
Read more...很快就要正式发布FreeBSD 6.x系列的最后一个（第五个）版本了。FreeBSD 5-STABLE发表了3个版本（5.3、5.4、5.5），FreeBSD 6-STABLE比它多两个。我对于FreeBSD 6.x系列在6.2之后的发展基本上不太满意，这次这个版本我想也是类似地，修正了一些之前版本的bug，增加了一些新硬件支持，但是显然这些与7.1-RELEASE相比是远远不够的。个人建议现有的6.x用户升级到7.1-RELEASE。
Read more...上次在MeetBSD的时候Tim提到了一种处理大量静态页的办法。今天看Squid开发人员在NYC的BSD活动上的一个演讲里面也介绍了各种方法处理I/O的区别。
大量小文件是脑残的做法。意味着大量浪费buf cache。
善用mmap等现代OS特性来规避不必要的开销。但是varnish也遇到了问题，即如果内容不能完全放在内存里面就会导致性能急剧下降。
之前 A core 说过一个100、10、1的规律，不知道我是那个100个想到的，还是会做到原型的10，或者会是那1个在生产里面用上这种做法的？
Read more...一段时间之前我曾经和很多人讨论过使用ZFS作为/的可能性。现在看来，这个也未必真就是一个很好的主意。
目前FreeBSD 8-CURRENT已经完全支持从ZFS启动了（换言之，连 /boot 也不需要了），方法是透过 GPT 分区（我最近MFC了最后一套gpart的补丁回7-STABLE，gpart将在7.1-RELEASE中以一种可用的形式出现）的gptboot。简单地说，配合ZFS v13和支持ZFS的gptboot，FreeBSD就可以从ZFS启动了。针对RAID-Z和RAID-Z2的支持也在计划中。
但是，我认为现阶段使用ZFS做／仍然是风险相当大的事情。
Read more...今天MeetBSD由Pawel Jakub Dawidek开讲，等，为啥出来的是xterm……？然后OpenOffice Impress从命令行启动了。
ZFS是大家最关心的一个话题。Pawel最近这段时间对ZFS做了相当多的完善工作（主要是写测试用例和改用例发现的bug）。新版本的ZFS v13除了大大改善了可靠性问题之外，还增加了很多有意思的功能。不过这样一来，这patchset的尺寸？（后话：后一天的committer闭门会议，在大家的一致怂恿下ZFSv13终于给commit到了-HEAD）提问非常踊跃，我们最大的白老鼠之一，运营Internet（作为ISC公司的雇员）的Peter Losher就他遇到的一些问题进行了询问，并且得到了满意的答复。
Murray老大在这之后对这次Google SoC进行了总结。FreeBSD这几次SoC的项目成功率都很高，唯一的遗憾是在SoC之后，很多没有最终进入-HEAD。在肯定SoC的成功的同时，如何更好地利用？很多SoC的代码品质并不是很高，如何求得完成目标与高品质代码之间的合理平衡？这些都是我们需要思考的问题。
Read more...今天起了一个大早，9:00到了位于 1600 Amphitheatre Parkway 的 Google 总部。
手头没有精确的人数统计，不过目测来看，大概有120－150人。看到的第一个见过照片的人是著名的 Cameraman 同学， DragonFly 的 Matthew Dillon 老大！
由于今年是 FreeBSD 计划成立15周年，今年的 MeetBSD ‘08 California 很大程度上是一次 FreeBSD 的活动。
Read more...Riverbed的Edwin老大 (edwin@，portmgr) 来湾区，在 -developers@ 里面约附近的committer吃饭。离Sunnyvale最近的企业是Juniper，不过Craig临时有事没有来，见到了Marcel大长辈（marcel@，re-ia64）和一位tmpfs的fans（囧ing）。这两位，我都是头一次见到活人。Marcel提到除了最近的gpart之外，他还写了一个 调试器，准备以后用它把gdb换掉，其中基本的断点、单步等等都实现了，这位老大的其他作品还包括IA-64编译器等等。
Read more...