似乎每隔几个月，就有中国企业收购一些欧美著名制造企业部分业务的新消息。去年，中国电视机制造商TCL收购了法国汤姆逊公司(Thomson SA)的电视机业务，随后，阿尔卡特(Alcatel)的手机业务也被TCL买下。接下来，中国电脑集团联想(Lenovo)收购了IBM公司标志性的个人电脑业务。

 我们很可能还会看到更多的此类交易，因为富裕国家的企业发现，它们根本竞争不过中国极低的制造成本。这将引起很多人鼓吹(或攻击)即将来临的“中国世纪”。

然而，这些交易真正揭示的，却是“中国世纪”离我们还很遥远。当中国公司收购衰败的西方制造企业时，它们得到的条件远远没有台湾公司得到的那么优惠，这表明中国企业存在严重薄弱环节，需要多年才能克服。

去年宣布的两大中国企业并购交易中，联想和TCL通过极其廉价地出售股权，收购了现成(即使是不盈利的)外国品牌和分销渠道。TCL几乎没有动用现金就收购了汤姆逊的资产，而汤姆逊保留了电视机业务三分之一的股份，并且有权将其转换成TCL的股份。而联想则不仅以现金和承担债务的方式向IBM支付了17.5亿美元，还让IBM获得高达19%的联想股份。

在这两笔交易中，西方企业没有付出任何代价，就退出了不盈利的业务(IBM得到的报酬还很不错)，还获得了低成本的选择权，使它们能够在中国公司成功将业务扭亏为盈之后，也能得利。两笔交易对西方企业都极其有利，但对中国人来说，却有种迫不及待的架势。

上周，西门子(Siemens)掏钱给台湾企业明基(BenQ)，让它接手其境况不佳的手机业务。这笔交易就完全不同了。

西门子以相当高的代价退出了手机业务，而且只在明基可能会带来的业务扭亏中，获得一笔象征性股份。西门子将向明基支付2.5亿欧元，以让出手机业务，另外将支付5000万欧元获得明基2.5%的股份。此外，明基将获得西门子手机部门所拥有的全部专利。相比之下，TCL收购汤姆逊的电视机业务时，电视机中最值钱的元件显像管的生产却被排除在交易之外。

简言之，这家台湾企业很好地左右着局面，而大陆企业则被牵着鼻子走。为什么呢？

主要原因是台湾公司是真正的企业，有着来之不易的优势，可以转化为真正的国际竞争优势。而中国大陆却不是这样。虽然有种种对“中国制造业竞争力”的大肆宣传，但中国大陆的主要制造企业，其实是利用短暂套利机会赚钱的贸易公司。

台湾电子企业的主要优势在于供应链管理。台湾设备生产商依靠由高度专业化的元件供应商构成的密集网络。这些供应商和明基这样的最终组装商经营周转极快，且高度灵活。这种灵活性使台湾企业能将新设计迅速投入市场，并在有新的电子小设备发明时，很快开发出新的产品系列。自90年代中期以来，台湾企业将多数低端生产转移到劳动力成本较低的大陆，增强了自身的优势。

相比之下，TCL和联想等企业的兴起，主要是因为中国市场购买力和效率低下。当大多数中国人买不起质优价高的外国电子产品时，这些企业提供价格超低、而人们憧憬的电子产品。它们了解当地情况，在驾驭中国分散而不透明的分销体系时，这是一大优势。

但随着中国市场开放，且消费者越来越富有，这些企业的优势消失，利润也下降了。由于它们的利润率实在太低，因此TCL、联想这样的企业无力建立研发能力；但它们的日本和韩国竞争对手，正是借助研发活动长期保持竞争优势。而且因为这些中国企业本质上是套利商，它们没有像台湾竞争对手那样，提升制造及供应链管理的效率。

中国充满活力，制造业有着强大的比较优势。但其创业型企业十分不成熟，而且受到重重束缚，因为政府的产业政策向国有大型企业倾斜，使私营企业几乎无法整合国内市场、并投资发展持久的竞争优势。我们离“中国世纪”至少还有数十年。

//这样下去,中国的企业在世界上如何立足啊?

李维语一：不会用“设计模式”（design patterns）的程序员是低层次的软件人才，他们只会写code罢了.
李维语二：SUN和微软都在搞垄断。一个垄断了选择语言的权利，另一个垄断了选择操作系统的权利。
李维语三：程序员应该正确认识自己的发展方向，而不要把注意力集中于某种语言或讨论工具时优劣之上。
李维语四：程序语言固然重要，但程序员不能围着它们打转，他们必须摆脱对语言的依赖。很多人顶着C++光环，我觉得他顶的光环越大他的束缚也就越大，因为他没有跳出语言环境。
李维语五：程序员必须牢牢掌握中间件技术。要做到能够用它，还必须精通，能把它用在任何软件或项目的开发之中。

///////////////////////////////////////////////////

第一条和第五条个人感觉是最最重要,尤其是中间件技术,必定是需要每个有抱负的程序员好好掌握的!!!

准备写一个H261encoder/decoder练练手!
然后分析mpeg1/mpeg2/mpeg4

Google的服务怎么了?
Gmail老是无法登陆!

以后准备花些时间去学习BSD,—-我一直对Linux的安全性和代码质量产生怀疑,目前的Linux的开发模式根本不可能产生高质量的代码,推而广之,对整个开源社区也是如此,虽然有很多优秀的开发人员在开源上投入了大量的时间和精力,但是开源的管理模式却无比混乱,根本不可能产生优秀的代码,在很大程度上,开源软件就是”难用”软件.将一个开源的project集成到自己的项目中,经常是一件很痛苦的事.

//———————————————–

面临OpenBSD挑战 Linux将成为手下败将？

　　尽管Theo de Raadt是开源软件运动的先驱并且极力倡导免费软件，但是他并不是开放源代码操作系统Linux的爱好者。

　　De Raadt表示，人们对Linux盲目热衷，那些使用Linux的用户根本不知道这一系统有多糟糕，他们会执著地使用这一系统，尽管会遇到许多障碍，他们也不愿意退缩并且说’这简直就是垃圾，我们应该修复它’，显然这是一件可怕的事情。

　　De Raadt在开发另一个开放源代码操作系统OpenBSD，它是Linux的竞争对手。不同于Linux是Unix的克隆，OpenBSD是基于Unix变种BSD内核开发的。基于BSD演变出了全球最佳的两大操作系统，一个是来自Sun微系统公司的Solaris，另一个是苹果电脑公司的OS X系统。

　　基于BSD产生了三大开放源代码操作系统FreeBSD、NetBSD和OpenBSD，其中OpenBSD以其安全性出名。然而Linux的知名度和流行度远远大于上述任何一款BSD开源操作系统。De Raadt表示这其中部分原因是由于Linux系统得到了大型硬件厂商包括惠普和IBM公司的支持。

　　该人士表示，过于这些大型公司开发Unix系统不得不耗费可观的成本，当用户需要某些功能时，公司内部的工程师负责去开发，而现在他们可以让开放源代码社区做这些事，投入的成本也微乎其微。

　　De Raadt称他领导着60个优秀程序员组成的小组致力于OpenBSD系统的开发，他们一开始就采用了可靠的Unix内核，并采用了缜密的开发方式，不像Linux的开发过程那样散漫和仓促，为此其开发出的代码要远远优于Linux。

　　De Raadt直言不讳，我认为我们的代码质量更高，这是因为我们所采用的开发方式和专注的程度，而Linux系统根本就无质量可言，因为其很多系统功能是在仓促之间完成了。在评价Linux创始人Linus Torvalds时，De Raadt表示，我不知道在他开发Linux时专注的要点是什么，但是这要点肯定不是质量。而Torvalds通过电子邮件称De Raadt是个很难相处的人，并拒绝做进一步的评论。

　　De Raadt在指责Linux系统开发过程存在问题的同时，还表示大型公司的介入也会带来新的问题，因为每个公司只会关注自己的日程开发，在不同公司产生冲突时就难免会争吵，就像最近红帽子公司的程序员发贴谴责IBM的Linux程序员。

　　对于Linux和OpenBSD两个开源操作系统而言，其开发者的动机也不同。De Raadt称，Linux社区之所以这么做是因为他们憎恨微软，而我们之所以这么做是因为我们热爱Unix，然而具有讽刺性的是尽管Linux爱好者们不断表示对微软的憎恨，但是Linux系统正越来越像微软的产品。

　　De Raadt表示，BSD本来有望成为全球最流行的操作系统，但是一个针对BSD的诉讼吓坏了开发者，最终这些开发人员转移到了Linux阵营并一直待着那儿，即时后来BSD被确信合法后。该人士表示，这的确是一件很遗憾的事情，Linux得花费很长的时间才能达到BSD系统10前就拥有的性能。

　　网络设备引擎开发商Lok科技公司最初在其设备中使用的是Linux系统，但是当公司的创始人Simon Lok在仔细察看了Linux系统内核源代码后，他决定转换到OpenBSD系统。Simon Lok获得了计算机专业博士学位。Lok表示，你知道我发现了什么？在Linux系统内核源代码中，我居然发现一个开发人员的评注称’这行代码是应该放置在这儿吗？’，居然开发人员都没有足够的信心，可见这个系统的糟糕性。因此我知道这是更换系统的时候了。

由于目前的项目中ME/MC,DCTQ部分使用了硬件加速,对于QVGA大小的图像,ME为7ms,MC为14ms,DCTQ为16ms,从而理论上可以达到27fps,但是由于三星的VLC部分好像有问题,所以我们目前将VLC部分放在ARM(192MHz)上单独实现,由于实现的不怎么好,VLC部分竟然用掉26ms,从而使得帧率一下子下降到了14fps,令人无法接受!
下周的主要任务是优化VLC!争取控制在10ms以内!

一天下来,充斥大脑全是 Ice,proxy,interface,reference,…..,英语忘的差不多了,资料看起来有点累,真想忘掉一切,好好的睡一觉!但是 I must fight for my dream!

   从semantic上来说，Reference就是一个变量的alias.对引用的操作对变量产生的影响与对变量直接操作完全一样。
    引用必须在定义的同时初始化
    引用初始化后不能再使其成为其它变量的引用。引用类似一个常量指针(int * const p)，不能修改引用的指向。
   
    ·假设有如下定义：
　　int j;
　　int & i = j;
　　那么，&i应该是什么呢？&i = &j，就是j这个变量的地址。

引用使用技巧：

1 引用和多态
　　引用是除指针外另一个可以产生多态效果的手段。这意味着，一个基类的引用可以指向它的派生类实例。例如：
　　class A;

　　class B: public A

　　{
　　 …

　　};

　　B b;
　　A & aRef = b; // 基类引用指向派生类
　　如果A类中定义有虚函数，并且在B类中重写了这个虚函数，就可以通过aRef产生多态效果。
2 作为参数
　　引用的一个重要作用就是作为函数的参数类型。C/C++的函数参数是传递value的，如果有大对象（例如一个大的结构）需要作为参数传递的时候，以前的（C语言中）方案往往是指针，因为这样可以避免将整个对象全部压栈，可以提高程序的效率。但是现在（C++中）又增加了一种同样有效率的选择，就是引用。
　　与指针类型的参数一样，引用不论指向什么类型的对象，作为参数传递的时候都是只压栈4个字节（在32位机上）。引用所占用的4字节大小是根据编译器产生的代码判断的，因为sizeof(a_reference)只能得到它所指向对象的大小。
　　引用型参数应该在能被定义为const的情况下，尽量定义为const，这不光是让代码更健壮，也有些其它方面的需要，例如，假设有如下函数声明：
　　string foo();
　　void bar(string & s);
　　那么下面的表达式将是非法的：
　　bar(foo());
　　bar("hello world");
　　原因在于foo()和"hello world"串都会产生一个临时对象，而在C++中，这些临时对象都是const类型的。因此上面的表达式就是试图将一个const类型的对象转换为非const类型，这是非法的。
3 作为返回值
　　引用作为返回值的时候，有一些规则必须遵守。这些规则包括：
　　不能返回局部变量的引用。这条可以参照Effective C++[1]的Item 31。主要原因是局部变量会在函数返回后被销毁，因此被返回的引用就成为了“无所指”的引用，程序会进入未知状态。
　　不能返回函数内部new分配的内存的引用。这条可以参照Effective C++[1]的Item 31。虽然不存在局部变量的被动销毁问题，可对于这种情况（返回函数内部new分配内存的引用），又面临其它尴尬局面。例如，被函数返回的引用只是作为一个临时变量出现，而没有被赋予一个实际的变量，那么这个引用所指向的空间（由new分配）就无法释放，造成memory leak。
　　可以返回类成员的引用，但最好是const。这条原则可以参照Effective C++[1]的Item 30。主要原因是当对象的属性是与某种业务规则（business rule）相关联的时候，其赋值常常与某些其它属性或者对象的状态有关，因此有必要将赋值操作封装在一个业务规则当中。如果其它对象可以获得该属性的非常量引用（或指针），那么对该属性的单纯赋值就会破坏业务规则的完整性。
　　另外，引用也常常与一些操作符的重载相关：
　　流操作符<<和>>。这两个操作符常常希望被连续使用，例如：cout << "hello" << endl;因此这两个操作符的返回值应该是一个仍然支持这两个操作符的流引用。可选的其它方案包括：返回一个流对象和返回一个流对象指针。但是对于返回一个流对象，程序必须重新（拷贝）构造一个新的流对象，也就是说，连续的两个<<操作符实际上是针对不同对象的！这无法让人接受。对于返回一个流指针则不能连续使用<<操作符。因此，返回一个流对象引用是唯一选择。这个唯一选择很关键，它说明了引用的重要性以及无可替代性，也许这就是C++语言中引入引用这个概念的原因吧。
　　赋值操作符=。这个操作符象流操作符一样，是可以连续使用的，例如：x = j = 10;或者(x=10)=100;赋值操作符的返回值必须是一个左值，以便可以被继续赋值。因此引用成了这个操作符的唯一返回值选择。
　　在另外的一些操作符中，却千万不能返回引用：
　　+-*/四则运算符。它们不能返回引用，Effective C++[1]的Item23详细的讨论了这个问题。主要原因是这四个操作符没有side effect，因此，它们必须构造一个对象作为返回值，可选的方案包括：返回一个对象、返回一个局部变量的引用，返回一个new分配的对象的引用、返回一个静态对象引用。根据前面提到的引用作为返回值的三个规则，第2、3两个方案都被否决了。静态对象的引用又因为((a+b) == (c+d))会永远为true而导致错误。所以可选的只剩下返回一个对象了。
4 什么时候使用引用
　　现在可以总结一下什么时候使用引用这个问题了。首先我们要看看什么时候必须使用引用：
　　流操作符<<和>>、赋值操作符=的返回值
　　拷贝构造函数的参数、赋值操作符=的参数
　　其它下面的情况都是推荐使用引用，但是也可以不使用引用。如果不想使用引用，完全可以使用指针或者其它类似的东西替代：
　　异常catch的参数表
　　大对象作为参数传递
　　返回容器类中的单个元素
　　返回类数据成员（非内建数据类型成员）
　　返回其它持久存在的，且获得者不负责销毁的对象

　　另外一些情况下，不能返回引用：
　　+-*/四则运算符

整个Ice体系包括：Slice（Ice规范语言，创建客户端/服务器之间的契约、描述持久化对象）及编译器（将Slice编译到C++、Java等目标语言，同时生成文档）、Ice（核心库，实现高效通讯协议，提供线程池支持等）、IceBox（Ice应用服务器）、Freeze（持久化对象管理）、Glacier（防火墙）、IceStorm（消息服务）、IcePatch（补丁发布服务），以及其它相关工具、软件包。

//
//the skeleton of server side
//
int main(int argc, char* argv[])
{
    int status = 0;
    //smart pointer:the main handle to the Ice run time
    Ice::CommunicatorPtr ic;//init to NULL?
    
    try {
    //init the Ice run time
    ic = Ice::initialize(argc, argv);
    //creat a adapter named "SimplePrinterAdapter",use TCP/IP,and listen 10000 port
    Ice::ObjectAdapterPtr adapter = ic->createObjectAdapterWithEndpoints(
        "SimplePrinterAdapter", "default -p 10000");
    
    //
    //insert actual implementation here
    //
    
    adapter->activate();
    ic->waitForShutdown();
    }
    //first:catch all the exceptions that may be thrown by the Ice run time
    catch (const Ice::Exception & e) {
    cerr << e << endl;
    status = 1;
    }
    //catch all the additional error msg
    catch (const char * msg) {
    cerr << msg << endl;
    status = 1;
    }
    if (ic) {
        try {
        ic->destroy();
        } catch (const Ice::Exception & e) {
        cerr << e << endl;
        status = 1;
        }
    }
    return status;
}

////////////////////////////////////////////

//
// the skeleton of Client side
//
int main(int argc, char * argv[])
{
    int status = 0;
    Ice::CommunicatorPtr ic;
    try {
    ic = Ice::initialize(argc, argv);
    //obtain a proxy for the client App
    Ice::ObjectPrx base = ic->stringToProxy("SimplePrinter:default -p 10000");
    
    //
    // insert actual implementation here
    //
    
    } catch (const Ice::Exception & ex) {
    cerr << ex << endl;
    status = 1;
    } catch (const char * msg) {
    cerr << msg << endl;
    status = 1;
    }
    if (ic) {
        try {
        ic->destroy();
        } catch (const Ice::Exception & ex) {
        cerr << ex << endl;
        status = 1;
        }
    }
    return status;
}