赞
踩
前文提到,Monty 得知 Oracle 收购 Sun 的提案得到了美国政府的支持后,发动社区用户向欧盟委员会请愿,希望通过反垄断的名义让 Oracle 知难而退,进而实现剥离 MySQL 的目的。而 Oracle 为了得到欧盟委员会的许可,迅速提出了十条针对 MySQL 生态厂商和用户的承诺,最终获得了欧盟的同意,于 2010 年初完成了交易。
那么,Oracle 完成收购后是如何处置 Sun 的核心资产的呢?让我们将视线稍微拉远一点,看看后面发生了什么事情。
Oracle 是一个极其关注技术竞争力和商业回报的公司,这也决定了它在开源方面采取的动作会非常保守,甚至可以说倒退。Oracle 关闭 OpenSolaris 开源项目之前,内部漏出了一些邮件,从中可以看出 Oracle 的决策逻辑:
致 Oracle Solaris 工程团队:
今天,我们将宣布一系列关于 Solaris 11 发展路径的决策,并回答有关开源、开放开发、软件和二进制许可证的关键问题,以及开发者和早期采用者在 Solaris 11 2011年发布之前如何使用 Solaris 11 技术的问题。
众所周知,“OpenSolaris”一词通常被用来泛指一系列源代码、一个开发模型、一个网站、一个标志、一个二进制发布版本、一个源代码许可证、一个社区以及许多其他相关事物。因此,从组织和商业角度考虑每个问题,并确定正确的下一步行动需要一些时间。因此,请仔细阅读这里的所有细节。我们将首先讨论我们的策略,然后是实施该策略的政策和流程的决策和变化。
Solaris 策略
Solaris 是第一大企业级操作系统。我们在今天的 Solaris 上拥有领先的商业应用份额,包括 SPARC 和 x64。我们的应用基础是 AIX 和 HP-UX 的两倍多。我们的品牌代表创新、品质、安全和信任,这是基于我们对 Solaris 操作系统工程 20 年的投资。
从商业角度看,我们对 Solaris 工程上投资目的是推动我们的整体服务器业务,包括 SPARC 和 x64,并推动由 Oracle 组合中多个组件集成带来的业务优势。这包括将我们的服务器与我们的存储、我们的交换机、Oracle 应用与 Solaris 结合起来,以及由这些组合带来的服务体验的效果。总之,Solaris 推动了以数十亿美元计的整体业务,并具有显著的增长潜力。
我们正在增加对 Solaris 的投资,包括从整个行业招聘操作系统专家,这是我们对这些目标承诺的标志。Solaris 不是我们外包给其他人的东西,它不是某个第三方技术的组装,也不是仅供维护的产品。我们期望业内顶尖的操作系统工程师,即你们所有人,都能创造并交付创新,继续使 Solaris 独一无二、有区别性,并对我们的客户及我们的业务产生价值。
Solaris 必须作为 Oracle 企业级客户的最佳操作系统而存在。我们希望所有人都认为“如果要运行的话,它就应该运行在 Solaris 上。”这就是 Solaris 品牌。这就是可扩展性重要的地方,不仅仅是几个 CPU 插槽和几个 GB 的 DRAM。这就是为什么我们可靠地交付数百万 IOPS 的存储、网络和 Infiniband。这就是为什么我们在文件和数据管理、安全和命名空间隔离、故障管理和可观测性方面具有独特属性。我们还希望我们的客户知道,Solaris 将继续是新想法和新技术的来源——这些技术简化了他们的业务并优化了他们的应用程序。这就是为什么 Solaris 10 是有史以来最具创新性的操作系统发布。同样的关注点将推动 Solaris 11 中一系列新的创新。
为了使 Solaris 成为 Oracle 完整和开放组合中最佳的操作系统,它必须在其他服务器硬件上运行良好,并且执行每个应用程序,同时为我们的硬件和我们的应用程序提供独特的优化。这是 Oracle 完整、开放和集成策略的核心价值主张。这些是互补而非矛盾的目标,我们将通过适当的设计和工程实现这些目标。
Solaris 的增长机会从未如此之大。例如,约有 40% 的 Oracle 企业客户使用 Solaris,这意味着我们仅在顶级客户中就有 60% 的增长机会。就绝对数字而言,仅在北美就有 130,000 个 Oracle 客户尚未使用我们的服务器和存储,全球客户基础为 350,000(之前的 Sun 基础约为 35,000)。作为一个合并后的公司,这是一个我们可以攻克的巨大机会,它将增加 Solaris 的采用率和整体硬件服务器收入。我们的成功还将增加 ISV 为 Solaris 优化其应用程序所做的努力。
我们将继续培养一个充满活力的开发者和系统管理员社区。交付二进制版本,以源代码或二进制形式交付 API,交付开源代码,交付技术文档,以及为常见行业技术(如 Apache、Perl、OFED 等)进行上游贡献,将是该活动的一部分。但我们还将做出具体决策,说明我们何时以及为何进行这些事情,遵循两个核心原则:
(1) 我们不能做所有事情。限制因素是我们的工程带宽,以人和时间衡量。因此,我们必须确保我们的首要任务是推动 top 1 企业操作系统 Solaris 11 的交付,以增长我们的系统业务;
(2) 我们希望我们的技术和知识产权的采用能加速实现整体目标,而不是允许竞争对手在我们之前从我们的创新中获得商业优势(或制造不确定性、恐惧和怀疑)。
我们正在利用我们在核心 Solaris 创新和工程方面的投资来推动多个业务,通过多个产品线。这已经包括了我们的企业级操作系统 Solaris 和我们的 ZFS 存储产品线,并将很快包括其他 Oracle 产品。这个策略完全是关于从一组共同的软件投资中创造更多价值:它使你们所做的一切更有价值,被全球更多人使用。这也意味着,作为一个工程师或经理,你有更大的责任去了解你的工程部署所在的更广泛的商业和技术背景。
Solaris 决策
我们将继续在几乎所有 Solaris 源代码文件中使用 CDDL 许可声明。我们不会从任何已适用 CDDL 的 Solaris 文件中移除 CDDL,新创建的源代码文件将遵循当前关于应用 CDDL 的政策(简单来说,usr/src 文件将采用 CDDL,而在 usr/closed 中的极少数文件可能不会采用)。在非 ON 聚合中继续使用其他开放许可证(例如,在桌面区域使用 GPL)也将持续。和以前一样,更改与源代码相关联的许可证的请求将逐案决定。
我们将在完整发布我们的企业级 Solaris 操作系统后,分发获批准的 CDDL 或其他开源许可的代码更新。通过这种方式,新的技术创新将首先在我们的发布版本中出现。我们将不再实时地分发整个 Solaris 操作系统的源代码,例如每晚的构建。
任何使用 CDDL(无论是片段还是作为 OpenSolaris 源代码分发或其衍生产品的一部分)消费 Solaris 代码的用户,将能够在我们发布更新时,根据 CDDL、LGPL 或适用的任何其他许可证的条款,使用这些更新。
我们将设立一个技术合作伙伴计划,通过 Oracle 技术网络(OTN),允许我们的行业合作伙伴全面访问正在开发中的 Solaris 源代码。这将包括对代码和二进制文件的早期访问,以及在适当的情况下对我们的贡献。所有此类合作伙伴关系将根据具体情况进行评估,但我们的核心现有技术合作伙伴关系,例如与 Intel 的合作,是受重视的参与示例。
我们将鼓励并倾听对 Solaris 技术的所有许可请求,无论是部分还是全部。所有此类请求将根据具体情况进行评估,但我们相信存在许多互补领域,新的合作机会可以扩大我们的知识产权使用。
我们将继续在特定加速我们整体 Solaris 目标的领域中进行积极的开放式开发,包括上游贡献。示例包括我们围绕 Gnome 和 X11、IPS 打包的活动,以及我们在 Solaris 上优化 Apache、OpenSSL 和 Perl 生态系统的工作。
我们将通过我们的 OTN Solaris 存在形式,提供技术设计信息,包括文档、设计文件和源代码描述。我们将不再默认发布每个 ARC 案例的预先技术描述,表明未来 Solaris 发布可能包含哪些技术创新。当它服务于特定有用需求时,我们可以随时做出发布任何项目的预先技术信息的特定决定。
我们将有一个名为 Solaris 11 Express 的 Solaris 11 二进制分发版本,它将有一个免费的开发者 RTU 许可证和一个可选的支持计划。Solaris 11 Express 将在今年年底前首次亮相,我们将对其进行更新,直至 2011 年 Solaris 11 的完整发布。
Oracle 在 Solaris 技术的二进制分发方面的所有努力将集中在 Solaris 11 上。我们将不会发布任何其他二进制分发版本,如 Solaris 二进制的每日或双周构建,或 OpenSolaris 2010.05 或更新版本的分发。我们将确定一种简单、经济有效的方式,使之前 OpenSolaris 二进制版本的企业用户迁移到 S11 Express。
我们将设立一个名为 Solaris 11 Platinum 的客户计划,包括直接的工程参与和反馈,针对使用我们 Solaris 11 技术的客户。我们将邀请你们所有人参与这一努力,借助以前 Sun Platinum 计划的优势,同时利用我们作为合并公司现在可用的更大的宣传渠道。
我们期待每个人在 Solaris 11 上持续工作。我们的目标很简单,就是使其成为有史以来最好、最重要的 Solaris 发布版本。
Oracle 对 SPARC、Solaris 的热情持续几年后,终于在 2017 年散去了。在这一年,SPARC 迎来了最后一次发布;而 Solaris 随后在 2018 年迎来了最后一个小版本。2019 年开始,Oracle 又开始频繁折腾 Sun 硕果仅存的最后一笔遗产 Java。从历史的角度看,Oracle 折腾 MySQL 是一个必然事件,这也是 Monty 最担心的事情。不过出乎意料的是,虽然 Oracle 的投入虽然远远没有达到令 Monty 满意的程度,但是后继的版本都正常发布了,而且功能、性能还得到了持续完善:
对于 Oracle 收购 Sun 之后发布的 MySQL 5.5,Monty 给予了肯定,同时也给 MariaDB 打了些广告。
祝贺 Oracle 和 MySQL 团队成功发布 5.5 版本!
首先,我必须承认,由于在过去的两年中,MySQL 6.0、5.4 和 5.5 的大部分规划都是在闭门进行的,没有社区的洞察,我无法像我希望的那样密切关注 MySQL 5.5 的发展。虽然到最近为止,提交记录一直是开放的,但仅仅通过查看提交记录来了解正在发生的事情并不容易。我确信我在下面遗漏了一些 5.5 版本中的重要功能,并忘记了感谢那些在 5.5 版本上做出了杰出工作的人们。
…………
现在已经距离 MySQL 5.1 GA 发布几乎整整两年了,那么对于 5.5 版本的结论是什么呢?
InnoDB 存储引擎和 DLL 锁的改进让我印象深刻。尽管像 Windows 上的速度提升这样的结果很棒,但大多数新功能都是小的(技术上的)调整。作为一个技术人员,我认为这都是些几小时内就能完成的事情,而且本可以在 5.1 版本中轻松实现,所以没有让我感到惊喜。
最让我担忧的是 MySQL 5.5 中缺失的那些功能。一些原本应该包含在下一个 MySQL 版本中的功能包括:
线程池(而不是像 MySQL 5.1 那样每个连接一个线程)。
- 据我所知,这个功能已被移到 5.6 企业版中,并不会包含在社区服务器版本中。
一个开源的、免费的备份工具和备份 API,适用于所有存储引擎。这可能是 MySQL 有史以来最受期待的功能!
- 这个项目在功能被认为准备好加入到 5.5 版本的同一天被 Oracle 停止了。
在 5.5 版本中,一些内部子系统,如 safemalloc(一个可移植的内存检查器),也被移除了。
我还担心的另一个问题是,在重要的核心开发者继续离开的情况下,Oracle 能够持续开发 MySQL 多长时间。在上面提到的人中,Konstantin Osipov 和 Vladislav Vaintroub 已经离开了甲骨文,剩下的老员工不多了。
…………
问题在于,很难评估 5.5 版本的稳定性究竟如何,因为 5.5 版本还没有被大家充分测试过,而且公开的 Bug 系统中的某些 bug 信息无法被访问,比如致命的 #33082。Bug 系统显示 MySQL 5.1 有 294 个未解决的 Bug,而 MySQL 5.5 有 150 个。然而我还没有时间评估所有公开的 Bug,所以我不知道它们的严重程度如何。稳定性还取决于 GA 版本发布后,被提交上来的 Bug 数量。
对于 MySQL 8.0 版本,Monty 的态度就更负面一些,给 MariaDB 打的广告也更赤裸裸:
上周,Oracle 宣布 MySQL 8.0 版本正式可用。这对数据库用户来说是个好消息,因为这意味着 Oracle 仍在继续开发 MySQL。
…………
在许多方面,MySQL 8.0 已经赶上了 MariaDB 的一些早期版本。例如,在四年前的 MariaDB 10.0 中,我们引入了角色(roles)。在三年前的 MariaDB 10.1 中,我们引入了加密的 Redo 日志和 Undo 日志(encrypted redo/undo logs)。一年前的 MariaDB 10.2 中,我们引入了窗口函数和公用表表达式(CTEs)。然而,MySQL 仍需追赶 MariaDB 10.2 服务器的一些功能,如检查约束(check constraints)、Binlog 日志压缩(binlog compression)和基于日志的回滚(log-based rollback)。
…………
在 Roadmap 方面,MySQL 在小心避免引入那些能够缩小 MySQL 与 Oracle 差距的功能。MariaDB 则没有这样的限制。在 MariaDB 10.3 中,我们引入了 **PL/SQL 兼容性(Oracle 的存储过程)**和 AS OF(带有按时间点查询功能的内置系统版本表)。MariaDB 是第一个实现这两个功能的开源数据库。我不认为 Oracle 会在 MySQL 中提供上述功能!
同样在 Roadmap 方面,MySQL 并没有与生态系统合作拓展功能。在 2017 年,MariaDB 一年之内接受的代码贡献量,比 MySQL 在其整个生命周期中接受的还要多,而且差距还在拉大!
我相信,如果 MySQL 采用一个开放的开发模式,让社区能够轻松参与到 MySQL 的持续开发和测试中,我在测试 MySQL 8.0 的体验会显著改善。大多数让人困惑的错误信息和奇怪行为都会在 GA 前被发现并修复。
…………
MySQL 8.0 似乎是一条通向未知未来的单行道。在 MySQL 5.7 及之前版本,迁移到 MariaDB 是很简单的事情,而且可以随时通过 mysqldump 返回到 MySQL。所有 MySQL 客户端库都能与 MariaDB 兼容,所有 MariaDB 客户端库也都能与 MySQL 兼容。但是到了 MySQL 8.0,情况往不好的方向发展了。
只要你使用的是 MySQL 5.7 或更低版本,你对未来还有选择权,但在 MySQL 8.0 之后,你的选择就非常有限了。但不要绝望,因为 MariaDB 总是能够加载 mysqldump 文件,并且将你的旧 MySQL 安装升级到 MariaDB 也非常简单
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/羊村懒王/article/detail/578343
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。