Fedora Minimizasyon Hedefi

Fedora, geleneksel fiziksel/sanal iş istasyonları ve sunucular için çok uygun olsa da, geleneksel kurulumların ötesinde kullanım durumları için genellikle göz ardı edilmektedir.

Bazı modern kurulum türleri - IoT ve konteynerler gibi - büyüklüğe karşı oldukça duyarlıdır. IoT için bu genellikle yavaş veri bağlantıları (güncellemeler/yönetmek için) ve bulut ve konteynerler için büyük ölçekte hacimleridir.

Belirgin bir örnek Systemd’dir — çok faydalı olmasına (herkes Systemd’yi sever) ve her zaman fiziksel sistemlerde bulunmasına rağmen, konteynerlerde nadiren gereklidir. Bu nedenle, paketlerin sadece kullanıcılar oluşturmak amacıyla systemd-sysusers için Systemd gerektirmesi bir problem değildi. Bununla birlikte bu, konteynerlerde önemli bir boyut artışı anlamına gelmektedir.

Bunun yanında, kurulum alanı ile atak yüzeyi ve ilgili CVE’ler arasında doğrudan bir ilişki olduğundan, temel olarak küçültülmüş bir boyut tüm kurulum türleri için faydalıdır.

Binlerce kişisel ve kurumsal katılımcı, yeni sorunları keşfetmek ve altyapılarını modernize etmeleri üzerine deneyler yapmalarını sağlayan zengin bir ekosistem ile hızlı bir şekilde hareket eden modern bir işletim sistemi oluşturmak için Fedora topluluğunda işbirliği yapmaktadır.

Açık kaynaklı geliştiricilere, sistem yöneticilerine ve Linux dağıtımcılarına kendileri için uygun olan şeylere odaklanmaları konusunda yardımcı olmak.

Fedora popüler bir platformdur, çünkü ekosistemi son teknolojidir ve IoT ve konteynerler gibi modern dağıtımlar için iyi optimize edilmiştir. Bu, birçok insanın kendi ürünlerini doğrudan upstream projelerden bir araya getirmek ve oluşturmak yerine Fedora’yı kullanmalarını sağlamaktadır. Bu, diğer türlü kendi güvenlik ve diğer sorunlarının hızlı bir şekilde çözülmesini isteyen kullanıcıların neden olduğu açık kaynak geliştiricileri üzerindeki baskıyı hafifletmektedir.

Yani:

Özel kullanım durumları Fedora’da tanımlanmıştır. Daha sonra topluluk, geliştirme ve bakım, optimizasyon (minimizasyon gibi) ve test etme (CI ve gating gibi) kullanım durumlarına odaklanır. Bu kullanım durumlarına, topluluk çıkarlarına dayanarak altyapı kaynakları için şeffaf bir şekilde öncelik verilebilir.

Geri Bildirim Hattı, her bir kullanım durumunu aktif olarak izler ve çalışması için gereken boyutu ve bağımlılıkları kaydeder. Veri geçmişi saklanır ve zaman içinde değişimi görmek için gösterilir. Ve zamanla işleri küçük tutmak için, Geri Bildirim Hattı ayrıca boyut artışlarını otomatik olarak algılar ve potansiyel olarak bu artışları şeffaf bir şekilde izlemek/düzeltmek/doğrulamak için Bugzilla hataları açar.

Minimizasyon üzerine aktif bir odaklanma, bakımcılarımızın aynı veya daha az çabayla boyuta göre optimize edilmiş içerik üretmesi anlamına gelir. Araçlar, hizmetler ve veriler, bağımlılıklarla ilgili doğru kararı vermelerini ve zamanla işleri daha küçük tutmalarını sağlamaktadır.

İlgili kullanım durumlarını tanımlayın ve topluluğun (sadece Minimizasyon Takımı değil) kendi tanımlarını yapmasına izin verin. Kullanım durumunu, belirli bir bağlamda kurulmuş, belirli bir amaca sahip olan — Apache HTTP Sunucusu Konteyneri gibi bir paket olarak düşünürüz. Kullanım durumlarını en azından aşağıdakiler için tanımlayın:

Ayrıca, konteynerlere özgü kullanım durumlarına bakmayı düşünün, örneğin:

Teknik etkinliklerde, internet forumlarında ve diğer uygun yerlerde insanlarla konuşarak özel kullanım durumları toplayın.

Şunları yapan izleme hizmetlerini genişletin (Geri Bildirim Hattı):

Özellikler dışında ayrıca şunları yapmamız gerekmektedir:

Neler olup bittiğini görebilmek herhangi bir değişikliğin uygulanmasının ön şartıdır. İlgili tüm fırsatları görmek, en fazla etkiye sahip olanlara odaklanmamıza yardımcı olur ve şeffaf bir takip, çalışmamızın yararlarını kanıtlamamıza ve en etkili faaliyetlere daha fazla odaklanmamıza yardımcı olur.

RPM bağımlılıklarını, özellikleri, yazılım mimarisini ve diğer faktörleri optimize ederek kullanım durumlarının kurulum boyutunu en aza indirin. Özellikle, şunlara bakın:

Paketleme ve mimarideki daha büyük değişikliklerle ilgili olarak upstream geliştiricileriyle bağlantı kurun. Systemd ve systemd-sysuser paketini bölmek örnek olarak verilebilir.

Daha büyük, daha genel değişiklikleri yansıtan süreç ve politika değişikliklerini uygulayın. Yine iyi bir örnek, systemd’yi konteynerlerde kullanmak veya konteynerlerde kullanıcı oluşturma genel sorunu.

Fedora topluluğu için blog gönderileri, videolar ve konferans konuşmaları şeklinde rehberlik sağlayın. Kurallarımız ve politikalarımız olsa da, haberi yaymak her zaman önemlidir.

Prototip hizmetleri için bulut kaynakları. Geliştirdiğimiz şeyin faydalı olduğunu kanıtlamadan ve istikrar ve üretimin değiştirilmesinin telaşına değmeden, mevcut Fedora altyapısını hiçbir şekilde değiştirmeyeceğiz.

Şu anda mevcut hiçbir Fedora Infra veya Sürüm Mühendisliği kaynağına ihtiyaç yoktur. Ancak, bulut kaynaklarını ayarlamak (veya erişmek) için yardıma ihtiyacımız olabilir.

Bakımcılarımız, FPC ve diğer topluluk üyelerinden aktif destek kesinlikle gereklidir. Bu açıkçası "talep edebileceğimiz" bir şey değil, ama yine de gerekli bir girdi.

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.

RPM Kullanımı: Bunu RPM ile yapıyoruz. Minimizasyonu kurulumdan sonra dosyaları silerek gerçekleştirmiyoruz. Bu bariz olabilir, ancak yine de bahsetmeye değer.