Objectiu de Minimització de Fedora

Tot i que Fedora s’adapta bé a estacions de treball i servidors físics/virtuals tradicionals, sovint es passa per alt per a casos d’ús més enllà de les instal·lacions tradicionals.

Alguns tipus moderns de desplegaments, com l’IoT i els contenidors, són força sensibles a la mida. Per a l’IoT, sol ser degut a connexions de dades lentes (per a actualitzacions/gestió) i per al núvol i els contenidors és l’escala massiva.

Un exemple específic és Systemd: tot i ser molt útil (a tothom li encanta Systemd) i estar sempre present en sistemes físics, rarament es necessita en contenidors. Per tant, no era un problema que els paquets requerissin Systemd només perquè systemd-sysusers creés usuaris. No obstant això, en contenidors, això significa un augment significatiu de la mida.

A part d’això, bàsicament tots els tipus de desplegaments es beneficien d’una mida reduïda, ja que hi ha una relació directa entre la petjada d’instal·lació i la superfície d’atac i els CVE rellevants.

Milers de col·laboradors individuals i corporatius col·laboren a la comunitat Fedora per explorar nous problemes i construir un sistema operatiu modern de ràpida evolució amb un ecosistema ric que els permet experimentar amb la modernització de la seva infraestructura.

Ajudar els desenvolupadors de codi obert, els administradors de sistemes i els mantenidors de distribucions Linux a centrar-se en el que és rellevant per a ells.

Fedora és una plataforma popular perquè el seu ecosistema és d’avantguarda i està ben optimitzat per a desplegaments moderns com IoT i contenidors. Això fa que molta gent utilitzi Fedora en lloc de construir i muntar els seus propis artefactes directament des de projectes upstream. I això alleuja la pressió sobre els desenvolupadors de codi obert causada pels usuaris que, d’altra manera, demanarien que es solucionessin ràpidament els seus problemes de seguretat i altres específics.

Així doncs:

Els casos d’ús específics es defineixen a Fedora. Aleshores, la comunitat se centra en aquests casos d’ús amb desenvolupament i manteniment, optimització (com la minimització) i proves (com CI i control d’accés). Aquests casos d’ús es poden prioritzar de manera transparent per als recursos d’infraestructura basant-se en els interessos de la comunitat.

El Feedback Pipeline supervisa activament cada cas d’ús i registra la mida i les dependències necessàries perquè funcioni. Es manté i es mostra l’historial de dades per veure els canvis al llarg del temps. I per mantenir les coses petites amb el temps, el Feedback Pipeline també detecta automàticament augments de mida i potencialment obre automàticament errors a Bugzilla per fer un seguiment/arreglar/justificar aquests augments de manera transparent.

Un focus actiu en la minimització significa que els nostres mantenidors produeixen contingut optimitzat per mida amb la mateixa o menor quantitat d’esforç. Les eines, els serveis i les dades els ajuden a prendre la decisió correcta sobre les dependències fàcilment i a mantenir les coses més petites al llarg del temps.

Identificar casos d’ús rellevants i permetre que la comunitat (no només l’equip de minimització) defineixi els seus propis. Pensem en un cas d’ús com un conjunt de paquets instal·lats en un context específic, que tenen un propòsit específic, com ara Apache HTTP Server Container. Definiu casos d’ús almenys per a:

També considereu mirar casos d’ús natius de contenidors, com ara:

Recopileu casos d’ús específics parlant amb gent en esdeveniments tecnològics, fòrums d’internet i qualsevol altre espai viable.

Amplieu els serveis de monitorització (Feedback Pipeline) que:

A part de les funcionalitats, també necessitem:

Poder veure què està passant és un requisit previ per implementar qualsevol canvi. Veure totes les oportunitats rellevants ens ajuda a centrar-nos en les que tenen més impacte, i un seguiment transparent ens ajuda a demostrar la utilitat del nostre treball i a centrar-nos encara més en les activitats més impactants.

Minimitzeu la mida de la instal·lació dels casos d’ús optimitzant les dependències RPM, les funcionalitats, l’arquitectura del programari i altres factors. Específicament, busqueu:

Interaccioneu amb els desenvolupadors upstream pel que fa a canvis més grans en empaquetament i arquitectura. Un exemple és Systemd i la divisió del paquet systemd-sysuser.

Implementeu canvis de procés i política reflectint canvis més grans i generals. De nou, un bon exemple és utilitzar Systemd en contenidors, o el problema general de crear usuaris en contenidors.

Proporcioneu guia per a la comunitat Fedora en forma d’entrades de blog, vídeos i xerrades en conferències. Tot i que puguem tenir directrius i polítiques establertes, córrer la veu sempre és important.

Recursos al núvol per prototipar serveis. No canviarem la infraestructura existent de Fedora de cap manera abans que qualsevol cosa que desenvolupem demostri ser útil i valgui la pena per l’esforç d’estabilització i canvi de producció.

No es necessiten recursos existents d’Infraestructura de Fedora o d’Enginyeria de Versió en aquest moment. No obstant això, podríem necessitar ajuda per configurar (o obtenir accés a) els recursos al núvol.

El suport actiu dels nostres mantenidors, l’FPC i altres membres de la comunitat és definitivament necessari. Òbviament, això no és una cosa que puguem "sol·licitar", però encara és una entrada necessària.

Utilitat abans que la mida: Hi ha un equilibri entre la utilitat i la mida. Ho tenim en compte i no implementarem canvis dràstics que impedirien als nostres usuaris utilitzar Fedora. No obstant això, res no ens impedeix produir artefactes addicionals molt específics i mínims.

Utilitzant RPM: Estem fent això amb RPM. No estem aconseguint la minimització eliminant fitxers després de la instal·lació. Això pot ser obvi, però encara val la pena mencionar-ho.