我承认,之前喷红帽太大声了
不久前,红帽宣布改变 RHEL 源码发布方式。
就这件事,OSCHINA 邀请了红帽大中华区首席架构师张家驹、《大教堂与集市》中文版译者卫 sir,以及 20 多年开源经验的老工程师谭中意站在各自立场展开了讨论。
一场直播听下来,让我不得不承认,之前喷红帽喷得太大声了。事情好像并不是我理解得那样——红帽在开源方向上倒退,反而是更加激进。
根据直播,记录了一些观点,如下:
仅仅改变了 RHEL 源代码发布的位置
RHEL(Red Hat Enterprise Linux),是红帽公司推出的企业级 Linux 系统,是完全开源的。以前,其源代码主要放在三个地方:CentOS stream、Red Hat Customer Portal、git.centos.org。只不过现在,源代码不放在 git.centos.org上了,其他两个地址仍然有效。
既然只是位置变化,为什么要“多此一举”?
CentOS Linux、CentOS Stream 都是 CentOS 项目下的两个变种,目前 CentOS 项目依然存在并健康发展。大约三四年前,红帽将主要精力从 CentOS Linux 转移到了 CentOS Stream。
随着红帽精力的转移, Linux 相关的工作也都放在 CentOS Stream 上,所以在 CentOS Stream 里,就可以拿到 RHEL 的最新源码。源码就没必要再放 git.centos.org 里面了。
红帽改变 RHEL,有没有违反 GPLv2?
RHEL 采用 GPLv2,此次改变源码发布位置,并没有违反 GPLv2。被分发方只要拿到了 RHEL 二进制代码,都可以免费、无障碍、不受任何约束获得源码,并且可以再分发。而且拿到源码仍然很容易。
免费用户一样下载 RHEL 源码
现在官方有两种方式下载源码:CentOS stream、Red Hat Customer Portal。
CentOS stream 自不必说。Red Hat Customer Portal,其实就是订阅账户,付费和不付费都有。对于普通用户来说,不是付费用户也能拿到源码。
只不过,依赖原地址自动更新的用户,需要修改自动下载更新的脚本,此外并不会产生其他成本。
CentOS Stream 和 RHEL 是怎么回事?
CentOS Stream 是 RHEL 的开发主线,也是运维主线。CentOS Stream 和 RHEL 是同步前进的。CentOS Stream 的每一个 commit 都最终都会进入 RHEL 中,你看到的 CentOS Stream 就是 RHEL,二者基本没有什么差别。
一定要说有什么差异的话, CentOS Stream 是时时更新(每天有更新), RHEL 是到了发布节点才更新(约半年一更新)。 RHEL 里面的任何好东西,全都先放到 Stream。
很多人认为,CentOS Stream 是 RHEL 的上游,就变得不稳定。事实并非如此。 CentOS Stream 的任何一个 commit 都要经过完整测试,跑完之后没有问题,才会放到 Stream 这个主线上,所以说 Stream 每天都会有新的补丁。
简单地总结一句话,就是 RHEL是里程碑式发布,CentOS Stream 是持续发布。
有人问,更新这么及时这有啥意义呢?比如对于硬件厂商来说,就可以提前几个月拿到最新的版本进行兼容性测试。而且,由于各版本之间是保证兼容的,不存在后面更新了前面测试就白干了的情况。
重心转移到 CentOS Stream,其实是更积极的发布策略
CentOS Stream 是持续发布,实时更新,用户可以看到 RHEL开发、演进的细节(其实也就是 CentOS Stream 的演进细节)。这也是我们常说的“授人以渔”而非“授人以鱼”,不仅仅给了结果,还给了过程。
相较于 RHEL, CentOS Stream 采取了更积极的发布策略,用户可以更早拿到最新的版本。那为啥红帽要采用更积极的做法呢?从商业逻辑角度出发,产品出了一个新功能往往会在前期保密,避免被竞争对手抄袭。不然早早公开了,产品还卖给谁?
这也是红帽令人敬佩的地方了。
固然很多人选择开源一部分,闭源一部分,以开源的名义获取客户,获取商业利益。但红帽的价值观就是,最核心的部分是要开源的,而且只有开源到社区里,才会更有价值。同时,100% 开源也是获得用户信任的过程。
那商业利益怎么获取,这就跟红帽的商业模式有关了,比如通过现场服务、培训、服务保障等方式来获得收入。
那红帽做错了什么?
话说回来,既然改变 RHEL 源码发布方式,对用户来说并没有太大影响。那大家在到底在喷红帽什么?
首先,红帽这个姿态让人不爽。大家本来习惯这条路径,突然没了,就让人以为,红帽是从“开放”变得“不开放”了。本来很简单的事,好好解释一下,解释得直接一点,很快大家都能理解的。只能说公关 PR 这方面确实没做好。
另外, Stream 这个名字,让大家天然认为 CentOS Stream 版本是不稳定的,或是理解成 beta 测试版,其实人家就是“稳定版”,已经达到交付级别的产品。很多人都以为红帽把好东西——RHEL 藏着掖着,不让人看。其实真的冤枉啊。
如果有理解错误的,大家可以扫码,再看看直播回放。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
CGLIB动态代理对象GC问题排查 | 京东云技术团队
一、问题是怎么发现的 最近有个新系统开发完成后要上线,由于系统调用量很大,所以先对核心接口进行了一次压力测试,由于核心接口中基本上只有纯内存运算,所以预估核心接口的压测QPS能够达到上千。 压测容器配置:4C8G 先从10个并发开始进行发压,结果cpu一下就飙升到了100%,但是核心接口的qps才200左右。于是观察jvm的垃圾回收发现younggc很频繁,但是fullGC数量为零。 二、排查问题的详细过程 由于刚一开始压测,容器cpu就飙升到了100%,所以需要先定位cpu使用率问题,找出使用cpu最高的几个进程。可以通过top命令查找进程ID,发现正是压测的Java应用进程ID;然后在定位该金晨曦cpu使用率最高的线程,可以通过top -p 进程ID -H 命令显示该进程下的线程使用cpu信息。 top top -p 进程ID -H 图片中PID列则为十进制显示的线程ID,然后转换为16进制;在通过jstack 系统进程ID | grep 16进制线程ID 命令找到对应的线程信息如下,也就是该线程占用了一半左右的cpu。 jstack 系统进程ID | grep 16进制线程I...
- 下一篇
百度APP iOS端包体积50M优化实践(五) HEIC图片和无用类优化实践
一、前言 之前的文章介绍了图片优化和代码优化的几种方式,本篇文章重点介绍HEIC图片和无用类检测的优化实践。HEIC是High Efficiency Image Format(高效图像格式)的缩写,是一种新的图像文件格式,它是2017年苹果公司在iOS 11中引入,用于代替JPEG图像格式,以更高效地压缩图像并减少存储空间占用。HEIC支持多帧图像、透明度和16位深度色彩,使得它成为高质量图像和动画的理想选择。本文重点探究HEIC图片在百度APP中使用的可行性和包体积收益,验证HEIC图片在Bundle和Asset Catalog的兼容性,重点研究了Asset Catalog管理图片的机制,记录了验证过程中发现的特殊问题和解决思路。无用类则是详细介绍了如何用静态分析和动态分析相结合的方式,精简代码体积。 百度APP iOS端包体积优化实践系列文章回顾: 《百度APP iOS端包体积50M优化实践(一)总览》 《百度APP iOS端包体积50M优化实践(二) 图片优化》 《百度APP iOS端包体积50M优化实践(三) 资源优化》 《百度APP iOS端包体积50M优化实践(四) 代码优...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境