选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
Jeff Roberson 下周左右将会正式发表对于 UFS 的一项改进，为 Soft Updates 加入 Journal-ling，从而简化其恢复逻辑，并消除对 fsck 的依赖。
目前常见的保持元数据一致性的方法有四种：最原始的、将元数据以同步方式写盘的方法，性能非常差；常见的文件系统中使用的元数据回写日志（如ext3），缺点是无法检验日志本身的正确性，而且元数据需要写入两次因此对性能有潜在影响；Soft Updates，缺点是需要运行fsck来释放资源泄漏，而这个操作很耗时，且实现本身比较复杂；Copy-on-Write，在WAFL和ZFS中采用的技术，随着硬盘的淘汰随机存取时间不再是性能瓶颈，应该是未来的发展趋势，目前的缺点是会导致产生较多碎片。SU+J结合了Soft Updates和Journalling的优点，即，使用Soft Updates来确保写到磁盘上的数据的一致性，而使用Journalling来确保资源泄漏能够迅速回收，从而消除了fsck的必要性。
非常期待看到明年BSDCan的presentation。虽然目前我拿到的代码还有少量毛边，但是总体来说这次改进：
如题。其实已经算是超期服役了，这次是硬件故障，相当严重的硬件故障，不过还是希望能多用一段时间。
Read more...FreeBSD 5.5和6.1开始内建了 portsnap，portsnap是一种新的 ports 套件同步机制。
与传统的 cvsup 更新方式相比， portsnap 有一些优越性：
早先，架设portsnap镜像的方法比较复杂。由于portsnap的设计，架设portsnap镜像所产生的流量，在通常情况下大约会是仅做portsnap操作的3000倍左右。
之前听lwhsu提到了台湾那边的镜像所采用的方法，值得借鉴：
由于portsnap使用的是HTTP协议，而数据集相对较小，因此，实际上可以把这些内容全部作为反向代理放进内存。
Read more...前几天看了一下 iGoogle，感觉就是，做门户首页的真可以洗洗睡了（我说的是首页，我很少去门户网站的首页，而是直奔新闻之类的子站）。
Read more...感谢 Henry Hu 的帮助。ibus的一些代码在64位系统上有些问题，另外发现预编译的bytecode也有点小毛病，需要手工删除 /usr/local/share/ibus/ui/gtk/ 中的所有 pyc 和 pyo 文件，看来需要找时间看看到底是什么问题了。ibus拼音的效果要好过scim的智能拼音。
Read more...最近收到一封邮件邀请我参加一个调查，发现老外对参加代码公开的项目，特别是开源以及自由软件项目的动机总结的很透彻，多少也帮助我更深入地理解了为什么会存在开源和自由软件的分别。
许多参加开源项目的开发人员最初的动机纯粹就是回馈，或者希望自己能够从中受益—-例如，他们受益于开源项目（例如，使用了这样的软件，等等），对这些项目进行了一些改进，而另一方面又不希望自己去独力维护一个fork版本，因为这样做比较浪费时间，或从成本上来算不合适，等等。
而参加自由软件的开发人员则是希望社会对其有所回馈。例如，他们会希望别人使用自己的东西的时候能够把改进送回来，等等。
许多人会同时有这两种想法。态度比较强硬的会更倾向于使用自由软件的授权，如GPL；而其他人则会希望使用更宽松一些的授权，如Apache、MIT、ISC或BSD。
我个人倾向于使用BSD和MIT授权。
Read more...终于，在美国有接入商开始提供（通过T1）native的IPv6接入了。前几天考 HE 的 IPv6 Sage 的时候看到，IPv4还有600多天就全都用完了，真会这么快用完吗？
Read more...如 quakelee 所说，这类手机应该当作上网本而不是手机。是的，非常费电。
功能方面基本上和之前希望的一致，没有超过太多，也没有太失望。性价比方面感觉比 iPhone 要好一些，当然更重要的原因是 iPhone 完全不支持 Verizon Wireless 使用的 CDMA 网络。
\[1\]的手机，这款手机为 Google 的应用提供了良好的集成，并继承了大量采集用户信息，并根据这些信息改进服务的传统。这款手机提供了将手机通讯录与 Google 通讯录集成，并与 Facebook 以及 Exchange 服务器同步信息的能力，并能够将同一个人对应起来，例如，它能够将 Facebook 上的头像放到电话簿上，并显示此人在 Google Talk 上的状态，等等。而GPS导航功能则是将交通数据做了进去，可以根据路况决定走一些其他的备选路线来加快到达目的地的速度；与 Google Voice 的集成是可以通过呼叫 Google 接入号码（类似 Skype Lite 的方式）来以自己 Google Voice 号码的身份来呼叫其他人，并在后台以3G或wifi来更新 Google Voice 信箱的信息；与 Google Mail 的集成与多年以前的蓝波快信的意思很接近，很亲切。
在收集用户信息方面，我已经能想到非常多的收集信息并利用这些信息的方法了，相信Google已经在收集，或至少是有类似的计划。
安装了一些免费的应用程序，如 Amazon 的 Amazon Mobile、Google的拼音输入法、Voice、推的客户端Twdroid、一些理财工具，等等。重新整理了一下自己的联系人名单，从 LinkedIn 和 Facebook 导入了一些之前失去联系的人的电话等等。
一些不足：有些应用程序发热量偏大（这个OS应该予以检测）、耗电量较大而电池不是很强劲，需要经常充电（当然这个也不能要求太高，毕竟功能并不仅限于打电话）、目前不支持作为数据/传真的调制解调器使用。
总体感觉是，这个东西和几年前用 Nokia 6681 的感觉类似，当然功能要强很多，主要还是作为PDA那一类的设备。
\[1\]操作系统，或作业系统：管理计算机软硬件资源、实施任务调度、存储管理的核心程序。浏览器不是操作系统，网站也不是操作系统，云操作系统是外行的狗屁的概念，他们全家说话都云山雾罩的。
Read more...很多人在一个新产品发布的时候，往往会非常关心这个产品是否发布了相应的源代码。然而，对开发者来说，这毫无疑问是一种本末倒置的关注。
源代码能告诉我们的事情是，一件事情是"如何"去做的，而不是"为什么"要那样做。这事就有点像填写报税的表格，那个表格会告诉你在第1行到第20行每行填写什么数字，然后从第几行到第几行的数字相加，减去第几行到第几行的数字之后写到第几行。而当你想要知道为什么要这样做的时候，税表会告诉你"详见税法某某条"或"详见某说明"，而提供了源代码的产品就不一样了，因为那些说明，往往要么是一些公司的内部机密文档，要么干脆没有。
没有文档是一件很糟糕的事情，但是很多人却会认为，代码可以取代文档。虽然我自己也不太愿意写文档，但是我完全无法认同这种观点。代码可以告诉你"我做了什么"，但是却很难告诉你"当时我是怎么考虑的"，而文档则相反。维护旧的代码，在缺少文档的情况下是代价很高的一件事，因为开发人员在撰写代码的时候认为显而易见的事情，往往在其他人看来并不那么明显，甚至，这些被认为是对的东西很可能其实是错的。显然，代码的同僚复审并不能完全消灭这样的问题，因为很可能两个人水平接近，而撰写文档的过程则会帮助开发人员重新整理思路和思考其中的错误。
我相信，随着不提供文档，但源代码公开的软件的越来越多，明白每一件事在计算机里面到底是如何发生、以及为什么会这样发生的人会越来越少。不重视文档，却单单重视代码，总有一天会酿成为我们这个行业的悲剧。
Read more...继续记一笔，在 /usr/src/share/examples/ses 里面。
为啥这些程序不成为基本系统的一部分呢？难道是因为太简单了……害得我好找（好歹应该在联机手册里面提一句吧）。顺手把代码清理了一下，等新机器到了拿这个去杵杵看。有谁知道ses设备和总线位置（也就是物理的槽位）之间的对应关系有什么办法能拿到吗？还是只能写个程序让一个人去根据这种设备训练一下系统？
Read more...