Obiettivo di Minimizzazione Fedora

Sebbene Fedora sia ben adatta per workstation e server fisici/virtuali tradizionali, viene spesso trascurata per casi d’uso che vanno oltre le installazioni tradizionali.

Alcuni tipi moderni di deployment — come IoT e container — sono piuttosto sensibili alle dimensioni. Per l’IoT si tratta solitamente di connessioni dati lente (per aggiornamenti/gestione) e per il cloud e i container si tratta della scala massiccia.

Un esempio specifico è Systemd — pur essendo molto utile (tutti amano Systemd) ed essendo sempre presente sui sistemi fisici, è raramente necessario nei container. Quindi non era un problema per i pacchetti richiedere Systemd solo per systemd-sysusers per creare utenti. Tuttavia, nei container, ciò significa un aumento significativo delle dimensioni.

Oltre a ciò, fondamentalmente tutti i tipi di deployment beneficiano di una dimensione ridotta, poiché esiste una relazione diretta tra l’impronta dell’installazione, la superficie di attacco e le CVE pertinenti.

Migliaia di contributori individuali e aziendali collaborano nella comunità Fedora per esplorare nuovi problemi e costruire un sistema operativo moderno e in rapida evoluzione con un ricco ecosistema che consenta loro di sperimentare sulla modernizzazione della loro infrastruttura.

Aiutare gli sviluppatori open source, gli amministratori di sistema e i manutentori di distribuzioni Linux a concentrarsi su ciò che è rilevante per loro.

Fedora è una piattaforma popolare perché il suo ecosistema è sia all’avanguardia che ben ottimizzato per i deployment moderni come IoT e container. Ciò spinge molte persone a utilizzare Fedora piuttosto che costruire e assemblare i propri artefatti direttamente dai progetti upstream. E questo allevia la pressione sugli sviluppatori open source causata dagli utenti che altrimenti chiederebbero che i loro specifici problemi di sicurezza e di altro tipo vengano risolti rapidamente.

Quindi:

Casi d’uso specifici sono definiti in Fedora. La comunità si concentra quindi su tali casi d’uso con sviluppo e manutenzione, ottimizzazione (come la minimizzazione) e test (come CI e gating). Questi casi d’uso possono essere prioritizzati in modo trasparente per le risorse dell’infrastruttura in base agli interessi della comunità.

Feedback Pipeline monitora attivamente ogni caso d’uso e registra le dimensioni e le dipendenze necessarie per eseguirlo. Lo storico dei dati viene conservato e mostrato per vedere i cambiamenti nel tempo. E per mantenere le cose piccole nel tempo, Feedback Pipeline rileva anche automaticamente gli aumenti di dimensione e potenzialmente apre automaticamente bug su Bugzilla per tracciare/risolvere/giustificare tali aumenti in modo trasparente.

Un focus attivo sulla minimizzazione significa che i nostri manutentori producono contenuti ottimizzati per le dimensioni con lo stesso o minore sforzo. Strumenti, servizi e dati li aiutano a prendere facilmente la decisione giusta sulle dipendenze e a mantenere le cose più piccole nel tempo.

Identificare casi d’uso rilevanti e consentire alla comunità (cioè non solo al Team di Minimizzazione) di definire i propri. Pensiamo a un caso d’uso come un insieme di pacchetti installati in un contesto specifico, con uno scopo specifico — come Container Server HTTP Apache. Definire casi d’uso almeno per:

Inoltre, considerare l’analisi di casi d’uso nativi per container, come:

Raccogliere casi d’uso specifici parlando con le persone agli eventi tecnologici, sui forum Internet e in qualsiasi altra sede idonea.

Estendere i servizi di monitoraggio (Feedback Pipeline) che:

Oltre alle funzionalità, dobbiamo anche:

Essere in grado di vedere cosa sta succedendo è un prerequisito per implementare qualsiasi cambiamento. Vedere tutte le opportunità rilevanti ci aiuta a concentrarci su quelle che hanno il maggiore impatto, e un tracciamento trasparente ci aiuta a dimostrare l’utilità del nostro lavoro e a concentrarci ulteriormente sulle attività più impattanti.

Minimizzare la dimensione di installazione dei casi d’uso ottimizzando le dipendenze RPM, le funzionalità, l’architettura software e altri fattori. In particolare, cercare:

Interagire con gli sviluppatori upstream riguardo a cambiamenti più grandi nel packaging e nell’architettura. Un esempio è Systemd e la suddivisione del pacchetto systemd-sysuser.

Implementare modifiche ai processi e alle policy che riflettano cambiamenti più grandi e generali. Ancora una volta, un buon esempio è l’uso di Systemd nei container, o il problema generale della creazione di utenti nei container.

Fornire guida alla comunità Fedora sotto forma di post di blog, video e interventi a conferenze. Anche se potremmo avere linee guida e policy in vigore, diffondere la voce è sempre importante.

Risorse cloud per prototipare i servizi. Non modificheremo l’infrastruttura Fedora esistente in alcun modo prima che qualsiasi cosa sviluppiamo si dimostri utile e valga la pena della fatica della stabilizzazione e del passaggio in produzione.

Al momento non sono necessarie risorse esistenti di Fedora Infra o Release Engineering. Tuttavia, potremmo aver bisogno di aiuto per configurare (o ottenere accesso a) le risorse cloud.

È decisamente necessario il supporto attivo dei nostri manutentori, dell’FPC e degli altri membri della comunità. Ovviamente non è qualcosa che possiamo "richiedere", ma è comunque un input necessario.

Utilità prima della dimensione: C’è un equilibrio tra utilità e dimensione. Teniamo conto di ciò e non implementeremo cambiamenti drastici che impedirebbero ai nostri utenti di usare Fedora. Tuttavia, nulla ci impedisce di produrre artefatti aggiuntivi molto specifici e minimali.

Usando RPM: Stiamo facendo questo con RPM. Non stiamo ottenendo la minimizzazione eliminando file dopo l’installazione. Questo potrebbe essere ovvio, ma vale comunque la pena menzionarlo.