2023 年，红帽意图越来越明显，指明了要杀死 CentOS，目前的形势还有什么非用 CentOS（包括 rhel、rockylinux 等发行版）不可的理由？

[Masoud2023]

其实我表意不太好，标题里的 RHEL 指的应该是 RHEL 免费授权。

商业版当然不用说了，有钱我也买。

我想说的是免费的发行版。

[lessMonologue]

入门时候学的就是 centos 。

[geekjoehome]

我（ Linux 桌面用户）早完成了：CentOS -> CentOS Stream -> Fedora Workstation -> Fedora Silverblue 的切换。

[putaozhenhaochi]

redhat 只是不想让大家白嫖，centos stream 不能用吗

[kokutou]

你好，没有
docker 一把梭，下面是啥完全无所谓。。。

[wdssmq]

发现 Ubuntu 这边的 ppa 略香。。

[liantian]

因为在中国，RH 的培训体系健全，培训出身的，都是 redhat / centos 那套。

自学的有很多 debian 出身的，因为 debian 省资源，vps 省点钱，特别是 10 年前 64/128/192mb 内存 VPS 的年代。

一个企业里，也不是一个人熟另一个系统就行的，先熟的只能活都到这个人身上...都是人情世故，改太难了。

[sadfQED2]

我待过的所有公司，用的都是 centos ，操作系统这种东西，谁敢瞎鸡巴切啊。

[wbrobot]

用腾讯定制版本 TencentOS Server

[Vraw5]

不止红帽在杀，各云厂商均在发行自己家的系统，都在自己的云环境中构建了系统，基本都兼容 RH 系。

以前还在考虑 rockylinux ，现在全容器化，对底层系统的操作已经很少了，后续可能考虑换 Debian 系或者 Ubuntu 了。容器中的系统，用啥都无所谓了。

自己玩的话，那就随便了

[tin3w5]

楼主是开发出身吧？如果你用过硬件服务器而且在服务器保修期内，报过售后，估计你就知道为啥了。
大型的硬件服务器厂商，产品出厂之前都是要做大规模测试的，而且会与操作系统发型方做深度交流，了解未来开发进度与走向。所以硬件服务器厂商会提供一个 OS support matrix ，什么型号的服务器会被规定只能使用某些操作系统发行版的某些版本，差一个小版本号都不行。
而这里面几个掏钱的大头无非是微软、Redhat 、Ubuntu server 和 SLES ，如果你认真的去读硬件服务器发行厂商的文档，会发现这里面 Ubuntu server 很多时候是主动购买大型服务器厂商的产品，自己搞驱动之类的兼容性和稳定性测试，然后找硬件厂商认证（至少我之前用过的几个国际大品牌的硬件服务器是这样）。对于 CentOS 、Rocky ，跟着红帽混肯定能分得一杯羹。
当然，假如你就是头铁——“老子技术好，啥驱动问题老子都能解决，老子装好的系统就是稳定”。那 OK 啊！服务器硬件出了问题别去找售后就行，因为人家的工作流程第一步就是检查你的操作系统是不是在 support matrix 里，不在直接让你重装系统，然后再来报障。另外就是刷固件，如果刷固件之后硬件损坏了，售后发现操作系统版本不对，那就你自己负责，你用工资赔吗？这种事情也不能怪售后，如果遇到又菜又爱玩的逗比，硬件更换之后售后检测中心发现硬件没问题，就是客户的操作系统订制没做好或者驱动有问题，从 rpm 转出来的新包有问题……那售后第二年的评级是要 downgrade 的（而且这种又菜又爱玩的人还真的不是少数）。
企业级运维是要讲究成本的，既然某些东西经过开会研讨定版，就会尽可能统一化。下层的硬件服务器用了 Redhat 系，上面的服务为什么要换成别的给自己找麻烦？而且反正都是业务服务，为什么不用 docker ？换 docker 容器了，开发爱用啥用啥。只要做好隔离，底层系统是什么根本不重要。

[Alliot]

项目上，现在已经从 CentOS 切到了 Ubuntu LTS 了， 个人自己使用的 Debian

[justfindu]

没关系 马上我们要全国产了 更难受

[w292614191]

@tin3w5 #10 老哥比较贴合实际，其他说法感觉跟好玩一样不顾后果。

[forvvvv123]

改用 Debian 系的发行版吧，比如 ubuntu 我看挺好

[Masoud2023]

@tin3w5 #10

道理是这个道理，可是至少在我视野范围之内，我真的没看过几个直接从物理机开始做的。

我视野内除了几个政发布这个内容需要你已经注册满 90 天府外包之外基本都是全套公有云。

当然不可否认，无论是什么系统，这一点原因想一想确实是真实存在的。

[Masoud2023]

@kokutou #4 完全赞同，直接公有云 k8s 确实不用关注这些，唯一需要在意的只是 dockerfile 里 FROM 哪个 base😂

[oldboy627]

@Masoud2023 你没看过只能说你工作的公司少或者都是互联网公司。 我之前工作过的一家公司的客户就是，所有 Linux 都是 SUSE 和 RHEL ，全部商业化付费版本支持。 即使新上线的项目，新的机器也一律是新购 License 安装商业版系统。CentOS 等免费的一律不准使用的，因为就是没有售后，没有 support 。

[yolee599]

目前我的个人 vps 已经从 CentOS 切换为 Debian 了，并且不打算再用 CentOS 。

[yrzs]

新服务器全用 Ubuntu LTS 了，况且现在确实只需要在意 pod 里面的 base 镜像了

[vtgoal]

如果你没找到非用不可的理由，那说明你很可能不需要，就不要为了找理由而找理由了。
等你发现为什么需要商业支持，需要高水平的商业支持的时候，自然就理解为什么还有企业愿意为了这个支持付费了。

[tin3w5]

@Masoud2023 习惯就好，运维很多时候是要给自己留后路的。天有不测风云，谁也不知道下一个被裁员的是不是自己。万一被裁了，要去机房抗服务器，数据中心对运维的要求就是得对 OS support matrix 上的操作系统熟悉啊！尤其是现在的大环境，更是这个样子。总不能为了技术、为了理想，跑去给大家送饭碗（外卖）吧！
只能说，硬件服务器厂商不改变，运维不敢变……

[BaseException]

前天刚把我 digitalocean 上 4 年前创建的 droplet ，centOS7.6 重装了系统，换到了 debian12 。 博客运行速度都更快了（之前还是直装，现在是 docker-compose ），cpu 内存资源占用比起以前也更少。

[kingfalse]

那几个是彻底报废了，目前在主力用 debian 跟 opensuse

[xcai]

个人用户用哪个发型版本无所谓，怎么舒服怎么来，企业用户推荐购买商业发版本，另外容器技术不是万能的，也要有个底座，别懂一点容器技术就觉得这玩意儿是万能的，包括 vm 觉得什么业务都能上容器。

[xcai]

我个人目前用 centos stream 9 稳不稳定用过才知道，而不是看名字以及看带有观点的媒体发的文章就觉得不稳。

[xcai]

@tin3w5 站在硬件角度说的很好，除了硬件也还有商业软件层面，例如 Oracle 数据库 SAP 等 同样会针对有限的几个企业级 os 提供支持。

[willamtang]

我们用的系统或者应用有一条要求就是可以购买商业支持。你可以先不买，但需要的时候要有的选。所以 OS 都是 windows 或者 RHEL

[adoal]

厂家的底气就是用户惯出来的毛病。反正我要买在物理硬件上直接部署要新开发的业务系统的服务器时，集成商给我做的招标参数我会加上 Debian ，软件开发商给我报的招标参数我也会加上 Debian……

[adoal]

不过说真的除了极端的情况之外已经很少遇到需要物理机上直接装业务系统的情况了。

[princeofwales]

世上不只有互联网企业，中国还有很多传统行业，在线交易型系统，用的还是免费的 RHEL+Oracle 一套，比如医疗卫生行业

[xcai]

@adoal 主要是 Debian 没有支持，买了硬件和商业软件，OS 作为这俩中间最重要的连接部分选择 Debian 不是一个很好的选择，哪怕加上这个这个参数，当出现问题时可能也无法及时的得到支持（当然团队中如果有人能快速响应和解决的话那就没有问题）。仅仅是个人观点。

[adoal]

@xcai 嗯，不同的选择都是权衡过利弊的结果。大部分甲方信息化人员就是当自己是文科生出身的文员，要职场套路，要保平安，要政治要业务要修齐治平，就是不在乎技术，那就只能惯着厂家，被厂家捏鼻子走了。

[adoal]

@xcai 另外一，我当然不是只上 Debian……比如新上的业务系统，除了是已经成熟很多年的系统拿来直接销售给我们之外，新开发的我还要求数据库都用 PG 你不愿意就别来玩呢。另外二，现在确实极少用物理机，所以底气要足很多。

[adoal]

@xcai 大连机务段 Flash 事件之后，twitter 上有人评价说：其实大部分体制内的信息化根本没人在乎技术，只是偶尔有极少数的，恰好碰到了懂技术又在乎技术的人。引起一些泪奔。

[tin3w5]

@adoal 你说的情况可能在国内比较多，毕竟在国内更看重的是我能怎么用最少的钱创造最高的价值。但是在国外，企业更在意的是商誉。很多公司即使上了云服务也是要从云厂商买物理服务器装 Oracle 的，如果真的是 Oracle 数据库出了问题，责任是 Oracle 的。明天的新闻会说是 xx 厂商因为使用了 Oracle 的数据库，遇到了一个 xx bug 导致业务中断 xx 分钟。事后 Oracle 还得赔款。
国内的一些企业的思路是，你的确可以什么东西都上云、上虚拟化，然后呢？出了问题开发、运维担责任，公司商誉受损。新闻上只会有 xx 公司昨天业务中断了 xx 分钟，公司股价下跌 xx%，然后开发和运维搞不好就要跟着卷铺盖卷走人。而事实上只是因为 PostgreSQL 的一个 bug ，但是选型是你自己选的，开源社区也不会替你背锅，更不会给你任何赔偿。
还有就是，你说的招标时加条件是可以的，但是需要买硬件厂商的额外操作系统服务，通常都非常贵，按操作系统数收钱。说白了就是相当于你买了一个从硬件厂商那里订制的 Debian ，而且享受 5*8 或 7*24 的售后服务。
早些年我知道的是一些大外企，国内的迅雷、百度买过 Debian 的定制化服务，但是你的服务器售后成本（包含在服务器采购价格里）比正常购买要高出好多。你认为你的老板能批吗？通常情况下，就算你老板给你批了，采购、财务在评估的时候也会把你这个需求砍掉。按照某大型国内公有云厂商的尿性——“大不了连提需求带人一起砍掉就好了。”
懂技术不是什么东西都要追新，而是能把手里现有的东西都搞好、不出错，然后逐步革新。不然国内那么多芯片企业的工控机上用的还是 Windows7/10 个人版+.Net Framework 4.5 桌面应用、kernel 2.6 的 CentOS5+perl+DB2/Oracle 。要不要让他们都换成 Ubuntu ？那群玩意连打开个 PDF 帮助文件都要找厂商问，你还能指望他们能用明白 Debian ？产品分分钟投标就直接 failed 了。地铁也是类似的情况，他们能日常用明白 flash 就不错了，那种突发状况他们根本不知道怎么操作。不知道怎么办？一层一层的上报，一层一层的等消息，然后联系外包，外包再一层一层的转达……体制内是容不下懂技术的人的，只有那些上面没关系、又不会溜须拍马、投其所好的人，才会被发配去对接外包们搞技术。

@xcai 是的，之前在外企工作，核心数据库基本上都是 Oracle ，大规模项目不是一两个开发工程师或者开发团队就能决定的。

[paopjian]

有没有可能,20 年后国产化那一套还是 centos7 甚至 centos6,因为 xinchuang 套皮 OS 早就是搞兼容 centos 那套了,最终决定用什么的是领导,开发运维就是再烂的系统也得开发

[herozzm]

换呗 一堆可以替换的 反正都是 docker

[adoal]

@tin3w5 你说的都对。你说的我也都懂。混职场，自保套路比别的都重要。然而作为一个讨论的话题时，如果最后都收敛到这个“终极答案”，其实从讨论的角度看，挺没意思的。

[adoal]

另外，你们说花钱买 RHEL 那我没啥好说的，按职场套路，这是最明智的选择。

但是我遇到更多的是他麻辣隔壁的一帮沙雕用着 CentOS 还跟我讲爹味的职场责任。比如知乎上曾经有一个 CentOS vs Debian 之辩话题下一个叫袁昊洋的无脑 CentOS 粉……对此我只想说：我支持孔庆东教授。

[adoal]

另外 N+1 ，你们不会真的没见过在部分（甚至超半数）标准的 supoort matrix 里有 Debian 的服务器厂家吧？

[felixcode]

服务器厂商支持的也是 RHEL 而不是 CentOS ，所以要么买商业支持的 RHEL 等，要么直接社区版的 Debian 等，而不是不伦不类的 CentOS 之流。

[xcai]

@adoal 所以说 CentOS 扼杀的好啊，现在 CentOS Stream 才对味。

[greatbody]

这和我月薪 3000 有关系么

[duluosheng]

我司最近在搞下一代操作系统的调研和各个基础组件的适配，基本和 10 楼的说法一致。最终考虑的版本都是 RH 衍生的 alma 和 rocky

[Masoud2023]

@duluosheng #44 那我劝你们可得掂量好，现在 centos 所有下游都生死未卜，并且我同意 41 楼看法：服务器厂商支持的也是 RHEL 而不是 CentOS ，所以要么买商业支持的 RHEL 等，要么直接社区版的 Debian 等，而不是不伦不类的 CentOS 之流。

[Masoud2023]

并且 alma 和 rocky 真的有很多生产实践么？这两个东西这么久了也没见有太多人讨论过。

[leonshaw]

没懂 docker 跟这有啥关系，docker 里依赖不还是基于发行版的？

[tin3w5]

@adoal 我之前在硬件服务器厂商做过，后来又去了云厂商，那个时期的操作系统 matrix 我几乎可以到背下来的程度。我可以很负责的跟你说，我印象中截止 2020 年 4 月份，大多数国际知名品牌，除了非常古老的型号（大概 06 或 08 年左右吧），100%不支持。国内的个别厂商可能会写明支持的，但是生产环境肯定是要统一版本的。而且小厂商往往都是为了照顾一些关系户，真的采购了也不敢往生产环境里放。而且就像我之前说的，人家没说不支持 Debian ，只是默认的操作系统支持列表里没有 Debian ，只要你花钱买厂商的 OS support ，你上 Gentoo 都行。
至于 CentOS 为什么是社区系统就能享受硬件厂商提供的商业化系统支持这个问题，我只能说人家硬件厂商就是这么写的。从 CentOS stream 8 开始，要么明面上不写支持（注意是不写支持，不是写出不支持），但是私下会支持一些 RHEL 的下游版，比如 ClearOS 、Rocky 、Alma ，要么就不对支持 CentOS 的原文进行修改。

至于你说 Alma 和 Rocky 有没有生产支持，我只能说，硬件厂商不找麻烦，就有人敢用。

还有一个方面就是企业级的影响范围和社区级的影响范围是不一样的，试想一下为什么三胖子的家的服务器用的都是用 Fedora 改的（和早期的红旗很像，都是操作系统向硬件服务器做妥协的成果），而不是用 Debian 去改呢？这很值得深思。

从讨论的角度来讲，我只能说我喜欢 Redhat 系列的包管理机制、系统目录结构和软件包选择方案。用的久了，习惯了。就像当年 RHEL7 刚出来的时候，一堆企业骂 Redhat 的娘。一方面是因为 systemd 不符合传统 UNIX 的“一个软件包只好做一件事”哲学，另一方面的确是那次买步子迈得太大了，让太多的人都感觉不仅用起来不习惯，而且各种脚本也要做大量的修改。但是即使是这样，除了几家特定的企业有听说换 Ubuntu Server ，大家不还是用 CentOS 用的津津有味的吗？

[duluosheng]

@Masoud2023 我们是上了规模，而且有自己的软硬件团队，硬件厂商也一起配合，CentOS 7 马上就 EOL 了，加上旧机器过保，才做切换，服务上面的实际业务都基于容器，业务方感知不大。对于传统企业而言，没有专门的团队，还是直接 RHEL 省心。

[adoal]

@tin3w5 byebye~~确实不同场景的人的需求不一样。可能你们的土豪客户有钱堆起来让供应商跪着添爸爸所以可以不在乎 RH 系的各种操蛋。像我这样只能小成本接触“地行小”供应商的，用 RH 根本是在作践自己。麻辣隔壁的那些狗屁地行小供应商，根本没有能力做所谓的整体交付。他们在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新，直到被同单位的信息主管子单位送来安全通告。这种情况下，反而用你们觉得不够职业化的 Debian 对我来说更省心。至少大部分基础组件都是一句 apt 就装好的，是版本不太老可以拿来用的，是有 update 的，是按照 FHS 等最佳习惯打包好的。至少不用让那些连把业务功能开发正确都要靠甲方反反复复督促才能做到的地行小来一脸懵逼勉为其难自以为是狗屁不通地负责我的基础设施。

[libook]

我们公司以前用 CentOS ，后来容器化了之后宿主机就无所谓用啥了，红帽宣布改变 CentOS 策略之后我们很容易就换了 Debian 作为宿主机，再后来就用云厂商自己的发行版，功能、性能都会好一些。

现在 RHEL 的意义主要还是一整套付费支持服务，还是有很多企业需要的，特别是用私有云的，一方面可以降低运维成本，另一方面可以提高服务质量，花钱就能解决问题。

[Maboroshii]

很好奇哪些公司的业务，可以跨过应用上的 bug ，直接面对操作系统级别的阻碍性问题。还是说企业级的发行版主要是安全漏洞比较完善呢？不过楼上说和硬件结合，那也确实没得选

[adoal]

@Maboroshii 打个比方吧，深交所的某个系统出错了，领导一声令下：会诊！业务系统厂家 1：到！业务系统厂家 2：到！……业务系统厂家 N：到！服务器厂家：到！存储厂家：到！网络设备厂家：到！操作系统厂家：？？？

其实还有个问题就是，不知你有没有注意到最近 Alma 说的：AlmaLinux 不再 1:1 兼容 RHEL ，未来致力于兼容 ABI
https://www.oschina.net/news/249342/almalinux-no-1-1-rhel
实际上很多做业务系统开发的团队在遇到 OS 基础组件级别的 bug 时，有很多靠速查 CSDN+猜测+尝试来编程的程序员其实没能力判别这是基础组件 bug ，所以按照“当前这样的行为就是正常的”来写业务了；或者即使有能力发现 bug 但因为工期或者依赖可控性等原因没办法等到操作系统厂家的下一次 update ，于是就把 bug 当 feature ，自己在应用层面去 workaround ，同时又因为工期等原因并没有写下这个 bug 如果被 fix 了之后按照正常预取应该有的行为要怎么做。然后这个业务系统的正确性就依赖底层的 bug 了。那么操作系统的仿品如果要去争取各种行业用户就要维持一个“bug-for-bug compatibility”才行。

[tin3w5]

@adoal 你这思维就是错的，你要清楚你的定位，你是 dev 就好好的写代码，别管线上到底跑的是什么。你是 Ops 就好好维护线上线下环境，别去想着哪个软件包的安全问题，安全的问题有安全部门负责，他们会告诉你应该用什么版本的软件包。所以，安全部门不发 ticket 为什么要做安全 update ？不发说明安全部门的审核与评估认为不需要更新，那你更新了，出了故障，锅就是你的。
至于你说的手工编译的东西，难道不是通过 docker 去进行编译，然后搞成 docker image 用来跑业务吗？为什么感觉你说的东西还停留在 10 年前？
还有，在生产环境下，每一个包的安装都是要严格遵守升级前订制的 baseline ，而且要事后审计的，不是你说的一个 apt update && apt upgrade -y 就敷衍了事的。安装软件包更不是无脑使用 yum/apt install -y 进行安装。每一个软件包的安装、更新，都是要经过内部确认商讨的。就算安全发来更新的 ticket ，OPS 和 Dev 也可以从业务的持续性、稳定性的角度出发提出质疑或申请拒绝升级某些或某个软件包。你说的这种方法搞搞测试环境、搞十几台、几十台虚拟机这种作坊或者小 cluster 还凑合，暂且不说给你一个十万台级别物理机的环境，目测两千台，你这种思路就得搞出一堆问题。
最后我想说，从你的描述来分析，不是你说的这种小 vendor 没能力做 Redhat 系的交付，而是当使用方式是错的，谁也得不到一个正确的结论的。

[adoal]

@tin3w5 所以我说不同场景的人需求不一样啊。你可能跟高大上的金主爹型客户、高大全的一互大型技术方接触多了，真的想不到都这个年代了还有这种很落后的信息化环境（而且还是这个行业里有话语权的一流单位），还有苦逼的从写报告写 PPT 申请经费开始一条龙都要管的“综合信息化”人员，还有法人单位的信息化部门技术能力乱七八糟给下面的处级业务单位提供不了足够的基础设施支持业务单位只好自己搞的苦逼场景。定位？定他妈的位。你说的那些都对，都对、都对！但是，如果换了你在我这里，恐怕比我还瞎搞。还特么的给我一个十万台级别的物理机的环境……别拿一互大的做事条件来 PUA 我了。在这种综信岗位上做几年，跟一堆地行小斗争上几年还没走人的话，这些一互大的美好理念都特么的……还十万台物理机……我真不是在一互大干活的，我单位再怎么自我膨胀也就百来个虚拟机几十个系统，真的经不起您这种一互大场景 PUA 的指导。

[adoal]

何不食肉糜？

[feather12315]

@tin3w5 #54
可能是没经历过所以不了解

[cassyfar]

推荐 Debian 的不是坑人？现在云厂商支持最好的第三方系统基本就是 Ubuntu Server 和 RHEL 。

现在都是容器化了，OS 对于你本身的软件兼容影响很少。你的问题主要是技术落后导致的。

如果只是个人开发机，完全随意，你用 Arch ，Gentoo 都没人管。

[Masoud2023]

@cassyfar #58

你猜猜 Ubuntu 上游是谁？ Ubuntu 跟他有啥区别？

哪家公有云指明了说就这两个支持最好了？

[vtgoal]

@adoal 他说的是大企业大厂商之类的运转方式，你说的是小规模企业的生存方式，不存在什么何不食肉糜。

好比一个家庭年入 5 万，要求他过的精致点，消费的好点，买 20 万的车，这就不现实，同样的年入 100 万的家庭买个 50 万的车，你也不能说人家交智商税，跪舔厂商，非让人家买个 5 万的车才对。

不过如果 100 万的家庭只是为了省钱买个 5 万的车就不一定不合适了，没准浪费的时间成本比车还贵呢，这个比方不太合适，不过方便理解。比如世界 500 强还用小作坊的思维就不对，光是合规一项就把小作坊里的那一套生存哲学扼杀了，你老想着客户花的钱就是为了跪舔厂商，这个就是眼光狭隘了。

[adoal]

@vtgoal 后面我思路被他带过去了，在吐槽他说的管理上万台物理机的假设对我的现实情况没意义，看起来好像我要表达的重点成了大 vs 小的规模……其实我本来不是要说这个的。

不过说起来，规模大的场景里，对技术细节的要求的确不是重点考虑的，而且也是难以去重点考虑的。只要钱到位，用管理手段和所谓的职业化精神，总可以包装出巧克力盖浇屎，来掩盖内部实现的恶臭。

但是没这条件的时候（所谓没条件不一定是因为小厂，也可能是因为体制问题，比如叠床架屋的婆婆机构，业务单位拿不到 infra 的经费，只能做纯业务系统，而且经费只够勉强把业务功能做好，不会有余量来提升 infra ，但同时本该负责 infra 的信息化平级负责单位的 infra 水平又不够让业务单位放下心不去考虑 infra ），没办法像他说的用当代一互大的先进运维方式去提升 infra 水平，只能去抠类似“在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新”的 bad practice 细节。

他以为我不想“清楚自己的定位”，以为我想啥都管，以为我不想搞 baseline 每个基础组件变更都审核，不想用一互大的先进理念吗？除了你说的小规模（另外提一下，小规模不一定是小“厂”）条件下不一定有必要用大长的思维，再就是没条件啊。除了没钱，也没这样做机制。

他说我关注的这些技术细节的玩法是 10 年前的……可是如果我像业务部门人员、技术部门里技术能力停留在入职前永远不再更新的伪技术人员一样只关心业务功能实现，不关注这些东西，那我的“地行小”vendors 送给我的可不只是 10 年前……恐怕放到 20 年前都算烂的了。我在没条件把我手上的 infra 拉到 1 年前的情况下，至少还努力尝试从 20 年前拉到 10 年前。他说的那些再先进的，臣妾真的没力气做到了。

另外，我认为，以前做事不讲究，动辄搞出“在 RH 系上，自己手工编译一堆基础组件，装好的路径乱七八糟各种不可预测，可执行程序的 FS owner 和启动的 euid 一样，在 shell 里手工 nohup 交互启动，而且从来特奶奶的不管任何更新”等各种运维屎的那些乙方“（又做业务对接又写代码又勉为其难给甲方做部署和运维的）综（合）信（息化人员）”们，在现在流行的容器化 infra 下，实际上只是在做巧克力盖浇屎，虽然容器化在一定程度上可以减缓原来不懂 infra best practice 带来的问题（比如容器内环境较为精简可以减少攻击面，比如可执行程序文件的 FS owner 和启动的 euid 一样导致的远程溢出获取 shell 来修改可执行程序埋桩可以随着容器的毁灭重建复原），但屎还是屎，不能因为浇了一层巧克力壳就变成巧克力。

[adoal]

托尔斯泰说得对，信息化搞得幸运都是一样的，不好的则各有各的不幸。^_^

其实这个世界上很多支撑着社会基本运转的单位的信息化水平尤其是 infra 水平烂到习惯了“一互大”的人无法想象。

[adoal]

不过一互大里的 infra 其实也很多草台班子。钱多人多市场近的行业，必然萝卜多了不洗泥，不过正是因为钱多人多市场近，即使 infra 草台，也有各种非技术的办法让他运转好。

[salmon5]

AlmaLinux 路过，官方非正式回复，还是 10 年维护生命周期。
https://www.reddit.com/r/AlmaLinux/comments/14yyg3i/comment/jryd24w/?utm_source=share&utm_medium=web2x&context=3