Tujuan Minimalisasi Fedora

Meskipun Fedora sangat cocok untuk workstation dan server fisik/virtual tradisional, Fedora sering kali diabaikan untuk kasus-kasus penggunaan di luar instalasi tradisional.

Beberapa jenis penerapan modern - seperti IoT dan kontainer - cukup sensitif terhadap ukuran. Untuk IoT, biasanya koneksi data yang lambat (untuk pembaruan/pengelolaan) dan untuk cloud dan container, skalanya sangat besar.

Contoh spesifiknya adalah Systemd - meskipun sangat berguna (semua orang menyukai Systemd) dan selalu ada di sistem fisik, namun jarang sekali dibutuhkan di dalam kontainer. Jadi, tidak menjadi masalah jika paket-paket membutuhkan Systemd hanya untuk systemd-sysusers untuk membuat pengguna. Namun, dalam kontainer, itu berarti peningkatan ukuran yang signifikan.

Selain itu, pada dasarnya semua jenis penerapan mendapatkan keuntungan dari ukuran yang berkurang, karena ada hubungan langsung antara jejak instalasi dan permukaan serangan & CVE yang relevan.

Ribuan kontributor individu dan perusahaan berkolaborasi dalam komunitas Fedora untuk mengeksplorasi masalah baru dan membangun OS modern yang bergerak cepat dengan ekosistem yang kaya yang memungkinkan mereka untuk bereksperimen dalam memodernisasi infrastruktur mereka.

Membantu para pengembang open source, sysadmin, dan pengelola distribusi Linux untuk fokus pada apa yang relevan bagi mereka.

Fedora adalah platform yang populer karena ekosistemnya mutakhir dan dioptimalkan dengan baik untuk penerapan modern seperti IoT dan kontainer. Hal ini membuat banyak orang menggunakan Fedora daripada membangun dan merakit artefak mereka sendiri secara langsung dari proyek-proyek hulu. Dan itu mengurangi tekanan pada pengembang open source yang disebabkan oleh pengguna yang akan meminta keamanan spesifik mereka dan masalah lain untuk diperbaiki dengan cepat.

Jadi:

Kasus penggunaan spesifik didefinisikan dalam Fedora. Komunitas kemudian berfokus pada kasus-kasus penggunaan tersebut dengan pengembangan dan pemeliharaan, pengoptimalan (seperti minimalisasi), dan pengujian (seperti CI dan gating). Kasus-kasus penggunaan ini dapat diprioritaskan secara transparan untuk sumber daya infrastruktur berdasarkan kepentingan komunitas.

Feedback Pipeline secara aktif memonitor setiap kasus penggunaan dan mencatat ukuran dan ketergantungan yang diperlukan untuk menjalankannya. Riwayat data disimpan dan ditampilkan untuk melihat perubahan dari waktu ke waktu. Dan untuk menjaga agar ukurannya tetap kecil dari waktu ke waktu, Feedback Pipeline juga secara otomatis mendeteksi peningkatan ukuran dan berpotensi secara otomatis membuka bug Bugzilla untuk melacak/memperbaiki/membenarkan peningkatan tersebut secara transparan.

Fokus aktif pada minimalisasi berarti bahwa pengelola kami menghasilkan konten yang dioptimalkan untuk ukuran dengan jumlah upaya yang sama atau lebih rendah. Perkakas, layanan, dan data membantu mereka membuat keputusan yang tepat tentang dependensi dengan mudah, dan untuk menjaga agar ukurannya tetap kecil dari waktu ke waktu.

Identifikasi kasus penggunaan yang relevan dan izinkan komunitas (artinya bukan hanya Tim Minimisasi) untuk mendefinisikannya sendiri. Kami menganggap kasus penggunaan sebagai sekumpulan paket yang diinstal dalam konteks tertentu, yang memiliki tujuan tertentu - seperti Apache HTTP Server Container. Tentukan kasus penggunaan setidaknya untuk:

Selain itu, pertimbangkan juga untuk melihat kasus penggunaan asli kontainer, seperti:

Kumpulkan kasus penggunaan tertentu dengan berbicara dengan orang-orang di acara teknologi, forum internet, dan tempat lain yang memungkinkan.

Perluas layanan pemantauan (Saluran Umpan Balik) itu:

Selain fitur, kita juga perlu:

Kemampuan untuk melihat apa yang sedang terjadi merupakan prasyarat untuk menerapkan perubahan apa pun. Melihat semua peluang yang relevan membantu kita untuk fokus pada peluang yang memiliki dampak paling besar, dan pelacakan yang transparan membantu kita membuktikan manfaat dari pekerjaan kita, dan untuk lebih fokus pada aktivitas yang paling berdampak.

Meminimalkan ukuran instalasi kasus penggunaan dengan mengoptimalkan ketergantungan RPM, fitur, arsitektur perangkat lunak, dan faktor lainnya. Secara khusus, cari:

Berlibat dengan pengembang hulu mengenai perubahan yang lebih besar dalam pengemasan dan arsitektur. Contohnya adalah Systemd dan pemisahan paket systemd-sysuser.

Menerapkan perubahan proses dan kebijakan yang mencerminkan perubahan yang lebih besar dan lebih umum. Sekali lagi, contoh yang baik adalah menggunakan Systemd dalam kontainer, atau masalah umum dalam membuat pengguna dalam kontainer.

Menyediakan panduan untuk komunitas Fedora dalam bentuk posting blog, video, dan pembicaraan konferensi. Meskipun kita mungkin memiliki panduan dan kebijakan, menyebarkan informasi selalu penting.

Sumber daya awan ke layanan prototipe. Kami tidak akan mengubah infrastruktur Fedora yang ada dengan cara apa pun sebelum apa pun yang kami kembangkan terbukti berguna dan sepadan dengan kesibukan stabilisasi dan perubahan produksi.

Tidak ada sumber daya Fedora Infra atau Release Engineering yang dibutuhkan saat ini. Namun, kami mungkin membutuhkan bantuan untuk menyiapkan (atau mendapatkan akses ke) sumber daya cloud.

Dukungan aktif dari pengelola kami, FPC, dan anggota komunitas lainnya sangat dibutuhkan. Ini jelas bukan sesuatu yang bisa kita "minta", tetapi tetap merupakan masukan yang diperlukan.

Usefulness over size: There is a balance between the usefulness and size. We take that in mind and will not implement drastic changes that would prevent our users from using Fedora. However, nothing prevents us from producing additional very specific and minimal artifacts.

Menggunakan RPM: Kami melakukan ini dengan RPM. Kami tidak mencapai minimalisasi dengan menghapus file setelah instalasi. Hal ini mungkin sudah jelas, tetapi masih perlu disebutkan.