据市场调研机构的数据,在刚刚过去的六月份,Linux 桌面的全球市场份额突破了 2%——如果笔者没有记错的话,这是有史以来第一次达到 2%。

根据 Net Applications 的数据显示, 之前 Linux 的桌面市场份额一直徘徊在 1% 到 2% 之间,在六月份首度突破,达到了 2.02%。

Linux 桌面份额首破 2%

以下是 Linux 桌面份额在这两年来的变化

Linux 桌面份额变化

不过,要是据 W3Counter 的统计数据,这不是 Linux 桌面第一次突破 2% 份额。本月,Linux 的份额是 2.48%。而在之前几年,已经长期保持在 2% 以上的份额了。

需要说明的是,以上两家的统计数据都是依据浏览器对网站的访问进行统计的。

由于甲骨文Oracle在开源项目上的一些作为,以至于它成了开源界的嘲讽对象。在 2015 年旧金山举办的 JavaOne 大会上,前太阳微系统公司Sun Microsystems的 CEO Scott McNealy 出现在了 Java 20 周年纪念视频中,在那段视频中,他讽刺性的列出了“Java 开发者的 12 大噩梦”,其中第四条是“你喜欢开源和分享,但是你却在甲骨文工作。”这惹得在场的开发者们哄堂大笑,但从其中也可以看出甲骨文在开发者中间的形象。

下面列出了一些甲骨文在开源方面发生的一些事情:

2009 年 12 月

MySQL 的创造者 Ulf Michael “Monty” Widenius 向欧共体(欧盟前身)发起请愿,要求阻止甲骨文收购太阳微系统公司Sun Microsystems,其时,太阳微系统公司刚刚收购了 MySQL 公司一年。Widenius 预测,如果太阳微系统公司被收购,甲骨文有可能将 MySQL 的一部分闭源。

2010 年 1 月

甲骨文完成了对太阳微系统公司的收购。

2010 年 2 月

甲骨文从其产品路线图中排除了 OpenSolaris。

2010 年 3 月

太阳微系统公司的开源官 Simon Phipps 在两家公司合并时离开了该公司。

2010 年 4 月

Java 之父 James Gosling 离开了甲骨文,他后来称该公司“挑战了道德”。

2010 年 8 月

甲骨文内部备忘录告知员工,OpenSolaris 将会中止,Solaris 和 ZFS 也会“关闭”。

OpenSolaris 管理委员会解散。

“完全开放”的 OpenSolaris 和 ZFS 项目 Illumos  启动。

多名 MySQL 团队成员离开并加入了 Rackspace,参与到了 MySQL 分支 Drizzle 项目的开发。

2010 年 9 月

OpenOffice.org 社区的一些成员离开并创立了文档基金会The Document Foundation(TDF),并分支出了 LibreOffice 项目。他们邀请甲骨文加入文档基金会。

2010 年 10 月

甲骨文要求文档基金会成员离开 OpenOffice.org 项目,理由是“利益冲突”,并且拒绝加入文档基金会。

LibreOffice 正式成为替代 OpenOffice.org 的一个分支。

甲骨文闭源了 HPC 平台(以前叫做太阳网格计算引擎 Sun Grid Engine),转而开源维护 开放网格计算调度器Open Grid Scheduler项目。四个月后,整个网格计算团队离开并加入了 Univa。

2010 年 12 月

阿帕奇基金会Apache Foundation为其 Java 开源实现版本 Apache Harmony 提出了一个技术兼容配套方案,在甲骨文拒绝许可该方案之后,阿帕奇基金会辞去了 Java 社区进程Java Community Process(JCP)组织的执行董事席位。

2011 年 1 月

甲骨文申请了商标“Hudson”,这是一个开源的 Java 持续集成平台的名字(社区后来投票改名为“Jenkins”),甲骨文继续以它自己的名字“Hudson”开发该项目。

2011 年 4 月

甲骨文停止了 OpenOffice.org 和 OracleOpenOffice 的开发,两个月后,该公司将代码捐献给了阿帕奇基金会。

2011 年 9 月

甲骨文宣布它将发布 MySQL 的商业扩展,并且该项目将不再是完全开源的了,变成了“内核开源open core”模式。

2013 年 6 月

甲骨文改变了开源的伯克利 DBBerkeley DB(BDB)的许可证,从一个 BSD 风格的公开许可证变成了 Affero 通用公开许可证,它要求用户以 GPLv3 或 AGPL 许可证提供其应用的源代码给任何一个通过网络连接到他们的应用的人。这一举动被广泛认为是要么恐吓用户为其开发的应用购买商业许可,要么是想弄死伯克利 DBBerkeley DB(BDB)。


 

以上信息仅限于笔者收集到的部分,欢迎大家提交更多可信来源的信息来完善此文。

信息参考来源:arstechnica

(题图来自:zimbio.com)

你可能听说过类似的消息了,甲骨文公司不声不响地撤掉了一项社区技术的资金和开发人员支持,而许多消费者和企业合作伙伴已经在这项技术上投入了大把的时间并编写了大量的代码。究其原因也简单的很:这技术,不挣钱啊!

甲骨文干这事儿也不是第一次了,对于那些被甲骨文收购的开源项目,这样的结局似乎成了一种宿命。从 OpenSolaris 到 OpenOffice.org,都是这样的命运。这回轮到了 Java 头上,更准确的说,是 Java 企业版Java Enterprise Edition(Java EE)。OpenSolaris 和 OpenOffice.org 两个名字大概很多人都没听说过,但 Java EE 可是每个人都接触过的,作为一种服务器端技术,Java EE 在全世界驱动着数以百万的网站和企业应用。甚至在许多不是基于 Java 的应用中,Java EE 也扮演着不可或缺的角色。

甲骨文的律师已经就安卓系统 Davlik 编程语言的 Java 接口问题在法庭上和谷歌打了好几个月的官司了。这期间,甲骨文的 Java 开发进度明显减慢了,Java EE 更是完全处于停滞状态。这完全停止开发进度让依赖 Java 平台的企业和 Java 社区里的许多用户都深感不安,要知道,这些人中有许多就是甲骨文最大的几个客户。

一些曾在甲骨文参与 Java EE 开发的员工曾在 Java 社区上透露,他们已经被分配到了别的部门。一些 Java EE 开发者们想要自立门户建设 Java 平台的言论也不是一两天了,他们想要自己实现 Java 平台,摆脱对甲骨文手中这个 20 年历史的软件平台的依赖。尽管如此,尽管公司内负责管理 Java 标准的成员明确要求甲骨文就 Java EE 的未来做出规划,甲骨文仍然是一言不发。

一位独立选举的 Java 社区进程执行委员会Java Community Process Executive Committee的成员 Geir Magnusson 就表示:“甲骨文在玩火。说来也是讽刺,现在竟然有一家公司让我们怀念起 Sun 来。”(译注:Sun 是最初开发 Java EE 的公司,后来在 2009 年被甲骨文收购。)Magnusson 觉得去猜测甲骨文的动机根本不可能,因为管理层的决策方式非常不透明。但如果非要从那些与甲骨文内部 Java 开发团队走得近的人透露的消息猜一下的话,可能甲骨文是要放弃 Java 了,毕竟它也不是第一次做这种事了。况且在公司正在法庭上和谷歌打官司的时候,就已经开始减少对 Java EE 开发的资金和人力支持了。

甲骨文对此事出奇的沉默,这让许多 Java 社区的成员担心甲骨文是不是不只是放弃 Java EE,而是要扔掉整个 Java 平台。一个自称“Java EE 守护者Java EE Guardians”的组织正在试着通过公共关系和联名请愿的方式给甲骨文施压,让它要么重启 Java EE 的开发,要么就让 Java EE 自由。但让甲骨文放弃 Java 这一大知识产权希望实在是渺茫,特别是现在谷歌在法庭上打赢了官司,甲骨文还准备再次上诉。

曾经在甲骨文从事 Java 宣传工作的 Reza Rahman 担任“Java EE 守护者”的发言人,他说道:“我们目前从甲骨文听到的唯一消息是来自 Java EE 规范制定团队的,他们说目前无法继续进行自己的工作。然而他们并没有说他们现在正在干什么,或者在开发什么。”

Rahman 相信甲骨文对 Java 不管不问会对全球 IT 业产生巨大冲击,无论长期还是短期都是这样。他解释道:“Java 和 Java EE 是普适的技术,全球 IT 业的许多内容都基于它。整个 Java 生态系统是在过去的 20 年间逐渐形成的,它的开放标准受到了多家供应商的支持。可以说许多人的生计就依赖于 Java 了。”如果没有继续的资金支持和发展,整个 Java 生态系统的每个部件都会逐渐变得落后,全球 IT 行业也会随之减慢发展的脚步,直至找到合适的 Java 替代品。

当人们联系到甲骨文 Java 开发团队成员以及甲骨文客户,想要他们提供相关信息的时候,都受到了拒绝。他们大多害怕甲骨文会追究他们的法律责任。甲骨文的媒体部门也对 Java 的相关话题三缄其口,邮件和电话一概不回。

甲骨文作为商人的本性被人们编成了许多笑话,比如在“12 个 Java 开发者的噩梦”评选中获得第四名的笑话是“你热爱开源运动、热爱分享,但你在甲骨文工作。”

封锁

人们希望甲骨文能够改变颁发 Java 使用许可的方式,但都遭到了拒绝。最近的一次尝试来自 Java 社区进程组织Java Community Process(JCP),也在今年被甲骨文的律师们否决了。公司的法律团队表明,在当下谷歌的诉讼还没有结束的状态下,甲骨文是不会对许可方式作出改变的。

与此同时,JCP 为监督 Java 标准变化所做的努力也逐渐被甲骨文的 OpenJDK 开发人员破坏掉了。OpenJDK 的开发人员在没有联系 JCP 的情况下直接给 Java 平台添加了新的功能。JCP 和非甲骨文员工的 OpenJDK 社区成员都对这种行为感到担忧,如果将来 JCP 被甲骨文架空,那就不好玩了。来自 JCP 的 Milinkovich 表示,随着 OpenJDK 的开发成果越来越多,同样是开源项目的一部分,JCP 作为 Java 行业的领军组织之一,其地位也受到了威胁。但 Milinkovich 也说道他目前还不担心这一点:“作为开源社区的组织者之一,我相信开源的力量。我们需要澄清 OpenJDK 社区的角色,以及他们会给开源社区带来怎样的贡献。当然,对 Java 标准的影响也要说清楚才行。”

与此相比,Java EE 可能取消的议论显得更加激烈。自打甲骨文刚开始减少对 Java EE 的开源版本 GlassFish 的资金和技术支持,人们的不满就不绝于耳。即便没有了商业支持,Open Glassfish 仍然会在甲骨文员工的主导下进行开发,并于 2013 年 6 月 12 日和 Java EE 7 一同发布。在随后的一年里,Java EE 有进步的,在 2014 年,JCP 处理的关于 Java 标准的请求大多是关于 Java EE 的。而在同年的 JavaOne 峰会上,甲骨文和 JCP 更是共同宣布了 Java EE 8 的开发。他们设立了一个目标,那就是在 2016 年 9 月份完成标准制定。

云服务变成了新宠

在 2015 年,甲骨文加快了将工作重心转到云服务销售上的速度,Java 开发部门的预算再次受到削减,特别是 Java EE 和 GlassFish 团队,削减更是严重。与此同时,甲骨文宣称 Java EE 8 的标准制定工作要推迟到 2017 年上半年才能完成

在 2015 年八月份,Java EE 团队正在紧张地处理一项涉及多个开发项目的问题时,却突然被公司叫停。甲骨文总裁发现数据库等中间件产品的销售额在 2016 年第二季度出现了下降后,决定关闭 Java EE 的大部分开发进程。这一举动吹响了在甲骨文董事们的领导下,全公司转向以云服务为中心的号角。甲骨文前高级副总裁 Cameron Purdy 因为主张重新给 Java EE 团队注资而被公司董事会革职。

甲骨文的预算削减给那些密切注视 Java 项目,特别是 Java EE 的人带来了很大影响。Java 团队解决的问题数量出现了明显的下降, 而提交到各个项目的代码数量也比以前少的多了。原定于 2016 年第一季度推出的 Java Server Faces 新标准也没有了消息,具体推迟到什么时候推出也没有信。

在 4 月份,JCP 执行委员会终于正式讨论了 Java EE 开发停滞的问题。代表伦敦 Java 社区的 Martijn Verburg 表示 Java EE 的进程在 11 月份就有停滞的迹象。他说:“现在看来,甲骨文旗下的 Java EE JSR 开发已经基本停滞,或者是完全停止了。一些甲骨文内领导相关标准开发的人已经公开承认自己已经被公司分派到其它项目上去,没有时间开发 JSR 了。”

开源运动的好机会

甲骨文对此举没有做任何解释,这无疑给 Java 社区和生态系统带来了很大的负面影响。Verburg 表示:“一些主张独立的人已经开始讨论重拾 Java EE 开发,以及考虑更换 Java EE 领导权的问题。”没有了甲骨文的表态,各个公司只能根据自己的现有框架去应对客户们的新需求,这无疑会让 Java 社区变得更加分散。

Verburg 声明:“我们需要甲骨文的官方消息!”如果甲骨文对 JCP 关于 Java EE 的请求不管不问,就表明他们根本不重视 JCP。

截至目前,甲骨文仍然没有发布任何公开声明。大部分社区成员依然很失望。即便是一些金融服务公司的 JCP 代表都对此表示担忧。“Java EE 守护者”团队建设了一个抗议网站并组织了一次请愿活动。在最近的 JCP 执行委员会会议上,Verburg 更是感叹道:“甲骨文对此不管不问,显然是对 Java 生态系统没兴趣了。”他同时表示自己的公司不会再依赖于 Java EE,因为未来甲骨文随时可能叫停 Java EE 的开发。多么讽刺啊,JCP 委员会成员公开表示他们不能再依赖于 Java EE 了。

Milinkovich 坦言甲骨文终究还是那个甲骨文,他评论道:“甲骨文的一大特点就是作出决定后坚决执行,有人说这是优点,也有人说这是缺点。因为甲骨文公司很庞大,这些决定需要一段时间才能生效。我觉得甲骨文在推动 JavaOne 开发的同时应该给 Java EE 制定好路线图,不然就太说不过去了。”

残局

我们有很多理由相信甲骨文不会让 Java EE 彻底消失,其中一个就是他们自家的许多产品也依赖于 Java EE。尽管 Java EE 对甲骨文来说不如 Java SE 有战略意义,但它仍然直接或间接地为甲骨文 70% 的软件授权和支持收入做出了贡献。

来自“Java EE 守护者”组织的 Rahman 表示他希望甲骨文能够对舆论压力做出反应。他说守护者组织的活动才开展了几个星期,现在就说甲骨文永远不会有反应还为时尚早。如果甲骨文现在回心转意的话,事情还没有发展到无可救药的地步。其他人则不认为甲骨文会做出积极回应,Magnusson 表示甲骨文不是一个习惯被别人推来推去的公司。

当然,甲骨文完全可以砍掉 Java EE 而且不让任何其他人接手。这种动作的影响远远不止于企业用户,而是会动摇甲骨文对 Java 整体的信心,要知道 Java 现在可是物联网的最佳选择。

Rahman 说道,甲骨文摆脱 Java 的最好办法就是把 Java 平台整个捐给 Eclipse Foundation、Apache、ECMA 或者 W3C 这样的组织。这样一来希望继续使用 Java 的用户和企业还可以接着开发。但连他自己都怀疑甲骨文决定放弃 Java EE 之后还会这么好心的把它捐掉?

Java 启示录

如果甲骨文真的决定走“毁灭一切”的路,本来就落后的安全补丁开发就会完全停止。数以千计使用 Java EE 的服务器和云服务都会受到威胁,他们最终不得不替换掉植入的 Java EE 组件,或许那些抛弃甲骨文 JCP 的公司会出资开发一个新的开源项目来替代 Java。许多公司已经在考虑这种情况,作为最后一根稻草,其它厂商已经开始讨论开发一套独立的 Java API 的方案。如果事情真的走到这一步,JCP 也会加入他们。

鉴于这些原因,甲骨文更有可能选择让 Java 社区进程委员会的成员来领导 Java EE 的开发,而自己则保留 Java SE 的领导权。因为 Java EE 依赖于 Java SE 核心,这样一来甲骨文依然保有对 Java 平台的控制权。即便 IBM 或 Red Hat 接管了 Java EE 标准制定,也不能威胁到甲骨文的地位。 

同时 Rahman 相信继续开发 Java EE 会给甲骨文带来更多利润。他认为能否成功的管理 Java 是决定甲骨文在云服务中取得开发者、顾客以及行业信任的关键。作为成功推广 Java 的公司,如果能亲手把 Java 带入云服务,将会是战略性的胜利。但话说回来,想要甲骨文为了商誉继续开发 Java EE 恐怕比较困难。特别是现在公司正和谷歌在法庭上战的不可开交,此时动摇对 Java 这一知识产权的所有权不是在打自己的脸吗?请愿活动估计也会收效甚微,前 Sun 公司首席开源官chief open source officer直截了当地道:“一场不能威胁甲骨文营利的请愿活动是没有效果的。”

考虑到现在甲骨文的利润额继续上升,而公司的两名联合首席执行官目前是科技行业薪资最高的两名高管,想要赢得他们的注意力相当困难。在这一切有所改变之前,我们唯一能确定的就是 Java EE 会一直站在悬崖边上。

经过了六个月的努力,发布了 4 个 beta 版本、2 个 RC 版本,Rails 5.0 终于正式发布了!

Rails 社区的公告中说,“这是由数百位贡献者,历经上千次提交而达成的一个新的里程碑,Rails 5.0 无疑是迄今为止最好、最完善的 Rails 版本。 经过了这么久的发展,社区依然具有如此活力,感谢每一位帮助过我们的人们!”

在本次发布的 Rails 5.0 中,有两大亮点:

Action Cable

Action Cable 是一个重新打造的框架,用于在 Rails 中控制 WebSocket。它是一个完全整合的解决方案,包括了连接管理、用于服务器端处理的 channel 层以及客户端交互的 JavaScript 层。它增加了易用性,让设计类似聊天、提示、现场等实时功能更加容易。如果你想看看它的具体表现,你可以看看它在 Basecamp 3 强大的表现。

Action Cable 中最棒的地方是你可以在你的 WebSocket 里面访问你的整个 Active Record 和 PORO 域模型。如果你想为 WebSocket 响应复用服务器端模板的话,甚至还有一个全新打造的 ActionController::Renderer 系统可以使你在控制器之外渲染你的模板。

在开发模式时,Action Cable 可以运行在你的应用内部,你只需要将默认的开发服务器从 Webrick 切换到 Puma 即可。在产品环境中,你也可以让 Action Cable 运行自己的服务器。

API 模式

Rails 不仅是你使用服务器端 HTML 模板渲染来构建全栈应用的最佳选择,而且也是开发客户端 JavaScript 或原生应用的好伴侣,只需要用 JSON 和后端通讯即可。新推出的 -api 模式可以让你使用 rails new backend --api 创建一个新的 Rails 应用,这样会采用 JSON 而不是 HTML 作为应用骨架和配置。

这个功能还需要更多的完善,不过这是一个良好的开端。

其它亮点

  • 不用再使用 rake 命令了,统一采用一个  rails 命令即可。比如现在用 bin/rails db:migrate 取代了 bin/rake db:migrate
  • 新的属性 API
  • 生成器创建的所有模型都以 ApplicationRecord 为默认父类。
  • 等等……

具体你应该看看各个部分的变更日志,都有不少变化:

更多的细节,你可以看看完整的 Rails 5.0 发布公告,Claudio B. 做了一篇简短的演示来介绍了他喜欢的一些改进(和一些功能的去除),DHH 本人也录制了一段基础性的介绍视频: 让我们用 Rails 5 打造一个博客 。

此外要注意,根据 Rails 的维护策略,Rails 5.0 的发布代表着以后将只会对 5.0.x 进行错误修复,安全问题的修复会包括 5.0.x 和 4.2.x,(如果 5.1 出来了就是 5.1.x、5.0.x 和 4.2.x)。也就是说,4.1.x 及其以下版本原则上不支持了!而且,Ruby 2.2.2 及以上版本也将仅支持 Rails 5.0 及以上版本。

(题图来自:mobiloitte.com)

今日关注

据调查机构 Net Applications 的报告, Google Chrome 即将在桌面端取得 50% 的市场占有率。而自从微软决定在 Windows 10 中采用新的 Edge 浏览器(5%)起,IE 的份额就越来越低,现在只略高于 30%。Firefox 将近 8%。

Google Chrom 48.65%,Internet Explorer 31.65%

图文摘要

作为现存的最古老的 Linux 发行版, 也是笔者用过的第一个 Linux 发行版,Slackware Linux 刚刚发布了 14.2。作为坚守传统的代表,该发行版是目前少数的仍旧不使用 systemd 的主流 Linux 发行版之一。虽然如此,这并不代表 Slackware 很陈旧,这次发布的新版本中使用了 Linux 4.4 内核、支持  LLVM/Clang 的 GCC 5.3 编译器、 PHP 5.6.23、Python 2.7.11 等。

著名的 Linux 滚动发行版例行发布了新的 ISO 镜像:Arch Linux 2016.07.01。新用户可以用它安装,一滚到位。

著名的微型 Linux 发行版 4MLinux 发布了 18.0。