另一方面，随着 Linux 在 Server 市场的所向披靡，微软又不得不接受这个现实，并不得不在自己的产品中支持 Linux。微软与 Linux 的关系让人觉得这得是精神多么分裂的人才能干出来的事啊。 2009 年，微软的 Hyper-V 的 Linux 驱动被发现包含了 GPL 代码，随后微软开源了该驱动，并对开源的代码使用了 GPL 版权。微软开源的这些代码主要是为了能在自己的 Hypervisor 虚拟机上更好的运行 Linux。显然，云计算与虚拟化的大热，以及 VMWare 的高利润率不可能不吸引到微软投入其中。 微软与 Novell 的合作(现在是 Attachmate，该合作刚刚续到 2016 年) 也是为了能够更好的在 Windows 与 Linux 的互操作性上提供支持，特别是虚拟化的环境下，比如在 Hyper-V 虚拟机上运行 SUSE Enterprise Linux Server。微软在今年早些时候宣布 Hyper-V 虚拟机将支持 CentOS，在刚刚结束的 OSCON 2011 上，微软又宣布 Hyper-V 将正式支持 RHEL。在虚拟化与云计算的大环境下，微软不得不考虑客户多系统的环境。 所有这些都是商业利益，不过在 Linux Kernel 的开发人员眼里，源代码才是最真实的。微软在让自己的代码进入官方 Kernel 的过程中，痛苦不堪。在 2009 年开放源代码并提交给 Kernel 开发人员之后，这些代码并没有直接进入官方 Kernel，而是在 staging tree 中接受 review，直到符合 Kernel 的代码标准为止。 显然，Windows 与 Linux 这两个各有 20 年历史的项目，代码上最直观的不同来自于编码风格。虽然 Linux Kernel 的开发人员都极其痛恨 Windows 的编码规范（DWORD, HANDLE 这些玩意儿），但让 Windows 的开发人员将这些代码一一改成符合 Linux 的编码规范，也不是件好差事。因此在最初的代码提交后，Microsoft 就没了下文，直到负责驱动部分代码维护的 Greg K.H 威胁将这些代码从 staging tree 中拿掉，微软才又开始慢慢的行动起来，不过进程仍然极其缓慢，直到这次 3.0 的发布。根据 LWN 的统计，微软的开发人员将最初提交的 20000 多行代码精简到了大约 15000 行代码。 因此微软这次对 Linux 3.0 的贡献主要集中在对之前开源驱动代码的清理与规范上，未来微软仍有可能对 Linux Kernel 有较大的贡献，因为这些代码仍然在 staging tree 中，仍然有一些问题需要解决才能正式的进入 Kernel，并且随着 Kernel 的发展，这些代码也需要不断维护。至于除此之外，微软会不会对 Linux Kernel 有更多贡献，除非微软开发自己的 Linux 发行版。 最后回到蛋糕身上，当你再次欣赏这个可爱的视频时，你会想到什么呢？ 我想到的是，前不久，当 Firefox 5.0 发布时，IE 团队也送上了祝贺的蛋糕。嗯，这是他们的老套路了。 |
