| 你知道，如果你继续你的生活，你可能就会错过，但是死灰正在复燃：KDE和GNOME继续有几分不和，而Canonical直接支持KDE。正如KDE Aaron Seigo的解释,问题的中心是GNOME缺乏合作。 不过在我们理解Seigo之前，我想关注Mark Shuttleworth。他的博客上一篇冗长的文章中，他解释说，虽然Canonical在GNOME的保护下着手创建Unity作为GNOME的外壳，但是他们想使用友好的GNOME技术，并且，如果他们选择建立自己的东西，它会要求“实质性审查”。Canonical想在GNOME内部建立竞争，而不是取代GNOME。 “我们已经失败了 “。Shuttleworth坦率地总结道，“ 我看到Gnome内部的多种语言和多种决策，是基于Unity将与Gnome竞争的想法，而不是Gnome内部的竞争。” 根据Shuttleworth说，一个最好的例子 (还有Seigo，但是我们等会说他）是状态栏通知器（Canonical说是应用指示灯 ），该通知器现在是FreeDesktop.org标准，已经被Canonical自己的Unity和KDE采用。然而GNOME, 虽然第一次公开了这个想法，但是不久后拒绝了。 至少根据Shuttleworth一人的观点可见，拒绝背后的理由是，GNOME视Unity为竞争对手；于是，由Unity催生的技术——不管它们有多大的潜力——都是一种威胁，而非一份礼物。“它不与gnome-shell兼容”是GNOME给出的理由；考虑到那一API没有被以一个完整的部分推入GNOME，这完全是一个胡扯的理由。事实上，该API仅仅只是作为一个外部依赖被推出，以使运行在其他平台上的GNOME应用能够让我们误以为，该API是可用的。“ “因此拒绝这些API的主要理由，用最好的话说吧，是一个之前从未用来过拒绝任何外部依赖请求的理由：‘它不同于Gnome’。这句话之中有一些更深的含义隐藏：‘它与Gnome之内某人恣意追求的一种完美相悖’，” Shuttleworth论述道。 那么，其基本目标似乎是要阻止GNOME应用开发人员支持这个API—–但未能成功，根据Shuttleworth,因为开发人员无论如何已经拾起了API，无论GNOME喜欢与否。 “这个单一的声明让我心碎的是GNOME的核心价值观的结尾：说得很清楚：代码谈判，”Shuttleworth进一步明确，“这里我们的API是现实的，测试过的代码，与许多Gnome的补丁一起可用，并且实施了一个已经在FreeDesktop.org广为讨论的细则。这是真实的代码。但是因为某人—–一个Gnome Shell 设计者—–想探讨其他的想法而被禁止，而那个想法是在当时根本没有有效代码时的想法是诞生的。” 但是还不尽然。这个API的工作，和Canonical的愿景， 在2008 ux hackfest大会时已经向GNOME Shell设计者做了展示。 “[Jon] McCann否认了解过，但是显然我方那时与他谈论过这个问题，我被告知进行过谈话，而且我们收到了认可，这项工作将是‘对外壳一个有价值的贡献’ ”。Shuttleworth 回忆说，“显然，到提交时，McCann认为这个认可不具约束力。他在另一专家组的兴趣伪造了那个认可及现存于FreeDesktop.org 的谈论和规范。” KDE的确协调了与状态通知栏的工作，因此， KDE 应用在Unity‘刚好正常’，一切源于API 已经成为一个标准被KDE采用。 根据Shuttleworth，目前与GNOME的运行还有一个主要的问题。虽然捐助方和开发者的尾巴很美好，但是其领导龙头错了。“我直说我感觉到了善良的Gnome贡献者得尾巴，Gnome 应用被一个决策过程辜负了，并且已经让竞争态势减弱了Gnome本身的范围。”他写道“没有进入‘核心’的理念必须努力垂死挣扎，否则很难获得氧气。你可以问问Zeitgeist 部门。” “领导一个项目别无他法。土方法就是让这个失去了伟大人民的环境以不同方式向世界开放。这是最基本的。比如Unity。”他补充道。 |
