Fedoran minimointitavoite

Vaikka Fedora sopii hyvin perinteisiin fyysisiin/virtuaalisiin työasemiin ja palvelimiin, se jätetään usein huomiotta perinteisten asennusten ulkopuolisissa käyttötapauksissa.

Jotkut nykyaikaiset käyttöönottotyypit — kuten IoT ja kontit — ovat melko herkkiä koolle. IoT:n osalta, joka on yleensä hidas datayhteys (päivityksiä / hallintaa varten), ja pilvipalvelujen ja konttien osalta se on massiivinen.

Nimenomainen esimerkki on Systemd — vaikka se onkin erittäin hyödyllinen (kaikki rakastavat Systemd: tä) ja on aina läsnä fyysisissä järjestelmissä, sitä tarvitaan harvoin säiliöissä. Joten pakettien ei ollut ongelma vaatia Systemd:tä vain systemd-sysusers:lle käyttäjien luomiseen. Säiliöissä tämä tarkoittaa kuitenkin merkittävää koon kasvua.

Tämän lisäksi periaatteessa kaikentyyppiset käyttöönotot hyötyvät pienemmästä koosta, koska asennuksen jalanjäljen ja pinta- ja asiaankuuluvien CVE:n välillä on suora yhteys.

Tuhannet yksityishenkilöt ja yritykset osallistuvat Fedora-yhteisöön yhteistyössä uusien ongelmien tutkimiseksi ja nopeasti kehittyvän modernin käyttöjärjestelmän ja rikkaan ekosysteemin rakentamiseksi, jotta he voivat kokeilla infrastruktuurinsa modernisointia.

Autamme avoimen lähdekoodin kehittäjiä, järjestelmänvalvojia ja Linux-jakelun ylläpitäjiä keskittymään heidän kannaltaan tärkeisiin asioihin.

Fedora on suosittu alusta, koska sen ekosysteemi on sekä huippuluokan että hyvin optimoitu nykyaikaiseen käyttöönottoon, kuten IoT:iin ja kontteihin. Tämä saa monet ihmiset käyttämään Fedoraa pikemminkin kuin rakentamaan ja kokoamaan omia esineitään suoraan alkupään projekteista. Ja tämä lievittää paineita avoimen lähdekoodin kehittäjille, jotka aiheutuvat käyttäjiltä, jotka muuten pyytävät heidän erityisten turvallisuus- ja muiden ongelmiensa korjaamista nopeasti.

Siten:

Erityiset käyttötapaukset on määritelty Fedorassa. Sitten yhteisö keskittyy niihin käyttötapauksiin, joihin sisältyy kehitys ja ylläpito, optimointi (kuten minimointi) ja testaus (kuten CI ja portointi). Nämä käyttötapaukset voidaan priorisoida avoimesti infrastruktuuriresursseille yhteisön etujen perusteella.

Feedback Pipeline seuraa aktiivisesti kutakin käyttötapausta ja tallentaa sen suorittamiseen tarvittavan koon ja riippuvuudet. Tietohistoria säilytetään ja näytetään muutosten näkymiseksi ajan myötä. Ja jotta asiat pysyisivät pieninä ajan myötä, Feedback Pipeline havaitsee myös koon kasvun ja avaa mahdollisesti automaattisesti Bugzilla-virheet seuraamaan/korjaamaan/perustelemaan tällaisia lisäyksiä avoimesti.

Aktiivinen keskittyminen minimointiin tarkoittaa, että ylläpitäjämme tuottavat koon mukaan optimoitua sisältöä samalla tai pienemmällä vaivalla. Työkalut, palvelut ja tiedot auttavat heitä tekemään oikean päätöksen riippuvuuksista helposti ja pitämään asiat ajan myötä pienempänä.

Tunnista asiaankuuluvat käyttötapaukset ja anna yhteisön (ei vain minimointitiimin) määritellä omat. Mielestämme käyttötapaus on pakettien joukko, jotka on asennettu tiettyyn kontekstiin ja joilla on tietty tarkoitus – kuten Apache HTTP Server Container. Määritä käyttötapaukset ainakin:

Harkitse myös tarkastella konttikohtaisia käyttötapauksia, kuten:

Kerää erityisiä käyttötapauksia puhumalla ihmisten kanssa teknisissä tapahtumissa, internet-foorumeilla ja muissa kannattavissa paikoissa.

Laajenna valvontapalveluja (palauteputki), jotka:

Ominaisuuksien lisäksi tarvitsemme myös:

Kaikkien muutosten toteuttamisen edellytys on kyky nähdä, mitä tapahtuu. Kaikkien asiaankuuluvien mahdollisuuksien näkeminen auttaa meitä keskittymään niihin, joilla on eniten vaikutusta, ja läpinäkyvä seuranta auttaa todistamaan työmme hyödyllisyyden ja keskittymään edelleen vaikuttavimpiin toimintoihin.

Minimoi käyttötapausten asennuskoko optimoimalla RPM-riippuvuudet, ominaisuudet, ohjelmistoarkkitehtuuri ja muut tekijät. Etsi erityisesti:

Ota yhteyttä ylävirran kehittäjiin koskien suurempia muutoksia pakkauksessa ja arkkitehtuurissa. Esimerkki on Systemd ja paketin systemd-sysuser jakaminen osiin.

Ota käyttöön prosessi- ja käytäntömuutoksia, jotka heijastavat suurempia, yleisempiä muutoksia. Jälleen hyvä esimerkki on Systemd:n käyttö konteissa tai yleinen ongelma käyttäjien luomisesta konteissa.

Tarjoa ohjeita Fedora-yhteisölle blogitekstien, videoiden ja konferenssikeskustelujen muodossa. Vaikka meillä saattaa olla ohjeita ja käytäntöjä, sanan levittäminen on aina tärkeää.

Pilviresurssit prototyyppipalveluihin. Emme aio muuttaa olemassa olevaa Fedora-infrastruktuuria millään tavalla, ennen kuin kaikki kehittämämme osoittautuu hyödylliseksi ja vakauden ja tuotannon muuttamisen vaivan arvoiseksi.

Tällä hetkellä ei ole tarvetta Fedora Infra- tai Release Engineering -resursseille. Saatamme kuitenkin tarvita apua pilviresurssien määrittämisessä (tai niihin sisään pääsemisessä).

Aktiivista tukea ylläpitäjiltämme, FPC:ltä ja muilta yhteisön jäseniltä tarvitaan ehdottomasti. Tätä emme tietenkään voi "pyytää", mutta se on silti välttämätön apu.

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:n käyttäminen: Teemme tämän RPM:illä. Emme saavuta minimointia poistamalla tiedostoja asennuksen jälkeen. Tämä saattaa olla ilmeistä, mutta silti mainitsemisen arvoista.