15年是个什么概念？6年又是个什么概念？如果我能活到80岁，大概能有5个15年，13个6年。从现在算起，大概还有3个15年，9个6年。有两个人，15年前在一起，最近的一次见面是6年前，其中一个，以后再也见不到了。

15年前，我们算是互相了解，而现在，虽然可以通过电话联系，声音也没有改变，但一种陌生和恐惧却油然而生。陌生是因为不知道他现在是什么状态？什么性格？作什么？想什么？喜欢什么？别人怎么看待他？由这种陌生产生的恐惧，在电话中提现不出来，可真有一天面对面坐下喝酒的时候，会在沉默中冲击心灵。

真是有些"物是人非"，虽然树都砍光了，可路还在；以前的教室虽然从3层扩建成了4层，可样子没变；以前的平房都变成了楼房，可地名没变；以前的人还是那个人，可却已不再熟悉。

人能作的无非就是改变世界和改变自我，在良性循环体系中，天平平衡的两边，一旦天平倾斜，就像水车一样，把水倒了出来，稀里哗啦，天平的指针没有倾斜的概念，一下就到底了，从楼顶到地面。

我们很熟么？未必吧？但15-6=9年的时间并没有改变什么，再次聚会反而觉得更亲近了，大概是上学和工作之后的自由导致的后遗症，毕竟在老家憋的时间太长了，尤其是初中，回头看看和封建社会差不多。那个时代留到现在的，除了成为档案中的几页纸，学习工作的垫脚石之外，就是对朋友的感觉了。

感觉这东西很奇妙，有点像白酒或者普洱茶，怎么放也不变味，反而更纯了，就像一幅画，当你离的很近的时候，一切都能看仔细，会发现很多毛刺、花边和瑕疵，而当距离稍微远一些，这些不好的东西都看不到了，转而欣赏画的整体美，从而赞不绝口。人会很主动的"忘记"不好的记忆，残留的对很久以前的感觉自然是越发的美好。

提问，是要这种模糊的美好，还是要清晰的缺陷？

七百多公里不算远，开车一天，坐火车也是一天，坐飞机估计2小时就到了，可惜家里没飞机场，以前的所谓"飞机场"（记忆中只停过直升飞机，还是极其破旧，不知道是开走还是被汽车拖走的那种，放风筝的好地方）现在早就变小区了，我姐姐就在那里住，另外一个人在地势最低的地方，哦，那地方太黑了，以至于第二天我就忘记具体在哪个胡同里了，也许是酒和太多了的缘故，好在没说错话，也后悔没多说几句，其实也不敢，也不是不敢，是怕说了没用。

就这么点距离，就能让人生产生巨大的变异，时间是散射的催化剂，分道扬镳用在这里再合适也不过了，不过这条条道路并不都是通向罗马的。

如果真的有时间旅行，那么我想逆向运动，生命在于运动，岁数大点无所谓，能回到那个年代就好，比现在的环境好多了。现在的烦你比楼还多，以前的房子稀稀拉拉，烦恼也是稀稀拉拉。

宁愿相信宇宙中存在平行时空，更希望家里有一只机器猫，逼它拿一只望远镜出来，看看另外一个时空的人都在作什么。呃，如果是现在，应该是睡觉呢，不知道会作什么梦。再让机器猫拿个装备出来，到梦里去搅和搅和。除此之外，还能作什么呢。呆头鹅，痴人说梦，不知道眼不见心不烦么。

想什么就写什么，写什么就想什么，这种感觉真不错，只是难为看官了，如果你能逐字看到这里，还真是强人。

清楚的记得一些事，我给你看的东西，现在已经成为现实，我给你说的话，可能当时被你当作笑话，也没有达成传声筒的作用，不过都无所谓了，这些所谓秘密，现在一半在我这里，一半已在地下，永远的绝版了。关于传声筒，还是那句话，物是人非。有一点我望了，是你猜中的，还是我自己说的？实在记不清了。

那个谁，发什么呆呢，说的就是你，就是你，知道不？呆头鹅，不过鹅现在正痛苦并快乐着，岁月的枷锁已经深入骨髓了，可怜啊，谁又不可怜了啊，想起来有些事确实挺郁闷的，郁闷这个词用再这里太合适了，发明这个词的人我很崇拜。

世界上最远的距离大概就是电信和网通吧，不过这是在第一宇宙，在第二宇宙，是两个猪头之间的距离，因为一头并不知道另外一头是怎么想的，唉，希望在第三宇宙能有所改观。相信我，人是一个思维体，其它的都是在matrix中的虚无，都素浮云。思维体之间的沟通就像磁铁，对味儿了就相吸，不对口味就排斥，最痛苦的就是中间路线，上不去下不来，还吃不到茴香豆，百年孤独。

铁路还有换轨、错轨的时候，岁月却是单行道，即使兜个大圈子能回到原地了，却发现其实不在一个时空，不兼容。

突然又有一种更不好的感觉，觉得死去的人还活着，而活着的人已死亡。死亡，是美好事务永保青春的最好方式，so，本文就在这里太监了吧，8月16的月亮值班，我去睡觉了。

Source: http://www.fwolf.com/blog/post/356

一个表，里面的三个字段A B C均为字符串类型（varchar或者char），其中C的实际数据为c1, c2, c3等有限的几种。表的主键和索引都不是ABC三个字段。下面的sql语句：

SELECT * FROM tbl_name WHERE A='a' AND (C='c1' OR (C='c2' AND B='b'))

是能够正常执行，得到数据的。但是当在字段C是创建索引：

CREATE INDEX idx_name ON tbl_name(C)

之后，上面的SELECT sql语句也能正常执行，但却无法得到数据了。而在创建索引前后，符合WHERE条件的数据是肯定存在的，所以可以理解为这个索引导致了sql的执行结果无数据；在删除索引之后，马上就又能取到数据了。

这是索引有问题？还是索引损坏？还是其它的什么问题？

Source: http://www.fwolf.com/blog/post/355

我的数据库是sybase 11.9.2，这个版本不支持ALTER TABLE tbl_name MODIFY col_name datatype语法，所以只能采取变通的方式，比如要把col从decimal(8,2)更改为decimal(14,2)类型：

1. 新建colA，类型为decimal(14,2)
2. UPDATE table SET colA=col
3. ALTER table DROP col
4. sp_rename "table.colA", col

但过程中，接二连三的遇到问题，首先进行SET colA=col的时候，由于表含有一个非主键索引，所以很慢，这个只能忍，下次记得先删除索引，好在数据不多。

然后是锁类型，为了提高并发性我更改成了DATAROWS，而这种锁类型下是不允许DROP column的，所以要变更回ALLPAGES，DROP列之后再变回来。

然后是sp_rename存储过程出了莫名其妙的错误（忘记具体内容了，反正不能用），所以上面的第4步变成了再新建列col，然后SET col=colA把值再写回来，然后再删除colA。

最后，也是最致命的问题，就是这个表上还有update和delete的触发器，我太大意了，以至于在第二次UPDATE的时候才发现，但这时已经晚了，整表的UPDATE，还有其它的一些实时处理，让整个数据库系统几乎瘫痪，虽然进程不多，但由于表之间的关联和sybase的加锁机制，很多进程都成了send sleep或者sleeping状态，再过一会儿，日志满了，又多了一些等待日志空间释放的sleep进程。这个时候， drop trigger操作已经无法执行了，一方面是drop trigger和这个表的其它进程锁冲突，另一方面是当事务正在进行的过程中无法truncate日志。最后，只能中止客户端操作，并重启数据库服务。

真正的噩梦才刚刚开始，drop trigger之后，所有update操作都完成了，col类型更改的任务完成了，再重新把trigger建上，但很快发现，只要有针对这个表的update操作，即使操作的对象集为空，数据库服务器也立刻陷入一种死循环状态，update操作永远执行不完，并且进程无法kill，用户越连越多，最后不仅日志很快又满了，而且用户连接数也用完了。找了一下午原因，发现还是drop掉这个update的trigger之后就没问题了，猜测可能是由于某种客户端操作的中止，使这个表的为触发器预留的inserted和deleted数据缓存滞留在系统中，并随着trigger的触发再次被处理，进入死循环，重启服务之后，依然存在，然后再被触发，再造成死循环。

最终，新建了一个同结构的表，把数据全部导过去，然后重建索引、触发器，最后再删除旧表，把新表的名称改成现在用的这个，问题终于解决了。同时也从侧面证实了我的猜想，问题就出在这个表上。按说sybase应该不会出现这样的问题的。

总结一下，再更改字段类型的时候，应该按照这样的顺序操作：

1. 删除触发器和索引
2. 添加新字段colA
3. col的值赋给colA
4. 更改锁类型为ALLPAGES
5. 删除字段col
6. 更改锁类型为DATAROWS
7. 添加新字段col
8. colA的值再赋给col
9. 更改锁类型为ALLPAGES
10. 删除字段colA
11. 更改锁类型为DATAROWS
12. 重建索引和触发器

重复更改锁类型的原因是在ALLPAGES锁类型的情况下，进行update的操作比较慢，影响其它同时进行着的操作。并且在高版本的sybase，比如ASE 15下，就不用这么麻烦了，可以使用"ALTER TABLE tbl_name MODIFY col_name datatype"这样的SQL来直接实现。

Source: http://www.fwolf.com/blog/post/354

Yahoo!虽然现在已经不比当年风光了，可依然还是大哥级别的，在中国的分铺也算是国内的一大门户，但就我个人直接或间接使用Yahoo!服务的体会来说，Yahoo!的用户id是越来越乱了。

1. 挑个好名字暴难

   从我开始上网那时（1999年吧）算起，yahoo id就已经很难注册了，稍微顺口一点的不带上数字根本申请不到，经过近几年的发展，估计中文拼音的组合也用得差不多了，很多朋友都在用拼音+数字的id，可怜，更不幸者，会在id中带上一个经常被小白们输成中文符号的-或者_。

2. 你的邮箱后面到底有没有".cn"？

   goodboy@yahoo.com邮箱和goodboy@yahoo.com.cn邮箱是一个么？打电话询问别人邮箱地址时，一定要问清楚，不然你的信不定会到谁手里呢。

3. @yahoo.cn邮箱搅局

   嗯，这个新邮箱我照例"抢注"了个id，不是真的想去用它，而是怕被别人注了冒我的名来作坏事，不好的一面是，下次打电话问别人邮箱地址的时候，不仅要确认后面有没有".cn"，还要问问带不带".com"才行。

4. @yahoo.cn邮箱居然整体就是一个雅虎id

   雅虎的@yahoo.cn邮箱上线之后，邮箱登录界面就不再是只输入id就行了，要输入整个邮箱地址（比如goodboy@yahoo.cn）才行，这说明邮箱地址成为了雅虎的用户名，虽然现在用邮箱作为id的网站不少，可是，你知道你注册的@ yahoo.cn邮箱同名的@yahoo.com.cn邮箱是谁的么？

所以，@yahoo.cn邮箱除了是一次炒作之外，我还真看不出有什么实际的作用，在现在邮箱普遍上G的环境下，把空间用尽的肯定不多，但常忘记注册名的人肯定不少。

还好，这些都是雅虎中国在折腾，英文Yahoo!依然是有一个id就通行了，不知道@yahoo.cn的id去英文Yahoo!登录是怎样的？我试了一下，居然还能够自动进入中文界面的邮箱（和直接在中文雅虎登录是一样的啦），不过在"我的账户"中无法更改语言，这一点和@yahoo.com.cn不同，看来是一个更本地化的阉割版本了。

Source: http://www.fwolf.com/blog/post/353

1、在/etc/rc.d/rc.local中加入：

for　t in 1 2 3 4 5 6 7 8
do
    setleds –D +num
    $t>/dev/null
done

不过setleds在我这里怎么用也不行。

2、在/etc/console-tools/config这个文件靠近最后的几行：

# Turn on numlock by default
#LEDS=+num

去掉第二行的注释就可以了，不过好像只能用于纯控制台，对图形界面无效。

3、先安装numlockx这个小工具：

sudo apt-get install numlockx

然后编辑/etc/X11/gdm/Init/Default这个文件（注意备份），在最后一行exit 0前面添加：

if [ -x /usr/bin/numlockx ]; then
    /usr/bin/numlockx on
fi

然后再重启就可以了，在我的Ubuntu 7.04，xfce桌面环境下成功。

参考：

• 如何让gnome启动后numlock键开启？
• 如何在Linux启动后打开Num Lock