2007年5月20日星期日
技术、哲学、做人
比如有空读读70年代80年代90年代的RFC,这些RFC有些已经很陈旧了,有些只是在讲一些原则性的东西,有些只是在讲一个技术历史故事甚至插曲。不一定都当技术文档来读,这样说来,有时候其实也是个从技术出发的“心灵鸡汤”。
下面是前些天我发给同事们的一个邮件。不一定大家都能认同这些,也许有人觉得这些浅显的道理没什么。但我觉得在我们现在这种浮躁的技术实现领域,特别是软件开发领域是应该有这些态度的。其实也是一种做人处世的态度吧。
-----------the email------------
在读RFC1122(Requirements for Internet Hosts)的时候,对下列部分感触很多,希望大家分享学习:
1.2 General Considerations ................................. 12
1.2.1 Continuing Internet Evolution ..................... 12
1.2.2 Robustness Principle .............................. 12
1.2.3 Error Logging ..................................... 13
1.2.4 Configuration ..................................... 14
这个RFC虽然是Internet对主机的要求,更是对主机软件的要求,特别是对我们如何设计和实现软件,在软件开发、协议开发、接口开发中很有指导意义。给出了非常明确的软件设计原则,对软件的可发展性原则,稳健性原则、错误异常统计和Log、可配置性都提出了很好的一般性原则。建议大家好好读读这部分。
1. 可发展性:软件最初设计和实现的时候可能没有那么多功能,但产品和需求是不断发展的,如果不设计好结构和可扩展性,就的不断反工或者最后乱的一团糟;
2. 稳健性原则:特别是"Be liberal in what you accept, and conservative in what you send"这句明言,其实和我们中国的一句老话“宽以待人,严以律己”非常符合,这里介绍的稳健性原则是非常经典的总结;
3. 错误异常统计和Log:任何时候发现问题或bug或和别的设备或模块对接的异常都应该能从软件中提供的统计和log中分析出来,这就需要很好设计这些统计和Log。统计Log+代码走查应该能查到所有问题,而不是靠测试和现场重现。如果在出现异常的时候必须需要模拟重现该异常才能找到原因,那么这个软件的设计和实现就不能说是成功的。
4. 可配置性:软件用到的任何配置数据和参数都应该是可以加、删、改的,而且这些可配置性应该是稳健的,可以用最方便的方法做到的,不依赖别的软件和设备的。
以下是节选的一段:
1.2 General Considerations
There are two important lessons that vendors of Internet host
software have learned and which a new vendor should consider
seriously.
1.2.1 Continuing Internet Evolution
The enormous growth of the Internet has revealed problems of
management and scaling in a large datagram-based packet
communication system. These problems are being addressed, and
as a result there will be continuing evolution of the
specifications described in this document. These changes will
be carefully planned and controlled, since there is extensive
participation in this planning by the vendors and by the
organizations responsible for operations of the networks.
Development, evolution, and revision are characteristic of
computer network protocols today, and this situation will
persist for some years. A vendor who develops computer
communication software for the Internet protocol suite (or any
other protocol suite!) and then fails to maintain and update
that software for changing specifications is going to leave a
trail of unhappy customers. The Internet is a large
communication network, and the users are in constant contact
through it. Experience has shown that knowledge of
deficiencies in vendor software propagates quickly through the
Internet technical community.
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:
"Be liberal in what you accept, and
conservative in what you send"
Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue. In general, it is best to assume that the network is
filled with malevolent entities that will send in packets
designed to have the worst possible effect. This assumption
will lead to suitable protective design, although the most
serious problems in the Internet have been caused by
unenvisaged mechanisms triggered by low-probability events;
mere human malice would never have taken so devious a course!
Adaptability to change must be designed into all levels of
Internet host software. As a simple example, consider a
protocol specification that contains an enumeration of values
for a particular header field -- e.g., a type field, a port
number, or an error code; this enumeration must be assumed to
be incomplete. Thus, if a protocol specification defines four
possible error codes, the software must not break when a fifth
code shows up. An undefined code might be logged (see below),
but it must not cause a failure.
The second part of the principle is almost as important:
software on other hosts may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is "watch out
for misbehaving hosts"; host software should be prepared, not
just to survive other misbehaving hosts, but also to cooperate
to limit the amount of disruption such hosts can cause to the
shared communication facility.
1.2.3 Error Logging
The Internet includes a great variety of host and gateway
systems, each implementing many protocols and protocol layers,
and some of these contain bugs and mis-features in their
Internet protocol software. As a result of complexity,
diversity, and distribution of function, the diagnosis of
Internet problems is often very difficult.
Problem diagnosis will be aided if host implementations include
a carefully designed facility for logging erroneous or
"strange" protocol events. It is important to include as much
diagnostic information as possible when an error is logged. In
particular, it is often useful to record the header(s) of a
packet that caused an error. However, care must be taken to
ensure that error logging does not consume prohibitive amounts
of resources or otherwise interfere with the operation of the
host.
There is a tendency for abnormal but harmless protocol events
to overflow error logging files; this can be avoided by using a
"circular" log, or by enabling logging only while diagnosing a
known failure. It may be useful to filter and count duplicate
successive messages. One strategy that seems to work well is:
(1) always count abnormalities and make such counts accessible
through the management protocol (see [INTRO:1]); and (2) allow
the logging of a great variety of events to be selectively
enabled. For example, it might useful to be able to "log
everything" or to "log everything for host X".
Note that different managements may have differing policies
about the amount of error logging that they want normally
enabled in a host. Some will say, "if it doesn't hurt me, I
don't want to know about it", while others will want to take a
more watchful and aggressive attitude about detecting and
removing protocol abnormalities.
1.2.4 Configuration
It would be ideal if a host implementation of the Internet
protocol suite could be entirely self-configuring. This would
allow the whole suite to be implemented in ROM or cast into
silicon, it would simplify diskless workstations, and it would
be an immense boon to harried LAN administrators as well as
system vendors. We have not reached this ideal; in fact, we
are not even close.
At many points in this document, you will find a requirement
that a parameter be a configurable option. There are several
different reasons behind such requirements. In a few cases,
there is current uncertainty or disagreement about the best
value, and it may be necessary to update the recommended value
in the future. In other cases, the value really depends on
external factors -- e.g., the size of the host and the
distribution of its communication load, or the speeds and
topology of nearby networks -- and self-tuning algorithms are
unavailable and may be insufficient. In some cases,
configurability is needed because of administrative
requirements.
Finally, some configuration options are required to communicate
with obsolete or incorrect implementations of the protocols,
distributed without sources, that unfortunately persist in many
parts of the Internet. To make correct systems coexist with
these faulty systems, administrators often have to "mis-
configure" the correct systems. This problem will correct
itself gradually as the faulty systems are retired, but it
cannot be ignored by vendors.
When we say that a parameter must be configurable, we do not
intend to require that its value be explicitly read from a
configuration file at every boot time. We recommend that
implementors set up a default for each parameter, so a
configuration file is only necessary to override those defaults
that are inappropriate in a particular installation. Thus, the
configurability requirement is an assurance that it will be
POSSIBLE to override the default when necessary, even in a
binary-only or ROM-based product.
This document requires a particular value for such defaults in
some cases. The choice of default is a sensitive issue when
the configuration item controls the accommodation to existing
faulty systems. If the Internet is to converge successfully to
complete interoperability, the default values built into
implementations must implement the official protocol, not
"mis-configurations" to accommodate faulty implementations.
Although marketing considerations have led some vendors to
choose mis-configuration defaults, we urge vendors to choose
defaults that will conform to the standard.
Finally, we note that a vendor needs to provide adequate
documentation on all configuration parameters, their limits and
effects.
---------------------------
做一个对周遭的事物包容的人,做一个对自己做事严谨的人!
2006年12月29日星期五
2006年11月24日星期五
七年之纪念日
七年前的这一天,拎着个小包带了几件衣服从原来的城市和原来工作了一年的公司请了个长假来到现在的公司,一晃真快。那时候对未来的生活和事业都不知道是什么样子,充满着未知数和憧憬。七年真快,人变得成熟了,事业也奋斗了,生活也......。现在好像又轮回了,重新开始考虑未来的事业,重新开始考虑未来的生活,一切也许是个新的开始。一直以"幸福"这个虚无缥缈的目标作为自己的目标。一直想要营造那种温馨浪漫幸福的生活,却屡屡受挫。忽然觉得,自己追求幸福的企图就好像是要抓住在风中飘浮的一朵羽毛,对着它一把抓过去,伸开手一看,却什么也没抓到,那朵羽毛仍然飘浮在空中。就这样抓呀抓,把自己变的很累也很沮丧。忽然明白,在追求幸福的过程中也许不必拼命去抓,用手捧也许更好吧。
今天是什么日子,今天是我来到这个城市来到这个公司的第八个年头的第一天。新的起点,新的开始。
2006年10月14日星期六
忘性越来越大
最近老是丢三拉四的,于是不得不总结一下了:
- 最近的这次:今天把两个钱包忘在公司大楼洗手间的洗手台上,结果是在将近一个小时后想起,并狂奔回来侥幸找到。我的确记得当时放上去的时候脑子里提醒过自己洗完手记得拿的。经验:今后不出远门、没什么事儿,钱包里面别塞那么多东西,就是带着钱包也随时放在包里,别老拿在手上,更别到处乱放。
- 国庆节:放假回老家时下了飞机还得捣腾两次大巴,为了不坐到汽车站再返回家,通知老哥开车在高速公路出口处等我,快下高速公路时我提着自己的小包挪到门口准备好,还跟副驾驶说等会儿把行李箱里面我的箱子取出来,然后打电话给老哥问在哪里。可到了的时候我跳下车一头钻进我哥的车就忘了,那个副驾驶TNND也没提醒我,开了将近十几分钟才想起糟糕。于是调转车头一路追到汽车站也没追到,我还压根儿就没记那车的牌号,连车的颜色还是想了半天才想到是白色,还好有车票,知道车次,可因为是晚上9点多钟了,双方的车站调度都下班了。我们仨这回可把洛阳的汽车总站给模了个透,挨着有四个车站,这顿找。最后问到一个同一线路的客车司机,这老兄说“兄弟,你运气真好,俺有那司机的电话”,还说了车牌,可电话已经关机,不过总算没白费力气。第二天一早电话打通,这才找到箱子。经验:下车别太急了,就算想家心切也别急,点点自己的东西先。
- 2004年底出差归来:经过一个多月在革命老区的出差,可把我憋坏了。出了机场打个车就奔家里,又是晚上。回到家才想起,箱子忘在出租车上了,当然里面大部分是些赃衣服,但还是有两件值钱的外套啊。还好拿了车票(要报销嘛),车票上有车牌号和出租公司的电话。第二天打过去,出租公司很快就找到了箱子。经验:还是别急啊,忘什么也别忘了拿出租车票,现在的出租基本都是自动打印发票,上面的信息还是比较全的。
- 2000年在酒吧:那时候年轻,几个朋友周末喜欢去坐坐,我的钱包喜欢装在牛仔裤的屁股兜里,坐在那里聊天喝酒,不知不觉就掉了,等俺出来准备坐车回家才发现,赶紧回去找,在旁边桌子下面找到了。酒吧里面灯光灰暗,我的钱包在地上被踢来踢去竟然还在。记得还有一次类似的经历是我撅着屁股在实验室蹲在一排交换机后面接电缆,钱包在一堆黑色的电缆中间藏了两天才被我找到。经验:钱包别装在牛仔裤的屁股兜里啊,特别是坐着的时候。估计那样坐公车也比较容易被小偷得手。
2006年10月1日星期日
回忆之一个人的大京珠-回家
每到长假,很多朋友们都自驾车回老家或者出游,每每听到有朋友谈论这个话题,偶就常常想起自己2006春节的那一段“千里走单骑”从深圳回洛阳老家的经历。从那次回来,偶就一直想把这次经历写下来,但由于实在是作文只有小学生水平,一直也没敢开写。现在又是假期,很多朋友问我是否还驾车回去,俺说不了,乘飞机了,这样多轻松啊。放假了闲来无事,就坐下来写写吧。因为凭大脑记忆,很多细节都记不清了,所以肯定有些地点时间会不准确哦。
出发――没有目的地
言归正传,废话少说。话说偶的2005年后半年比较衰,多年来第一次一个人过春节好不适应,不知道怎么过,也没什么计划。大年三十好友夫妇邀请吃年夜饭,美美吃了一顿,大年初一可劲儿睡到了11点半,起来吃了早餐,实际上应该是午饭了,12点半开车出门,路边加满油就准备出去逛逛,去哪里呢?去广州玩玩吧,于是上了广深一直往前开。说实在话开始根本没有计划回家,快到广州收费站时看到有个北二环标志,据说北二环过去就是京珠了,可以一路飚到老家门口。就停下车打老罗电话,此刻老罗正在海南Happy呢,老罗证实了俺的判断,于是突发念头,上京珠开开看,就毫不犹豫地拐上了北二环。嘿嘿,看着路标走,很快就上京珠了,车头对着的方向可就是老家的方向啊。
广东――兴奋,阳光,风景,休闲游
大年初一,家家团聚,在广东这样的发达省份,路上也没几辆车,当然也有赶路的,都飚的飞快,粤B的车牌最多。大晴天,阳光明媚,一点都不冷,由于车少,俺也有机会看看风景,车窗外风景都不错,心情也很好,飚的也不慢。很快就飚到清远境内,这里在修路,所以有几条车道不能通行,但车少,丝毫不影响速度。常常有朋友说跑京珠常常收到来自清远的超速罚单,所以俺也小心了很多,反正不赶路,慢慢开,看风景。越往北,山就多了,山洞钻一个又一个,钻出山洞就是高架,在两山中间的峡谷,高架蜿蜒重叠,比较壮观,偶独自一车飚在上面很刺激的说。慢慢的阳光就要变成夕阳了,带点金色的阳光照着那些山和路。在清远境内的时候正飚的爽,忽然发现路边侧卧一辆桑塔纳,姿势优美,撞土堆上了,一哥们正站在土堆上郁闷,我向他挥手表示慰问,看看他有没有需要帮助的,他只是点头苦笑,没反应,我就继续走了,大年初一整个翻车,估计这哥们不爽坏了,偶自己也多加了小心。穿过一个山洞的时候,偶已经连续开了三个小时了,于是就尿急,前方是一小桥,路边较宽敞,停下车,回头瞄了几眼,没发现车,于是就站在路边准备就地解决了,正在此刻,隐约听见有什么声音,向洞口瞄了一下,坏了,一辆黑色帕萨特已经正向我方飚来,好像还在减速,慌乱中慌忙藏好东西。更搞笑的是,帕萨特在我的车后面嘎就停了,两名女子夺门而出,毛着腰满地找草丛,哈哈,好险啊。到达曲江韶关附近境内,快到湖南了,山水就更美了,路边不光有山还有湖,再加上夕阳一照……早就听说这里的山很大,高速要翻过大山,有一段还是常年大雾,不过今天天气好,没见到雾,第一次飚这么长这么陡的坡还是比较兴奋。开始看到上山的外侧标有爬坡道,不知道什么意思,心想不都是爬坡嘛,干吗还有个单独的爬坡道,走到半坡,看到几个大货冒着黑烟像蜗牛一样吭哧吭哧在上面爬,才明白,这是专门给他们用的。翻过山顶就是长下坡,嘿嘿,又发现新东西,每下一段坡就发现内侧有一个急上的土坡或石子坡,上面还有些大土堆,旧轮胎什么的,应该是给那些刹车失灵的车缓冲用的。在韶关境内,在高速上就感受到了传说中的“丹霞”地貌,红土奇形,在夕阳照耀下煞是美丽,以后有空一定来瞻仰一下丹霞山。偶就这样不紧不慢在5点整的时候就出了广东了,下车活动活动筋骨,继续深入湖南。
湖南――搭黑,美女带路,夜宿长沙,阴天有雾,快马加鞭
进了湖南,山水更秀了,可惜天也慢慢变暗了,没功夫研究路边的风景,晚上总得找个地方睡觉啊。6点的时候就飚到了耒阳,低头一看油快完了,赶紧进加油站。冬天就是冬天,6点刚过天就黑下来了,看这耒阳太小,问了一下加油MM到长沙还有多远,答曰还有
湖北――水多桥多,大雾,疲惫,空旷,思家心切
进入湖北,雾越来越大,天越来越冷,时而可以看见比较惨得车祸。其中一辆货车从对面直接贯穿隔离带冲到我这一侧的沟里去了。湖北有很多湖泊河流,很多很长的大桥,现在记忆中只记得几个奇怪的名字了:斧头湖大桥等等,当然还有著名得长江大桥。偶长时间开车,饿了只啃点面包喝点水,所以比较疲惫,所以也格外小心。13点到达武汉,又快没油了,刚才还那么多加油站,现在却一个也看不见,所以在长江大桥前后这段都是小心翼翼稳稳当当地开,到武汉西只好下去加了油再上来,这里已经开始使用乙醇汽油了,比较不爽。湖北的距离比较短,就是赤壁-武汉-孝感-大悟这几个地方就快到河南了,雾也渐渐散去,车更少了,粤字牌的车几乎都看不见了,心中知道离深圳已经很远了,可离家越来越近了,因为偶尔也会看到豫字牌的车了,更加想快点到家了。有一段路在我的脑海里印象很深,那是在一望无际的旷野丘陵上的长长的一段缓坡路,云很低,只有偶一辆车,有一种处在天地之间的感觉、空旷、壮丽、深远。湖北和河南的交界处一定治安很乱,因为路上看到一巨猛的横幅:严厉打击车匪路霸,群众打死有奖。远远望见进入河南的拱门上的两头白象了,离家近了。
河南――雨雪冰,寒冷,黄河,我的家乡
刚进入河南不久,就下起了雨加雪。记的那个地方好像叫灵山,车外的温度很低,水也喝完了,于是就到灵山半坡的那个服务区补充给养,可能是人少吧,商店的服务员都围着炉子聊天。买了水,站在寒冷的路边,没有别人,没有别的车,阵阵寒意袭来,让偶直打哆嗦。离开深圳的时候,连一件稍微厚点的衣服都没带。寒冷越来越强烈,路面开始有冰,雨刮器刮着前挡玻璃上的冰吱嘎作响。路边不断有车祸发生,基本都是一下子不能适应湿滑的道路造成侧滑撞到护栏或者相撞,还有很惨的场面,警察正在忙活。遇此情景,偶也非常紧张,但看着逐渐暗下来的天,还是得硬着头皮赶路。河南的路面质量真的很差,修修补补的地方很多,很不平坦,路噪也很大,开起来真是战战兢兢。快到漯河,路两旁已经被白雪覆盖,路面也是被压的稀烂的雪水。有的路段时速只能
回家――温暖,饺子,爸爸妈妈,兄弟姐妹
终于回到熟悉的街道,来到家的楼下,停了车,抬头看见二楼的家灯火通明,他们一定都在等我吧,低头看里程表1800多公里。激动兴奋的心难以用文字表达,整理一下心情,给牵挂我的人打了个电话报我已经平安到了家。刚上楼梯,妈妈已经迎出了门,我单薄的衣着让妈妈吃了一惊,她一定是听见了车的声音,所以猜测是她的儿子回来了。温暖的家在迎接着我,我的爸爸妈妈,我的哥哥姐姐,我的外甥侄女,我的温暖的家。热腾腾的饺子已经到了我的眼前,是妈妈一个小时前刚刚包好的,一天没吃热饭了,好香好暖和。奇怪的是,此时的我竟然一点都不感觉累,我很开心,我很温暖。
2006年9月19日星期二
老同学,老情谊
先交待一下这次老同学见面的人物,以及偶心目中的他们(没见面时记忆中的他们):
gg张博士:正在广州读金融博士,比偶小,很聪明,记得以前读高中的时候比较稚气,他比我们都小嘛;
mm慧珍:不爱说话的乖女孩,瘦弱,长得挺漂亮,据传现在还有同学在追求着;
2班的一个gg:听他们说他的名字的时候,我第一反应是一个女同学,实在记不起来,可能毕竟不是一个班的吧。
那天中午正在上班,收到未知者短信说“我到广州了,明天去你那里”。我猜应该是慧珍吧,但还是故意回复说“你是谁,请给我电话”,想试试还能否听出同学的声音。于是电话来了,一听还是那个声音,一点都没变,而因为俺们班有两个慧珍,一慌竟然把姓给搞错了。第二天中午时分,他们来了,在接他们的地铁口,远远就看到了张博士和旁边的mm慧珍,一点都没变化啊。
他们住在我的家,老同学见面自然话很多,晚上常常聊到深夜凌晨,回忆中学时代的往事,说同学们都在干什么,谈以前年少时羞于提起的话题,聊那时朦胧的爱情。我发现我已经常常想不起很多同学的名字,虽然他们的样子在脑海里还很清晰,只有被人提醒说到那个名字的时候,我才说“哦!就是是那个谁谁谁”。张博士说慧珍mm这次来是要来看看我的,于是很惭愧,离开家很多年了,回去的时间却寥寥无几,别说去看同学,就连看父母都很少,每次回家都匆匆忙忙,两三天就走,我真的那么忙吗?心中想以后回家一定多住些日子,多陪陪父母大人,多看看老同学。晚上在滨海大道上,慧珍mm说收到一个在家乡的同学的短信,问她见到我没有,我是否还和以前一样。忽然间鼻子一酸,十来年未见的老同学还牵挂着,能不感动吗?慧珍说还有一个2班的gg在深圳工作,她有电话,晚上约到我家聚聚,我很高兴,来了以后才知道,我们俩上班的地方不过间隔200米,还几乎是同行,世界真小!
同学在的几天很不巧,老天爷总是下雨,也许他怕出去玩占用了太多谈话的时间吧,于是下雨的时候他们就呆在我家里,呵呵。虽然时间短暂,没有好好玩玩这个城市,但他们的到来我真的很开心,祝愿他们都好,希望今后常常能见见。
2006年8月20日星期日
理工大风流往事之母校回忆
1. Princeton University
2. Harvard University
3. Yale University
4. California Institute of Technology
Massachusetts Institute of Technology
Stanford University (tie)
7. University of Pennsylvania
8. Duke University
9. Columbia University
Dartmouth University
University of Chicago (tie)
对美国的的大学没有什么感觉,对这个排名也是。就像The executive editor Brian Kelly所说:“If schools move up a couple points, down a couple points, that's not really meaningful to us. The difference between 1 and 10 is minuscule. Whether that's minuscule or not to a reader, that's up to them.”
从新闻文中第一次知道母校的英文单词是“alma mater”,由此想起了母校,自从离开美丽的南京紫金山下宽大的母校后,已经整整8年了,很多凌乱的回忆时而会被想起,大部分的同学都从此没有见过面,不知到你们现在都在做什么,你们好吗?我的同学伙伴们。记得刚刚来到广东的时候,发现同一个公司里竟然有5、6个校友,而且还大部分是系友,后来通过校友又陆陆续续认识了不少校友,但基本上都是我们那个年级的同学。2004年冬天去成都招聘的一次出差途中,在飞机上,聊天中发现坐在我左右两边的两位同事大姐是学姐,前面还坐着一个同事是学长,因此很惊讶,这世界真小啊,聊起母校也倍感亲切。俺的母校原来是个军校,后来改了个理工大学的名字就转民了,当别人问俺哪个学校毕业的时候,俺喜欢说“炮兵工程学院”,这样听起来比较 “猛”点,呵呵。至今俺还保存着一个有点“猛”的证书“XXX同学,经研究,批准你为兵器工业总公司XXXXX标兵。”^_^。对母校的回忆很多,但咱实在不是写东西的料,还是ZT同学比较厉害,写了两本三国演义版网络文学:
2006年8月12日星期六
艰难的Blog选站历程
1. 自己建Blog站:先是想在自己的网站服务器上建一个Blog什么的,这样所有的东西自己都可以控制,而且速度没的说。但试了试觉得自己搞的东西毕竟功能和效果有限,而且又不是专业搞这个的,没有精力维护的很好。更重要的是没有专业网站搞得内容丰富,那些集成多种功能的专业Blog或Space站比较吸引人,而且和朋友交流起来就更不方便了。
2. MSN Spaces: 微软虽然不是老本行,但借助MSN的推广,用MSN Spaces的人真的不少,朋友之间交流起来很方便。但我不太喜欢MSN Spaces的风格,如果能集成其他自己关心的咨询就好了。另外,也是有一种对微软的偏见吧,也许这是搞技术的人常见的偏见,呵呵。总体来说,MSN Spaces不错。
3. NPHOTO.NET: 新摄影的个人主页和Blog可能知道的人很少,但由于学习摄影,常常到nphoto.net逛逛,记得2002年的时候还是个简单的论坛,当时注册了个帐号,就基本上很少上去了,一直以来都是关注xitek.com。但今年偶然的机会上去一看,嗯,发展的还不错,不仅作品比以前优秀了很多,而且网站也改的功能更强了,最难得的是我的帐号还能用。这里大部分是象我一样的摄影初学者,大家互相鼓励还算不错的。用了一段时间,感到毕竟是小站,后劲不足,速度很慢,比较难忍受。
4. 百度空间hi.baidu.com: 在这个Blog泛滥的年代,百度也来了。百度每时每刻都是畅通的,而且速度很快,对于我国的internet冲浪者来说,比较爽。百度空间做的还可以,但用起来好像bug比较多。我特别喜欢它的“所见即所得WYSIWYG: What you see is what you get”的功能,但就是对图片上载的尺寸控制上没有做好。总体上百度空间是很好的,但就是可能由于起步晚,做的比较粗糙。
5. Yahoo! 360:其实使用Yahoo!已经很多年了,从1999年注册Yahoo!ID以来,几乎所有有关Finance的信息都是使用Yahoo!,my.yahoo.com更是很好用,它允许你编辑自己感兴趣的咨询,内容很丰富。去年开始通过Frank知道了flickr.com这个photo管理的好东东而被flickr.com所吸引,而flickr.com被Yahoo!收购了,最近又知道flickr.com也集成进了slide.com,^_^。虽然Yahoo! 360的Blog对图片上有些缺陷(一篇Blog只能一个photo),要是它的WYSIWYG对photo的处理更灵活些,象Google Blogger或百度空间就好了。但因为有专门的相册和集成了flickr.com,这些也就可以忍受了。
6. Google Blogger:曾经最想用的就是Google Blogger了,一是对Google的亲和,而是觉得做的的确简洁好用,但作为我国人,却要常常忍受blogspot.com被封掉。此时此刻,试了一下,blogspot.com又可以上去了,但愿从此不在被封。另外,Picasa也集成了Blogger和Hello。
呵呵,一路下来,比较费时间的说,但总算确定了个地方。


