tin3w5
2020-12-09 13:14:40 +08:00
这里要大言不惭一下，毕竟这个问题我个人感觉很有发言权。
楼上推荐 Debian 和 OpenSUSE 的朋友估计是没有管理过一些老品牌的硬件服务器。据我所知，至少在 2018 年之前，很多知名的老品牌服务器厂商都没有提供面对这些非商业系统的驱动（ CentOS 除外），想要用要么是买专门的操作系统服务，要么是自己从社区里搞，但是在使用过程中出现问题，前者是由专门的 team 负责 support，后者……自己负责。
在这里说几个背景，应该能更方便大家理解。由于本人之前在某硬件服务器厂商工作过，对于售后流程和常规的故障判断标准非常熟悉。用户遇到硬件故障，如果使用的不是官方支持列表里的系统，使用过程中出现任何问题，客户自行负责，刷固件出现任何问题，客户自行负责，硬件有故障需要维修，就看你报障的时间是不是他们最近 QA 查录音严不严，严的时候会要求你至少用他们官方支持的系统收集日志，才能派送备件（其实厂商也不是有意难为客户，都是国内各路“高手”采用各种手段骗保的情况太严重了，太具体的案例，这里就不展开说了，毕竟与本话题无关）
至于楼上很多人说，很多人说国内大多数人愿意用 rpm，不愿意用 deb，楼上有人评论是因为《鸟哥》。其实我个人是不认同的，试问有几个人能认认真真的把两本鸟哥都仔仔细细的读透，彻底融会贯通的？我相信绝大多数人还是拿来当作工具书需要的时候临时查查、亦或者是买回来之后简单翻一翻、读一读、然后当枕头用，能认认真真跟着做实验、记笔记的人都算不错了（没有嘲讽的意思，主要是书写的太细了，真的愿意深入的人还是少数，很难形成一种普遍的习惯。）。再者说大多数硬件服务器厂商还是愿意提供 Ubuntu 的系统支持的。而且 Ubuntu 的一个好处是，Ubuntu 官方提供了硬件服务器的驱动，而不是像 CentOS 一样，要自行安装 Vendor 提供的驱动，所以很多数据中心还是会采用 Ubuntu 作为其硬件服务器的操作系统。
OK，现在肯定有人要问了，我们用的都是虚拟化、为什么要局限于硬件服务器？答案是：为了方便，或者说的更直白点——为了偷懒。因为大多数环境都是要自动化部署、初始化的。哪个 ops 也不想天天被 Security 打电话催系统补丁、软件版本的事情，也不想被 dev 天天抱怨生产环境与开发环境不一致，更不想因为各个不同的环境中，相同的功能仅仅是因为系统的差异就要重新再写一份自动化脚本（出了 bug 导致 issue 就该头疼了）。综上所述，OPS 很多时候会有意控制环境，让所有环境尽可能统一一个发行版，不要出现太多的差异化。当然，随着 docker 的诞生，这方面的事情会越来越少。
最后再来说主题，CentOS stream，看样子感觉和 Kali 的 rolling 版本差不多（由于刚刚描述的点，本人没使用过太久 Debian，只是早些年在研究渗透测试的时候在虚拟机里装过 Kali Linux ）。Kali 早在几年前就在推 rolling update 。估计其他的发行版也都有类似的玩法。估计 RH 也是看其他的发行版这么跑没什么问题，才打算这么做的。毕竟 Fedora 是 Redhat 的小白鼠这件事情几乎是地球人都知道的事情了，再加上前面提到的几个问题，相信绝大多数人是不会在 Fedora 上部署生产环境的（极特殊情况除外），所以很多的 Bug 还是没有第一时间在 Fedora 上反馈出来，比如 RHEL6 系列早起的 NFS 不能重启的 Bug，RHEL7 早期版本 firewalld 与 iptables 条目并存的时候导致的读取 bug，CentOS8 偶发的 yum 源拉取失效问题……
上面有点朋友说，CentOS 以后可能会沦为 RHEL 的小白鼠，从目前公开的信息来看，几乎是板上钉钉的事情了。但是只要严格控制版本，不要什么东西都上来全都拉最新的软件包，应该就不会存在什么太大问题。另外就像前面有朋友说，反正 RHEL 的源码都是开源的，如果 CentOS 的品控不好，以后一定会出现另一个发行版来替代 CentOS 。服务器硬件厂商也不是傻子，系统完全一样，只不过换了一个 logo 、名字，兼容性测试几乎不用做，为什么不添加到自己的系统支持列表里呢？