优快云的Blog,我们最需要什么?

优快云的Blog是我写的最早的一个Blog，用了很久，屡次想要放弃，却始终有所不舍。习惯了总数有感情的。
但是前几天还是写下了一篇Blog，声明放弃优快云的这个Blog。

今天上来，居然看到了优快云的Blog发生了一些变化：
1.增加了最近回复的列表
这是一个好的变化，虽然我想不通为什么实现这样一个简单的功能需要这么漫长的等待...
2.对于SPAM的处理
我不知道在后台作了怎样的处理，但是优快云可能是对垃圾留言痛下了杀手，我的评论里边铺天盖地的垃圾回复不见了。

在我放弃优快云的Blog声明中，我曾经提到过，垃圾回复已经让我忍无可忍了，删除起来累得自己手酸(况且优快云又是出奇的慢)，而如果放任，

你知道，就仿佛看到自己的花园里杂草丛生，于心何忍?
于是，强忍心痛，放弃吧。

优快云的改变让我提出想到一个问题: 优快云的Blog,我们最需要什么?
既然大家这么多人在这里，这么多人爱着优快云，那么我们有必要提出自己的观点。
就我自己而言，我有这样一些想法，为着我曾经使用了那么久的Blog:

1.我最需要的是稳定性
对于每个Blogger来说，最痛心的莫过于看到自己的辛苦努力付之东流，所以稳定性是我最关心的。
在我的记忆中，优快云有过一次最重大的故障，应该是2004.11.26，经历了长久的无法访问以后，恢复过程中又出现了内容混乱，文章混乱的情

况，那天我写了一篇Blog:《优快云的Blog怎么了?》(找不到链接了，优快云太慢了，就在我尝试打开时，又死掉了).

也许问题总是难免的，可是我从未看到优快云官方关于问题的声明或者公告(也许有，但是我没有看到)，所有Blogger除了对自己的文章安全惴惴

不安以外，一无所知了。

而实话实说，优快云是我所见过的Blog里边最不稳定的。
几乎每天我访问的时候都能碰到服务器错误的情况，很多人恨恨的骂:微软的东西就是不稳定...

可是优快云为什么就不能做的更好一些呢?稳定就那么难么?

2.对于垃圾留言的防范
此前我想优快云的Blog也许是不设防的，随便一个机器人就可以不停的发送垃圾留言上来。
这让我深恶痛绝。
当然这是所有Blog面临的问题之一，以致在不久之前几大搜索引擎联合抵制SPAM，six apart也推出了专门的插件nofollow用以制止SPAM。

好在，优快云终于有了动作，但是是怎样一种机制呢?
我希望是一种良好的永久的机制，而不是一时兴起在后台的批量删除(想想不太可能吧?)

改进是一个好事情，可是为什么不做一个改进/新增功能列表呢?让使用者也知道某些等待并非遥遥无期?

3.速度
我想人人都想要更好的速度，作为一个服务提供商可能要考虑怎样满足大部分用户的需求。我暂时先不考虑这些。
我的情况时，优快云的Blog...,太太太慢了...
现在我测试了一下，在北京网通ADSL宽带访问优快云，ping测试的速度:
C:\>ping www.youkuaiyun.com

Pinging www.youkuaiyun.com [61.186.252.133] with 32 bytes of data:

Reply from 61.186.252.133: bytes=32 time=694ms TTL=115
Reply from 61.186.252.133: bytes=32 time=734ms TTL=115
Reply from 61.186.252.133: bytes=32 time=761ms TTL=115
Request timed out.

Ping statistics for 61.186.252.133:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 694ms, Maximum = 761ms, Average = 729ms

C:\>ping blog.youkuaiyun.com

Pinging blog.youkuaiyun.com [61.186.252.132] with 32 bytes of data:

Reply from 61.186.252.132: bytes=32 time=741ms TTL=115
Reply from 61.186.252.132: bytes=32 time=730ms TTL=115
Request timed out.
Reply from 61.186.252.132: bytes=32 time=815ms TTL=115

Ping statistics for 61.186.252.132:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 730ms, Maximum = 815ms, Average = 762ms

平均相应时间在750ms吧，丢包咱就不计较了。
在北京有多少网通用户呢?这还是在周末空闲时段，在繁忙时段我就暂时不想了，慢就慢吧，写这篇blog之前点"写文章"，写完之后总会出来了

吧?

而且似乎，阅读的时候可能速度好些，一旦进入后台管理界面，巨慢无比...

关注了一下以上两个ip，网上的显示是:
61.186.252.133
来自 重庆市 电子职业技术学院

原来机器远在重庆(不知道这信息是否准确)，也许只是一台pcServer,也许是台兼容机，这样为什么频频down机就可以解释了。

对了，也许是我的网络问题，也许别人都很快?

4.美观问题

算了，这个问题我不应该提的，咱们还是朴素点好。
可是最近新浪的Blog也开张了，最近在进行内部测试，sina的也很简单，可是感觉很大方，心里是有一点喜欢的。

也许csdn是不做修改的吧，我对这个Blog的也不是很熟悉，刚才试图访问了一下 Copyright的Scott Watermasysk
一下子就看到了熟悉的页面:

Server Error in '/' Application.
--------------------------------------------------------------------------------

Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the

details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers

running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a

<customErrors> tag within a "web.config" configuration file located in the root directory of the current web application.

This <customErrors> tag should then have its "mode" attribute set to "Off".

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect"

attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>

对了，这就是在优快云上经常看到的，不过有些字是中文的而已。
也许，这个，就不说了。

如果优快云能解决前三点，也许这里将是大家更好的一个居所.

那么你呢?对你来说，优快云的Blog你最需要什么?