Red Hat 限制 RHEL 源码可得性，源码仅通过 CentOS Stream 公开

[lvii]

https://www.solidot.org/story?sid=75313

Red Hat 宣布其企业发行版 RHEL （ Red Hat Enterprise Linux ）相关源码 仅通过 CentOS Stream 公开。付费客户和合作伙伴仍然可通过 Red Hat Customer Portal 访问到源代码。限制 RHEL 源码可得性将加大社区发行版如 Alma Linux 和 Rocky Linux 以及甲骨文的企业发行版 Oracle Linux 提供 1:1 二进制兼容构建的难度。CentOS Stream 是一个 滚动更新发行版，是 RHEL 的 上游版本。CentOS 项目是在 2020 年停止提供传统的基于 RHEL 的社区发行版，之后 Alma Linux 和 Rocky Linux 出现去填补了原版 CentOS 的空白。

https://lwn.net/Articles/935592/

[james122333]

我以前都没有发现 centos 所谓 abi 相容怎么回事...看来是水平在提升

[ltkun]

我用 redhat 的时候还没有 yum 但是 Debian 已经有 apt 了。所有...

[tin3w5]

说这些都没有用，归根结底一句话——硬件服务器支持能不能跟得上。
之前 rocky Linux 再新（单只年龄小）、Ubuntu server 的软件包再新，只要 HPE 、Dell 这些服务器厂商提供产品支持，不会要求我哪怕是硬盘、电源报个黄灯就让我把操作系统装回人家支持的系统，我就他娘的敢用。反之只要 Debian 、opensuse 不在人家的支持列表上，哪怕社区里说它再怎么好、稳定，你特么连官方驱动都没有。想在线升级个硬件固件，官方不给你提供升级包，如果自己手工搞一个就要做好一旦升级失败，运维人员负全责的尴尬境地。
谁也不想在自己身上背黑锅，除非公司全部上云，没有一台硬件服务器，不然硬件厂商的支持列表即运维人员的备选列表。

[swulling]

不提供免费版本的情况下，不直接公开源代码而是只给付费用户公开源码，符合 GPL 协议。

所以无可指责。

[m0yBPjyX3475syS4]

@iwdmb Ubuntu Server is OK.

[feather12315]

@james122333 #20
做成 dkms 也可以呀。可是用的结构体字段或者函数变更了，需要修改 dkms 代码才行。
第三方厂商愿意为你一个厂家适配吗？

但是第三方厂家愿意为 RedHat 、SuSE 、Ubuntu 企业版适配：因为他们签约合作协议。

为什么不做成 dkms ？因为要保证二进制一致性。这是 dkms 不具备的。
有时候编译器的改动都可能带来潜在的 bug ，以及：签名。dkms 编译的可不具备来自 server 厂商的签名：这需要用 server 厂商的构建系统构建。

[feather12315]

@yyws2012 #16
内核不一样，你可以拉下来 kernel 的代码看看有没有结构体预留字段。

[Ansen]

已经在逐步使用 Ubuntu server 了，个人怎么折腾都行，企业还是稳定为主

[alex8]

付费客户可以看源码，购买个 self support 许可不就好了么，一年$349 又不贵。

[datou]

无所谓了，从来不在生产环境用 centos/rhel/fedora/oraclelinux 之类的发行版

[zhongbeyond]

@ShikiSuen 我之前还想在我服务器用 oracle linux 呢，看来后面也不一定兼容吗。 它的支持周期很长。中文有没有也无所谓

[cy18]

Red Hat 作为商业公司，只要还在 GPL 允许的框架内，干啥都无可指摘。

纯好奇，不是说现在都是用容器部署了么，内核部分是没办法，其他的 glibc 之类的兼容性应该都不是问题了吧？

[echo1937]

@liantian #12
@james122333 #13

可以蹭到技术支持的，开发者订阅是免费的，除了不能开 case ，其他啥都有。

[Jirajine]

@ShikiSuen 只改变了“可得性”，没改变授权。
所以还是可以通过付费的方式获得源码并重新打包。

[121121121]

debian 、rhel 、suse 虽然都是 linux 但是系统配置文件有所不同，不但文件名和文件位置不同而且配置文件本身也有区别，系统管理员当然不会混用

[james122333]

@feather12315

不是厂家是核心 而且你应该做成与其无关 不知道你说的字段是什么 但以程序来讲什么结构体字段你自带自己的就好 保证相容 这也很常见 至于签名这不是很必要
确保来源正确即可 包建置都需要检查 checksum
编译器目前没看到有问题的 发行版都会测 只要第三方模块商不恶搞都没事 nvidia 驱动也都有 dkms 的

[james122333]

@echo1937

没有要蹭 也不想蹭 会用只有一个理由就是公司用 也刚好都有碰过 玩的也还算遛 centos ubuntu 都有公司用 但不论 rpm 还是 deb 都是包建置不友好 硬改可以但那是很麻烦的 即便你放 docker 里问题不变 都是要有人解决
包建置友好也可以包依赖 docker docker image 做成一个包 然后再安装根本傻瓜好用 远比你想的操作更智能

[james122333]

能玩的花样可多了 现在对很主流的发行版没什么好感
自行定製过于麻烦

[iUnix]

2007 年放弃了 CentOS 和 RPM 系一路支持 Debian 至今的路过

[feather12315]

@james122333 #36
那你看 NVIDIA 的 dkms 模块能得到 NVIDIA 的商业支持吗？
就是 ko 出了任何问题都能找 NVIDIA 来 support 。

很多芯片厂商代码都是两套：一套是开源的，随便用；一套是给商业公司的。
给商业公司的代码，不少是二进制交付（而不是源码交付，看需求）。二进制交付的话，这个模块除了任何问题，都可以找厂家。


一个大型系统（比如存储系统），上下游团队很多，每个团队有自己的 release 。
以二进制交付的话，kabi 变更，任何一环变更了 kabi 导致的模块重新编译，都是不可承受的。
不以二进制交付，那就是源码交付。团队：我都源码交付了，模块遇到问题当然被交付方先处理了。 被交付方愿意吗？