Ne, neznám "to". Když chci do své distribuce nainstalovat "basic" aplikace, tak jsem právně strašně vděčný za balíčkovací systém, protože to zvládnu jedním příkazem - apt install vlc gajim libreoffice... Jo, může to pak nějakou dobu trvat, ale to už to nemusím celou dobu hlídat a po instalaci jedné věci přemýšlet, co jsem to ještě chtěl nainstalovat dalšího...
Tím se to dost liší třeba od jednoho nejmenovanného majoritního systému, kde bez využití nějakých speciálních nástrojů nemůžete ty instalace ani nějak zřetězit. Nainstalujete jednu věc, ta se instaluje třeba pár minut, když je to něco většího - a pak můžete teprve instalovat něco dalšího. Jinak Vás ten instalační program toho dalšího také může poslat do háje, že už přeci nějaká instalace běží... To samé při odinstalaci...
Trochu se obávám, že tyhle Flatpaky a Snapy nás jenom vrací zpět...
Ano, asi se hodí mít způsob instalovat některé věci, které nejsou v repozitářích - navíc je to asi fajn i pro ty, co ten software vyrábí, že s tím možná nemají tolik práce. Někdy se může hodit mít šanci od něčeho nainstalovat tu nejnovější verzi, protože než to "probublá" do repozitáře, může to trvat.
Ale jaký je třeba zrovna "usecase" pro to, instalovat si dvě verze VLC? To jsem nějak moc nepochopil.
Navíc bych měl k příspěvku (a teď nevím, jestli se to ještě může takhle do komentáře) i určité stylistické výhrady. Na to, že je to jen pár vět, si je mohl po sobě autor také přečíst a trošku je ještě "vyšperkovat". Co ta kostrbatá vazba "jako jedno z nejlehčích řešení je použít"? Proč ta čárka před "jako"? Dvě věty hned po sobě, které v podstatě začínají "Tento správce aplikací". Vůbec je v tom textu na malém prostoru nějak moc ukazovacích zájmen - tento, to, tato...
> Ale jaký je třeba zrovna "usecase" pro to, instalovat si dvě verze VLC?
A proč zrovna VLC? Zrovna klokan výše uvedl docela dobrý důvod třeba pro Blender, který pokud vím teď dost překopává uživatelské rozhraní. Sice ty změny budou nejspíš super, ale asi je lepší učit se nové věci až po dokončení aktuální práce, zvlášť když má deadline…
> Naprosto souhlasim az na vyjimku - kontejnerove
> instalatory nas nevraci zpet. Defacto virtualni
> masinu pro kazdou aplikaci! Jen si to predstavte.
> Linuxovy svet zase predbiha M$. Jen si nejsem
> jisty, jestli ve spravnem smeru... :(
Microsoft ve směru kontejnerů také postupuje. Myslím, že od verze 1809 by mělo být k dispozici API pro práci s kontejnery (a spouštění aplikací v nich) za pomoci Hyper-V, čehož zřejmě bude využívat Docker (ale podle dokumentace to má řadu omezení).
Osobně nejsem kontejnery implementovanými prostřednictvím virtualizace moc nadšený, protože je pak problém provozovat jiné virtualizační platformy.
Pak tu je Device Guard (izolace důležitých procesů prostřednictvím virtualizace), ale jelikož na jeho provozování nemám hardware, tak o něm víc nevím :-).
Jaká konkrétní negativa? Pro uživatele to přináší lepší ochranu proti nedůvěryhodnému software, pro vývojáře a baliče je to mnohem snazší, než muset cílit na N různých dister, každé v M různých verzích. No a to, že se všechno nenas*re do /usr ale každá aplikace se instaluje odděleně taky není na škodu.
Bezpecnostna chyba v libxyz predtym: maintainer libxyz aktualizuje balik este ked chyba nie je verejna, opravi sa tym aj 100 programov, co na libxyz zavisia.
Ta ista chyba so snapmi: zo 100 programov si na to 10 programov s komercnym pozadim da pozor, vyda aktualizaciu ked chyba nie je verejna. Dalsich 30 na tom zacne pracovat po zverejneni chyby. Dalej nastava vseobecna panika, clanky su aj v printovych mediach, 40 autorov programov narychlo prekompiluje snapy. 15 autorov chybu ignoruje, ale s novym vydanim to zhodou okolnosti opravi. A 5 autorov nema zaujem nieco aktualizovat, lebo program funguje. Tak bude navzdy zranitelny.
Skoro by som tvrdil, ze toto zoberie cast bezpecnosti a ziskame menej.
No, Snappy i Flatpak mají jakési runtimes, extensions apod. Co jsem pochopil, pokud se knihovny dostanou tudy, lze jej upgradovat nezávisle na aplikaci. Neznám to do všech detailů, pokud mi něco uniklo, budu rád, když mě někdo opravíte.
Ano, pokud autor knihovny přibundluje, musí je updatovat sám – to ale platí i všude jinde, včetně dpkg, rpm, Portage a dalších.
Lepsi ochranu? Uzivatele by se meli nejdriv naucit s pocitacem zachazet, Linux sam je bezpecny (nebo zabezpecitelny) az dost. Tohle je jen noseni drivi do lesa a jeste se za to musi platit (viz nize).
Ano, kontejnery smazavaji rozdily mezi distry, IMHO protoze jedou primo pod jadrem. Vsechno ostatni je potreba do nej dodat. Takze kazdy skript, ktery ma at nezeru 4k se ti ve vysledku v kontejneru nadherne nafoukne. On ten runtime neco zabere a to nemluve o rezii samotneho spravce (u me to byl docker). Jasne na moje trapne ctyri kontejnery je to nic. U 100 se to uz projevi. Na systemu mi momentalne bezi nejakych 115 procesu (podle htop), podle aptitude mam nainstalovanych pres 4 a pul tacu baliku. Jima me hruza z toho, ze kazdy by byl smostatny kontejner: <sarkasmus>"Hurra vyslo novy Ubuntu! Zahodily jsme dpkg, vykoply Apty a mame tu ted Chnapika! Vas pocitac bude s nim lespi nez kdy driv, protoze jen na zakladni instalaci potrebujet 4T na hadru, 12-ti jadrovy procak a 16G Ram. OMG!"</sarkasmus>
Samozrejme, muzes kontejnery propojit, tim usetris rezii. A stejne to budes muset udelat, aby mohly jednotlive aplikace smysluplne spolupracovat. Jenze tim podle me ztraci cela ta sranda smysl. Jako je "jednoduche" vytvorit kontejner pro vyvojare, je stejne jednoduche pro sikovneho crackera jej podvrhnout. A propojeni kontejneru, mu da to co potrebuje - falesny pocit uzivatele ze se nic nemuze stat, a jemu dost prostoru k radeni, do ktereho neni z venci videt.
A jeste k te jednoduchosti: Na nekolika mistech zrovna zde se nekteri vyjadrili jak je obtizne kontrolovat klasicke baliky (rpm, deb), ktere me osobne prijdou transparentnejsi. Jsem zvedav, jak se to bude darit s kontejnery. Uz ted se mi zda, ze by se v nich mohl pohodlne schovat slon a hnedtak si ho nevsimnes.
S tim "nas*anim" do /usr je to vec pohledu. Uprime ja jsem za tento system instalaci vdecny. Uz jenom proto, ze kdyz potrebuju najit data programu vim presne kam hrabnout. A pokud se to dodrzuje, tak je v podstate jedno jaka data a jakeho programu hledam. Byl bych vdecny za to, kdyby vsechny projekty a na vsech distrech sva data vzdycky rozdelovaly do slozek v /usr.
Samozrejme nemusis se mnou souhlasit, navic moje zkusenosti vychazeji z dockeru. Ale jak jsem psal, jako doplnkova metoda instalace, ci provozovani software to muze byt velmi uzitecne. Nasazeni v sirsim meritku, by podle me bylo spatna cesta.
Jen na okraj, jak vypada a co obnasi vezneni aplikaci je pekne videt na Androidu. Nerad bych se nekdy v Linuxu dostal do podobneho stavu.
Zmínil bych ještě jedno pozitivum. Když teoreticky všechny balíčky přesuneme tímto způsobem do Flatpaku nebo Snapu, zůstane nám neměnný a tím pádem snadno testovatelný systém, který se nerozbije jen proto, že jsme přidali repositář, který nahrazuje půlku původního systému. Nemusí to být ani půlka, stačí nějaká často používaná knihovna, kterou si jedna aplikace potřebovala aktualizovat.
Qubes OS nedělá separátní VM pro každou aplikaci (samozřejmě, lze jej takto použít), ale pro každý kontext:
* Prohlížení pochybných stránek a internetové bankovnictví – stejná aplikace, jiný kontext.
* IDE, konzole, grafický editor a prohlížeč – různé aplikace, stejný kontext.
> nedela virtualizaci ala qemu nad systemem, ale o uroven niz pres xen vedle systemu primo na zeleze...
Rozdíly mezi Xen a QEMU tu jsou, ale ten popis je spíše zavádějící. Xen běží nad Linuxovým kernelem. Zvlášť v QubesOS se na Xen lze dívat trochu i jako na mikrokernel. Linuxový kernel je pak framework…
Já ho používám, ale není (nemusí to být) to 1 VM / aplikace, vizte můj komentář výše: https://www.root.cz/zpravicky/spravce-aplikaci-snappy-umozni-instalaci-nekolika-verzi-stejne-aplikace/1024007/