为什么Ubuntu的Unity 8开发需要这么长时间?

译文
系统 Linux 游戏开发
时至今日一些Linux用户一直存在疑惑:为什么Unity 8至今还没有正式发行?上述疑问来自于最近发布在Linux Reddit网站上的一个帖子;这个网站上的用户分享了他们对于为什么Unity 8仍尚未发行其正式版本问题的思考。

[[174640]]

【51CTO.com快译】Ubuntu知名发行商Canonical公司已经在它发行的Ubuntu 16.10中包含了Unity 8桌面的一个预览版本。但是,时至今日一些Linux用户一直存在疑惑:为什么Unity 8至今还没有正式发行?

上述疑问来自于最近发布在Linux Reddit网站上的一个帖子;这个网站上的用户分享了他们对于为什么Unity 8仍尚未发行其正式版本问题的思考。有关内容如下:

Linuxode:“Canonical公司有很多很有才华的开发人员和大量开发资源。更不用说作为Linux世界主要成员的Ubuntu——她应该会吸引来自于企业外界的大量参与者。即使情况如此,Unity 8的开发速度似乎仍以蜗牛爬行般进行中。那么,到底是什么原因阻碍Canonical公司延迟Unity 8正式版的发行呢?”

Blackout24:“新的显示服务器开发,协议开发,外壳程序开发,输入服务器开发,以及他们不得不为仅由自己所使用的解决方案而维护的所有补丁程序;再加上其他几十个Canonical项目……太多的任务,也够难为这个小公司的了。”

Rbrownsuse:“直截了当地说吧,因为只有Canonical一家小公司在做它。当然,不只是Unity 8这一个工程,还有Mir这个工程,因为显示服务器正是依赖于Mir项目。这两个可都是巨大的工程项目。

这种任务通常是需要一个大规模的软件工程部门来承担的(以微软和甲骨文公司的规模的话,可能需要投入500多个软件开发人员进行开发,而这是Canonical公司所根本无法实现的)。

因此,合乎逻辑的选择是与其他公司共同协作开发。这样才符合典型的开源软件的开发方式。而且,这也是Red Hat、SUSE、Collabora及其他自由/开源软件公司所遵循的开发模式,即把这些公司的解决方案组合到一起,从而以一种可负担得起的、可持续的方式开发。

但看起来,这也是Canonical公司似乎不容易遵循的一种开发模式——他们似乎总是愿意把一些开源生态系统中的可用项目纳入到他们自己的项目中。但就开源社区贡献方面来说,他们似乎只愿意做他们自己想做的事。

从我的角度来看,他们上面这种做法真正妨碍了如Mir和Unity 8这些项目的开发进度;这也正与像Wayland & GNOME这些可以选择的替代方案形成对比——这些方案其实可以对整个项目的进度起到大的推动作用。”

Uoou:“我认为Unity 8正式版本迟迟未发行的原因之一是,他们很难找到符合贡献者许可证协议(ContributorLicenseAgreement,简称“CLA”)的适合于他们的项目的开源合作者。”

Rbrownsuse:“那当然是为什么我有可能永远不会向Canonicals贡献项目的原因。

我的一条非常强烈的个人意见是,我将永远不会签署CLA协议,因为这种类型的开源协议授予许可证持有人的权利是,他可以基于另一种不同的许可协议来重新授权我的工作——而这根本不是我的工作所想遵循的许可。

对我来说,足够幸运的是我的公司老板在这些问题上也持有与我相似的观点。这并不会妨碍自己的任何项目使用CLA许可,从而避免了通过CLA许可向开源社区贡献项目;因此,我也不可能还需要为受CLA许可妨碍的项目进行工作。”

Boomboomsubban:“他们试图仅凭他们自己的力量来取代和改进已发展了三十年的X11。”

Uoou:“我大体上同意您的看法,但我认为他们是有足够信心的。我理解自由软件基金会(FSF)的CLA协议,当然我也很清楚为什么他们需要这种协议并且坚信他们能够坚持到底(这并不困难,因为这是他们企业形成和存在的理由)。

不过,Canonical公司选择CLA的确是个问题,因为我并不太了解为什么他们选择这种许可(或者,更糟糕的是,也许我也是这样做的)。”

Sherba800:“谁说Canonical公司拥有很多很有才华的程序员?我至今是没有发现。不过,我建议:Canonical团队应该针对是支持引入现成的Wayland项目还是自行开发Mir项目进行投票表决,因为在使用systemd工具的情况下系统应该仍然能够工作。”

Mordiken:“用户很多并不意味着有大量的开源贡献者。对于Canonical公司,情况更是如此;由于他们的社区管理混乱、使用了糟糕的决策以及后续的由其竞争对手(和各自的粉丝团)发起的FUD(指攻击开源软件的「恐惧、不确定、怀疑」活动),致使他们疏远了本来可以成为他们极有潜力的用户群的很大一部分人。”

Bkor:“每个人都非常同意引入Wayland项目,包括Canonical公司员工自己。然后,由于他们另有决定,于是开始了Mir项目的开发。在6个多月以后,他们才最终告诉其他人他们所做的决定。他们选择独自开发这个项目而忽略引入其他人的贡献。”

Ventomareiro:“Mir项目以GPLv3协议发布,从而使得项目的版权归属于Canonical公司;这一事实给人们带来某种预测——Canonical公司想开辟一条新的业务线,从而想以一种不同的许可协议把Mir项目提供给手机制造商使用。(并不是说我看到了什么毛病,这毕竟是他们的代码)。”

有关这方面的更详细的信息,请参考:Reddit网站(https://www.reddit.com/r/linux/comments/592xjk/why_is_unity_8_development_taking_so_long/)。

DistroWatch评论Ubuntu 16.10

Ubuntu 16.10已经发布一段时间了,而有关评论仍然不断地针对这款最近版本的 Ubuntu展开。作为提供全球数百个Linux发行版情报和他们之间比较的权威网站,DistroWatch上发布了一篇针对Ubuntu 16.10的评论,评论中说它是一款“坚固的、闪亮的发行版”。

Joshua Allen Holm为DistroWatch撰写的报告中说:

乍一看,Ubuntu 16.10几乎没有什么改变。它看起来几乎完全像其他每次最近发布的Ubuntu版本,随同发行的应用程序与以往人们期望看到的一样。还有一个更新的4.8版本的Linux内核;至于火狐浏览器Firefox、雷鸟Thunderbird、LibreOffice以及其他的人们希望看到的应用程序等都存在,而且都比Ubuntu 160.4 LTS发行时携带的版本新。因为我所有的计算机都安装了英特尔图形加速卡,所以我无法亲自测试看看是否当前的16.10版本中的更新的程序包修复了或改善了Ubuntu 160.4 LTS发行时与AMD图形加速卡有关的问题。

最大的变化来自于使用GNOME 3.20的应用程序的更新。新版本的Ubuntu软件,其实就是GNOME软件3.20版本的更名,提供了更加流畅的软件安装体验。当你切换到GNOME文件的3.20发行版本(又称「Nautilus」)时,你会注意到其中发生了不少变化,其中许多变化都比GNOME软件的改善更为吸人注目。现在,这些文件都使用了现代GNOME应用程序中所具有的单一的全局菜单特征。

Unity 8具有很大的潜力。尝试过后我很喜欢,并真心希望Unity 8能够出现在下一个LTS版本的Ubuntu中,因为它确实提供了很多亮点。然而,包含在Ubuntu 16.10中的开发人员预览版还远没有准备好,我几乎怀疑它默认包括在此版本中的唯一原因是为了展示此发布中提供了桌面部分的新功能而吸引用户。

总之,Ubuntu 16.10是一个坚固的、亮点汇集的、可用的Linux发行版。然而,相对于以前的16.04 LTS版本并没有太多的推荐理由。仅有几处调整和一些略新一些的软件包,但是没有什么惊天动地的发行。唯一令人信服的升级理由是,如果恰好Ubuntu 16.10修复了你正在使用Ubuntu 160.4 LTS时出现的问题。即便如此,Ubuntu 16.10中并没有大的问题;所以,如果你是那种总想使用最新版本的软件包的人,那么你可以进行升级。

更多的相关信息,请参考DistroWatch(http://distrowatch.com/weekly.php?issue=20161024#ubuntu)。

原文标题: Why is Ubuntu's Unity 8 development taking so long?,作者: Jim Lynch

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

责任编辑:武晓燕 来源: 51CTO.com
相关推荐

2019-12-18 16:05:57

Python编程语言代码

2020-03-02 16:59:58

数据恢复微盟删库

2016-03-16 10:43:08

项目时间

2017-11-07 11:01:51

服务器持续工作

2020-11-19 15:34:47

前端招聘开发

2011-03-07 13:01:50

2011-09-07 17:00:51

Ubuntussh

2022-01-23 16:23:43

数字化转型人工智能数据

2016-05-12 10:55:46

UbuntuUnity 8效率

2018-08-16 08:03:21

Python语言解释器

2020-02-27 15:44:41

Nginx服务器反向代理

2013-03-04 10:10:36

WebKit浏览器

2024-02-26 21:15:20

Kafka缓存参数

2022-06-02 08:03:19

PyCharmPython代码

2019-08-30 14:58:47

JavaScript程序员编程语言

2018-11-20 09:25:00

2022-06-13 21:52:02

CDN网络节点

2020-02-27 21:03:30

调度器架构效率

2020-11-09 15:12:13

开发技能代码

2016-12-28 11:28:19

.NET反射
点赞
收藏

51CTO技术栈公众号