2020年12月8日，CentOS項目將重點轉移到CentOS Stream
CentOS項目的未來是CentOS Stream，在明年，我們將把重點從重建Red Hat Enterprise Linux（RHEL）的CentOS Linux轉移到CentOS Stream，后者緊跟當前RHEL版本發布。作為對RHEL 8的重建，CentOS Linux 8將於2021年底結束。CentOS Stream在此日期之后繼續，作為Red Hat Enterprise Linux的上游（開發）分支。
大多數人的反應都是抗拒， 包括我，已經開始准備測試 Ubuntu、Debian 了。
仔細思考下來，其實 CentOS切換到Stream應該不會差。
因為時代不一樣了。
那么，什么改變了？
軟件開發。
利用DevOps的優勢，我們一直在轉向基於平台的開發方法。
編程語言是由工具支持的平台
如今，人們無法在帶有編譯器的編輯器中進行編程。
他們使用具有許多集成功能的Github或Gitlab和本地IDE。他們承諾使用一個VCS（實際上，git在一個單一的VCS上融合了整個世界），並觸發了很多事情。類型檢查，重新格式化，測試，還包括代碼質量指標和安全掃描程序。
即使在2020年啟動一種新的編程語言也沒有過去那樣容易。僅憑一種語言是不夠的，因為您不僅需要一種語言，也許還需要一種標准庫，而且還需要支持它的JetBrains產品，SonarQube支持，XRay集成，gitlab-ci.yml示例等等。基本上，有一個龐大的基礎架構系統旨在支持開發，而無論您從什么開始就需要從一開始就適應它。
也就是說，因為我們已經依賴整個工具生態系統來提高開發人員的速度，並在整個團隊中實施統一的標准。那是一件好事，它可以幫助我們成為更好的程序員。
Github和Gitlab是開發人員之間有關代碼的對話工具
我們也開始依賴工具來實現協作以及關於代碼的結構化討論，因為我們作為程序員不再單獨工作。Gitlab，Github和類似軟件的很大一部分價值是使開發人員之間能夠以開發人員重視的方式進行有益的合作。
在這些平台的生產端可以提取價值的另一部分：我們以可復制的方式自動生成構件。
其中還包括了解與這些工件有關的事情，例如，產生這些工件並能夠報告這些事情的原因：
- 依賴關系
- licenses
- 版本號
- 漏洞
- 提交每個依賴項修復的頻率和時間，放棄軟件警報
還有更多的東西。通過這些過程，存儲庫以及其他要素，只要我們找到一種適當管理和發展狀態的方法，我們就可以部署和回滾成為自動化且標准化的過程。
與2010年代手工定制的部署和回滾程序相比，這是一個巨大的進步。
不變的基礎架構和可復制的構建
這另一部分是不變的基礎架構。
這是一個基本思想，即在部署代碼后，我們就不再對運行代碼的基礎鏡像的狀態進行操作。從根本上說，這是Puppet及其類似角色的死亡。
取而代之的是，我們更改構建過程，生成不可變的鏡像，然后快速進行重建和重新部署。我們部署基礎鏡像，然后以其他更合適的方式提供機密、運行時配置和控制配置。諸如Vault之類的東西，諸如Zookeeper之類的共識系統之類的東西或類似的機制都浮現在腦海。在當今所有計算已成為分布式計算的時代，它使我們能夠在整個實例隊列之間協調變更，以確保整個實例隊列之間的一致性。
可以將相同的思想應用於主機的實際基本操作系統，在該主機中，我們從基本操作系統中完全刪除了應用程序安裝。相反，我們提供了一種以虛擬機鏡像，容器鏡像或無服務器功能部署（也包括容器，但按鈕較少）的形式安裝和卸載應用程序安裝（包括其依賴項）的機制。
結果，一切都變成了單用戶，單租戶–一個鏡像僅包含 Postgres，另一個鏡像僅包含您的靜態鏡像Web服務器（由外部可掛載卷提供的鏡像），而第三個鏡像僅包含您的生產Python應用程序和運行時環境。容器中只有一件東西，Linux UID 不再具有有用的分離功能，而其他隔離和分離機制將取代它們：
- virtualization,
- CGroups,
- Namespaces,
- Seccomp,
和類似的。無論如何，它們可以說更強大。
這在偉大的論點中也形成了一種論點：“ curlbash甚至 sudo curlbash還是一件壞事嗎？”
鏡像作為應用程序的基礎
因此，現在我們可以使用整個應用程序（具有在運行時提供並注入的配置）來構建服務，並且可以在環境提供的現有服務之上添加我們自己的代碼中的一小部分來構建我們自己的服務。我們獲得了Kubernetes的Helm Charts，獲得了The Serverless Sea Change和Step Functions。我們還獲得了Nocode，無代碼或類似的嘗試，僅從服務中構建某些東西而沒有實際編碼。
但這比這更普遍：
- Unifi控制平面使用多個Java進程和一個Mongodb。可以將其打包到一個鏡像，也可以將其作為舵圖提供，也可以將其作為包含多個容器的泊塢窗提供，以實現更好的可伸縮性和維護性。
- gitlab Omnibus再次使用單個容器，並帶有Postgres，Redis和許多內部狀態以及Chef，以部署大約十二個組件，但是在K8s上下文中還存在針對各個組件的差異部署。
- 像Jitsi設置之類的東西可以打包到一個相對簡單的docker-compose.yml中，並且將自動從鏡像中自動組裝它們。只要提供Linux內核syscall接口，結果就可以在幾乎所有操作系統的基板上運行。
打擊康威定律
這樣就很重要了：將所有依賴項打包到容器或VM鏡像本身中，基本操作系統就不再重要了。它使我們能夠在每個項目的基礎上以各自的速度前進。
該項目將自帶數據庫，緩存，運行時和庫，而不會發生版本沖突，也無需等待發行版對其進行升級或完全提供。相反，它允許Distro遷移到Stream：它們最終擺脫了緩慢發展的OSS項目，從而阻止了它們升級本地組件，因為其中一個尚不准備就緒。
甚至企業中的團隊現在也可以按照自己的速度自由移動，因為他們不再需要等待六位利益相關者進入積壓的技術債務部門。
我認為主要要點是，應用程序使用與主機使用的不同的“不再是完整的操作系統”是正常且正常的。承認兩者都可以縮小范圍和規模，並進行優化。這是一件好事，將加速發展。
因此，在一個將組件及其依賴項打包為單用戶單租戶執行單元（虛擬機，容器等）的世界中，CentOS遷移到Streams不僅承認了這一變化，而且還迫使緩慢的一半世界承認並接受它。
我說：這是一件好事。