Univerzalni paket menadžeri – Deo I

11. marta 2019.16. aprila 2019. Dragutin Ostojić 0 Komentara Linux

U ovom članku biće predstavljena ideja za poboljšani proces distribucije softvera na Linuks sistemima. Biće poređene prednosti tradicionalnih sistema baziranih na pakovanju za specifične distribucije sa kontejnerskim softverom koji funkcioniše na sistemima poput Flatpak, Snap ili AppImage. Novi proces obećava efikasnije korišćenje softvera u čitavoj zajednici slobodnog softvera, bolju podršku na korisničkim sistemima i istovremeno bolji kvalitet.

Danas Linuks i ceo ekosistem zajednice slobodnog softvera najčešće sav softver preuzima sa jednog izvora. To obično znači da je on dobro integrisan sa sistemom, može biti testiran u kombinaciji sa svakim drugim paketom i podrška dolazi od jednog distributera. U poređenju sa sistemima na kojima se svaki pojedninačni paket softvera preuzima od posebnog distributera i onda instalira manuelno, ovaj pristup ima velike prednosti. Jedna od njih je lako preuzimanje ispravki za sav instalirani softver na sistemu jednom komandom. U ovom modelu bazni sistem i softver dolaze iz istih ruku i mogu se testirati kao celina. Lakoća nadograđivanja sama po sebi predstavlja veliku prednost u odnosu na sisteme na kojima desetine aplikacija moraju zasebno uz asistenciju korisnika biti nadograđene, što oduzima puno vremena, a neblagovremeno ažuriranje može nositi i bezbednosne rizike.

Tradicionalno Linuks se oslanja na dva glavna formata paketa, to su .deb ( Debian ) i .rpm ( Red Hat ). Iako strukturno različiti, oba formata paketa sastoje se od upstream softvera prilagođenog za specifičnu distribuciju i skripti koje omogućavaju instalaciju zavisnosti kao što su biblioteke, uslužne aplikacije i drugi paketi koji već nisu instalirani na sistemu. Ovakav aranžman svodi trošenje prostora diska na minimum i verno je služio Linuks zajednicu dve decenije.

Međutim, u proteklih par godina, ovi tradicionalni formati počeli su da trpe kritike. Korisnici Linuksa povećali su očekivanja u pogledu korisničkog iskustva sa aplikacijama – želeli bi da ono bude slično iskustvu sa aplikacijama za npr. pametne telefone. Kritike upućene distribucijama koje koriste .deb i .rpm pakete uglavnom se odnose na striktne i komplikovane zahteve koji usporavaju uvođenje novih verzija i komplikuju podršku za Linuks zahtevanjem različitih verzija paketa za skoro svaku distribuciju.

Postoje i slabosti u vezi sa tim kako se trenutno bavimo razvojem i instalacijom softvera. Većina njih se odnosi baš na sistem ažuriranja. Uvek postoji čovek u sredini koji odlučuje o tome kada i šta treba da bude ažurirano. Rezultat je često zastarevanje aplikacija, što je loše i može proizvesti puno problema ako bezbednosne i druge ispravke ne budu dostavljene blagovremeno.

Glavni problem je što ovakav koncept rezultuje time da sistemi nisu uvek konzistentni. Paketi nisu instalirani u doslednom redosledu, i to znači da je svaki klijentski sistem jedinstven i nikada se neće poklopiti u potpunosti sa onim na kome su obavljena testiranja. Dok je .deb ili .rpm pakete lako napraviti, specifični zahtevi distribucija za njihovo postavljanje na zvaničnim repozitorijumima je mnogo striktnije i komplikovanije, što može dovesti do odlaganja dostupnosti nadogradnji, naročito za stabilna izdanja distribucija. Štaviše, svaka distribucija je različita, zahteva drugačije zavosnosti i koristi različite alate, tako da developeri neprestano menjaju pakete za svako pojavljivanje nove distribucije i svaku novu verziju neke postojeće. Takođe, i korisnici mogu imati problem sa nekonzistentnim zavisnostima i zastarelim paketima. Naročito postoji zabrinutost u vezi davanja pristupa arhivama koje stižu sa nezvaničnih repozitorijuma ( untrusted ). Problem nastaje kada takav sofver zahteva biblioteke koje nisu planirane da se instaliraju na toj distribuciji ili ih korisnici jednostavno ne žele, ili pak prepisuju postojeće biblioteke nepodržanim verzijama. Sve to može izazvati ozbiljne probleme u funkcionisanju celog sisema, a vraćanje sistema u prvobitno stanje često je komplikovano.

Sadržaj

Upstream, Maintenance i Downstream

Razvoj aplikacija se u tradicionalnom modelu može podeliti u više međusobno zavisnih tokova:

Upstream: Autor aplikacije objavljuje originalnu verziju aplikacije i vrši njeno razvijanje i održavanje.

Maintenance: Maintainer prilagođava aplikaciju za specifičnu distribuciju i zadužen je za njeno održavanje na toj distribuciji.

Downstream: U slučaju problema ili nedostataka aplikacije, korisnik se obraća maintainer-u koji rešava problem ili ga prosleđuje autoru, koji objavljuje ispravljenu originalnu verziju aplikacije, koju maintainer prilagođava distribuciji i nakon toga, ispravka postaje dostupna. Sličan je tok dešavanja i u slučaju da korisnik sam ponudi ispravku, koja može biti prihvaćena ili odbijena. U drugom slučaju, zbog navedenog procesa koji traje, ili iz nekog trećeg razloga, sam korisnik može objaviti svoju verziju aplikacije ( fork ) i taj tok razvoja predstavlja downstream.

Neke od najznačajnijih mana ovog modela su:

Neretko se dešava da je softver instaliran na „podržanoj“ distribuciji zastareo i da uopšte nije podržan od strane autora na dan kada dođe do korisnika. Što je još gore, politika koju koriste u mnogim distribucijama ograničava ažuriranje određenih paketa isključivo na ispravke koje se odnose na kritične sigurnosne probleme.
Softver pušten u distribuciju sa svojim problemima nije više podržan upstream i izveštaji o greškama koji se dostavljaju autorima su često nevažeći i ispravljeni su u novijim verzijama ili se od korisnika traži da testiraju najnoviju verziju koja najčešće nije dostupna na njihovoj distribuciji. To otežava rešavanje problema sa softverom i frustrirajuće je i za korisnika i za programera.
Čak i da su greške ispravljene na vreme, male su šanse da ih korisnici prime bez manuelnog instaliranja ( backporting ).
Pakovanje softvera za različite distribucije je značajno gubljenje vremena. Iako se taj proces može u određenoj meri automatizovati, to je i dalje daleko od idealnog zato što se obim posla množi brojem distribucija, a greške u pakovanju se jednostavno događaju zato što distributerski paketi ne razumeju u potpunosti kako je određeni deo softvera izgrađen i raspoređen i softverski stekovi često nisu dobro usklađeni.
Ciklusi podrške se razlikuju, što dovodi do dva problema:
- Distribucije treba da garantuju podršku za softver koji one ne proizvode.
- Programeri duži period nemaju uvid u kvalitete nove verzije, jer često treba da sačekaju sledeću verziju distribucije operativnog sistema da bi njihov softver stigao do krajnjih korisnika.
S obzirom na prethodnu stavku, potvrda o uspešnoj ispravci bug-a od strane korisnika stiže posle dugo vremena.
Postoji samo mali broj distribucija koje mogu da pakuju svaki pojedinačni deo korisničkog softvera koji je na raspolaganju. Ovo u suštini ograničava izbor korisnika, jer možda njegova omiljena distribucija jednostavno ne raspolaže svim potrebnim softverom.

Vrednost downstream razvoja

Primer odgovornog downstream toka je openSUSE koji koristi KDE Plasma okruženje za svoj operativni sistem. Pri pregledu verzije KDE-a koja treba biti upotrebljena, oni često nalaze određene probleme. Umesto da ih sami rešavaju, openSUSE tim prijavljuje probleme upstream tokom i pomaže u njihovom rešavanju, što kao krajnji proizvod daje brži razvoj i veći kvalitet softvera.

Jedan veliki problem sa kojim se trenutno suočavamo jeste raznovrsnost softvera koji se koristi downstream. Primer koji se često dešava je da Linuks distribucije kombinuju aplikacije sa različitim verzijama Qt okvira. Ovo nije samo problematično na desktopu, već se sreće i na pametnim telefonima. Pokretanje aplikacije koja korsti noviju umesto testirane verzije Qt-a, može rezultovati manjim brojem korisnicima vidljivih problema, što programere dovodi u iskušenje. Ukratko: Bilo bi bolje da se što više dešavanja sa downstream toka prebaci na upstream.

Upstream kao distributer softvera

Dakle, šta je ideja? Ona je radikalna, ali rešava dosta navedenih problema:

Dovodi do znatno smanjenog napora za pakovanje distribucija, jer su aplikacije samo jednom zapakovane, a ne jednom po distribuciji.
Mnogo manje kašnjenje od prijave do ispravljenog bug-a koji je stigao do korisnika.
Specifičnim softverom se bave samo ljudi koji ga najbolje poznaju.

Imajući pakete napravljene od strane upstream programera i uključujući sve zavisnosti kao deo svakog paketa, univerzalni paket menadžeri imaju za cilj pojednostavljivanje i ubrzavanje isporuke najnovijeg softvera korisnicima, kao i brzih povratnih informacija programerima.

Univerzalni paketi mogu dodati još jedan nivo sigurnosti pakovanjem aplikacija u kontejnere koji ih izoluju od ostatka sistema. Postojanje načina za razdvajanje domena sigurnosti na jednom desktopu omogućuje zaštitu od upada i gubitka privatnosti na mnogo bilji način. Većina članova zajednice se slaže da tradicionalni i univerzalni paket menažeri treba da se posmatraju kao kooperativni. Univerzalni paket menadžeri mogu znatno smanjiti količinu rada potrebnog za pakovanje distribucija.

Ograničenja univerzalnih kontejnera

Poznavaoci prilika su u velikoj meri primetili da bi Snap, koji je razvio Canonical, koji razvija popularni Debian derivat Ubuntu, i Flatpak, koji je razvio Red Hat, kao krajnji rezultat jednostavno mogli da naprave još jednu verziju podele između .deb i .rpm formata. Međutim, ova opservacija ne nudi ništa korisnije od ironije. Drugi razlozi su daleko važniji.

Za početak, kontejneri nisu univerzalna sigurnosna rešenja kako se ponekad pretpostavlja. Studijama iz 2017. godine utvređeni su mnogi sigurnosni problemi. Mnogi od njih se mogu pripisati još uvek ranim verzijama i nedovoljno testiranom softveru, ali veći je problem to što iako kontejneri mogu pružiti sigurnost od upada, ništa ne štiti korisnike od samog sadržaja kontejnera. Iako neki alati za automatizaciju procesa pakovanja mogu dosta ublažiti rizik od zastarelih biblioteka, još uvek puno toga ostaje na savesti programera koji pakuje paket.

Politika protiv tehnologije

Sve navedeno ukazuje na sledeće: Iako tehničke zajednice instinktivno traže rešenja u novoj tehnologiji, tehnologija ne zamenjuje potrebu za politikom.

Kada uporedimo .deb format sa univerzalnim paketima, .deb predstavlja samo arhiv datoteka, a ono što stvarno čini Debian paket onim što jeste je politika. Debian bez .deb formata bi i dalje bio Debian, a Debian bez svoje politike bio bi samo SourceForge ili Rpmfind, tj. kolekcija paketa i izvornog koda bez ukupne kontrole kvaliteta. Obimni dokument detaljno opisuje šta .deb paket mora da sadrži, šta ne sme sadržati, kako mora komunicirati sa ostalim paketima, gde treba postaviti datoteke, kako se logovati, kako dodati stavku menija u radno okruženje. Sve ovo, i više od toga, je jasno specificirano.

Pre nego što Debian paket može da pređe iz nestabilnog u test verziju ili stabilno stanje, on je u više navrata ispitivan u pogledu usklađenosti sa politikom Debiana. Zbog tako pažljivog nadzora, Debian je postao standard u Linuks zajednici i izvor dve trećine svih aktivnih distibucija, posebno onih koje se brinu o sigurnosti. Politika Debiana se ne završava samo na detaljnim specifikacijama. Ako pokrenete Debian sistem, kombinacija nadgledanja ispravki, potrebe za restartom i aktivnom bezbednosnom podrškom držaće sistem u stabilnom i sigurnom stanju. Debianov bezbednosni tim generalno češće ispravlja propuste nego što izbacuje nove verzije, čineći tako distribuciju veoma bezbednom za automatsku nadogradnju. Pri korišćenju stabilne verzije, svi slojevi krećući se na gore biće zaštićeni ovom šemom.

Do sada ni jedan univerzalni paket menadžer nije imao nikakvu politiku koja može da se poredi sa Debianovom. Međutim, u relativno ranoj fazi razvoja u kojoj se oni trenutno nalaze, to se možda i ne može očekivati. Ipak, na kraju, da li oni mogu isporučiti sve što obećavaju zavisiće od politike za izgradnju paketa, a ne samo od njihovih tehničkih karakteristika.

Upstream vs. distribucija

Sledeća pitanja koja se postavljaju su:

Ko će uspostaviti kontrolu kvaliteta na univerzalnom paketu?
U kom trnutku će proces objavljivanja paketa biti izvršen?

Tradicionalna kontrola kvaliteta se odvija na nivou distribucije. U mnogim slučajevima, upstream programeri tradicionalno isporučuju samo izvorni kod, ostavljajući pakovanje u potpunosti distribucijama. U krajnjem slučaju, oni pružaju pakete različitog kvaliteta za nekoliko popularnih distribucija.

Ovakav aranžman trpi kritike zbog teškoća pisanja aplikacija jer postoji toliko Linuks distribucija. Prema sadašnjem aranžmanu, upstream programeri nisu odgovorni za prilagođavanje njihovog koda distribucijama. Distribucije to rade za sebe. Na primer, kada je Steam bio prebačen na Linuks, originalni kod je prvo prilagođen za Ubuntu, a tek za nekoliko nedelja druge distribucije su prilagodile Ubuntu verziju za svoje potrebe.

Ipak, ako se univerzalni paketi objavljuju bez intervencije maintainer-a, implicira se da će upstream distributeri testirati pakete i sprovoditi samu politiku. Neki smatraju da je o novim alatima za univerzalno pakovanje jedini pravi način razmišljati kao o distribucijama. Moraćemo se baviti istim odgovornostima kojima se bavimo u svetu distribucija. Automatsko testiranje može pojednostaviti proces, ali u nekom trenutku to još uvek neko manuelno treba da uradi.

Štaviše, postoji zabrinutost u vezi toga da nisu sve distribucije strukturirane na isti način. One postavljaju fajlove na različite lokacije i ponekad koriste različite aplikacije za koordinaciju različitih verzija Linuksa. Još uvek ćete morati da razvijete i testirate sve na svakoj mogućoj distribuciji, osim ako ne uvežete svaku moguću zavisnost koja vam je potrebna, što je svakako daleko od idealnog rešenja ako tu uračunamo Gnome, X.org, GTK+, Qt…

AppImage pokazuje, kao rani napor u svetu univerzalnih paketa, da sama ideja o paketu koji se može pokrenuti na svakoj distribuciji trenutno nije potpuno realna. Jedini način da se to postigne je usvajanje nekog standarda, kao što je Linux Standards Base, koji bi koristila svaka distribucija, a to je napor koji nije uspeo u prošlosti.

Obećanje brzih izdanja, koje propagiraju univerzalni paketi, ipak predstavlja ideju za koju se vredi boriti. Međutim, na osnovu iskustva openSUSE-a, postoje i predlozi kontinuiranih rolling izdanja – stalnih i postepenih ažuriranja umesto formalnih objava kompletno novih verzija distribucija. U suprotnom, prelazak pripreme paketa na upstream programere čini dodatnu odgovornost, koju mnogi nisu spremni da prihvate. Neki smatraju i da pomeranje odgovornosti nije neophodno, jer maintainer-i već rade u toj ulozi i imaju potrebno iskustvo da to rade dobro.

Zaključak

Za veći deo sistema koji ostaje relativno statičan, trenutni način pakovanja softvera funkcioniše sasvim dobro. Ono što će novi sistemi pakovanja popraviti jesu aplikacije koje se brzo menjaju, gde su ažuriranja kritična za produktivnost korisnika ili jednostavno situacije u kojima korisnik prosto želi aktuelnu verziju softvera.

Zbog ovih razmatranja, oni koji očekuju da univerzalni paketi uskoro zamene tradicionalne formate biće razočarani. Niti, da budemo fer, oni koji razvijaju univerzalne pakete stvarno imaju takva očekivanja. Vidi se koegzistencija između konvencionalnih sistema upravljanja paketima i novih načina. Na primer .deb paketi nude fleksibilnost, dok Snap nudi jednostavnu upotrebu. Konvencionalni načini pakovanja su najbolje rešenje za izgradnju operativnih sistema gde mala grupa ljudi upravlja velikim brojem međusobno duboko povezanih paketa. Sa druge strane, Snap je bolje rešenje za distribuciju nezavisnih, samostalnih aplikacija, bez obzira da li se radi o desktop računarima ili serverima.

Slično tome Flatpak je zaista samo za desktop aplikacije. Postoji nada da razdvajanje aplikacija iz jezgra OS-a dovodi do modela u kojem se distribucije mogu fokusirati na poboljšanje jezgra, a ne na konkurenciju u tome koliko različitih aplikacija mogu da pakuju.

Pošto su univerzalni paketi postali široko prihvaćeni, njihove primene postaće uskoro očiglednije. Distribucije već šalju dobre signale, pripremajući sledeće verzije za sve formate univerzalnih paketa. U međuvremenu, dok se univerzalni paketi ipak još uvek samo razvijaju, znati šta mogu, a šta ne mogu učiniti je veoma važno da bi se suprotstavili rastu nerealnih očekivanja.

Praktična primena univerzalnih paket menadžera biće predstavljena u drugom delu.

Reference

Autor: Dragutin Ostojić

Sarednik u nastavi na Prirodno-matematičkom fakulteti u Kragujevcu i nastavnik u Prvoj kragujevackoj gimnaziji.

Upstream, Maintenance i Downstream

Vrednost downstream razvoja

Upstream kao distributer softvera

Ograničenja univerzalnih kontejnera

Politika protiv tehnologije

Upstream vs. distribucija

Zaključak

Reference

Autor: Dragutin Ostojić

Podeli ovo:

Dragutin Ostojić

Možda Vam se svidi i

Univerzalni paket menadžeri – Deo II

Systemd – Linux init sistem – deo I

IPTables firewall – praktikum – Deo I