Da li je budućnost distribuiranja aplikacija u posvećenim container sistemima?

Kao što su AppImages, Flatpaks i Snaps? Siguran sam da jesu, ali nisam siguran koji će sutra dominirati, mada bih nešto voleo da to budu Flatpaks.

Ovde pričam o scenariju gde su, nakon instalacije Linux distribucije, aplikacije isporučene preko Flatpakova, recimo. Nema situacije gde uz svežu verziju distribucije stiže malo ranija verzija Firefoxa, na primer, gde moraš da čekaš na upgrade distribucije na neku novu major verziju kako bi dobio noviju verziju Firefoxa, gde opet postoji dobra šansa da i tada neće stići sa poslednjom stabilnom verzijom. Pored toga što se uvek može isporučiti poslednja stabilna verzija softvera, nezavisno od trenutnog "stanja" sistema (u smislu trenutne faze razvoja distribucije), u prilog ovome svakako idu stabilnost i bezbednost tako isporučenih aplikacija.

U prilog najvise ide to da se u svemu ide na taj immutable status - sto je u sustini dobra stvar. Spakuje ti developer sve kako treba i sve zajedno - i to radi. Lici malo na staticko linkovanje od pre... ;) Da li je to docker, flatpack ili snap format, tebi je kao korisniku bitno da imas sve uredno spakovano i da znas da radi, mali izolovani svet koji niko ne dira. Python ima venv vec neko vreme koji radi nesto slicno, ali ovo je jos bolje, bukvalno dobijes paketic koji nema nista da se menja, od kad ga stavis do kraja, ne zavisi ni od cega, eliminises mogucnost za ROP jer realno flatpack nema sta da cita van sebe, bukvalno ga izolujes od ostatka sistema. Za desktop, da, milina.

Apple to radi isto vec godinama, vecina apple "applications" su samo spakovani fajlovi u kojima je sve sto app-u treba, biblioteke i sve.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Sto se mene tice, to unistava svrhu shared objects, tj biblioteka koje se jednom ucitaju za ceo sistem, tako da mi ovo vise lici na MAcizam nego nego na Unix filozofiju. Ono sto je prednost ovakovg nacina
je sto se dependencies bundluju sa aplikacijom pa je instalacija jednostavnija...

Dođoh ovde da se dopunim i napišem ovo. :)

Zbog ovakvih stvari postoji Fedora Silverblue. elementary OS isto ide u ovom smeru, gde koriste Ubuntu LTS za osnovu sistema, a ostatak isporučuju preko Flatpaka.



Kakve veze ima što liči na njih? macOS, iOS i Android već dugo koriste ovakav model. Da ne valja, valjda ga ne bi koristili.

Činjenica je da ovo obezbeđuje stabilniji i bezbedniji sistem, a kao dodatan benefit pruža i redovno ažuriranje aplikacija na poslednju stabilnu verziju u svakom trenutku.

Ali i nepotrebno zauzimanje prostora na hdd ili ssd. Pet aplikacija koje koriste istu verziju jedne biblioteke smeštaju istu biblioteku na 5 mesta.

Potpis

Po temi http://www.elitesecurity.org/t385534-0 ja sam terorista.
Use The Force my young Luke Filewalker.

Stefan:"Kakve veze ima što liči na njih? macOS, iOS i Android već dugo koriste ovakav model. Da ne valja, valjda ga ne bi koristili.

Činjenica je da ovo obezbeđuje stabilniji i bezbedniji sistem, a kao dodatan benefit pruža i redovno ažuriranje aplikacija na poslednju stabilnu verziju u svakom trenutku."

Ima veze, sto dodatno jede i memoriju i kako je madcama lepo primetio prostor na disku. Osim toga svi distroi dolaze sa paketima koji su kompajlirani za tekuci distro
i o tome se brinu distro maintejneri. Dakle potpuno nepotrebno da vuces depeendencies na tim sistemima. Ljudima ovakav nacin instalacije na Linux-u treba samo
ako hoce da instaliraju verziju koja ili novija ili starija i koja se ne uklapa u dependencije na tekucem distru.

Mislim da je danas sam prostor sve manje problem, kada se kapacitet meri u terabajtima. Sa druge strane, ranije se moglo desiti da recimo imate aplikaciju A i aplikaciju B, koje dele neku biblioteku. Onda aplikacija A apdejtuje tu (deljenu!) biblioteku i aplikacija B pocne da brlja iz nekog razloga. Ako svaka aplikacija ima svoj library pool, ovo se nece desiti.

fighter:""Onda aplikacija A apdejtuje tu (deljenu!) biblioteku"

To se ne desava na Linux distroima zato sto se biblioteke nezavisno apdejtuju, a aplikacije kompajliraju sa tako apdejtovanim bibliotekama.
Znaci ne apdejtuje se biblioteka, nego obrnuto, aplikacija. Dakle samo u slucaju da vuces nesto van repoa, treba ovaj nacin, sto je normalno
za komerijalne operativne sisteme posto tamo ne mozes da iskompajiras iz source-a niti mozes odvojeno zbog toga da odrzavas biblioteke.

Da stvarno ima neke značajne veze, ne bi se tako radilo na macOS, iOS i Android sistemima.
Ali nema veze. Niti jede značajno više memorije (ako se neko dohvati nekih benchmarkova da bi dokazao suprotno, barem neka se dohvati nekih svežijih, iz poslednjih par godina, zbog relevantnosti), niti je prostor na disku danas neki problem, i verovatno više nikada neće ni biti problem u ovom pogledu. Dakle, te stvari su se smatrale potencijalnim problemima u neka ranija vremena.



Ovo je upravo jedan od problema. Pripremanje svakog paketa po hiljadu puta kako bi se otpremio za svaki distro je suludo. Korisnik ne treba da ispašta, brinući o tome da li željeni distro uključuje sav neophodan 3rd party softver koji želi da koristi i da li njihov distro ima ažurne verzije istog. Naročito ne treba da razmišlja koliko će nedelja ili meseci (što se često događa) maintaineri odlagati otpremanje bug fixeva, jer moraju da se krpe i drndaju sa upstreamom.

To o čemu govoriš ima smisla za pakete koji su zapravo deo osnovnog sistema, ali ovo ne mora (kako vreme prolazi, izgleda da po mnogima danas i ne treba) da važi za korisničke aplikacije koje sede na OS-u.

Dalje, posvećeni container sistemi nisu tu, pre svega, da bi krajnjem korisniku život bio lakši, već upravo package maintainerima. Ako maintaineri imaju lakši posao, pre će se isporučiti ažurirane verzije. S tim u vezi, Flatpak poseduje neke karakteristike koje ZIP, DEB i APK ne nude. Na primer, Flatpak za Firefox je tako izolovan, da ima pristup samo Downloads direktorijumu. Ovo je jedan od mnogih primera kako Flatpak značajno unapređuje bezbednost. Ako se neki Flatpak zarazi malicioznim softverom, potencijalna šteta je drastično ograničena.

OK, mislim stoji, u teoriji ima par desetina megabajta memorije vise, skida se pa stotina megabajta sa neta i snima par stotina megabajta vise na disk. Sve stoji. :)

Onda pogledas kako izgleda server-side container orchestration i skontas da ti treba tri servera da trce raft algoritam za etcd i da svaki mora da ima bar 16GB RAM (pozeljno bar 32GB), da bi na njemu trcao i APi i gateway, a to je sve samo infra, nula za kod. Dobar dan, kontejner orchestration za vas web shop od 50 posetilaca dnevno? Moze, daj jedno 128GB RAM.

When in doubt, throw RAM at it. Realno, ovo je mantra vec neko vreme.

Sustina nije, bar ne vise, sta je "cisto", vec sta bolje radi. Sta se dobija? Realno, danas optimizacioni kompajler trpa char u 64-bitnu promenjlvu ;) - jer tako se lepo uravna, pa o cemu mi pricamo? Prednosti ovog nacina rada su velike - i to je ono sto se trenutno gleda. Mane postoje, uglavnom ove koje je Bane naveo, ali, realno, RAM-a ima, danas svaki normalan racunar ima 8-16GB RAM (ako nema, baci ga i kupi nov, upgade je komplikovan, a data ti je uonako u cloud-u, zar ne? :) ) .

Zapravo, prednosti jesu velike. Lakse je spakovati kontejner nego bildati za distro, radi bolje... sta da se covek nevira? Sta se, osim malo RAM-a, potrosi? Realno?

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Ako bi biblioteke u nazivu sadržavale i verziju, svaka aplikacija bi mogla da referencira najnoviju verziju koju podržava.
Kako je bilo kod VB i sada kod .NET-a, na istoj instalaciji OS-a mogu da postoje sve verzije biblioteka koje instalirane aplikacije zahtevaju, zašto tako ne može u opštem slučaju?
Jeste da problem mogu da prave biblioteke koje su sastavni deo OS-a (API i sl.), ali tu valjda postoji neka kompatibilnost između 'minor' revizija, odnosno verzija, inače bi novije verzije svih aplikacija zezale na prethodnoj verziji OS-a.

Mada, evo i kod Win 10 je počelo sa "requires Win 10 build version 19nnnn.nnnn", tako da je neka biblioteka najmanji problem.

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

Svaka platforma, os itd... hoce da te utera u svoje app pakovanje. Jedan od razloga je bezbednost, zatim standardizacija, a treci mnogo vazniji jeste da delegira odgovornost za rad tvog programa tebi, da ne bi bilo zabune tipa, ne radi app jer ... Takodje odavnina app su mogle da se pakuju na ovaj nacin u smislu da sve pinkle distribuiras sa svojom app, ali ono sto je danas drugacije jeste formalizacija tog zahteva u zavisnosti od platforme.

Zauzima vise mesta na disku, ali ne bi trebalo da zauzima vise mesta u memoriji, mislim teoretski instanciranje os shared ili istog tog lib-a u kontejneru treba da rezultira istom kolicinom memorije, sta vise ako licenciranje dopusta, mozes i da osisas lib samo za tvoje potrebe, pa da bude manje :)

OK, ajde ovako:

Pros :

- Applikacija radi nezavisno od libova koji dolaze uz OS.
- Aplikacija se lakse pakuje od strane osobe koja je odrzava
- Aplikacija je bolje izolovana od ostatka sistema (security)
- Aplikkacija je spakovana u kontejner koji je immutable (opet, security, verified by hash...)

Cons:

- Uzima, mozda, jako malo vise memorije
- Uzima nesto vise prostora na disku
- Ne uklapa se u neku filozofiju.... ?

Pitanja:

1) Jesam li nesto propustio ?
2) Da li tradeoff vredi ?

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Možda još u pros da je testiranje olakšano, jer znaš sa kojim bibliotekama tvoja aplikacija radi na svim računarima, ovako bez toga nikad ne znaš šta na nekom računaru ima ili nema, pa ako je u pitanju računar u firmi koji izlazi preko nekog proxy-a koji ima zabrane preuzimanja dll/exe i ko zna čega još, aplikacija/OS ima problem da povuče tu biblioteku sa interneta, ovako je ima u svom folderu.
Takođe, nema opasnosti da pri instalaciji aplikacija zameni postojeću biblioteku na OS-u novijom verzijom iste (neko iznad već pomenuo sličnu situaciju), N puta mi se desilo da installer prikaže poruku da je na sistemu neki .dll koji je noviji od onoga koji dolazi uz aplikaciju i pita da li da ostavi tu noviju - šta god odabere korisnik, može se desiti da mu nešto ne radi, bilo ta aplikacija (ako ostavi postojeću biblioteku) ili neka druga (ako postojeću prepiše ovom starijom verzijom).

Sećam se od pre 15 ili tako nešto godina kad su prestali da isporučuju određene VB biblioteke, a posebno VBRUN300.dll, a stalno sam nailazio na aplikacije koje traže tu biblioteku, a još nije zaživelo to da aplikacija povuče sa interneta šta nedostaje (kao što neki installer-i povuku .NET koji im treba), jer je verzija aplikacije iz vremena kad je taj dll dolazio uz Windows... i ti sad nađi na net-u vbrun300.dll (nije teško, ali ima sajtova gde ti uvale neki "freeware" ili ko zna šta uz taj dll, sad kad tražiš ima gde hoćeš, ali sećam se da nije bilo lako naći odgovarajući fajl, jer ih je bilo različite veličine u kilobajtima, pa sam posle nekog vremena počeo da nosim na flešu tih nekoliko DLL-ova koje su tražile starije aplikacije.

To je samo jedan od primera kad App traži neku biblioteku, a mora ručno da se juri na internetu... ovako, da je tada postojala mogućnost u VS-u da tu biblioteku upakuju sa aplikacijom, i svaka aplikacija ima odgovarajući vbrun123.dll u svom folderu umesto da traži u sistemskom.

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

Najveći problem je što umesto jednog, imamo 3 "standardna" pakovanja. I plus neki programi imaju binary pakovanje koje nije nijedno od navedenih :d

Canonical gura snap, koji iako je dostupan i na drugim distribucijama, nisam siguran da može postati standard. AppImage i Flatpak mi se čine kao popularnije i bolje varijante.

Koliko je sve to dobro ili loše, nemam pojma. Kada sam prvi put probao OS X i video kako to funkcioniše, bilo mi je izuzetno glupo rešenje. Sad više nisam siguran, pošto jednostavno radi. Posebno AppImage i Flatpak. Pri tom je flathub dobar repo i ima dobru integraciju sa paket menadžerima (Discover, Store...). Sigurno je ljudima lakše da spakuju program u jedan format dostupan svima, nego da održavaju 5 repoa za nekoliko distribucija. Takođe, na ovaj način se lako mogu instalirati/koristiti različite verzije istog programa.

Jesi.

Poenta gradnje i pakovanja na strani distribucije tek je sekundarno manje zauzeća diska i memorije.

Primarna poenta je ova. Kad autor oprema program da ga treće strane grade i uklapaju u sistem, mora to mnogo strože, temeljnije da uradi. Zatim mora da reaguje na reakcije mnogobrojnih graditelja i ispravlja prijavljenje probleme, tehničke (tipa bezbednost) i političke (tipa licenciranje). Program postaje takav da bilo koja treća strana zaista ima dobre šanse da program izgradi, ispita i prilagodi za svoje potrebe, uključujući upotrebu i prebacivanje na različite sisteme. To je okosnica dugoročne tehničke održivosti jednog programa, kao i njegove bezbednosti. Posebno bezbednosti korisnika od samih autora programa, gde su gradioci stražari između korisnika i autora.

Kao primer sa drugih operativnih sistema, ovo su razlozi, na primer, zašto na Androidu F-droid zahteva od autorâ da umesto gotovih paketa prilože izvorni kôd opremljen za gradnju, koji zatim F-droid gradi. F-droid u napomenama uz program zatim navede eventualne mane za korisnike, tipa reklamiranja unutar programa, odašiljanja telemetrije ili oslanjanja na prevaziđene zavisnosti sa poznatim bezbednosnim problemima.

Što se mene lično tiče, kontejnerizacija mi ne smeta samo kod programa za „jednu upotrebu“, npr. kod igara. Ali čak i tada ne svih igara; one poput Flajtgira ili Friciva itekako treba (i jeste) da budu opremljene za gradnju na trećoj strani.

(Ova rasprava je inače stara već preko 20 godina, i ne vidim da se išta u tom pogledu promenilo.)