编译器的艺术
在我们尝试解决glibc 线程问题的时候，我给Ulrich Drepper发了封email（他是Cygnus的一员并且在glibc的开发中举足轻重）。我在e-mail中提到了我们碰到的POSIX线程问题和我们在Enoch中使用pgcc来获得优化的性能。在他的回信中他这样提到（我解释一下）：“我们自己的包含在CodeFusion中的编译器制作的可执行代码比其他的一些编译器、比如pgcc编译出来的代码执行速度更快速。”显然我对测试测试Cygnus那帮家伙开发的神秘的“turbo”编译器非常有兴趣。
因此我申请拿到了一个Cygnus Codefusion 1.0的demo拷贝以便我可以对它的性能做一个测试。Omegadan和我对测试的结果很吃惊，它同Ulrich提到的那样出色。x86的后端提高了 90％的有关cpu-intersive的可执行文件的执行效率（比如bzip2）。几乎每一个程序都能从中获得至少10％的真实世界的性能提升，而我们所作的仅仅是换了一个编译器。Enoch的速度也因此获得了30％－40％的提升。同时性能也提高了不少，提升的幅度超过了我们以前把编译器从gcc切换到pgcc时提高的幅度。显然，在对这个编译器的测试后，我们很希望把这个编译器包含在Enoch中，有点幸运的是CodeFusion CD中的包含的源代码遵循的是GPL，这样在Enoch中使用这个编译器已经可以算是已经得到了完全的认可了..........，至少我们是这么想的。
异常事件的发生
为了能在Enoch中使用这个编译器，我给Cygnus的市场部主管发了一封电子邮件，但是期望中的“哦，拿去用好了，感谢使用我们的编译器！”这样的回复并没有收到，取而代之的是一句“虽然在技术上我们许可使用Cygnus的编译器，但是我们强烈建议不要在在Enoch中使用该编译器或是包含它的源代码。接着在我的回复中我问了他们这样一个问题：“既然不愿意让别人使用它的源代码，为什么还在以GPL的许可条例来发布它的源代码？”作为一个猜测，我觉得他们事实上是不想以GPL的方式来发布他们的源代码的，但是由于这个编译器是源自egcs（以GPL方式发布的），他们除了以GPL方式发布之外别无选择。
这是当某一个公司想使用开源的代码来生产私有产品这样的情况时，GPL如何阻止这样的事情发生的一个很好的例子。我比较有根据的一个猜测是 Cygnus担心我们使用这个编译器后将会打击到他们整个产品框架的销售，更加奇怪的是不管是他们的行销方案还是InfoWorld的预览中都没有提及包含在CodeFusion中的那个新的编译器，因为CodeFusion销售的是一套“development IDE”而不是一个编译器。
为了缓解一下他们那种偏执的态度，我提出了个建议，就是在我们的Enoch主页上放置上CodeFusion的签注文件并加上一个链接来刺激 CodeFusion的销售。从我个人的观点来说，我不认为一个“turbo”的Enoch会影响到CodeFusion（虽然它是一个IDE产品）的销售情况。但是我还在想方设法的令到他们愉快，比如告诉他们这个IDE的组件是一个商业化的产品，我们也并没希望或者有什么意图用Enoch来发行它。
我把这个（大方的）请求用电子邮件的方式发给了Cygnus，但是收到的确实另一个奇怪的回复。他们想得到所有我们关于“市场元素”方面的具有权威的权利（显然，这也包括了我们网站上的内容），真是太令人震惊了。Cyguns的营销团队似乎对Linux社区和GPL的运作一无所知，事到如今我终于决定终止与Cygnus彼此间的联系，因为再这样下去事情会变得怎么样谁都不知道。与此同时，我们为Enoch准备了两个版本，一个是内部的 “turbo”版，一个是公开的“non－turbo”版，其实就是把决定留在将来再去做。
但是几个月之后，他们就把CodeFusion x86的backend换成了gcc 2.95.2，现在不只是那些知道包含在CodeFusion CD中的“隐秘的GPL编译器”的这群人可以获益，几乎每一个人都可以从这个新的优秀的backend中获益了。然后我们还是决定继续前行，尽量使用 gcc来替代CodeFusion的编译器。在gcc 2.95.2已经越来越成熟的情况下，我们已经可以放开Cygnus了（同时，RedHat却为购买这个CodeFusion而花费了比较冤的一笔钱了。）（注：新的x86版本gcc 2.95.2的backend为新的Linux发行版提供了一开始我们提到的很重要的速度提升，它也为FreeBSD 4.0相对3.3.6版本速度上提升做出了很大的贡献。你注意到这两个提升的不同点吗？）
