Any message for me or my blog?

Leave’em here

Powered by Ggarlic

哈哈。整一个全cli的系统一直是我的梦想，dos就免了，功能太弱了。就这么定了。回家用家里的破机子折腾折腾去。一直想看看bsd到底什么样的，哈哈哈。

考虑是不是给本子换一个大硬盘，到时候win+ubuntu+OpenSuse+FreeBSD，惭愧啊惭愧，学计算机的，还是离不开win，学校的IDE是vs6，不用还不行，而且，，，，，，，，为了痛快的游戏跟office，我还是留着win吧，这就是它存在的全部价值。

这两天要考试了，烦死了，读书笔记也好几天不做了，第一卷我看了看，还是咬咬牙，买了一本，有些书还是不看电子书的好，没感觉，效果也不好。实体书拿在手里的感觉真实爽啊

暖冬的XA终于下雪了，一天，虽然小的可怜，但是仍然集了挺厚的一层。看着外面洁白的一片，我心中不由得升起了---------破坏欲

要考试了，实在忙不过来了，笔记暂缓。昨晚2点睡的。困阿

有感于XXXXXXXX

Powered by ScribeFire.

Network Working Group L. Masinter
Request for Comments: 2324 1 April 1998
Category: Informational

Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

Status of this Memo

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

This document describes HTCPCP, a protocol for controlling,
moni×ing, and diagnosing coffee pots.

1. Rationale and Scope

There is coffee all over the world. Increasingly, in a world in which
computing is ubiquitous, the computists want to make coffee. Coffee
brewing is an art, but the distributed intelligence of the web-
connected world transcends art. Thus, there is a strong, dark, rich
requirement for a protocol designed espressoly for the brewing of
coffee. Coffee is brewed using coffee pots. Networked coffee pots
require a control protocol if they are to be controlled.

Increasingly, home and consumer devices are being connected to the
Internet. Early networking experiments demonstrated vending devices
connected to the Internet for status moni×ing [COKE]. One of the
first remotely _operated_ machine to be hooked up to the Internet,
the Internet Toaster, (controlled via SNMP) was debuted in 1990
[RFC2235].

The demand for ubiquitous appliance connectivity that is causing the
consumption of the IPv4 address space. Consumers want remote control
of devices such as coffee pots so that they may wake up to freshly
brewed coffee, or cause coffee to be prepared at a precise time after
the completion of dinner preparations.

Masinter Informational [Page 1]

RFC 2324 HTCPCP/1.0 1 April 1998

This document specifies a Hyper Text Coffee Pot Control Protocol
(HTCPCP), which permits the full request and responses necessary to
control all devices capable of making the popular caffeinated hot
beverages.

HTTP 1.1 ([RFC2068]) permits the transfer of web objects from origin
servers to clients. The web is world-wide. HTCPCP is based on HTTP.
This is because HTTP is everywhere. It could not be so pervasive
without being good. Therefore, HTTP is good. If you want good coffee,
HTCPCP needs to be good. To make HTCPCP good, it is good to base
HTCPCP on HTTP.

Future versions of this protocol may include extensions for espresso
machines and similar devices.

2. HTCPCP Protocol

The HTCPCP protocol is built on top of HTTP, with the addition of a
few new methods, header fields and return codes. All HTCPCP servers
should be referred to with the "coffee:" URI scheme (Section 4).

2.1 HTCPCP Added Methods

2.1.1 The BREW method, and the use of POST

Commands to control a coffee pot are sent from client to coffee
server using either the BREW or POST method, and a message body with
Content-Type set to "application/coffee-pot-command".

A coffee pot server MUST accept both the BREW and POST method
equivalently. However, the use of POST for causing actions to happen
is deprecated.

Coffee pots heat water using electronic mechanisms, so there is no
fire. Thus, no firewalls are necessary, and firewall control policy
is irrelevant. However, POST may be a trademark for coffee, and so
the BREW method has been added. The BREW method may be used with
other HTTP-based protocols (e.g., the Hyper Text Brewery Control
Protocol).

2.1.2 GET method

In HTTP, the GET method is used to mean "retrieve whatever
information (in the form of an entity) identified by the Request-
URI." If the Request-URI refers to a data-producing process, it is
the produced data which shall be returned as the entity in the
response and not the source text of the process, unless that text
happens to be the output of the process.

Masinter Informational [Page 2]

RFC 2324 HTCPCP/1.0 1 April 1998

In HTCPCP, the resources associated with a coffee pot are physical,
and not information resources. The "data" for most coffee URIs
contain no caffeine.

2.1.3 PROPFIND method

If a cup of coffee is data, metadata about the brewed resource is
discovered using the PROPFIND method [WEBDAV].

2.1.4 WHEN method

When coffee is poured, and milk is offered, it is necessary for the
holder of the recipient of milk to say "when" at the time when
sufficient milk has been introduced into the coffee. For this
purpose, the "WHEN" method has been added to HTCPCP. Enough? Say
WHEN.

2.2 Coffee Pot Header fields

HTCPCP recommends several HTTP header fields and defines some new
ones.

2.2.1 Recommended header fields

2.2.1.1 The "safe" response header field.

[SAFE] defines a HTTP response header field, "Safe", which can be
used to indicate that repeating a HTTP request is safe. The inclusion
of a "Safe: Yes" header field allows a client to repeat a previous
request if the result of the request might be repeated.

The actual safety of devices for brewing coffee varies widely, and
may depend, in fact, on conditions in the client rather than just in
the server. Thus, this protocol includes an extension to the "Safe"
response header:

Safe = "Safe" ":" safe-nature
safe-nature = "yes" | "no" | conditionally-safe
conditionally-safe = "if-" safe-condition
safe-condition = "user-awake" | token

indication will allow user agents to handle retries of some safe
requests, in particular safe POST requests, in a more user-friendly
way.

Masinter Informational [Page 3]

RFC 2324 HTCPCP/1.0 1 April 1998

2.2.2 New header fields

2.2.2.1 The Accept-Additions header field

In HTTP, the "Accept" request-header field is used to specify media
types which are acceptable for the response. However, in HTCPCP, the
response may result in additional actions on the part of the
automated pot. For this reason, HTCPCP adds a new header field,
"Accept-Additions":

Accept-Additions = "Accept-Additions" ":"
#( addition-range [ accept-params ] )

addition-type = ( "*"
| milk-type
| syrup-type
| sweetener-type
| spice-type
| alcohol-type
) *( ";" parameter )
milk-type = ( "Cream" | "Half-and-half" | "Whole-milk"
| "Part-Skim" | "Skim" | "Non-Dairy" )
syrup-type = ( "Vanilla" | "Almond" | "Raspberry"
| "Chocolate" )
alcohol-type = ( "Whisky" | "Rum" | "Kahlua" | "Aquavit" )

2.2.3 Omitted Header Fields

No options were given for decaffeinated coffee. What's the point?

2.3 HTCPCP return codes

Normal HTTP return codes are used to indicate difficulties of the
HTCPCP server. This section identifies special interpretations and
new return codes.

2.3.1 406 Not Acceptable

This return code is normally interpreted as "The resource identified
by the request is only capable of generating response entities which
have content characteristics not acceptable according to the accept
headers sent in the request. In HTCPCP, this response code MAY be
returned if the opera× of the coffee pot cannot comply with the
Accept-Addition request. Unless the request was a HEAD request, the
response SHOULD include an entity containing a list of available
coffee additions.

Masinter Informational [Page 4]

RFC 2324 HTCPCP/1.0 1 April 1998

In practice, most automated coffee pots cannot currently provide
additions.

2.3.2 418 I'm a teapot

Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout.

3. The "coffee" URI scheme

Because coffee is international, there are international coffee URI
schemes. All coffee URL schemes are written with URL encoding of the
UTF-8 encoding of the characters that spell the word for "coffee" in
any of 29 languages, following the conventions for
internationalization in URIs [URLI18N].

coffee-url = coffee-scheme ":" [ "//" host ]
["/" pot-designa× ] ["?" additions-list ]

coffee-scheme = ( "koffie" ; Afrikaans, Dutch
| "q%C3%A6hv%C3%A6" ; Azerbaijani
| "%D9%82%D9%87%D9%88%D8%A9" ; Arabic
| "akeita" ; Basque
| "koffee" ; Bengali
| "kahva" ; Bosnian
| "kafe" ; Bulgarian, Czech
| "caf%C3%E8" ; Catalan, French, Galician
| "%E5%92%96%E5%95%A1" ; Chinese
| "kava" ; Croatian
| "k%C3%A1va ; Czech
| "kaffe" ; Danish, Norwegian, Swedish
| "coffee" ; English
| "kafo" ; Esperanto
| "kohv" ; Estonian
| "kahvi" ; Finnish
| "%4Baffee" ; German
| "%CE%BA%CE%B1%CF%86%CE%AD" ; Greek
| "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; Hindi
| "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; Japanese
| "%EC%BB%A4%ED%94%BC" ; Korean
| "%D0%BA%D0%BE%D1%84%D0%B5" ; Russian
| "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; Thai
)

pot-designa× = "pot-" integer ; for machines with multiple pots
additions-list = #( addition )

Masinter Informational [Page 5]

RFC 2324 HTCPCP/1.0 1 April 1998

All alternative coffee-scheme forms are equivalent. However, the use
of coffee-scheme in various languages MAY be interpreted as an
indication of the kind of coffee produced by the coffee pot. Note
that while URL scheme names are case-independent, capitalization is
important for German and thus the initial "K" must be encoded.

4. The "message/coffeepot" media type

The entity body of a POST or BREW request MUST be of Content-Type
"message/coffeepot". Since most of the information for controlling
the coffee pot is conveyed by the additional headers, the content of
"message/coffeepot" contains only a coffee-message-body:

coffee-message-body = "start" | "stop"

5. Operational constraints

This section lays out some of the operational issues with deployment
of HTCPCP ubiquitously.

5.1 Timing Considerations

A robust quality of service is required between the coffee pot user
and the coffee pot service. Coffee pots SHOULD use the Network Time
Protocol [NTP] to synchronize their clocks to a globally accurate
time standard.

Telerobotics has been an expensive technology. However, with the
advent of the Cambridge Coffee Pot [CAM], the use of the web (rather
than SNMP) for remote system moni×ing and management has been
proven. Additional coffee pot maintenance tasks might be
accomplished by remote robotics.

Web data is normally static. Therefore to save data transmission and
time, Web browser programs s×e each Web page retrieved by a user on
the user's computer. Thus, if the user wants to return to that page,
it is now s×ed locally and does not need to be requested again from
the server. An image used for robot control or for moni×ing a
changing scene is dynamic. A fresh version needs to be retrieved from
the server each time it is accessed.

5.2 Crossing firewalls

In most organizations HTTP traffic crosses firewalls fairly easily.
Modern coffee pots do not use fire. However, a "firewall" is useful
for protection of any source from any manner of heat, and not just
fire. Every home computer network SHOULD be protected by a firewall
from sources of heat. However, remote control of coffee pots is

Masinter Informational [Page 6]

RFC 2324 HTCPCP/1.0 1 April 1998

important from outside the home. Thus, it is important that HTCPCP
cross firewalls easily.

By basing HTCPCP on HTTP and using port 80, it will get all of HTTP's
firewall-crossing virtues. Of course, the home firewalls will require
reconfiguration or new versions in order to accommodate HTCPCP-
specific methods, headers and trailers, but such upgrades will be
easily accommodated. Most home network system administra×s drink
coffee, and are willing to accommodate the needs of tunnelling
HTCPCP.

6. System management considerations

Coffee pot moni×ing using HTTP protocols has been an early
application of the web. In the earliest instance, coffee pot
moni×ing was an early (and appropriate) use of ATM networks [CAM].

The traditional technique [CAM] was to attach a frame-grabber to a
video camera, and feed the images to a web server. This was an
appropriate application of ATM networks. In this coffee pot
installation, the Trojan Room of Cambridge University labora×ies
was used to give a web interface to moni× a common coffee pot. of
us involved in related research and, being poor, impoverished
academics, we only had one coffee filter machine between us, which
lived in the corridor just outside the Trojan Room. However, being
highly dedicated and hard-working academics, we got through a lot of
coffee, and when a fresh pot was brewed, it often didn't last long.

This service was created as the first application to use a new RPC
mechanism designed in the Cambridge Computer Labora×y - MSRPC2. It
runs over MSNL (Multi-Service Network Layer) - a network layer
protocol designed for ATM networks.

Coffee pots on the Internet may be managed using the Coffee Pot MIB
[CPMIB].

7. Security Considerations

Anyone who gets in between me and my morning coffee should be
insecure.

Unmoderated access to unprotected coffee pots from Internet users
might lead to several kinds of "denial of coffee service" attacks.
The improper use of filtration devices might admit trojan grounds.
Filtration is not a good virus protection method.

Masinter Informational [Page 7]

RFC 2324 HTCPCP/1.0 1 April 1998

Putting coffee grounds into Internet plumbing may result in clogged
plumbing, which would entail the services of an Internet Plumber
[PLUMB], who would, in turn, require an Internet Plumber's Helper.

Access authentication will be discussed in a separate memo.

8. Acknowledgements

Many thanks to the many contribu×s to this standard, including Roy
Fielding, Mark Day, Keith Moore, Carl Uno-Manros, Michael Slavitch,
and Martin Duerst. The inspiration of the Prancing Pony, the CMU
Coke Machine, the Cambridge Coffee Pot, the Internet Toaster, and
other computer controlled remote devices have led to this valuable
creation.

9. References

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068,
January 1997.

[RFC2186] Wessels, D., and K. Claffy, "Internet Cache Protocol (ICP),
version 2," RFC 2186, September 1997

[CPMIB] Slavitch, M., "Definitions of Managed Objects for Drip-Type
Heated Beverage Hardware Devices using SMIv2", RFC 2325, 1 April
1998.

[HTSVMP] Q. Stafford-Fraser, "Hyper Text Sandwich Van Moni×ing
Protocol, Version 3.2". In preparation.

[RFC2295] Holtman, K., and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, March 1998.

[SAFE] K. Holtman. "The Safe Response Header Field", September 1997.

[CAM] "The Trojan Room Coffee Machine", D. Gordon and M. Johnson,
University of Cambridge Computer Lab,

[CBIO] "The Trojan Room Coffee Pot, a (non-technical) biography", Q.
Stafford-Fraser, University of Cambridge Computer Lab,
.

[RFC2235] Zakon, R., "Hobbes' Internet Timeline", FYI 32, RFC 2230,
November 1997. See also

Masinter Informational [Page 8]

RFC 2324 HTCPCP/1.0 1 April 1998

[NTP] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.

[URLI18N] Masinter, L., "Using UTF8 for non-ASCII Characters in
Extended URIs" Work in Progress.

[PLUMB] B. Metcalfe, "Internet Plumber of the Year: Jim Gettys",
Infoworld, February 2, 1998.

[COKE] D. Nichols, "Coke machine his×y", C. Everhart, "Interesting
uses of networking", .

10. Author's Address

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

EMail: masinter@parc.xerox.com

Masinter Informational [Page 9]

RFC 2324 HTCPCP/1.0 1 April 1998

11. Full Copyright Statement

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

昨天一直在修理烦人的Mplayer，没时间写这个，今天补上。

1.7    分用Demultiplexing

概念详见原文

协议ICMP，IGMP，ARP，RARP在分用中的定位问题太长了，懒得抄了

当进一步描述T C P的细节时，我们将看到协议确实是通过目的端口号、源 I P地址和源端口号进行解包的

1.8   客户-服务器模型

重复型服务器：

I1. 等待一个客户请求的到来。
I2. 处理客户请求。
I3. 发送响应给发送请求的客户。
I4. 返回I 1步。

并发型服务器：

C1. 等待一个客户请求的到来。
C2. 启动一个新的服务器来处理这个客户的请求。在这期间可能生成一个新的进程、任务
或线程，并依赖底层操作系统的支持。这个步骤如何进行取决于操作系统。生成的新服务器
对客户的全部请求进行处理。处理结束后，终止这个新服务器。
C3. 返回C 1步。

对服务器进行分类而不对客户分类的原因见书

TCP服务器是并发的，而 UDP服务器是重复的，但也存在一些例外

1.9   端口号

知名端口号，动态端口号，保留端口号

服务器一般都是通过知名端口号来识别的。任何TCP/IP实现所提供的服务都用知名的1～1023之间的端口号。这些知名端口号由Internet号分配机构（Internet Assigned Numbers Authority, IANA）来管理。

注意这里unix跟一般OS在端口号上的不同，比如256～1023之间的端口号通常都是由U n i x系统占用，以提供一些特定的U n i x服务，比如保留端口号

客户端通常对它所使用的端口号并不关心，只需保证该端口号在本机上是唯一的就可以了。客户端口号又称作临时端口号（即存在时间很短暂） 。这是因为它通常只是在用户运行该客户程序时才存在，而服务器则只要主机开着的，其服务就运行。

大多数TCP/IP实现给临时端口分配1024～5000之间的端口号。大于5000的端口号是为其他服务器预留的（Internet上并不常用的服务)

1.10   标准化过程

了解一下就行了，看上下文，貌似ISOC最牛，IAB隶属于它，IETF，IRIF有隶属于ISOC

ISOC，IAB，IETF，IRIF

1.11   RFC

所有关于Internet的正式标准都以RFC（Request for Comment）文档出版。另外，大量的RFC并不是正式的标准，出版的目的只是为了提供信息。

一些重要的RFC我已经用通过email获取了

1.12 标准的简单服务

当使用TCP和UDP提供相同的服务时，一般选择相同的端口号。

如果仔细检查这些标准的简单服务以及其他标准的TCP/IP服务（如Telnet、FTP、 SMTP等）的端口号时，我们发现它们都是奇数。这是有历史原因的，因为这些端口号都是从NCP端口号派生出来的（NCP，即网络控制协议，是ARPANET的运输层协议，是TCP的前身）。NCP是单工的，不是全双工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。当TCP和UDP成为标准的运输层协议时，每个应用程序只需要一个端口号，因此就使用了NCP中的奇数。

怎么没说明啥是“单工”“全双工”，还要自己去查

1、单工
单工就是指A只能发信号，而B只能接收信号，通信是单向的，就象灯塔之于航船——灯塔发出光信号而航船只能接收信号以确保自己行驶在正确的航线上。 
2、半双工
    半双工就是指A能发信号给B，B也能发信号给A，但这两个过程不能同时进行。最典型的例子就象我们在影视作品中看到的对讲机一样：

007：呼叫总部，请求支援，OVER  
总部：收到，增援人员将在5分钟内赶到，OVER  
007：要5分钟这么久？！要快呀！OVER  
总部：……  
　　　　　　　GAME OVER

    在这里，每方说完一句话后都要说个OVER，然后切换到接收状态，同时也告之对方——你可以发言了。如果双方同时处于收状态，或同时处于发状态，便不能正常通信了。
3、全双工
全双工比半双工又进了一步。在A给B发信号的同时，B也可以给A发信号。典型的例子就是打电话。 

A：我跟你说呀…… 
B：你先听我说，情况是这样的…… 

    A和B在说的同时也能听到对方说的内容，这就是全双工。 

1.13   互联网

internet意思是用一个共同的协议族把多个网络连接在一起。而Internet指的是世界范围内通过TCP/IP互相通信的所有主机集合（超过100万台）。Internet是一个internet，但internet不等于Internet。这个观点我还是第一回听说

1.14    实现

关于BSD的，不废话了，看书去吧

1.15   应用编程接口

使用TCP/IP协议的应用程序通常采用两种应用编程接口（API）：socket和TLI（运输层接口：Transport Layer Interface）。

第一章终于结束了

正在放Attraction哈，挺符合心境的。Ok，move on to Chapter Two

页面操作
SPC,C-v 向下翻页
b,ESC v 向上翻页
l,C-f 焦点向右
h,C-b 焦点向左
j,C-n 焦点向下
k,C-p 焦点向上
J 向上滚动一行
K 向下滚动一行
^,C-a 到行首
$,C-e 到行尾
w 到下一个单词
W 到上一个单词
> 右移一屏
到末行
ESC g 到指定行
Z 当前行居中
z 当前列居中
TAB 转到下个超链接
C-u,ESC TAB 到上个超链接
[ 到第一个超链接
] 到最后一个超链接

超链接操作
RET 打开超链接
a, ESC RET 链接另存为
u 查看链接url
i 查看图片url
I 查看图片
ESC I 图片另存为
: 标记rul字符串为锚点
ESC : 标记ID串为锚点
c 查看当前页面的URL
= 显示当前页面属性
C-g 查看当前行号
C-h 查看历史记录
F 提交表单
M 用外部浏览器打开当前页面 (use 2M and 3M to invoke second and third browser)
ESC M 用外部浏览器打开链接 (use 2ESC M and 3ESC M to invoke second and third browser)

文件/流 操作
U 打开URL
V 打开文件
@ 执行外部命令并导入
# 执行外部命令并浏览

缓存操作
B 返回
v 查看源代码
s 选择缓存
E 编辑缓存代码
C-l 重画屏幕
R 刷新
S 页面另存为
ESC s 源码另存为
ESC e 编辑图片

缓存选择模式（也就是按了s以后）
k, C-p 上一缓存
j, C-n 下一缓存
D 删除当前缓存
RET 转至选择的缓存

书签操作
ESC b 打开书签
ESC a 添加当前页到书签

搜索
/,C-s 向前搜索
?,C-r 向后搜索
n 下一个
N 上一个
C-w 打开/关闭 循环搜索

标记
C-SPC 设定/取消 标记（这个键一般被输入法占用了）
ESC p 转至上一标记
ESC n 转至下一标记
" 使用正则表达式标记

杂项
! 执行外部命令
H 帮助
o 设置选项
C-k 显示接受到的cookie
C-c 停止
C-z 挂起（退出）
q 退出（需确认）
Q 退出而不确认

行编辑模式
C-f 光标向后
C-b 光标向前
C-h 删除前一字符
C-d 删除当前字符
C-k 删除光标后所有内容
C-u 删除光标前所有内容
C-a 光标到行首
C-e 光标到行尾
C-p 取得历史记录中的前一个词
C-n 取得历史记录中的后一个词
TAB,SPC 自动完成文件名
RETURN 确定

Powered by ScribeFire.

听说某些国家已经无法访问了，难道GFW是双向的？

不管那么多了，这种垃圾早该被封，看着一帮人在里面装酷装颓废我就恶心。虽然我不喜欢GFW，但是这次它做的对，我们绝对不能让Qzone丢人丢到国外去。

TX的定位实在是太低下了，我甚至都觉得有损。。。的光辉成就。看看我们的青少年都在干什么，挂qq，为了几个破星星月亮，每年浪费国家多少电。我那个小妹就成天央求我给她挂qq，烦人的很，在他们眼中有个太阳是很光荣的事。日！

看看TX怎么抓住青少年的心吧：积分，等级，完全是哄小孩的东西，大家从小被教育要争第一，比别人等级高当然高兴。qq邮箱确实做的不错，跟qq整合的很好，功能也很强大，而且比gmail速度快（国内貌似没有比gmail慢的）。但就凭它那个可恶的积分政策我就坚决抵制用它，最让我不能忍受的是连官方都没想好积分要怎么用。看着我周围那几个同学每天为了几个积分狂发邮件，我有种哭笑不得的感觉，兄弟，多大了？

最近QQ又在搞问问了，我最不看好TX在这方面的实力，不说别的，单单是他的用户的水平，呵呵，实在不敢恭维。虽然是人肉引擎，但肯定比不上baidu，更不用说wikipedia了。如果说“百度一年你也不知道”的话，那么QQ问问就是，哈哈，不说了，省的招人扁。

Qzone这种被阉割的然后被打扮的跟个妓女似的BLog根本就不应该出现在世界上。

我总算知道MSN，AIM这帮国际大鳄为什么打不过QQ了，首先是积分跟等级制度，其次是就是先天人数优势：周围的人都在用，不用就会被孤立（自己用MSN跟谁聊去啊）。我想这帮不熟悉中国国情的老毛子想坏了脑子都想不出这个原因。我还是继续去usenet跟irc上窝着去吧，虽然大多数时候插不上话（里面高人确实多），但总比在QQ群里听一帮人大呼小叫强

PS：貌似QQ一直在偷，连QQ本身都是偷来的，最近除了偷出了一个问问，还有一个叨客，虽然我喜欢Twitter，但我不会碰叨客一下，我怕破坏我心中twitter的形象，