This blog was discontinued. pls visit the new site.

https://www.ibm.com/developerworks/mydeveloperworks/blogs/dbtrue/?lang=en

or

http://www.dbtrue.com/blog/

Please visit my new blog and DB2FAQ

www.yhcss.com is my new site and you can find a DB2 FAQ I'm running. The Faq is just at the beginning and your input is highly appreciated.

the DB2FAQ locate here: db2faq.yhcss.com

Programmers Only: Optimistic Locking

转一篇关于locking的文章，学习ing।

LOCKING BASICS

For the purposes of this article, let us assume that we have chosen LOCKSIZE PAGE (or ANY) for the table spaces used in the examples. In this article, whenever I use the word PAGE you may substitute ROW if you like.

The DB2 for z/OS lock manager (also known as the IRLM) is designed to monitor access to data stored in DB2 tables. The IRLM is consulted every time an application requests a lock. The IRLM then decides whether or not the requested lock can be obtained concurrently with existing locks held by other users or if the requested lock must wait in a queue and be handled serially. If the latter situation occurs, then the request will either be granted after the other incompatible locks are released or it won't be granted at all and the requester will timeout while waiting. In other words, the IRLM decides and enforces the logic that is needed — concurrent versus serialized access logic (see my prior columns on locking, listed in Resources).

The IRLM needs no special directions for the length of time to hold exclusive (X) page locks. They're held from the time they're acquired until they're released at COMMIT. Period. No more discussion. The COMMIT may be explicitly coded or may be implicit (such as COMMITs after ROLLBACKs or at program termination). Once you've acquired a page X-lock you no longer need to worry about someone else updating or deleting your data during your unit of recovery. What the application programmer must worry about and understand is the concept of duration for readers. But not just any readers. In this article, we're talking about a reader who intends to update the data he has read. Our reader is worried about other users updating his data between his read and his update. Our reader recognizes that there's a vulnerable duration between the initial read and the eventual update. If someone else is able to update the data during this unprotected duration, then what will happen when our reader does his update? Our reader's update will overlay the update that occurred during the duration. He will never ever be rewarded for overlaying
someone else's update. This duration between the read and the following update, this potential data integrity exposure, is entirely under the control of the application
programmer.

PESSIMISTIC LOCKING TECHNIQUES

There are many ways of protecting the data between the read and the subsequent update. If we are pessimists, we will assume that there are users out there lying in wait for our data, exactly our data, our page, our row. Therefore, we must protect the data we're reading at any cost. But not all pessimistic locking has the same impact on concurrency and performance. The techniques vary from extreme to potentially tolerable.

Probably the most pessimistic technique would be to BIND the program with ISOLATION RR. With ISOLATION RR, the application attempts to acquire an S-lock on every page read (for every single SQL statement on every table the application uses) whether or not a row qualified on that page. And it holds and accumulates the S-locks until COMMIT. This isn't a very realistic solution for multiple reasons. First, concurrency and performance would suffer dreadfully and, second, online applications would still be in trouble unless they used CICS conversational techniques or the equivalent. Likewise, binding with ISOLATION RS, which "only" acquires locks on pages in which rows qualify (accumulating those locks until COMMIT), is seldom a realistic solution.

Another pessimistic technique would be to have a LOCK TABLE IN EXCLUSIVE MODE statement embedded in the program for those tables being read and subsequently updated. Just kick everyone else out of the tables. While this technique may work for a few applications, it isn't a very realistic solution for day-to-day batch activity and certainly not for online applications.

A third pessimistic technique would be to use the FOR UPDATE OF clause in a DECLARE CURSOR statement. Surprised? The FOR UPDATE OF clause is pessimistic because it assumes that someone will update the data if it isn't "tied up." The application programmer is so sure that someone will update our reader's data that he's willing to acquire not just one lock but two: a U-lock that will be held while our reader is evaluating the data and then an X-lock when he actually does the update. The conversion of the U- to an X-lock is done by means of an upgrade process. Our reader will upgrade the lock on every page that he reads for update and pay for two lock acquisitions just because the application programmer is so pessimistic. And, by the way, this technique works in batch but not online.

A fourth pessimistic technique would be to BIND the application with ISOLATION CS and CURRENTDATA YES. This technique works to protect our reader some — but not all — of the time. Hmmmm. Now there's a scary technique upon which to base the integrity of corporate data: pessimism accompanied by high CPU overhead, concurrency issues, and no dependability. ISOLATION CS with CURRENTDATA YES ensures that our reader will only be allowed to read clean, committed data. Whenever a qualified row is found on a page, an S-page lock will be acquired on the page. The S-locks will not be accumulated; they will be released when the CURSOR moves off the page.

This technique seems much more benign than the others. However, it doesn't work at all for online pseudo-conversational applications. And for batch applications? It depends on the access path that was chosen. If the access path is one WHERE the qualified row is found at FETCH, then the S-lock will be held while the row is returned to the application. If the access path is one WHERE the qualified row is found at OPEN, then the S-lock will be acquired and released at OPEN. It will not be held at FETCH when the row is returned to the application. And since it won't be held at FETCH, it won't be held during the vulnerable duration. One thing we don't need is access-path-dependent data integrity.

One horrid side effect of this technique is that the BIND parameter applies to all read-only SQL, not just the reads that you intend to update. Our reader may actually timeout trying to acquire an S-lock on a page even though his desired row is clean and all he wants to do is read it.

Before we move on to the optimistic locking techniques, I want to point out that none of these pessimistic locking techniques (except for locking everyone out of the data completely) will protect our reader/updater from timeouts. Just because you have an S- or a U-lock on the page while you're in your application deciding to update or not doesn't mean that someone else won't have another S-lock at the same time. So, when you decide to update and request your X-lock, there's absolutely nothing to make that other user with his S-lock move out of the way. And you wait ever so patiently for your X-lock. And timeout.

OPTIMISTIC LOCKING TECHNIQUES

The concept behind optimistic locking assumes that most, if not all of the time, no one out there is interested in your page, in your about-to-be-updated data. It does not assume that there will never be a stranger lurking out there waiting to take advantage of your optimism. It doesn't mean that you're uninterested in the integrity of your data. It doesn't assume you're willing to overlay someone else's update. It just means that you are realistic about the fact that it's highly unlikely that another user will want to update exactly your row on your page at the same time you do. If you're optimistic, there's no need to kick everyone else out of the data. And there's
no need to acquire and accumulate locks on every page whether a row qualifies on that page or not. There's no need to acquire U-locks on every page and then pay for the upgrade to an X-lock (two locks on every page). And there's no need to make rules that apply to all of your read-only SQL whether you intend to update that data or not.

MINIMAL OPTIMISM

The first optimistic locking technique has been employed in DB2 applications since DB2 began. I first saw the technique in an online application. The programmer realized that locks, no matter what kind or how acquired, weren't held across screen displays. While the user was staring at the data on a screen, any other user could be updating that data. After a user changed the data and hit the "OK — do the update" key, a pessimistic programmer would open a CURSOR declared with the FOR UPDATE OF clause, reread the data, and then update the data WHERE CURRENT OF CURSOR. Our optimistic programmer wouldn't pay for the overhead of rereading the data and the overhead of the U-lock followed by the X-lock. Our optimistic programmer would just code the update — but not foolishly so. The UPDATE would contain a substantial WHERE clause to ensure that the data hadn't changed between the initial read and the update

(Listing 1 shows an example).

This rich WHERE clause syntax ensures that our user's data hasn't changed between the time he read the data and then updated the data, all without the overhead of the reread and without the overhead of upgrading a lock. In the second optimistic locking technique, the programmer maintains and checks a counter or an update timestamp in the updating SQL to confirm that the data hasn't changed during the vulnerable duration. In order to use this technique in V8, the table design must include either a counter or a timestamp that's updated by every update statement. Because optimistic locking techniques are so important for performance and
concurrency, tables created under DB2 9 for z/OS contain an automatic update timestamp.

Although these two optimistic techniques were initially used for online applications, they can be used in batch applications in which pessimistic techniques cause too darned much overhead. The combination of using either of these techniques along with binding programs with ISOLATION CS and CURRENTDATA NO ensures that our reader will only be allowed to view clean, committed data, while avoiding locks in all but very rare situations. Reduced CPU overhead and rare contention. Nirvana. With extreme optimism, tempered by "I'm optimistic but I'm not stupid" WHERE clause techniques, the programmer can now avoid almost all read locks.

MORE TO COME

Now that you understand the concept of optimistic locking, whether implemented by a rich WHERE clause or by using the update timestamp or counter technique, we can move on to more complex scenarios. In my next column, I'll discuss three related issues: built-in optimistic locking (part of V7's static scroll cursors), multirow reads followed by set updates WHERE CURRENT OF CURSOR (V8), and the new built-in timestamp (V9).

Bonnie Baker is a consultant and corporate trainer specializing in application performance issues on the DB2 for z/OS platform. An IBM DB2 Gold Consultant, a five-
time winner of the IDUG Best Speaker award, and a member of the IDUG Speakers' Hall of Fame, she is best known for her series of seminars entitled "Things I Wish They'd Told Me 8 Years Ago" and for writing this column. You can reach her through Bonnie Baker Corp. at 1-813-837-3393 or bkbaker@bonniebaker.com.

Listing 1.
A WHERE clause that ensures data hasn't changed between an initial read and an update.
UPDATE tname
SET UPDCOL1 = :HVUPDCOL1,
UPDCOL2 = :HVUPDCOL2
WHERE UPDCOL1 = :ORIGINALVALUECOL1
UPDCOL2 = :ORIGINALVALUECOL2
NO_UPDCOL3 = :ORIGINALVALUECOL3, etc.... listing all columns in the table


Programmers Only: Optimistic
Locking, Part 2
When it comes to DB2 for z/OS locks, a pessimistic approach rarely pays.
By Bonnie Baker

In my last column I explained the concept of optimistic locking in DB2 for z/OS. I explained how optimistic locking techniques can be used in application programs to reduce locking overhead (including potential timeouts) and improve performance. I explained that SQL functions — such as for update of and update where current of
cursor) — and BIND parameters — such as ISOLATION RR/RS, FOR UPDATE OF, or CURRENTDATA(YES) — are very pessimistic and will most likely consume many more DB2 resources than necessary.

You might recall that I told you that optimistic locking techniques have been around since DB2 was a V1R1 baby; however, until now, the techniques have always been enforced by developers using application program logic and special WHERE clause predicates. Finally, I explained that a program that uses optimistic techniques is far less likely to be a victim of data integrity exposures than one that foolishly relies on pessimistic techniques such as CURRENTDATA(YES) and assumes that DB2 is always holding necessary locks.

Now that we understand the optimistic locking concept, whether implemented by a rich WHERE clause that reapplies qualifying predicates or by using the UPDATE TIMESTAMP or update counter technique, we can move on to more complex scenarios. In this column, I'll discuss four related issues: V4's row-level locking, V7's static scroll cursor with its "built-in" optimistic locking, V8's dynamic scroll cursor and row-positioned cursor, and DB2 V9's new data type that folks are calling a "built-in timestamp."

ROW-LEVEL LOCKING

Now why would a discussion about row-level locking be in this particular column? Well, many people who are using pessimistic locking techniques encounter more than their endurable quota of timeouts and deadlocks. To solve the problem, they could try to do less locking by using optimistic locking techniques, or they could blame the problem on page-level locking and switch to row-level locking in an attempt to solve the timeout problems. But by doing so, their pessimism just becomes more granular. Locks are acquired on rows instead of pages. In a worst case scenario, if someone reads six rows FOR UPDATE OF on a single page, that person will acquire six U-locks instead of one. And, as the rows are updated WHERE CURRENT OF CURSOR, that person will make six trips (instead of one) to the lock manager to upgrade the locks from U to X.

Locking problems can often be solved by other less onerous means. Sometimes creating indexes to allow better access paths that touch fewer pages will solve a locking problem. If you filter out the rows you want from the rows you don't want by using a great index with matching and screening predicates, then you won't read as many pages. And if you don't read a page, you won't ask for a lock on that page. Nor will you be told that you can't read it because someone else has an incompatible lock on the page. But you don't necessarily have to create more indexes. Often, switching from pessimistic locking techniques to optimistic locking techniques will solve any locking problems you have.

V7'S STATIC SCROLL CURSOR

There are many ways of protecting data (optimistically, of course) between a read and a subsequent update. One is by declaring the cursor as a static scroll cursor. But not just any static scroll cursor. The cursor must be a SENSITIVE static scroll cursor — sensitive to change by others as well as by our own program. With these cursors, the DB2 developers have given us built-in optimistic locking. At OPEN CURSOR a result set of all the qualified rows is materialized. Remember, we have told DB2 that the cursor is sensitive, with each update or delete to the base table, both by ourselves (DECLARE SENSITIVE) and by others (FETCH SENSITIVE). DB2 will make sure that our result set stays in sync with the real table. In order to stay in sync, each FETCH from the static CURSOR causes a simultaneous read to the real table to see if anyone else has changed or deleted the underlying row. We get the most current COMMIT-ted image of our row
regardless of what's in the result set. If we then look at the data and decide to either UPDATE WHERE CURRENT OF CURSOR or DELETE WHERE CURRENT OF CURSOR, DB2 has to read the base table to make the change. Because the base table has to be read anyway, DB2 can simultaneously and automatically check to see any of the values on the row have changed between the time we fetched our in-sync image and the time we decide to update the row. If the values have changed, then DB2 gracefully lets us know. DB2 is essentially using the rich WHERE clause technique that I mentioned in Part 1 of this article (available online at DB2mag.com). And we don't have to code the WHERE clause ourselves. DB2 is doing it for us. If the row hasn't changed, the update is performed and our change is perpetuated to the result set. If the row has been changed by someone else, the UPDATE isn't successful and a message is returned to the program.

One side benefit of this technique is that for the first time we can now use the UPDATE/DELETE WHERE CURRENT OF CURSOR technique on a cursor that has an ORDER BY clause. Before the advent of static scroll cursors, we couldn't use FOR UPDATE OF and UPDATE WHERE CURRENT OF CURSOR if we had sort syntax (for example, ORDER BY) in our CURSOR. Coding both an ORDER BY clause and a FOR UPDATE OF clause in the CURSOR declaration netted a slap on the coding wrist that this cursor was an "unambiguously read-only cursor."

Well, we still can't use ORDER BY and FOR UPDATE OF in the same cursor declaration, but we can use ORDER BY in the CURSOR declaration and follow the FETCH with an UPDATE WHERE CURRENT OF CURSOR. We can do so without fear — as long as the CURSOR is a SENSITIVE STATIC SCROLL CURSOR with built-in optimistic locking.

V8'S DYNAMIC SCROLL CURSORS, ROW-POSITIONED CURSORS,
AND LOCKING

In V8, we're allowed to DECLARE DYNAMIC SCROLL CURSORs. By definition, these cursors are always reading rows from the base table — never a sortout file, never a result set. If the cursor has an ORDER BY, there must be an index available for DB2 to use in order to avoid the data sort. Otherwise, the BIND will fail. In other words, we know that, sort syntax or not, DB2 will always be reading the base table.

So, with these cursors, even with sort syntax we can UPDATE WHERE CURRENT OF CURSOR. We can't use FOR UPDATE OF if we have an ORDER BY, but we can update anyway. The problem is that, unlike with static scroll cursors, there is no built-in optimistic locking. So, how do we ensure that there's no data integrity exposure? The optimistic locking techniques that we've talked about aren't available.

The problem is exacerbated if we use the new "row-positioned" option that allows us to FETCH more than one row, let's say 100 rows, with one connect to DB2. If we then UPDATE WHERE CURRENT OF CURSOR, 100 rows will be updated and we won't be able to check 100 timestamps. Nor will we have the ability to apply 100 rich WHERE clause comparisons.

I've come up with some approaches that work, but none that I really like. First, remember that we know we're accessing the base table; this means that BINDing with
CURRENTDATA(YES) will cause DB2 to hold locks on the row or rows between the FETCH and the UPDATE WHERE CURRENT OF CURSOR.

What I especially don't like about this approach is that CURRENTDATA is a BIND parameter and applies to all the read-only SQL in the program, not just the CURSOR in question. To make it apply to just the CURSOR in question, we'd have to isolate the cursor in its own program. And besides, CURRENTDATA(YES) was in the list of pessimistic techniques I mentioned in the last column.

A second, SQL-specific technique is to use the WITH clause on our cursor declaration and use WITH RS for our isolation. WITH RS will cause DB2 to acquire an S-lock on each page that has a qualified row on it and accumulate those locks (very important for our row-positioned cursor) until the locks are upgraded to X-locks by the UPDATE WHERE CURRENT OF CURSOR. At COMMIT all the X-locks and any outstanding S-locks will be released. This approach is also a pessimistic technique that causes upgrade overhead (see Part 1), but at least it's SQL specific. And because of that I like it better than CURRENTDATA(YES). If anyone has a better, more optimistic technique to handle data integrity exposures from concurrent updaters, please share the technique with me so that I can share it with others.
V9'S BUILT-IN TIMESTAMP

In Part 1, we discussed adding an update timestamp column to our table so that we could check it for change each time a row was updated. However, the burden of
maintaining the timestamp fell to the programmer. If someone slipped into SPUFI and updated the row, the timestamp might not get changed. The rules may not be obeyed. In V9, we have new SQL syntax for an automatically updated timestamp. You can now create/alter tables and include a ROW CHANGE TIMESTAMP. The name of the column can be anything you like (MY_UPD_TIMESTAMP) but the definition of the column includes new parameters: GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP.

Now the program code can use the optimistic UPDATE TIMESTAMP technique (see Part 1) without worrying that other applications (such as SPUFI or QMF) might not be obeying the rules.

STICK WITH IT, OPTIMISTICALLY

If I could make one thing stick in every programmer's brain, I would say that figuring out when a lock is held and when one isn't, when there is data integrity exposure and when there isn't, is a complex, confusing, and painful process. Using a single approach whenever possible has many advantages. Whenever that single technique is unusable, choose the most optimistic of the available options.

Bonnie Baker is a consultant and corporate trainer specializing in applications performance issues on the DB2 for z/OS platform. She is an IBM DB2 Gold Consultant, a five-time winner of the IDUG Best Speaker award, and a member of the IDUG Speakers' Hall of Fame. She is best known for her series of seminars entitled "Things I Wish They'd Told Me 8 Years Ago" and writing the "Programmers Only" column. She can be reached through Bonnie Baker Corporation at 1-813-837-3393 or bkbaker@bonniebaker.com.

IDUG User View: Locking Up DB2 Performance
A new locking feature in DB2 9 for z/OS improves the performance outlook.
By David Beulke

Supporting multiple systems and dealing with application developers and managers who often don't have a clue makes the DBA's job a challenge. Fortunately, DB2 9 for z/OS offers a new optimistic locking feature that can improve system performance-and perhaps the DBA's (and application developer's) mood.

Database locking is a necessary overhead and a core component of all DBMSs. Locking maintains integrity by preventing multiple transactions from changing the same data at the same time. But taking and maintaining database locks can be expensive, especially for complex systems, applications, or transactions.
Optimistic locking now uses new features defined within DB2 tables to reduce deadlocks and overall locking overhead, improving system and application performance. (Read Programmers Only for more on optimistic locking.)

To use the new feature for optimistic locking, you need to define a new ROW CHANGE TIMESTAMP column in a DB2 table with new parameters (GENERATED ALWAYS, FOR EACH ROW ON UPDATE, AS ROW CHANGE TIMESTAMP) as follows:

CREATE TABLE BEULKE.PRODUCT_TBL (
PROD_NBR INTEGER NOT NULL,
PROD_INVENTORY INTEGER NOT NULL,
PROD_LAST_UPD NOT NULL
GENERATED ALWAYS
FOR EACH ROW ON UPDATE
AS ROW CHANGE
TIMESTAMP);

These parameters tell DB2 to always populate and pay special attention to thetimestamp and table. The last update timestamp has been embedded in some

applications for years; now IBM has endorsed and improved on this technique.

These new features enable DB2 to retrieve rows from a specific time period and understand when they were last modified. DB2 not only notes the row timestamp
information but also the record ID (RID) and change token information. Noting the row attributes allows applications and users to query the database via timestamp to get a specific row or group of rows based on WHERE timestamp clause criteria.

The new column feature reduces locking overhead by allowing the majority of applications to be rebound and reduces locking profiles from Repeatable Read (RR),
Read Stability (RS), or Cursor Stability (CS) to Uncommitted Read (UR). Uncommitted Read avoids database locks; the application can maintain database transaction integrity by using the new timestamp column within the application UPDATE SQL statements. The new timestamp column provides both the timestamp and the record ID (RID) of the row that DB2 can use to verify that no other application has changed the data in question.

Another DB2 9 SQL phrase, SKIP LOCKED DATA, also helps avoid locks by not retrieving or affecting data rows with incompatible locks. You can use the phrase within SELECT, UPDATE, and DELETE SQL statements to avoid deadlocks.

Use both the isolation level UR and the SKIP LOCKED DATA phrase cautiously. Although the techniques can dramatically reduce locking and improve performance, they require that you thoroughly know your applications. Research each application in detail before using this performance boost, and read the DB2 manuals for full details. Because these techniques can significantly reduce deadlocks and locking overhead, especially in a data sharing environment, they're worth the research and implementation time.

These techniques and other performance topics are covered at International DB2 Users Group conferences around the world (www.idug.org).
David Beulke [davebeulke@cs.com], a past president of IDUG, is a DB2 consultant,
author, and lecturer who specializes in database performance, data warehouses, and
Internet applications.

New Start

一年了。

前几天有个朋友说看你的blog觉得你日子过的蛮happy的。苦笑。

心情好的时候才写blog，心情不好郁闷了确是很不习惯上来晒的。

anyway,重新做人。

希望这里还可以是朋友们交流DB2 UDB的一块自留地，谢谢。

我又回来了。

new H1b filing rule out

Wish good luck this year!

http://www.mitbbs.com/ym_article/lianglaw/31080710.हत्म्ल
(梁勇律师事务所，lianglaw.com专稿)移民局刚刚公布了有关H-1B Cap 申请相关规定
及Q&A，相关规定的内容包括以下几点：

1。如果第一天H-1B 申请就额满的话，原本只是将隔天送件的申请件一起并入“抽签”
的行列，现在移民局改为5个工作天内送达的申请通通并入一起可加入“抽签”的申请
案。(这样竞争就更激烈了，不论是在申请后5个工作天内的那一天额满，都是一并加入
抽签的行列。)

2。禁止同一个雇主为同一个员工提出多个申请，即使是工作内容不相同也不行。唯一
可以例外的是如果是“关系企业”(像是母子公司) 的话，是可以各自为同一个员工申
请一个H-1B 的申请。

3。如果被移民局发现出现同一个雇主为同一个员工提出多个申请的话，将会拒绝或撤
销H-1B的申请，所付出的申请费也不会退回。(这家公司为这个员工所申请的所有H-1B
都会被拒绝或撤销，但是为其他员工的申请如果没有违返规定则不影响。)

4。移民局将变更抽签的顺序，若是20,000个美国硕士以上名额的申请在开放后5天内额
满的话，移民局会将20,000个美国硕士以上名额的申请人优先抽签。若是这些拥有美国
硕士以上学位者没有被抽中的话，会将再放入65,000个名额一起抽签，等于美国硕士以
上学位申请人在5天内送件者有两次抽签的机会。

5。移民局同时也表示，他们会继续接受学校发出证明申请人完成所有课程、论文及答
辩，只差领取毕业证书的证明信。但是如果你并没有符合完成其学位的证明却声称已经
取得学位的话，是不会退会申请费的。

6。目前移民局将继续接受H-1B快速审理的申请，$1000 快速审理的开始计算时间是以
抽签决定后开始计算。

7。由于移民局会将收到的所有H-1B Cap 案件送交给其他移民处理中心做电脑输入的动
作，因此，申请人在收到收据时可能与寄件的地址不符，这一点请申请人不要担心。

所有要求以移民局原件为主，移民局原文可在本网 http://www.lianglaw.com/H1.htm
取得，相关消息包括：
Full Text Advance Copy of the H-1B Cap Filing Rule(03/19/2008)
USCIS FAQs: Interim Rule on H-1B Visas(03/19/2008)
USCIS Fact Sheet: Changes to the FY2009 H-1B Program(03/19/2008)
USCIS Announces Interim Rule on H-1B Visas(03/19/2008)

***谢谢您阅读本文，如需转载，请注明出处，其他相关新闻请查看本所网址:http://www.lianglaw.com

转 心不在焉时干的最牛事

发信人: 恶少 (觉醒), 信区: Joke
标 题: 转 心不在焉时干的最牛事
发信站: 两全其美网 (Tue Feb 5 21:59:49 2008), 本站(lqqm.net)

1、昨天游完泳，直接把后备箱打开，钥匙丢进去，然后关上后备箱……　　穿着三点式在野外等了一个半小时。

　　2、有一次煮饭,淘完米直接把米倒进没放内锅的电饭煲中...后来拿吹来吹啊吹....

　　3、就发生在中午，丢人啊~　中午打算叫楼下面馆送碗刀削面来吃吃~ 脑袋也不知道想什么~ 电话通后，我直接说：“您好~麻烦送一碗刀削面”，后面就听到我妈妈的声音出现：“女儿！你中午想吃刀削面啊！”　我妈刚开始还觉得有点莫名其妙，回过神 来就大笑~~ 我当时也愣了下~ 脸都红了，尴尬啊~~

　　4、第一天上班 有人电话找经理(女的) 把电话给经理顺便说了一声 妈
有人找你接电话

　　5、戴着眼镜（框式的）洗脸。镜片上一片迷茫………………

　　6、盘算着给老妈打电话,　领导突然进来,于是对他说:妈,材料找到了，给你!!!!!!!!

　　7、把钱捏在手里 ,然后揉成一团,抓在手里,觉得很不舒服 ,扔了

　　8、去好朋友家，聊天中，她爸回来，张嘴就叫“阿姨”，尴尬中，她妈又出现，张嘴又叫“叔叔”……然后无限怀疑自己的智商

　　9、我有两个：一次好朋友结婚，头天去她家时她给我拍了张照片，我当时没看她相机里的照片，回头就忘记这回事；

第二天喝喜酒的时候她拿出相机，我说看看你都拍了些什么照片，翻着照片我就发现有张照片里的人特别象我，脑子里就没反应过来，还傻呼呼的喊人家看有个女孩子张得很象我，等反应过来，觉得自己特傻，怎么会不认得自己的照片；

第二个比较惨，骑车快速经过一辆面包车，车门刚好打开～～我结实的撞到车门上，惨～

　　10、最丢脸的一次,洗脚的时候也不知道在想啥,本来要脱袜子的,差点把裤子脱下.....

　　11、从讲台往座位走，一同学的脚伸到过道上，本来想说“请让下”，结果脱口而出“谢谢” 　

　　12、有次上photoshop课，我一边给男朋友发短信一边很勇敢的大声对老师喊道:"老公!我的电脑没连上!"　闹怏怏的教室瞬间安静了　5秒后全体暴笑　老师是个50多岁的小老头　推着眼镜盯盯瞅我　这个庐山瀑布汗呀

　　13、给女友家打电话，她爸爸接的，说：“喂？” 我硬是顶着她爸的声音回答说：“阿姨好，请问***在吗？”　她爸能同意我们在一起真是奇迹！

　　14、早上扔垃圾,,拿着挺顺手,一路上了公车,活活开了一小时,到了公司,,下车才发现垃圾袋还在手上,我带着绕了大半个城市,结果扔到写字楼垃圾箱.

　　15、某日深夜狂欢结束后回家
一路上不知道在想什么进了电梯以后就等啊等啊 等好久也没到我家那层楼 心里开始狂汗 难道是电梯出问题了? 这会也没人在啊喊救命都没人甩我 同时 鬼电影里面的画面就一张一张的闪过 顿时觉得浑身寒毛竖立　正要打电话给BF ,叫他来救我突然发现自己没按楼层电梯还一直在一楼没动.....

　　16、拿学校饭卡给工行的工作人员取款,别人看了一眼,利索的丢了出来,我又塞回去大大声的说我取钱啊,他有利索的丢出来懒散的说卡错了,我讪讪的取回来，又从钱包拿了一张建行的卡递给他……

　　17、很小的时候，家里要烧煤的，妈妈煮好的米饭放在厨房，我拿个小铲子弄了一铲子的煤，将盛着米饭的锅盖打开，将煤一下子都倒了进去。。。

　　18、上大学时和一群朋友一起吃饭，想着下午的考试，心不在焉，吃完了照例从包里拿纸巾出来擦嘴，是无意识的擦了好久，突然发现朋友们都不说 话了，看着我，这才发现自己拿着擦嘴的是一个卫生巾！朋友们可是有男有女啊！我当时真不想活了！是护舒宝的丝薄日用！不可理解的是，我还把外面粉色的包装 拆了！

　　19、我有一次早晨起吃早点（饼和稀饭），边看新闻边吃。当时正好播的是我们那边的一场事故之类的。我看得特别认真，顺手就把遥控器拿起来啃，还把遥控器套子啃下来一块，狂嚼了半天，吐出来一看差点没郁闷死。我一直想不明白我是怎么把它啃下来的


　　20、还有一次是旅游的时候，和女朋友一起去的。当时景区人特多。我顺手就把女友的手拉起来说；“老婆，拉紧我的。”然后，就感觉女友的手直 往下松，我以为她不好意思，便往紧拽。后来她不走了，我回过头一看。才发现是一个男的。然后旁边还有一个女的很怪异得看着我。我吓了一身的汗，干笑了几 声，红着脸就溜了，郁闷死了。`````

　　21、跑完步气喘吁吁,边喝水边准备离开,结果没按好结束键跑步机停不下来,我整个人就势滑了出去,杯子里的水也洒了一地被教练当作反面典型对旁边的人说,千万不要像她一样没停机就下来.好丢脸啊


　　22、还有一次在三楼进了电梯，然后一直按3键，还奇怪为什么按不亮。　另外一次是一个同事的。那天同事一边用遥控器开空调，一边让我帮她倒杯水，结合起　来使我看到的场景非常诡异：只见她拿遥控器对着我一按，嘴里说：请你帮我倒杯水！
　我发誓绝不是角度误差，空调在相反的方向。

　　23、去买衣服，到试衣间试衣服，一进去就脱了上衣，脱了bra，然后穿衣服，穿上以后觉得怪怪的，看到旁边的bra，才反映过来～～汗～

　　24、一次去买热干面,前面有一对情侣正在买,老板问他们要不要放香菜,男的说不要，女的说怎么不要。我就在旁边想"香菜,为什么男的要香 菜,女的不要香菜……"　想的正出神呢，老板问我，吃什么？　我毫不犹豫的大声答到：“香菜！！！”　老板＋旁边的那对情侣不解的看着我！

　　25、家里新买的微波炉,很兴奋地用它来做鱼.弄好时间,调好火侯,十五分钟后激动地打开微波炉,晕,什么都没有.鱼还在桌上.郁闷地再次操作,时间到,没等打开微波炉就发现鱼仍然在桌上.于是,决定一个星期都不再吃鱼.

　　26、有一次，去买水果刀，拿着刀看了又看，然后叫那个买刀的找个东西让我试一下，刀快不快，结果俺特短路的用刀割自己的大指头，血喷呀 ``````````````我还高兴的说“嗯，快”惊得那个买刀的怎么都不收钱，非要送我此刀``````　一转身，那个痛呀``````钻心

　　27、小学几年级忘了，有次上自习不认真，就拿剪刀把圆珠笔芯最前面的头给剪了，把笔芯里面的油吹出来玩，然后吹着吹着就把油给吸嘴里去了

Evernote 2.2

Ordered the license for Evernote 2।2 at a price of 19.99$ with 3$ 3 years download warranty. It's the first software I bought ever, except the Winxp coming with laptops and some versions of Linux.

Evernote is a great product. Like Microsoft Onenote but much cheaper(I notice that from lenovo website you can buy a copy of Onenote at 20$ if you buy a tablet, wow, that's great! But my x60 tablet is coming from Lenovo outlet store and I just cannot customize that. What a pity!). Acutually its free edition is powerful enough for normal laptop users. But you'll feel the strong temptation when you're using a Tablet. Handwriting is very important feature. Say, I ever considered that I can handwrite with sticknote and use some snipping tools to copy the handwriting to notes, but it's too fussy. Then, what could you do when you want to make some change to the handwritings? There're some other advanced features like handwriting recoganization is very useful -- but not the decided point.

Richard Hammond presents Bloody Omaha

http://www.youtube.com/watch?v=WRS9cpOMYv0

bloody work done!

文革与希特勒的种族屠杀之胡思乱想

最近看《金婚》，有关于文革的一些镜头。lp说她爸妈那时候觉得就应该那样的，觉得那样就对。而我好像接触到的人对那段历史多是大摇其头的。也许是，这就是只有深受其害才能知其利害对错，而很多根正苗红的无产阶级们是不是只是play而已。反正痛的不是自己。人性中卑劣的一方面被名正言顺的发扬光大了。

联想到希特勒的种族屠杀。犹太人似乎是一个一直受迫害的民族，嗯，似乎偶是一直这样受教育的。近代尤以希特勒为甚。当年学习修正版历史的时候被教育说因为犹太人如何富裕如何精明商业而与普通民众有间隙，民众被挑拨对犹太人的仇恨，所以如何又如何的。这个说法不太经得起推敲吧，总感觉到这后面有太多的背景故事是我们不熟悉的，不然，以犹太人的素质不应该受到千年的迫害而是应该得到充分的敬重吧。

今天看到这样一个帖子，应该是交代了一些真实的背景，贴到这里给自己当个索引，以后想起来可以参考：）

（那个文章正文贴到回复中了...）

Dialogue Concerning the Two Chief World Systems

LINK

Today Galileo is a famous and romantic name। We have all been taught the story of his heroic fight in the name of science against the intractable ignorance of the tyrannical Catholic church. The reality is not so starkly drawn, but no less interesting for that; Galileo's own arrogance created many enemies, and Rome's anxiety over its authority in the schismatic era of the Protestant reformation made their collision inevitable.

......

网友爆内部消息：08年春晚赵本山小品《卖股》

http://www.mitbbs.com/news_wenzhang/Headline/30259744.हत्म्ल

赵本山： 现如今，执照越来越难考了，关系越来越难搞了,媳妇越来越难找了，股票越来越难炒了。这不，刚48块买的股票就被套牢了，这心急火燎的，今天我去证券市场看能否把这只股票高价位卖出去。哎呀，到了。 Mitbbs.com

范　伟： 哎呀，这不是大忽悠吗？ Mitbbs.com

赵本山： 荣幸之至。哎呀 ，小样儿，身上穿着名牌西服，手里提着笔记本电脑。怎么地，抢银行发财了？ Mitbbs.com

范　伟： 怎么能这么说话呢？我是跟着人家炒股炒发的，是股票这位天使娘娘改变了我苍白无力的命运。你这是上这儿卖拐还是卖车来了？ Mitbbs.com
jiaoyou8.com

赵本山： 改行了，现在的好心人赚不了钱，我也炒股呢。 Mitbbs.com

范　伟： 看你一脸愁容，赔钱了吧？你是散户吧？ Mitbbs.com

赵本山： 啊？ Mitbbs.com

范 伟： 涨了笑赔了哭，不是庄家是散户。 Mitbbs.com

赵本山： 你啥眼神，没看出我的真实身份吗？ Mitbbs.com

范　伟： 什么身份？ Mitbbs.com

赵本山： 不瞒你说，我现在是忽悠集团的董事长，我公司的股票“中国忽悠”准备进行网下申购，我特地亲自到一线市场考察考察。 Mitbbs.com

范　伟： 忽悠，接着忽悠。 Mitbbs.com

赵本山： 信不信由你。听说过平民股神赵百万没有？ Mitbbs.com

范　伟： 那当然了，怎么? Mitbbs.com

赵本山： 鄙人。 Mitbbs.com

范　伟： 啥？你？！ Mitbbs.com

赵本山： 对头。你不信？那好，你今天想买哪只股票？我能知道这只股票是涨是跌？你信不？ Mitbbs.com

范　伟： 我不信。我今天买中石油，肯定赔不了。 Mitbbs.com

赵本山： 我的妈呀，完了，你指定有病。 Mitbbs.com

范　伟： 我没病啊。你看我腿也好了，脑袋也小了，末梢神经也正常了，聪明的智商也占领了高地了。 Mitbbs.com

赵本山： 没病你买两股，没病买两股。 Mitbbs.com

范　伟： 买就买。我今天就买1000股中石油给你瞧瞧。 Mitbbs.com

赵本山： 看，病得不轻啊。瞧，瞧，中石油跌了吧？ Mitbbs.com

范　伟： 哎呀，大哥，它怎么说跌就跌了呢？ Mitbbs.com

赵本山： 你信我了吗？ Mitbbs.com

范　伟： 我我我~~~我信，大哥，你说我该怎么办呢？ Mitbbs.com

赵本山： 别急，这么着，我先给你来个小学算术题，检查一下你的智力有问题没？ Mitbbs.com

范　伟： 那大哥你说。 Mitbbs.com

赵本山： 请听题，说你用1块买了100股中国忽悠，那么需要多少钱？ Mitbbs.com

范　伟： 这也太简单了。100元，对不对？ Mitbbs.com

赵本山：别着急，我先向你介绍一下中国忽悠这只股票，我公司总资产万亿，属于大盘蓝筹股，具有超强的成长性，垄断资源明显，年利润增长率预计为1000>以上，公司旗下有无数 个分公司，分公司里有无数成员，每天作案无数次，业绩那真是相当可观，是亚洲最赚钱的企业…… Mitbbs.com

范　伟： 大哥你别说了，赶紧提问题吧。 Mitbbs.com

赵本山： 好的，假如你用1元申购成功1000股，上市合理价位是25元，你算算你的资金变成多少了？ Mitbbs.com

范　伟： 250啊？ Mitbbs.com

赵本山： 看看，默认了吧。那是2500元。连这么简单的题都算错了，250还炒股呢？这样下去，你肯定得赔，晚年就是穷光蛋。 Mitbbs.com

范　伟： 哎呀，大哥，那怎么办呢？ Mitbbs.com

赵本山： 别着急，我自有办法。你说你放着好股不炒，偏要买那破石油呢？ Mitbbs.com

范　伟： 大哥，我糊涂啊。那你能帮我解套吗？ Mitbbs.com

赵本山： 没关系，前几年给你卖拐卖车，把你整残疾了，是我对不住你，现在我帮你是应该的。 Mitbbs.com

范　伟： 大哥，那我就买10000股中国忽悠，你看行不？ Mitbbs.com

赵本山： 那可不行，中国忽悠还有几个月才能申购，这么地，我先把我手头的股票给你分一部分，就算是哥对你的补偿。 Mitbbs.com

范 伟：行吗？Mitbbs.com

赵本山：绝对的黑马，刚刚的。我认识庄家，明天准备拉升。保赚。每股50元，买不买？ Mitbbs.com

范　伟： 我买，我买。 Mitbbs.com

（开始网上交易） Mitbbs.com

范　伟： 大哥，你看我的资金不多了，买不了你的股票，哎呀，我的手气不好。 Mitbbs.com

赵本山： 什么手提电脑？啥手提电脑？大兄弟，你要给我我跟你急昂…… Mitbbs.com

范　伟： 对对对，大哥你说得太对了，你把电脑拿去，像我这样的炒股水平，以后也就用不着电脑了。 Mitbbs.com

赵本山： 那我就把它收下了，不过哥不缺这玩意儿，哥打算把它捐给贫困地区。听哥的，完了把中石油卖了， 准备申购我的新股，明白不? Mitbbs.com

范　伟： 明白，明白。 Mitbbs.com

赵本山： 我就喜欢明白人。从今往后好好跟哥学啊，你看哥一开始什么也没有，现在有钱了，哥是股神，你怕啥呢？Mitbbs.com

范 伟： （激动地）大哥，啥也不说了，还是那句话，缘分呢！Mitbbs.com

赵本山： 没关系，中国忽悠上市的时候，我会及时通知你的。后会有期。Mitbbs.com

范 伟： 谢谢啊！Mitbbs.com

madison travel

It will my 3rd time there. Everytime with very different mode.

Life is hard and I must fight a way.

尽力而为，但求问心无愧。

string searching algorithm

Now busy rebuilding C/C++ and algorithm skills। Three more years from this filed, so, in several weeks, just wish to recover 60+% level of what I feel on 2003.

Just now, met a string search, say, "The problem is to search for a pattern string, pat[1॥m], in a text string txt[1..n]। " In university textbooks, it was described as a Boyer-Moore algorithm, which may be the best method. basically, it has two ideas.

The first one, also the key one, is if the mth character is not the end character of our searching pattern string, then the 1 to m characters could just be omitted। then we check next m characters।

The second idea is a supplemental, depends on which the last character is, shift specilized positions*, then check again as idea 1, if not move m positions, if yes, check if a matched pattern found। There is a need for a logic to calculate the shift table.

I believe it is the best idea। though even from the time I learned it, I hate to count the characters one by one। I prefer some direct, maybe "rude" ones. I'm a lazy boy;)

One of this kind of algorithm is Rabin's. Very simple, for the pattern string, C1C2...Cm, I caculate their weighted sum, Sm=C1+C2*3+C3*3**2+...+Cm*3**(m-1). and then... you know that?:)
We're writing C/C++ code and we would always need to make some decisions for the algorithm choice। For this kind of problem, they are aleady in the library. but if we meet with a new type question?

I prefer to the simple one। If no special performance demands, I would always choose a algorithm like Rabin's. My excuse:

1। Easy to implement।
2।Easy to understand and maintain। Our code will be maintained by somebody else, too complex and too gorgeous solution will bring big trouble to the tester and programmer who has to review your code.

回归

anyway，要回去了。

借用朋友的帐号查了点东西，看到久违的w3觉得好亲切。虽然一如既往的缺乏营养：）希望能有机会回去做一些项目。四处跑跑，consulting的生活虽然很适应，也比较舒服了，但还是需要能够补偿一下缺少完整项目的遗憾。从学校毕业就一直做service，经历过n多项目，拼起来大概也足够一个完整了，不过越这样就越觉得一个完整参与的必要。呵呵，希望运气够好哦。祝福一下自己。祈祷一下。Eternal father in heaven, pls bless your terrestrial son and he will do as his best. You'll feel pround of him. In the name of Jesus Christ, amen!

阚凯力称五至十年内打电话将免费

http://mitbbs.com/news_wenzhang/ScitechNews/27641722.हत्म्ल

批示：严重同意。

------------

主持人：是这样，我们最近看到您一个很知名的观点，“阚凯力预言五年内语音通话将免费，运营商将全部死掉”。不知道这个结论是怎么得出来的。Mitbbs.कॉम

阚凯力：五年可能报道得不太确实，应该说五年到十年吧。我觉得是这样，关键是电信技术革命的结果，比如我们今天讲，我们要做生意，要做空气的买卖，大家一定都会认为这人是个疯子、神经病，为什么？因为空气确实每个人都离不了，但另一方面，在地球上至少到今天为止还取之不尽、用之不竭。所以在这种情况下，没有什么空气生意好做。Mitbbs.कॉम

电信行业在二十世纪后期实际上就经历了这样一场技术革命，从网络容量的严重不足，现在变成了严重过剩，尤其是光通信的普及。光通信，比如一根光芯上可以传递的信息速率是多少，按我们学校的有些通信专家来讲，理论极限是40个T，现在的技术已经做到了30个T，一个T就是1000G，一个G是1000兆，它技术上可以做到30个T，但我们现在实际使用中的光芯传递的速率是多少？能用到几十个G已经算谢天谢地了，实际上绝大部分的光芯都不到G，而绝大部分的光芯也就是几百兆，所以说，和我们技术的能力相差至少三四个数量级。Mitbbs.com
光说一根光芯、一根光缆，几十根光芯，咱们国家是平行光缆，几大运营商，再加上广电什么的，至少五六根，七八根，在这种情况下，电信网络的容量就已经像空气一样了，像空气了你还做什么生意呀？这就叫做技术进步必然会使原来靠这种技术的稀缺性生存赚钱的企业走向消亡。Mitbbs.कॉम

我们知道话音是典型的窄带信号，不压缩的低于40K，但手机上一般压缩的也就十几K，我们说在能有几十个T传输能力的光芯上，那这个技术不是微乎其微吗？所以现在的问题是如何去解放电信技术，尤其是光通信所带来的蕴藏了极大的生产力。而不是去保护在原有条件下由于网络容量短缺而应运而生的、已经有一百多年历史的ATNT的老的电信运营商模式，他们已经完成了历史使命，该被淘汰了。Mitbbs.कॉम

但是，运营商总要维持它自己的生存，所以就像刚才比喻的空气一样，明明地球上有大量的空气，所有的人类加上动物都取之不尽，用之不竭，结果它一定要把全世界所有的空气都霸占起来，甚至把它毒化，让你吸不了，然后它好卖空气。Mitbbs.com
所以才有今天话费这么高、上网费这么高还速度太慢。我记得半年前信产部有个科技司长讲，现在的宽带不宽，我上网才几十K的速度。为什么？就是因为运营商把“空气”都霸占住了，不让你吸这个空气。他就会说，看，为什么他要卖啊？因为他要升级，拨号的不行了，需要宽带，宽带512兆的不行了，需要1兆的，然后再升成2兆。实际上绝大部分，99.9999%光缆容量都空闲在那里，还不说有多少光芯根本就黑在下面。Mitbbs.कॉम

主持人：互联网就要取代，或者互联网会融合通信网吗？Mitbbs.com
阚凯力：是，互联网IP是整个通信业未来的发展方向，它最大的效用就是剥夺了运营商对于网络的控制权，所以今天运营商保护的就是网络控制权。什么3G也好，固网当然更是了，都是要保护运营商的控制权，它好把空气都夺走，让我们大家都吸不了空气，去向他买。而另一方面，以IP技术为代表的这一方，就是要剥夺它对网络的控制权，要把全地球的空气都解放出来，这样我们大家就可以免费了。本质的问题就是这么一个问题。Mitbbs.कॉम

主持人：从商业规则来说，这种模式好象更合理一些？Mitbbs.कॉम
阚凯力：商业规则，就像空气一样，空气就没有商业了，更无从谈起商业规则了。比如现在全世界都在迅速发展的一个叫做“无线城市”的概念，因为无线宽带已经便宜到这种地步，刚才我跟别的朋友一块儿算了个帐，全北京市的无线宽带覆盖，六环以内一千平方公里，一共也就才需要几千万人民币，就搞定了，现在的技术使成本降到这么低，为什么不把它解放出来呢？北京是一个立交桥都上亿，一公里地铁就好几个亿，几千万的投资对于北京市政府来讲还算什么呀？微乎其微嘛。所以现在全世界普遍都是由地方政府来提供无线宽带服务，这叫做无线城市，被称为“第五公共事业”。如果所有的市民都通过这个第五公共事业，通过无线城市免费上网了，上面都是网络电话，都免费了，运营商生存何在？自然就消亡了嘛。Mitbbs.कॉम

主持人：这个话题挺有意思的，上周时国际电联也确定了WIMAX成为3G的国际标准，中国也有自己的TD标准，现在还有另外两个其他的国际标准，您怎么看待WIMAX这个标准？到底是怎么样的？Mitbbs.com
阚凯力：WIMAX应该说它和WIFI一样，就是一个互联网的无线延伸，但是它的覆盖半径更大一些，如此而已，所以它本质上也是一个全IP的接入技术，应该说和WIFI一样，都是把整个网络改造为以IP为基础的一个有效的手段。Mitbbs.कॉम

阚凯力：刚才你提到国际电联的表决问题，应该说非常不幸地，我们中国代表团这次与全世界极其个别的利益集团站在一起，站在了全世界绝大多数国家的对立面，反对WIMAX成为3G标准之一。实际上就是说，不同意分配给WIMAX一个频率，企图阻挠WIMAX正常的发展。Mitbbs.com
主持人：我个人理解，中国相关部门会不会认为TD就代表中国的利益呢？从国家利益的角度来想的话。Mitbbs.com
阚凯力：TD不代表中国的利益。Mitbbs.com
主持人：为什么这么说？Mitbbs.com
阚凯力：TD代表的是某些个别的利益集团的利益，不是国家利益。TD虽然在某些技术特性上比其他的两种标准有一些优势，唯一的也就是因为它是同频双功，上下是同一个频率，所以频谱的利用率高一点，但与其他两种没有本质的区别，尤其刚才和我们讲的全IP网络的发展方向是没有区别的。如果在二十年前，甚至十年前，九十年代初我们国家推TD，那应该说是没有问题的，甚至是正确的，但是时至今日，已经有了更先进的技术，能够使通信行业更好地为广大人民群众生活提高来服务，为国民经济的发展来服务，在这种情况下，反对WIMAX而要搞TD，说得最多最多，也就是保护个别设备制造商的利益，而这里面还只是短期的、暂时的（利益）。这实际上是以我们全国人民的利益为代价，是以我们国家的综合国力，以及我们国家通信产业持续、长期、健康发展为代价，来为个别的利益集团去说话。这种做法是完全错误的！Mitbbs.com
主持人：假如中国不推出自己国家的3G标准，可能国际上会继续让中国使用2G，技术并没有向前发展。Mitbbs.com
阚凯力：不对，首先中国的2G网络在全世界不但是规模最大，而且也是质量最好的网络，北美、西欧的网络质量根本就没有办法和我们中国的网络质量相比，尤其是中国移动的GSM网络，那么就有一个问题，我们3G网络推出来关键到底给谁用，做什么用？这个问题我想我都不要多说了，上个星期信产部的一个副部长叫娄勤俭已经说了这个问题了，就是靠什么盈利，市场需求在哪里？盈利模式在哪里？现在不清楚，所以信产部最近再一次重申，我们的3G牌照，包括TD牌照的发放没有时间表，与奥运会的举办没有必然的联系。那么我们就要问了，既然这些东西都不清楚，你为什么还要推它呢？就像高通这样，WIMAX，这次国际电联是讨论全球的应用，明明WIMAX比3G的技术性能至少高一两个数量级，而它的成本也至少要低一两个数量级，那么难道我们中国的表决就要阻止非洲、拉丁美洲、亚洲的贫穷国家以及中国西部地区，要让他们用不到更物美价廉的技术吗？我们不是把我们中国的利益和全世界人民的利益摆在对立面了吗！Mitbbs.com
主持人：下面我们讨论关于商业模式的问题，因为刚才您提到WIMAX的商业模式和现在的互联网是非常相似的，但有一个问题是，如果现在运营商依然走传统的有中心的发展方向的话，WIMAX的商业模式必然会跟现在的运营商做的商业模式完全不一样，您觉得，如果有一个机构或者企业来运营WIMAX的网络，它应该怎样做这个运营呢？Mitbbs.com
阚凯力：现在无线城市，在全世界也好，在中国的六个试点城市也好，已经非常明确了，不是以运营商为主的，而是以地方，市政府为主的。地方市政府关心的是什么呢？信息惠民，怎么对老百姓有好处；信息强政，怎么通过信息化来提高政府效率；还有一个叫做信息兴业，怎么通过信息化来推动整个国民经济的发展。那么，有商业模式没有商业模式，要叫我说，没有商业模式比有商业模式好。Mitbbs.com
主持人：它是作为一个公益事业来提供。Mitbbs.com
主持人：我这里有一个想法，比如现在有一个交通干道，大家因为有交通需求，车走过去要收取过路费，WIMAX不可能完全只有投入没有产出吧？Mitbbs.com
阚凯力：如果作为政府的第五公共事业的话，咱不说WIMAX，说WIFI好了，WIMAX在目前阶段来讲，尤其是固定版本的，因为手持终端还不够普及，至少芯片还不成熟，所以它现在主要作为一个无线终极手段，不是直接作为终端的。所以我们说 WIFI好了，全北京市只要几千万的投资，那么政府还需要有收入吗？比如政府修一个立交桥，那就是几个亿，从立交桥上政府有什么收入呢？没有收入，它通过交通便捷提高了城市的公共基础设施，这个服务水平本身既方便了人民生活，又促进了各行各业的发展，政府如果财政上有收入，各行各业一发展了的话，还可以多收点税嘛，这样自然就回来了，何况无线城市所需要的投入如此之小呢？这完全可以用其他的方式来收回。Mitbbs.com
主持人：我大概明白了阚教授您的观点，WIMAX这个东西因为是一个无中心的，人人平等的网络，它更多是在于对公共事业上的贡献，而不是应该作为改变今天运营商强势垄断地位的工具？Mitbbs.com
阚凯力：对。Mitbbs.com

还原《走向共和》结尾被删掉的孙中山演讲词

link

“我知道诸位议员急什么。张勋复辟了，国会又开不成了。可我急的不是这个。我这些日子想的是，咱们本来是共和国啊，可怎么一次又一次地出现封建主义、专制主义的东西？这个问题不解决，复辟就是必然的，共和国就永远是一个泡影！” “共和的观念是平等、自由、博爱——“共和国是平等之国，人们在法律面前一律平等。可民国六年来我们看到的是什么？是各级行政官员都视法律为.土，人民仍被奴役着，被压迫着； “共和国是自由之国，自由是人民的天赋人权。可民国六年来我们看到的是什么？是只有当权者的自由，权力大的有大的自由，权力小的有小的自由，人民没有权力、没有自由； “共和国是博爱之国，人人为我，我为人人。可民国六年来我们看到的是什么？是只有人民对当权者恐惧的‘爱’，当权者对人民口头上的虚伪的‘爱’，那种真诚的真挚的博爱我们看不到。　　 “共和国是法制之国——“立法是国会。可民国六年来，我们看到的却是行政权力一次又一次肆无忌惮地干涉立法，你不听话，我就收买你，逮捕你，甚至暗杀你。立法者成了行政官员可任意蹂躏的妓女！　　 “行政是大总统和他统领的文官制度。可民国六年来，我们看到的却是一个打着共和旗帜的‘家天下’；在行政中，我们看不到透明的程序，看不到监督系统，人民不知道他们如何花掉了人民的血汗钱，人民不知道他们把多少钱装进了自己的腰包。共和国的行政应该暴露在阳光下，可我们看到的却是暗箱操作，漆黑一团！　　 “司法是裁判。它在立法和行政之间，谁犯规，他就亮谁的黄牌、红牌，甚至罚下场去。而裁判的原则是什么？是一部主权在民的共和国宪法！可民国六年来，我们根本没有看到这样一部宪法。就那部不成熟的临时约法也一次又一次地被强奸，被当权者玩弄于股掌之上。 “女士们先生们，我们的民主共和国成立整整六年了，可真正的共和国，她还没有开始！她一次又一次地被各种东西所击败。　　 “有人说，哦，不是一个人，是许多人，他们说，你说的这些个东西，太虚幻，太遥远，可望而不可及，不符合国情，是个气泡，看着很美丽，一飞上天，嘭，破灭了！这还是好听的。难听的说我是‘孙大炮’，就会放空炮，嘭——响声很大，可什么也没有！他们说，共和国其实就是个称号，还是别说她了，我们想要点实际的东西。 “那我想问问大家，我们到底想要什么？就要这样一个假共和吗？　　 “如果共和是假的，那我们有的就永远是真专制； “如果共和是假的，那我们有的就永远是真复辟； “如果共和是假的，那我们有的就永远是被奴役！ “如果共和错了，那自由就是错的； “如果共和错了，那平等就是错的； “如果共和错了，那博爱就是错的； “不，共和没有错，我追求共和没有错，你们追求共和也没有错，她只是还不完善。美国的共和制不完善，瑞士的共和制也不完善，咱们中华民国新生的共和制更不完善。我们要做的，是一点一滴地完善她，让她更美丽！ “我想到的是什么呢？还是民权。我刚才说了，三权分立那是西方的制度，很不完善，他们的立法、司法、行政都是高高在上的权力，很难直接体现民权。所以我想在宪法中规定人民有参政议政的权力。如何体现呢？ “一个是考试权。我们中国有考试的传统。可我们把科举废除了，这对大兴新学有好处，是好的；可当官不再考试了，这不好。这叫倒脏水把孩子也倒出去了！这就为任人唯亲、任人唯钱开了一个口子。大家看民国这六年来行政上用的都是什么人？都是袁世凯北洋的人，至今还是如此！所以我们要把考试权还给人民！今后用人行政，凡是我们的公仆都要经过考试。不管是谁，都有机会成为行政官员。 “还有一个就是监察权，这也是我们中国古代就有的。就是皇上有错，御史也可以冒死直谏，风骨凛然。现在，我们应该把这个权力让人民掌管。共和国的人民要人人都是御史，只要发现行政官员有错，就有权力弹劾！对你们国会的某项立法不满，也有权力弹劾。　　 所以，过去你们制定的共和国宪法，那是学西洋的，叫‘三权宪法’，我今天发明一个新词，叫做‘五权宪法’，就是在立法权、行政权、司法权之外，再加上考试权和监察权。大家不要小看这两项权力，如果‘老三权’不过是代议制度下的间接民权的话，那么我所说的这考试权和监察权就是直接民权！所以真正的‘主权在民 ’不是西方的‘三权宪法’，而是我发明的这个‘五权宪法’！”　 “啊”，也就是我设计的这件服装，有人就用我的名字来称呼它，叫‘中山装’—— “大家还不明白，是吧。我告诉你们——这本来是个秘密，连裁缝我都没告诉他——这衣服就是按照我们共和国的理念，按照‘五权宪法’的理念设计出来的。” 这里，我设计了三个扣子，这是让人们记住，共和国的理念就是‘自由、平等、博爱’。” “这里也有三个扣子，这是让人们记住，永远不要忘记人民，就是我们的‘民族、民权、民生’——就是三民主义。”　 这些口袋里装的，就是‘五权宪法’，这里装着立法权，这里装着行政权，这里装着司法权，这里装着考试权，哦没了？别急…… 他撩开衣服，露出里面暗兜，监察权在这里装着！这个监察权为什么要藏在里面呢？因为它是人民的杀手锏啊！当权者永远不知道人民什么时候就‘杀’过来弹劾他，所以他要战战兢兢地当官，老老实实地为人民做事！” “我是个疯子是吧？至少是个政治动物。穿衣吃饭都是政治，走路也是政治，开口就是政治。有点傻是吧？不好玩，一点也不好玩！没错。我不要求你们都跟我一样。更不能要求我们的人民天天过我这样的日子。我只是希望，让我们的共和国不是一个词语，不是一个形式，她要成为我们实实在在的生活方式，成为我们牢不可破的信念！因为，历史不是巧合，历史是选择，只有信仰坚定才能创造历史！”

Opera9.23@USB for U3

This afternoon I installed the Opera9.23 for U3. I think it's great for my Sandisk U3 though some obvious flaws.

Pros:
1. Small and fast.
2. Email integrated. easy to configure gmail and yahoo.
3. Speed Dial is cool.
4. Note function is simple but useful. I can forward my notes to my special gmail address for achive.
5. Contact, email well cooperated.

Cons:
1. Cannot set interval for checking email.
2. No synchronizing function for Opera U3 and desktop. It's said from 9.50 this function would come, so, just wait.

fishing

这样的论文也发表了

最后一段，呵呵，够意思。

强赞助人和HP services(notebook)

来美国前在国内买的二手，助人的，质量很不错。

前几天重装系统然后找不到无线驱动，非常感谢助人(join-2008.com)的同志帮忙找到发过来，非常感谢，呵呵，在这里小小广告一下~

最近风扇不知道怎么回事，一直转个不停，cpu的利用率只有2-5%的时候也是这样，这在以前是没有出现过的，以前这时候就知道一般是firefox占据90%cpu了。本来问题也不大，不过今天在安静的图书馆待着就觉出区别来了。在hp的网站上反映了一下，说偶笔记本最近风扇好像有异常，感觉好像是控制风扇的部分有问题了。没想到1个小时以后就收到一封信件问欧的地址电话，说要送一个dropbox过来。回信告知地址。刚才钓鱼回来收到信件说dropbox已经寄出..

这个服务做的到位阿，让人感觉真舒服。

btw,hp的小本用久了，感觉也很喜欢。唯一欠缺的就是指点杆做的比thinkpad还是要差很多。