戏说Linux-2.6.38中进程调度的优化

2.6.38?现在2.6.37还在RC中,怎么会有38?是的,因为37进了RC,所以不会再加新功能了。那么将要进入的新功能只能放到38中。而谁会是2.6.38的闪光点呢?对于进程调度subsys来说,很有可能就是autogroup了。

虽然现在这个新功能还在讨论中,但是Linus和Ingo都已经buy in得差不多了,进入main tree是指日可待了。这个feature要说最早也是来自于Linus的灵感,其实很多人应该也多有感受。比如在我们编译内核时,桌面响应就会变慢,甚 至在vi里敲个字都顿啊顿的;再比如在emule下载完一部电影后做sync时,大量IO也会拖得桌面很顿。这是由于进程调度器在选择下个需要被调度进程 时对于需要快速响应的进程没有做到充分考虑其特殊性。但是你要是用过Redhat9的话,一定会感觉现在Linux的桌面响应或是普通tty响应都快太多啦。这完全要归功于Con Kolivas 和Ingo的不懈努力得到的CFS(虽然Con在技术论战中败下阵后一蹶不振,回去干麻醉师的老本行了;但在论战中胜出的Ingo把sched维护的有 声有色),CFS的完全公平调度天性,让编译程序等非交互性进程被调度器选择时的优先度大大降低(运行的时间越多,在RB tree中越靠边;而运行时间及机会越少的交互式进程越有机会靠近RB tree的左下角,这个左下角可是黄金地段啊,调度器就喜欢从这个地方调进程了)。这么看来CFS做的也很好了,但是在这个牛人辈出的时代,Mike Galbraith站了出来,大声的说,我还可以让交互进程响应更快!

凭什么这么说?凭cgroup!说到这个cgroup,对笔者来说算是老朋友了,或者说是老朋友的老朋友了。国内的Linux新一代牛人中的一位Zefan LI是我的老兄弟,而他恰恰又是cgroup的maintainer,2008年时国内的少数几位内核维护者之一。cgroup是干嘛的呢?google 搜一下,有功底的朋友应该可以看懂,我在这里简单解释,相信也能让大家有个概念。想象一下有这么种容器,你可以把进程放入其中,并给这个容器贴个标签,比如:“核心业务进程”,“娱乐用进程”,“老婆用的进程”等等。并且你可以拿个更大的容器,把“娱乐用进程”和“老婆用的进程”的小容器都扔到那个大容器中,并贴个标签“家用进程”。cgroup就是用来定义这些容器的框架。有了它,我们可以让“核心业务进程”的容器内的进程享有一些特权,比如说固定的网络带宽,较大的IO速度等;我们还可以让“老婆用的进程”容器里的进程只得到很少的系统资源,哈哈,床上打不过你,我还不能靠我的拿手本领整你!(这里的我,泛指天下受苦受难的男性软件工程师)

废话少说,就要到正题了,看到这里,就算你不是Mike G,你也该知道怎么整了吧?虽然知道怎么整与能整出code来还是有差距的,但是至少我们也想到啦。Mike的做法果然不出我们所料,具体说,就是在进程需要用到tty资源时,比如说vi啦,gedit啦,魔兽世界啦。。。。(魔兽世界在Linux上还能玩啊?)就把它放到一个特殊的容器中,这个容器贴了标签“老子要快点响应”。那么进程调度器在挑选下一个家伙来使用CPU时,就会乖乖的去找它啦。就这么简单。简单?你去写一个!

Mike只用了一个220行左右的patch就做到了,代码极尽精炼无耦之能事,被Linus开心的表扬了一遍又一遍。不过最厉害的还是让数据说话,调度平均响应时间为原来的16分之1左右。厉害吗?太厉害了。但是。。。

对的,什么事都会有但是,这是唯物辩证法告诉我们的。cgroup对系统是有penalty的。你想啊,本来人家进程们好好呆在红黑树上等着调度,你非得再给人家按容器分分类,贴贴标签,等到调度器来拉壮丁去享受CPU或其他资源时,不仅得去树里挑,还得在一堆罐子中挑,最可恨的是罐子里还套着罐子。这个Linus当然也是一针见血的就看出来了,可Mike不愧是小牛人。立马拿出准备已久的理由说,对于缺少人机交互的server来说,这个确实比较扯淡(其实也还好啦,cgroup不会带来大于5%的开销),但是对于那些装了Fedora,Ubuntu等等的桌面用户来说,根本无法感知cgroup的开销,反而会乐意接受基于cgroup的autogroup带来的高速响应。厉害!

厉害归厉害,社区里厉害而又爱挑刺(追求完美啦)的人多得是,所以Mike同志还在矜矜业业根据大家的建议做些细微的改善,细微却很重要的改善,估计进Ingo的sched tree是没问题了。热切期待其正式进入2.6.38,接受大众的考验。

Which areaes kernel contributors focused on

I’ve made a new kind of analysis for Linux Kernel contributions. It tells us the contributors, such as IBM, Intel, Oracle and Fujitsu etc., were focusing on what kind of areas/subsystems of kernel to make their contributions.

As we know, Linux Kernel have a lot of different kind of active contributors including Non-profit and corporations. For corporations, there are also lots of different kinds and make the contribution be done on different kernel subsystems. We can simply attribute the corporations to distro vendor, hardware vendor, software vender and IT vendor, and pick up some representative corporations from each class to see what those giants are interesting in and bring them on contributing.

1) Distro Venders which sell Linux Distributions and provide support service

a) Red Hat

  • kernel/trace/:  No surprise that an OS development company uses a lot of effort to focus on how to monitor and debug kernel.
  • arch/[x86|sparc*|ia64|powerpc|x86_64]/:  As we will see, although other companies also cover some parts of arches,  such as x86(Intel), PowerPC(IBM) and ia64(SGI), no one completely covers so many arches as a kernel contributor. A distro vendor should take care of arch code as seriously as platform vender.
  • drivers/[net|char|scsi|media|ata|md|...]/:  Also no surprise, although some hardware vendors provide Linux driver for their products, distro vendors still need to take care of some orphan devices or integration bugs.
  • fs/gfs2/:  Not only as a Distro Vender, Red Hat plays some role of IT vendor too and provide integrated solution for costumers. The Red Hat’s product – GFS is the file system which used for manage cluster servers for enterprise deployment.
  • Red Hat are involved in a lot of other areas to which the contributions are not as shining as those mentioned before, however they are still huge ones compared to the contributions of companies after TOP10 contribution. Details can be referred by the KPS statistic data.

b) Novell

  • sound/pci/: As Novell claimed “SUSE Linux Enterprise Desktop is the market’s only enterprise-quality Linux desktop”, SUSE also aims on desktop market. Providing great sound subsystem seems be consistent to that target.
  • drivers/*/: Also consistent to the desktop market target, Novell provides more driver development efforts than Red Hat. Greg KH as one of the Novell employee costs a big part of his time on Staging Drivers to help Linux Kernel to support more and more new cool drivers.
  • fs/fuse/:  I can’t see obvious reason that why Novell support fuse such dedicated.

2) Hardware Venders which mainly sell hardware for profit.

a) Intel

  • drivers/net/:  Who are the biggest NIC and Wireless NIC vendors on the world? I think Intel must be one of the them.
  • drivers/acpi/:  As the biggest platform vendor, Intel leads the hardware and software development of power management.
  • arch/[i386|ia64|x86_64]/:  Who made the CPUs? As the biggest CPU manufactory, Intel should take care the arches which her CPUs support.

b) Renesas

  • arch/sh/:  SuperH arch’s biggest manufactory supports the sh kernel without any surprise.

c)  Analog Devices

  • arch/blackfin/: Most of her efforts focus on her own platform – blackfin.

3) Software Venders which mainly sell software(except OS) and service for profit.

a) Oracle (before acquiring Sun, Oracle is more like a software vendor)

  • fs/[btrfs|ocfs2|nfs]/: As the biggest OSS contributor of software vendor, Oracle is carrying a lot of OSS projects on. The Linux kernel filesystems are just the typical area Oracle is focusing on. As a database maker, Oracle is enforcing some filesystems of Linux Kernel and keeping creating new filesystems to tie in with their database or middleware products.
  • block/:  No surprise, Oracle should not only spend efforts on fs subsystems and also block IO subsystems to support their database solutions.

b)  Parallels

  • net/[ipv4|ipv6|core]/:  As a virtualization software maker, Paralles’s engineers did a lot of jobs to refine network namespace, which can support network virtualization better.

4) IT Venders which sell whole solutions including hardware, OS, middleware and applications, and of course service for profit.

a) IBM

  • arch/[powerpc|s390|ppc64]/: IBM created those arches and provided Linux kernel which can be run on those platforms.
  • kernel/:  As the No.2 kernel contributor following Red Hat, IBM did a lot of work to core kernel part, such as kernel synchronism, cpu control, kprobe and etc.
  • fs/[cifs|ext3|ext4]/: IBM also hired some active community engineers who work on filesystem area. As we all know, Ted is working as ext3/4 maintainer, IBM employee and TLF consultant.
  • Linux Test Project: Although my statistic analysis only includes kernel source code, the great work of LTP makes me have to mention it. As a synchronous-with-kernel and individual project, LTP keeps updating its test cases for kernel and makes a lot of Linux related IT vendors to have a easy day to do QA work for kernel. The LTP project is a special contribution to Linux Kernel.

b) SGI

  • fs/xfs/:  As a product of SGI, XFS got wonderful support from SGI. A storage solution and HPC vendor taking some efforts on filesystems is totally unsurprising.
  • mm/:  Former SGI employee Christoph Lameter did a lot of contribution to memory management subsystem.
  • arch/ia64/: SGI and HP are the initiators of IA64, thus for IA64, SGI did a lot of work as well as HP, Intel.

c) Fujitsu (my former employer :) )

  • kernel/trace/: As a whole IT solution vendor, Fujitsu are doing a lot of work to enhance Linux Kernel’s trace and debug features to provide customer a more robust, maintainable and higher availabilty IT environment.
  • drivers/pci/:  During integration, Fujitsu enhances drivers to ensure a high quality hardware environment of server.
  • mm/:  Memory controller is maintained by Fujitsu and Google engineers to provide user a more flexible IT environment.

As we can see, corporations are dedicating themselves to kernel contribution for their product lines or services and trying to feed back to community when they gain from community. They are taking the responsibility to make sure the enterprise using components of kernel to be as healthy as customers want.

Let’s see the non-profit contributors are focusing on what areas, which maybe different from that of corporations.

Hobbyists (No one pays them for doing kernel contribution)

  • drivers/media/:  As we know, no commercial companies focused on this area. But hobbyists committed 3818 patches(2.4% of total patches of kernel since Linux-2.6.12) to drivers/media/. That  is the amazing phenomena that desktop users are doing such great works to kernel development.
  • drivers/[net|ide|staging|usb|video]: A lot of hobbyists are taking care of the stuff which enterprise users maybe don’t want to care.
  • arch/[x86|arm]/:  The hobbyists’ most favorite platforms are x86 and arm :)

That’s the brief introduction about who are interesting in what subsystem of kernel.

For detail information about other corporations and non-profit population who are not mentioned here, such as Google, HP, Academics etc. please refer to the statistic.

Canonical copyright assignment

Canonical由于对内核社区的贡献很少,曾经受到Greg老大的点名批评。但是Ubuntu的高用户体验,以及我所知道的一些在Canonical工作的朋友对社区的贡献,让我感觉到Canonical是一家真正想做开源的同时又使用私有软件来提高发布版质量的开源公司。

但最近Canonical发布的新条款,让人不禁对此产生怀疑。难道Canonical只是一家利用开源做私有软件的公司?

新条款确实有一些不厚道的地方,可能会减少Ubuntu粉丝的贡献度。比如:Canonical will ordinarily make the Assigned Contributions available to the public under a “Free Software Licence”, according to the definition of that term published by the Free Software Foundation from time to time. Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms. 很多开源贡献者并不想把自己的代码交给那些会把它变成”Free Software Licence”的人,更何况,根据本条款,Canonical还可以把其他许可权条款加到代码上,而“其他许可权”很有可能就是私有软件许可权。

Canonical会不会在未来进一步对这个新条款做解释,我们将拭目以待。

声纳型电脑电源管理

这个Geeker觉得现在计算机的电源管理功能太弱,比如看电影时会自动屏保,休眠之类的.

于是开发了一个通过声纳系统来精确探测室内人员的系统,主要是使用每台计算机都具备的speaker来发出超声波,然后通过计算机的话筒(有些笔记本会自带)来接受回声,从而像雷达一样判断活动物体.

想法是挺好的,但是我不敢用,因为不知道超声波到底对人体有没有影响,特别是对我们家未来的孕妇和胎儿来说,还是安全第一.

玩笑开大了

2009 LinuxConf上Mark Shuttleworth(Ubuntu的核心维护者)负责一个Keynote,并在其中说了一段让众多女性开源软件爱好者感到被冒犯了的话,大意:“if we did a better job at considering our non-technical users and accepting help from expert UI designers, we’d have an easier time “explaining to girls what we actually do”.”

虽然有很多其他男性社区开发人员为Mark辩解,但是女性开发人员仍然认为Mark欠她们一个道歉。目前Mark本人还没有表态。

从我的观点来看,Mark的话无疑把“girls”等价于”不懂软件开发技术的人”,确实是个冒犯。但冒犯女性不是他的本意,所以也可以看作是无意的冒犯。很可惜,无意的冒犯,也需要一个道歉来回答。

据说,以下言论也有大男子主义倾向:

“A release is an amazing thing; I’m not talking about the happy ending..”

“Your printer, and your mom’s printer, and your grandma’s printer”

所以大家以后在公共场所发表技术言论时一定要注意玩笑的尺度 :)

Android代码将被Linux内核驱逐?

继之前微软的Hyper-V事件后,Linux内核驱动程序维护者GregKH在9-Oct.提出将在2.6.33内核开始删除Android驱动。

Due to no support from Google, I’ve dropped the android code from the staging tree for 2.6.33.
不过Google的职员的对应相当迅速,David(虽然不负责Android开发)质疑了Greg的“no support from Google”指责,表明对于是否删除Android代码没有意见,但是对于Greg给出的理由表示了不满。明显Google对于Android给予了一定的支持,但是由于和开源社区的开发流程不能很好融合的原因,导致了对于驱动的修补反应较慢。
那么Android驱动在Linux内核中的命运到底如何?这可能还要看Android开发者们跟社区是否能够更好的合作,Greg目前还没有收回删除Android驱动的想法。

微软向Linux提交代码能走多远

微软虚拟机代码可能被移出Linux!

Linux驱动维护者GregKH在为Linux-2.6.32的merge window做准备时整理了现有的staging目录。对于微软提供的虚拟机hv驱动代码发表了一下的观点:

hv (Microsoft Hyper-V) drivers. Over 200 patches make up the massive cleanup effort needed to just get this code into a semi-sane kernel coding style (someone owes me a bit bottle of rum for that work!) Unfortunately the Microsoft developers seem to have disappeared, and no one is answering my emails. If they do not show back up to claim this driver soon, it will be removed in the 2.6.33 release. So sad…

目前的hv还没有进入mainline,但是在Greg的patch队列中可以看到hv的代码确实来自于微软。微软在2009年七八月份时把她的Hyper-V技术相关的驱动代码以GPLv2的许可权方式贡献给了Linux内核社区。其主要目的是希望Linux可以运行在Windows2008及其Hyper-V虚拟机之上。

对于如此巨大的贡献,Greg自然非常乐意接受,可是在Greg提出一系列TODO后,微软的开发人员反应非常缓慢,导致Greg发了以上的观点。虽然hv还是有可能在2.6.32的merge window期间加入mainline,但是如果微软的工程师继续不理会Greg的要求的话,hv也有可能在2.6.33的开发期间被移出。

好在微软又做出了反应,这次的微软Linux合作得以有继续的可能,我们也将拭目以待这次重大的合作是否能给微软和Linux带来双赢。

Linux内核社区投稿

2年前指导公司内部人员如何提交Linux内核Patch时整理的wiki资料。在这里共享,主要介绍Patch作成时,以及社区对应时的注意点。

1.  patch制作

1.1 bug修正

bug修正时请注意以下几点:

  • 是否没有多余的注释。
  • 注释是否符合kernel doc format。
  • 是否include了多余的头文件。
  • 函数原型是否用了#ifdef。
  • 一个画面内不能显示#ifdef和#endif时,是否添加了/* CONFIG_NAME */ 这 样的注释。
  • 应该使用EXPORT_SYMBOL_GPL()的地方是否使用了EXPORT_SYMBOL()。
  • 使用scripts/checkpatch.pl检查一下。
  • 修正后是否再次编译并测试。
  • 修正后编译是否有warning。

1.2 生成patch

生成patch时请注意以下几点:

  • patch是否太大超过邮件服务器接收单封邮件的上限。
  • 一个patch只修正一个问题。类似patch分为多个作成系列,用[n/m]的形式发送。
  • 是否明确描述了patch的目的。patch被采用时,这些说明会直接放入Changelog。尤其是反映了社区的意见后再次投稿时容易忘记,请注意。
  • 是否对正确的版本制作的patch。
  • patch制作时的当前路径是否是新旧两个版本所在路径的父目录。
  • patch制作后是否应用并再次测试过。
  • 内核patch最好使用git生成。
  • diff的参数尽量使用 -Nurp

2.  patch推进

如果推进时已经有人正在社区中推进相关内容的话,请停止patch的提交,而只参与讨论。

2.1 问题再现方式

  • 请假设将要面对的社区的维护人员不能理解你在source层的解释,他只能理解更浅显的说明方式。
  • 再现的程序尽量是一组command的组合。
  • 如果有多种情况可以再现同一个bug的话,那请挑选最自然的方式。假设有个bug导致任何l打头的命令都不能使用。再现方法有多种,以下三种,哪个更好?
a.#lamnotacmd
b.#lshal
c.#ls

首先abc确实都能再现bug,但是a使用了一个不存在的命令,b使用了一个存在的命令,但是并不常用,显然c在实际应用中更加频繁和自然。c作为再现方式的话更容易被社区的维护人员理解和接受。

  • 如果这个bug有时会引起kernel panic,有时不会,那请不要忘了告诉社区kernel panic的事,这样可以引起重视。

2.2 邮件格式

  • 邮件的标题是否合适。
    • 投稿多个不同的patch时,必须分别采用不同的邮件标题。(标题为 patch名。例:”Subject:[PATCH] mm: fix a bug in container driver” → fix-a-bug-in-container-driver.patch)
    • 投稿一个系列的patch(为了一个目的制作的patch,因为太大的原因 而进行了分割)时,标题上必须添加编号。例:”Subject:[PATCH 1/4]…”
  • 邮件采用纯文本格式,并且每行字长小于72字节,不要使用英语以外的文字。
  • 邮件的签名不要使用公司统一的复杂签名。
  • 邮件作成后,直接另存为*.patch,用这个patch再试验一次是否能打上。因为社区维护人员大都直接把mail另存后作为patch使用。
  • 是否添加了必要的Signed-off-by, Reviewed-by, Tested-by。
  • Thunder Bird 发送patch时的配置(防止tab自动转换为空格):
    • 1 工具->邮件/新闻账户设置 选择“通讯录”去掉“以HTML格式编写消息”的选框
    • 2 在C:\Documents and Settings\YourName\Application Data\Thunderbird\Profiles\xxxxxx.default目录下生成user.js文件,文件内容如下
      • user_pref(”mailnews.wraplength”, 0);
      • user_pref(”mailnews.send_plaintext_flowed”, false);
    • 3 重启ThunderBird就可以了

2.3 和社区讨论

向社区投稿时请注意以下几点:

  • 投稿地址是否正确。(查看MAINTAINERS中相关人员后To or CC)
  • 讨论时回复邮件请不要置顶回复,应该在对方的邮件的正文中插入回复。

2.4 patch采用后的对应

patch经过社区review后,认为没有问题,就会被采用。 但是采用后,发生问题的可能性仍然存在。 比如,某个服务器制造商在自己的服务器上运用patch后,可能会由于硬件平台的差异,引起新的障害,这个时候大家就会讨论是否要把patch退回。 因此,出现这种问题后,需要迅速对应,否则很有可能被采用的patch又被退回。

Chrome OS for webook/adbook

Chrome OS = Linux Distribution – Kernel

At this moment Chrome OS is still a mystery, but we can imagine its future a bit and help Google to figure out what Chrome OS shouldn’t be.

What Chrome OS shouldn’t be:

  1. Another universal operating system of PC. We already have Windows, MAC, Fedora (Ubuntu, OpenSUSE…) and OpenSolaris. If Chrome OS only wants to use Linux kernel and do what XWindow and shell can do, it will fail because it depends on Chrome, which is a web browser, too much. Any of the above OSes can provides flexible interface and abundant applications, which Chrome OS doesn’t have. 
  2. Another mobile phone OS. Every mobile phone vender has its own favorite OS. We already have Maemo, Symbian, Android, RIM, etc. and Chrome OS even can’t support dialing.
  3. Another netbook or smartbook OS. Ooh NO. People buy netbook not only for Internet accessing. Most of them hope netbook can do something else without Internet connection.

To be consistent with Google’s strategy: do things that matter to a large number of people at scale. Chrome OS most likely to be a webook or an adbook OS. Of course, your editor coined the name of webook and adbook.

As your editor imagine webook is a mobile device that is

  1. A client or terminal of Cloud Computing Service.
  2. Light enough to handhold.
  3. Has Multi Network access interfaces. (Wi-Fi, LAN, etc)
  4. Price lowers than netbook. (Actually netbook can be eliminated by webook and notebook)
  5. Powerful graphic computing ability to replay the video form net.
  6. Plenty software support for Internet.
  7. High security.

We can use webook like that:

  1. Hold it when we take train, use it to check email, twitter and youtube when boring.
  2. Connect it to a monitor; use it as a pc, except we want to do development, or play hardware depended games.
  3. Put it on the car and as a GPS device.

And hope one day PSP can be OEMed by Chrome OS too.

—————–Below is Chinese Version—————–

—————–原创之中文版分隔线—————–

虽然目前Chrome OS对于我们还是一个谜,但是我们还是可以展开丰富的想象力来看看未来Chrome OS到底可以做些什么,也同时帮助Google考虑一下至少不能把Chrome OS做成什么。

Chrome OS不能成为:

  1. 另一个泛用性个人电脑操作系统。因为我们已经有了Windows, MAC, Fedora (Ubuntu, OpenSUSE…) 和OpenSolaris这些PC操作系统典范。如果Chrome OS只是想在Linux内核之上做XWindow和shell的工作的话,它肯定会失败,因为Chrome OS太多依赖Chrome这个浏览器,这会是此操作系统的先天局限性。以上的任何一款操作系统都能提供比Chrome OS更灵活的使用接口以及丰富的软件
  2. 另一个手机操作系统。每个手机制造商都有其面向的操作系统。目前Maemo, Symbian, Android, RIM等系统都表现非常出色。而Chrome OS甚至不支持电话功能。
  3. 另一个面向netbook 或 smartbook 的OS。千万不要。人们购买netbook不仅仅是为了访问互联网。很多人需要使用netbook来做很多其他和网络无关的事情。

为了顺应Google自己的战略: 只作能够影响很多人的事情。 Chrome OS更有可能会成为一个webook或adbook的操作系统。当然webook和adbook是笔者杜撰的名字。

笔者假想的webook是具有如下功能的移动设备:

作为访问云计算服务的一个客户端或终端。

  1. 轻便,利于携带。
  2. 具备多种网络接口。 (Wi-Fi, LAN等)
  3. 比上网本的价格更低。(实际上如果webook能够成长起来的话,必将和笔记本一起把上网本这个过渡产品取代)
  4. 足够的图像处理能力以满足网络视频的播放。
  5. 丰富的网络相关软件的支持。
  6. 高安全性。

那么我们可以像这样使用webook:

  1. 乘坐交通工具时用来收邮件,上twitter以及看youtube。
  2. 如果不是用来开发或玩要求比较高的游戏的话,把它连接到一个显示器,作为一台个人电脑使用。
  3. 作为一个车载GPS设备。

最后希望PSP有朝一日也能搭载Chrome OS。

VMware迎娶SpringSource

8月17日VMware和SpringSource宣布前者收购后者的消息。从SpringSource的CEO Rod Johnson的blog上可以看出,待嫁的新娘SpringSource对于未来的郎君VMware非常满意,并表态说,自己的未来蓝图和夫君的不谋而合,从现在开始翻开人生的第二篇章(Rod在blog上的文章标题哦),一定会在PasS这条路上走出一个美好的未来。虽然SpringSource的娘亲,风投Peter Fenton(这个娘家实力可大了,twitter,JBoss,Xensource都在/曾在他旗下)觉得自家的闺女如果再养个年把,应该能吸引到更多阔少,这次VMware的聘金给的少了点,但是机不可失,过了这个村没这个店,在半推半就的状态下把女儿给嫁了出去。

而VMware方面没有具体的表态。让人不禁暗自猜测此次收购的意图。

首先可以肯定的是VMware准备大张旗鼓做些什么了。种种证据表明VMware已经不甘心在虚拟化和云计算的革新大潮来临之际再继续做一个软件供应商了。VMware提出了PaaS(平台即服务),并具备了vSphere这把利剑,与此同时还顺手从Google签走了几个云和搜索API的大牛,看来VMware可以在平台供应商的舞台上大战身手了。

其次从竞争对手的角度来看,有三个竞争对手促使VMware先下手为强,

  1. RedHat,杀手锏是RHEL+JBOSS+虚拟化。全方位的解决方案,在PaaS中,特别是开源的PaaS领域占有极大优势。可是Mr. VMware和Ms. SpringSource的全新组合有可能改变未来PaaS领域的格局,带来更多创新和商机。SpringSource把之前带给用户的快捷,实用的服务开发和部署能力注入VMware的云技术中,使未来的用户可能在云平台上也能轻松搞定应用的编译,运行和管理。而RedHat如果对应不力的话,在这方面可能完全失去优势。
  2. 微软的Windows7将提供完美的虚拟化方案,而Visual Studio也将提供在云环境下的快速应用部署功能。在此形式下,如果VMware还不提供更接近最终用户的应用部署方案的话,势必会沦落为Windows平台上的一个虚拟软件供应商。而VMware选择了开源的Spring,也正是通过差异化竞争,防止老情人微软的醋意大发。
  3. Google App Engine,最近App Engine的宕机并没有让其fans失望,反而在稳步的走向PaaS的模范之路。VMware在和Google做生意的同时,也学习到了Google的战略思维,在自己不具备开发App Engine的实力时,出手收购了SpringSource。虽然一个搞Java,一个搞Python,看似互不影响。但是挖墙脚的事情总让人不踏实,而谁知道呢,说不定这样的人员流动是在Google的默许之下呢?

最后再看看SpringSource对社区的承诺。几乎每个社区支持的商业化开源软件在换东家时都会向社区承诺其江湖义气。MySQL不也是吗?但是嫁了人的姑娘,即使在郎君允许下可以和以前的哥们情人见面,但是多少多了些限制,跟新郎官的roadmap不符的事情可就千万不能做了。