Vlákno názorů k článku Flatpak, Snap, Modularity: počátek konce éry balíčkovacích systémů? od Oriwen - Pořád nechápu smysl těch baličů. Buď chci mít...
-
Petr M (neregistrovaný)
Změna balíčkovacího systému by částečně pomohla v případě, že by balíček nedeklaroval závislost na "ABC", ale závislost na "ABC minimálně verze xyz" a balíčkovací systém se podíval, jestli odpovídající knihovnu má. Pokud ne, stáhne ji použije. Takže hybrid - ty si definuješ závislosti, balíčkovač se postará, aby tam byla potřebná verze potřebnýho balíčku a launcher podstrčil do envu cestu ke korektní knihovně.
Pokud jsem správně pochopil OsTree, mělo by to fungovat zhruba takhle + "megabalíček" s kernelem, launcherem,... v dobře otestované sestavě.
-
ja. (neregistrovaný)
:facepalm:
Co tak najprv si to vyskusat, pozistovat ako to funguje a az potom si zacat domyslat?
Napriklad ked budete aktualizovat system, bude sa stahovat iba delta, podobne ako pri git pull. Runtime bude niekolko, nie mnoho, a urcite ich nebudete mat viac ako aplikacii, v uplne najhorsom pripade, pokial kazda aplikacia bude pouzivat iny runtime bude mat kazda aplikacia svoj. Pokial niekolko runtime obsahuje rovnake subory (napriklad glibc), tak na disku budu ulozene iba raz. Atd, atd.
-
j (neregistrovaný)
A co takhle nezvanit? Pokud mam v systemu jednu knihovnu, stahuje se update na ni JEDNOU, kdyz ji budu mit ve 30 verzich, tak se (pokud by se stal naprostej zazrak) bude stahovat 30x. Ve skutenosti se nic stahovat nebude, protoze pokud tvurce neni schopnej drzet aplikaci kompatabilni s aktualni verzi, tak zcela jiste nebude knihovny udrzovat vubec. Tudiz bude naprosto vsechno deravy jak reseto a neaktualizovany, stejne jako ve widlich.
-
Petr M (neregistrovaný)
Proč? Popíšu princip, jak to může fungovat (netuším, jestli to tak doopravdy funguje, ještě nebyl čas to zkoumat)
Při instalaci se zapíše do nějaké DB, co ta aplikace chce. Třeba knihovnu ABC verze XY. Instalátor zjistí, že ji má a neřeší, nebo že ji nemá a stáhne si ji.
Když spustíš aplikaci, tak dostane proměnné prostředí (ENV). Tam vidí třeba home dir, jméno uživatele a kde hledat knihovny. No a teď si představ, že chceš natahovat ABC_XY.so. Tak "něco" vytvoří podle té databáze třeba adresář /temp/env_appka, do něho symlink na ABC_XY.so ze skladiště a do ENV pro appku strčí místo odkazu na knihovny v systému odkaz na /tmp/env_appka, kde se hledají závislosti.
Pokud stejnou knihovnu potřebuje někdo další, zase se udělá /temp/env_jinaapka/ a do něj link na stejnou kopii ABC_XY.so a hotovo. Fyzicky je soubor v systému jednou...
A když třetí appka potřebuje novější verzi ABC_XZ.so, udělá se symlink v /temp/env_novaapka na nový soubor.
-
ja. (neregistrovaný)
Backend pre storage flatpakovych aplikacii sa nazyva OSTree. Je velmi podobny git repository v tom, ze kazdy subor je v content-addresable storage (t.j. subor je nazvany svojim hashom). Na rozdiel od gitu, a) checkout nie je kopia, ale hardlink do c-a storage a b) je mozne mat vycheckovanych niekolko rozlicnych branches naraz (v rozlicnych adresaroch, samozrejme).
Kazda aplikacia je samostany branch. Kazdy runtime je tiez samostatny branch. Kazdy major release, ktory moze menit ABI, je tiez samostatny branch (major verzia je sucastou nazvu, t.j. org.gnome.Platform/3.28 je iny branch ako org.gnome.Platform/3.30). Instalacia spociva v tom, ze sa z prislusneho remote (ten isty koncept ako pri git) potiahnu vsetky objekty, ktore su pre dany branch potrebne a vycheckuju sa do adresara. Pokial nejaka ina aplikacia alebo runtime pouziva ten isty objekt ako nejaka existujuca aplikacia alebo framework, tak sa logicky stahovat nemusi, pretoze uz v repository je. Pokial je nejaka aplikacia updatuje, tak sa urobi ekvivalent git pull a novy checkout; stary a novy mozu byt paralelne, ked sa stary prestane pouzivat, tak sa odstrani, dalsi start je uz do noveho. Je mozne urobit ekivalent autoremove, a z repozitory odstranit vsetky branche, ktore nie su uz potrebne (frameworky, ktore uz ziadna aplikacia nepouziva).
Pri instalacii sa ziadne dependency nikam nezapisuju; kazdy balicek ma manifest. Aplikacia moze pouzivat najviac jeden framework; nie je vsak problem vytvorit novy framework, ktory "zdedi" subory existujuceho (GNOME aj KDE frameworky dedia subory z org.freedesktop.Platform, ktory je barebone) a tym padom su stale na disku iba raz, aj mmapovane do procesov iba raz. Pri starte aplikacie sa vytvori tmpfs root, do ktoreho sa mountne checkout aplikacie do /app a checkout frameworku, ktory pouziva, do /usr. Ak ma aplikacia pravo vidiet home adresar, bind mountne sa aj ten, ak ma pravo vidiet dalsie mountpointy, bind mountnu sa aj tie. Teoreticky moze vidiet aj host root, ale nie ako svoj root, ale vo /var/run/host. Nikdy sa nepouzije host rootfs ako rootfs pre aplikaciu.
V takomto virtualnom filesysteme dostane kazda aplikacia presne to ABI, ktore vo svojom manifeste deklaruje ako potrebne, ale pritom stale je kazdy subor ukladany iba raz a do pamate mapovany iba raz, aj ked ich pouzivaju rozlicne frameworky a aplikacie.
-
Karel (neregistrovaný)
Smysl je oddělit OS od aplikací. Pak můžete mít aktuální jak OS, tak aplikaci.
Ve stavu, kdy jsou spojené, totiž běžně dochází k tomu, že nemáte na výběr. Respektive že ten výběr něco stojí - například máte kvůli starší verzi aplikace v systému i starou verzi nějaké knihovny. V takové situaci řada lidí ocení možnost, kterou vám tyhle balíčkovače dají - mít systém zcela aktuální a jen s nejnovějšími verzemi knihoven. A pro tu jednu jedinou aplikaci mít přibalenou starší verzi knihovny. Přidejte k tomu ještě benefit v tom, že takový balíček můžete odsunout do kontejneru, ze kterého vám ani stará verze knihovny nedokáže ublížit, a máte rázem velmi lákavé řešení.
Zabugované to bezesporu bude, ale právě že ne na úrovni systému. Ten bude vždy dle vaší volby, ale záplatovaný. Žádný hybrid, ale čistý OS. Zabugované budou až ty aplikace - což není dáno tím balením, ale tím, že nová verze prostě ještě není, případně ji nemáte k dispozici nebo vám v nové verzi něco nefunguje/nevyhovuje, takže musíte/chcete zůstat u staré. Tím, že je to zabalené, vám to už ale nebrání v updatu OS.
-
Oriwen (neregistrovaný)
Díky za odpověď, co jsem tady četl tak zrovna sandbox zatím buď nefunguje nebo funguje naopak tak dobře že rozbíjí například vzhled.
Je v těchto systémech zavedený systém řešení závislostí ve stylu "use system library unless stated otherwise"? Protože například mít Qt pro každou aplikaci tak mi za chvíli 128GB na systém stačit nebude.Pro používání v řádu jednotek specifických aplikací nic nemám, považuji to naopak za přínos. Stupidní mi přijde (zatím snad jen) teoretická snaha to zavést jako standard.
-
bmann (neregistrovaný)
Jenže k čemu mi je aktuální OS, když mám na tom děravé aplikace ve snapu/flatpaku a podobně? Ve výsledku celkem k ničemu.
Chápu, že se nějaký takový systém hodí vývojářům, pro testování a podobně.Když si platím např. RHEL s podporou tak očekávám, že mám aktuální OS se všemi knihovnami a že aplikace, které nainstaluji, tak tyto knihovny používají.
Takže od RHEL očekávám záplatovaný OS a od výrobce SW aktuální aplikaci pro daný OS.
Když mi někdo nabourá aplikaci ve snapu kvůli staré knihovně a vycucne z ní soukromá data, tak asi akorát můžu říct, že aspoň ten OS je aktuální.
A čeho se bojím, že tento systém jakkoliv vhodný pro některé věci zvrhne do strašného bordelu.
-
To se nutně nevylučuje. V RHELu nepovolujeme zdroj softwaru, který nemáme pod kontrolou, takže něco jako povolený Flathub tam asi nikdy nebude. Nicméně i tam se můžou třeba flatpaky hodit. Ty můžou být sestavované z balíčků dané distribuce, takže člověk dostane stejné záruky záplatování jako u balíčků. A může to usnadnit práci jak tvůrci distribuce, tak uživateli. Rozchodit aktuální Firefox v RHELu 6 představuje fakt hodně práce. Mít možnost tam poskytovat Firefox ve flatpaku postaveném na novějším RHELu by to výrazně usnadnilo (těm, kteří se bojí bundlů, doporučuji se podívat na balíček Firefoxu v CentOSu 6, to je jeden obrovský bundle, protože ze závislostí aktuálního Firefoxu v distribuci už nevyhovuje prakticky nic). Naopak zákazníci by zase ocenili, kdyby jejich aplikace, které se těžce portují z jedné verze RHELu na druhou, mohli provozovat v něčem, co jim umožní je pouštět na starší verzi RHELu. Některým trvá přeportovat všechny jejich podnikové aplikace roky, dnes jim na tom stojí přechod jejich desktopů na novější RHEL a pak zápasí s věcmi jako podpora nejnovějšího hardwaru.
-
bmann (neregistrovaný)
Díky za info z pozice RHELu. Pokud to bude takto v RHEL pod kontrolou, tak to je ta lepší varianta. Ale i tak to bude výzva uhlídat ty flatpaky pokud tam budou třeba balíčky z různých verzí a s různou délkou podpory.
Na druhou stranu linux není jenom RHLE a moje obavy jsou co třetí strany a jak toto ovlivní chování dodavatelů do budoucna. Teď mi přijde, že tu je aspoň nějaký tlak držet aktuálnost vůči dané verzi systému a využívat ho.
Ono to dělat blbě jde i teď (aka eObčanka), moje obavy jsou aby flatpak/snap nebyl něco jako signál, že to tak je správně.
-
volani.tk (neregistrovaný)
Jak to funguje u Androidu?
Když by byl systém na rozdíl od androidu aktualizovaný a obsahoval by třeba nějaké standardní knihovny, API a nástroje které by byly udržované a aktualizované a záplatované a vývoj by se dal předvídat (aby autoři SW mohli na nové verze připravit dopředu..)..A aplikace by mohli normálně fungovat a sdílet třeba některé knihovny nebo frameworky atd.. Když by byla potřebaná jiná verze, tak by se stáhla ta..
Ideálně aby si uživatel mohl vybrat konkrétní verzi aplikace nebo aktualizační kanál (stable, testing, beta, developer..)..
Tvůrci by dávali aplikace přímo do repozitáře (se kterým by uměli pracovat všechny distribuce a mohlo by se pro distribuci využívat i dobrovolně i P2P stahování) a aplikace by mohl kontrolovat kdokoliv. Zprávci distribucí by mohli kontrolovat kompatibilitu a ladit případné chyby..
Aplikace by mohli být volitelně sendboxované (zřejmě to má dopad na výkon, ať si uživatel může vybrat zda dá přednost bezpečnosti nebo HW zdrojům).
Takový repozitář by mohl být sdílený njapříč distribucemi nebo fungovat i na BSD..Není tohle co potřebujeme?
Je opravdu potřeba tak moc testovat konkrétní aplikaci se zbytkem systému? Nešlo by to oddělit co je součást systému a co jsou uživatelské aplikace?U "systému" by také mohli být nějaké uživatelské volby a možnosti (výběr distribuce, výběr aktualizačního kanálu..s tím že by pro uživatelské aplikace byly nějaké ty sady "balíčků" nebo sw které musí obsahovat aby to chodilo "třeba více variant s výběrem ale aby to obsahovalo vše potřebné).
SW je děravý, bugový a nedostatečně otestovaný a jen tak se to asi nezmění.. Jde o to, aby se opravy opravovali okamžite jakmile to bude možné a investovalo se do testování aplikací přímo v nějakém centárlním zdroji.
Ten centrální zdroj aplikací by mohl být přístupný i třeba přes GIT nebo další nástroje a mohlo by být v podmínkách něco aby byla snadná kontrola a revize kódu.. -
volani.tk (neregistrovaný)
https://www.cnews.cz/aktualizace-aplikaci-pro-android-budou-vyrazne-mensi-ale-zaberou-vice-casu/
Teoreticky by se mohli aktualizovat pouze změny, takže něco jako rsync..
