Názory k článku
Snap přejde z komprese xz na lzo, aby balíčky rychleji startovaly

hmm preco nie zstd

Nemá kompresi? Ani pro přenos dat?
Na disku je otázka zda to nenechat na souborovém systému. Ale podpora transparentní komprese na Linuxu není moc podporovaná. Otázka je u copy on write filesystému jaké to má dopady na výkon.. zase se to hodí pro zálohy..

Fungují delta aktualizace?

Četl jsem že nejmenší jsou appimage.

Možná by stálo porovnání flatpaku, snapu a appimage a jaké GUI a obchody jsou. Jak fungují aktualizace a jaká je podpora v distribučních. Nebo proč mint zakázal snapy. A výhody nevýhody atd..

Přemýšlel jsem jestli Ubuntu do budoucna nebude chtít přejít kompletně na snap podobně jako to zvažuje Fedora s flatpaky..

Flatpak stahuje asi komprimované soubory, na disku je však rozbalí a už nejsou komprimované.

Snap používá SquashFS, který umí transparentní kompresi a je možné si ji zvolit.

Flatpak robí http(s) requesty buď pre každý súbor, alebo pre statické delty. Pokiaľ má server povolenú http kompresiu, tak sa použije. Pokiaľ nie, tak sa nepoužije.

U používateľa je flatpak repository normálny adresárový strom, nie image. Pokiaľ si používateľ zapne kompresiu pre daný adresár / subvolume (napr. `btrfs property set /var/lib/flatpak compression <zlib|lzo|zstd>`), bude to mať komprimované, ak nie, tak nebude.

TIL

To vysvetluje preco mi flatpak s jedinym balickom na chromebooku zabral vacsinu uloziska zatial co niekolko snap-ov sa tam v pohode voslo. Nijak som to blizsie neskumal a nenapadlo mi ze by to snap ukladal komprimovane. Ale teraz to dava zmysel.

Cim nechcem povedat ze by jedno alebo druhe riesenie bolo lepsie. Tu kompresiu si teoreticky mozem zapnut na urovni filesystemu.

Ono je to komplikovanejšie.

Flatpak (a aj snap) majú koncept runtime. Runtime je zbierka knižníc, v podstate mini-distribúcia, ktoré aplikácie môžu využívať a sú zdieľané medzi viacerými aplikáciami. Ak používate iba jednu aplikáciu, tak "fixný náklad" celého runtime je iba na túto aplikáciu, preto sa môže zdať veľká. Situácia sa mení, keď budete mať viacero aplikácií s tým istým runtime.

Třeba u zabraného místa na disku to srovnání bude dost záviset na způsobu použití. Pokud člověk používá jednu aplikaci v těchto formátech, bude mít nejmenší velikost asi AppImage. Jak jich ale bude používat víc, bude se výhoda přesouvat k těm ostatním. Flatpak používá sdílené runtimy a díky libostree má docela efektivní deduplikaci. Nic z toho AppImage nemá.

AppImage nie je distro-independent. Závisí na tom, čo do neho developer pribalí a čo nie, a chýbajúce dependencies musí poskytnúť host.

Ja se nemuzu pochlubit zadnymi merenimi, ale format LZMA pouzivam na self-executable archivy. Hodne casto takhle resim spousteni Dosovych her na Linuxu, nebo komplexnejsi instalacni baliky ( velmi casto obsahuji kompletni LO ). A s vysledky jsem vice nez spokojen.

Tak treba u tech dosovych her to beru od chvile, kdy spustim samotny archiv jako spustitelny soubor az po nabehnuti Dosboxu. Spousteci proces probiha tak, ze nejdriv se vytvori potrebna adresarova struktura, pak dojde k aktivaci/pripojeni OverlayFS, dekomprimace baliku a nasledne jsou jeste dekomprimovany uzivatelska data - jsou-li k dispozici. Pak je teprve dalsim, samostatnym, skriptem provedena priprava na spusteni dosboxu. Ve finale je spusten Dosbox s hrou. Prace jak na kostele, casto dvoji dekomprimace (oboje LZMA) a presto je to zhruba srovnatelne rychle jako spusteni nativni aplikace.

Takze si rikam, jestli problem Snapu, neni jinde a opravdu jej vyresi zmena komprimatoru.

30. 10. 2020, 20:41 editováno autorem komentáře

Nevím, jestli jsem to dostatečně pochopil, ale nemůže za tím být řádově menší velikost DOSovek?