Zypper rychlejší než yum

Duncan Mac-Vicar vydal článek, ve kterém provádí srovnání dvou verzí správce balíčku Yum z Fedory a jedné verze správce zypper z openSUSE. Článek srovnává jak výkon, tak paměťovou náročnost všech tří programů. Podle článku skončil nejhůře yum 3.2.14, druhý skončil yum 3.2.4 na prvním místě pak ZYpp 4.21.1, který byl ve všech testech několikrát rychlejší než yum.

14.5.2008 20:13 | Käyttäjä 11133 | Zajímavý článek

Komentáře

[belisarivs]

No ja nevim.

Da se yum pouzivat v SUSE nebo Zypper ve Fedore?

To srovnani upgradu jinak vypada divne.

A mereni casu, kdyz seceka na odpoved .. To se mi taky nepozdava.

[Käyttäjä 11133]

Minimálně yum v SUSE jde. Vždyť je to tak děláno i v tom článku, četl si ho vůbec? A nepředpokládám, že by se u autora nějak zásadně měnila rychlost stisknutí klávesy n, ale pokud si to chceš ověřit, nic ti nebrání použít yes no v pípě.

[saly]

Na pacmana to stejně nemá :)

[onion]

Ten se zase pro zmenu neobtezuje s resenim neceho tak podradneho jako downgrade balicku :)

[saly]

Ale, ja normalne z cache downgraduju baliky, kdyz neco nejde treba :)

[jas]

http://wiki.archlinux.org/index.php/Downgrade_packages

[Kyosuke]

Chm. Chm. Chmmmm! Dokud neuvidím sám, neuvěřím. Ale stejně bych tam rád viděl i apt a pacman , i když je mi jasné, že by to byla trošku umělotina - ani jeden nepoužívá RPM a musela by se simulovat podobná situace (obdobný počet balíků v repozitářích a tak).

pacman -S bude i tak v porovnání se zypperem pekelně rychlý, ale to bude asi tím, že se vývojáři ZYPPu odvážili při výpočtu závislostí řešit NP-úplné problémy... Ach jo, co oni neudělají pro to, aby zapůsobili na entrprajs managory...

A bude vůbec pořešený, jak bych si mohl ty "předkompilovaný" soubory, co si to bude stahovat ze serveru, generovat lokálně, kdybych si třeba dělal vlastní lokální repo? Nebo to bude privilegium jen pro oficiální zdroje? Ostatně mi přijde, že k celýmu ZYPPu je strašně málo dokumentace. (Hm, teď mi Michal navrhne, abych ji napsal. )

[Käyttäjä 11133]

nj, SAT solver :D jak řeší závislosti pacman? Dokumentace sice není moc, ale na #susecz @ Freenode najdeš AFAIK hned 2 vývojáře, co víc si přát?

[Quimby]

Me na zyyperu nejvic chybi neco jako apt-get clean. Protoze pri odinstalovani v systemu necha snad vsechny nepotrebne knihovny a to je dost nestastne. Hlavne pokud clovek s linuxem zacina a zkousi tedy vice programu.

[Kyosuke]

Mno já teda nevím, ale jestli tu manuálovou stránku apt-getu chápu správně, tak až do poslední trunkové verze zypp nic podobného nepotřeboval, a v nové verzi půjde cachování zapnout i vypnout a v případě zapnutí bude zypper clean dělat totéž, co apt-get clean...?

[Käyttäjä 11133]

apt-get clean odstraňuje nainstalované závislosti, které už nejsou nadále potřeba. Nainstaluješ program foo, který závisí (jako jediný) na libfoo. Nainstaluje se teda libfoo, po nějaké době se rozhodneš foo odstranit, ale libfoo ti zůstane, spusšít apt-get clean a odstraní se i libfoo.

[Kyosuke]

apt-get clean odstraňuje nainstalované závislosti, které už nejsou nadále potřeba.

Jenže manuálová stránka apt-getu mluví o něčem úplně jiném:

clean: clean clears out the local repository of retrieved package files.

O odinstalování sirotků tam není ani slovo. Sirotky AFAIK odinstalovává deborphan | xargs apt-get -y remove, ale otázka je, na základě jakých kritérií to vybírá. Pokud je mi známo, jen aptitude si pamatuje, co nanstalovala jako závislosti.

[David Jaša]

... Pokud je mi známo, jen aptitude si pamatuje, co nanstalovala jako závislosti.

Tuším, že právě proto je doporučovaná jako ten správný nástroj pro správu balíků. BTW už je v SUSE něco podobně silného jako ncurses xicht aptitude?

[Käyttäjä 11133]

Co tím ncurses xichtem myslíš? Celý YaST jde spustit v ncurses (AFAIK kromě SaXu).

[David Jaša]

A umí to stejný psí kusy jako TUI aptitude?

[Käyttäjä 11133]

Ale co to jsou ty psí kusy? Já ncurses TUI aptitude vždycky nenáviděl. Můžeš je tady popsat a já je pak nahážu vývojářům YaSTu do bugzilly. :D

[David Jaša]

1) rychlost. Po přežvýkání repozitářů po startu nebo updatu reaguje okamžitě

2) vynikající správa reverzních závislostí, možnost nastavit implicitní instalaci doporučovaných a navrhovaných závislostí (to druhé umí i apt)

3) ukazuje případné konflikty plánovaných změn a umožňuje ručně dopředu nastavit, které změny balíčků a verzí mají proběhnout a umožňuje nastavit víc věcí naráz. Tím pádem lze vyřešit problémy v závislostech a verzích balíčků předtím, než vůbec nastanou. Ve stable verzích se to omezuje na use-case jako bylo donedávna prohození backendů v totemu (ty se navzájem vylučovaly), ale ve vývojových větvích nebo při velkých upgradech to má svoje kouzlo - například mezi upgradem knihovny a na ní závisejících balíčků nebo při velkých změnách v rozložení balíčků, kdy je potřeba provést víc akcí a při rozložení do jednotlivých příkazů (remove, upgrade, install) by se člověk jednak upsal a druhak by byly balíčky mezi jednotlivými akcemi v nekonzistentním stavu

4) hledání podle regexpů

5) výpis dostupných verzí a dopředných i zpětných závislostí s odkazy v podrobnostech (a značením červenou pokud je někde nepravost). Obzvlášť užitečné ve spojení s (3) nebo při čištění systému.

BTW zadals někam relevatní připomínky z těch, co jsem ti posílal na podzim?

[Kyosuke]

Já si z aptitude nejvíc pamatuju to, že jsem chtěl odebrat jeden balík a ono to chtělo odinstalovat půlku balíků včetně kernelu. Ale to už je pár let zpátky, a možná jsem jen dělal něco špatně, připadalo mi to skoro jako Vim. Ohledně 2): kuk sem. Jako fíčura ZYPPu to fungujei v YaSTu. Je ale nutno přiznat, že i když YaST tyhle věci povětšinou umí taky, má jeho TUI verze trošku větší nároky na screen-estate a taky to klávesový ovládání by taky mohlo být trošku líp řešený...

[Jakub Lucký]

Co dselect?

[MarSik]

Na odstraneni zavislosti, ktere uz nejsou potreba, slouzi apt-get autoremove

[vlastagf]

to by se sakra hodilo, takhle aby clovek porad prolezal logy.

[pushkin]

A bude vůbec pořešený, jak bych si mohl ty "předkompilovaný" soubory, co si to bude stahovat ze serveru, generovat lokálně, kdybych si třeba dělal vlastní lokální repo?

Vlastní lokální repozitář jde udělat už hodně dlouho pomocí utility createrepo. Osobně takhle mám vytvořenou "druhou vrstvu" k médiím openSUSE 10.3 (chybějící balíky, co nejsou ve stažitelném GM ISO), mám takhle zkombinovaných několik repozitářů s Packmanem na DVD (obojí ve stavu k vydání distribuce, bohužel nemám dostatečně kvalitní připojení pro používání internetových repozitářů) a pro jistotu tak instaluji SUNovské OpenOffice.

[Kyosuke]

Ale co ty soubory pro solver? To mi nějak ušlo. Budu se muset zítra zeptat na místě.

[Käyttäjä 11133]

Nebo na IRC (#susecz @ Freenode), kde si už dlouho nebyl

[Ladicek]

se vývojáři ZYPPu odvážili při výpočtu závislostí řešit NP-úplné problémy

To mi chvilkama vrtá hlavou od chvíle, kdy jsem na to narazil tuším v Distribučních novinkách. Jaké NP-úplné problémy se vlastně při správě závislostí řeší? Čekal bych, že celá problematika vede na nějaká ta hledání cest v grafu apod., ale zřejmě to je o něco složitější.

Btw pousmál jsem se nad tím, že se takové problémy i v praxi řeší redukcí na SAT, měl jsem za to, že tohle je ryze teoretická technika

[MarSik]

SAT a ryze teoreticka? Ani ne. Aneb v Debianu o tom taky vedi (a docela dlouho)... http://people.debian.org/~dburrows/model.pdf

Jinak ciste nainstalovat jeden balik se zavislostmi je jednoduche. Jenze jak do hry vstoupi konflikty a upgrady verzi, tak to zacina byt fakt sranda (a to nemluvim o zavislostech na souboru jako ma rpm).

[Ladicek]

SAT a ryze teoreticka? Ani ne.

Já se spíš divil tomu, že opravdu někdo programově redukuje problém na SAT (pochybuju, že v balíčkovacím systému vyvstává problém splnitelnosti logických formulí ). Ale pak jsem pohledal a těch SAT solverů je strašná spousta, takže to asi vážně lidi dělají

[Ladicek]

pochybuju, že v balíčkovacím systému vyvstává problém splnitelnosti logických formulí

Teď jsem nad tím ještě chvilku přemýšlel, a říkám si, že různé "zaměnitelné" závislosti (stačí jedna z několika) nebo volitelné závislosti by možná šly reprezentovat logickou formulí docela dobře. Asi bych si o tom měl něco přečíst.

[Michal Vyskočil]

Teď jsem nad tím ještě chvilku přemýšlel, a říkám si, že různé "zaměnitelné" závislosti (stačí jedna z několika) nebo volitelné závislosti by možná šly reprezentovat logickou formulí docela dobře. Asi bych si o tom měl něco přečíst.

V tom případě doporučuji třeba Package Management/Sat Solver/Basics, anebo se podívat na odkazovanou prezentaci na FOSDEMu.

[Ladicek]

doporučuji třeba Package Management/Sat Solver/Basics

Díky! Řekl bych, že už je mi to trochu jasnější

[Vin]

Ale stejně bych tam rád viděl i apt...
...ani jeden nepoužívá RPM

Kecy. Co myslíš, že se používá na PCLinuxOSu, který je RPM-distro? Je poněkud "pomalejší", než jeho deb-verze.

[Michal Vyskočil]

pacman -S bude i tak v porovnání se zypperem pekelně rychlý, ale to bude asi tím, že se vývojáři ZYPPu odvážili při výpočtu závislostí řešit NP-úplné problémy... Ach jo, co oni neudělají pro to, aby zapůsobili na entrprajs managory...

To že je problém NP úplný neznamená, že se nedá v praxi rychle řešit. Hezký článek o tom byl v knize Umělá inteligence 5 - Fázové přechody, obchodní cestující a empirický výzkum algoritmů.

To už je i NP-complete buzzword?

BTW: time install nautilus na stroji s Factory a Packmanem trval cca 3 vteřiny (myslím tím načtení cache a vyřešení závislostí, ne samotná instalace).

[rincewind]

"Tato APT má schopnosti svaté krávy." :) Nic ve zlem, ale me vsechno co si hraje s rpm balicky prijde pomale - osobni nazor.

[Ilfirin]

Přijde čas, kdy bude zypper nejrychlejší ze všech .

[bhy]

jako že Novell bude jeho uživatelům dotovat výkonnější hardware? :)

[Käyttäjä 11133]

A to jako proč? Hloupý výkřik do tmy?

[bhy]

ne, protože zypper zřejmě zatím zdaleka není nejrychlejší ze všech.

[Ilfirin]

Já nepsal, že je, psal jsem, že bude (jednou, možná, asi ...) .

[bhy]

v pohodě, já jsem reagoval na obvinění Marka Stopky z hloupého výkřiku do tmy.

[Jan Grmela]

Tak mě napadá...proč je ten YaST (openSUSE 10.3) vlastně tak strašně pomalý? Když jsem si teď na druhé PC hodil CentOS, kde je yum, tak jsem úplně jásal, jak je rychlý oproti YaSTu. Jen spuštění výběru balíků u mě při cold-startu trvá asi 4-5 minut (C2D T7300). Hot-start je o něco rychlejší, ale i tak je to aspon na minutu a půl. Je ale pravda, že samotný zypper jsem používat nezkoušel.

[Kyosuke]

A už to tu máme zase... Tak ještě jednou: YaST není pomalý. Pomalá (a paměťově žravá) je jedna konkrétní knihovna, co se používá na správu balíčků, ale jednak ji používají i jiné součásti systému (zmd, opensuse-updater, zypper, ZYPP bindingy pro Python a Ruby...), jednak pro YaST samotný je tahle knihovna jen jedním z mnoha "obslužných backendů" (ty další jsou parsery a zapisovače všelijakých konfiguračních souborů, další knihovny a podobně.) Jinými slovy, říct "YaST je pomalý" dává asi takový smysl, jako říct "to auto jede dneska divně" při jízdě na pořádně rozbité silnici. Co s tím má to auto společného? A proč všichni pořád obviňují to nebohé auto, když za to můžou silničáři?

[Jan Grmela]

Dobře, YaST možná není pomalý z pohledu programátora, ale z pohledu koncového uživatele jeho rychlost hraničí z totální nepoužitelností (bavím se jen o balíčkovači). Sice je hezké, že je pomalá jen jedna knihovna ale to je (když použiju analogii s autem) jak říkat, že nové BMW nemůže ze to, že do něj dali motor z Fabie 1.2 HTP.

[Kyosuke]

Bože... Tak ještě jednou, balíčkovač (jedna silnice) není součást YaSTu (jednohou auta). Ten pro něj má jen rozhraní (čtyři kola ), a po té silnici (libzyppu) jezdí i jiná auta (zypper, opensuse-upgater, zm(r)d...) a to jedno auto (YaST) jezdí i po jiných silnicích (SCR agenty pro soubory v /etc, pro síťovou komunikaci...) a tak dále.

O žádný "motor v autě" (který by byl jen uvnitř YaSTu) se v případě ZYPPu nejedná, problémová věc je zcela mimo auto a to auto samo o sobě je rychlé až až - koneckonců je psané ve staticky typovaném předkompilovaném jazyku s docela rychlým VM. Myslím, že když mi YaST je schopen načíst konfiguraci tiskáren, načíst databázi ovladačů, nadetekovat tiskárny a konfiguraci zase uložit za tři sekundy, konfiguraci NFS za sekundu a konfiguraci všech rozhraní za dvě sekundy, stěžovat si na pomalost nemůžu. A to mám dva roky starý stroj s nepříliš velkou pamětí.

[Jan Grmela]

Já rozumím tomu, že za to samotný YaST nemůže. O to mi nejde. Jde mi ale o to, že když si běžný uživatel spustí YaST a chce spravovat balíčky, tak je výsledkem jen dlouhé čekání.

Mě osobně to zas tak moc netrápí s tím, jak často něco instaluju. Kdybych ale potřeboval instalovat balíky 2x denně, tak už mám na Suse APT či Yum.

[Käyttäjä 11133]

A je to chyba staré verze knihovny, která v openSUSE 11.0 dosahuje skvělých výsledků, které jsou lepší než výsledky Yumu. To jen tak pro úplnost :D

[Käyttäjä 11133]

Protože v 10.3 není verze 4.21.1, ale starší. Problém u starší verze bylo dlooouhé načítání vyrovnávacích pamětí.

[Jan Grmela]

Přesně tohle jsem potřeboval slyšet. Znamená to tedy, že v 11 už bude rychlost v pořádku? Ptám se proto, že zlepšení slibovali už u 10.3 a po čase jsme tam, kde jsme byli v minulé verzi openSUSE.

[Käyttäjä 11133]

No ono zlepšení mezi 10.2 a 10.3 bylo taky docela velké. Rozdíl mezi 10.3 a 11.0 je však ještě více patrný. Mě to přesvědčilo natolik, že jsem prostě nemohl jinak a aktualizoval jsem na openSUSE Factory.

[Kyosuke]

Nestačí repozitář zypp:Backport, který existuje pro 10.3?

[Käyttäjä 11133]

Pokud chceš odinstalovat půlku YaSTu, nebo co to po mě chtělo, když jsem ho chtěl nainstalovat... :D

[Kyosuke]

Tak jsem to zkusil...a pochopil, co máš na mysli... ^__^

[Michal]

Je celkem jednoduche pouzivat komplet YaST/zypper z Factory, moc dalsich zavislosti to nevyzaduje (perl&spol clovek nejak prezije :), cas od casu si to cele komplet updatnu.

[abr]

... ještě více patrný.

jeste vice nez jeste vice, je to proste parada
zypper refresh, zypper up, zypper se, zypper in
jeste udelat alias zzpper='zypper' (at je to jasnejsi a rychlejsi) :)

[andy]

ano, o vikendu jsem instaloval opensuse 11b2 a tohle tvrzeni muzu opravdu potvrdit - navyseni rychlosti je opravdu dost vyrazne.

[Vin]

Jo, přijde mi to o něco rychlejší než apt na pclinuxosu.

[thingie]

> Zypper rychlejší, než yum

?

[Michal]

Treba tady jsou nejake detaily: http://duncan.mac-vicar.com/blog/archives/309

[pushkin]

Tak jsem si říkal, že by nebylo od věci zkusit si nový Zypper, a tak jsem sebral odvahu, aktualizoval Zypper, libzypp a závislosti na tom i Yast. Výsledek? Ani jeden z modulů Yastu, který má souvislost s balíčky se nestartuje.

Error while creating client module sw_single

Tak, a teď jdu zjistit, jak si vrátit zpět svůj sice pomalý, ale funkční zypper...

[Käyttäjä 11133]

Proveď aktualizaci na Beta3, který dneska vyjde. Na to, že ten backport nemusí fungovat jsem tady už upozorňoval, takže asi tak.

[pushkin]

Mno, on backport Zypperu fungoval, jen nefungoval YaST. Nicméně půhodinka v Konsoli kombinovaná s odebráním a následnou instalací původního YaSTu ve Smartu to vyřešila

[MJ]

Je sice pěkné, že zypper je čtyřikrát rychlejší než yum, ale upřímně řečeno, 9 sekund na spočítání upgradu je naprosto absurdně mnoho. Takové operace mají probíhat na odmáčknutí.

[Käyttäjä 11133]

To by se mi také líbilo, ale asi to bude ještě nějakou du chvilku trvat. Snad se toho dočkáme.

[jik]

Jo, až se programy zkrátí na 1 (chybnou) instrukci.

[Kyosuke]

Možná se tomu směješ, ale jednou bude stroják možná vypadat takhle:

0x0000000000437837 <main+87>:   movq   $0x0,0xf0(%rsp)
0x0000000000437843 <main+99>:   callq  0x407258 <getegid@plt>
0x0000000000437848 <main+104>:  mov    %eax,%ebx
0x000000000043784a <main+106>:  callq  0x4068e8 <getgid@plt>
0x000000000043784f <main+111>:  zypper
0x0000000000437851 <main+113>:  jne    0x4380a5 <main+2245>
0x0000000000437857 <main+119>:  mov    $0x4a1652,%esi
0x000000000043785c <main+124>:  mov    $0x6,%edi
0x0000000000437861 <main+129>:  callq  0x407af8 <setlocale@plt>
0x0000000000437866 <main+134>:  mov    $0x4a2841,%esi

[Petr Tomeš]

Zypper je nejen výrazně rychlejší, ale také mnohem méně náročný na RAM než yum i smart.

[Jakub Lucký]

Doporučuji udělat ještě srovnání s emerge... To mi přijde takové pomalé a strašně náročné na CPU (jeden balík to instaluje třeba i několik hodin) ;) :)

[Käyttäjä 11133]

Kdyby si ten článek alespoň viděl, tak by si určitě zjistil, že článek neřeší samotnouinstalaci, ale jen dobu, než si balíčkovací systémy načtou své vyrovnávací paměti, vyřeší závislosti,.. na samotnou instalaci je poté odpověděno [ne].

[Jakub Lucký]

No, uznávám, vtip se nepovedl (článek jsem opravdu nečetl, nějak mě tyhle RPM based frontendy netrápí)

[Kyosuke]

Jasně, s dpkg-based frontendy si člověk taky užije spoustu legrace.

[Jakub Lucký]

To každopádně :)

To mi tak připomíná, že už tu dlouho nebyl flame: apt vs. aptitude vs. dselect vs. checkinstall vs. Gentoo ;)