Tujuan Minimalisasi Fedora
Proposal Tahap Kedua
Tujuan utama: Adam Samalik (asamalik)
Masalah
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.
Visi
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.
Misi
Membantu para pengembang open source, sysadmin, dan pengelola distribusi Linux untuk fokus pada apa yang relevan bagi mereka.
Hasil
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:
-
Pengembang open source dapat fokus pada pengembangan fitur
-
Sysadmin dapat dengan mudah menggunakan bit yang sudah dibuat sebelumnya yang juga mendapatkan pembaruan rutin
-
Kontributor Fedora (vendor dan individu) dapat berkolaborasi dalam komunitas Fedora dalam mengeksplorasi dan mengembangkan solusi open source untuk masalah di masa depan
Keluaran
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.
Tindakan
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:
-
httpd
-
nginx
-
MariaDB
-
PostgreSQL
-
Fedora IoT
-
Python 3
Selain itu, pertimbangkan juga untuk melihat kasus penggunaan asli kontainer, seperti:
-
GO untuk aplikasi kontainer
-
Karat untuk aplikasi kontainer
-
Quarkus
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:
-
Memvisualisasikan ketergantungan dan ukuran total untuk setiap kasus penggunaan
-
Memantau perubahan ukuran dari waktu ke waktu
-
Mendeteksi perubahan ukuran yang besar secara otomatis
-
Memberi tahu pengelola tentang peningkatan ukuran yang tidak terduga
Selain fitur, kita juga perlu:
-
menulis tes untuk menyederhanakan kontribusi secara signifikan
-
melakukan pengoptimalan kinerja agar layanan dapat diskalakan dengan baik
-
mengeksplorasi penggunaan CI dan Rawhide Gating
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:
-
Ketergantungan RPM yang tidak perlu (meskipun mungkin tidak akan banyak)
-
Beberapa implementasi dari fungsionalitas yang sama yang diperlukan oleh berbagai paket - cobalah untuk membuat mereka menggunakan yang sama
-
Persyaratan khusus konteks - seperti membutuhkan Systemd pada penerapan tradisional tidak masalah dibandingkan dengan membutuhkannya dalam kontainer yang berarti peningkatan ukuran yang signifikan. Memanfaatkan ketergantungan yang lemah dalam kasus-kasus tersebut (yang mungkin memerlukan perubahan kode).
-
Ketergantungan pada hal-hal besar sementara hanya menggunakan sebagian kecil fungsionalitas - seperti membutuhkan seluruh tumpukan Perl untuk menjalankan satu skrip - skrip semacam itu dapat ditulis ulang ke Python yang ada di mana-mana sebagian besar karena DNF
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 dan Masukan
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.
Prinsip-prinsip Panduan
Kegunaan lebih penting daripada ukuran: Ada keseimbangan antara kegunaan dan ukuran. Kami mempertimbangkan hal tersebut dan tidak akan menerapkan perubahan drastis yang akan menghalangi pengguna kami untuk menggunakan Fedora. Namun, tidak ada yang menghalangi kami untuk memproduksi artefak tambahan yang sangat spesifik dan kecil.
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.
Pencapaian Tahap Pertama
Lihat halaman status untuk info rinci dan pembaruan mingguan bersejarah. Ringkasan di bawah ini.
Pemahaman yang lebih baik - Ya, kami sekarang memiliki pemahaman yang jauh lebih baik tentang masalah dan ide yang lebih baik dan lebih spesifik tentang langkah selanjutnya.
Feedback Pipeline - Layanan yang memantau kasus penggunaan untuk ukuran dan ketergantungan. Termasuk berbagai tampilan dalam tabel dan grafik ketergantungan interaktif.
Systemd dan kontainer - Kami membahas masalah Systemd vs kontainer, terutama untuk paket yang membutuhkannya hanya untuk membuat pengguna dalam kontainer menggunakan systemd-sysuser. Bekerja dengan hulu untuk memisahkan paket. Memikirkan, tetapi belum mengusulkan, kebijakan yang lebih luas mengenai hal ini.
Kebijakan yang dipikirkan:
-
A - Jika systemd hanya dibutuhkan untuk memulai layanan, sebuah paket seharusnya hanya "Merekomendasikan" systemd. Ini akan memungkinkan kontainer untuk menginstal paket tanpa systemd.
-
B - Jika sebuah program hanya menggunakan library dari systemd, hanya memerlukan systemd-libs. Contoh: libusb
-
C - Jika sebuah paket ingin menggunakan systemd-sysusers untuk membuat user/group, hanya membutuhkan systemd-sysusers. (CATATAN: Subpaket ini belum diimplementasikan)
initial-setup - Jika sebuah image dibangun tanpa pengguna, perlu ada beberapa cara untuk menambahkan pengguna pada saat startup. initial-setup melakukan pekerjaan yang baik untuk itu, tetapi dengan mengorbankan ukuran. Ini menarik anaconda-tui dan anaconda-core. Kedua paket tersebut kemudian mulai menarik banyak paket lain yang agak besar. Ini untuk gambar IoT, dan juga yang lainnya. Saat ini kami belum memiliki rekomendasi, tetapi sedang dikerjakan.
Gunakan pcre2 sebagai pengganti pcre - Upaya minimalisasi mencoba untuk memangkas
Polkit dan mozjs60 - Mari kita jelaskan yang satu ini dengan analogi yang mengerikan! Polkit adalah orang baik (.5M) yang membunyikan bel rumah Anda dan mengatakan bahwa mereka akan mencuci jendela rumah Anda. Setelah Anda setuju, mereka akan mengeluarkan gajahnya (mozjs60 30M) dan menggunakannya untuk menyemprot jendela Anda dengan air. Polkit menarik mozjs60, yang merupakan paket yang cukup besar. Jadi, kami mencoba untuk menyelesaikan masalah ini juga.
Want to help? Learn how to contribute to Fedora Docs ›