伴随着夏天的暑热降临东瀛，日本各大商场也比往日变得热闹，几乎每家商场里都会设立“中元礼”专柜，加上五颜六色的装饰和广告，呼吁过往的客人 – 第一，该买中元礼了；第二，要买中元礼，我家最丰富最方便。。。

日本商场中的条幅让人想起那句话 – 我家今年不送礼，送礼就送脑白jin
日本人在生活中，一大特点是传统礼节繁多。我们中国人春节的时候习惯互相寄贺年卡，而在日本三伏天也会收到卡片，打开一看，原来是日本友人发来的“暑中见 舞” – 因为夏天到来而发来问候；不几天，又收到卡片，打开一看，原来还是同一位发来的“残暑见舞” – 因为夏天快过去了所以发来问候。从中国人的眼里看来，虽然礼多人不怪，这样过分的客气实在有些没必要。
http://www.talkcc.net/article/1694003
而在这种种传统中，有两次送礼最为隆重，一次称为“岁暮”，即新年到来时给朋友，师长等赠送礼品，一次就是现在这个季节送的，称为“中元”。日本送“中元”礼的时间，贯穿整个七月，送礼的对象，主要是长辈和曾经给过自己关照的人。

新年送礼，辞旧迎新，大家都可以理解。那么，夏天送“中元”礼是为了什么呢？
http://www.talkcc.net/article/1694003
因为在日本送中元礼的时候，商场里热闹得如同国内中秋前的月饼大战，很多在日本的中国人虽觉得时间有些出入，但经常把它和中秋节相混淆。偶然问之日本友人，方知这根本不是一回事。

在日本公司中，下级常常向上级寄送中元礼，笔者曾抱着开玩笑的心思向一个日本熟人问道 – 这样，是不是有行贿的嫌疑呢？不料，这位日本熟人回应道 – 中元礼，原来正是用来行贿的阿！
http://www.talkcc.net/article/1694003
原来，古代日本，“中元礼”真的带有行贿的色彩。所谓“中元”，来自中国传入日本的道教传说。集仙录曰：”张道陵于龙虎山，修三元默朝之道”。道家从汉代 张道陵开始奉三元大帝，称天地肇定后，天元，地元，水元三大帝负责治理天，地，水三界，考校天人功过，司众生祸福。并传说正月十五日为上元天官大帝生日； 七月十五日为中元地官大帝诞辰；十月十五日为下元水官大帝诞辰。这三天分别被道家称为上元节，中元节和下元节。道经称：天官赐福，地官赦罪，水官解厄。恰 巧，日本古代的政府官员也附会周礼自称“地官”。于是犯了罪的人常常借口七月十五日是中元地官大帝的生日，向政府官员也就是“地官”送礼，祈求赦罪。而当 时的政府也视此日的贿赂为官员们合法的灰色收入，而不加严格管理。久而久之，就形成了夏天向自己的上司，长辈和关照过自己的人赠送“中元礼”的习惯。按照 日本古代习俗，差不多所有的赠礼都要给予回礼，唯独给关照自己的人送中元礼例外，就是因为它本来属于贿赂的范畴而并非正常的礼物。

日本商场里邮送的“中元”礼的柜台
http://www.talkcc.net/article/1694003
当然，在今天的日本，赠送“中元礼”仅仅表达对受礼人的尊重和感谢，已经与贿赂无关。假如借口中元大帝的生日向检察官或者法官行贿，一样要被抓起来的。

事实上，中元礼的起源在日本民间至少还有两种其他说法。
http://www.talkcc.net/article/1694003
一种是“盂兰盆节相关说”。按照佛教礼仪，日本人在夏天都会过祭祀祖先和逝去亲人的“盂兰盆节”。在祭祀的时候，渐渐有些日本人感到也应该同时表达对于在世长辈的敬意，于是向他们寄送礼物，逐渐形成“中元礼”的习惯。

另一种是“八朔说”。和中国一样，古代日本也存在贡品制度。从室町幕府时代开始，向天皇和将军进贡贡品的时间被定在八月一日，称为“八朔”，从各地出发运 送贡品的官员同长七月就要上路。他们还有一个职责，就是为当地官员帮忙，帮助他们给关照过自己的长官带去礼物。这个习惯沿袭至今，就成了“中元礼”。
http://www.talkcc.net/article/1694003
综合看来，在日本“中元礼”的形成并非来自一个源头，以上三种说法都有一定道理。

古代，“中元礼”赠送的主要是贵重珠宝和地方特产，今天，具有地方特色的食品已经成了它的主体。其内容五花八门，包括茶叶，海苔，酒，点心，海鲜，蘑菇， 咸鱼，甚至酱菜。在各大商场中元商品专柜，通常都设有开放式的货架，上面摆放各种包装好的礼品样品，旁边加上价格和编号。通常中元礼的包装都精美高雅，外 包称为“水引”的特制包装纸，价格则考虑到顾客与送礼对象的亲疏从低于一千日元到数万日元不等，计算起来，比商品的正常价格要高20%-30%。讲究形式 的日本人却多半不肯自己买了礼品邮寄，而甘愿掏多两三成的价钱购买“正宗”的礼品。
http://www.talkcc.net/article/1694003
如果顾客对某一种礼品有兴趣，可以打开包装细看，决定购买后，只要记住编号，到专柜对服务员说明即可。

通常，在日本国内，销售“中元礼”的商场都免费提供寄送业务。这一点曾让我颇为困惑。因为有些商品本来就是时鲜（在笔者居住地附近的商场，今年有送一席包 括麻婆豆腐在内的川菜为“中元礼”的，生意还颇红火），本市内寄送还算说得过去，如果从北海道寄到九州，怎能承受得了如此旅途颠簸？而送货地点无论远近一 律免费，也就是说送到我家对门不花钱，送到几千里外的札幌也不花钱。
http://www.talkcc.net/article/1694003
川菜当礼送，并不是玩笑，不过日本的川菜一点儿辣味儿都没有。四川人问了 – 那叫个洒子汆菜呦

经过向商场的工作人员询问，才知道这并不奇怪。中元礼是日本商家一大赚钱机会，但能够做这种生意的，实际上只有屈指可数几家公司。各大商场里面的专柜，几 乎都是他们包下。他们能够承揽这个大生意，一个必不可少的条件就是具备涵盖日本全国的仓储网络，在任何商场销售的中元礼，其公司在全国各地的仓库中都要有 库存。这样，当你在大阪买一条鱼作为中元礼送给在东京的某人时，并不表示你买的这条鱼会被包装送到东京去，而是该公司大阪分公司送一个通知给东京分公司， 让他们从仓库中提出同样的一条鱼（分量，尺寸可能略有不同但相差不超过10%），从东京发送给你的朋友。所以，你要送礼的对象是在东京还是在北海道，对礼 品公司来说是没有区别的。
http://www.talkcc.net/article/1694003
最后，需要对前面的内容作一点澄清，所谓送一桌川菜作为中元礼，确有其事但每道菜是装在密封袋里寄送的，需要受礼人自己用微波炉加热才能实用。要知道把一 桌子热气腾腾带着鸳鸯火锅（去除辣味）的川菜滴水不露地运到收件人手中，不要说日本的礼品公司，就是孙悟空只怕也难以办到。

[完]

发表者：Google（谷歌）研究员 吴军

1. 成王败寇

2. 嗜血的地方

3. 机会均等

4.硅含量不断降低

5.亘古而常青

中国二十几年前有一本叫《神鞭》的小说，现在可能已经没有多少人记得了。小说讲述了一个发生在清朝末年的故事。主人公傻二从小练就了神奇的辫子功夫，在冷兵器时代他罕有敌手。后来他参加了义和团，在和拿着洋枪洋炮的八国联军和假洋鬼子的对抗中一败涂地。劫后余生的傻二剪掉了辫子，练就了百步穿杨的神枪法，并用他的枪惩戒了汉奸。他对别人讲：“辫子没有了，神留下。”硅谷也是一样，或者说半导体并不是硅谷真正的本质。硅谷的灵魂是创新。硅没有了，创新的灵魂留下了，它保证了硅谷的繁荣和发展。

我很喜欢德国一位诗人讲过的一句话：亘古而常青的昨天永远是过去，也永远会再来。这句话描述硅谷再合适不过了。当仙童和英特尔的神话已经成为过眼云烟时，在硅谷开创半导体公司的热浪仍然随着惯性持续了一段时间，但是英特尔那样的神话并没有重现，以后也很难有新的半导体公司能做到英特尔的规模。虽然有些投资者为自己错过英特尔的机会而惋惜，但是，人们很快在硅谷找到了新的金矿--软件业。

在信息时代，微软向全世界证明了计算机软件可以独立于计算机硬件系统成为一个赚钱的行业。同时（在企业级市场上）证明这一点的，就是甲骨文公司。在甲骨文和微软以前，计算机软件必须随着计算机硬件一起出售，无论是大型机公司 IBM ，还是小型机公司 DEC 和惠普都是如此。而 IBM 公司的商业模式以前是，今天仍然是硬件、软件加服务的捆绑销售。过去要想用 IBM 的系统，必须买 IBM 的硬件，外加每年百分之十左右的高额服务费，它的软件不单卖。甲骨文公司尝试了一种新的商业模式，并很快获得成功。这种商业模式今天说起来简单得不能再简单了，就是一次性卖软件的使用权，而这在当时是对 IBM 商业模式颠覆性的革命。这样用户不再需要每年向 IBM 等公司缴纳高额的服务费了。甲骨文公司看中了当时市场最大的数据库软件，开发出和 IBM 相抗衡的 SQL 数据库系统，很快靠“卖软件”的方式占领了市场，并且仅仅依靠数据库系统一种应用软件就成为了世界上第二大软件公司。后来就连 IBM 也学着甲骨文卖软件了。甲骨文成功后，硅谷很多人纷纷效仿办起了各种各样的软件公司，包括很成功的做 Photoshop 的 Adobe 和财务软件 Turbo Tax 的 Intuit（Google的邻居）。虽然很多基于 PC 的应用软件的公司都不断的被微软挤垮，但是总是不断有新的冒出来并且成长壮大。而企业级的软件公司由于和微软的冲突较少，更容易生存下来。

当计算机软件创业的浪潮尚未完全平息时，互联网又在硅谷兴起了。我们已经介绍了和互联网有关的思科公司，今后还会介绍 Google 和 Ebay，这里就不再赘述互联网的发展了。值得一提的是，以 Google 和 Yahoo 代表的互联网公司，颠覆了以微软代表的软件公司向每一个终端用户（End User）收钱的商业模式。而通过在线广告的收入保证终端用户可以免费享受以前的付费服务。除了当今世界上最大的 Google、Ebay 和 Yahoo 三家互联网公司在硅谷外，世界上三家最大的 Web2.0 公司中的两家，YouTube 和 Facebook 也在这里。（另外一家 Myspace 在好莱坞。）

在硅谷的人，不论是投资者还是创业者，已经习惯了这种快速的产业变迁，人们不断在寻找着下一个思科、下一个 Google 。其实，硅谷的创新并不局限于 IT 领域。生物科技无疑是硅谷另一个亮点。今天的硅谷，也是世界上新兴生物公司最集中的地方。硅谷拥有美国前十名的医学院中的两所--旧金山加大医学院和斯坦福医学院，以及世界上最好的化学系伯克利加大化学系。再加上充足的风投资金，便为创办生物和医药公司创造了条件。当然，硅谷人的创业热情在其中起了决定性作用，否则哈佛大学和约翰霍普金斯大学周围应该有很多的生物公司才对。

创办一家生物公司要比一般的 IT 公司更难，这主要是因为美国食品与药品管理局（US Food and Drug Administration，简称 FDA ）的限制，使得一项生物科技的发明很难在短时间即几年内变成产品和利润。所以，创办生物公司投入大、周期长。但是，在冒险家乐园的硅谷，仍然有很多人坚韧不拔地在生物科技领域艰苦地创业，它们中间不乏成功者。最典型的就是基因科技公司。该公司成立于一九七五年，早期，它依托于旧金山加大医学院，专门研究和生产抗癌药品比如 Avastin 和 Rituxan。今天基因科技已经是世界上最大的生物药品公司，有一万多名员工，包括无数杰出的科学家，市值达八百亿美元。并且，在 Google 以前，它是全美最好的雇主。

基因科技的成功经验很值得大书特书。但是，由于它不属于我们整个系列讨论的范围，我没有把它单独成章。但是，透过基因科技，我们可以看到硅谷的灵魂所在，因此我们简要介绍一下这家大家也许并不熟悉的公司。

在介绍基因科技之前，我们有必要先介绍一下美国医药市场的简单情况，这样才能理解基因科技公司的商业模式和经营方式。在美国，除了像西洋参和卵磷脂那样的保健品外，药品分为两类，一类是处方药比如抗生素，另一类是非处方药比如治感冒的泰诺。前者利润当然远远高于后者，而其中又以有专利的新药最挣钱。比如基因科研一共只有十种药品在市场上销售，每种药销售额最低的每年也有几亿美元，最高的 Avastin 年销售额近三十亿美元。美国专利法保证二十年内新药的知识产权。也就是说在这二十年里，一种有效的新药可以非常挣钱，而过了专利期，其它厂家可以仿制时，它的利润就一落千丈了。而新药的研制投入是非常巨大的，但是其生产的成本可以忽略不计，（甚至盗版的成本都很低）。在这一点上制药业非常像软件工业。（实际上，世界上药品的盗版甚至比软件盗版来的严重。）虽然药品市场没有反摩尔定理限制它的利润逼着医药公司发明新药，但是专利法起到了同样的作用，它既保护发明，又防止个人和公司长期垄断发明。如果一个公司旧的支柱药品专利到期了，而新的专利药品还没有跟上来，这个公司的业绩就会一落千丈。两年前默尔克（Merck）公司便是如此。因此，制药公司的竞争关键是创新的和科研效率的竞争。

照理讲，药品是一个规模非常大的行业，应该有很多新的公司冒出来才对。但是，美国食品和药品管理局 FDA 人为造成了这个行业极高的门槛。根据 FDA 的规定，所有处方药和用于临床的医疗仪器甚至是治疗方法的临床试验，都必须得到 FDA 的许可，更不用说在市场上销售了。而这些许可证是极难拿到的，要进行无数对比试验并且要尽可能了解和降低所有可能的副作用。FDA 的初衷很好，因为人命关天不能不仔细，但是这也使得小公司几乎无法进入处方新药的市场。其直接结果就是保护了原有的大公司利益和垄断性利润。（一种观点是，大制药公司通过 FDA 维护自己现有利益。）传统大的制药公司诸如辉瑞（Pfizer）和默尔克（Merck）的研究部门很像三十年前的贝尔实验室，一个科学家进去一干就是一辈子。而这些公司的高额垄断利润也养得起这些科学家。当然，人浮于事、效率低下和官僚主义在里面也屡见不鲜。由于 FDA 的保护，创业的小公司要打破原有制药公司的垄断是件很难的是。这就是我们很难看到小的生物公司成功的原因。

而以创新著称的硅谷却敢于挑战传统。基因科技公司的崛起，打破了传统制药业平静的水面，创造了一个神话。相对于有一百五十年历史的辉瑞制药（它的伟哥闻名于世）和一百多年历史的默尔克相比，有三十年历史的基因科技只能算小孙子。虽然它今天的销售额只有辉瑞的四分之一，但是却以每年百分之二三十的速度发展，而辉瑞制药基本上处于停滞状态，营业额时高时低，因此基因科技超过辉瑞只是时间问题。基因科技在早期阶段，无论从财力、人力以及和 FDA 的关系都无法和辉瑞等公司相比。它成功的关键就在于创新和执着。和生产上百种药品和保健品的辉瑞公司不同，基因科技公司只能集中于少数抗癌特效药，并保证每一种年销售额均在亿元以上。为了防止专利到期而带来的利润锐减，基因科技将销售额的百分之二十，去年是二十三亿美元投入到新药的研制上。在它现在的研发产品线上，有十四种药和治疗方法已经进入了上市前最后的阶段，十五种药和治疗方法进入了研制的第二阶段，十三种处于初期阶段。可以说今后若干年，基因公司产品线上会源源不断地推出新药，替代慢慢专利到期的旧药成为新的成长点。

创新必须依靠技术实力。和 Google 一样，基因科技也是世界上单位办公面积博士密度最高的公司。就连它的七名董事中都有五名博士，九名执行官中也有六名博士。基因科技里的科学家在同行中是佼佼者，在公司内部地位也很高。基因科技是我读过的上百个大公司年度报告中唯一介绍其所有资深科学家（Staff Scientists）的公司。当然，技术只是保证公司成功的诸多必要条件之一，但远不充分。要保证创新，公司的体制非常重要。这就如同一个国家，它的体制决定了它的发展。在传统的制药公司辉瑞制药，它是一个从日用品（这个部门最近卖给了强生公司）到最赚钱的药什么都做得巨无霸医药公司，它在全美国最赚钱的十个药中占有四席，它每年用于新药的研发经费也高达八十亿美元，足足是基因科技的四倍，但是它的研发效率却是主要医药公司中最低的，它那些挣钱的药主要是靠购买专利获得的，而不是自己开发的。（因为 FDA 设置的门槛，一个大学的研究室和小公司很难拿到 FDA 的许可证，所以采用将专利卖给大制药公司的做法。）这倒不是辉瑞科学家的水平不如基因科技，也不是他们不够努力。只有公司体制好，像辉瑞这么有钱的公司不愁找不到最好的科学家，只有有一个良好的知识转化成技术再成产品的有效途径以及公平的分配制度，不愁这些科学家开发不出好药。遗憾的是辉瑞旧式的体制恰恰做不到这一点，而基因科技完全按照IT公司的模式经营，却做到了这一点。

创新是在竞争中立于不败之地的保障，这任何国家任何领导人都懂得的道理。很多国家都投了大量的资金建造自己类似硅谷的科技园，以鼓励创新，但鲜有成功的。主要是因为其它地方很难再复制硅谷的天时（二战后 IT 工业的发展）、地利（背靠斯坦福和伯克利）和人和。而这其中，人和是最重要的，它就是在硅谷发展起来的新型的生产关系。这是硅谷在全世界最特殊的地方，并充分保障了创新。在生产关系中，在以科技为主的行业，生产资料的作用微乎其微，像微软和 Google 这样的公司，除去现金后，资产占不到市值的十分之一。那么人的作用就是关键，具体讲就是利润的分配方式和人与人的关系。科技公司的期权制保证了各级雇员除了工资以外，可以从公司的利润中分到一杯羹。因此，他们的利益和公司的利益息息相关。硅谷科技公司（包括基因科技等生物公司）在上市前，一般员工的股权可以占到公司的百分之十到十五。也就是说像 Google、英特尔和思科这样规模的公司，每家都有几十亿美元的财富掌握在员工手中。员工从股票上的收益可以大于自己的工资，这就是大家拼命干活的动力。在人与人、雇员与雇主的关系上，硅谷的环境是对发挥员工创造性最有利的。公司内上下级之间虽然有等级的差异但是彼此是互相尊重的。（有些时候，一个优秀员工的级别和收入可能比他的直接上级还要高。）这样大家在一起共事就会觉得相对“舒服”一些，每个人都容易安心做好份内的事，而不是必须勾心斗角往上爬。硅谷的基因科技和 Google 在最近的好几年中，被评为全美国最适合工作的公司。硅谷公司对员工的约束也很宽松，一般不会阻止员工跳槽，更不会因此打官司。甚至当员工利用职务之便搞发明创造（只要不是偷技术）然后出去创业，硅谷公司（包括各研究所）也不会像美国其它地方公司追究得那么厉害的，而一般采用入股的方式做到双赢。思科创始人和斯坦福之间就是这样解决了知识产权问题。我们可以毫不夸张地讲，硅谷的主流生产关系是世界上最先进的，这也正是保障了硅谷的创造力长盛不衰的原因。

结束语

今天，旧金山附近恐怕已经找不到一块金矿石了，“旧金山”这个名字只能代表它过去的历史。也许有一天，硅谷没剩下一家半导体公司，那时大家会说这里曾经有过半导体工业。但是它绝不会像底特律和匹兹堡那样从此衰落下去，而仍然会是世界科技之都，因为硅没有了而创新留下来了。硅谷的竞争仍然会很激烈，不断会有旧的公司消亡，旧的产业衰退，又不断会有新的公司创立和成长，新的产业诞生和繁荣。硅谷过去是、今天是明天还是年轻人梦开始的地方。

As you probably know MySQL Replication (statement based) works by fetching statements from MASTERs binary log and executing them on the SLAVE. Since MySQL 4.0 this process is a bit more involved having events passing via relay logs on the Slave which also means there are two replication threads "IO Thread" and "SQL Thread" used in the process but idea remains the same.

For replication to work properly you need to have proper "snapshot" - consistent state of the database as it was on master and corresponding position in masters binary logs. There are multiple ways to get the "snapshot" - shutting down MySQL Server and copying data, using LVM, Using Innodb Hot Backup Tool, Using another Slave, using backup image etc but in all the cases you have to be sure the snapshot you're dealing with corresponds to correct binary log position.

There are two sources of information for binary log position SHOW MASTER STATUS - this shows position as master writes its own binary and is helpful when you for example take backup on the Master to bring up first slave. This command output is pretty simple and leaves no room for mistakes:

If you're backing up from the Slave or you're cloning the Slave to make another one you need to use SHOW SLAVE STATUS which provides much more information.

As you can see in this output there are 3 log file names and log file positions which can get confusing, and indeed I often see people using wrong values to restore the replication using CHANGE MASTER TO statement.

It is very important to understand the difference between IO Thread position in Master logs (Master_Log_File:Read_Master_Log_Pos) and SQL Thread position in Master logs (Relay_Master_Log_File:Exec_Master_Log_Pos).

When you're using CHANGE MASTER TO to set start position for the slave you're specifying position for SQL thread and so you should use Relay_Master_Log_File:Exec_Master_Log_Pos. Otherwise you're going to ruin your replication.

It does not help SHOW MASTER STATUS has Master_Log_File value and CHANGE MASTER TO accepts Master_Log_File parameter, while you actually want to use Relay_Master_Log_File instead. This naming was left from pre MySQL 4.0 era and it still causes confusion so many years later.

The mistake of using Master_Log_File is in fact VERY typical. I've seen multiple "internal instructions" for cloning the slave or slave recovery from backup using this value.

Infact Master_Log_File will work in most cases as well - you can note in the output about Master_Log_File and Relay_Master_Log_File are the same, and it will be the case in vast majority of cases.

If your replication does not fall behind the SQL Thread and IO thread will be running close, quite often being at same master position at all. Even if replication gets a bit behind in most cases you would still see SQL thread and IO threads close enough to share same master log file. Only in rare cases of switching master binary log file or replication being delayed very significantly you will see different log files for these variables which makes it very easy to make mistake and very hard to catch.

---

Entry posted by peter | 5 comments

Add to: | | | |

发表者：谷歌公关部

今天，是俄国著名的超现实主义画家——马克·夏卡尔（1887年7月7日—1985年3月28日）的诞生纪念日。

我们谨以改变 Google Doodle 的方式，向这位艺术家致敬。