星流

    win7如果只有一个用户且没有设置密码的话，开机后应该可以自动进入桌面，而不必选择用户。但最近每次开机时都需要手动选一下，在控制面板的“用户账户”里也看不出所以然。
    后来查到，win+r调出运行窗口，输入“control userpasswords2”，可以打开一个用户账户的管理窗口。在里面看到多了一个“__vmware_user__”用户，原来是虚拟机建的，此用户虽然不会在启动时显示，却会影响自动进入。

    一年前买了专用主机，除了搭了个WordPress之外什么也没做过，现在终于决心装一个VPN了。
    为了稳妥起见，没有选择PPTP，而是选择了肯定可以在OpenVZ上安装的OpenVPN。准备工作是联系客服打开相应的支持。在hellohost的说明上写着：“增加 TUN/TAP 支持一次性 50 元”，没想到填了ticket之后客服很快回应说年付的可以免费开通，而且不一会儿就生效了。输入cat /dev/net/tun，提示File descriptor in bad state，就说明已经成功开通。
    安装配置过程主要参考了这篇攻略：http://rashost.com/blog/centos-openvpn-install，需要注意或者略有不同的部分如下：
    1. 修改服务器端配置文件/etc/openvpn/2.0/conf/server.conf的时候，一定要注意修改ca、cert、key、dh的路径，否则启动会报错。push redirect-gateway和push dhcp-option DNS前面注释的分号要去掉，否则客户端连上以后会收不到默认网关或DNS服务器。DNS可以用Google的8.8.8.8。
    2. iptables的转发规则的修改，主要参考这篇：http://www.deepvps.com/centos-vps-openvpn-install.html 即使用命令：
            iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 1.2.3.4
    把其中的1.2.3.4改成服务器的地址。
    3. 客户端下载地址：http://openvpn.net/index.php/open-source/downloads.html 客户端配置文件除了注意修改remote的服务器地址外，如有必要也要修改ca、cert、key的地址，修改为从服务器发回来的key文件。当然如果忘了修改的话，启动时的错误提示还是很清楚的。
    4. 启动客户端连上vpn之后，会自动创建一个网络连接，关闭vpn后会在右下角显示一个“网络电缆没有插好”，除了在任务栏的属性里设置将此图标总是隐藏以外，没找到太好的处理办法。
    5. 可以用刷新www.ip138.com的方法简单地判断代理是否生效。

    PS：不得不说，Win7的体验比XP好太多了，完全不存在那个讨厌的网络连接图标的问题。再者，不用GUI而直接用openvpn.exe打开似乎也不错。

    前几天京东、当当、苏宁易购竞相搞活动，却发现没有多少可买的书。一来是因为6月份刚从京东买了一大批，二来是因为最近在kindle上看了不少，却少有激起购买欲望的。所以还是记录一份待购书单比较好，再有活动的时候方便出手。
    1.《批评官员的尺度》 [美]安东尼·刘易斯 （2011.11.11√）
    对公共事务的讨论应当不受抑制、充满活力并广泛公开。
    2.《龙纹身的女孩》等千禧年三部曲 [瑞典]斯蒂格·拉森 （2011.11.11√）
    直面社会问题的处女作&遗作。
    3.《自私的基因》 [英]理查德·道金斯
    人生的意义的科学层面。
    4.《天命》 钱莉芳 （2011.11.11√）
    历史与科幻的结合，有珠玉琳琅，惜乎连缀不谨。

    to be continued...

    前一阵装了Bing Dynamic的win7主题，按照官方说法应该是每周通过RSS推送两张桌面，但过了好几星期也没见动静。从网上的说法看，RSS源的自动加载靠的是计划任务中的“IE RSS更新任务”，如果此任务被360或者金山之类优化工具屏蔽掉就无法自动更新了。但我的优化记录里并没有这一项。
    最后发现，此项任务是在IE的“选项-内容-源和网页快讯”的设置中开启的，不知道一般系统的默认设置是怎样，我的确实没有勾选自动检查。

    勾上之后，系统服务中就出现了RSS的更新任务。此外，在IE的“收藏夹-源”中也能看到这个源的地址。

    解决了软件本身的显示问题，更难办的就是使用习惯问题。策划们用了多年的VSS，很难要求立刻养成编辑文档之前先锁定的习惯，一旦出现两人编辑同一文档的情况，产生的文件冲突很难妥善处理。
    SVN中有一种needs-lock属性，使得文件默认是只读的，只有先锁定才能获得编辑权限，能够很大程度地解决忘记上锁的问题。而且只读的文章显示的是灰色对号，十分直观。对于已经在版本库里的文件，可以通过在根目录上递归添加needs-lock属性的方式一次性设置好，但要想让新添加的文件自动带有这个属性，就不是那么容易了。
    一开始查到一种解决办法，通过修改C盘中User目录下的SVN配置文件来设置，这比设置图表显示时逐个手动设置注册表还不靠谱，后者的位置好歹还是固定的。好在又查到这个也是可以通过改注册表来实现的，在一篇博文中提到通过reg文件自动导入注册表来实现的方法。但更靠谱的是把这几句也做到bat文件里，一次性解决配置图标和设置默认只读的问题。
    bat中添加注册表项比删除要复杂一些，需要分别指定key、类型和value，例如：“reg add "HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Config\miscellany" /v enable-auto-props /t reg_sz /d yes /f”，/v后面是key，/t后面是类型，/d后面是值，/f表示不经询问直接添加。

    前两天策划用的VSS服务器坏了，于是组里打算把文档也放在SVN上，用TortoiseSVN作为客户端。TSVN能够嵌入资源管理器，用起来还算方便，不过由于SVN对文档合并的支持并不好，所以最好不用复制-修改-合并模式，而还是使用传统的锁定-修改-解锁的模式，lock功能就很重要了。一试之下却发现，对文件加锁之后图标依然是绿色的对号，而没有如文档所言变成一把黄色小锁。
    几经周折，在官网FAQ里查到以下说明：“You may find that not all of these icons are used on your system. This is because the number of overlays allowed by Windows is limited to 15. Windows uses 4 of those, and the remaining 11 can be used by other applications.……Locked is only loaded if there are less than 13 overlays already loaded. It falls back to Normal if there are not enough slots.”就是说Windows只放出11个空位给软件自定义的覆盖图标，如果空位不足，SVN就主动把自己的Locked图标撤掉了。
    进一步查到DIY的方法，在一篇博文中提到可以修改注册表中的HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers，通过把SVN的条目提前来保证可以显示。网上通行的对SVN图标不显示的解决方案都是这个，而且普遍认为其方法有效。查看我的注册表，果然包含同步工具Groove带来的多个图标，但提前SVN条目并不能解决我的问题。我猜想即使把SVN的条目提前，锁定图标也不会正常显示，只是大家很少用到锁定功能，只要看到对号、感叹号等图标能显示就认为正常了。干脆将Groove的条目全部删除，再重启explorer.exe，锁定可以正常显示了。
    因为工具是给策划用的，不能挨个机器去删注册表，卸载groove又很麻烦，于是搞了一个bat工具去批量删除注册表，例如“reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\Offline Files" /f”，美其名曰recover_svn_icon.bat，安装完TSVN之后运行此脚本就可以了。

（1） 64M内存的主机怎么样也是不够用的，虽说可以优化软件把内存占用降下来，可是如果连运行yum都报告内存不足的话，自己一个个下载rpm就太辛苦了。还是256M用着比较爽，毕竟一分钱一分货。
（2） 即使是256M的内存，mysql还是一定要优化的，占用悬殊太大；apache也可以替换为lighttpd，别的优化似乎做不做均可。
（3） 操作系统用CentOS就很好，Ubuntu自启动项之类太多，当桌面机是优点，当VPS的服务器太费内存。
（4） 有的攻略里建议安全起见把php的一系列函数禁掉，但其中的parse_ini_file()有些插件会用到，比如WP的统计插件owa，这个还是不要禁的好。
（5） 指定二级域名的跳转并不难，但DNS要设好泛解析。就hellohost.net的系统而言，DNS管理的时候除了"@  A  地址"之外还得加一条"*  A  地址"，一开始忘了的话再修改的时候又得等两个小时。
（6） WordPress的插件和主题如果因为权限问题装不上，索性chmod -R 777 wp-content一下；自己手动下载的插件还得另设置，否则插件管理器里都看不到。
（7） WP的配置文件加一行define('FS_METHOD', 'direct');，下载插件就不用提供ftp接口了。有了ssh就没必要再开ftp。

    不知道是不是我的个人问题，ls输出结果中文件夹的亮蓝色在黑色背景下十分难以辨别，好在系统提供了修改的方法。
    控制ls输出结果配色方案的变量是LS_COLORS，在命令行下输入echo $LS_COLORS可以显示其内容，是一坨以冒号分隔的键值对，如其中一项是ex=01;32，规定了可执行文件的配色，后面的颜色玩过AsciiArt的人看这个肯定不陌生了，01代表高亮，32代表绿色。
    想知道LS_COLORS变量的详细规则，可以用dircolors -p命令，详尽地列出了各个值的含义及默认值，如其中有一行是DIR 01;34 #directory，说明DIR控制的是文件夹的颜色，默认是蓝色高亮。在echo $LS_COLORS的输出中有di=01;34，无疑该修改的就是这个了。
    修改系统变量用的是vim ~/.bash_profile命令，在其中加一行export LS_COLORS='...'，把...用echo $LS_COLORS的输出结果替代，并把其中的di=01;34改成我们要的颜色。这个颜色既要柔和，又不能和常见文件的颜色混淆，诸如压缩文件的亮红、软链接的亮青、可执行文件的亮绿都最好不要用了，至于暗蓝比默认的亮蓝还要杯具，个人觉得比较合适的是暗青(00;36)和暗绿(00;32)。暗青的好处是和默认的亮蓝比较接近，接受障碍比较小，缺点是看起来是丑陋的臭豆腐色。暗绿的缺点是和可执行文件的亮绿有点近，优点是看上去讨喜。
    以上修改重新登录有效。

附：修改vim查看源代码配色
    在vim中输入:hi，可以查看一个详细的配色方案列表，我要改的是#include、#define等预处理命令，可以看到列表中有“Include links to PreProc”“Define links to PreProc”等，说明这些预处理命令只要修改PreProc对应的颜色就可以了。修改~/.vimrc文件，在里面加入hi PreProc ctermfg=darkcyan，不必重新登录即可生效。要注意的是如果.vimrc中有syntax on语句，新加入的语句一定要在它的下面，否则自定义的配色方案会被系统的覆盖掉。

    前一阵查清楚unix域套接口发送数据报(dgram)的阈值之后，进一步测试了字节流(stream)的发送上限。还是接收端不接收，发送方持续发送data大小固定的msg，结果远比数据报难以理解：data大小在1字节到64字节之间时，发送468个msg后产生拥塞；大小在65字节至128字节时，发送367个msg产生拥塞；……大小在193至256字节时，发送256个msg拥塞。
    1字节和64字节行为一致尚好理解，显然是一种字节对齐后的行为，查看内核代码也确实发现了一句比较复杂的宏进行64字节对齐。问题在于64 * 468 = 29952，128 * 367 = 46796，这里面16844字节的差值一直没有想通。因为刚刚遭遇了数据报的问题，第一反应是也存在有某种复杂的msg个数上限，却找不到内核代码佐证。
    更诡异的是，无论是修改发送端的SNDBUF选项，还是接收端的RCVBUF选项，都不会影响发送个数，使人越发摸不着头脑。
    这个问题搁置了一阵，后来闲暇无事的时候继续看内核，发现这个应该受SNDBUF影响才对，进一步发现之所以之前认为修改SNDBUF无用，是因为修改的是linsten fd的SNDBUF，虽然在TCP里面conn fd会继承listen fd的缓冲区设置，但Unix域的字节流并不存在这种继承关系（此处是否继承本质上与TCP的三次握手机制以及unix域的特殊缓冲机制有关，暂不赘述）。
    重新设置了conn fd的SNDBUF，果然看到发送个数同比例变化了。而且SNDBUF的默认值是106KB，由此得到发送64字节data时，msg总大小约是232字节，而128字节data对应的msg是296字节，msg与data的差值是固定的168字节（因为舍入误差，一度以为是167字节，但根据字节对齐的惯例，还是168字节比较合理，特别是106 * 1024 / (256 + 168)恰等于256）。事情到这里就豁然开朗了，进一步看内核，果然看到了一个比较大的结构体被填入msg中，浅尝之后放弃了对这个复杂结构体的解析，毕竟查到这一步也算比较清楚了。
    抛开这些技术细节，最值得反省的是，在当初看到64/468、128/367的对应关系时，只要稍有直觉，就应该可以列出(64 + x) * 468 = (128 + x) * 367的式子，得出101 * x = 16844，进而省去查内核之苦。之所以没有做到，可能是潜意识里觉得即使msg中有填充，也不可能大到明显影响msg的比例，就草率否定了这个可能。主要教训是，在简单机制的猜想还没有完全证实或证伪的时候，不应该盲目地把希望寄托到复杂机制上，否则很可能带来大量的无用功。

    昨天下午测试在Unix域套接口上使用数据报发描述字，发现如果接收端不收取的话，发送端最多发11个就阻塞住了，而且阻塞与否和数据报的字节数大小也没有关系。查了半天内核代码，确定是一个叫做unx.sysctl_max_dgram_qlen的变量在作怪，默认值是10，却没看出有什么修改的接口。
    晚上到家以后百无聊赖地翻UNP，本想随便看看非阻塞IO一章，却无意翻到有一节的题目叫“sysctl操作”，顿时觉得似曾相识。这一节在第18章《路由套接口》里，一般来说这一章很容易被忽略，想不到居然隐藏了这么重要的功能。
    里面提到sysctl函数可以读写很多系统参量，诸如文件系统、虚拟内存、网络等信息，例如函数的参数设成{CTL_NET, AF_INET, IPPROTO_UDP, UDPCTL_CHECKSUM}就可以读写UDP校验和有关的设置。没有看到与Unix域有关的设置，便打算今天到公司再查。
    不料把UNP里的程序录入以后却无法编译，提示找不到几个头文件，UDPCTL_CHECKSUM之类的常量无从解析。内核中的unx.sysctl_max_dgram_qlen倒确实找到变量与之对应，使用系统命令sysctl -a就能看到输出项里有net.unix.max_dgram_qlen=10。用sysctl -w net.unix.max_dgram_qlen=20可以调大，经验证有效。但无法用函数实现终归不爽。
    中午有同事提醒说Linux下与sysctl有关的常量定义都在sys/sysctl.h下，而不是像UNP中那样一层一个头文件。检查sysctl.h，很容易找出了net.unix.max_dgram_qlen对应的名字序列：{CTL_NET, NET_UNIX, NET_UNIX_MAX_DGRAM_QLEN}。格式上确实比书中的（应该是BSD的格式）要规整一些。至于书中那个例子，AF_INET应该用NET_IPV4代替，但UDP对应的变量很少，似乎在Linux下是不开放接口的。