Fedoras minimeringsmål

Medan Fedora är väl lämpat för traditionella fysiska/virtuella arbetsstationer och servrar förbises det ofta för användingsfall vid sidan av traditionella installationer.

Några moderna sorters utplaceringar — såsom IoT och behållare — är ganska känsliga för storlek. För IoT är det ofta långsamma dataförbindelser (för uppdateringar/hantering) och för moln och behållare är det dess massiva skala.

Ett specifikt exempel är Systemd — medan det är väldigt användbart (alla älskar systemd) och alltid finns på fysiska system, behövs det sällan i behållare. Så det var inte ett problem för paketerare att begära Systemd bara för systemd-sysusers för att skapa användare. I behållare, däremot, betyder det en signifikant storleksökning.

Vid sidan om det vinner i princip alla sorters utplaceringar på en reducerad storlek, eftersom det finns ett direkt samband mellan installationens fotavtryck och attackytor och relevanta CVE:er.

Tusentals individuella och företagsmedarbetare samarbetar i Fedoragemenskapen för att utforska nya problem och att bygga ett snabbrörligt modernt OS med ett rikt ekosystem som tillåter dem att expermimentera med att modernisera sin dess infrastruktur.

Att hjälpa utvecklare av öppen källkod, systemadministratörer och de som underhåller Linuxdistributioner att fokusera på vad som är relevant för dem.

Fedora är en populär plattform för att dess ekosystem är både det allra senaste och väl optimerat för moderna installationer såsom IoT och behållare. Det gör att många använder Fedora snarare än att bygga och sätta samman sina egna artifakter direkt från uppströmsprojekt. Och det tar bort trycket på utvecklare av öppen källkod som orsakas av användare som annars skulle bet dem om sina specifika säkerhets- och andra ärenden att rättas snabbt.

Så att:

Specifika användningsfall definieras i Fedora. Gemenskapen fokuserar sedan på dessa användningsfall med utveckling och underhåll, optimering (såsom minimering) och testning (såsom kontinuerlig integration och slussning (gating)). Dessa användningsfall kan prioriteras transparent till infrasturkturresurser baserat på gemenskapsintressen.

En återkopplingspipeline övervakar aktivt varje användningsfall och registrerar storleken och beroendena som krävs för att det skall köra. Datahistoriken sparas och visas för att se ändringar över tid. Och för att hålla saker små över tiden upptäcker även återkopplingspipelinen automatiskt storleksökningar och öppnar potentiellt automatiskt Bugzilla-ärenden för att spåra/fixa/justera sådana ökningar transparent.

Ett aktivt fokus på minimering betyder att våra medarbetare producerar storleksoptimerat innehåll med samma eller lägre ansträngning. Verktyg, tjänster och data hjälper dem att ta de rätta besluten om beroenden lätt, och att bevara saker små över tiden.

Identifiera relevanta användningsfall och låt gemenskapen (vilket inte bara betyder minimeringsgruppen) definiera sina egna. Vi tänker på ett användningsfall som en uppsättning paket som installeras i en specifik miljö, har ett specifikt syfte — såsom Apache HTTP Server Container. Definiera användningsfall åtminstone för:

Överväg även att titta på användningsfall för behållare, såsom:

Samla specifika användningsfall genom att tala med folk på teknikevenemang, internetforum och andra möjliga vägar.

Utöka övervakningstjänster (åtekopplingspipeline) som:

Förutom funktioner behöver vi även:

Att kunna se vad som pågår är en förutsättning för att implementera några ändringar. Att se alla relevanta möjligheter hjälper oss att fokusera på de dem som har den största effekten, och att transparent spåra hjälper oss att bevisa att våra verk är användbara, och att ytterligare fokusera på de aktiviteter som har störst påverkan.

Minimera installationsstorleken av användningsfallen genom att optimera RPM-beroenden, funktioner, programvaruarkitektur och andra faktorer. Leta särskilt efter:

Engagera oss med uppströmsutvecklare gällande större ändringar i paketering och arkitektur. Ett exempel är Systemd och att separera paketet systemd-sysuser.

implementera process- och policyändringar som avspeglar större, mer generella ändringar. Återigen är användningen av Systemd i behållare ett bra exempel, eller den allmänna frågan om att skapa användare i behållare.

Ge ledning för Fedoragemenskapen i form av bloggpostningarn, videor och konferensföredrag. Även fast vi kan ha riktlinjer och policyer på plats är det alltid viktigt att sprida ordet.

Molnresurser för att göra prototyper för tjänster. Vi kommer inte ändra den befintliga Fedorainfrastrukturen på något sätt före vad vi än utvecklar visar sig användbart och värt besväret med stabilisering och ändring av produktionen.

Inga av Fedoras befintliga resurser för infrastruktur eller utgåveteknik behövs för närvarande. Dock kan vi behöva hjälp med att sätta upp (eller få åtkomst till) molnresurserna.

Aktivt stöd från de som sköter paketen, FPC och andra gemenskapsmedlemmar behövs definitivt. Detta är uppenbarligen inte något vi kan ”begära”, men det är fortfarande nödvändig indata.

Användbarhet framför storlek: Det finns en balans mellan användbarheten och storleken. Vi har det i åtanke och kommer inte implementera drastiska ändringar som skulle hindra våra användare från att använda Fedora. Dock finns det inget som hindrar oss från att skapa en väldigt specifika minimala artifakter.

Använda RPM: Vi gör detta med RPM. Vi åstadkommer inte minimering genom att radera filer efter installationen. Detta kanske är uppenbart, men fortfarande värt att nämna.