无意中查了下，发现我经常订阅的2个邮件列表，lists.openstack.org和lists.dns-oarc.net，竟然没有MX记录。如果没有MX记录，邮件如何路由到目标域？一时竟困惑。来自easyDNS的Mark和openDNS的Frank分别答复，如果没有MX，那么MTA默认投递到该域的A记录。不过即使如此，我认为邮件域还是明确设置一条MX记录比较好。
If no MX records are found, mail exchangers try A records.
See section 5 of RFC2821.
如果你在上网时遇到了问题，借助一些专业工具，有助于迅速查找原因。Viewdns.info在一个页面集成了21种不同的测试方法。例如，检查DNS和网站健康、端口扫描、网络traceroute、ping、whois、IP位置查询，还竟然有个功能可以检查网站是否被我朝防火墙过滤掉。这些工具别的地方也有提供，但该站把它们都集中在一起，不妨一试。该站还提供API，开发者可以在自己的应用里使用他们的知识库，不过要付费，免费的每月限250次查询。
我的Macbook的Ruby还是1.8.7版本，很老了。可以使用rvm来升级和管理ruby版本。
打开Terminal，运行如下命令安装RVM：
curl -sSL https://get.rvm.io | bash -s stable
查看可用ruby版本：
rvm list known
安装某个版本：
rvm install ruby-2.0.0-p247
使用某个版本：
rvm use ruby-2.0.0-p247
rvm use的作用就是更改当前shell的$PATH变量，将ruby某个版本的安装路径提到最前面。运行ruby -v和which ruby可以看到这个变化。注意的是rvm并没有变更系统ruby版本（/usr/bin/ruby），如果在程序开头设置了#!/usr/bin/ruby，那就还是用的旧版。如果使用新版，在每个用户shell里需要先运行rvm use $VERSION。安全起见，可以将系统ruby链接到rvm安装的ruby版本。
在Sitepoint上看到一片文章，对比了AWS RDS、Google Cloud SQL、ClearDB、Xeround四款云端Mysql产品，包括它们的功能、价格、限制等因素。引用如下：
Even though all providers offer a hosted MySQL database, there are some differences. You will find limitations with:
在今天云计算日新月异，而云存储是其中一个重要组成。我认为云存储首先要是分布式的，分布式起码具备如下属性：
分布式存储产品Couchbase是其中典范。除此之外，云存储还应具备如下功能：
目前主流的云存储产品可分为如下几类：
其中关系型DB最难实现分布式，如AWS的RDS，不过是运行在EC2上的Mysql实例，Rackspace的Cloud Mysql，也是采用container技术的DB实例。
NoSQL具体来说，又包括面向行、面向列、以及K/V型的。
根据应用需求的不同，用户可以选择不同的云存储产品。比如在我们公司，对象存储、K/V存储、Document存储就被广泛使用。
老大的车终于出手了，我既遗憾又高兴。遗憾的是这车一直是我的梦想，LX570，牌照是GA13号段（了解这个号段的应该知道多牛X）。高兴的是他这车不容易出，遇到有能力拿下的人也算缘分。我也想过接这个车，无奈今年接连遇到一些事，经济上能力不够，只好作罢。
好些年前，我开的第一辆就是军用越野车。日本产，粗糙，耗油，谈不上一点舒适。但是，结实耐操，脱困能力强，有路的地方就能去，从来不会落下。这个车给我留下很深的印象，也让我深信日本越野车的专业与品质。一直想着今后有能力，再整一个陆巡或雷克萨斯高端SUV，然后沿着新疆西藏，把大好河山自驾一遍，不枉人生。现在错过了老大这款，今后找机会再圆梦吧！
看到一篇文档，认为RAID5在坏了一块盘情形下，数据丢失风险是单盘的N倍，N等于剩下硬盘的数量。例如，一个RAID5阵列由4块硬盘组成，如果坏了一块盘，剩下3个盘组成RAID0工作，数据分散写在3块硬盘上，故障概率是单盘3倍。即使RAID5 + Hotspare也不安全，因为Hotspare恢复数据灰常慢，而且恢复期间大量的读写会增加剩下硬盘故障的风险。结论就是如果你的数据很重要，就不要使用RAID5。推荐RAID6，因为RAID6可以处理2块硬盘同时故障的情况。
近日多次发现国外的域名无法解析，甚至有些国内的不常访问的网站，也无法进行DNS解析。查了一下，发现国内访问根DNS，以及访问com/net域的权威NS，都大规模故障。如下在一台广东电信服务器上，运行一个shell命令，测试根DNS的解析情况：
$ dig . ns +short |sort |while read LINE;do if dig . soa @$LINE >/dev/null 2>&1;then echo $LINE OK;else echo $LINE fail;fi;done a.root-servers.net. OK b.root-servers.net. fail c.root-servers.net. OK d.root-servers.net. fail e.root-servers.net. OK f.root-servers.net. OK g.root-servers.net. OK h.root-servers.net. fail i.root-servers.net. OK j.root-servers.net. fail k.root-servers.net. OK l.root-servers.net. fail m.root-servers.net. OK
我们看到，13台根DNS里，有5台无法解析。
再运行如下shell命令，测试com/net域的权威NS服务器解析情况。
$ dig com ns +short |sort |while read LINE;do if dig com soa @$LINE >/dev/null 2>&1;then echo $LINE OK;else echo $LINE fail;fi;done a.gtld-servers.net. fail b.gtld-servers.net. fail c.gtld-servers.net. OK d.gtld-servers.net. fail e.gtld-servers.net. OK f.gtld-servers.net. fail g.gtld-servers.net. OK h.gtld-servers.net. OK i.gtld-servers.net. fail j.gtld-servers.net. fail k.gtld-servers.net. fail l.gtld-servers.net. fail m.gtld-servers.net. OK
这个情况就更严重了，13台com/net域的权威NS，有8台无法解析，故障率高达61.5%.
对于不常访问的域名，各地的递归服务器里没有缓存，会产生向上查询。而上一级的权威NS（如com/net域）、以及根DNS都大规模访问失败，从而导致域名解析超时，或无法解析。
这个白皮书包含如下内容：
