Shell's Home

Jan 31, 2008 - 2 minute read - Comments

Process Explorer的潜在内存泄漏

贝壳最近碰到一个郁闷到死的问题。机器经常出现硬盘狂转,系统响应延迟。系统弹出一个错误,然后死机。贝壳开始猜测是硬盘驱动问题,升级驱动N次,无效。然后再猜测是ext2fs的问题(贝壳用这个驱动挂载linux下面的盘的),看来看去,不是。最后,贝壳确定了,这是内存泄漏了~~~ 问题是,这时候可没人跳出来推荐喝什么口服液的。贝壳系统中永远挂着一个procexp,看内存状态的。这东西是sysinternals的产品,后来被微软收购了。功能强大,很多系统调试,杀马都需要用到。于是贝壳就用这个工具看哪个程序的内存泄漏,可是看来看去看不到。准确说,是没等贝壳看到,系统就先死透了。最后贝壳多次尝试,发现了一个死机的规律。当mysql开启的时候,procexp就会随时发生异常死机。这是一个重要的提示,要么mysql内存泄漏了,要么procexp内存泄漏了。究竟是哪个呢?贝壳用了同属于sysinternals开发的pstools系列工具,仔细检查了异常发生时候的内存状态,确定,Process Explorer存在内存泄漏的风险! 看来sysinternals被微软收购后,旗下的工具也出现了微软的一贯特色。以下是一次内存泄漏后,终止mysql服务后抓下来的内存状态输出。如果不终止mysql,不等我抓系统就挂了。 Process memory detail for HOME-B2326348D0: Name Pid VM WS Priv Priv Pk Faults NonP Page Idle 0 0 28 0 0 0 0 0 System 4 800 52 0 0 10120 0 0 smss 772 3748 48 172 1648 223 0 5 csrss 828 68132 1464 2304 3768 13748 6 144 winlogon 856 61528 580 8536 8684 5143 39 96 services 900 37724 804 2256 2404 2740 7 65

Jan 26, 2008 - 1 minute read - Comments

弄死MSN的共享文件夹

MSN8的共享文件夹功能根本就是一个废物功能,速度慢,不习惯,而且用处不大。最恶心的是,没有卸载选项不说,手工卸载后一开MSN一重起还会回来。NND,看我怎么弄死他。MSN虽然是微软自己的产品,但是也需要遵守微软的API行为。改变资源管理器的行为是用COM组件注入到exlporer中实现的,没有使用驱动层的东西。那么我们就设法阻断DLL文件的注入加载。 首先,regsvr32 /u是不行的。因为MSN一启动又会注册上,除非你不用MSN。删除文件也不行,因为会再生成一个。那么,我放着文件不动,把内容清空,然后再删除NTFS权限怎么样呢?即使是微软的产品,也不会强制说我的更改无效,然后自己胡来一套吧。 首先,关闭所有MSN有关软件,在运行中输入cmd开一个命令行窗口。然后,用process explorer(现在这东西也是微软的产品)终止explorer进程(系统自带那个应该也行,不过我没有测试过)。这步顺序非常重要,因为我们要先阻断COM组件的加载,否则无法对文件实行更改。所以我们要先打开一个CMD,然后再关闭explorer。否则一旦关闭explorer,开CMD就难了。而没有CMD,要去删除文件就要多费一些手续了。 我们现在在CMD中切换到MSN所在目录,删除fsshext.8.1.0178.00.dll啥的文件。这个文件名会根据你安装的版本而变化。而后启动explorer(在CMD里面敲explorer就好),这个时候COM组件已经没有加载了。于是我们建立一个文本文件,改名叫fsshext.8.1.0178.00.dll,放到MSN的目录里面,再删除所有人的访问权限。删除的方法是文件上右击,点属性,安全,高级,取消”从父目录继承权限”的勾选,然后点删除。如果看不到安全选项卡,检查以下项目。工具,文件夹选项,察看,使用简单文件共享(推荐),取消他的勾选。微软的东西,最好表随便勾。 根据我的测试,这时候你随便重起电脑,MSN的组件说加载不上就加载不上。同理也可以应用到3721之类的流氓组件上,只要抢先建立了同名的文件,并且阻断了权限,这些组件就会无法使用。如果你进一步做了分离权限(日常不使用管理员账户),即使安装程序作者知道这种方法都无法应对。如果可以的话,就说明微软存在漏洞了。

Jan 25, 2008 - 4 minute read - Comments

财务数据库

贝壳最近工作繁忙,一般都是晚上十一点到家睡觉,第二天早上继续上班的那种,所以blog基本没怎么动。现在放篇财务数据库的原型,大家参考一下吧。当然,是对程序员而言。像六牙四皂小姐这种下面估计是压根看不懂的,而且也不会有那种变态的资金准度要求。 首先建立一个账户表。 DROP TABLE IF EXISTS `accont_info`; CREATE TABLE `accont_info` ( `id` int(11) NOT NULL auto_increment, `username` varchar(40) NOT NULL, `accont` varchar(40) NOT NULL, `accont_type` int(11) NOT NULL default '0', PRIMARY KEY (`id`), UNIQUE KEY `username` (`username`,`accont`) ) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=gbk; 输入用户名,账户名和账户类型,例如”许智翔”,“招行账户”,2。账户类型中规定1是现金,2是存款,3是信用卡,4以上不计算。这样可以使用多个现金账户,存款账户和信用卡账户。然后利用子查询把所有类型间的相互行为统计出来。 然后是类型表。 DROP TABLE IF EXISTS `type_info`; CREATE TABLE `type_info` ( `id` int(11) NOT NULL auto_increment, `type` varchar(40) NOT NULL, `subtype` varchar(40) default NULL, PRIMARY KEY (`id`), UNIQUE KEY `type` (`type`,`subtype`) ) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=gbk; 最后是资金流动数据表,accont_id中填写出户账户名,to_accont中填写入户账户名。如果是外部(例如从别人那里拿钱或者给别人钱),则写0。happen_time上填写发生时间,money上写金额,message上写备忘。

Dec 27, 2007 - 1 minute read - Comments

libxml使用中的编码问题

libxml是gnome的XML解析库,具有强大的解析能力,支持DOM和SAX解析模型,属于验证型解析器。其内部是使用utf-8编码工作的,因此gbk之类编码的XML无法解析。为了解决这个问题,我们可以使用一个很简单的小窍门。 libxml是要和iconv一并使用的,头文件引用一般类似以下形式。 #include <iconv.h> #pragma comment(lib, "iconv") #include <libxml/tree.h> #include <libxml/parser.h> #pragma comment(lib, "libxml2") 这样的话,我们向libxml注册一个处理句柄,对其他编码的xml先执行一次转换,再进行解析。 iconv_t iconv_utf8_gbk = NULL; iconv_t iconv_gbk_utf8 = NULL; int gbk_input (unsigned char *out, int *outlen, const unsigned char *in, int *inlen) { char *outbuf = (char *) out; char *inbuf = (char *) in; size_t rslt; rslt = iconv (iconv_utf8_gbk, (const char **) &inbuf, (size_t *) inlen, &outbuf, (size_t *) outlen); if (rslt < 0) return rslt; *outlen = ((unsigned char *) outbuf - out); *inlen = ((unsigned char *) inbuf - in); return *outlen; } int gbk_output (unsigned char *out, int *outlen, const unsigned char *in, int *inlen) { char *outbuf = (char *) out; char *inbuf = (char *) in; size_t rslt; rslt = iconv (iconv_gbk_utf8, (const char **) &inbuf, (size_t *) inlen, &outbuf, (size_t *) outlen); if (rslt < 0) return rslt; *outlen = ((unsigned char *) outbuf - out); *inlen = ((unsigned char *) inbuf - in); return *outlen; } 初始化的时候运行以下代码进行句柄注册。

Dec 25, 2007 - 1 minute read - Comments

继承函数的拷贝构造

从基类继承一个子类,基类有一个拷贝构造函数,子类重载了一个。那么在子类拷贝构造的时候会自动调用基类的拷贝构造函数吗? 答案是不会,自动调用的是基类的构造函数。 子类中如果需要调用基类的拷贝构造函数,需要这样用。 D (const D & o): B (o){...}

Dec 4, 2007 - 1 minute read - Comments

wc、sort介绍

首先声明一点,我介绍的小软件系列都是Linux下的,在Windows下可以找Gnuwin32里面提供的移植包。因此多数人都是可以使用的,只是高兴不高兴用的问题而已。 其次我得道歉。本来说好了每周介绍一些小软件的,结果MSN空间不稳定,加上贝壳又忙。所以现在才介绍第二个,大家理解理解吧。 这次介绍的对象是wc,不是厕所,也不是世界杯,而是一个字符统计软件。这个软件的目的是统计出一个文件内的行数,单词数,字符数。行数是按照硬回车来统计的,单词是按照分割符号来统计的,字符么就不说了。这个和Word的字符统计很像,不过用起来并不那么方便。也许有人奇怪,这种软件有什么用呢?主要是在脚本程序内使用来统计一些数据,也有用来统计程序的代码行数的。平时大家一般都是分开统计行数,这次可以wc -l *.cpp *.h。就可以得到所有文件的行数和总行数。 而后我补充介绍一个东西,sort。这东西也很简单,就是把输入的内容按照一定的法则排序输出。一般来说,排序法则是alpha法则,当然也有数字法则等等。这个软件主要是从输出中排除一些重复数据,或者把输出过滤。例如我们可以和上面的联合使用,wc -l *.c *.h | sort。就可以得到当前所有的文件的行数,并且排序。

Dec 2, 2007 - 1 minute read - Comments

IM之争

我不记得这个Title是否已经写过了,不过无所谓,因为国际形势发生了变化。 以前是ICQ和QQ争霸中国市场。后来MSN加进来一脚,ICQ淡出了。现在Fetion跑进来了。那么未来呢? 我们先看看IM软件的发展方向吧。IM最早的远亲应当是IRC和电子邮件。不过电子邮件对于服务器需求太强大,用于实时对聊做不到。IRC虽然需求小了点,但也在不可承受的范围内。随着网络的发展,大家挂网时间越来越多。所以大家要求一种廉价有效的即时通讯手段。可以和某个人对话,而不用耗费太多的服务器成本。于是,ICQ应运而生了。ICQ可以说是最初的P2P体系者,两个人聊天的时候数据都是互相发送的,只有登录的时候才和服务器通讯。这样的好处是避免了大量的服务器开销,坏处是无法穿透防火墙。 从协议上说,IM的协议互动机制和电子邮件基本是一致的。如果不介意服务器开销的话,我们可以把IM协议构架在POP3和SMTP上。对于这种倾向,有人应该感觉熟悉。那不是MSN的离线消息么?差不多。我们定义发送逻辑为,如果可以找到对方IP就找对方IP,不可以找到对方IP就给对方发送邮件。接受的时候我们就接受邮件,如果碰到特殊格式的就解析掉当做消息处理。同时如果在线则服务器会主动推送邮件消息过来(如果不这样就要非常快的定时查询新消息,非常耗费资源)。那么我们就构成了一个跨越服务商的IM方案了,并且还支持多种客户端和离线消息。例如我们通过智能手机的终端接入进来(记得么?我们的客户端其实只是个特殊点的邮件程序),那就成了无线IM。 问题是,我们动了谁的奶酪? 服务商恐怕对此会非常不高兴。大家知道,电子邮件服务商的竞争比IM残酷多了。那么多IT公司,有多少是纯粹做电子邮件做发起来的?几乎没有。为什么呢?因为电子邮件的开放性强。开放性强是历史的产物,早在主机时代邮件协议就已经固定了,而且有了大量的实现。如果哪个ISP不遵循,那么就没有用户。但是遵循标准的结果就是谁都可以被谁替代。也许某某邮箱系统的界面好看点,某某邮箱系统的容量大点,某某邮箱的速度快点,某某邮箱的垃圾少点。但是都不是不可以替代的,属于非强用户粘着性的产品。(注意我没有使用弱这个词,因为一般人习惯用一个邮箱后也就不怎么更改了)如果邮箱服务收费,ISP会发现,几乎是立刻就没有用户了—— 然而IM则是在端点时代才发展出来的,而且始作俑者不是IETF成员,IETF也没有太关注。——这捅了大篓子。现在的IM产品,几乎一个产品和另外一个无法连接。一旦你大部分的朋友使用了某种IM,你也必须被迫使用某种IM。好比贝壳虽然不喜欢QQ(这厮没Linux版本还老封锁协议),但一帮朋友都是QQ的,难道不用?这是意味着IM是扩散用户粘着的产品! 这意味着什么呢?ISP们不用推销,只要他们拥有一定的用户了,用户就会自动扩展用户群。而且你的用户不会轻易离开你,即使你收费,也有相当的用户。如果改成开放的形式,很多大型的IM商就等着客户流失吧。因为他们有相当的客户群,因此往往会收取一定的费用或者产生较多的广告。而IETF已经开始制订IM的交互协议了,即SIMPLE协议。先不说这个协议是否先进是否安全,至少这个协议是开放的。开放的协议意味低附加值的服务,因此IM商肯定会抵制协议的推行。一般的逻辑是。如果SIMPLE协议的总客户集群无法和自己的客户群比较,则不和SIMPLE互通。这样有利于维持自己的IM群,进而取得收益。如果SIMPLE协议的总客户集群已经大大超过了自身的客户群,则和SIMPLE互通。因为可以扩大自己的群,进而扩大用户。所以SIMPLE协议应该是从新兴公司开始推广的。 因此,作为一个用户来说,我更希望大家现在开始使用带有SIMPLE特征的服务。这样更有利于促使更多IM商互通服务,而且还会减少服务的费用。 从历史上说,当今的各大IM厂商自有其来。QQ是特殊历史时期的特殊软件。开始的时候其实就是简化的ICQ中文版,除了中国制造外没有什么特长。后来中国的互联网娱乐潮起,QQ向娱乐转型,主攻大众市场,结果红的发紫。MSN则是更晚时期的产物,是MS攻占全球IM市场的拳头产品,主攻的是商务市场。Fetion是中移动今年新推出的IM产品,特点是和手机互通。 就发展趋势来预期,IM主要呈现两个特点,一个是全分布化,一个是嵌入化。 虽然IM软件的工作原理对于服务器要求不高,然而很多后续服务对于服务器却有强烈需求。我们先仅仅计算基础通讯消费吧。一个人登录的时候先认证,后回传所有好友的名单,套接字。一般登录一次开销最小也要在3K上下。一般成熟的IM软件总用户量至少是1000W以上(国内市场),峰值冗余计算为五倍。计算结果就是一天的通信最少300G,最低带宽需求是20M。这还仅仅是登录造成的通讯成本。我们再考虑持续心跳激活某个特定客户端的重复时间——那这个开销就不是某个服务器所能支持的了。现在的IM服务器端,一般都是服务器组来完成这系列的需求。当然——未来的IM软件,我们的期许绝对不是仅仅1000W用户这个级别了,至少要包含国内的上亿人,加上国际的上亿人。每个IM的有效注册用户规模可能达到数亿这种恐怖规模。加上嵌入化的发展,在线时间也会越来越长。因此服务器的规模也会随之上升,进而造成IM收费时代的到来。 如果要IM持续免费,则我们就必定要发展分布式IM。简单来说,用户登录,持续心跳等等都不以服务器为中心,而以分布网络为中心。服务器只辅之以用户入口和统一的模糊查询的功能。这样会大大减轻服务器的负担,但是也会带来几个问题。 首先是用户的注册,没有用户数据库了。不过不难解决,可以让用户不需要注册。因为没有一个统一的服务器,因此用户注册只需要生成一个UUID,生成一对公私密钥,就算完成了。登录的时候即是告知别人自己的UUID,公钥和套接字即可。需要寻找一个好友的时候,可以使用UUID查询此人的套接字,具体方法请看DHT,Kademila,我上面有写的。 其次是大规模块内容的传输,简单来说其实就是传文件。这些数据如果可以直接传输则没有问题,但是在无根分布系统中,间接数据传输是要过中间机的。这样会造成中间机的网络开销。这个还要看人家乐意不乐意呢。这个没有什么好的解决方法。 最后则是安全问题。这倒不难解决,发送内容用私钥和对方公钥各加密一遍,接受用对方公钥和私钥解密就好了。第一次发送一个统一加密块,后面就用这个块加密,定时更换。兼顾了安全和效率。 IM的另外一个特点就是嵌入化,简单来说就是移植向手机上。中国的移动运营是特殊状态,不过世界的发展大致都是一样的。就是将手机发展为网络终端,然后尽量用软件解决问题。那么中国移动现在的短信优势还能持续多久就是一个非常大的问题了。当然不排除短信优势消灭前飞信拥有了新的特性的可能。

Nov 28, 2007 - 1 minute read - Comments

网络银行安全性的理论分析

最近好像用网银的人比较多阿,贝壳就做件好事,简单介绍下密码学体系。让大家了解下网银安全性的方方面面。 我们说,银行系统的安全性和易用性往往是一个磁石的南北极,不大可能出现在一个地方的。从易用性角度来说,输入用户名和取款密码直接操作的网银是最方便的。可惜,你的钱被偷的概率也是最高的。因为你和银行间的通讯过程需要流经无数节点,任何一个地方都可以轻易拿到你的登录密码。那么重复这个过程就可以登录并且操作你的钱。所以,任何一家银行都不会提供直接的登录手段。 一般来说,银行在设计网银的时候,往往会提防以下的攻击手段。社会工程学,嗅探,重复发送,钓鱼,中间人钓鱼,猜解,内部盗窃。我们先来大致了解下这些攻击手段的方法和实施条件,然后再说银行的对应手段。 社会工程学攻击是成功率最高的,技术要求最低的攻击。其要决就是一个字,“骗”!社会工程学攻击主体上就是各种骗术,例如把机器塞上,旁边写一个处理电话。等你打电话的时候,就过来一个“工作人员”。然后弄出你的卡来,说要验明你是否是卡主,问你密码。等确认好了身份,你拿到的就不是自己的卡了,那个工作人员也就拿了钱跑了。诸如此类的攻击核心要点就是骗取客户信任。所以社会工程学的对应手段只有让客户提高警惕,其他没别的好办法。 嗅探指的是从登录的机器上或者附近符合一定条件的机器上(具体是哪些需要一定的专业知识),窃取登录过程数据,并且从中还原出用户密码的手段。这种攻击往往和重复发送一起使用。无法还原密码的情况下,将原先登录的包重新发送一次。对应嗅探攻击的方法很简单,就是挑战-回应方法(Challenge-Responses)。现代加密算法有专门对应已知明文攻击的,用于对抗已经知道明文和密文情况下反解密码。服务器发送一个随机数过来,客户端加密后发送回去。服务器端核验客户端的加密结果和服务器端的加密结果,就知道客户端是否通过认证了。而嗅探者需要相当数目的明密文对才能知道密码。所以相对安全程度更高。 钓鱼是一种社会工程攻击。一般是通过邮件或者其他手段引导你到某个网站上,看上去和网银很像。等你登录想用的时候,会发现上面说网银现在正在调整。如果当时没有在意,等下次登录的时候帐户里面的钱就没了。由于窃取的是密码本身,所以挑战-回应方法无法解决这个问题。这种情况下就必须使用挑战-回应方法的变形,例如零知识验证。大致上看起来就是这样的,银行给你本很长的书,里面写什么你也不知道。然后银行问你,第512页三行15个字是啥?钓鱼收集到这个知识就没用了。但是中间人攻击还是有效的。中间人和钓鱼看起来很像,只是中间人不是窃取密码,而是窃取会话。当你以为登录到银行的时候,其实是登录到了一个中间服务器。一切你的操作其实是通过中间服务器代理上去的。当你退出的时候,中间服务器就会替换你的操作,实施一次转帐和退出。要屏蔽中间人攻击,就必须使用签名证书系统来认证服务器地址。 猜解和内部盗窃是通过对主人情况的了解来猜测或者偷窃密码/密码设备的攻击。目前没有啥好办法,只有想点自己都想不到的东西作为密码才行。生日,电话,车牌,名字,都不可以直接作为密码。当然,做一些基础变形后作为弱密码还是可以的。例如将生日倒过来作为查询密码。 目前网银的认证系统有以下几种,密码直接验证,文件证书验证,密码卡认证,手机动态认证,硬件设备认证。 密码直接认证一般使用了SSL技术来防止嗅探,但是对于钓鱼,中间人,猜解,内部盗窃都没有防护能力。一般都是各个网银的最差防护状态,为某些对安全不在意的人设计的。只是使用方便而已。 文件证书验证是利用密码和文件数字证书来验证身份的方法,对于钓鱼,中间人有比较好的防护手段。可以防止猜解,但是无法防止内部盗窃。因为文件证书为了方便起见都是存放在电脑内部的,所以文件证书的安全就又成了问题。即使是存放在U盘上,也会在使用的瞬间被复制。电脑中木马,文件或者U盘被盗拷,都是产生不安全的原因。 密码卡是某种零知识验证的变形。差不多就是给你张密码卡,刮一次能上一次。对于钓鱼有一定防护能力,但是对于中间人攻击无能为力。可以防止猜解,但是无法防止内部盗窃。 手机动态认证是通过手机收取临时动态验证码来确认客户的身份。如果要窃取客户的身份,就必须同时得到用户手机卡和用户密码。所以,也是防嗅探,钓鱼,猜解,但是不防中间人和内部盗窃。注意这里有种特殊形式,大家也许不知道,手机发送的短信是可以被特殊设备截获破解的—— 硬件设备认证则是将密钥和计算放入了特殊硬件内。银行发送挑战数到硬件上,硬件设备返回数据到银行。如果要窃取身份,就必须获得设备和密码。因此,也是防嗅探,钓鱼,猜解,但是不防中间人和内部盗窃。一般就是指银行的U盾设备,但是要注意区分U盾究竟是用来计算呢,还是用来存放密钥。后者的安全级别和文件证书一致。 我们对比各种攻击之前,先去掉两个特殊选项,社会工程和中间人攻击。社会工程某种意义上是无法防御的,你说你要把东西交给别人,银行怎么防范?拿你的生物特征?那就太麻烦了。中间人则是因为可以用CA证书验证地址有效性,因此现在很少成功。当然,也有先欺骗DNS服务器的。碰上这种蓄意的中间人攻击,差不多就和碰上人强奸一样——反抗是没意义的。这两种方法,只要是有心算无心,基本都可以成功。因此我们先去掉这两个成功么未必成功,防范么没法防范的选项。 SSL技术是网银登录的基础技术,没有的话请记得早日离开这家银行。文件证书使用方便,但是电脑一旦中木马就立刻危险。密码卡看似安全,其实对于精心设计的钓鱼还是没用的。而且使用麻烦,不如趁早不用。手机动态验证的安全性是非常高啦,可是要记得手机的安全就是帐户的安全。所以手机卡千万看住,别被人复制了。(手机卡是可以复制的,然后就可以用这个号码打电话了。当然这种事情发生概率很小,一般倒是用在一卡多号上比较多)还有手机信号问题,找个深山老林上网吧。 硬件设备认证是比较硬的方法,一般是比较完美的。可惜价格太贵。 综合下来,偷懒的可以用手机。怕事的还是用硬件。

Nov 26, 2007 - 1 minute read - Comments

Google Calender

Google有很多产品,Google Calender就是其中之一,这个东西主要的目的就是管理日历。 其实从常规角度考虑,这是最不适合bs的产品。日历的要点就是随身,谁会高兴为了看个日历找宽带上网阿。可不能不感慨Google的水平,凭着各种技术的支持,这么一个产品居然还真让我觉得好用。 Google Calender的两个核心思想就是同步和共享,同步用的是iCalender标准,共享也很类似。Google Calender的管理中,允许在多种客户端内同步Google Calender的日程。这样Google Calender就从一个不适合的产品一下变成了多个日程工具的平台标准。贝壳现在是利用他同步多个机器上的多个软件,主要的产品包括Sunbird/Lighting,raincalender,部分的手机日历,相信很多人也会做这个应用。贝壳用的就是其中的Sunbird,这个软件是Mozilla的产品之一。(贝壳现在是Mozilla的忠实用户,FireFox,Thunderbird,Sunbird三件套常备,都做了跨系统共享)不加载Provider for Google Calendar的情况下,可以读取iCalender格式的远程日历。加载插件后会多出一个Google日历的选项,用Google中的个人xml链接,保存入个人的用户名和密码(个人的gmail,带域名),然后就可以双向同步gcal了。 至于共享,在管理的时候应该可以看到和谁共享。做项目的时候,拉组员进来共享。或者没有gmail的可以用全可见加给html链接的方式。这样就可以给组员看他们的工作状态,别人的工作状态,将来的项目安排。如果组员可信任,可以给予写权限。这样他们会自动更新进度,可谓超级省事。 最后,Google Calender可以被结合入iGoogle里面,成为标准平台的一部分。

Nov 26, 2007 - 1 minute read - Comments

开blog宣言

blog供应商更改,发个新的纪念下。 msn的blog已经用了好几年了,期间也没有出过什么大问题。只是最近在Linux下面写的东西无法提交,windows下也没有格式。问了几个朋友都正常,莫非是贝壳人品问题?算了,不搞这么复杂了,听说google的产品也不错,换了算了。 就这样。