选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
之前和 A core 聊过这个问题。整理一下发出来。
这个话说的可能比较绝对，有人说，缺少信任的社会是可悲的—-而我想说的是，现今，被过度滥用的信任则是可怕的。通过各式各样的社交网站，如 Facebook、LinkedIn、开心网、天际网等等（我想有人会提到 豆瓣，但是我个人认为豆瓣算是一个比较另类的社交网站，因为上面的人很少使用真名），很多人之间的联系被轻易地挖掘和利用。
类似"谁认识谁"这样的信息，在过去是不太容易获得的。而有了社交网站，一切都变得如此透明。一个人的人际关系如何？作为招聘的HR，只要到这样的网站上检索一番就能够一目了然；想要让一个人身败名裂？很简单，从身边的人下手—-几年前，在blog还没那么普及的时候，我就收到了一封匿名的"检举信"，讲的是某低年级同学在某地所做的丑事，导致该君到处写信灭火，而事实？只是寻衅报复—-互联网使得信息的传播变得比人类以往的任何时候都要更加迅速，当然，正如很多可以分成靠谱的和不靠谱的东西一样，海量的信息带来的则也包括了海量不靠谱的信息。
和很多人一样，我对于要求填写个人信息的注册表格有非常强烈的抵触情绪。我为什么要相信一个网站或公司能够确保这些信息不被未经授权的第三方得到？事实上，正如对软件所做的各种保护一样，主流安全公司所做的所谓验证，无非只是一种心理上的安慰—-这家公司采用了比较严格的流程，使得你的隐私信息，例如姓名、地址、信用卡号，等等，不太容易被攻击者得到—-比如说，这些信息只能一次性地写入到服务器，之后只能得到其中的后几位，而那台记录这些信息的服务器受到了更为严格的保护—-但是，只要这些信息能够被任何这家公司的工作人员读取，那么，它就不可能是绝对安全的。
你相信大型邮件服务提供商，例如 Google、MSN、Yahoo、网易、新浪 能够保证邮件的安全吗？我想，海量的用户带来的巨大的关注成本以及这些公司招聘时候对入职人员的进行的考察所保证的职业操守，足以让我相信做为一个普通用户，完全可以信赖这些邮件系统；然而，如果你的通讯涉及到巨大的商业或其他利益，事实上，基本上没有有效的办法去阻止邮件在不知道的情况下发生丢失或被泄露给通讯双方所不知道的第三方。
从工作在客户端的间谍软件，到大楼的网管，再到互联网服务提供商（到互联网骨干，再到IDC等等），再到服务器所属的那家公司—-如果考虑收信的一方，那么还要再多加一倍的可能入侵的环节，更重要的是—-你的通讯多数时候是明文的。加密并不能解决全部问题，除非能够有有效的方法确认收件人的身份，并保证路上不出现故意的"遗失"，还要保证，在你能够把文本加密之前，所用来编辑和加密的系统是可信的。
互联网时代没有隐私。永远不要说"永远不"，但是我还是想说，如果不希望某些信息公之于众，那么最好的办法仍然是把它烂在肚子里，而不是放到互联网上某个让你觉得别人永远找不到的角落。类似地，也不要把能够很容易地获得的信息太当回事，这个世界上有很多不够小心的人，但这并不代表，这个世界上的人都不够小心。
哦，对了，写这篇文章是因为看到了 MD5 considered harmful today，终于有人凑出了一个CA证书。是的，加密也不一定有用了。
Read more...来自李笑来老师的blog(原来在新东方上过他的GRE课)的《如何找到属于自己的兴趣》。
Read more...洋人欺我太甚，竟至国之将亡。与其苟且图存，贻羞万古，不如大张挞伐，一决雌雄！我大清朝威严宣布：向英吉利国开战！向法兰西国开战！向美利坚国开战！向德意志国开战！向俄罗斯国开战！向意大利国开战！向奥地利国开战！向日本国开战！钦此。
Read more...有 HTML 和 PDF 两种版本，详见 OpenGroup书店。
Read more...帮人发的。北京某公司，地点在中关村。
要求：熟悉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...