Fedora minimalisatie doelstelling

Hoewel Fedora zeer geschikt is voor traditionele fysieke/virtuele werkstations en servers, wordt het vaak over het hoofd gezien voor gebruik buiten traditionele installaties.

Sommige moderne soorten implementaties — zoals IoT en containers — zijn behoorlijk gevoelig voor grootte. Voor IoT zijn dat meestal trage dataverbindingen (voor updates/beheer) en voor cloud en containers is het de enorme schaal.

Een specifiek voorbeeld is Systemd — hoewel het erg handig is (iedereen houdt van Systemd) en altijd aanwezig is op fysieke systemen, is het zelden nodig in containers. Het was dus geen probleem voor pakketten om Systemd alleen voor systemd-sysusers te vereisen om gebruikers aan te maken. In containers betekent dat echter een aanzienlijke toename van de omvang.

Daarnaast profiteren in principe alle soorten implementaties van een kleinere omvang, omdat er een directe relatie is tussen de installatievoetafdruk en aanvallen op oppervlak & relevante CVE’s.

Duizenden individuele en zakelijke bijdragers werken samen in de Fedora-gemeenschap om nieuwe problemen te onderzoeken en een snel bewegend modern besturingssysteem te bouwen met een rijk ecosysteem waarmee ze kunnen experimenteren met het moderniseren van hun infrastructuur.

Open source-ontwikkelaars, systeembeheerders en Linux-distributiebeheerders helpen zich te concentreren op wat voor hen relevant is.

Fedora is een populair platform omdat het ecosysteem zowel hypermodern als goed geoptimaliseerd is voor moderne implementaties zoals IoT en containers. Dat maakt dat veel mensen Fedora gebruiken in plaats van hun eigen artefacten rechtstreeks vanuit upstream projecten te bouwen en samen te stellen. En dat verlicht de druk op open bron-ontwikkelaars die wordt veroorzaakt door gebruikers die anders zouden vragen om hun specifieke beveiliging en andere problemen snel op te lossen.

Dus:

Specifieke use-cases zijn gedefinieerd in Fedora. De gemeenschap richt zich vervolgens op die use-cases met ontwikkeling en onderhoud, optimalisatie (zoals minimalisatie) en testen (zoals CI en gating). Deze use-cases kunnen transparant worden geprioriteerd voor infrastructuurbronnen op basis van gemeenschapsbelangen.

Feedback Pipeline bewaakt actief elke use-case en registreert de grootte en de afhankelijkheden die nodig zijn om deze uit te voeren. Datageschiedenis wordt bewaard en getoond om veranderingen in de tijd te zien. En om de zaken in de loop van de tijd klein te houden, detecteert Feedback Pipeline ook automatisch de toename van de grootte en opent mogelijk automatisch Bugzilla-bugs om dergelijke verhogingen transparant te volgen/repareren/rechtvaardigen.

Een actieve focus op minimalisatie betekent dat onze beheerders met dezelfde of een kleinere inspanning geoptimaliseerde inhoud produceren. Gereedschappen, services en data helpen hen om gemakkelijk de juiste beslissing te nemen over afhankelijkheden en om de zaken na verloop van tijd kleiner te houden.

Identificeer relevante gebruiksscenario’s en sta toe dat de gemeenschap (dus niet alleen het minimalisatieteam) hun eigen behoefte definieert. We beschouwen een use-case als een set pakketten die in een specifieke context zijn geïnstalleerd en een specifieke doel hebben partner hebben, — zoals Apache HTTP Server Container. Definieer use-cases ten minste voor:

Overweeg ook om te kijken naar container-native use-cases, zoals:

Verzamel specifieke use-cases door met mensen te praten op technische evenementen, internetforums en andere haalbare locaties.

Bewakingsdiensten uitbreiden (Feedback Pipeline) die:

Afgezien van functies, moeten we ook:

In staat zijn om te zien wat er aan de hand is, is een vereiste om eventuele wijzigingen door te voeren. Door alle relevante kansen te zien, kunnen we ons concentreren op degenen die de meeste impact hebben, en een transparante tracking helpt ons de bruikbaarheid van ons werk te bewijzen en ons verder te concentreren op de meest impactvolle activiteiten.

Minimaliseer de installatiegrootte van de use-cases door RPM-afhankelijkheden, functies, software-architectuur en andere factoren te optimaliseren. Kijk in het bijzonder naar:

Werk samen met upstream-ontwikkelaars met betrekking tot grotere veranderingen in verpakking en architectuur. Een voorbeeld is Systemd en het splitsen van het systemd-sysuser pakket.

Implementeer proces- en beleidswijzigingen die grotere, meer algemene veranderingen weerspiegelen. Nogmaals, een goed voorbeeld is het gebruik van Systemd in containers, of het algemene probleem van het aanmaken van gebruikers in containers.

Bied begeleiding voor de Fedora gemeenschap in de vorm van blogposts, video’s en conferentielezingen. Ook al hebben we misschien richtlijnen en beleid in orde, het verspreiden van het woord is altijd belangrijk.

Cloudhulpbronnen voor prototypeservices. We gaan de bestaande Fedora-infrastructuur op geen enkele manier veranderen voordat alles wat we ontwikkelen nuttig blijkt te zijn en de drukte van stabilisatie en veranderende productie waard is.

Er zijn op dit moment geen bestaande Fedora Infra of Release Engineering hulpmiddelen nodig. Mogelijk hebben we echter hulp nodig bij het instellen (of krijgen van toegang tot) de cloudhulpbronnen.

Actieve ondersteuning van onze beheerders, de FPC en andere leden van de gemeenschap is zeker nodig. Dit is natuurlijk niet iets dat we kunnen "vragen", maar het is nog steeds een noodzakelijke input.

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 gebruiken: We gaan dit doen met RPM. We bereiken geen minimalisatie door bestanden na installatie te verwijderen. Dit is misschien voor de hand liggend, maar toch het vermelden waard.