Názory k článku Flatpak, Snap, Modularity: počátek konce éry balíčkovacích systémů?
-
sid (neregistrovaný)
V com je pulse audio ine ako napr zfs, btrfs atd? Mozno by bolo fajn sa oprostit od autora a kritizovat skor napr navrh api atd. Linux uz davno nie je kiss a pochybujem ze pri sucasnej zlozitosti hw a sw by to vobec dobre fungovalo v zmysle toho, ze by vykon nebol o niekolko radov nizsie
-
Trident (neregistrovaný)
Navrh api necht si kritizuji programatori a to u tohoto relativne low level nastroje neni zas az tak podstatne vyjma stabilniho interface. API je spis dulezite u high level vyvoje a taky je zde nejvic cunat - cim vic high level tim vetsi cune posedle vrstvenim.
Mne jako systemaka zajima hlavne jeho stabilita,kompatibilita jak se chova konkretni implementace. Zda-li je to napriklad dostatecne pouzitelne v oboru a/v zpracovani,telekonference pripadne jen hloupy desktop na prehravani youtube videi Autor je dle implementaci jeho vyblitku mj. spatny designer a to je horsi nez spatny programator.
Problem je v tom ze ma validni argumenty pro to co je v linuxu spatne, ale implementuje to tim nejhorsim moznym zpusobem.
Nepletl bych si rozhodne ZFS a BTRFS dohromady. ZFS je tvrde otestovane ( a v sunu na otestovani ZFS byl brutalni lab a testy ktere by nikdy linuxova komunita neda dohromady ) jeste v dobe kdy za nejvetsi vykrik technologickeho uspechu byl v linuxu povazovan reiserfs. BTRFS stale neni dostatecne stabilni na kriticke veci a je taky znacne admin unfriendly.Pri soucasne slozitosti hw je o to vice dulezite mit ti dalsi vrstvy nad tim co nejjednodussi pripadne je eliminovat. Slozite veci bez toho aniz by k tomu byl opravdovy duvod navrhuje nemehlo a ne inzenyr. Jednoduchost je svym zpusobem umeni.
-
Trident (neregistrovaný)
ZFS je primarne slouceni vlastnosti volume manageru a filesystemu. Na to co ma delat a jak ma byt rozsiritelne celkem kiss splnuje. A zdaleka nebylo prvni pokud srovnam v te dobe jeho uvedeni komercne dostupne produkty. Je to reseni urcene primarne jako backend pro storage, druhotne jako FS pro slunickove systemy a ne k tomu aby si pepa z depa na tom z lokalniho ssd poustel ze sveho tabletu sbirku hentai videi.
Cele je to udelane tak aby se pokud mozno za behu dala menit konfigurace, delat deduplikaci,linkovani, overovani/migrovani struktur nebo upgradovat to cele taktez z behu. Umi si samo merit a delat statistiky rychlosti blokovych zarizeni a podle toho se zaridi. Je tam nejaky engineering koncept ktery mel resit rozsiritelnost. A ne jako pripade lennarta kterej ty svoje zazraky vzdycky prekopa, chce aby mu pomalu prekopali jadro a polovina veci na tom navesenych prestane fungovat.Nedokazu si predstavit jak pulseaudio nekde preklapim vcetne knihoven a streamu na tom bezicich za behu. Pokud by toto bylo treba tak pulseaudio rovnez nebude odpovidat tvemu kiss principu a bude o rady slozitejsi.
-
ava (neregistrovaný)
Ono to pravidlo může být i psané: https://semver.org/ . Sémantické verzování je např. povinné u všech Rustových balíčků a správa závislostí je díky tomu podstatně lepší.
-
Miloslav Ponkrác (neregistrovaný)
Takže každý Rusťák musí mít kvalitní křišťálovou kouli (to znamená ne žádné čínské výroby), aby odhadl také kompatibilitu budoucích verzí, které ještě kolem nevznikly. A uvedl to do balíčku.
Jestli ona ta konvence kompatibility podle major a minor verzí není mnohem lepší. A vzhledem k nedostatku špičkových křišťálových koulí také jediná prakticky možná. A jestli Rust se nesnaží tak trochu rozdojit kozla podle sovětského vzoru.
-
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..
-
singerko (neregistrovaný)
Presne o tom hovorim. Koncept zalozeny na tom, ze disk je neobmedzeny je chory. Ako developer musom vzdy brat do uvahy vsetky zdroje. Efektivitu kodu i miesto zabrate na disku. Co je to za uchylaka ktory ide robit balik co sa da spustit vsade a na tom este stavat cele distro? Naco je to dobre? Potom sa dostavame k aplikaciam ako posledny sokoban ktoreho som nasiel. Ma 250M a to mu este nesiel zvuk. Kde su casy, ked sa mi takych hier zmestilo na disketu 10?
-
Trident (neregistrovaný)
Typicky developer ktery v zivote poznal jen high-level programovani, tak ten misto na disku vubec neresi. Je to pro nej expandujici neomezeny etericky prostor, ktery proste je a udaje z df -kh je neco jako reliktni zareni. A kdyz je najednou full,tak jde prastit po hlave prislusne infrastrukturni oddeleni. Po te co projektakovi reknou ze to "fakt stoji penize" a nedostane ferrari, tak devel najednou zjisti ze zdroje jsou omezene a eskaluje svoji neschopnost...
Neberu v potaz junior embedaky kterym na zacatek u nas nedavaji PLC ale ty smart city linuxovy slataniny. I ti i na kdejakem nedulezitem smart pitku taky resi stovky kilo na knihovnach.Temto megabalikum co obsahuji prakticky dalsi kopie tech samych knihoven v systemu a to jeste na vice mistech po distribuci se zaclo rikat - "typicka enterprise s.....".
Protoze misto na disku je levne, devel to muze svest na systemaky a cas drahy. Je lepsi to tam naflakat v x kopiich jeste s jinou funkcionalitou a pro jistotu natahat knihovny i ktery zatim nepotrebuju nez resit ze system nema posledni knihovny. Vykaze se to jako "DONE", protoze US jsou "result oriented" a do "bean counters" kriterii ktere nezahrnuji security a udrzovatelnost jim to sedi. -
Přezdívka: * (neregistrovaný)
Nevim SNAP ani nic ostatni moc rad nemam. Nerikam ze by standardni balickovaci systemy nejakou tu aktualizaci nepotrebovali, take nerikam ze sandboxovani je spatne(prave naopak). Co se mi ale nelibi je, ze do ted s tim treba
gnome-system-monitornepocita, takze v zalozce s disky abych se podival kolik mam mista na disku je 150 kravin, ktere absolutne nepotrebuji videt(je to vubec k necemu dobre videt? vetsina ma 100% a ja nejak nevidim pridanou hodnotu). Navic, k linuxu jsem prechazel taky prave diky peknemu reseni zavislosti(jiste sem tam to drhne, to vime vsichni), jinymi slovy ze balicek si netahal vsechny nemysli s sebou. Takze diky temto nesmyslum jsme se dostali na uroven Windows kdy si kazde sebemensi aplikacka, ktera ma par kB taha MB knihoven, ze kterych mnohdy pouzije dve funkce.At uz je to SNAP ci flatpak, tohle se proste dalo vymyslet nejak lepe a i kdyby ne klidne bych to ozelel. Co je horsi ze Vam to treba ubunty cpou na kazdem rohu a vy si musite davat bacha aby to pouzilo klasicke APT resp. DPKG misto snapu. Ano, realne to tak moc samozrejme nehrotim, ale snad chapete myslenku.
-
To co píšete je zásadní problém. Používám debian, takže jsem nevěděl, že ubuntu cpe automaticky něco jiného než .deb. Jakmile si BFU zvyknou, tak tím způsobem začnou vydávat software všichni a to už asi rozmlátím počítač a vydám se poustevničit někam do Malajsie.
Teď mám jedinou aplikaci v appimage a neuvěřitelně mě štve, že musím minimálně každý měsíc otevřít firefox, najít github stránku, stáhnout nový appimage, přesunout ho do .složky, vlézt do properties a přidat tomu execute bit. Napsal bych si skript, ale nedovedu odhadnout jméno další verze. A možná by to nemusel dělat skript, ale mohl by být program, který to udělá pro všechny aplikace. A třeba by se mohl jmenovat dpkg. Ta dá...
A to ještě neřeším to, že v něčem zůstane knihovna openssl verze -1, protože to se autor učil ve škole tak proč používat něco novějšího.
Přiznávám, že s komerčním software jsou podobné problémy už teď a to jsou v .deb nebo binárkách, ale ulehčovat jim prasárny není ani logické ani morální.
-
Jestli to je morální nebo ne, s vámi nechci polemizovat, ale ta neschopnost aktualizace je čistě problém AppImage (přesněji té konkrétní aplikace, protože AppImage aktualizace umožňuje, ale musí si to pořešit autor aplikace), ne těch nových formátů obecně. Moduly ve Fedoře používají YUM repozitáře a lze je normálně aktualizovat přes DNF jako balíčky. Flatpak a snap primárně pracují nad repozitáři a co se týče aktualizací, tak fungují podobně jako balíčky. V určitých ohledech ještě jednodušeji, protože vzhledem k tomu, že je to bezpečné (nepřepisují při aktualizaci soubory, které běžící aplikace používá), mají by default zapnuté automatické aktualizace, takže jediné, co musí uživatel udělat, je onen software restartovat.
-
volani.tk (neregistrovaný)
A ty automatické aktualizace ve flatpaku jsou by default i v lubuntu? Mám pocit že kdžy jsme dal ruční aktualizaci tak se to zaktualizovalo a jinak ne.
Jak je to s AppImage? To je jeden sw= jeden soubor který obsahuje všechny knihovny? Jak probíhá tam aktualizace? Jaký příkaz? Jak často? Dá se na pozadí bez zásahu uživatele? Co když program už běží? Odkud to stahuje? Ověřuje se to přes klíče? Musí se věřit autorovi a může do systému natáhnout cokoliv?..Mě připadá že tvůrci SW nedodávají balíčky buď vůbec nebo včas.. Ale virtualizace mám obavu že hodně zpomalý běh applikací a spíš by bylo dobré aby se sw instaloval z ověřených zdrojů (tzn někdo kontroloval na malware a ověřovalo se jestli se do systému dostane co má..). Také by bylo fajn když by to sdílelo knihovny a části systému a mohli být v různých verzích když by zlobiliy.. Stáhování souborů a aktualizací pokud by byl problém s náklady na provoz serverů odkud se stahuje by se dal řesiit P2P stahováním..
-
TKL (neregistrovaný)
Přesně. Zásadní problém se jmenuje "Aktualizace". Spoléhat se na to, že autor balíku vydá novou verzi je chabá záruka. Ano, Snap a Flatpak má aspoň nějakou možnost aktualizací, ale to, že v aktualizovaném balíku přibalil autor i nejnovější verze knihoven, to nikdo nezaručí. K podobné situaci může dojít i u repozitářů, které nejsou distribuční, např. PPA v Ubuntu, nebo jakýkoliv repozitář třetí strany v jakékoliv distribuci. Že autor nepoužije statické linkování knihoven namísto dynamického, takovou záruku člověk nemá nikdy, proto by se taky měly jakékoliv zdroje třetích stran používat s velkou rozvahou a jen v nejnutnějších případech. O Appimage nemluvím, to je sice krásná idea, mít něco ala Apple, ale už jen tím "nastavte příznak pro spouštění" vyřazují ze hry běžného uživatele a pravověrný linuxák si něco takového 3x rozmyslí, už jen z vámi popsaného důvodu nutnosti hlídání nových verzí.
Roky profesně používám Windows, Mac OS i Linux, ale zatím nikdo nevymyslel nic lepšího, než klasické balíčkovací systémy. Což neznamená, že by se nedalo vymyslet něco dokonalejšího, jen by to chtělo spolupráci, místo znovuobjevování kola a vytváření toho, co už existuje: Snap, Flatpak, Appimage a teď Modularity... je v tom akorát - s prominutím - čím dál větší bordel.
-
Mahátmá (neregistrovaný)
A nakonec všichni vynalezou kolo a udělají to tak, jak to má macOS už 15 let - každá aplikace má svůj adresář se vším co potřebuje a hotovo. Zadně zasvinění /usr/lib,bin,sbin kde čím. Jediná věc co se potenciálně zasvinit může je ~/Library což je userspace a to zasvinění se rovná akorát tak úbytku místa na disku.
No a aplikace vyžadující nižší úroveň přístupu (drivery, VM) můžou využít systémový installer a předepsaný pkg formát (což je jen varianta opensourcoveho XAR, což je defacto MS Windows style instalátor). Opět všechno co potřebují musí mít přibaleno, spolehnout se můžou pouze na default systémové knihovny.
-
Tak nějak to mám i na Mintu 17. Některé programy stažené jako archív (např. prohlížeč Basilisk), jen rozbalím do složky a používám. Aplikace se aktualizuje sama (bez práv roota) mimo systémové aktualizace a k jejímu odstranění stačí jen smazat danou složku. Podobně např. asi i ḧra WarThunder... vytvořím složku, stáhnu launcher, ten si natahá co je potřeba a vše se odehraje s právy běžného uživatele. V podstatě to funguje jako PortabbleApps ve Windows.
-
to vubec neni pravda - presunutim aplikace do kose klidne zustanou dalsi soubory aplikace v \Preferences, \Application Support, \Library, \˜Library a dalsich adresarcich atd. , samo to nic neodinstalovava jen to presune *.app do kose, takze klidne zustanou i sluzby, demoni atd ...
proto se pouziva aspon AppCleaner
nejhorsi byva situace pri pokusu o odinstalovani neceho co se instalovalo pres instalator.pkg
je to dost podobne jako to byvalo na Classic Mac OS 9.x viz peklo s Extensions, Control Panels ..
zkratka OS na Macu nikdy neumel odinstalovavat
-
Alfonz (neregistrovaný)
Kecas. Pkg v pohode odinstalujes pres pkgutil a mnoho aplikaci nabizi i komfortnejsi uninstaller (ktery stejne spusti jen pkgutil). Co se tyce smeti po odhozeni app do kose, tak uz bylo psano ze jde o userspace, klidne to muzes smazat nebo se na to vysrat, nema to vplyv na system. AppCleaner a pod. zajima tak pouze lidi co maji 128G disk a 5 let nemeli cisty install systemu :-)
-
to by mne zajimalo jak odinstalovavas pres pkgutil, nejlepe podrobny navod (samozrejme uz puvodni installer.pkg nemas)
https://wincent.com/wiki/Uninstalling_packages_(.pkg_files)_on_Mac_OS_X
99% mac os aplikaci zadny uninstaller nema
-
Alfonz (neregistrovaný)
1. uninstaller maji zpravidla aplikace co se instaluji pres .pkg a ne kopirovanim do Applications (treba tady https://i.stack.imgur.com/O5vyT.png )
2. Ta linka je v pohode nechapu co nerozumis, pres pkgutil si vylistujes slozky a fajly a pres pipu mazes. Ti bystrejsi si udelaji shell nebo automator script. Pokud si pouze klikac, mas na githubu par utilitek co to udelaji za tebe. -
Alfonz (neregistrovaný)
To neni zadna sprava balicku ty stehno :-) To je navod na odinstalaci aplikace az dotycny nema po ruce originalni uninstaller. Ono mezi nama je tam skryta volba "pkguitl --unlink nazev.pkg" ale pred par lety to radeji z man stranky vyhodili aby to bfu nepouzivali a neco nepokazili :-)
-
ja. (neregistrovaný)
Skuste tak odinstalovat Virtualbox, MS Office alebo hocico od Adobe, ci vam to pojde bez toho, aby vam ostal v systeme bordel.
A to je presne ten problem: v macOS neexistuje moznost cisto odinstalovat aplikaciu, ktora ma svoj instalator (a to je 50:50, instalator vs app bundle). Treba dufat, ze po sebe zabechala aspon lsbom info a je mozne vycistit ju rucne.
-
Alfonz (neregistrovaný)
Ja spravuji cca 50 macu a 90% uzivatelu jsou BFU kteri zadny .pkg nepotrebuji a ziji z AppStoru nebo klasickych .app . Ale s Adobe Suite ci MS Office mas recht, tam je to spatny a je treba nekdy rucne smeti poresit. To ale stezi muzes dat za vinu macOS, proste je to instalator co chce roota a delat to nejak inak.
-
makta (neregistrovaný)
myslíš tím adobe třeba photoshop, co nejde nainstalovat na case-sensitive filesystem a když googlíš, zjistíš, že jim to cca 7 let zpátky něco rozbilo a než aby to opravili, udělali podmínku v instalátoru? na adobe i m$ produktech je vidět, že to nejsou věci dělaný primárně pro mac.
-
neregistrovany (neregistrovaný)
Tak prave tato "ficura" je zdedena z Macu. Povodny OS Classic case-sensitive fs nevedel, tak sa vtedy s niecim takym v Adobe ani Microsofte netrapili a odvtedy sa to v ich produktoch vlecie.
Tieto dve firmy nie su ziadnou vynimkou, viacero produktov s historiou siahajucou do OS Classic ma presne ten isty problem.
-
Trident (neregistrovaný)
Rika se tomu programatorsky lempl. To ze to vrstvy pod tim neumoznuji neznamena ze nedojde k pruseru v budoucnosti. BTW treba u tech vidli je to slozitejsi o to ze s nastupem NTFS prisel system ktery uvnitr je case sensitive, a da se tak z widli i pouzivat, ale pres standartni volani OS budi dojem ze je case insensitive.
Podobny programatorsky lempl byl kdyz programatori na prvnich PC misto timeru (ktery byl uz u prvnich PC) pouzivali smycku na casovani v softwaru. Dopadlo to tak ze 'Turbo' button aby tydle blbe napsane appky fungovaly. Protoze takhle to develove delali predtim vzdycky a vlastne nikdy zadne rychlejsi pecko nebude ze, tak proc se s tim babrat. -
Pokud SW počítá s tím že cesty na FS nejsou case sensitive, a běží na OS který je case sensitive nemá, tak nevidím problém. Horší je pokud SW například neumí fungovat s názvy adresářů/souborů obsahujícími mezery, i pokud to FS umožňuje. A to byl dlouhá léta problém třeba pro Oracle. Mám za to, že teď už se konečně dají binárky Oraclu nainstalovat do Program Files, ale tím to bohužel končí. A to zdaleka není jediná unixová aplikace, která má tenhle problém :/
-
Jestli si myslíte že v MacOSu odinstalujete aplikaci přesunem do koše, tak to se šeredně mýlíte. Takhle to funguje možná pro 60% aplikací, u zbytku instalátory rozkopírovávají bordel všude možně a vždy tam zůstane konfigurace a dočasné soubory. Realita odinstalace takových programů = neskutečné peklo.
MacOS používám jen na facebook, je to neskutečný co z pěkného UNIXu Apple udělal za srágoru. A ten filesystém to byl opravdu "klenot", tak díkybohu že alespoň to opravili (se zhruba desetiletým zpožděním).
-
Petr Neni (neregistrovaný)
Prosim alespon o 3 popularni aplikace co si kopiruje bordel nekam vsude po disku... Pokud nepocitam Symantec s jejich mrdkovirem, tak jsem se potkal jeste s 1 aplikaci co nesla odstranit smazanim do kose. Konfigurace zustava stejne jako kdyz v linuxe pouziju ssh a zustane mi tam authorized hosts file, docasne soubory - treba ruzne pomocne indexy, cache a podobne veci - zalezi od aplikace. Pouzivam nejaky odinstalator, pretahnu aplikaci do kose a tenhle bordel vcetne ruznych logu mi nabidne ke smazani.
-
FE (neregistrovaný)
macOS má hlavně výhodu v tom, že přesně víte co jaká verze macOS obsahuje za systémové knihovny a odladit to na ty ~4 podorované verze macOS je jednoduché, vše ostatní může mít aplikace v sobě.
U linuxocých aplikací se můžete spolehnout tak maximálně na stadndardní C/C++ knihovny. -
fe (neregistrovaný)
>Rozdíl mezi přítomností jediné verze dané knihovny či pěti jejích verzí na drahém SSD je obvykle rozdílem v řádku stovkách kB či maximálně desítkách MB.
Dovolím si nesouhlasit např. v případě Electron-based aplikací se skutečně neuvěřitelně mrhá místem, v tomhle případě se skutečně bavíme o jednotkách stovek MB/aplikaci, které zabere Electron.
MS je zdárným příkladem –> cokoli nového od MS (Skype, VScode, Teams) je Electron-based. -
Podotýkám že se to sice tváří jako instalace DirectX, ale jde o instalaci DirectX redistributable. Těch pro každou verzi DirectX může být více, a ten "DirectX Setup" prostě zajistí, že daná verze v případě potřeby nainstaluje.
https://support.steampowered.com/kb_article.php?ref=9974-PAXN-6252 -
j (neregistrovaný)
Tvurci se stim parou proto, ze widle a jejich komponenty sou tak uzasne kompatabilni, ze musis mit od kazdy 30+ ruznych verzi. A presne proto se ti spousti i ta instalacka dx, protoze widle nevedi a tvurce netusi, jestli tam je presne ta verze kterou pouziva.
Zrovna na to koukam, jen d3dx ruznych verzi mam 36 kusu.
-
MarSik (neregistrovaný)
Nejsem si úplně jistý jestli ten článek je psaný vhodnou formou.. je tam tolik nepřesností a osobních výpadů, že ten zbytek se v tom docela ztrácí.
- PulseAudio nebyla první audio mezivrstva. Bylo/je jich několik. Jack se stále používá. A pamatujete ještě esound? (OSS bylo z hlediska míchání zvuku peklo, Alsa s vhodnou zvukovkou menší, ale neuměla třeba nezávislou hlasitost a propojení aplikací).
- Uživatelé a hlavně vývojáři na desktopu chtějí více verzí jedné aplikace celkem běžně, protože občas musí vyvíjet a podporovat i starší větve. Nebo třeba chtějí pracovat s nejnovější verzí bez toho, aby si rozbili systém stabilních knihoven. Někteří si také občas chtějí instalovat aplikace i bez pomoci správce systému (což není vždy ten uživatel).
- Zákazníci také chtějí více různých verzí na serveru pořád (typicky LAMP stack, nikdo totiž nebude přepisovat interní webové aplikace pro nové verze). To byl třeba důvod pro vznik Software collections. Nebo důvod současné obliby kontejnerů a Dockeru.
- A nakonec nezávislí výrobci software (i komerčního) nechtějí zkoumat a podporovat všechny možné kombinace distribucí a svých verzí. Proto kdysi vznikl LSB (Linux standard base), a proto třeba Flatpak umí záviset na konkrétním verzovaném runtime.
Takže poptávka po ne-RPM způsobu distribuce je velká. Základ systému ale pořád balíčky používá, stejně jako build skripty pro spoustu těch modulárních systémů.
-
Dramon (neregistrovaný)
+1
Celý článek a většina diskuze mi připadá jako bouře ve sklenici vody. Že existence F+S+M znamená konec RPM/DEB je takový z prstu vycucaný názor. Zatím to vypadá na koexistenci vedle sebe.Vážně zmíněná otázka zní:
Je opravdu tak špatné, pokud budu mít nějakou aplikaci se zastaralou knihovnou, pokud je alternativou to, že nebudu mít aplikaci vůbec?Upravit Flatpack tak, aby aplikace byla sandboxovaná, bez ohledu na to co nastavil její vydavatel, mi přijde jako řešitelné a třeba se to časem implementuje. Pak by zneužití jedné aplikace mělo minimální dosah.
-
Doted jsem mel v Mintu DEB balicky. Neco ze zdroju distribuce, obcas mela aplikace vlastni repozitar.
Neni to na 100% skvely system, ale funguje.Nyni budu mit krome DEB balicku jeste Flatpak, Snap, Modularity, AppImage. Za par dni mozna pribyde neco dalsiho.
Takze kazdy s techo systemu si bude sam resit aktualizace a vsechno kolem toho. Jako na windows, kde mi ve spravci uloh trvale bezi firefox/chrome/adobe/... updater.
Nejsem uplnym zastancem systemd, ale alespon prinesl sjednoceni, takze ve vysledku jde o pozitivni zmenu oproti starym init skriptum.
Proc ale potrebujeme flatpak/snap/...? Nestacil by jeden? Prdpokladam, ze tvurce aplikace si vybere jeden a ja, jako uzivatel budu mit 10 techto systemu.
Proc by taky tvurce aplikace tvoril "balicek" pro 10 techto systemu? To uz by vyslo nastejne, kdyby udelal nyni deb/rpm pro 10 nejpouzivanejsich distribuci.
A i do toho deb balicku mohl zabalit binarni knihovny a celou aplikaci mit treba v /opt.Nejvetsi vyhodu vidim v sandboxu, ale tim to pomalu konci :-(
-
ja. (neregistrovaný)
Problem s Cannonicalom je ten, ze
1) tvori technologie preto, aby ich "vlastnil". Mir vznikol kvoli ocakavaniu konzultacneho biznisu pre Cannonical s vyrobcami zariadeni. Snap ma centralizovany store, aby zabetonoval Cannonical ako prostrednika.
2) pouzivaju pristup, ze treba nieco rychlo vytvorit, je to sice nedomyslene, ale cakaju, ze ako prvi obsadia trh a vsetko sa casom nejako vyriesi. Vid napr. riesenie dependencies v upstart, alebo izolacia v Snap.
Kombinacia tychto dvoch faktorov sposobuje, ze nakoniec ich riesenie je slepa ulicka, ktora iba fragmentuje prostredie a pribrzduje jeho rozvoj.
-
Podotýkám že ty updatery některých SW ve Windows jsou zavedené po přihlášení uživatele, ale není to nijak náročné na zdroje. Samotný executable je jen memory-mapped file, a navíc naprostou většinu času jen čeká na timer. Takže když je tam RAM potřeba, tak jí prostě použije jiná aplikace. Teprve když pingne timer, tak se těch pár stránek paměti může dotáhnout z původní binárky, případně ze swapu.
Windows ale mají vestavěný Task Scheduler. Někteří výrobci ho používají, a jiní z nějakého důvodu ne. Asi jde buď o setrvačnost, nebo se snažili o kompatibilitu s Windows XP, které měly jen starší verzi API (která neuměla například spustit task při přihlášení, po zápisu správného eventu do event logu apod.).
-
No me se to nastesti netyka, Debian GNU/Linux urcite dpkg nezahodi a myslim ze ani Fedora nezahodi rpm. Verim tomu, ze ve vetsine dister - pokud se to vyznameji uchyti - tak maximalne jen jako doplnkova metoda zpravy software, k tem tradicnim.
[To Redakce]
Davide, prosim te, neslo by k takovym clankum psat upozorneni, ze se jedna o spekulativni clanek? Jako, ten nadpius i perex me docela zmatl a mel jsem to za hotovou vec. Bylo by fakt fajn, aby vase clanky neuvadeli vase ctenare hned na zacatku v omyl. Diky -
kuba77 (neregistrovaný)
Ale může se stát, že pro některé programy nikdo nevytvoří deb/rpm, u Archu se třeba sníží počet programů v AURu... už teď je to vidět třeba na gnome-podcasts, který je v AURu ve dvou verzích a ani jedna není funkční, takže jsem musel ten program nainstalovat přes Flatpak a se vším okolo Flatpaku to má přes 1 GB :-(
-
rws (neregistrovaný)
Je ta Fedora Modularity neco jako sloty v Gentoo? Kdo nezna, proste je kazdy program zavisly na knihovne, v pripade potreby na konkretni verzi, tak gentoo maintaineri udelaji pro ruzne verze jedne knihovny ruzne sloty a ty ruzne verze jedne knihovny pak muzou byt nainstalovane najednou. Snap, Flatpack a podobne se mi nelibi, protoze tvurce programu/baliku musi hlidat vsechny pouzite knihovny a pri nalezene chybe ihned udelat update, coz muze byt v zavislosti na poctu pouzitych knihoven a jejich deravosti relativne casto. A pokud je tvurce lenoch nebo nema proste cas, tak novy flatpack nebo snap neudela a program zustane deravy. Vyhodu se sdilenymi knihovnami vidim v tom, ze staci zaktualizovat jednu knihovnu a vsechny programy jsou vyresene.
-
petr_p (neregistrovaný)
Modularita není jako sloty v Gentoo. Ve spod jsou pořád RPM balíky instalované DNF, které neumí nainstalovat více verzí téhož balíku (kromě zadrátované výjimky pro kernel), tudíž žádná paralelní instalace se nekoná.
Smyslem modularity je nabídnout náhradní verze balíků. Některé jsou kompatibilní se zbytkem distribuce, některé ne. Rozdíl oproti softwarovým kolekcím je, že moduly instalují soubory do standardních cest. Moduly mají uplatnění tam, kde někdo potřebuje konkrétní verzi kvůli jedné aplikaci a je ochoten obětovat nedostupnost jiných aplikací. (Ve vší obecnosti. Teoreticky lze jiné aplikace přebalit do modulu, který se přeloží proti všem existujícím verzím, ale to málokdo dělá, protože je to pracné a obecně to vede k explozi kombinací závislostí.)
-
Článek o ničem, TL;DR:
- vyvolání nesmyslné úvahy o "konci éry"
- autorovi nevoní Flatpack
- autorovi nevoní modularita
- Fedora je testovací distribuce (RHELu)
- autor by "vsadil" na Ubuntu/DebianuInformační hodnota blížící se nule, autor se neobtěžuje jít ani náznakem do hloubky. Ano, nic není dokonalé zejména když se zkouší nové věci, to beru, ale ať se autor pustí do nějaké zásadní kritiky, tohle je výstřel do prázdna aby byl nějaký obsah k diskusi.
K tématu snad jen že nové technologie jako je os-tree, Flatpack i modularita se skvěle doplňují s RPM i SCL a nikdy nebylo smyslem je nějak "nahradit", jak si to autor zřejmě vyložil a servíruje to tady na rootu ostatním. A závisloti přikompilované do aplikací se naopak snaží Fedora korektně řešit zejména díky exlozi softwaru psaného v Go. Naprosto pominutým faktem je, že tady 25 let doufáme v "Linux na desktopu" ale to nemůže nikdy přijít bez projektu typu Flatpack nebo podobnému. Je mi fuk jestli vyhraje Flatpack, Snap nebo něco úpně jiného, ale ať se to proboha skonsoliduje, základ systému je RPM/DEB/jiný a nad tím ať jsou aplikace v nějakém "storu" s možností svobodné volby, nějakým slušným skenerem na přibalené závislosti (kvůli security bugům). Holt pokud chceme aplikace sjednotit, nějaké ty závislosti se přidat holt musí. To je podle mého názoru cesta z kola ven.
-
pajac (neregistrovaný)
Jj, místo systémového řešení přes balíčkovací systém, kvůli neschopnosti, nedůslednosti a okrajovým případům se na něj kompletně rezignuje a základem bude bordel.
Argumentace typu "levná" kapacita zdrojů disky/síťový provoz/ram jak stehno, jen potvrzuje pochybnosti o příčetnosti.
Užijte si 10 verzí knihovny současně hnijící na disku i okupující paměť, z nichž jen jedna má záplatované známé bezpečnostní díry, protože na update snapu pro ostatní aplikace se zatím čeká..
-
mln (neregistrovaný)
Prečo by nemohli tie Flatpak balíky fungovat ako nejaký sekundárny failsafe spôsob šírenia sw pokial z nejakého dôvodu zlyhá šírenie sw cez repozitáre ?
Ja sa len čudujem že sa tie balíky objavili až teraz. Už celé roky to chýba - jednoduchý user fiendly sposob ako šíriť napríklad špecializovanejší a málo používaný linuxový sw bez toho aby človek bol rukojemníkom správcu repozitárov. Napríklad keď sa pred pár pohádali správca repa Debianu a Jorg Schiller = tvorca napalovacieho sw, vdaka čomu sa defaulne nedá napalovať BlueRays v Debiane bez toho aby to neskončilo chybou.
Napríklad tá idea nemať viac verzii jednej knižnice bola u mňa dochvíle ked som potreboval na Debian stable nainštalovat novšiu verziu ntfs3g (v defaultnej boli stále bugy), a skončilo to nakoniec nejakým hybridom Stable a Unstable systému. Fakt elegantné riešenie.
RPM, DEB a pod tiež implicitne predpokladá že počítač je pripojený k internetu.
Pred vyše 10 rokmi ked som nemal doma internet, tak stahovať sw pre linux bola fakt lotéria. Čisté dependency hell. Ked som zabudol na nejakú závislosť, tak som musel si znova spraviť výlet ísť do jednej internetovej kaviarne. Z toho dôvodu snažil som sa vyberať si distribúcie ktoré sa šírili na DVD. -
K> (neregistrovaný)
Ten clanek je doslova o nicem. Mam pocit ze jsem precetl uvod a najednou clanek skoncil.
Nejprv je popis balickovacich systemu.
Pak je oznameni ze autor uz nema problem s mistem.
Pak se autor zmini ze ve Fedore je nejaka idea Modularity.Ale nikde, vubec nikde neni zadna uvaha, proc by kontejnery mely vest ke konci balicku, coz je jaksi nadpis, takze jsem tu uvahu cekal. A nic.
Nejvetsi drzost je odkaz na popis systemu Modularity jako druhe slovo odstavce. Ctenari dostuduj si sam. Nejprv autor popisuje znamejsi systemy (balicky, kontejnery), ale novou vec nepopise?
Prosim sefredaktora, aby takovy odpad jiz nezverejnoval. Ano, nemusim to cist, jenze jaksi je problem zjistit ze to je odpad driv nez to prectu.
A receno bez obalu a politicke korektnosti: Jezku, bez do ....
-
Jakub Valenta (neregistrovaný)
Tyhle články a zprávičky co se tady v poslední době objevují jsou důvod, proč jsem zrušil "přeplatné" roota. Už to není odborný server o OSS, ale spíš IT bulvár o tématech, o kterých se dá flamovat. V článku se člověk dozví jen pár kontroverzních názorů a diskuze je hned plná komentářů o ničem. Tak snad se to aspoň finančně vyplatí.
ČLÁNKY DO MAILU
