选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
可怕，很可怕。
其实也没啥，年度对帐单其实就是把月度对帐单里面的帐目做了一下summary，然后分门别类地把刷卡的明细排列出来，告诉你每个月花了多少钱，有多少调整金额和charge（我从来不相信国内某银行宣传材料上写的那种月底不把钱还清是好的理财策略的说法，无论如何不还清导致最终的还款现值pv都会比还清的高，所以这项几乎一定是 < 0的）。
不过我比较好奇的是这么大量的数据是如何存储和查询的。难不成是事先查询好保存成一个待下载的数据吗？想想看，这么大用户量跟数据量（当然，热数据很少，而且访问模式其实和邮件比较类似），还是需要动些脑筋才能做好的，也许这也是当天交易只减信用额度而不反映到实时帐单上的原因。
Read more...和蛇头GG讨论了一个关于卖票的问题，简单地说是票很有限，需求量很大，如何能够尽可能高效地让票以尽可能公平的方式卖出去。
我设计了一个分布式的结构来解决这个问题，当然这个原型可以进一步改进，此处按下不表。记录一下我对这个结构公平性的描述的一个比喻：
“因为其他人也hash了，或者换句话说，这个系统其实不介意一开始有人就注定拿不到票。 就跟一大群人排队抽签是一样的道理，其实这个就相当于说一帮人排队抽签决定去拿一个信封， 然后拿到空信封的可以重新排队抽签，要么拿到票。”
这个系统其实要求参与进来的客户机一起参与计算（但是这些计算并不会明显加大服务器系统的负载），有一些能想到的缺陷，也许需要克服，也许根本不是问题？先把想法记下来再说。
Read more...今天又帮人做了一次恢复，上次干这个事是十几年前的事情了。数据恢复是个手艺活，恢复个60%-70%基本上靠工具，剩下的就靠运气和经验了。
想起很久以前做的一个小工具。简单地说是先把磁盘复制一份出来，然后在数据文件上去操作，把已知的链接上，然后把未知的文件的首簇、长度算出来，在空闲区里面找（很明显，大文件恢复的成功与否很大程度上取决于你多久整理一次磁盘以及是否经常删除文件）然后接个链出来。我当时很感激某文本编辑软件每次都会把之前的文件改名做BAK然后把文件整个重新写一遍。
我对做数据恢复这事是很反感的，总体而言。21世纪需要的是健壮的、支持事务和版本的文件系统。
Read more...First of all, thanks goes to all people who has helped me on this project, especially Pav (portmgr@) who gave it a twist on pointyhat.
It seems that this has taken me almost a month and 20 commits to get into the tree, after the code is ready. At the beginning, the changeset was ~200KB, and I believe it’s not good to just go ahead and commit it in one time, since it makes reviewing hard. Instead, I manually split it into smaller, functional related chunks, and commit it part-by-part.
Read more...最近帮公司的一个客户做了一个数据库迁移，客户声称数据是 utf-8 的，然而在使用过程中出现了许多乱码，检查发现数据并非 utf-8，而是 utf-8 编码之后的 big5，而排序方式更是混乱不堪的默认的utf8-swedian-ci。
MySQL的国际化支持很差。MySQL从 4.1 版本开始大刀阔斧地进行了不兼容的改动，简单地说，这些改动让相当多的操作默认以UTF-8进行，然而这会给旧的应用程序带来很多问题。许多文献推荐使用 SET CHARACTER SET 作为 workaround，尽管这能够解决一些问题，但这种做法本质上会导致 MySQL 进行额外的转换，因此并不是十分理想。
正确的方法是把所有的东西都转换成 UTF-8。一个比较常见的错误是使用SET NAMES UTF8并直接从原始的 Big5 表中导出。这种情况下，文字会被以UTF-8编码的big5方式保存。比较简单的做法是将其直接导入数据表，并以 latin-1 导出：
mysqldump -u 用户名 -p密码 –skip-extended-insert –default-character-set=latin1 –databases 数据库名 > big5.sql
接着，使用 piconv （随 Perl 提供）来转换编码。我个人认为这个工具比 uconv 和 iconv 都要好。
piconv -f big5 -t utf8 < big5.sql > utf8.sql
接下来要把 utf8.sql 中的 latin1 等不正确的编码改为 utf8（通常，简单地sed即可）
最后重新导入。前面 skip-extended-insert 可以让发生错误时显示较具体的行号，这对于较大的数据库而言会比较方便。
声明：此 HOWTO 文档以现状方式提供，不提供任何担保。此文档为个人作弊条，本人会对部分疑问进行解释，但同样不提供任何保证。
此篇按下述授权发表：
/*-
* Copyright (c) 2009 Xin LI delphij@FreeBSD.org
终于，是吧，直接写入BIOS的终极木马诞生了。十几年前的CIH病毒等等现在看来都是小儿科。
这种东西迟早会出现，这个我并不觉得奇怪，但是这次CORE实现的这个攻击是一个通用性很强的攻击，换言之，它能够适应多种不同品牌的 BIOS；实际上我认为这种攻击很可能也适用于网卡、RAID卡、显卡上面的可刷写ROM。例如，如果在 VBE 中写上这么一个玩意呢？现在看来 ACPICA 真是一个有前瞻性的玩意，也许 Intel 早就意识到了这种问题可能会发生？
不管怎么说，我想这是一次很好的机会来让用户知道：永远不要获得不应该获得的权限，如果你是小白，就不要用管理员身份登录！这件事真的很危险。
Read more...之前在水木社区发过，这里也发一下。
我们目前正在寻找有意参加这次活动的在校学生。Google Summer of Code 是由Google公司赞助的供在校学生参与开源项目的暑期活动。目前，FreeBSD已经被选为符合资格的 mentoring organization，这是 FreeBSD 第 5 年参与 GSoC。
重要的日期：
Google将为获得资助的学生提供每人 $4,500 的资助，分3次支付；同时，对于每个项目，Google还会为对应的开源项目提供 $500 的资助。
关于 FreeBSD 本次 SoC 活动的 网站。
Read more...FreeBSD 今天发布了 2009 年第 6 号安全公告 FreeBSD-SA-09:06.ktimer。这个安全公告适用于 7.0-RELEASE 以上到修正日期之前的所有 FreeBSD 版本。
由于这个安全公告修正的是一个零时差 (0-day，也就是发现者直接对问题进行了全面披露，而不是等待供应商修正之后再发布漏洞细节) 披露的漏洞，因此，适当地评估其风险并采取措施就非常重要。安全公告中提到，这是一个"Local privilege escalation"（本地特权提升问题），这种问题属于一类非常常见的（特别是 Linux 内核）、严重的安全漏洞，具体来说，通过一定的方法，登录在系统上的用户可以提升其权限，并实施进一步的攻击。
关于这类漏洞的一个常见的误解是，“本地"漏洞通常是没什么大碍的。然而，那种无关大碍的一类"本地"漏洞，指的是只能在本地控制台触发的问题。例如，如果手中有一张包含了某些工具的Windows PE光盘，用它启动系统便可以得到本地的管理员权限—-这是一个安全问题，但是并不严重，因为事实上如果别人能够接触本地系统，那么他就可以做任何事情。
而 FreeBSD-SA-09:06 指出的问题则不是这类问题。在其上下文中，“本地"是指能够登入系统的任何用户，以及能够以本地用户身份运行的服务进程。对于 Web 服务器而言，这是一个非常严重的安全威胁—-例如，如果在设计时因为疏忽而没有考虑上传文件是否有可能由于某种条件被执行，那么，之前这可能只是一个简单的 DoS 问题（例如，用户可以上传一个不停 fork() 的程序，将 www 用户的进程配额耗尽而导致新的服务请求无法被及时响应），而有了这个漏洞，这些问题便成了远程特权提升问题，其危害也就非常严重了。
Read more...今天路过Castro的时候看到了El Camino Real上那家Washing Mutual上面原先大字的WASHINGTON MUTUAL换成了CHASE的logo，隐约还能看到WAMU大字留下的痕迹。这家百年老店就这样一点一点地消失了。
Read more...出来混迟早要还的。
PST 01:59:59AM之后，系统立即将时间改成了PDT 03:00:00AM。时间就这样在不知不觉中少了一个小时。
Read more...