真相：為什麼紅帽為了 CentOS Stream 而拋棄 CentOS？

當 CentOS 的 Linux 母公司紅帽宣布將重點從 紅帽企業 Linux （ Red Hat Enterprise Linux ） （RHEL）的重建版 CentOS Linux 轉移到 CentOS Stream上，而 CentOS Stream 的跟蹤時間剛好在當前 RHEL 版本之前時，很多 CentOS 用戶簡直要昏倒了。

在 Hacker News 上，最主要的評論是，「想像一下，如果你正在經營一家企業，並基於 10 年壽命的承諾部署了 CentOS 8 。現在你全完蛋了，而紅帽知道這一切。他們究竟為什麼不從 CentOS 9 開始做這個轉換？？！讓我們不要粉飾這個問題。他們背叛了我們。」

在 Reddit/Linux 上，另一個人咆哮道：「從 CentOS 4 以來，我們的開源項目都是基於最新的 CentOS 版本的，我們的旗艦產品運行在 CentOS 8 上，我們已然把一切都押注在了他們承諾的 2029 年 5 月 31 日生命周期上。」

自稱 「Unix 宇宙中最好的 Linux 博客」，nixcraft，一個擁有超過 20 萬訂閱者的賬號發布的熱門推特說：Oracle 收購了 Sun 公司， Solaris Unix、Sun 伺服器/工作站和 MySQL 被轉到了 /dev/null。IBM 買下紅帽：CentOS 去了 >/dev/null。請注意。如果有一天 Oracle、IBM、MS 等大廠商購買了你喜歡的軟體，請儘快啟動遷移。」

其他許多人也加入了這個令人惱火的 CentOS 用戶吐槽團，認為他們最喜歡的 Linux 被奪走是 IBM 的錯。還有一些人則尖聲叫罵紅帽在背叛開源本身。

紅帽為什麼要這麼做？紅帽的首席技術官 Chris Wright 在推出 CentOS Stream 時說：「開發者......需要更早地[在 2019 年 9 月]訪問代碼，與更廣泛的合作夥伴社區進行改進和更透明的合作，並能夠影響新的 RHEL 版本的方向。CentOS Stream 正是為了解決這些需要而出現。」

簡而言之，一個原因是開放紅帽企業 Linux（RHEL）的代碼。原 CentOS 董事會成員、長期的 Fedora Linux 貢獻者、紅帽高級社區架構師 Karsten Wade 在一篇博客文章中進行了更進一步的解釋：

RHEL 本身的開發仍然封閉在紅帽的防火牆之後。 這種情況已經持續了近二十年。對於開源開發生態系統來說，這一直是一個重要的，而且經常是痛苦的缺口 —— 這仍然是和 2003 年一樣的開放性缺口。

這就是我們今天所處的境地。將項目的重點轉移到 CentOS Stream 上的舉動，就是為了在一些關鍵的方面填補這個開放性缺口。本質上，紅帽是通過將 CentOS 的位置從 RHEL 的下游轉移到 RHEL 的上游，來填補 Fedora 和 RHEL 之間存在的開發和貢獻缺口。

是的，這是真的。部分原因是紅帽在 Fedora 和 RHEL 開放之間做最後的、重要的步驟。另一個部分的官方原因是，正如 Wright 所說，CentOS Stream 作為 RHEL 下一步的「滾動預覽」，無論是在內核還是功能上都可以用於當今容器化、雲原生的 IT 世界。畢竟，Facebook 已經在 CentOS Stream 衍生的 Linux 操作系統上運行了其數百萬台伺服器。

因此，Wright 繼續說道，雖然「CentOS Stream 並不是 CentOS Linux 的替代品，相反，它是一個自然的、不可避免的下一步發展，旨在實現該項目進一步推動企業 Linux 創新的目標。」是的，CentOS Stream 不是一個你可以運行多年、穩定版本的 Linux 伺服器發行版，但它是以云為中心的公司所需要的，以部署「容器化應用和雲原生服務，以快速的硬體創新和生態系統轉向軟體即服務（SaaS）。......這就是我們認為的 CentOS Stream 優勢所在。它為社區層面的快速創新提供了一個平台，但又有足夠穩定的基礎來了解生產動態。」

是的，這也是事實。但是，它們不是故事的全部。以下是紅帽將老式的定期發布的 CentOS 放任自流的真正原因。

紅帽公司根本沒有怎麼談論這方面的問題，但是紅帽公司 Linux 工程副總裁 Mike McGrath 在 ITPro Today 上接受 Christine Hall 的採訪時，卻把秘密泄露了出來。「我想說的是，對我們來說，最大的問題是 CentOS 本身其實並沒有給紅帽提供那麼大的用處。我們建立的大多數社區，比如 Fedora，確實有很多雙向的社區參與。不幸的是，CentOS 從來就不是這樣的。它一直是一個用戶社區，所以那種貢獻模式大多是單向的。」

讓我再重複一遍，「CentOS 本身其實並沒有給紅帽提供那麼大的用處。」 它從來沒有。而且，有很多紅帽的資深人士從第一天開始就知道這一點，他們一點也不喜歡它。

你知道誰在使用 CentOS 嗎？一份簡短的名單包括迪士尼、GoDaddy、Rackspace、豐田和 Verizon。此外，還有幾十家公司圍繞 CentOS 打造產品。這些公司包括 GE、Riverbed、F5、Juniper 和 Fortinet。紅帽從這些 CentOS 的「客戶」身上賺了多少錢？零！

在 CentOS 博客上，一位不滿的用戶說：「整個前提，也是唯一有人使用 CentOS 的原因，就是因為它重構了 RHEL。恭喜你破壞了這一點，笨蛋。」

沒錯，這也是 CentOS 要為 CentOS Stream 讓位的最大原因。

紅帽公司沒有人願意公開說這句話，但眾多紅帽公司的高管告訴我，情況就是這樣。

有一位說：「這與 IBM 幾乎無關。在 2018 年秋季收購的消息還沒有傳來之前，我們就在詳細地討論這個問題。有兩個內部原因。首先，工程和銷售部門無論如何也想不出如何在各自的產品組合中定位 CentOS。而且，把 CentOS 變成上游的想法始於 2014 年，當時 Jim Perrin [前紅帽開發人員和 CentOS 董事會成員，現為微軟首席項目經理]在 2014 年巴西的 Fórum Internacional de Software Livre（FISL）演講中談到了這種可能性。結果就出現了 CentOS 特別興趣小組（SIG），這是 CentOS Stream 之路的開始。」

一位前紅帽高管坦言：「CentOS 在挖銷售的牆角。客戶的看法是『它來自紅帽，是 RHEL 的克隆，所以它很好用！ 』其實不然。它是一個二流的拷貝。」以他的立場看，「這 100% 是防守，以避免 CentOS 造成更多損失。」

還有一位前紅帽官員說。如果不是因為 CentOS，在紅帽成為十億美元的企業之前，紅帽就已經是一家百億美元的公司了。

而另一位紅帽員工指出：「看看 CentOS 的 FAQ，它就在那裡寫著 ——

CentOS Linux 不受 Red Hat 公司的任何支持。
CentOS Linux 不是 Red Hat Linux，不是 Fedora Linux，也不是 Red Hat Enterprise Linux，它不是 RHEL。CentOS Linux 不包含 Red Hat® Linux、Fedora 或 Red Hat® Enterprise Linux。
CentOS Linux 不是 Red Hat® Enterprise Linux 的克隆。
CentOS Linux 是由 Red Hat, Inc 為 Red Hat Enterprise Linux 提供的公開源代碼，在一個完全不同的（CentOS 項目維護的）構建系統中構建的。

我們不欠你什麼。」

這可能會讓你們中的一些人對紅帽非常生氣。不過，在你們發火之前，讓我先問你們一些問題。CentOS 的「客戶」為 CentOS 貢獻了多少？我說的不是錢。我說的是代碼、文檔和支持。所有這些開源社區應該回饋的東西。答案是：幾乎沒有，接近於無。

在 CentOS 從事安全工作的 Dick Morrell 在推特上寫道：「社區[是]由合作和互動定義的。如果 @CentOSProject 是一個社區建設的住宅開發項目，它將享受那些受益和使用其設施的人所貢獻的擴建、樓層和功能。」 Morrell 繼續說道：「然而 @CentOSProject 一直是不斷給予的仁慈禮物，而現在那些抱怨的人從來沒有站出來用磚頭、水泥或玻璃來擴建這個物產。」

你真的能責怪紅帽做了一個企業應該做的事情嗎？賺錢的同時而為他們的付費社區服務？我明白為什麼人們對紅帽感到生氣。這是溝通不暢的問題。僅僅用一年的警告就切斷了對 CentOS 8 的支持，這理所當然地換來了很多人的不滿。 但如果你是那些現在對紅帽憤怒的人之一，在你太過自以為是之前，你可能要先自我反思一下，想想你對 CentOS 的回報有多少。

最後，如果你還是無法忍受紅帽對 CentOS 的做法，還有其他的 Linux 替代品。而且，至少有兩個「經典」的 CentOS 構建版本，CloudLinux 的 Project Lenix 和 Rocky Linux 可供你考慮。

via: https://www.zdnet.com/article/why-red-hat-dumped-centos-for-centos-stream/

作者：Steven J. Vaughan-Nichols 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive