https://feng.si/posts/2019/07/centos-the-last-linux-distro-you-should-ever-consider/

[utterances-bot]

CentOS: The Last Linux Distro You Should Ever Consider :: I can I up 🙃 — feng.si

CentOS 是 Community Enterprise Operating System 的缩写，按字面翻译为“社区企业操作系统”，而 CentOS 受害者一般称其为“圣斗士”，准确描述它的中二性质。这是一款让人一言难尽的 Linux 发行版。

https://feng.si/posts/2019/07/centos-the-last-linux-distro-you-should-ever-consider/

[z-gong]

centos存在的一个重要原因是有些行业软件只保证在rhel和suse上的可用性。要是不想买rhel那就只能选cent了

[balthild]

然而，RHEL/CentOS 的「稳定性」指的是「ABI 稳定性」，而不是什么其他稳定性……系统更新导致软件（尤其是企业内部开发的专用软件）挂掉，绝大多数原因都是 ABI 变动，这并不应当是程序员或运维的责任。使用 CentOS 最主要的目的，就是较长周期内保持 ABI 不变。

有了容器之类的 DevOps 技术后，这种特性就不再是必要的了。但也不应该一味地回头指责旧的技术，毕竟时代局限性并不是那么容易克服的。同样的道理也适用于某些历史包袱沉重的语言（C/C++ 等），它们与现代格格不入并不是一个错误，而是早期工业界不成熟的摸索。

[fengsi]

@balthild 它本意也许只想锁 ABI，可惜实际上对内核、GNU Core Utilities、其他程序这三大部分没有做任何区分，客观上造成了全部锁死的事实。

我在之前的这篇文章里已经探讨过大部分 Linux 发行版的一刀切发行模式缺陷，也提到 Docker 之类的容器技术产生的原因，接近你的观点。

反观 FreeBSD 甚至 Windows，它们每一个发布版的 ABI 都和 RHEL 这类发行版一样稳定（锁定内核与基本系统），但是并不会强制锁定需要灵活性的其他程序版本，反而还提供多版本选择。Linux 这样一刀切的发行模式属于典型的因噎废食。

[floating-cat]

主要是 CentOS 包太旧了，从 LTS 和稳定性来考虑就容易产生这个很讨厌的后果。如果一个公司原因用一个半年一更新或者一年一更新或者 LTS 时间更短的发行版本就能解决这个问题了。

无论怎么样，等几个月 CentOS 8 出了，对需要 LTS 的用户来说是个还算不错的选择。包比起 CentOS 7 新太多太多 & 很多不错的东西。

[fengsi]

@floating-cat CentOS 的一大流毒是助长了动不动就从源代码裸编译安装（直接 make install）的妖风，培养了大批眼高手低还不可一世的「运维」。这些牛气冲天的「运维」连怎么正确制作 RPM 包，从而避免裸编译安装破坏系统完整性都不会，也通常是直接使用 root 帐号和明文密码来 ssh 的主力军。

[yankeguo]

一个早就在主线内核修复了的 bug 直到最近才被 RHEL 合并，然后进入 CentOS。这个 bug 会导致网络设备挂起，k8s 集群无法释放容器。这种拖沓的处理方式真是让我恨之入骨，公司之外的项目我再也不会考虑 CentOS 了。

[ghost]

既然CentOS问题这么大为什么在国内用的这么多？FreeBSD这么好为什么国内没人用？除了培训机构鼎力推荐以外CentOS本身还是有很多优点吧。Scientific Linux也不再开发了，费米实验室改用CentOS8了。

[deathrush]

作者对解红帽系发行版的了解浅薄。 红帽喜欢魔改内核，内核版本号看上去不高，但是经常会集成新版本中企业迫切需要的功能。比如CentOS 6 2.6.32中就支持了SSD的TRIM指令。

[fengsi]

@Bond171

既然CentOS问题这么大为什么在国内用的这么多？FreeBSD这么好为什么国内没人用？除了培训机构鼎力推荐以外CentOS本身还是有很多优点吧。Scientific Linux也不再开发了，费米实验室改用CentOS8了。

国内的技术体系一向有很大问题。CentOS 除了虚头巴脑的「企业级系统」标签外没有任何优点，属于贪小便宜吃大亏的典型反面教材

[fengsi]

@deathrush

作者对解红帽系发行版的了解浅薄。 红帽喜欢魔改内核，内核版本号看上去不高，但是经常会集成新版本中企业迫切需要的功能。比如CentOS 6 2.6.32中就支持了SSD的TRIM指令。

你对 "integrity" 这个词没有概念，没有明白「野」与「不野」的重要区分标志。Integrity 与内核版本号以及发行版功能没有任何关系，文章重点表达的是 CentOS 的原罪造成了系统必须「野」化之后才能用的事实，而这与其标榜的「稳定」自相矛盾。这是很简单的逻辑

[ghost]

那费米实验室也是贪小便宜吃大亏了？

[fengsi]

@Bond171

那费米实验室也是贪小便宜吃大亏了？

如果你稍微了解一点 RHEL 系发行版历史的话就会发现自己这问题问得有多幼稚

Fermilab 早在 RHEL 前就推出了 Red Hat Linux 的山寨品，叫做 Fermi Linux。之后 Red Hat 把民用版变成 Fedora 交给社区，付费版做成 RHEL，于是 Fermilab 又用 RHEL 山寨了一个 Fermi Linux LTS，还早于 CentOS。正好那时候 CERN 也在搞自己的 RHEL 山寨，两边一合计不如一起开发算了，所以才有了接下来的 Scientific Linux

过了大概十年，CERN 突然开窍了：自己明明不是真正的硬核玩家，搞的都是些边边角角的重新编译重新贴牌工作而已，偏偏还要出钱出力出人在这个项目上。算一算好像不如直接买 RHEL 付费支持一了百了？我 TM 真是傻的！

想明白这个道理之后，CERN 发现自己的人生完全没有意义，两家闭门山寨还不如享受 CentOS 群众山寨的现成劳动果实，所以就和 Fermilab 闹着分家，退出 Scientific Linux 合作，直接上了 CentOS。最后剩一个 Fermilab 也撑不下去了，不得不宣布停止开发 Scientific Linux，转投 CentOS

回顾 Fermilab 和 CERN 这俩傻孩子这十来年的山寨路，这个亏吃得不是一般大。它们最初的目的都是想省钱用上免费的「企业版」，结果却付出了高昂的学费。转用 CentOS 很大的一个原因是现有 legacy 系统不能说丢就丢，必须死撑，否则整个架构得重来。改用 CentOS 不是因为它有多好，而是因为它在 RHEL 一系列垃圾山寨品里算最不垃圾的那一个，如此而已

所以回到你最初的问题：

是的，费米国立加速器实验室 和 欧洲核子研究中心 都是因为贪小便宜而吃了大亏

[ghost]

你不要偷换概念，费米实验室一开始用的不是CentOS，而是费尽心思搞ScientificLinux，所以并不存在你所谓的贪小便宜。开始用CentOS8时才应该叫贪小便宜。还有山寨红帽就叫贪小便宜？你的逻辑太难理解。你怎么不说SUSE贪小便宜？CentOS早都招安了，就别在这里尬黑了好吗？

[fengsi]

@Bond171

你不要偷换概念，费米实验室一开始用的不是CentOS，而是费尽心思搞ScientificLinux，所以并不存在你所谓的贪小便宜。开始用CentOS8时才应该叫贪小便宜。还有山寨红帽就叫贪小便宜？你的逻辑太难理解。你怎么不说SUSE贪小便宜？CentOS早都招安了，就别在这里尬黑了好吗？

山寨 RHEL 绕过付费就是贪小便宜，这是什么偷换概念？Scientific Linux 是这样做的，CentOS 也是这样做的，类似于很久以前的各种 QQ 魔改和 Windows 魔改，换个名字就当自己产品了。Scientific Linux 换到 CentOS 继续贪便宜，一个路子没错啊？自己之前贪小便宜，搞到最后入了这个坑爬不出来，难道不是吃了大亏？

其实贪小便宜没啥问题，open source 有本事自己改，只要不违反协议都行。可是贪了小便宜还不让人批，这就完全没有道理了。自己的魔改系统一个劲蹭原版的品牌热度，真是一点脸都不要了

另外你提到 SUSE 真是大错特错。openSUSE 与 SUSE Linux Enterprise 的关系就相当于 Fedora 与 RHEL，都是官方原生支持的。文中对 Fedora / RHEL 这种双赢关系是持明确支持态度的，反对的仅仅是 CentOS 这种沽名钓誉发行版的精分行为。CentOS 被招安文中也提到了，因为它实在太恶心，Red Hat 的目的是让它不要再这样瞎搞，而不是从一开始就是官方设计的 openSUSE / SUSE Linux Enterprise 和 Fedora / RHEL 这类良性的共生关系

你对开源历史的认知有重大缺陷，一些常识都会搞错

[ghost]

RHEL既然开源肯定有人去山寨绕过付费，这是各种协议许可的行为。SUSE有能力就大改特改。CentOS没能力就小改。为的就是让大家不付费就能体验到RHEL。红帽收购CentOS并不是因为怕它乱搞，而是CentOS间接的推广了RHEL，红帽希望亲自调教CentOS，让它更能代表RHEL，从CentOS迁移到RHEL更容易。当然我是猜的，我相信你那些结论也都是猜的，咱们也别说谁对谁错。我写这些东西就是不想看到有人被你这篇文章误导。还有就是你才是对开源历史认知有重大缺陷，开源社区是黑客带起来的，山寨红帽这种行为是完全符合开源精神的，并不是沽名钓誉。鼎鼎有名的开源软件哪个不是山寨的商业软件？只要是收费的软件就有人想去山寨一个免费的，或者直接破解来造福大众，所以CentOS正是体现了开源精神。红帽现在都在发展CentOS，你还在这尬黑，你比红帽高层领导都厉害啊。

[fengsi]

@Bond171

RHEL既然开源肯定有人去山寨绕过付费，这是各种协议许可的行为。SUSE有能力就大改特改。CentOS没能力就小改。为的就是让大家不付费就能体验到RHEL。红帽收购CentOS并不是因为怕它乱搞，而是CentOS间接的推广了RHEL，红帽希望亲自调教CentOS，让它更能代表RHEL，从CentOS迁移到RHEL更容易。当然我是猜的，我相信你那些结论也都是猜的，咱们也别说谁对谁错。我写这些东西就是不想看到有人被你这篇文章误导。还有就是你才是对开源历史认知有重大缺陷，开源社区是黑客带起来的，山寨红帽这种行为是完全符合开源精神的，并不是沽名钓誉。鼎鼎有名的开源软件哪个不是山寨的商业软件？只要是收费的软件就有人想去山寨一个免费的，或者直接破解来造福大众，所以CentOS正是体现了开源精神。红帽现在都在发展CentOS，你还在这尬黑，你比红帽高层领导都厉害啊。

你对「山寨」的定义与我的不同。GNU/Linux 并不是「山寨」UNIX，而是最大程度兼容 POSIX 的拥有版权的重写产品。而 CentOS 只是简单利用 GPL 的保护伞重新编译出一个「清真」的 RHEL，基本没有任何原创性可言，属于「窃书不能算偷」的范畴，其本质是直接窃取他人成果的行为。这才是真正的「山寨」，并不符合开源精神

有名的开源软件也并不是「山寨」商业软件——大多数商业软件又不是 GPL 发布，随意山寨还得了？顶多是像 GNU/Linux 那样自己重写的克隆，在代码方面是有自己版权的，仅仅是 API / 用户体验等类似而已

DistroWatch 上发行版趋势一查便知。排名前五名有四个都是 Debian 系，一个是 Arch 系，而 CentOS 早已跌至十名开外。不要强辩什么桌面和服务器用户数量不同，Debian / Ubuntu 这两个都是服务器大户，在一二线公司都是主力存在，根本没 CentOS 什么事

[PlutoLuna]

抛开业务谈技术都是扯。

用cent os原因主要是几个

1、最早是RedHat系，顺延下来了，教程多，国内一大票鸟哥弟子，前赴后继的就用了。 用QQ举例，不是企鹅做的多好，是它几乎事实垄断，你可以用line啊，可以用whatapps啊，没人跟你聊，你自讨没趣，只能老老实实随大流，除非你就孤芳自赏或者真有能力孤芳自赏。

2、因为1，所以很多企业软件只保证RH or cent os上可用，稳定，所以不得不用。 在用QQ举例子，我qq只保证正版windows上运行稳定正常，你非用什么魔改版，精简版，优化版windows（类比各种linux，Debian，Ubuntu） 当然一般情况下可以用，但是出了事情我可不负责，一句话可以推给你，系统问题。

3、因为是懒（稳定），服务器要的就是稳定，MacOS从10.6 10.8 ，10.11,10.15，个人用户没事更就更了，也没啥大事。但是服务器不行啊，更了有可能软件就用不了，上面举例的Mac下鼎鼎大名的PD都听过吧，更新系统就不能用，还得重新买，你是花钱还是不花钱，旧版能用不？能用干嘛花钱，直接领导给你否了。而且你更新了能保证这么稳定吗？出了事你负责么？

所以只有小公司，没有兼容包袱的，没有庞大用户的，你爱用啥用啥，求的就是一个新，快。那么Ubuntu很好啊，上呗，反正你做个手游要啥稳定，大不了停机维护一晚上，要是QQ，微信也是停机维护一晚上你受得了么？

[fengsi]

1、最早是RedHat系，顺延下来了，教程多，国内一大票鸟哥弟子，前赴后继的就用了。 用QQ举例，不是企鹅做的多好，是它几乎事实垄断，你可以用line啊，可以用whatapps啊，没人跟你聊，你自讨没趣，只能老老实实随大流，除非你就孤芳自赏或者真有能力孤芳自赏。

原文说了 RHEL 不错的，但是用 RHEL 山寨的没有技术支持的 CentOS 就是鸡贼行为。这两者并不矛盾

2、因为1，所以很多企业软件只保证RH or cent os上可用，稳定，所以不得不用。 在用QQ举例子，我qq只保证正版windows上运行稳定正常，你非用什么魔改版，精简版，优化版windows（类比各种linux，Debian，Ubuntu） 当然一般情况下可以用，但是出了事情我可不负责，一句话可以推给你，系统问题。

「一句话可以推给你，系统问题」在技术导向的互联网公司不可能出现。大嘴一张随意甩锅而不提供经得起 peer review 的 root cause 的行为无异于自杀，因为这表明你没有 debug 的能力，且没有责任心，只会推卸责任。这样的认知在一线公司技术岗活不过一周——只要敢甩锅，分分钟被其他组的大牛当面打脸然后上报给公司，同时抄送一圈人鞭尸。很多公司的文化是鼓励 ownership 精神，一个业务出了问题，第一件事不是分清「你」、「我」责任，而是大家一起找到 root cause 之后看怎么解决。以你「系统问题」为例，一定会被别人夺命连环问：

1. 能不能具体描述一下是什么系统问题？
2. 有没有找到原因？
3. 找到原因的话有没有解决方案？
4. 你没有解决方案的话有没有查过 / 问过业界的类似问题？
5. 业界是怎么解决的？
6. 你对业界解决方案的评估如何？技术难度和实现成本如何？

等等。而不是不做任何研究而简单回答「虽然我不知道为什么，但你用 Ubuntu 就是不行」，除非你想被马上开掉（因为你连第一二个问题都无法回答，这表明你不胜任这份工作）

3、因为是懒（稳定），服务器要的就是稳定，MacOS从10.6 10.8 ，10.11,10.15，个人用户没事更就更了，也没啥大事。但是服务器不行啊，更了有可能软件就用不了，上面举例的Mac下鼎鼎大名的PD都听过吧，更新系统就不能用，还得重新买，你是花钱还是不花钱，旧版能用不？能用干嘛花钱，直接领导给你否了。而且你更新了能保证这么稳定吗？出了事你负责么？

近年来的业界实践证明一味靠保守求「稳」的方案是毒瘤，正确的方式是用 CI/CD 保证稳定性。不敢升级是给自己埋雷，人力成本和风险长期来看均不可控，最后一定会恶化到无法维护的绝境

所以只有小公司，没有兼容包袱的，没有庞大用户的，你爱用啥用啥，求的就是一个新，快。那么Ubuntu很好啊，上呗，反正你做个手游要啥稳定，大不了停机维护一晚上，要是QQ，微信也是停机维护一晚上你受得了么？

实际上在湾区无论公司大小，保守不等于稳定已是业界共识，在 Docker / Kubernetes 生态下还非理性坚持用 CentOS 的更是凤毛麟角。Zero downtime 部署早就成为了标配，应该也只有你印象中的「大」公司（实际上是非互联网行业的古董公司）还采用停机维护的方案。不幸的是，CentOS 已经沦落到 PHP 的地步，出现在简历上很可能会被互联网公司扣印象分（当然古董公司请随意）……

[lhb5883]

我觉得CentOS名字已经说清楚了啊，就是一个社区版的RHEL，RH是商标Cent就只能从EL里面取名啊，L大家都是L，没什么区别性，我倒觉得这个名字正好说明了CentOS就是一个RHEL的试用版，让别人在付费之前大概熟悉一下体验，看看有什么坑。 我自己使用下来相对于Ubuntu，CentOS对一些一些奇门的企业硬件支持更好，而且有很多商业Linux软件只有RH系的发布，这些功能值不值得用RHEL是值得商榷的。 用CentOS我觉得从决策上的最大优势还是理论上可以转RHEL，这样如果出了问题，可以甩锅没有订阅RHEL，或者RHEL也没搞定，那就可以甩锅RH都搞不定，那么Linux上都搞不定也不是运维的锅。这种运维招起来应该比较便宜，不过总体成本TCO值得商榷。

[Ansen]

其实大多数公司对系统这一层并不敏感，主要是运维人员的习惯问题，大家都用CentOS，资料比较多~

对于运维来说：用自己熟悉的系统，能更快的解决问题

我们公司最开始用的是 Ubuntu 1404，我慢慢换到 CentOS 7，不用 FreeBSD的原因是：其它两个同事不会这两个系统~

[magicliang]

我从知乎过来的。 我只是来评论一句，我待过的中国互联网公司，都用 CentOS 或者定制过的 CentOS。

[fengsi]

我从知乎过来的。 我只是来评论一句，我待过的中国互联网公司，都用 CentOS 或者定制过的 CentOS。

那你知道三周前 CentOS 已经正式被官方抛弃了吗？这是个可预见的结局。之前那些非要贪小便宜吃大亏闭着眼睛上贼船的公司（包括你提到的公司）现在又将何去何从呢？我很好奇。。。

[balthild]

那你知道三周前 CentOS 已经正式被官方抛弃了吗？这是个可预见的结局。之前那些非要贪小便宜吃大亏闭着眼睛上贼船的公司（包括你提到的公司）现在又将何去何从呢？我很好奇。。。

首先，不是抛弃，而是把 CentOS 的软件包更新策略改成滚动更新（这使得 CentOS 不再像 RHEL 一样具有 ABI stability 的特性），发行策略从下游变为上游（这使得 CentOS 会在 RHEL 之前收到测试补丁和更新）。

其次，CentOS 之父紧接着宣布发行了 Rocky Linux，它实质上就是以前的 CentOS 的延续。

[balthild]

之前评论时只关注了「稳定性」这个概念，没有管其他内容。毕竟我也认同不要用 CentOS 这个结论，而关于 CentOS 绝大多数的指责焦点都在「老旧」与「稳定」的矛盾上，所以我一目十行下来，看到的确有吐槽「稳定性」，就评论解释了一下。现在我重新读了读这篇文章，发现其余部分一些错误之严重，真是让人不知从何谈起，一句句地反驳吧……

---

将 RHEL 用于生产环境的前提是必须付费订阅（最便宜的一档为自助服务，也就是不提供客服），否则只能用于测试和开发。换句话说，只有向红帽支付了过路费才有使用 RHEL 的权力。

最后一个词应该是「权利」而不是「权力」，不过这看起来像是 typo，略去不谈。

RHEL 本身并不是一个一致的整体，而是由很多个小部分组成的，其中每一部分的法律性质都不尽相同。用户购买 RHEL 的订阅，买的不是所谓的「RHEL 的使用权」这种东西，这个概念在法律上是不成立的。这个订阅授权实际上包括几个部分，除了支持服务之外，主要包含的是软件仓库的访问权和私有软件的使用权，前者是服务合同，后者是版权合同。

而除了上述内容之外，RHEL 这个操作系统中最大的组成部分——即自由软件包的这部分——的使用权，不是由 RHEL 订阅的合同授予的，而是任何人原本就通过各个软件的许可证（一般也被称为协议）获得的权利。（请留意合同 contract 和许可证 license 在法律上的区别。）

---

由于 Linux 采用 GPL 许可证，红帽发布的 RHEL 也必须完全开源，尽管不能直接免费使用成品。

两项错误。

首先，RHEL 并不需要完全「开源」，GPL 的「传染性」不是无限的。而且，这个系统中开源的那部分也不完全是（甚至大部分都不是）由于 Linux 的许可证而开源，而是由于其他以 GPL 协议发行的软件包。对 RHEL 中以 GPL 等协议授权的软件包，红帽必须将它（以及红帽针对它编写的 PATCH 等）以相同协议附带源码发行。对于其中以宽松自由许可证（比如 MIT、Apache 等）授权的软件包，或原本就是私有软件的软件包，就不需要「开源」了（不过 RHEL 一般还是把他们保持开源，因为这些软件通常依赖 Fedora 社区的工作）。

其次，「尽管」后面的叙述错误的。GPL 关注的核心是「自由」，而关于自由的第零条规定就是：「无论用户出于何种目的，必须可以按照用户意愿，自由地运行该软件。」因此，对于其中以 GPL（以及其他所有符合「自由」定义的协议，如 MIT、Apache 等）发行的自由软件，任何人只要能获取一份副本，就拥有了使用它的权利，无论他有没有给 RH 付费。

---

历史告诉我们，每当一款开源产品问世，开源社区一定会有一帮思路清奇的人灵机一动，投机取巧专做一些细枝末节的工作，然后包装成自己的成果发布。

果然，觊觎 RHEL 名望的鸡贼志愿者们一顿操作猛如虎，将 RHEL 的源码拿来洗洗，去除 RHEL 专有程序以及其他不「清真」的部分，最后脸也不红地改成自己的品牌，堂而皇之沽名钓誉。

首先，CentOS 的发行方没有做任何把其他人的工作「包装成自己的成果」这种事情。他们从来没有说 CentOS 是自己的杰作，而是从一开始就说明白了，这个系统里面的软件包都是用 RHEL 的源码构建的。他们也没有抹去软件包 metadata 中任何来自 RH（以及 Fedora 社区等任何其他地方）的 maintainer 和 contributor 的信息，而是保留得明明白白，每一个使用者都能看见。甚至在几乎所有软件包中，他们都没有额外地加入独属于 CentOS 发行方的 maintainer 和 contributor 信息，而是原样声明这个软件包完全来自 RHEL 发行方和 Fedora 社区。

第二，CentOS 发行方得最终的产品之所以要改叫 CentOS 而不继续叫 RHEL，不是因为他们乐意抹消 RHEL 的贡献，而是因为 RHEL 是红帽的注册商标，他们没有使用权。

第三，CentOS 要去除 RHEL 中的私有软件，不是因为它「不清真」，而是因为他们不拥有发行这些软件的权利。他们仅仅有发行 RHEL 中采用自由软件协议发行的软件（鉴于自由软件是绝大多数，这已经足够了）。

还有第四点（这一点说的不是原文描述事实有问题，而是修辞上有问题。原文虽然也有描述事实，但很多地方夹带私货，因此我决定也来带一条私货，不过不是夹带，而是明示），这段话刻意地用了贬义的话术来描述事实，以传递一种违背自由软件运动精神的价值观。自由软件运动的基本精神，就是用户应当对软件有使用、复制、修改、再分发这四大自由（或四大权利）。针对行使上述权利的行为本身做出攻击，也是在束缚乃至剥夺用户的这些权利，只不过不是使用法律手段，而是使用道德审判的手段。毫无疑问，这种束缚是违背自由软件精神的，RMS 在其演讲《计算机网络时代的版权与社区之争》中谈到针对「priacy」一词的看法时申明了这一点。

从上述任何一个角度看，CentOS 发行方都没有把他人劳动成果据为己有。他们发行 RHEL 打包的软件包的权利，也是 RHEL 打包者在打包时同意授予的（如果不同意，RHEL 就不会拥有发行这些软件包的权利）。把行使自由软件的复制与再分发权利称为「窃取劳动成果」（作者在评论区中发表的原文如此），是一种诽谤和污蔑——就好比我从你家窗户向你家里扔钱，然后又上网发帖说你抢我的钱一样。

CentOS（以及世界上所有「fork」性质的项目，「fork」可以看作是修改与再分发两个行为的合称）与鸿蒙、木兰等臭名昭著的一类确实属于「窃取劳动成果」的项目之不同，在于后者声称自己拥有「自主知识产权」，否认自己采用了来自其他贡献者的劳动，拒绝履行自由软件协议要求的署名义务（可能还有保持协议一致的义务）。Fork 本身不符合、也不应遭受任何「剽窃」的指责，它本身就是自由软件社群的运作方式，是应当受到鼓励的行为。

若是按照原文的思路，RHEL 也仅仅是做了整理、打包这种与软件本身关系不大的工作，或者加一些「细枝末节」的 PATCH 而已，但它却敢「脸也不红」地发行全世界无数自由软件开发者开发的软件，这岂不是也算「窃取劳动成果」吗？事实上当然不是，因为 RH 完整地履行了包括 GPL 在内的几乎所有自由软件协议都要求的署名义务——CentOS 也是一样。

---

要么付出时间（使用社区免费产品，自己花时间踩坑并回馈社区），要么付出金钱（使用企业付费产品，破财消灾，让别人帮你踩坑）。……而 CentOS 却鼓吹「又要马儿跑，又要马儿不吃草」，我只能说这个思路真是绝佳的中二典范。

很明显的自相矛盾。

在使用 CentOS 时，用户难道真的就不踩坑吗？既然 CentOS 用户会踩到坑，那么也就不存在「不回馈社区」、「又要马儿跑，又要马儿不吃草」的问题，上报 bug 本身就是在回馈社区。

而如果 CentOS 真的没有坑，那岂不是就意味着「又要马儿跑，又要马儿不吃草」是可行的？这又与你前面说的「要么付出……要么付出」矛盾。

也许 CentOS 的支持者的确有人鼓吹它坑少，但「少坑」并不意味着「没坑」。哪怕少坑也是有坑，只要有人踩，就是在回馈社区。反正我是从没见过有人敢说 CentOS 完全没坑的。

---

大致就是这样。除此之外，那些技术上的批判，我大多都赞同。

[magicliang]

我从知乎过来的。 我只是来评论一句，我待过的中国互联网公司，都用 CentOS 或者定制过的 CentOS。

那你知道三周前 CentOS 已经正式被官方抛弃了吗？这是个可预见的结局。之前那些非要贪小便宜吃大亏闭着眼睛上贼船的公司（包括你提到的公司）现在又将何去何从呢？我很好奇。。。

我知道 CentOS 已经被 CentOS Stream 替代了。 但这些大公司都有自己的内核团队，可以自己解决这个问题。

我说的大公司，包括阿里巴巴

[fengsi]

我从知乎过来的。 我只是来评论一句，我待过的中国互联网公司，都用 CentOS 或者定制过的 CentOS。

那你知道三周前 CentOS 已经正式被官方抛弃了吗？这是个可预见的结局。之前那些非要贪小便宜吃大亏闭着眼睛上贼船的公司（包括你提到的公司）现在又将何去何从呢？我很好奇。。。

我知道 CentOS 已经被 CentOS Stream 替代了。 但这些大公司都有自己的内核团队，可以自己解决这个问题。

我说的大公司，包括阿里巴巴

与你理解的相反，云生态其实与 Linux 内核关系不大，更多着力点是在编排和自动化，总体来说就是更高的抽象。RHEL 这样的发行版从本质上来说是上一代的抽象实践，也就是把松散的 Linux 内核、GNU 套件以及各种开源软件整合在一起。在云生态下，你可以把发行版这一整套想象成这个生态的「内核」这个概念

CentOS 已经成了无源之水无本之木，这一套山寨实践注定会没落。你要是有过选型相关决策经验，一定会马上意识到单靠公司的力量维护自己的 fork 是非常困难的，继续投入 CentOS 一定会是沉没成本，而且技术债一定会越积越多，以后被迫转型的成本大概率会指数级增加

这时候需要立马砍掉 CentOS 相关组，给六个月技术迁移，给十二到十八个月业务迁移。能做的留下，不能做的卷铺盖走人，这是个非常好做的决定。即便是阿里，与业界趋势对抗是不可能成功的。况且阿里在 Linux 发行版社区影响力几乎为零，在这个话题上强行提到阿里难道不会觉得别扭？

国内公司无论规模大小，对于 CentOS 和 Java 更多的是盲目崇拜而不是理性分析。这也是为什么今天业界去 CentOS / Java 化的趋势已经如此明显了，仍然能碰到生活在自己世界里三句话不离 CentOS / Java 的人。。。

[magicliang]

我从知乎过来的。 我只是来评论一句，我待过的中国互联网公司，都用 CentOS 或者定制过的 CentOS。

那你知道三周前 CentOS 已经正式被官方抛弃了吗？这是个可预见的结局。之前那些非要贪小便宜吃大亏闭着眼睛上贼船的公司（包括你提到的公司）现在又将何去何从呢？我很好奇。。。

我知道 CentOS 已经被 CentOS Stream 替代了。 但这些大公司都有自己的内核团队，可以自己解决这个问题。 我说的大公司，包括阿里巴巴

与你理解的相反，云生态其实与 Linux 内核关系不大，更多着力点是在编排和自动化，总体来说就是更高的抽象。RHEL 这样的发行版从本质上来说是上一代的抽象实践，也就是把松散的 Linux 内核、GNU 套件以及各种开源软件整合在一起。在云生态下，你可以把发行版这一整套想象成这个生态的「内核」这个概念

CentOS 已经成了无源之水无本之木，这一套山寨实践注定会没落。你要是有过选型相关决策经验，一定会马上意识到单靠公司的力量维护自己的 fork 是非常困难的，继续投入 CentOS 一定会是沉没成本，而且技术债一定会越积越多，以后被迫转型的成本大概率会指数级增加

这时候需要立马砍掉 CentOS 相关组，给六个月技术迁移，给十二到十八个月业务迁移。能做的留下，不能做的卷铺盖走人，这是个非常好做的决定。即便是阿里，与业界趋势对抗是不可能成功的。况且阿里在 Linux 发行版社区影响力几乎为零，在这个话题上强行提到阿里难道不会觉得别扭？

国内公司无论规模大小，对于 CentOS 和 Java 更多的是盲目崇拜而不是理性分析。这也是为什么今天业界去 CentOS / Java 化的趋势已经如此明显了，仍然能碰到生活在自己世界里三句话不离 CentOS / Java 的人。。。

我不知道你理解的是什么。

在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。

在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。

不必过度解读厂商对这个问题的投入。

而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。

说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

[fengsi]

我不知道你理解的是什么。

在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。

在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。

不必过度解读厂商对这个问题的投入。

而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。

说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

抛开技术细节，降低成本的一个方案是提高效率，而提高效率的一个方案是提升抽象级别。老系统是可以跑而且也可以很稳定，但是抽象级别没办法提升，就只能停留在低效率的水平。你所谓「投入最低，产出最高」是站在懒人的角度，自己熟悉的东西没有学习成本所以看不到再降低成本的空间。而站在资本家的角度，打工人分分钟可以替代，更高抽象级别的方案长期来看能节省更多费用，这些都是有数字支撑的可以量化的。等别的系统都迁移好了，接下来等着被开刀的就是 legacy 团队，回头市面上一看大家都不再需要这个技术，那时候再转已经来不及了。这都是常规操作

「非操作系统团队的工程师没有什么置喙的空间」大错特错。操作系统是为业务服务的，不能满足业务升级的操作系统团队留着何用？

[magicliang]

我不知道你理解的是什么。 在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。 在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。 不必过度解读厂商对这个问题的投入。 而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。 说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

抛开技术细节，降低成本的一个方案是提高效率，而提高效率的一个方案是提升抽象级别。老系统是可以跑而且也可以很稳定，但是抽象级别没办法提升，就只能停留在低效率的水平。你所谓「投入最低，产出最高」是站在懒人的角度，自己熟悉的东西没有学习成本所以看不到再降低成本的空间。而站在资本家的角度，打工人分分钟可以替代，更高抽象级别的方案长期来看能节省更多费用，这些都是有数字支撑的可以量化的。等别的系统都迁移好了，接下来等着被开刀的就是 legacy 团队，回头市面上一看大家都不再需要这个技术，那时候再转已经来不及了。这都是常规操作

「非操作系统团队的工程师没有什么置喙的空间」大错特错。操作系统是为业务服务的，不能满足业务升级的操作系统团队留着何用？

我不知道你在阿里巴巴之类的大厂待过没有，我没有见过你上面这段话说的情况，我很怀疑你打那么多字都是想象出来的。

如果你拿着“大错特错”的这段话去面试这些大厂，我认为面试官会直接否决你（因为我也当过面试官）。

我只讲一点，非操作系统团队的工程师，不需要学习任何操作系统内部的特性，只要熟悉自己技术框架的复杂性就行了。因为操作系统和技术框架的复杂度，是交给虚拟机和容器制作者来 cover 的，这个才叫 technical stack。上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层，这不是“为了证明自己勤奋而不是懒惰”，而是愚蠢。上层业务应该假设自己的服务一次编写，到处运行，应该假设自己的服务对下层依赖是透明的（也就是说，假设自己的服务程序可以在 CentOS 4.0 上跑也可以正确运行），做不到这一点，反而会出问题。

[magicliang]

我不知道你理解的是什么。 在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。 在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。 不必过度解读厂商对这个问题的投入。 而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。 说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

抛开技术细节，降低成本的一个方案是提高效率，而提高效率的一个方案是提升抽象级别。老系统是可以跑而且也可以很稳定，但是抽象级别没办法提升，就只能停留在低效率的水平。你所谓「投入最低，产出最高」是站在懒人的角度，自己熟悉的东西没有学习成本所以看不到再降低成本的空间。而站在资本家的角度，打工人分分钟可以替代，更高抽象级别的方案长期来看能节省更多费用，这些都是有数字支撑的可以量化的。等别的系统都迁移好了，接下来等着被开刀的就是 legacy 团队，回头市面上一看大家都不再需要这个技术，那时候再转已经来不及了。这都是常规操作 「非操作系统团队的工程师没有什么置喙的空间」大错特错。操作系统是为业务服务的，不能满足业务升级的操作系统团队留着何用？

我不知道你在阿里巴巴之类的大厂待过没有，我没有见过你上面这段话说的情况，我很怀疑你打那么多字都是想象出来的。

如果你拿着“大错特错”的这段话去面试这些大厂，我认为面试官会直接否决你（因为我也当过面试官）。

我只讲一点，非操作系统团队的工程师，不需要学习任何操作系统内部的特性，只要熟悉自己技术框架的复杂性就行了。因为操作系统和技术框架的复杂度，是交给虚拟机和容器制作者来 cover 的，这个才叫 technical stack。上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层，这不是“为了证明自己勤奋而不是懒惰”，而是愚蠢。上层业务应该假设自己的服务一次编写，到处运行，应该假设自己的服务对下层依赖是透明的（也就是说，假设自己的服务程序可以在 CentOS 4.0 上跑也可以正确运行），做不到这一点，反而会出问题。

而且， 业务团队自己给操作系统团队提需求说，我要这个高版本 Linux 内核的功能，纯粹是班门弄斧，jvm 团队提这种需求还差不多。

而且现在大厂的效率提升的方式多了，容器化、虚拟化超卖、混合部署，根本没有必要追求若干 API 和 ABI 级别的特性提升。即使是精细化运营的谷歌，主机利用率也不过百分之二十几（我上次看这个数据是几年前，如果有错欢迎指正）。指望靠升级操作系统来压榨硬件性能进而换取成本优化，近乎空想，而升级操作系统版本带来的 broken change 的不可预测性的成本，反而是资本家们不愿意负担的。

上面这一段话，实际上也解释了行业现状的一个动机：为什么传统的电信、金融行业的机房，不跟着 mainstream 的操作系统发布而滚动更新自己的系统。因为他们像你所说的一样，不思进取吗？不是的，因为他们精算过，这样划不来。

别把别人想得那么蠢，任何一个能够组建几十人团队的公司，总能得到投入产出比适合他们的方案。

[fengsi]

我不知道你理解的是什么。 在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。 在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。 不必过度解读厂商对这个问题的投入。 而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。 说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

抛开技术细节，降低成本的一个方案是提高效率，而提高效率的一个方案是提升抽象级别。老系统是可以跑而且也可以很稳定，但是抽象级别没办法提升，就只能停留在低效率的水平。你所谓「投入最低，产出最高」是站在懒人的角度，自己熟悉的东西没有学习成本所以看不到再降低成本的空间。而站在资本家的角度，打工人分分钟可以替代，更高抽象级别的方案长期来看能节省更多费用，这些都是有数字支撑的可以量化的。等别的系统都迁移好了，接下来等着被开刀的就是 legacy 团队，回头市面上一看大家都不再需要这个技术，那时候再转已经来不及了。这都是常规操作 「非操作系统团队的工程师没有什么置喙的空间」大错特错。操作系统是为业务服务的，不能满足业务升级的操作系统团队留着何用？

我不知道你在阿里巴巴之类的大厂待过没有，我没有见过你上面这段话说的情况，我很怀疑你打那么多字都是想象出来的。

如果你拿着“大错特错”的这段话去面试这些大厂，我认为面试官会直接否决你（因为我也当过面试官）。

我只讲一点，非操作系统团队的工程师，不需要学习任何操作系统内部的特性，只要熟悉自己技术框架的复杂性就行了。因为操作系统和技术框架的复杂度，是交给虚拟机和容器制作者来 cover 的，这个才叫 technical stack。上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层，这不是“为了证明自己勤奋而不是懒惰”，而是愚蠢。上层业务应该假设自己的服务一次编写，到处运行，应该假设自己的服务对下层依赖是透明的（也就是说，假设自己的服务程序可以在 CentOS 4.0 上跑也可以正确运行），做不到这一点，反而会出问题。

你接触过的 scope 是不是太小了？我大小厂都干过，还自己开公司，你可以说我是打工人和资本家双重身份。你不会看 LinkedIn 的？

[magicliang]

我不知道你理解的是什么。 在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。 在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。 不必过度解读厂商对这个问题的投入。 而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。 说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

抛开技术细节，降低成本的一个方案是提高效率，而提高效率的一个方案是提升抽象级别。老系统是可以跑而且也可以很稳定，但是抽象级别没办法提升，就只能停留在低效率的水平。你所谓「投入最低，产出最高」是站在懒人的角度，自己熟悉的东西没有学习成本所以看不到再降低成本的空间。而站在资本家的角度，打工人分分钟可以替代，更高抽象级别的方案长期来看能节省更多费用，这些都是有数字支撑的可以量化的。等别的系统都迁移好了，接下来等着被开刀的就是 legacy 团队，回头市面上一看大家都不再需要这个技术，那时候再转已经来不及了。这都是常规操作 「非操作系统团队的工程师没有什么置喙的空间」大错特错。操作系统是为业务服务的，不能满足业务升级的操作系统团队留着何用？

我不知道你在阿里巴巴之类的大厂待过没有，我没有见过你上面这段话说的情况，我很怀疑你打那么多字都是想象出来的。 如果你拿着“大错特错”的这段话去面试这些大厂，我认为面试官会直接否决你（因为我也当过面试官）。 我只讲一点，非操作系统团队的工程师，不需要学习任何操作系统内部的特性，只要熟悉自己技术框架的复杂性就行了。因为操作系统和技术框架的复杂度，是交给虚拟机和容器制作者来 cover 的，这个才叫 technical stack。上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层，这不是“为了证明自己勤奋而不是懒惰”，而是愚蠢。上层业务应该假设自己的服务一次编写，到处运行，应该假设自己的服务对下层依赖是透明的（也就是说，假设自己的服务程序可以在 CentOS 4.0 上跑也可以正确运行），做不到这一点，反而会出问题。

你接触过的 scope 是不是太小了？我大小厂都干过，还自己开公司，你可以说我是打工人和资本家双重身份。你不会看 LinkedIn 的？

我确实不会看 LinkedIn，也确实没有接触过多大的 scope。

既然你大厂小厂都干过，能否举个例子，业务团队什么情况下会去跟操作系统团队提需求，我需要这个版本的发行版？

我先说我自己： 我也在大小公司呆过，国内国外都有（国外的公司只能算 tier 2，不提也罢），不过我只是打工人。我没有见过任何一个这样的例子。

[fengsi]

我不知道你理解的是什么。 在国内，用什么操作系统，纯粹是一个商业决策的问题，用投入最低，产出最高的操作系统就是最贪婪的资本家最简单的选择。 在之前，CentOS 被大规模采用不是因为它技术上有什么过人之处，什么伟大的开源理想，是因为它的质量，最接近业界的企业操作系统的冠军，RHEL，就这么简单。 不必过度解读厂商对这个问题的投入。 而且业界到底会怎么转，这是操作系统团队自己要研究的事情了。像阿里有自己的内核团队，完全可能自己（只是存在这个可能，不必然这么做）维护一个 CentOS 的 fork，既不是原本的 CentOS，也可以 Merge from CentOS Stream。而且其实 BAT 内部有很多很老的发行版系统还一直在跑，根本没必要追新的发行版，CentOS5、6、7 甚至可能再跑很多年。 说到底，这只是一个咸吃萝卜淡操心的事情，非操作系统团队的工程师没有什么置喙的空间。

抛开技术细节，降低成本的一个方案是提高效率，而提高效率的一个方案是提升抽象级别。老系统是可以跑而且也可以很稳定，但是抽象级别没办法提升，就只能停留在低效率的水平。你所谓「投入最低，产出最高」是站在懒人的角度，自己熟悉的东西没有学习成本所以看不到再降低成本的空间。而站在资本家的角度，打工人分分钟可以替代，更高抽象级别的方案长期来看能节省更多费用，这些都是有数字支撑的可以量化的。等别的系统都迁移好了，接下来等着被开刀的就是 legacy 团队，回头市面上一看大家都不再需要这个技术，那时候再转已经来不及了。这都是常规操作 「非操作系统团队的工程师没有什么置喙的空间」大错特错。操作系统是为业务服务的，不能满足业务升级的操作系统团队留着何用？

我不知道你在阿里巴巴之类的大厂待过没有，我没有见过你上面这段话说的情况，我很怀疑你打那么多字都是想象出来的。 如果你拿着“大错特错”的这段话去面试这些大厂，我认为面试官会直接否决你（因为我也当过面试官）。 我只讲一点，非操作系统团队的工程师，不需要学习任何操作系统内部的特性，只要熟悉自己技术框架的复杂性就行了。因为操作系统和技术框架的复杂度，是交给虚拟机和容器制作者来 cover 的，这个才叫 technical stack。上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层，这不是“为了证明自己勤奋而不是懒惰”，而是愚蠢。上层业务应该假设自己的服务一次编写，到处运行，应该假设自己的服务对下层依赖是透明的（也就是说，假设自己的服务程序可以在 CentOS 4.0 上跑也可以正确运行），做不到这一点，反而会出问题。

而且， 业务团队自己给操作系统团队提需求说，我要这个高版本 Linux 内核的功能，纯粹是班门弄斧，jvm 团队提这种需求还差不多。

而且现在大厂的效率提升的方式多了，容器化、虚拟化超卖、混合部署，根本没有必要追求若干 API 和 ABI 级别的特性提升。即使是精细化运营的谷歌，主机利用率也不过百分之二十几（我上次看这个数据是几年前，如果有错欢迎指正）。指望靠升级操作系统来压榨硬件性能进而换取成本优化，近乎空想，而升级操作系统版本带来的 broken change 的不可预测性的成本，反而是资本家们不愿意负担的。

上面这一段话，实际上也解释了行业现状的一个动机：为什么传统的电信、金融行业的机房，不跟着 mainstream 的操作系统发布而滚动更新自己的系统。因为他们像你所说的一样，不思进取吗？不是的，因为他们精算过，这样划不来。

别把别人想得那么蠢，任何一个能够组建几十人团队的公司，总能得到投入产出比适合他们的方案。

我比较反感动不动就拿自己公司说事的人。不过既然你多次非要有意无意提大厂，那至少也花几秒钟时间扫一下我的 LinkedIn 大概了解我是干嘛的再说岂不是更好？我带的项目有一个就是砍一堆 legacy 然后往容器迁移，再细就不能详说了。业务、infra 都做，title 和 level 摆在那你自己看，还不知道是谁面谁。。。😅

「业务团队什么情况下会去跟操作系统团队提需求，我需要这个版本的发行版？」例子再简单不过：AI / ML 用 CentOS 不灵，大多都是上 Debian / Ubuntu。你提的这个问题只能反映出一个事实，就是你完全没接触过 AI / ML 的项目。。。🤦

[magicliang]

我比较反感动不动就拿自己公司说事的人。不过既然你多次非要有意无意提大厂，那至少也花几秒钟时间扫一下我的 LinkedIn 大概了解我是干嘛的再说岂不是更好？我带的项目就是砍一堆 legacy 然后往容器迁移，再细就不能详说了。Level 你自己看，不知道是谁面谁

我也不喜欢提大厂，我也不喜欢大厂背书，但既然总是提到容器的大规模应用，我不得不举大厂的例子。因为只有这种大厂，特别是阿里巴巴，特别喜欢提他们的 web scale 是世界上迭代速度超级快的一种（当然这未必是对的，也和国内的 996 文化有关，并不值得过度解读），他们特别看重稳定稳定稳定。即使你的 title level 很高，你去面试的时候去跟面试官这样讲业务和 infra 的关系，也非常容易得到 strong negative 的 feedback。这倒是这 level 和 title 无关，这是商业策略的问题。

我也恰好都在业务和 infra 做过，我也恰好迁移过 legacy 到 docker 过，我也因为 CentOS 不行自己在 baremetal 上搭建过特殊的业务环境。 我知道 TensorFlow 之类的项目是必须在 Ubuntu 上运行的。

但因为 TensorFlow 而给环境团队提需求，恰恰不是业务团队的职责，而是 Infra 自己的职责，业务团队的算法工程师的需求其实很简单，我要 xxx 版本的 Tensorflow ，而不是我要 xxx 版本的发行版，我就是要 apt-get - 当然这是在国内，我不清楚国外到底 DevOps 怎么分工的，到底 fullstak 到什么地步了。

[fengsi]

我比较反感动不动就拿自己公司说事的人。不过既然你多次非要有意无意提大厂，那至少也花几秒钟时间扫一下我的 LinkedIn 大概了解我是干嘛的再说岂不是更好？我带的项目就是砍一堆 legacy 然后往容器迁移，再细就不能详说了。Level 你自己看，不知道是谁面谁

我也不喜欢提大厂，我也不喜欢大厂背书，但既然总是提到容器的大规模应用，我不得不举大厂的例子。因为只有这种大厂，特别是阿里巴巴，特别喜欢提他们的 web scale 是世界上迭代速度超级快的一种（当然这未必是对的，也和国内的 996 文化有关，并不值得过度解读），他们特别看重稳定稳定稳定。即使你的 title level 很高，你去面试的时候去跟面试官这样讲业务和 infra 的关系，也非常容易得到 strong negative 的 feedback。这倒是这 level 和 title 无关，这是商业策略的问题。

我也恰好都在业务和 infra 做过，我也恰好迁移过 legacy 到 docker 过，我也因为 CentOS 不行自己在 baremetal 上搭建过特殊的业务环境。 我知道 TensorFlow 之类的项目是必须在 Ubuntu 上运行的。

但因为 TensorFlow 而给环境团队提需求，恰恰不是业务团队的职责，而是 Infra 自己的职责，业务团队的算法工程师的需求其实很简单，我要 xxx 版本的 Tensorflow ，而不是我要 xxx 版本的发行版，我就是要 apt-get - 当然这是在国内，我不清楚国外到底 DevOps 怎么分工的，到底 fullstak 到什么地步了。

招人的时候要是看到简历上满篇的 CentOS 那基本没戏，因为很多软件的官方镜像大部分是 Debian / Ubuntu / Alpine 的 base，CentOS 偶尔才会出现。另一方面，固守 CentOS 的人对公司来讲往往是一个很大的隐患，一定程度上反映了这个人对新事物的接受能力，所以那些容器组的人特别不欢迎 CentOS 以及 Java 背景的项目。运维的人，简历上有显示自己「折腾」能力的反而会大大加分，例如 Arch Linux

国内 996 风气你不妨这么解读：正因为很多业务停留在低抽象程度，所以需要很多人重复无意义的劳动，所以需要更多的加班时间，所以造成了极高的内卷，而不是提高效率把人解放出来。稳定不是靠保守，稳定靠的是更完善的测试、更短的错误响应时间以及更快的迭代，这些都需要大量的自动化而不是几个胆小怕事的运维

「上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层」这句话我真的看懵了。何来「越级」？我工作的几个公司都可以找任何部门任何人包括 CEO 直接沟通，有任何不合理的地方只要是对公司有利的都可以提出建议，有什么级不级的？数字可以量化，不服可以直接 A/B 测试。团队是手段，是为了实现目标，但团队本身不是目的。你这个想法真是本末倒置了

[magicliang]

我比较反感动不动就拿自己公司说事的人。不过既然你多次非要有意无意提大厂，那至少也花几秒钟时间扫一下我的 LinkedIn 大概了解我是干嘛的再说岂不是更好？我带的项目就是砍一堆 legacy 然后往容器迁移，再细就不能详说了。Level 你自己看，不知道是谁面谁

我也不喜欢提大厂，我也不喜欢大厂背书，但既然总是提到容器的大规模应用，我不得不举大厂的例子。因为只有这种大厂，特别是阿里巴巴，特别喜欢提他们的 web scale 是世界上迭代速度超级快的一种（当然这未必是对的，也和国内的 996 文化有关，并不值得过度解读），他们特别看重稳定稳定稳定。即使你的 title level 很高，你去面试的时候去跟面试官这样讲业务和 infra 的关系，也非常容易得到 strong negative 的 feedback。这倒是这 level 和 title 无关，这是商业策略的问题。 我也恰好都在业务和 infra 做过，我也恰好迁移过 legacy 到 docker 过，我也因为 CentOS 不行自己在 baremetal 上搭建过特殊的业务环境。 我知道 TensorFlow 之类的项目是必须在 Ubuntu 上运行的。 但因为 TensorFlow 而给环境团队提需求，恰恰不是业务团队的职责，而是 Infra 自己的职责，业务团队的算法工程师的需求其实很简单，我要 xxx 版本的 Tensorflow ，而不是我要 xxx 版本的发行版，我就是要 apt-get - 当然这是在国内，我不清楚国外到底 DevOps 怎么分工的，到底 fullstak 到什么地步了。

招人的时候要是看到简历上满篇的 CentOS 那基本没戏，因为很多软件的官方镜像大部分是 Debian / Ubuntu / Alpine 的 base，CentOS 偶尔才会出现。另一方面，固守 CentOS 的人对公司来讲往往是一个很大的隐患，一定程度上反映了这个人对新事物的接受能力，所以那些容器组的人特别不欢迎 CentOS 以及 Java 背景的项目。运维的人，简历上有显示自己「折腾」能力的反而会大大加分，例如 Arch Linux

国内 996 风气你不妨这么解读：正因为很多业务停留在低抽象程度，所以需要很多人重复无意义的劳动，所以需要更多的加班时间，所以造成了极高的内卷，而不是提高效率把人解放出来。稳定不是靠保守，稳定靠的是更完善的测试、更短的错误响应时间以及更快的迭代，这些都需要大量的自动化而不是几个胆小怕事的运维

「上层 stack 的工程师去越级学习下层的技术细节，是在破坏资本家设计的团队分层」这句话我真的看懵了。何来「越级」？我工作的几个公司都可以找任何部门任何人包括 CEO 直接沟通，有任何不合理的地方只要是对公司有利的都可以提出建议，有什么级不级的？数字可以量化，不服可以直接 A/B 测试。团队是手段，是为了实现目标，但团队本身不是目的。你这个想法真是本末倒置了

我觉得讨论技术最好不要有门户之见（我也力图做到这一点，我指出问题的方式也许也使用门户之见的方法，但这并不是我的本意）。每一个 distro 都有它的 big fan 或者黑子，在我看来这都是开源宗教的余音，有好有坏，但 big fan 或者黑子的言论有时候是事实，有时候只是观点。观点是对是错，尽量进入客体环境来讨论，脱离环境谈选择很空泛。

我尽量廓清一些事实：

1. 国内的大公司使用的操作系统的发行版，据我所知（班门弄斧一下），都是根据 release 出来的 code 自己编译，连官方校验和相关的镜像都不相信，所有的关键依赖也都自己做了自己的 mirror，不依赖于开源环境的 artifact。这么做的目的是：
   1. 使用自己构建的关键 artifact 符合安全策略。
   2. 需要自己定制一些关键的 artifact。
2. 这时候使用 CentOS 的优势就体现出来了，整个 CentOS 的 upstream 经过商业团队的测试，大家都在共用一套 packages。大公司只要确保关键的部分的稳定性自己能够掌控得好，其他的 SLA 交给 RHEL 自己保证。
3. 诚然，现在的各种其他发行版都提供了很多折腾的可能性（我自己就折腾过 Alpine，我没用过 arch，我连 ubuntu 升级 LTS 桌面会崩我都搞不定）。但新兴的发行版现在只向市场证明了他们的潜力，他们的稳定性并没有在足够大的商业环境里面反复论证过，这种风险是资本家极度厌恶的。
4. 即使有一天出现了足够好的发行版，能够理论上提供更好的稳定性，国内的大公司【这里先限定一个范围】的迁移 technical stack 的成本也极高，这需要先让全环境的运维都自动化，而且所有升级的 broken change 理论上都可以 cover 得住，这些大厂才会这样做。但这种 broken change 的影响可能极其深远，大厂也未必有足够多的高手有足够多的功夫来一一评估。到这里我们其实可以讨论出一种惰性，这种惰性背后有一种动机：can't afford it。
5. “正因为很多业务停留在低抽象程度，所以需要很多人重复无意义的劳动，所以需要更多的加班时间”。这句话其实既是一种事实，也是一种观点。事实上，国内的很多业务的抽象程度都很低，所以制造了很多 CRUD boys，但这不止和技术水平有关，也是一种 MVP 创业模式下的刻意选择。在人月神话那个时代，写可复用代码的成本是不可复用代码的成本的三倍，如果你在国内互联网公司上班，你面临的实际的市场情况是：一家大电商公司一年要尝试几十个新业务，每个新业务只有几名懂一点数据库和业务框架的工程师堆砌起来，不必谈分析模式、DDD，大家就最快速度抢占市场，整个团队是没有架构模式可言的，也就谈不上追求公司级的重新抽象，谁也支付不起三倍的成本-当然也不是没有，但那是另一个问题了。实际上业务团队是有向 infra 团队提各种定制环境的需求的，各种奇怪的定制 os，定制中间件，非标的存储，都是这么来的，这些 artifact 只是这些需求的副作用，业务团队需要的结果实际上很抽象，我就是要更稳定、更快、低延迟、强一致，仅此而已。这是国内电商公司的怪圈。这又回到了上面谈的惰性与动机：can't afford it。
6. 这种怪圈下的技术路径扭曲，有政治因素，有商业因素，不能拿技术的尺子去量商业决策者画出的线，应该正视这些因素。
7. 我们如果要在这里谈稳定，不等于谈保守。当然保守是稳定的最佳策略之一。“更完善的测试、更短的错误响应时间以及更快的迭代”这当然是国内也正在发生的事情，但国内的大公司的老板事实上并不是 bezos 式的老板，他们尊重技术规律，但并不一定追求前沿。事实上，在 CentOS 被抛弃以前，选择 CentOS 才恰恰是在追求“更完善的测试、更短的错误响应时间以及更快的迭代”，国内的公司之所以选择 CentOS，很有在白嫖 RHEL 上的测试工程师的劳动价值的感觉。世界上没有比白嫖更加自动化的方案了。这是一种鸡贼吧。假设 CentOS 没有被收购，也没有从 down stream 变成 middle stream，这些大厂的工程师根本没有兴趣去讨论其他任何非企业级的解决方案（Ubuntu 现在勉强算了，我认为 arch 不算，当然，这在社区里现在有没有公论，我不知道）。
8. 软件设计之所以要分层，就是为了 encapsulate，每一层的封装去掉了一些细节，更上层才足够敏捷。每一层之间通过 contract talk，decoupling 才算做得足够好（这不能算放之四海皆准，但大部分时候是准的）。用一个老少咸宜的例子来说明这个问题的话：假设我是使用 http 协议的应用服务器的 SDE，我该不该利用某个 tcp packet 里的特性（比如，某一种非标准 OS 里面才有的 domain socket 才有的某一种特性），做出某些设计？我如果做了这种设计，当然可以说是破坏了分层设计，越级去学习了下级的细节。这种设计首先不是组织架构上的（但最终会反馈回组织架构的沟通流的控制反转上），但却让整个设计变重，变具体了，好的架构师当然不取（当然，什么是好的架构师，也是一个开放性问题，此处姑且先抛砖引玉）。
9. 更重要的是，现在国内电商公司所谓的“敏捷”，是大兵团下小团队作战的方式，大部分团队的 kpi 是完不成的，去做 8 里面的 over design，performance review 的时候只会被嗤之以鼻，在这种环境下，谈“a/b测试”是无意义的，因为冒险会耗尽团队的资源，这时候保守的重要性就体现出来了。
10. 根据 7、8、9，我也经常说我们公司的各种环境不够好，但除非我能够拿出非常准确的数字，来说明要追求高版本的 Linux 有价值，否则我绝不会跟 infra 提出自取其辱的需求。毕竟，国内很多公司认为自己的 web scale 是世界级的了，双十一已经证明了 CentOS 6、7 也足够顶得住业务需求。这等于，业务对于这种环境，没有需求。

[magicliang]

我还得补充一下，这种危如累卵的架构开发方式，并不能算是国内独有的，毕竟，muddy ball 和 shit mountain 并不是软件工程研究者研究阿里巴巴之类公司得出的结果。

对于资本家而言，如果可能采取技术密集型的做法，堆高精尖的技术得到高投入产出比，就去做；否则，就堆人力，用劳动密集型的思路来解决任何问题。

杰克马和 bezos 手下的工程师疲劳程度差别如此之大，但这两人都一样有钱。资本家只要手里有钱，他们看问题定策略的方式，其实没有贵贱之分-比如，你能说一将功成万骨枯的将军不懂管理么？

[fengsi]

我还得补充一下，这种危如累卵的架构开发方式，并不能算是国内独有的，毕竟，muddy ball 和 shit mountain 并不是软件工程研究者研究阿里巴巴之类公司得出的结果。

对于资本家而言，如果可能采取技术密集型的做法，堆高精尖的技术得到高投入产出比，就去做；否则，就堆人力，用劳动密集型的思路来解决任何问题。

杰克马和 bezos 手下的工程师疲劳程度差别如此之大，但这两人都一样有钱。资本家只要手里有钱，他们看问题定策略的方式，其实没有贵贱之分-比如，你能说一将功成万骨枯的将军不懂管理么？

很多时候思维的僵化是不自知的。Tesla 搞出电车标杆之前被一众老牌车厂嘲笑，SpaceX 搞出 Falcon 和 Dragon 之前被一众老牌航天企业嘲笑，都是活生生的例子。前一个不方便说，后一个 SpaceX Dragon 的操控系统直接上了 JavaScript 实现界面，和 web 前端没有本质区别——这是之前开发团队公开交流时候说的。要放在传统航天界，别说引入 web 技术，就是加一个触摸屏都可以被口水淹死。要类比的话，那就是把你所谓资本家最爱的 CentOS 生产系统直接给换成 macOS 还整个图形界面来操作，完全没 Linux 什么事，那还不得把资本家都吓死？

新技术稳定吗？那是相当稳定，就问一句阿里双十一双十二稳定性要求能有载人航天高？不服不行 新技术牛吗？那是相当牛，直接淘汰各种乱七八糟的控制界面，降低成本的同时还变相减少了出错概率，更稳定了。不服不行

密集型思路也许可以解决双十一双十二 scaling 问题，反正堆机器说到底又不是什么 rocket science。但是你非要靠这个路子去搞 rocket science，那得向天再借五百年

[magicliang]

我还得补充一下，这种危如累卵的架构开发方式，并不能算是国内独有的，毕竟，muddy ball 和 shit mountain 并不是软件工程研究者研究阿里巴巴之类公司得出的结果。 对于资本家而言，如果可能采取技术密集型的做法，堆高精尖的技术得到高投入产出比，就去做；否则，就堆人力，用劳动密集型的思路来解决任何问题。 杰克马和 bezos 手下的工程师疲劳程度差别如此之大，但这两人都一样有钱。资本家只要手里有钱，他们看问题定策略的方式，其实没有贵贱之分-比如，你能说一将功成万骨枯的将军不懂管理么？

很多时候思维的僵化是不自知的。Tesla 搞出电车标杆之前被一众老牌车厂嘲笑，SpaceX 搞出 Falcon 和 Dragon 之前被一众老牌航天企业嘲笑，都是活生生的例子。前一个不方便说，后一个 SpaceX Dragon 的操控系统直接上了 JavaScript 实现界面，和 web 前端没有本质区别——这是之前开发团队公开交流时候说的。要放在传统航天界，别说引入 web 技术，就是加一个触摸屏都可以被口水淹死。要类比的话，那就是把你所谓资本家最爱的 CentOS 生产系统直接给换成 macOS 还整个图形界面来操作，完全没 Linux 什么事，那还不得把资本家都吓死？

新技术稳定吗？那是相当稳定，就问一句阿里双十一双十二稳定性要求能有载人航天高？不服不行 新技术牛吗？那是相当牛，直接淘汰各种乱七八糟的控制界面，降低成本的同时还变相减少了出错概率，更稳定了。不服不行

密集型思路也许可以解决双十一双十二 scaling 问题，反正堆机器说到底又不是什么 rocket science。但是你非要靠这个路子去搞 rocket science，那得向天再借五百年

我还得补充一下，这种危如累卵的架构开发方式，并不能算是国内独有的，毕竟，muddy ball 和 shit mountain 并不是软件工程研究者研究阿里巴巴之类公司得出的结果。 对于资本家而言，如果可能采取技术密集型的做法，堆高精尖的技术得到高投入产出比，就去做；否则，就堆人力，用劳动密集型的思路来解决任何问题。 杰克马和 bezos 手下的工程师疲劳程度差别如此之大，但这两人都一样有钱。资本家只要手里有钱，他们看问题定策略的方式，其实没有贵贱之分-比如，你能说一将功成万骨枯的将军不懂管理么？

很多时候思维的僵化是不自知的。Tesla 搞出电车标杆之前被一众老牌车厂嘲笑，SpaceX 搞出 Falcon 和 Dragon 之前被一众老牌航天企业嘲笑，都是活生生的例子。前一个不方便说，后一个 SpaceX Dragon 的操控系统直接上了 JavaScript 实现界面，和 web 前端没有本质区别——这是之前开发团队公开交流时候说的。要放在传统航天界，别说引入 web 技术，就是加一个触摸屏都可以被口水淹死。要类比的话，那就是把你所谓资本家最爱的 CentOS 生产系统直接给换成 macOS 还整个图形界面来操作，完全没 Linux 什么事，那还不得把资本家都吓死？

新技术稳定吗？那是相当稳定，就问一句阿里双十一双十二稳定性要求能有载人航天高？不服不行 新技术牛吗？那是相当牛，直接淘汰各种乱七八糟的控制界面，降低成本的同时还变相减少了出错概率，更稳定了。不服不行

密集型思路也许可以解决双十一双十二 scaling 问题，反正堆机器说到底又不是什么 rocket science。但是你非要靠这个路子去搞 rocket science，那得向天再借五百年

其实这个话题最初讨论的是“到底要不要远离 CentOS 这类的系统”，这个话题如果放在电商场景下，答案很简单，就是不必远离 CentOS。

等到国内有 SpaceX 之类的企业诞生了，也许会讨论用 JavaScript 来实现操作界面。但那是另一个话题了。

新技术到底是不是稳定的，隔行如隔山，我也不知道。

只有经过实践检验过的新技术是稳定的，这是（国内）工业界对这个问题的看法。

国内的互联网企业，实际上是有科技含量的商业公司，还不能算很强的高科技公司，innovation 不在他们的文化 scope 里面，这和国内的工程师戏称自己是码农，是同样的窘境。

[helloworldSB]

最离谱的是，还有很多SB还在用CentOS SB1号

[xtlsoft]

好了，我由于 Ubuntu 20.04 LTS 发布一个月某台机器（运行 18.04 LTS）没有升级就被喷了…… 像我这种软件甚至敢于直接 Launchpad 的是不是应该直接枪毙 愣是把 Ubuntu LTS 用成滚动

[wdklnbd]

我觉得楼主简直是预言家，国内用centos多的原因，我猜是红帽推出考试认证的原因,很多人考红帽认证作为简历敲门砖，而且很多公司要求要有这个考证，但是他们又买不起红帽商业版本RHEL，进去公司一看大家都是用centos, centos免费嘛。许多年后 红帽发现这样不行。我们搞了一套考试认证，为企业筛选人才背书信用。那些中小企业居然不买RHEL ,立马就把centos改策略,改成不稳定发行，不随RHEL 不对标RHEL 了，弄出一个 CentOS Stream. 那些中小企业怎么办呢？大型企业买的起RHEL的还是会用RHEL，他们能买得起RHEL ，就不会花钱多找那些考证的centos从业者，出问题直接找红帽官方红帽不爽吗？省了一大笔人力资源费。中小企业则需要这些RHCA，RHCE因为他们用着CentOS。估计以后会改其他发行版本。用不起RHEL还是用不起，最悲惨的是那些考红帽证书的。多年以后那些用centos的中小企业会慢慢把那些centos的老版本 centos 7 支持到期之后，那些yum 源就官方不支持了。还有8.0 8.1 8.2 8.3 8.4 就不支持了 以后没有8.5了 。替换成别的版本。 最可气的是，现在centos的创始人 又跳出来搞出了一个rocky linux走之前centos的路子来骗小白了。又想搞到最后名声起来了，想叫红帽花钱招安。哈哈 ，屡试不爽。 另外centos 和 rocky linux其实就是楼主说的山寨RHEL，她需要什么编译啊，直接拿ISO文件过来解压，修改下安装界面说logo图和使用协议文字。再重新打包ISO，要什么的鸡巴再编译。

[wdklnbd]

回答下：上面这一段话，实际上也解释了行业现状的一个动机：为什么传统的电信、金融行业的机房，不跟着 mainstream 的操作系统发布而滚动更新自己的系统。因为他们像你所说的一样，不思进取吗？不是的，因为他们精算过，这样划不来。

别把别人想得那么蠢，任何一个能够组建几十人团队的公司，总能得到投入产出比适合他们的方案。 国内那些传统的电信、金融行业的业务系统，作为消费者来说，体验一点都不好，烂的要死，特别是国内大多数的银行网银系统，对firefox支持都不友好，设计的烂的要死。三大运营商的业务系统，在线办理什么业务，作为消费者来说，烂的要死。这就是支付宝，微信支付。把银行干死的理由，因为拥抱技术变革。不守旧。

[IceBaka]

「野包」指的是非官方维护的第三方软件包，在这里「野」与「官方」是相对概念。例如，对于公司背书的企业级产品，「野」通常指代社区或者个人，「官方」指代公司。

这里的官方是指操作系统的官方，还是开发软件的官方？平常用的这些软件包是由操作系统的官方以及社区制作的吗？这些软件的作者不会负责把源代码编译成程序再发布吗？ 不太了解，想请教下。

[Handsome1080P]

用了3年的Centos 7,真是苦不堪言，默認源裡只有幾百年前包，想更新又得找一些亂七八糟的源，要么源碼編譯，煩死了，傻逼玩意兒。整個趁伺服器換代，直接升上Debian 11 Stable，爽！

[waitsaber]

其实我很好奇一个问题，debian跟ubuntu究竟是谁模仿谁，谁基于谁进行开发的。有些人说debian是基于ubuntu的。

[dogeow]

@waitsaber 从很多文章都能看到 ubuntu 基于 debian。这个文章也说了。要查证可以上维基百科。