Fedora 最小化目標

雖然 Fedora 非常適合傳統的實體/虛擬工作站和伺服器，但對於傳統安裝以外的使用情況，Fedora 常常被忽略。

某些現代部署類型 (例如物聯網和容器) 對規模相當敏感。 對於物聯網而言，通常是緩慢的資料連線 (只用於更新/管理)，而對於雲端和容器而言，則是龐大的規模。

一個具體的例子是 Systemd - 雖然它非常有用 (每個人都喜歡 Systemd)，而且一直存在於實體系統中，但在容器中卻很少需要它。 因此，對於套件來說，需要 Systemd 只是為了＿systemd-sysusers＿來建立使用者並不是問題。 但是，在容器中，這意味著所占用的體積大小都會大幅增加。

除此之外，基本上所有類型的部署都能從縮小規模中獲益，因為安裝的足跡與攻擊面和相關的 CVE 有直接關係。

數以千計的個人和企業貢獻者在 Fedora 社群中合作，共同探索新的問題，並建立一個快速發展的現代化作業系統，其豐富的生態系統可讓他們進行現代化基礎架構的實驗。

幫助使用開放原始碼的開發人員、系統管理員和 Linux 發行版維護人員，更加專注於與他們相關的工作。

Fedora 是一個很受歡迎的平台，因為它的生態系既尖端又針對現代部署 (例如物聯網和容器) 做了很好的最佳化。 這使得許多人使用 Fedora，而不是直接從上游專案建立和組裝自己的藝術品。 這也減輕了開放原始碼開發者的壓力，因為使用者會要求他們的特定安全和其他問題能快速修正。

So:

Fedora 定義了特定的使用個案。 然後，社群會將開發與維護、最佳化 (如: 最小化) 與測試 (如: CI 與 gating) 的重點放在這些使用個案上。 這些使用個案可根據社群利益，以透明的方式排定基礎架構資源的優先順序。

Feedback Pipeline 會主動監控每個使用個案，並記錄其大小及執行所需的依賴性。 資料歷史會被保留並顯示出來，以查看隨時間的變化。 此外，為了讓事情隨著時間的推移保持在較小的範圍內，Feedback Pipeline 也會自動偵測大小的增加，並可能自動開啟 Bugzilla bug，以透明的方式追蹤/修正/證明這些增加。

積極專注於最小化，意味著我們的維護人員只需付出相同或更少的努力，就能產生體積大小最佳化的內容。 工具、服務和資料可幫助他們輕易地就相依性做出正確的決策，並隨著時間的推移而保持較小的規模。

找出相關的使用個案，並允許社群 (不只是最小化團隊) 定義他們自己的使用個案。 我們認為用例是安裝在特定情境中、有特定目的的套件集 - 例如 Apache HTTP Server Container。 至少為以下項目定義用例：

此外，請考慮研究容器原生的使用案例，例如：

透過在科技活動、網路論壇和其他可行的場合與人們交談，收集特定的使用案例。

擴展監控服務（反饋管道），其中：

除了功能之外，我們還需要:

能夠看到正在發生什麼是實施任何變革的先決條件。 看到所有相關的機會有助於我們專注於最有影響力的機會，而透明的追蹤有助於我們證明工作的有用性，並進一步專注於最有影響力的活動。

透過最佳化 RPM 相依性、功能、軟體架構和其他因素，最小化使用個案的安裝大小。 具體而言，請尋找:

實施流程和政策變更反映更大、更普遍的變更。 同樣地，在容器中使用 Systemd 或在容器中建立使用者的一般問題就是很好的例子。

以部落格文章、影片和會議講座的形式，為 Fedora 社群 提供指導。 儘管我們已經制定了相關的指導方針和政策，但宣傳依舊永遠是非常重要的。

雲端資源的服務原型。 在我們開發的任何東西被證實有用且值得穩定和改變生產環境之前，我們不會以任何方式改變現有的 Fedora 基礎架構。

目前不需要現有的 Fedora 架構團隊或發行工程資源。 不過，我們可能需要協助設定 (或存取) 雲端資源。

我們絕對需要維護者、FPC 以及其他社群成員的積極支持。 這顯然不是我們可以「要求」的，但仍是必要的投入。

實用性重於大小： 實用性與大小之間需要平衡。 我們考慮到這一點，不會實施會妨礙我們的使用者使用 Fedora 的劇變。 然而，沒有什麼可以阻止我們製作更多非常特定且最小化的藝術品。

使用 RPM： 我們正在使用 RPM 進行此操作。 我們不是在安裝後刪除檔案來達到最小化。 這可能很明顯，但仍值得一提。