123
 123

Tip: 看不到本站引用 Flickr 的图片? 下载 Firefox Access Flickr 插件 | AD: 订阅 DBA notes --

2008-08-22 Fri

19:19 奋斗 (11437 Bytes) » 玉面飞龙的BLOG
3年前，麦子的一篇《我奋斗了18年才和你坐在一起喝咖啡》引起多少共鸣，一个农家子弟经过18年的奋斗，才取得和大都会里的同龄人平起平坐的权利，一代人的真实写照。然而，3年过去，我恍然发觉，他言之过早。18年又如何？再丰盛的年华叠加，我仍不能和你坐在一起喝咖啡。 那年我25，无数个夙兴夜寐，换来一个硕士学位，额上的抬头纹分外明显，脚下却半步也不敢停歇。如果不想让户口打回原籍，子子孙孙无穷匮，得赶紧地找份留京工作。你呢？你不着急，魔兽世界和红色警报？早玩腻了！你野心勃勃地筹划着“创业创业”。当时李彦宏、陈天桥、周云帆，牛人们还没有横空出世，百度、Google、完美时空更是遥远的名词，可青春所向披靡不可一世，你在校园里建起配送网站，大张旗鼓地招兵买马，大小媒体的记者蜂拥而至。334寝室很快在全楼名噪一时，小姑娘们从天南地北寄来粉粉的信纸，仰慕地写道：“从报上得知你的精彩故事……”得空，爬上楼顶吹吹风，你眉飞色舞地转向我，以照顾自己人的口气说，兄弟，一起发财如何？ 好呀，可惜，我不能。创业于你，是可进可退可攻可守的棋，启动资金有三姑六眷帮忙筹集，就算铩羽而归，父母那三室一厅、温暖的灶台也永不落空。失败于我，意味着覆水难收一败涂地，每年夏天，为了节省三五百块钱的机器钱，爹娘要扛着腰肌劳损在大日头下收割5亩农田。我穿着借来的西服完成了第一次面试，戴着借来的手表与心爱的女孩进行了第一次约会。当你拿到了第一笔投资兴奋地报告全班时，我冷静地穿越大半个北京城，去做最后一份家教。没错，“这活儿技术含量忒低”，但在第一个月工资下发前，我租来的立锥之地与口粮全靠它维持。 不多久，互联网就遭遇了寒流，你也对创业意兴阑珊，进了家国有性质的通信公司，我被一家外企聘用。坐井观天的我，竟傻傻地以为扳回了一局。明面上的工资，我比你超出一截，税后8000，出差住5星级宾馆，一年带薪休假10天。玩命一样地投入工作，坚信几年后也有个童话般的结尾，“和公主过上幸福的生活”。 好景不长，很快，我明白了为什么大家说白领是句骂人的话。写字楼的套餐，标价35，几乎没人搭理它。午餐时间，最抢手的是各层拐角处的微波炉，“白领”们端着带来的便当，排起了长长的队伍。后来，物业允许快餐公司入住，又出现了“千人排队等丽华”的盛况。这些月入近万的人士节约到抠门的程度。一位同事，10块钱的感冒药都找保险公司理赔；另一位，在脏乱差的火车站耗上3个小时，为的是18：00后返程能多得150元的晚餐补助。 这幕幕喜剧未能令我发笑，我读得懂，每个数字后都凝结着加班加点与忍气吞声；俯首帖耳被老板盘剥，为的是一平米一平米构筑起自己的小窝。白手起家的过程艰辛而漫长，整整3年，我没休过一次长假没吃过一回鸭脖子；听到“华为25岁员工胡新宇过劳死”的新闻，也半点儿不觉得惊讶，以血汗、青春换银子的现象在这个行业太普遍了。下次，当你在上地看见一群人穿着西装革履拎着IBM笔记本奋力挤上4毛钱的公交车，千万别奇怪，我们就是一群IT民工。 惟一让人欣慰的是，我们离理想中的目标一步步靠近。 突如其来地，你的喜讯从天而降：邀请大家周末去新居暖暖房。怎么可能？你竟比我快？可豁亮的100多平方米、红苹果家具、37寸液晶大彩电无可质疑地摆在眼前。你轻描淡写地说，老头子给了10万，她家里也给了10万，老催着我们结婚……回家的路上，女朋友郁郁不说话，她和我一样，来自无名的山城。我揽过她的肩膀，鼓励她也是鼓励自己，没关系，我们拿时间换空间。 蜜月你在香港过的，轻而易举地花掉了半年的工资，回来说，意思不大，不像TVB电视里拍的那样美轮美奂；我的婚礼，在家乡的土路、乡亲的围观中巡游，在低矮昏暗的老房子里拜了天地，在寒冷的土炕上与爱人相拥入眠。幸运的是，多年后黯淡的图景化作妻子博客里光芒四射的图画，她回味：“有爱的地方，就有天堂。” 我们都想给深爱的女孩以天堂，天堂的含义却迥然不同。你的老婆当上了全职太太，每天用电驴下载《老友记》和《越狱》；我也想这么来着，老婆不同意，你养我，谁养我爸妈？不忍心让你一个人养7个人。当你的女孩敷着倩碧面膜舒服地翘起脚，我的女孩却在人海中顽强地搏杀。 两个人赚钱的速度快得多。到2004年年底，我们也攒到了人生中第一个10万，谁知中国的楼市在此时被魔鬼唤醒，海啸般狂飙突进，摧毁一切渺小虚弱的个体。2005年3月，首付还够买西四环的郦城，到7月，只能去南城扫楼了。我们的积蓄本来能买90平方米的两居来着，9月中旬，仅仅过去2个月，只够买80多平。 没学过经济学原理？没关系。生活生动地阐释了什么叫资产泡沫与流动性泛滥。这时专家跳出来发言了，“北京房价应该降30％，上海房价应该降40％。”要不，再等等？我险些栖身于温吞的空方阵营，是你站出来指点迷津：赶快买，房价还会涨。买房的消息传回老家，爹娘一个劲儿地唏嘘：抵得上俺们忙活半年。在他们看来，7500元一平方米是不可思议的天价。3年后的2008，师弟们纷纷感叹，你赚大发了，四环内均价1万4，已无楼可买。 几天前，我看见了水木上一句留言，颇为感慨：“工作5年还没买房真活该，2003年正是楼市低迷与萧条之时。等到今天，踏空的不仅是黄金楼市，更是整个人生。” 真要感谢你，在我不知理财为何物之时，你早早地告诉我什么叫消费什么叫投资。 并非所有人都拥有前瞻的眼光和投资的观念。许多和我一样来自小地方、只知埋头苦干的兄弟们，太过关注脚下的麦田，以至于错过一片璀璨的星空。你的理论是，赚钱是为了花，只有在流通中才能增值，买到喜爱的商品，让生活心旷神怡。而我的农民兄弟——这里特指是出身农家毕业后留在大城市的兄弟，习惯于把人民币紧紧地捏在手中。存折数字的增长让他们痴迷。该买房时，他们在租房；该还贷时，他们宁可忍受7％的贷款利率，也要存上5年的定期。辛苦赚来的银子在等待中缩水贬值。他们往往在房价的巅峰处，无可奈何地接下最后一棒；也曾天真地许愿，赚够100万就回家买房。可等到那一天真的到来，老家的房价，二线、三线城市甚至乡镇的都已疯长。 这便是我和你的最大差别，根深蒂固的分歧、不可逾越的鸿沟也在于此。我曾经以为，学位、薪水、公司名气一样了，我们的人生便一样了。事实上，差别不体现在显而易见的符号上，而是体现在世世代代的传承里，体现在血液里，体现在头脑中。18年的积累，家庭出身、生活方式、财务观念，造就了那样一个你，也造就了这样一个我，造就了你的疏狂佻达与我的保守持重。当我还清贷款时，你买了第二套住房；上证指数6000点，当我好容易试水成为股民，你清仓离场，转投金市；我每月寄1000元回去，承担起赡养父母的责任，你笑嘻嘻地说，养老，我不啃老就不错了；当我思考着要不要生孩子、养孩子的成本会在多大程度上折损生活品质时，4个老人已出钱出力帮你抚养起独二代；黄金周去一趟九寨沟挺好的了，你不满足，你说德国太拘谨美国太随意法国才是你向往的时尚之都…… 我的故事，是一代“移民”的真实写照——迫不得已离乡背井，祖国幅员辽阔，我却像候鸟一样辗转迁徙，择木而栖。现行的社会体制，注定了大城市拥有更丰富的教育资源、医疗资源、生活便利。即便取得了一纸户口，跻身融入的过程依然是充满煎熬，5年、10年乃至更长时间的奋斗才获得土著们唾手可得的一切。曾经愤慨过，追寻过，如今，却学会了不再抱怨，在一个又一个缝隙间心平气和。差距固然存在，但并不令人遗憾，正是差距和为弥补差距所付出的努力，加强了生命的张力，使其更有层次更加多元。 可以想见的未来是，有一天我们的后代会相聚于迪斯尼（这点自信我还是有的），讲起父亲的故事，我的那一个，虽然不一定更精致更华彩，无疑曲折有趣得多。那个故事，关于独立、勇气、绝地反弹、起死回生，我给不起儿子名车豪宅，却能给他一个不断成长的心灵。我要跟他说，无论贫穷富贵，百万家资或颠沛流离，都要一样地从容豁达。 至此，喝不喝咖啡又有什么打紧呢？生活姿态的优雅与否，不取决于你所坐的位置、所持的器皿、所付的茶资。它取决于你品茗的态度。 我奋斗了18年，不是为了和你一起喝咖啡。 背景 3年前，一篇题为《我奋斗了18年才和你坐在一起喝咖啡》的文章引起了社会各界的广泛共鸣。作者麦子，这位来自小城市的年轻人，用第一人称描绘了最典型的中小城市和农村子弟的奋斗历程—— “从我出生的一刻起，我的身份就与你有了天壤之别，因为我只能报农村户口，而你是城市户口。……于是我要通过自己的奋斗获得你生下来就拥有的大城市户口，考学是我跳出农门唯一的机会。……我属于比较幸运的，东拼西凑加上助学贷款终于交齐了第一年的学费，终于可以如愿以偿地在大学校园里汲取知识的养分了。我努力学习获得奖学金，假期打工挣点生活费，因为实在不忍心多拿父母一分钱。……我发现自己真是土得掉渣，不会作画，不会演奏乐器，不认识港台明星，没看过武侠小说，不认得mp3，不知道什么是walkman。我的英语是聋子英语、哑巴英语，我的发音中国人和外国人都听不懂……终于毕业了，能幸运地在上海找到工作的应届本科生只有每月2000元左右的工资，我要租房，要交水电煤电话费还要还助学贷款，还想给家里寄点钱让弟妹继续读书，剩下的钱只够我每顿吃盖浇饭。” 在奋斗了18年之后，“我”终于融入到这个国际化大都市中，与周围的白领没有什么差别。“我的白领朋友们，如果我是一个初中没毕业就来沪打工的民工，你会和我坐在starbucks（星巴克）一起喝咖啡吗？不会，肯定不会。比较我们的成长历程，你会发现，为了一些在你看来唾手可得的东西，我却需要付出巨大的努力。” 革命尚未成功，同志尚需努力。
19:09 MySQL End Of Life (EOL) Policy (4627 Bytes) » MySQL Performance Blog

We’ve discussed today how we should implement MySQL Version advisory in mk-audit tool. One obvious questions was to look at the end of life - it is often bad idea to run MySQL versions past end of life as even security bugs may not be fixed in these (though do not get paranoid, if you’re running MySQL in isolated environment the risk may be low).
So how does EOL schedule looks ?

MySQL defines Active Lifecycle and Extended Lifecycle for release where first one is 2 years since initial GA release and second is further 3 years of life in “critical bug fixes only” mode with releases available for premium (Silver+) Support offerings.

For MySQL Community users this means only releases within Active Life Cycle will be made. For example MySQL 4.1 had end of its Active Lifecycle in the end of 2006. and indeed Latest MySQL 4.1 available for the public is 4.1.22 while as Manual Says there were number of further releases with last one in March 2008 containing fixes for security and critical bugs.

It is also worth to note even though MySQL 5.0 successor (MySQL 5.1) is still not released as GA, MySQL 5.0 Active LifeCycle will end in end of 2008, unless there are changes means. If same policies as of MySQL 4.1 are followed we’ll soon see stop in MySQL community releases of MySQL 5.0 most likely before MySQL 5.1 will proven MySQL 5.0 replacement.

There is no blame on MySQL - it is no fun to support these old versions both for Support team (remembering these all old versions limitations) and for development team, and it costs, so somebody has to pay for this and this is exactly what premium MySQL Support levels are for.

My main point is - make sure you understand MySQL Release Policy and so what to expect whenever you’re MySQL customer or community user.

Shameless Plug: I guess hundreds of Percona customers are reading this blog so I should say how Percona treats old versions. We obviously recommend to upgrade when it makes sense while at the same time we have no restrictions in terms of supported versions. If customer chooses to run older version he may have more problems and these may take more time to deal with, so the bill would be higher. We are also happy to provide builds based on updated trees and backport fixes from the newer releases if MySQL has chosen not to backport bug because of its severity. We believe in freedom of choice.

Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

18:37 Multiple column index vs multiple indexes (16696 Bytes) » MySQL Performance Blog

After my previous post there were questions raised about Index Merge on Multiple Indexes vs Two Column Index efficiency. I mentioned in most cases when query can use both of the ways using multiple column index would be faster but I also went ahead to do some benchmarks today.

I'm using couple of simple tables:

PLAIN TEXT
SQL:
  1. CREATE TABLE `t1000idxmerge` (
  2.   `i` int(11) NOT NULL,
  3.   `j` int(11) NOT NULL,
  4.   `val` char(10) NOT NULL,
  5.   KEY `i` (`i`),
  6.   KEY `j` (`j`)
  7. ) ENGINE=MyISAM DEFAULT CHARSET=latin1
  8.  
  9. CREATE TABLE `t1000idx2` (
  10.   `i` int(11) NOT NULL,
  11.   `j` int(11) NOT NULL,
  12.   `val` char(10) NOT NULL,
  13.   KEY `i` (`i`,`j`)
  14. ) ENGINE=MyISAM DEFAULT CHARSET=latin1

I have populated this table with random data for i and j having both of them having 1000 of distinct values, independent on each other. I also created couple of other tables with same data just with really low cardinality with i and j having just 3 values each. The table contained about 18M rows though was small enough to fit in the systems memory.

I've benchmarked simple queries using where clause which covers multiple columns:

PLAIN TEXT
SQL:
  1. Q1 SELECT sum(length(val)) FROM  T  WHERE i=2 AND j=1
  2. Q2 SELECT sum(length(val)) FROM  T  WHERE i=2 AND j BETWEEN 1 AND 2
  3. Q3 SELECT sum(length(val)) FROM  T  WHERE j=2 AND i BETWEEN 1 AND 2
  4. Q4 SELECT sum(length(val)) FROM  T  WHERE i=2 OR j=1
  5. Q5 SELECT sum(length(val)) FROM  T  WHERE j=2 AND i BETWEEN 100 AND 200

As some of them there way too fast if run once I ran them multiple times and measured time appropriately. To remove the overhead of starting MySQL etc from equation I also measured execution of "SELECT 1" query using same script and subtracted this time from result in the table.

time for ((i=0;i<100;i+=1)); do mysql test -e "SELECT sum(length(val)) FROM t1000idxmerge WHERE i=2 AND j=1"; done > /dev/null

In the result table I compute per query results and present results in milliseconds.

Query 1000 - 2 indexes 1000 - 2 columns 3 - 2 indexes 3 - 2 columns
Q1 20 0.2 6940 2530
Q2 25 0.3 7400 7500
Q3 25 0.3 7200 3830
Q4 70 3800 4700 4700
Q5 25 2980 - -

Note1: Q1 will not use Index Merge technique for low cardinality table but instead pick to do single index scan. I'm not aware of the optimizer hint which would allow to force index merge as you can do with index accesses in general.

Note2 Q2/Q3 can't use Index Merge however as it is currently implemented so they would use single index range scan. The 2 indexes however benefits to Q3 because it can only use first keypart of index (j,i) to resolve BETWEEN part of the clause which may not be very selective.

Note3 You may be surprised why 2 column index is faster for Q3 in case of low cardinality even though MySQL can't use index well. You're right MySQL can't and MySQL does not - Full table scan is performed and in this case turns to be faster than scanning 1/5th of the table using index. Also Full Table Scan is preferred for Q4 in all cases but in case of high cardinality multiple index configuration.

Note4 Q5 was just run on high cardinality tables to show what difference large BETWEEN can make.

Conclusion: For benchmarked queries we can see Multiple Column index beats Index Merge in all cases when such index can be used. It is also worth to watchout a MySQL may decide not to do Index merge (either intersection or union) but instead do full table scan or access table picking only one index on the pair.

Entry posted by peter | No comment

Add to: delicious | digg | reddit | netscape | Google Bookmarks

15:41 Friday round-up (2347 Bytes) » Red Hat Magazine

It’s the end of the week, and here’s a few stories that caught our attention:

11:02 利用字符串实现高精度数值运算（二） (705 Bytes) » yangtingkun
由于Oracle的数值类型的最大精度只有38位，因此对于高精度的数值计算就需要使用其他的方法来实现。这篇文章利用字符串来保存高精度数值，并实现了两个字符串中数值的运算。这篇描述两个字符串相乘。利用字符串实现高精度数值运算（一）：http://yangtingkun.itpub.net/post/468/469206上一篇给出了字符串表示的数值相加的函数，这一篇继续描述字符串表示数值相乘的算法。采用代码重用的方法，利用以前处理整数乘法的基础，加上小数部分的处理。整数部分算法描述可以参考：http://yangtingkun.itpub.net/post/468/241044由于包含了小数部分...
09:39 Sharding (292 Bytes) » Uploads from Fenng(dbanotes)

Fenng(dbanotes) posted a photo:

Sharding

09:13 Log Buffer #111: A Carnival of the Vanities for DBAs (7150 Bytes) » Pythian Group Blog » Log Buffer

Crisis has struck! This week’s Log Buffer editor had to beg off at the eleventh hour when his time vanished. It happens. But, in every crisis, an opportunity (well . . .  maybe, maybe not). The opportunity — an open discussion of this week’s best database blog articles. Readers in control.

Log Buffer is always looking for editors, so if you’d like to step forward and publish one on your own blog, read the Log Buffer guidelines and send me an email.

I’m going to go through my bookmarks and add my own presently. I hope to hear from you!

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Slashdot
  • Google
  • del.icio.us
  • Facebook
  • bodytext
  • Technorati
  • TwitThis
  • Reddit
  • Spurl
  • De.lirio.us
  • Furl
  • blogmarks
  • Ma.gnolia
  • E-mail this story to a friend!
09:06 需要什么样的监控? (3808 Bytes) » AnySQL.net

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    一提到系统监控就会联想到Cacti这个优秀的开源软件, 或用Nagios. 不管什么样的监控软件平台, 监控可做的事大约有四个方面.

    一定的报警机制. 对于特定的事件, 需要用特定的方式(手机, 邮件, 淘宝旺旺等)通知相关人员, 通知的事件大小由监制的机制来决定, 如果是7x24的, 那一般只有交易量下降多少比例时才会报警, 如果不是7x24的, 那么有任何错误发生时都需要报警.

    一定的图表显示. 图表是最好的表现数据趋势的方式, 对于交易量或主机负荷之类的少数重要数据, 用图的方式显示. 缺点是一个屏幕内能提供的信息量比较少, 对于详细诊断问题所在起不了多少帮助.

    很多的详细信息. 用网页方式显示某些方面详细的数据, 如将所有的消息滞留的情况记录下来, 用来查找发生的问题. 更多的如应用中关键的API调用次数, 显示一个当前值和历史平均值, 也可以确定某个点是不是有问题. 非常适合于详细问题的快速确定.

    一定的自动响应机制. 管理出身的会很关注这一点, 是很好的设想, 但不容易实现, 最简单地说表空问不足这个问题吧, 让程序自动加文件? 还是做一个空间预测, 提前加好空间, 个人偏向于后者.

    现在监时做的一些监控就是建立在自已开发的WebChart基础上的, 表格和图形并存的方式. 更适合于白天工作时段的监控, 好好保存一定历史信息, 还可用于事后问题查找.

相关文章 | Related Artiles

我要留言(当前0)

05:04 雅虎口碑需要增加SNS元素 (2772 Bytes) » Fenng's shared items in Google Reader
今天，一条马云称饿死也不做网游 中国雅虎不学网易的新闻，把我的视线又牵到了中国雅虎----雅虎口碑网。

我觉得马云看得很清楚，现在进入网游运营，大成功的机会已经很小了。不过，网游是一个成功的生意，围绕网游做一些支付宝的合作，甚至更多种类的一些服务都是可以的。

“ 中国雅虎强调，目前重点仍是生活服务的电子商务领域”。雅虎口碑要匹配实现的是未来五年巨大的第三产业和服务业的增长。雅虎口碑认为，租房子、吃饭、洗脚 店、理发、找保姆、找学校等等，是未来五年后中国互联网最大的业务之源。雅虎口碑的模式，在美国称为Local search，马云称之为生活服务类的平台。

这也就是为什么会有雅虎口碑的合并的根本原因。仅有口碑是不够的，需要由中国雅虎的支持。也就是说单独的分类信息网站是不够的。

说到分类信息网站，中国的分类信息网站学习的对象是：1995年创办于旧金山的Craigslist，创始人Craig Newmark。但他并不认可分类信息的说法，他说：“我不明白你们研究的商业模式是什么，我们是一个社区网站。”

我觉得他的说法是很核心的一个问题。

其实在搜索引擎当道的今天，信息的汇总、或者说搜集信息不是一个困难的事情。关键要看信息后面绑定的人群。

信息后面绑定的是中小企业，那是阿里巴巴；绑定的是小商户，那是淘宝。绑定的真正的消费者、爱好者，那就是健康的，是雅虎口碑想要的。最不合适的是绑定一大堆二手中介，那是目前分类网站都不想要的，因为他们影响用户的最终体验。

SNS的发展，特别是进入实名之后的SNS发展，为第三产业服务的网络化进程，提供了良好的基础。

我的观点依旧是融合。SNS网站现在聚集了真实的人，并且会越来越多；生活服务网站聚集了有效的服务。他们的发展会互相渗透，趋向融合，之后，竞争胜利者得以生存，并发展至趋向垄断。

这就是我们看到的，生活服务类网站，在分类信息的基础上，纷纷开始加大社区建设的投入的原因。而SNS网站，一条路走向WEBGAME，一条路走向生活服务。
01:48 简单syslog程序的改进 (764 Bytes) » Fenng's shared items in Google Reader

下午陪动力维护的兄弟去踩点，准备下周的电源割接，要影响几台服务器。回来后也没什么事情，业务那里几张单子做掉，一时又有兴趣来改一下以前的小程序。

主要起因是昨天偶然看到whatsup的syslog，打开很慢，而且搜索起来也不是很方便，于是想，写到数据库里就好多了。

于是在以前的程序上增加了写数据库的功能，把菜单什么的改成中文的，简单的INI文件配置数据库连接，ADO连接，可以自定义插表语句，以适应不同的表结构。

...

01:47 My Thoughts on China and the Olympics (1942 Bytes) » Fenng's shared items in Google Reader
Shared by Fenng
老外的评价

chinese_kids
Image from CNN

Two words: Fuck China.

Their “anything to get ahead” attitude is sickening. They’re exploiting the hell out of little kids by taking them from their families, putting the fear and pressure of a billion people on them, and putting makeup on them to try and pull off “16″.

It’s not working, guys. They’re fucking kids. 14 on a good day. The world is watching as you try and cheat your way to victory. We see what you are.

dismal
Image from ABC News

This same cheating mentality is driving the insane amount of pollution in the country.

red_river
Image from Treehugger

But who cares? Who gives a hell if the country is poisoned and ruined, right? What’s a few thousand people with cancer? As long as they’re an economic superpower, right? Anything for the glory of country, right? Displace tens of thousands to build the stadium, hide the squalor that their people live in day after day, lock up people who dissent.

All to make money. All to become powerful.

I hope the IOC finds that the Chinese lied about the ages of the young gymnasts. I hope they get stripped of all their medals. I wish them extreme embarrassment.

It will, in some small part, repay their soulless exploitation of humans for the sake of nationalism.:

01:06 [田径]博尔特到底做错了什么 为什么把矛头指向他 (4775 Bytes) » Fenng's shared items in Google Reader
Shared by Fenng
雅克·罗格 先生被北京的热情同化了
关键字： 罗格  北京奥运  博尔特

摘　要：“这不是我们所期望的冠军”，罗格这么评价着这位牙买加短跑运动员 。“我对他的作秀没有任何意见。但是我认为他应该对他的对手表现的更尊重一些，比赛结束后马上向其他挥挥手，拍拍肩。而不是做出那样的手势，好像100米这个项目只属于他一个人一样。”

体坛通讯员殳海报道 这几天，体育界最具权威的人士——国际奥委会主席罗格先生一直拿一位来自小岛国的短跑运动员大做文章。

博尔特在两项最举世瞩目的比赛里的表现虽然精彩绝伦，但是另外一些细节却被罗格认为是：现代奥林匹克史上最不合时宜而最无趣的。

“这不是我们所期望的冠军”，罗格这么评价着这位牙买加短跑运动员 。“我对他的作秀没有任何意见。但是我认为他应该对他的对手表现的更尊重一些，比赛结束后马上向其他挥挥手，拍拍肩。而不是做出那样的手势，好像100米这个项目只属于他一个人一样。”

天啊，这可比那些关于行贿买通IOC官员的谈话要有力度多了。

包括美国在内的所有强国、大国们，在比赛中都有自主权。他们可以撅嘴、炫耀、使眼色、大发抱怨、不能兑现他们对祖国的承诺……他们可以做任何他们想做的事情。甚至会让人觉得他们完全可以轮流给罗格主席和他的同事们一巴掌都不打紧，反正有人会来帮他们买单，请罗主席吃晚餐、喝红酒。

博尔特仅仅是一个短跑运动员而已。即使你不喜欢他的举止，也没有必要去攻击他、并把这个问题放到全世界范围内去讨论吧？

“我能理解他的幽默，”罗格说，“但是他可以用另一种方式来表达，而他呢？肆无忌惮地跟所有人表示‘有本事你就来追我啊’。也许他不会这么做，但是他却记在了心里，他还是个年轻人啊。”

博尔特是在跟谁表态呢？那些多年来一直都有庞大资金支持的大国运动员们？他们是这么定义的吗？然后再把他大肆宣传一番？

其实博尔特的形象，和奥林匹克的定义无比贴切。他不是什么发达国家的产物，但是通过计划周密的训练，他是那么理所应当地得到了金牌。

博尔特就像一缕春风般吹进了这个当今体育界，这个有如天外来客的家伙用他疯狂的表现和鲜明的个性让整个世界惊喜。他已经不再是那种老式机器里制造出来的工业品了。

博尔特属于他自己，而全世界也因此爱上了他。

凭借着他内心强烈的获胜欲望，博尔特成为了本届奥运会上最闪耀的明星，以他的一己之力拯救了“后菲尔普斯”时代，这几天奥运会的票房——虽然他没有那么多机会去创造世界纪录，但是他所表现出来的能力和他带给人们的快乐，完全能和菲尔普斯相提并论。

他在跑道上的所有竞争对手都输得心服口服，没有人对博尔特提出任何质疑：因为他们也知道，只有博尔特这样天神般的表现才能把田径历史上写满禁药丑闻的那一页翻过去。“闪电”博尔特终于用自己创造的奇迹把人们的视线拉回到了田径赛场，而在两个星期前，恐怕人们连想都不敢想。

“我并没有觉得他表达了任何不敬的意思，”美国名将肖恩·克劳福德对美联社的记者说，“他完全可以在场上尽情起舞。”

所以，我们想要告诉罗格先生，如果您真的想要展示自己强硬的一面，也许不应该拿博尔特这样一位来自小国的运动员开刀，不管是批评谁、发表什么头条言论，都大可以放胆去谈。

也许博尔特是奥运会的一个大问题，因为他让世界都觉得尴尬。但至少，他身上有值得我们学习的东西。

是的，雅克·罗格先生，是的。

2008-08-21 Thu

23:52 PHP字符编码绕过漏洞总结 » Fenng's shared items in Google Reader
23:44 gitorious » Fenng's shared items in Google Reader
22:56 联想 » Fenng's shared items in Google Reader
22:56 My Thoughts on China and the Olympics » Fenng's shared items in Google Reader
22:14 最佳雇主 » Uploads from Fenng(dbanotes)
22:01 最佳雇主 [Flickr] » DBA notes
21:55 央视记者冬日娜对史冬鹏的暴汗采访 » Fenng's shared items in Google Reader
21:07 央视记者冬日娜对史冬鹏的暴汗采访 » Fenng's shared items in Google Reader
20:25 关于英特尔文化----寄语Fab 68新员工 » Fenng's shared items in Google Reader
19:56 How to find wrong indexing with glance view » MySQL Performance Blog
19:12 鲜果诚邀各方合作，共赢新媒体未来 » Fenng's shared items in Google Reader
19:05 年纪大了，脑子不对了 » Fenng's shared items in Google Reader
13:30 Rendundant Array of Inexpensive Servers » MySQL Performance Blog
10:29 比特海29月9日，尘满面鬓如霜 » Fenng's shared items in Google Reader
07:51 开启异步IO的相关风险 » OracleBlog.cn
05:41 IBM Support Bulletin URL » AIXpert
00:00 TCP 连接断连问题剖析 » developerWorks 中国 : 技术文章 , 教程 AIX

2008-08-20 Wed

22:31 Learning ODI - Sybase to Oracle » Chanel [K]
20:57 I’m speaking at few conferences: OracleWorld, Miracle Open World, UKOUG, CMG » Tanel Poder's blog: Core IT for geeks and pros
20:07 科学救助流浪猫 » Fenng's shared items in Google Reader
14:48 VeryCD, The Leading Chinese P2P Media Directory Will Be Revamped Soon » Fenng's shared items in Google Reader
07:01 推荐一个多协议IM工具Pidgin » Ricky's Test Blog
00:11 2008奥运新疆游记 » Oracle Team @SNC

2008-08-19 Tue

22:31 Korn Shell 脚本入门 » developerWorks 中国 : 技术文章 , 教程 AIX