一个基于Jquery的打字效果插件TypingCat

前段时间，要写一个页面，需要用到打字效果。在网上找到几个基于jQery的插件，但是有些太复杂，有些不太可控。于是干脆就自己写了一个。

 

用法和效果都比较简单，直接把html的代码写出来，看注释应该就知道怎么用了

《鸿门宴》观影记录

今天中午拿到票，结果3点多的时候中心忽然有事，弄完都5：40了，电影是5：45开始，赶到影院的时间是6：00。

一进去就看到刘亦菲被欺负。根据国际惯例，欺负女人的，一定会便当。欺负女主的，肯定会马上便当。果不其然，在刘亦菲脱到一半的时候，霸王出现了。坏人就便当了。

霸王，说你愿意跟我么，刘亦菲说我愿意。这剧情真招人恨。

关于时间旅行的一些讨论

前言

穿越是近年来大家喜闻乐见的娱乐活动。大众开始关注穿越，我想“电视剧”这种大众媒体形式应该做出了不小的贡献。从很久之前大名鼎鼎的《寻秦记》，到现在各种“清穿”剧，还有在微博上被炒起来的《李献计历险记》，都在某种程度上代表了穿越的一种类型。作为一个伪资深理论科幻读者，某猫将在本文对“穿越”这一行为做一个全面的分析和总结，希望能够带领大家穿越迷雾，一睹芳容。

接下来，我们分别来看一下和时间旅行所相关的有趣原理和其可行性分析。

世界，你好！

blogspot很好用。但是有墙，有时候很不方便。所以决定自己动手，而且有点自己的地方，做点事情也比较方便。

域名就先用了免费的tk域名。空间买了yardVPS的Xen，每个月50左右。

在里面重新装了apache，php，然后答了一个wordpress上来。

由于wordpress需要php 5.2.4以上，但是CentOS默认php是php5.1。在网上找了找，有这种更新方法：

CentOS为yum添加官方源
由于centos5.4安装好后通过yum来安装php的版本是5.1.6,现在很多站点都是在5.2.x上开发的，所以我们要添加其他的yum repo
来安装Php5.2.x的版本，测试了几个非官方的repo仓库，感觉代码都不是很稳定，php版本也随时在升级。找了很久，发现centos
官方的一个test repo里面有php5.2.x,安装centos官方的rpm比较放心

1.添加yum repo php5.2.x

vi /etc/yum.repos.d/CentOS-Testing.repo
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
priority=1

安装使用testing库的许可
rpm  -import  http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing

2.升级

yum upgrade php

3. 安装Apahce, PHP, Mysql, 以及php连接mysql库组件

yum -y install httpd php mysql mysql-server php-mysql

//安装mysql扩展
yum -y install mysql-connector-odbc mysql-devel libdbi-dbd-mysql
//安装php的扩展
yum -y install php-gd php-xml php-mbstring php-ldap php-pear php-xmlrpc
//安装apache扩展
yum -y install httpd-manual mod_ssl mod_perl mod_auth_mysql httpd-devel

4. 启动服务配置

# chkconfig httpd on [设置apache为自启动]
# chkconfig --add mysqld [mysql服务]
# chkconfig mysqld on [mysqld服务]

# service httpd start [自启动 httpd 服务]
# service mysqld start [自启动mysqld服务]

（原文在此http://hi.baidu.com/luguo626138359/blog/item/f03bd6cf31a852ea53664f14.html）

一会看看能不能把我的blogspot同步过来。

DNS用的国内的NDSPOD，不知道啥时候能生效。

日志统计脚本

今天同学说让我写个脚本统计日志。日志是一些ip的捕捉记录，根据协议的类型定义了一些ID和子ID。统计的需求是统计出各个类型的客户ip和服务ip。

这些日志是自动写入的，每天会根据日期生成一个文件夹，文件夹中每个小时生成一个日志文档。脚本要做的就是便利24个文档，读取内容进行分析。

由于需要把24个文档在一起分析，所以同学一开始的思路是：

对每一个类型进行统计，每次统计都遍历所有文件

明显效率不怎么样，但是实际上也够用了因为只要在服务器上让脚本跑起来，过几分钟回去看结果就行了

但是因为脚本要给别人看==，所以不能太难看，因此要重新写一下。

开始的脚本是shell脚本，我不太熟悉，所以用python重写了

思路就是定义一堆list变量用来记录ip，每读入一个ip就在list里面查找（not in），如果找不到就插进去。

最后统计list的长度

这样只需遍历一边文件就行了，但是……………………………………


不知道为啥，貌似python写完之后比原来还慢

后来同学一句话点破，not in 查找的时候需要对字符串进行匹配，而原来的shell脚本是用sort排序之后用unique进行去重统计，难怪这么慢。

于是考虑将ip字符串转换成long型再存储在list里面，这样匹配的时候是不是能快点？

但是结果好象还是不理想。在少量数据（两个日志文件）的时候，大概能比shell（8s）脚本慢几秒种（16s，是两倍左右），但是在大数据量的情况下就不容乐观了（多出1/3左右的时间）。

大量数据的情况下会慢几分钟==

不过貌似数据量越大差距越小，足够大的话游客能超过shell，但是差距还是太差了啊.


后来在网上查找了一下，发现原来字典的查找速度更快，因为字典在查找的时候使用hash。于是尝试把所有list换成字典。

果然效果神速。在两个文件的时候，2.9秒左右。既然hash了，那么将ip转化位long型也没有意义了反而做了无用工。去掉之后大概是2.7秒。

然后调整了匹配的顺序，将数量较多的类型先匹配，这样又快了一点点。

如此做一个总结：

1.python中list进行查找和去重的时候（in 操作），使用字符串的匹配，所以速度比较慢。如果存储的是整型则会快一些（数量多的时候还是很慢）。
2.字典使用哈希查找，因此速度很快。
3.调整匹配顺序也可在一定程度上优化速度。

提取url中的主机地址和资源地址

这是网易笔试的一道题目，比如
http://www.mp3.com/test.mp3
则需要提取出主机地址：www.mp3.com
需要提取出资源地址：/test.mp3

由于没有限定语言，处理字符串当然首选python

当时给出的测试域名全部是.com，所以直接就这么写了：

f = open('url.file','r')    #打开测试文件
for l in f.readlines():
   s = l.find('://')           #查找到://作为开始
   e = l.find('com/')      #查找到.com作为结束
   host = l[s+3:e+3]    #://和com之间的是主机
   src = l[e+3:]            #.com/后面的是src
   print("host:"+host)
   print("src:"+src)
#end for

上面的做法有明显的彼端，遇到非.com域名就悲剧了

所以还是应该使用正则

代码如下：

import re
f = open('url.file','r')
rc = re.compile('://[\S]+/) #正则匹配://xxxxx.xxx.xxx/
for l in f.readlines():
sch = rc.search(l) #在url中查找匹配字符，返回一个正则的对象
s = sch.start()
e = sch.end() #返回匹配到的字符串在url中的起始和终止位置，终止位置会在‘/’后面一个字符的位置，所以下面的处理中不必进行e+1
host = l[s+3:e]
src = l[e:]
print("host:"+host)
print("src:"+src)
#endfor

读取文件奇数行

今天处理“如何读取文件偶/奇数行”这个问题的时候，本来是打算用python来解决

python本身是很简单的，偶数代码如下：

f = open('./test.file','r')

while f.readline():

print f.readline()

奇数行代码如下：

f = open('./test.file','r')

print f.readline()

while f.readline():

print f.readline()

在网上想看看别人怎么做的，结果发现大部分是shell中的实现，尤其是用sed命令实现。以前没用过这个工具，居然这么简单：

读取奇数行：

sed -n 'p;n' ./test.file

读取偶数行:

sed -n 'n;p' ./test.file

-n:quite，就是不会将读取的文件行默认显示出来

'n;p'：这是两个命令，读取一行之后，对这一行进行两个操作

n就是直接读取下一行

p就是打印该行

于是效果就是，读两行打印一行

'n;p'和'p;n'的区别就是先读还是先打印了，也就达到奇偶切换

海量数据处理总结

备战百度，在海量数据处理的主题上做一个总结。

详情来自http://www.cnblogs.com/pkuoliver/archive/2010/10/02/mass-data-topic-1.html

1.bloom filter

将数据通过hash函数映射到位数组，比如hash(str)=3则将位数组第三位置为1

对每一条数据都用k个hash函数进行映射，也就是一条数据会将位数组的最多k位的值置1

在查找数据是否存在的时候，则对其进行k次hash，如果位数组中对应的各位都被置1了，则说明该数据已经存在（明显是有一定错误率的）

bloom filter可以用来实现数据字典，进行数据的判重，或者集合求交集

同时，对其进行改进，即位数组每一位不再是0/1，而是数据出现的次数counter，那么出现数据则+1，删除数据则-1，这样可以实现删除操作。

实例：

给你A,B两个文件，各存放50亿条URL，每条URL占用64字节，内存限制是4G，让你找出A,B文件共同的URL。如果是三个乃至n个文件呢？

根据这个问题我们来计算下内存的占用，4G=2^32大概是40亿*8大概是340亿，n=50亿，如果按出错率0.01算需要的大概是650亿个bit。 现在可用的是340亿，相差并不多，这样可能会使出错率上升些。另外如果这些urlip是一一对应的，就可以转换成ip，则大大简单了。

2.hash表

hash表主要是整合了线性表”定位容易，添加删除复杂“和链表”添加删除容易定位复杂“的特点，将二者结合起来。线性表每一个元素位一个指针，指向一个链表。通过hash函数将一个数据映射到某个元素指向的链表上。如此查找是可以通过hash定位到链表，在链表中进行添加删除操作。

散列的方法有很多，不同的散列算法会导致链表的分布均衡问题。比较好的算法是非波那契算法

i ndex = (value * 理想乘数) >> 28

其中理想乘数为：

1，对于16位整数而言，这个乘数是40503

2，对于32位整数而言，这个乘数是2654435769

3，对于64位整数而言，这个乘数是11400714819323198485

适用

hash表适用于快速查找，但是需要数据可以全部放入内存。

作为扩展，可以使用d-left hashing

d-left hashing中的d是多个的意思，我们先简化这个问题，看一看2-left hashing。2-left hashing指的是将一个哈希表分成长度相等的两半，分别叫做T1和T2，给T1和T2分别配备一个哈希函数，h1和h2。在存储一个新的key时，同 时用两个哈希函数进行计算，得出两个地址h1[key]和h2[key]。这时需要检查T1中的h1[key]位置和T2中的h2[key]位置，哪一个 位置已经存储的（有碰撞的）key比较多，然后将新key存储在负载少的位置。如果两边一样多，比如两个位置都为空或者都存储了一个key，就把新key 存储在左边的T1子表中，2-left也由此而来。在查找一个key时，必须进行两次hash，同时查找两个位置。

实例：

海量日志数据，提取出某日访问百度次数最多的那个IP。

IP的数目还是有限的，最多2^32个，所以可以考虑使用hash将ip直接存入内存，然后进行统计。

3.Bit Map

类似遇bloom filter。若value==3，则将位数组第3位置1。这样，对于一串数字，进行如此造作后，从便利该位数组，若某位为1则输出下标，这样便完成了排序。

和插入排序很类似，但是其存储空间很小，适用于大量数据的排序，查重等操作。

实例

1)已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。

8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。 （可以理解为从0-99 999 999的数字，每个数字对应一个Bit位，所以只需要99M个Bit==12.4MBytes，这样，就用了小小的12.4M左右的内存表示了所有的8位数的电话）

2)2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。

将bit-map扩展一下，用2bit表示一个数即可，0表示未出现，1表示出现一次，2表示出现2次及以上，在遍历这些数的时候，如果对应位置的值是0，则将其置为1；如果是1，将其置为2；如果是2，则保持不变。或者我们不用2bit来进行表示，我们用两个bit-map即可模拟实现这个2bit-map，都是一样的道理。

4.堆

二叉堆是一种二叉树，最大堆为例，没一个节点都小于它的字节点。树是完全平衡的，并且最后一层的树叶都在最左边。

堆的操作主要是添加和删除。

适用

海量数据前n大，并且n比较小，堆可以放入内存

实例

最大堆求前n小，最小堆求前n大。方法，比如求前n小，我们比较当前元素与最大堆里的最大元素，如果它小于最大元素，则应该替换那个最大元 素。这样最后得到的n个元素就是最小的n个。适合大数据量，求前n小，n的大小比较小的情况，这样可以扫描一遍即可得到所有的前n元素，效率很高。

5.双层桶思想

当数据量过大的时候，进行比较，查找处理较为复杂，因此可以考虑将大量数据操作划分位对很多小部分数据的操作。直接看例子：

实例

1).2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。

有点像鸽巢原理，整数个数为2^32,也就是，我们可以将这2^32个数，划分为2^8个区域(比如用单个文件代表一个区域)，然后将数据分离到不同的区域，然后不同的区域在利用bitmap就可以直接解决了。也就是说只要有足够的磁盘空间，就可以很方便的解决。 当然这个题也可以用我们前面讲过的BitMap方法解决，正所谓条条大道通罗马~~~

2).5亿个int找它们的中位数。

这个例子比上面那个更明显。首先我们将int划分为2^16个区域，然后读取数据统计落到各个区域里的数的个数，之后我们根据统计结果就可以判断中位数落到那个区域，同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。

实际上，如果不是int是int64，我们可以经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域，然后确定区域的第几 大数，在将该区域分成2^20个子区域，然后确定是子区域的第几大数，然后子区域里的数的个数只有2^20，就可以直接利用direct addr table进行统计了。

3).现在有一个0-30000的随机数生成器。请根据这个随机数生成器，设计一个抽奖范围是0-350000彩票中奖号码列表，其中要包含20000个中奖号码。

这个题刚好和上面两个思想相反，一个0到3万的随机数生成器要生成一个0到35万的随机数。那么我们完全可以将0-35万的区间分成35/3=12个区间，然后每个区间的长度都小于等于3万，这样我们就可以用题目给的随机数生成器来生成了，然后再加上该区间的基数。那么要每个区间生成多少个随机数呢？计算公式就是：区间长度*随机数密度，在本题目中就是30000*（20000/350000）。最后要注意一点，该题目是有隐含条件的：彩票，这意味着你生成的随机数里面不能有重复，这也是我为什么用双层桶划分思想的另外一个原因。

6.数据库索引

7.倒排索引

所谓倒排索引的意思，就是建立索引的时候，不是按照key-文档，value-语素这样的形式建立，而是按照key-语素，value-文档这种形式，而且在value中保存了文档编号和该文档中出现语素的次数等信息。

因此在检索的时候，不必遍历所有文档，而只需便利查找的query关键字即可。

历史的河流

历史的河流打算按照日记的样子重新流过

Fedora 14 的一点指南

刚刚从Ubuntu换到Fedora14下面。原因是，fedora 的设计感更符合个人口味。

转过来发现，其实Fedora的UI还是很不错的。漂亮，而且有一些很人性化的设定。比如鼠标移动到右上角，就会转到程序切换的界面。

转过来之后遇到很多问题，比如在Ubuntu下面用deb的源太方便了，开始用yum的时候会有些不习惯，而且yum的源也不如apt-get的丰富，速度也很一般。所以第一件事情就是去找源。

1.设定更新源
虽然网上比较火的说法是上海交大的源比较快，但我是没装成功。我的感觉是，163和sohu的源速度还可以。这两个源可以自己去下载

mirrors.163.com

mirrors.sohu.com

163的比较稳定，搜狐的速度比较快。

当然也可以把两个源的repo文件代码拷贝下来，保存成repo文件，放到

1. /etc/yum.repos.d/

目录下面

之后，终端运行

1. sudo yum makecache

命令，源就可以用了。

2.wine设置

不是说离不开windows，这里说白了就是照顾没钱买vpn的朋友。目的是在linux下也可以用fg。懂了吧。

wine升级到1.3之后就不能wine fg了。我在Ubuntu下面搞了很久都没搞定。所以这里直接去官方网站下载wine1.1的源码。

进入源码之后，用

./configure

make

编译时会出错。提示

called object ‘pFT_MulFix’ is not a function

或者是

‘pFT_MulFix'不是函数

的错误。

google了半天，在官方网站的社区里面找到了解决办法。

把这里的patch下载下来patch文件，然后用命令

1. patch -p1 < 0001-Adjust-FT_MulFix-function-to-Freetype-cvs-head.patch

之后，错误消失。

接下来就是

1. make install

这个时候还是会出错。但是我忘了是什么错了。

解决办法还是在官方的社区中找到的。

把下面的代码保存成一个patch文件，比如保存成temp.patch，然后用和上面相似的命令

1. patch -p1

之后再make install。就ok了。

至此，wine安装结束。

剩下的可以参考以前的博客。传送门：

传送门啊传送门


3.安装libreoffice

在ubuntu下的时候我就换成LibreOffice了。更漂亮一点。而且OpenOffice好像很久不更新了，加上LibreOffice和谷歌的渊源，谷粉的不二选择。

这个安装到没什么，官方说的很清楚。去官方下载安装文件和语言包，安装方法官方说的很清楚。唯一的一个问题是，在用yum安装rpm时会有一个文件提示没有签名。

遇到没有签名的时候可以尝试一下这个nogpgcheck 参数：

1. yum -y --nogpgcheck localinstall xxx.rpm

就可以了。

另外，在安装LibreOffice的时候，官方给定方法是在下载的文件目录下

1. yum install *.rpm

但是我是用rpm命令安装成功的。只是在这里给一个其他选择。

今天先写这么多。

接下来还要记下来的是，显卡驱动,，Mendele的安装。

OpenVPN分析

OpenVPN

从架构上来看，OpenVPN在某种程度上和tinc或者和VTun比较相近，它是一个基于用户模式（user-mode）的程序，通过TUN/TAP接口与TCP/IP栈进行通信。作为用户程序运行的OpenVPN，带来了移动性和易维护性的优点，正如我们在VTun和tinc中看到的那样。和tinc一样，OpenVPN 在VPN服务中使用两种通道：一个携带用户的IP数据报文的数据通道，一个处理“密钥交互和配置(key negotiation and configuration)这种协议事务的控制通道。

OpenVPN 把两个通道都封装在UDP数据包中。两个通道使用相同的端口，所以一个给定的数据报既可以包含数据通道数据也可以包含控制通道数据。因为OpenVPN使用TLS协议进行认证和密钥交换，而TLS需要一个可靠的传输层，所以OpenVPN在控制通道中添加了一个可靠的层。这样保证了TLS所需要的可靠性，但是在数据通道中没有高可靠性的层（ but that there will not be competing reliability layers on the data channel），所以我们在SSL和SSH VPN 中看到的干扰现象不会发生。

正如我们在本章中其他VPN中看到的，OpenVPN可以携带IP数据报或者物理数据帧，它可以在IP层或者数据链路层进行操作。我们将把注意力集中在它在IP数据中的应用，但是其他模式是相近的。

OpenVPN 安全模式
OpenVPN 可以通过两种安全模式运行。两种模式各有利弊，但是正如我们将要看到的，只有一种使用与需要高于常规安全(more than casual security)需求的情形。我们在本节简明地介绍一下两种模式，但是把详细分析留给相对更安全的那一个。

我们把第一种模式叫做“静态密钥方法”(static key method)，在这种模式下，两个节点利用预先分享的密钥进行加密和认证。这些密钥在节点使用VPN之前协商配置。当然，这就意味着，必须使用其他的安全措施来在节点之间通知(inform)这些密钥。

默认情况下，有两个密钥：一个用来加解密，一个用来进行HMAC认证。在这种情况下，两个节点使用相同的密钥。配置OpenVPN使用四个密钥—可以这么做，而且这样更安全--每一个节点都有一个HMAC发送密钥和一个接收密钥，一个加密密钥和一个解密密钥。就是说，每一个节点都有一组发送密钥和一组接收密钥。这样坐的好处是，增加了密钥猜解的难度，并且降低了单个密钥被猜解之后的危害。

抛开使用四个还是两个密钥的问题，我们都应该警惕这种方式下，重复使用事先协商的密钥带来的弊端。同样的密钥将会用在VPN的整个生命周期，并且用在VPN的每一个请求，知道人为的改变或者VPN重启。尽管在不同的传输方向上使用不同的密钥可以减缓”使用相同密钥加密的数据量的增长速度“，但它能做的也就是减缓而已。最终，加密数据积累，事先商定的密钥变得越来越脆弱和敏感。一旦密钥被猜解，使用这个密钥的所有请求中的所有被传输的数据都变得可读。

传说中，静态密钥方法的优势在于，配置方便。VPN的管理员不许要被证书或者证书认证困扰，这正是第二种方法所需要的。（……）

第二种方法，被称作TLS方法，使用SSL协议来使每一个VPN节点和对应节点进行认证和交换密钥和其他控制信息。在这中方法中，OpenVPN为控制通道在它的节点之间建立一个SSL/TLS对话。在认证状态下，节点之间交换被信任的第三方CA签名的证书。这样保证了双方都确定都是在和他们想要的终端进行通信，同时也阻止了“中间人攻击”。

一旦认证完成，而且SSL对话已经在节点之间建立，OpenVPN就使用这个连接去协商数据通道的对话密钥。管理员可以配置OpenVPN基于任意传输的字节，报文或者时间去重新协商这些密钥。这样可以避免像头密钥加密的数据积累，而且提供了一个近乎完美的保密策略：猜解一个给定的密钥，不会影响到使用这个密钥之前和之后的数据。

TLS方法提供了一个十分健壮的认证和密钥交换机制。除了我们上面提到的短期的VPN服务，我们总是应该选择这种方法。下面的讨论都限制在这种方法上。

数据通道
正如我们前面提到过的，OpenVPN使用UDP作为他的传输协议，提供了一个良好的数据通道。

OpenVPN 可以选择TCP连接来代替UDP。尽管这在特定的环境下十分方便，但它重新引入了竞争性可靠层的问题，所以应该尽量避免。

通过UDP，我们得到一个类似的封装，如下图8.25：

OpenVPn 把负载头部分为两个部分：报文头部(packet header)，标识了报文的类型和密钥数据；和数据负载头部(data payload header)，包含了认证，IV,和数据报的序列号。




图8.26：

图8.26显示了TCP和UDP的报文头部结构。TCP版本中的packet length域显示了接下来数据报的长度。在UDP中不需要这此域，因为UDP十一个基于报文(packet-oriented)的协议，而TCP是基于流(stream-oriented)的协议。Op code域标识了数据报的类型。图8.27显示了所有可能的值。
图8.27

key Id域表示了数据报使用的密钥类型。我们很快会测试这个特性。

从8.25中可以看到，加密和认证的数据有一部分扩展到了数数据负载头部中。准确的机构在图8.28中有清晰的描述，结合了数据负载头部和数据负载。
图8.28

HMAC域基于标准的SHA-1或者MD5HMAC。正如图示，这个数据域对负载，数据报ID和IV进行了认证。IV是为CBC-mode加密生成的一个随机初始向量。

除了CBC加密模式，OpenVPN还支持CFG和OFB加密模式，都需要IV。

IV通常是64位或者128位。

packet ID 域作为序列号来防止重放攻击。OpenVPN为这些序列号保留了滑动窗口机制，如果接收的报文在窗口的左边，或者在窗口中但是已经接收过像头序列的报文，这个报文将被丢弃。如果接收的报文在窗口的右边，窗口将向右滑动，使得右边界位于新接收的报文序列处。这个滑动窗口机制和我们在tinc中看到的很类似。

除了滑动窗口，OpenVPn 还提供了时间测试，丢弃那些在接收到更高序列号的报文之后t时间的乱序报文( rejects out-of-order packets that are received more than t seconds after any packet containing a higher sequence number)。这个可配置的t参数默认为15s。窗口的宽度也是可以配置的，默认为64个序列长度。

图8.28显示了packet Id为32位，是它使用CBC加密模式时的长度。使用CFB，OFB，胡子哦和静态密钥模式时，他的长度都是64位。在CFB/OFB加密模式中，这个包含了时间戳和增量计数的64位数据包含在IV中，作为一种空间节省策略。

如我们所见，OpenVPN 的数据通道完美地满足了我们对VPN的需求：一个存在域主机或者网络之间的加密和认证通道。我们讨论安全性时将会看到，数据通道的设计十分优秀，不存在任何明显的安全缺陷。事实上，它精确模仿了IPsec ESP协议，而且在此协议在发展和部署中学到很多优点。

Ping和OCC协议
除了传输用户数据，数据通道还携带限定数量的控制信息。OpenVPN可以设置为使节点发送“维持(keep-alive)”消息，如果他们没有在规定时间内接收到这个消息，则可以关闭或者放重启VPN连接。尽管OpenVPN把维持消息看作ping包，但是他们并不是ICMP下的ping包。接收到这个ping，节点会重置接收时间并丢弃ping包。这个ping包作为一个携带一个唯一序列号的普通数据通道数据被传输。

应该注意到，这个协议只是要求每一个节点不要太久不在数据通道中发送数据。如果一个节点在超时之前没有接收到数据，它就可一根据配置来重启或者关掉VPN。一个节点并不期望得到ping包的回应，甚至不知到对方是否收到了自己的ping包。

在通道初始化的时候，节点使用OCC加密模式相互加换配置信息。和ping包一样，这些信息作为普通数据通过数据通道传输，并且通过一个唯一的序列号来和其他数据包区分。通常，这些信息的格式如图8.29所示。
图8.29

OCC magic域是一个16位的唯一序列号，用来标识OCC数据包。这是必需的，因为数据通道的数据报没有message type 域。OCC op code域标识了OCC信息的类型。最新定义的op code值如图8.30所示。
图8.30

可选的OCC data域包含了任何OCC 信息所需要的数据。比如，在OCC_REPLY消息中，OCC data域包含了节点的option string。

控制通道
正如我们在SSL，SSH，和其他轻量级的VPN一样，提供一个安全的数据通道的两大难点是，密钥管理和节点认证。这两个方面任意一个出现错误都可能到值数据通道的不安全，不论数据通道本身的设计如何优秀。在这一节，我们会看到OpenVPN如何处理这两大方面。

OpenVPN的一个优势在于，它使用SSL/TLS协议为节点提供密钥管理和认证。因为SSL协议在多年的深入发展和研究中，其安全性已经被专家们普遍认可，OpenVPN可以利用它的安全性保证VPN的安全。

图8.31显示了控制通道数据的格式。

session ID 域是一个64位的随机数，用来标识VPN会话。如同我们在其他协议中所见，VPN通信的每一端都有自己的session ID，在此域中出现的是发送放的session ID。

可选的HMAC域用来帮助防止DOS攻击。当使用它时，它对整个数据报进行认证，并且允许节点不需花费任何执行资源就可以丢弃一个伪造的数据包。它还可一防止一个伪造的数据包到达SSL层以探测安全缺陷，或者造成潜在的信息泄漏。此域只有在—tls--auth选项开启的时候才会出现。

packet Id域用来防止重放攻击。它和在数据通道中扮演的角色相同。当使用TLS方法时，长度位32位，否则就是64位。

可靠层使用ACK buffer 来获知一个节点的数据包。ACK buffer length域是单字节，用来标识后面信息的长度。如果是0，则ACK buffer不存在。如果大于0，则包含了ACK buffer中32位信息序列的个数。在ACK buffer 的最后是节点的session ID。节点通过这个session ID 把ACK buffer的信息和一个特定的VPN会话绑定。此session ID 也只在ACK buffer length不为0时出现。

如果这个数据包的op code是P_ACK_V1，那么ACK buffer是数据包中最后一个域。如果是P_CONTROL_V1,message sequence number域，也就是可靠层使用的序列号，包含了常规SSL数据记录的还有TLS payload 域，都会出现。

当VPN启动时，节点执行标准的SSL客户端认证握手行为。在这个行为中，通信双方都会位对方提供自己的证书。经过认证，双方都确认他们在和预订的节点对话，而且拥有了一个安全的SSL通道来位数据通道提供密钥信息的交换。

有两种密钥交换的信息。当节点根据opcode V1设定使用方法1（图8.27），它们使用的消息格式如图8.32所示。
图8.32：

cipher key length 域包含了cipher key 域的长度，cipher key中包含了一个随机生成的密钥供接收方解密使用。类似的，HMAC key length域包含了HMAC key域的长度。HMAC key包含了一个随机生成的密钥，供接收方对接收的数据包进行认证。应该注意的是，这里将会有四个密钥，双方各有两个。再次强调，这种方法并不完善，因为所有的密钥都由一个单独的节点完全决定。

最后的域十一个不定长的option string。option string必须和本地的option string匹配，保证两个节点的配置一致。

方法2必方法1要更加完善。每一个节点都提供了双方生成密钥的密钥数据。当方法2被使用的时候，如8.27的V2设定，节点间的交换数据，使用如下的消息。
图8.33：

如图所示，这个消息以4个字节的0开始，跟着是一个字节的key-method域。现在，这个域通常是2，标识这密钥交换的方法2，但是这个域允许以后添加更多的方法。

premaster secret域是由客户端生成的48位随机数据。此域提供的服务和SSL中的同名域相同：提供一个可以生成master secret的生成数据。premaster srcret域在服务器间的密钥交换中不被使用。

接下来，random1和random2两个域也在密钥生成的操作中使用。他们是32位的随机数据。因为通信双方都提供两个随机域，所以两边都不能当方面决定密钥。

optionstring length 域包含了不定长数据option string的长度。如同方法1描述的那样，节点使用option string来判别双方的配置是否一致。

user name length域包含了不定长的user name域的长度。相似的，password length域包含了不定长的password域的长度。user name和password 用在OpenVPN 运行在HTTP代理，而代理需要认证的情况。这些域可选，并且只在我们使用HTTP代理的时候使用。

密钥生成阶段和TLS使用的方法十分接近。首先，两边都通过OpenVpn master secret,客户端的random1,服务器端的random1来生成maste rsecret，使用结果和premaster secret作为输入来计算HMAC。

PRF(premaster secret, OpenVPN master secret || client random 1 || server random 1)

PRF函数对参数进行MD5和SHA-1 HMACs运算，并对结果进行或运算。

实际的PRF的细节比这里介绍的复杂一点。PRF函数首先把secret分成两部分，一半用来生成MD5的HMAC，一半用来生成SHA-1的HMAC。所需的输出长度是通过重复把种子数据反馈给HMACs来的到的。

一旦节点拥有了master secret，他们将利用OpenVPN key expansion(客户端random2，服务端random2，客户端session Id和服务端session ID)生成四个输入密钥（加密，解密，输入认证，输出认证）。结果和master secret用来作为PRF的输入得到密钥。
PRF(master secret, "OpenVPN key expansion" || client random 2 || server random 2 || client SID || server SID)

在密钥交换之后，数据可以在数据通道中传输了。数据通道中的数据包都用刚才生成的密钥进行了认证和加密。当需要更换密钥的时候，就重新进行密钥交换。如果不关心是方法1还是方法2，它看起来就像是最初的交换一样。为了帮助新密钥的传输，OpenVPN提供了下面三组密钥：
1.active keys
2.lame-duck keys，收回的密钥
3.另一个lame-duck keys，当密钥协商失败的时候使用。

这三组密钥解释了数据报头部的key ID 域。key Id标识了使用三组中的那一组密钥。

OpenVPN 安全性分析
不写了睡觉去。总之安全性很好。有兴趣的看原文去。

暗夜红天（译“red sky at night”）

By Matthew Juke（新闻作者，译者注）      

20世纪九十年代，中国从一个封闭的壳中苏醒，开始看到越来越多的科幻作家涌现出来。在我们面前的，则是中国最突出也是最高产的两位科幻作家，韩松和潘海天。书虫准备在三月十七日的中国科幻和中国未来的主题中邀请此二人（who are going to be putting forth the case for Chinese science fiction and the prospects for the future of the country at the Bookworm on March 17.） 

在此之前，他们对环球时报谈到了科幻的过去，当下，以及在未来的状况。 

第三代（Third foundation）

早在变革和开发之前，中国科幻便开始了复兴(emerge)。而当下，这两个人都被看作是中国第三代科幻人。

在20实际80年代，也就是所谓的“黄金年代”，中国开始大量翻译西方的科幻小说。在这段时间，这也是他们的启蒙年代。说起克拉克，阿西莫夫，飞利浦·K·迪克，两个人都认为科幻在中国并不是小众市场，而是一个代表了中文文学新方向的巨大市场。

“中国并没有科幻的传统，”韩松说道，“有策略小说，有幻想小说，有悬疑小说，但是没有科幻。而且也没有科学的传统。在早期，我们有四大发明，但是没有教授科学的老师；中国人喜欢在历史中，在现实中，在想象中寻找真理，不是在未来。”

正是这一点让中国科幻很独特。并不只是在情节和语言上，更是在视野上。作为一个封闭了很长时间的国家，中国的丢掉了科幻的目光，即使仅仅是对外事务的处理，看起来也是一个世纪之前的事情了。

“中国人很少作为一个角色形象出现在科幻小说中。在最开始，中国科幻小说只能去处理中西方世界的关系。”韩松说，“中国曾数次被西方历练入侵，在他们（作家）的脑中，他们拥有对西方社会和西方人民的幻想。西方科幻有外星人，我们有西方人。”

在韩松的主要作品《2066，美国上空的红星》中设置了一个反乌托邦的英国，这个国度在经济危机中备受煎熬，生活在当时经济发达实力强大的中国的阴影下。韩松在这部作品中对东西方矛盾上的反应十分强烈，他设想了一个强大的王朝将扮演一个对双方都产生消极影响的角色。

然而，韩松承认他周围的事物影响了他的写作。一条对时事的评论可能就将成为故事中对一个未来场景的设定。潘海天也同意生活有部分影响，但却对于如何定义现代科幻小说十分纠结。他引用了他数年前提出的一个定义：

“科幻小说应该设定在极端的环境，典型地代表人类的一个部分，或者象征整个人类行为或思想进程。”潘海天解释说这是他从十年前开始思索，“它需要孤独，恐惧，疯狂，愤怒，贪念这一系列隐藏在人类潜意识深处的要素。它们只有在极端环境下才能被暴露。”

善于言辞和幽默的潘海天现在决定改变自己的观念，部分归结于他在《九州幻想》的工作。

“现在回头看看这个定义，我太能赞同它。我常会被和我在线争论这个定义的读者搞的很焦虑，这也是为什么我要去做一个科幻杂志的编辑，因为我说它是科幻它就是。”

是否应该为幻想文学设立专架，或者说这个这个文学类型有没有足够读者去自给自足，这个问题在欧洲作家和书店之间久争不衰。然而，在中国，这个不是问题。

“中国人其实拥有想象的传统，在过去他们曾经创作了大量精彩的幻想故事，比如《山海经》，《西游记》，《草堂笔记》，《 Strange Tales from a Scholar's Studio（我不知道是什么）》，《建国大业》等等。”“只要中国作家开始拓展自己的事业，我相信中国科幻将成为这个年代中最有可塑性的文学类型，没有之一。”

“如今已经有了一个十分清晰的概念了，魔幻文学要多得多，魔幻作者的数量也几倍于科幻作家，也拥有更大的读者群。再一次，这也只是因为魔幻在中国更贴近传统。”韩松说，“但是科幻和魔幻都提供了一个从不同方向审视社会的新视角。”

黑暗扫描者（Dark scanners）

反乌托邦的故事已经是科幻的一个传统。在当前经济萧条的背景下，全球出版商都囤积了大量描述世界末日，反乌托邦，和未来世界崩坏的手稿。

我们曾经想，从当地书店找到一些类似的书应该很不错。但是韩松叹道我们不可能找到一丁点只言片语。

“在中国的科幻作家很少，而且理所当然的他们不都是很优秀。一个重要的原因就是，在中国的作家都被作协领导，”潘海天悻悻地说，“他们把文学类型分成几个子类。”

“我们属于儿童文学。”他补充道。

和很多其他作者一样，在出版之前，韩松的书稿常常要在各个出版商之间推送很多年，他们都不愿处理这样一个沉重的主题，或者是为“敏感素材”担心。潘海天的情况也是一样。

“通常来说，一部小说要哪位编辑审查，哪位编辑就要为这部小说负责，”他说，“关键在于相关的法规总是模棱两可难以摸定。”

据韩松所说，出版商这种“但求无过”的态度，归结于涉及到遥远未来的臆测小说。设想一个不是那么光明的未来的这种行为会吸引到努力让世界更买好的民众的大量目光。

“在中国写一部科幻下会所很容易。你甚至不需要想象，你只要记录下每天在社会上发生的事情，集合起来就成为了一部科幻小说。有时候你写信为就好象写小说一样。”韩松说。

韩松曾经写过一个短片，《我的祖国不做梦》，在这部小说中，中国的发展已经缓慢，人们赞同偷偷注射能够让自己通宵工作的药物来维持GDP的增长。

听起来有点像Orwellian（《1984》作者，译者注），不过韩松认为有所不同。

“Orwellian 是对社会不满和苛求。不同之处在于，我们爱中国，我们不想让中国堕入魂阑，但是我们很担心她的未来，”他说，“有一天中国的发展会停滞，我们就得日以继夜的工作，没有压迫，他们自己如此选择。如果他们休息，那么国家就将崩溃。”

《我的祖国不做梦》从未纸质发表，却在网络上传播。在读者可以一睹为快的同时，作者却无法得到可以让写作作为他们职业的收益。有可以做到的办法只是需要代价，韩松说。

“比如说，你用乐观的思路写作科幻。作家去描述一个十分光明的未来，灿烂而稳定，类似的东西，”他说，“如果每个人都这么写，我们就要做很多愚蠢的工作，不过他们可能能挣到钱。”

书本奥德赛（Book odyssey）

现在对中国科幻来说还太早，同时两位作家都表示自己对用英文写作并不反感，对于那些幸运的，能够欣赏到完整的想象实力的少数精于语言能力的读者来说，这是个振奋（left）的消息。

“我想情况在变化。我不知道美国和英国如何，但是我认为相对中国好多了。至少我能列举出一些欧美作家的名字，你们那有多少人知道我呢？”潘海天说。

如果你想要更深入的了解，你可以在明晚的“书虫国际文化节”（Bookworm International Literary Festival）遇到他们。

（看到英文版，想下干脆翻译下来好了，第一次翻译，很多不懂啊我又不考GRE。附上原文：http://msn.huanqiu.com/chinalife/community/2011-03/1565756.html）

渡边，青豆，和卡夫卡

这一段时间，一直想写一点关于村上春树的一点感受，现在终于有时间了。刚洗了澡，宿舍还真冷。


接触村上春树，算是从10年刚开始。当然，在早一点，高中的时候算是久仰过大名，但也只限于听说过那部《挪威的森林》。


真正用拜读的态度去读村长，应该就是从《挪》开始。我一直以为在此之前并未接触过村长的文章，然而某天翻开一本村长短篇小说集的目录时，一篇《电视人》赫然跃入眼底。


这真是一种戏剧性的邂逅，原来很久之前，我和村长的第一次相遇，竟然是在《sfw》上的一篇短篇科幻小说，正是《电视人》。


那时lz年幼，对这篇文章作者并未在意，但是当时这篇文章怪异的行文方式让我印象深刻，也因此，《电视人》这个标题深深刻入脑海，以至于在反倒文集目录的时候，才恍然大悟。村长兄，原来你就是当年路过窗前的那个怪异少年啊。


为什么忽然想读《挪》，原因已经记不清楚了。然而事实是，这是我难得的正确决定之一。


lz对《挪》十分喜欢，无论是故事本身，还是讲故事的方式，都十分精彩。我习惯在手机上面读书，可以利用等人，等车，等饭，等眠的闲散时间随时阅读。但是在看过《挪》之后，决定一定要买下一本，摆在书架上面。过几天回家之后，打算再重新读一遍。


当时去书店买《挪》的时候，已经有《1q84》的book1出售了。当然，1q84 book1到book3 我也是在手机上完成的。


后来，又一次在坛子里面某个帖子里面提到了《1q84》，说有些科幻（那时候还没注意到《电视人》出自村长手下），有同学说，村长很多东西都有些科幻的味道，比如《海边的卡夫卡》。当时我手机里面已经有了村长书记的一些收集，但是也许是受到这句话的影响，我决定接下来要读《海边的卡夫卡》。


读完之后，对村长的感受逐渐清晰，遂著此帖。






好了，直接进入主题。


先抛开《挪》不说，《海边的卡夫卡》与《1q84》之间有很多类似的设定。一个孤独的人的冒险（离家出走的少年和青豆），主角的特殊身份（最顽强的十五岁少年和女杀手），主人公背后的智力支持（大岛和老妇人、肯德基大叔），魔幻色彩的世界构造（“入口”和小小人），双线索（卡夫卡+中田，青豆+天吾【+牛河】），命运主题等等。


这在某些程度上，也许体现了村长的故事构成方式。当然只是某种程度上，因为在《挪》和村长的出山作品《且听风吟》中，都是更加现实的叙事风格。


从故事上来说，《1q84》明显是一个大坑，在读完book3之后，一般都会有一种被骗的感觉。


我了个去，坑爹呢这是，小小人到底是个啥啊，NHK收费员到底是个谁啊，猫的小镇到底是个啥啊，难道一句“王子和公主从此幸福的生活在一起”就像混过去么？玩儿蛋去吧村长！！！！！


没错，太多事情没有交代清楚了，就好象一部悬疑小说，最后却没有给出最后凶手一样。这种感觉，并不比在看《少年金田一》的第一页就看到以前的读者用黑色碳素笔圈一人还写出“这就是凶手”的感觉好到哪去。


其实《卡夫卡》这部小说，也有很多事情没有写明白（虽然要比《1q84》好很多）。度过《卡夫卡》之后我开始思索，村长到底是想写什么呢？如果《1q84》的大坑不是第一次这么做，那么就不是自己挖坑填不上，或者是自己尝试新风格的问题。


在《卡夫卡》这部小说中，经常提到一个词“暗喻”。尤其让我印象深刻的是，大岛解释迷宫的时候，说迷宫的由来是远古时候人把肠子取出来，根据肠子的纹理进行占卜。所以肠子即迷宫原型。人的内部是迷宫，这是暗喻。这种暗喻在文中彼彼皆是。这是由作者在文中借大岛和卡夫卡的讨论说出来的暗喻，那么作者没说出来的，真的暗的暗喻又有多少？


《1q84》中这种暗喻有多少？


在《挪》的《序》中，介绍村长时有提到，村长丰富的想象力造成很多精妙的比喻。这点在他的文中确实很明显，但是从这种略带魔幻色彩的超现实主义小说中，恐怕暗喻要比明喻更多，甚至多出一个数量级也不一定。


《1q84》也好，《海边的卡夫卡》也好，其实不是柯南道尔或者希区柯克或者刘慈欣的作品那种，好像齿轮一样紧紧咬合，严丝合缝。相反，故事只是一个暗喻的载体。我也说不清楚，这算不算是一种故弄玄虚，但不得不承认，村长把这种暗喻摆弄的很漂亮。


怎么说呢，也许在你看完这两部小说之后会觉得意犹未尽，（或者说根本就应该有一个book4来打补丁才对吧）但是就像是玩试玩版的游戏一样，尽管没有100%完成度的快感，但是一部优秀的游戏，能让你在试玩过程就有良好的体验。


就是这样，让你最后一直想拨开迷雾，将书中的世界尽收眼底，这在某方面说明，这个书中描写的世界将你牢牢吸引了。


也许，村长自己也不知道这个世界到底是怎样的。


我在《三体》那个帖子里面提到过，《三体》中曾经描写了一种“以构造人物为中心”的创作方式。如果用这种方式类比，我觉得村长的这两部作品，是以“构造世界为中心”。用某种方式给出初始参数，好像推到多米诺骨牌的第一张牌，然后会怎么样，作者自己也没有力量决定了。之后村长要做的，无非是把这个初始参数创造的矛盾，神秘的世界用文字记录，描述出来而已。类似一种文学上的思想实验。


从描述方式上来说，无论是第三人称，还是第一人称，村长讲故事的节奏都很平淡，平淡到有些像说明文一样。他不想《三体》那种，在最后跌入二维的时候明显就是一轮高潮，之后的故事明显就是缓缓滑落。如同晴天->多云->骤雨->收云这种过程。村长从头到尾就是，雾->雾->雾->雾->...，无论村迷雾中跳出多让人吓一跳的东西，说书人都波澜不惊。


但是，讲出来的故事，却异常引人入胜。


一个原因，我想大概是由于村长对书中的世界描述的异常清晰，让读者亲临其境。


书店，酒吧，健身中心，公车，图书馆，旅馆…………即使讲述的是最不可思议的奇迹，就算是小小人创造的神迹，发生地点也都是这种普通的不能再普通的地点。在神迹发生的时候，也没有什么引人注目的光影镜头出现，都是极其朴素的现象“物体飘逸”，“雷电”，“石头的重量变化”等等。这大概也是一种暗喻，村长没有把那种怪异的现象写的更加怪异，而是用暗喻的手段，用现实暗喻超现实。就像通向异世界的森林小路，或者两个月亮。


村长造了一个世界，但只给读者看了从我们角度可以看到的东西，由于透视原理和一些角度问题而看不到的东西，他并没有可以拿出来给我们看，而是用暗喻这面镜子反射出来。


我在读《1q84》的时候真的怀疑，村长是写的小说么？会不会《1q84》便是《空气蛹》呢？会不会村长便是深绘里呢？


前几天在推特上看到一个人在读《1q84》，他写道“天上好像真的有两个月亮”。


让人沉浸在书中无法自拔，这种力量是一种强大到可怕的实力。


以前坛子里有人说，你们喜欢《挪》是真的喜欢还是人云亦云？《挪》里面不过是一种颓废的无病呻吟。（大意如此）我看到这条评论，也有反思。lz年轻的时候，非主流文章也看过不少，滥用悲伤基调，用悲剧去博取同情这种行为的确更容易俘获人心。但是《挪》不同。虽然确实充满颓废，消极的基调，但是真正打动人的，不是靠这些东西，而是故事本身，和讲故事的方式。


作者写这部小说，是从短篇《萤》扩写出来。在《萤》中，只有“渡边”和“直子”两个角色，而且也直写道直子不辞而别。在《挪》中，又加入了很多其他角色，情节也更加丰满悠长。剧情并不复杂，没有刻意的制造矛盾（类似琼瑶或者韩剧的姐弟恋，贫富恋，家族乱这种狗血剧情丝毫没有）。及时主人公同时爱恋两个少女，除了自己内心的迷茫之外，并没有人物关系的纠结。




从头读过，读者所经历的，便是渡边所经历的。从消极生活，到遇到直子，到对绿子不知所措，到时去直子是的悲痛心境。这种经历，不是一句“颓废基调”可以概括的。尤其是读到渡边因为直子的去世，悲痛的不能自已，独自一人毫无目的的沿着海岸流浪那里。遇到一个好心人给他食物，以为他的母亲去世而安慰他。渡边因为不想解释什么，只能听他讲述他自己母亲去世时的感受。“你知道我失去什么了么？直子去世了，再也会不来了，你却在这里说什么你母亲！”


这种感情的宣泄不是随随便便就可以完成的，这是建立在前面完成的铺垫上。


村长的故事，大概都是这样，在爆发点，不用可以描写气氛，是一种水到渠成，所以即使是描写最震慑人心的情节，也只需要最朴素沉静的语言。


我了个去，这中水平，我感觉到了诺贝尔的水准……










此外，村长的作品中对音乐的描写算是一种特色。从名字来说《挪》和《海边的卡夫卡》都是音乐的名字。《1q84》开场就是青豆和出租车司机对交响乐的讨论。


在他的作品中，常常会出现对摇滚乐和古典交响乐的讨论。对于我，其实很多是无法理解的，因为本身对他所讨论的音乐没有欣赏能力，所以往往不能体会他所说的感受。然而，在村长的作品中，音乐总是用一种魔力的载体。


它是皮诺曹的蓝色仙女，是星矢的雅典娜，是大力水手的菠菜，是我镜子里的背影。


在《海边的卡夫卡》中，星野偶然经过一家咖啡屋，听到了贝多芬的交响乐，从此改变了一生。卡夫卡在和大岛对音乐的讨论中，也渐渐体会到了生命，时间或者是人生的意义。在接近结局的时候，卡夫卡不知要怎么做。佐伯说:“看画，听音乐。”


在《挪》中，玲子和渡边为直子独自举行直子的葬礼，便是用吉他自弹自唱，将自己能弹出的曲子全部弹出来。真是罗曼提克。


除了音乐，村长也常常在文中加入一些对文学作品的讨论。


在《挪》中，渡边第一次遇到永泽，也是因为相同的文学喜好。


而《1q84》中的天吾，本身就是一个作家，所以自然少不了对创作的描写。


至于《海边的卡夫卡》，因为卡夫卡和大岛生活在图书馆中，大岛对卡夫卡的指导往往会旁征博引。


在这些对文学的探讨中，我有时会遇到自己熟悉的讨论主题，但是很多时候都超出了自己的阅读范围。也就是说，比那些对音乐的探讨理解稍好一点。


在这些对文学和音乐的大量引用和讨论中，几乎很少会感到村长的掉书袋，或者不和谐感。原因大概是这些讨论放置的位置恰到好处，在对的地方，对的时机，对的人，讨论一件对的事情。


在《海边的卡夫卡》和《1q84》中，都提到了切克夫斯基对戏剧的论点：“如果舞台上有一把枪，就一定要发射。”看来村长是很赞同这个论点的。在某种程度上，村长也是切身履行了这个论点。也就是前面提到的，后面的情节发展总是建立在前面的情节铺垫上的。情节几乎没有缀余。


这也让我偏向相信，村长的某些看似无用的情节，应该是一种暗喻。


这次回家，决定把《挪》和《海边的卡夫卡》再读一遍。


另外，有一个1q84.fm音乐电台网站，刚刚面世的。可以去看看。