这个要从大调式讲起。

    大调式是以大三度为基础构建的调式，主音到中音为大三度，中音到属音为小三度，两者构成大三和弦。主音到属音为纯五度，属音到主音为纯四度，大调式的三个基础音之间，都是和谐音程关系。以C大调而言，就是do mi so。

    好吧，C大调之所以叫做C大调，是因为以中音C为do。那么G大调呢？以中音G为do？对的，问题是，C大调的所有音，是否能够不做任何变化的构成G大调的音？

    这是不可能的，C大调的音不做变化唯一能够构成的只有a小调。G大调一定需要对C大调的音做升降的。

    为什么？因为C大调的音程关系是全全半全全全半，这个在小学就教了。通过这个，你可以数出上面说的三个纯音关系。当我们位移到G=do的时候，你会发现，不做变化的话，音程就变成了全全半全全半全，这就糟了。所以，需要对C调的fa(即F)升半个音，来回复大调调式。

    常识上我们知道，12平均率是对称关系，所以上述过程可以运用数学归纳法作用于整个中音音阶。即，每个大调可以通过升该调中的fa半个音，变成另一个大调。后者刚刚好比前者高一个纯五度。

    降调关系亦然，可以类比。

    小调关系亦然，不过小调使用全半全全半全全作为结构，主音到中音为小三度，中音到属音为大三度，两者构成小三和弦。主音到属音为纯五度，属音到主音为纯四度，小调式的三个基础音之间，也都是和谐音程关系。

    稍微数一下就知道，小调式上的所有音，可以构成比自己高小三度的大调，两者称为关系大调和关系小调。

    虽然音是一样的，然而主音中音属音的位置完全不同，因此调式色彩完全不同。

    目前有很多服务，其实我们都是按照非正规用法在用的。例如github，看上去像是个源码托管服务，我们拿来当blog用。GAE，看上去像是个代码托管服务，我们当翻墙工具用。空间，常规都是发布应用的，我们也拿来翻墙。

    对服务的非正规用法，我们首先把这个命题分几个类。一类是服务本身没有对用法做出特殊假定，但是你的用法和传统用法相违背，例如VPS传统是作为私有主机用的，用于发布网站。但是天朝人民经常用VPS当作云存储，或者是VPN。作为这类用途，我觉得是没有任何问题的，服务商本身就没有限定你的应用类型。

    第二类，是服务商默许或者半鼓励你作为特殊用途应用。例如github并不反对你用他作为blog。这也没问题。

    第三类，服务商明确反对的用途。例如利用空间来翻墙。一来ssh流量并不计入你的流量限额中，二来长期使用空间翻墙会导致空间的服务器地址在中国被封。前者影响成本，后者影响销售。因此，很多空间商都封锁了ssh的跳板功能，例如DreamHost。

    也许有人会骂，空间商为什么要阻止ssh，这是对自由人权的破坏什么的。我觉得这压根是骂错人了。如果你无法自由浏览你想要浏览的网页，你需要骂的是阻止你访问的人，而不是别人。空间商既没有封你，也不是帮凶。通过对人有害的方法获得自己想要的利益，别人阻止你还骂人，这是流氓嘴脸。

    第四类，服务商没有明确回应，他们可能对此一无所知。这种情况最复杂，也最值得讨论。

    无论空间商默许还是反对，我们都可以看作是一个附加合同。这种事情你同意就接着用，不同意就换家人，市场经济大家好聚好散。但是服务商没有明确回应，那么事情就比较暧昧。我倾向于将事情分为两个阶段，或者类型。一类是影响较小，或者刚刚出现，服务商有理由不知道。这种阶段下，该怎么用就怎么用。直到服务商有表态为止。另一类是我们有理由相信服务商知道这类用法。在这种阶段下，你不妨参照第二类。

    当然，这里顺便说另外一个话题，就是很多人对翻墙的要求是——免费。

    我去阿，你在中国网络上玩多了，啥都要免费，有没有写信给电信要求宽带接入免费阿。你要是真没钱，要么就不用，要么就学学怎么让自己出去。

    天下的特权有几类的，一种是你通过努力来获得某种特权，一种是你付钱让别人帮你获得这种特权，一种是左求右拜，借到某种特权。这特权还不稳固，有点问题就让人收了回去，因此不得不小心翼翼，缩着尾巴做人。且不提现实中有个头痛脑热，行政手续，求爷爷告奶奶的诸多无奈。那毕竟很多时候还是不得以而为之。网络上凡是有点大小P事，全是“360度冰天雪地裸体跪求”，就这种人还自诩为“不食嗟来之食”之后，实在让人叹息。

    墙的存在意义，就是要“拦截大多数”。要稳定翻墙，基本就两种途径。一者是牛，自己付出辛苦，学会了整个过程，从而翻墙出去。或者你付钱，弄到了翻墙帐号，从而翻墙出去，这也是一种。这两者都算的上少数，剩下的就是绝对的大多数。既不付钱，也不想付出辛苦，张口就求各种方法的人不知有没有想过，当某种方法会的人多了，墙自然就会把这种方法连根铲掉。法子不能用了，瞬间破口大骂给法子的人，不知道脑子里转的是什么逻辑——或者是，他们其实想过，只是：

1. 在中国，只要考虑三天后的事情，三个月后的事情谁说的准呢。

2. 在网络上求爷爷告奶奶也是一种辛苦阿。

    ——我已经连叹息都发不出了。

    最后一个话题，如果你的某种对服务的应用，对其他人会产生伤害怎么办？例如，你用某个空间翻墙，这个空间IP就可能被墙。你用GAE翻墙，GAE就会被墙。你在网站上发表很合理的言论，自己没事，站长进去了。

    首先请允许我就最后一个例子向中国的有关部门表示无比的XXX。。。就这精确度还好意思指责人家老美的导弹？

    我们先说最后一个。很多人往往鄙视中国的网站管理者，我写个无比正常的内容你都给我删了。实际上，在一切不正常都当作正常的国度，再正常的内容都可能是不正常的。我是挺同情网站的管理者的，删把，道义上挺站不住的，不删吧，自己进去了。某种意义上说，开网站是为了赚两个钱顺便提供娱乐的(当然，很多人是反过来的)，而不是为你表达言论挺身而出的——真是这个目的开的网站现在站长的骨头都在长草了——从这个意义看，删，不是恶。如果你要指责，应当指责的是这个制度和产生这个制度的原因。

    但是，我又要但是了，这也有个度。删本身不是恶，但是捕风捉影，删了不说，不删，偷偷让别人看不到，这就沦为不道德了。只是在中国，各种事情交错纠缠之下，人人皆提心吊胆提防别人，往往事情就会走了样。

    这里插一个前两天的段子。魔都地铁是要安检的，大家知道。坐地铁的经常听说保安和你争执两句就躺地上装死讹钱的例子。前两天过地铁的时候，把包拿给保安检查。保安摸到我的饭盒，说，这是啥阿。我刚要说话，旁边保安示意放行，小声说，摸坏了你赔不起。

    ——那地铁安检的结果就不言自明了。

    因此，在层层把关的网络审查中，往往下层执行的东西和上层想的差了十万八千里。其距离大概就和客户心里的网站和项目经理笔下的网站和工程师手下的代码的区别差不多。

    当然，即便结论如此，我还是管我自己。我的blog都是在自己的域名下面——结果被封，也是自己的选择。如果发到其他网站，能不能留，留多久，就看别人的意思了。

    至于使用GAE翻墙的问题，我觉得适用于我们有理由相信服务商知道的情况。我相信Google一定知道上面有人放什么网站，做翻墙用途。既然他没有反对，我们可以看作是他默许。

# 我有必要换git么 #

实话说，这得分干吗。目前的推荐是，如果是企业级项目，对权限要求比较严格，你必须用svn。如果是普通项目，你可以尝试使用git，但是这并不表示git是最适合你项目的。有的时候svn比git合用的多。

# svn是什么模式 #

svn的核心思路是，取出，修改，提交，合并。即，你从核心库中取得数据，修改，然后提交上去。如果有两个一样的修改，那么要求你进行合并。当然，svn工具会首先尝试自动合并，然后再让你手工干。但即使如此，合并的时候还是很费力。

svn的模式很容易理解，然而在使用中却有两个实际缺陷。

1. 保存数据的唯一方式就是提交，而提交是不可撤销的。

2. 必须连接核心库使用。

第一点问题，就是说，如果你希望暂时保存一下当前的修改状态，然后进行某个测试性修改。如果失败，退回当前。抱歉，做不到。你的提交一定会进入svn库。虽然你可以退回到你提交前的版本，但是很麻烦，而且版本记录不会消失。而第二个问题更加致命。如果在网络不稳定/没网络的时候，还干不干活了？

因此，svn的设计模式并不鼓励你提交。当你有修改的时候，你必须保持修改的状态，直到某个稳定的状态。你需要检查代码是基本可用的，然后才应当提交。svn提交有个基础原则，不能塞住head，讲的就是这个。

# 所以有了hg #

hg正是为了解决上述问题而出现的。hg实际上是用python实现的，解决上两个问题的svn。

hg拥有本地版本库，这解决了离线模式。至于暂存性提交，你可以在本地随便提交。只要不提交到核心库上，就不会导致塞住。如果你觉得本地库不行，可以直接重新co，而不进行push。

# git和hg哪个好 #

锤子和扳手哪个好？我永远无法回答你这个问题，因为这两个的目标根本不同，因此根本没有可比性。同样，git和hg的工作流程和模式完全是两回事，因此不要问这个问题，没意义。

# 哦，那么git是 #

git的设计核心思路，是取出，分支，修改，提交，合并分支。git的分支是处理工作的利器。

要彻底理解git，你必须接受平行世界假定。假设世界并不是顺序发展的，由于你的选择不同，而会变成不同的几个分支。git可以让你在分支间自由穿越，并且让世界变成某个分支上的某个点的状态。你可以重新选择，产生一个不同的分支。当你需要时，可以对两个分支进行合并。如果两个分支从源头分开后，对世界的影响各自不同，那么合并就是自动的。

git的同步就是在同步这颗世界树。树扩展成什么样子和你在树的什么位置没有关系，因此fetch后如果不chechout，那么就不会应用最新的修改。

# 我没看出多大区别 #

实际是非常大的。有了平行世界假定，我可以正交的对一个源码做两件以上不同的事情。而在hg中，虽然也可以做两个不同的分支，然而却很难在两个分支间切换，从而使得切换到做另一件事情非常困难。这也导致了一个人实际上只能做一件事情，否则就无法将过程同时纳入vc管理，又满足正交。

第一次参加BSP，还不错拉。因为以前没参加过，所以等搞明白了这个是干吗的再和大家说。

BSP是bug squeeze party的简称，简单来说就是修错会。debian马上要发行7了，在此之前有很多的bug没有修复。其中有一种是RC bug，即运行就会出大问题的bug，或者干脆没法编译。无论哪个，都会导致这个包不能进入最新的发布。有些bug很麻烦，需要maintainer和author沟通，这个没有办法。但是有些问题解决起来很简单，只是因为后果很严重，作者又暂时没空处理，导致包无法进入stable，实在很无谓。BSP的目的，主要是以非维护者上传(non-maintainer upload)的方式修复这类bug。因为包不是自己的，所以礼貌上，只修复半个月以上的rc级别bug，其他的留给maintainer来处理。

BSP的主要目的，就是这么一个苦力会。没有挂名，最多只有一条changelog记录，还要大量寻找和修复bug。不过BSP相当重要，因为很多maintainer往往有一段一段的不活跃时间。这时候即使再简单的问题也不会处理。按照debian的规则，别人也不会帮他处理。除了BSP，很少有一批人会专门找这种简单的Bug来修正。如果没有BSP，debian stable发布的时候一做RC冻结，就要少掉很多有用的包。BSP更大的目的是，交流和传授debian打包和除错的经验，唤起人们的关注。也许在会后，如果有人看到一些简单bug，会使用nmu的方法给与修正。不过BSP到确实是有一个额外加成的好处——基本变成了签名会。昨天估计是中国大陆地区首次DD数量接近其他人数量，我一下弄到了5个签名，2个DD一个Ubuntu员工。加上原来就有的zigo签名，我就有3个DD签名了。

本地BSP是在thomas的公司举行，欧特家博士匹萨厂商赞助了我们两天的午餐——微波食品匹萨。第一天来的人比较多，很多都是纯新手，大概有20多人。Zigo倒是在网络上说会帮助新手，但是纯新手看到debian打包系统根本无从下手，所谓指导什么的也无从说起。很多人一天一个bug都修不掉，甚至都看不懂，很有挫折感，估计有不少有热情的人在第二天就这么默默退散了，第二天只来了15个左右。

我主要是以修复自己的问题为主，python-snappy和python-formalchemy都升级到了最高级，并且修复了自己以前打包的一个问题。至于RC bug么，我修了一个。两个包在python中命名冲突了，所以在debian中需要声明为conflicts。另外我评审了一下，最终还是决定关闭了python-libmemcached的ITP。虽然对douban很不好意思，还让他们修了一下。但是python-libmemcached依赖于libmemcached，而后者已经逐步升级到了1.0.X版本，但是douban为了稳定使用，是sticky在0.4版上的。因此当更新的debian发行时，实际上python-libmemcached和系统中的libmemcached不是一回事。因此，我不能依赖libmemcached的维护者，而是需要自己去维护后者——没办法，我就是怂了。python-libmemcached的爱用者，还是自己打包吧。我倒是可以公开打包文档。

另外，我在想是否要集合一批python/debian的用户，来做投票。例如，python的一个容器——flup，在debian中实际上已经orphon了。如果有足够的人投票，我愿意为flup做接手维护工作。不过目前debian下问下来的结果，大家对flup没什么太大兴趣。

    随手就写害死人阿。

昨天写了一篇google drive你这是在找死，结果被人指出了错。我忘记注明了，没有文件夹上传的是android版本，linux版没有客户端，windows版可以看到客户端下载，但是我目前没有确认下来有人能用。

即使如此，我还是觉得google drive不好用。

# 基于文件的数据管理 #

基于文件的数据管理很简单，一个文件系统有很多目录，每个目录可以放文件或者其他目录，文件里面就是各个程序的数据。基本上每个用电脑的人都知道基于文件的数据管理是怎么回事。

问题是基于文件的数据管理很不好用。

文件就有文件名，我需要找一个文档，里面是上个月的财务数据，但是我不知道叫什么文件名，这种需求并不少见。然而，要在文件系统上干这个事情，你只有搜索所有doc/xls文件，然后一个个看。

蛋疼不蛋疼阿。

基于文件的数据管理的理由，多半因为多文件组合。例如，我有一个html，里面引用了两张图片，一段音乐。在html里面，我只要写明其他文件的文件名，就自然可以指定对其他文件的引用。这省去了“复合数据存储”的烦恼。但是，大部分情况下，我们用不到这个。

因此，目前逐步在向另一个方向过渡，基于数据集合的数据存储。

# 基于数据集合的数据管理 #

数据集合，听起来和文件没什么区别，但是本质上并不是一回事。大家都用过flickr吧，也用过google doc吧。他们基本上就是“基于数据集合的数据管理”。和文件的区别在于，数据集合是有“元数据”的。照片会有拍照时间，说明。如果运气好，还有地点和评论。文档是有作者，简述等等。你可以基于数据类型和元数据进行过滤，排序等动作。而基于文件的基本没有办法这么玩。微软winXP以上版本的资源管理器可以看到，如果文件夹里面多半是图片，就会变成图片专用视图，而显示出图片的内置元数据。然而，这个是逐个扫描的，速度慢。而且万一一个文件夹里面又是图片又是音乐，至少有一个得虾米。

google drive基本是google doc的升级替代品，可以打开多种格式的文件。然而，当上传一个文件时，必须显示的“转换”为google doc文档，才可以介入管理。而且，每个类型的google文档，都有限额。以文本文件为例，大小限制在2M以内。我上传了一个5M的小说，直接报错，要求原样上传。上传后不能直接打开，必须下载打开。

# 整合和过渡 #

两者如何整合？

在文件系统的管理上，同步，而非上传，是一个非常重要的功能。我不可能每时每刻都联网，即使联网，也不能每个文件修改好了就上传一次。我需要对传统的文件系统做持续的修改，然后通过手工的，或者自动的同步，将差异转移到云端上去。而不是我手工的对比每个文件差异，然后一个一个的上传更新和删除。

没有同步工具的云端存储是个垃圾，除非你共享的目标是少数几个超大的文件，例如电影，或者资源合集之类的东西。这是以共享为目的的云，说的更直白点，就是免费的下载空间，而不是个人云存储。

在个人文件被同步到了云端后，应当能够让云端的程序直接打开和修改某个文件，而不是强迫转换。

# google drive是什么 #

从表现上看，还是基于文件的管理。我不能通过元数据直接查看我拥有多少张相片，也没办法找所有邓丽君的歌。

然而，他们又没有同步，至少linux不行。而且android手机上连文件夹上传都没有。也许有人说了，找个数据线和电脑连起来不就得了？要是我喜欢用数据线连，我到哪连一次电脑，玩个同步就完了，还要云干吗？

所以，结论还是不变。