Pozitivní Vibrace 4 a Gentoo Portage

19.9.2005 10:10 | Přečteno: 1290× | Hudba

Minulý týden v sobotu proběhla akce Positive Vibes 4 v olomoucké Envelopě. Jednalo se o Drum And Bass party, které jsem se nejen zúčastnil, ale zahrál si na house stage. Fotky jsou na sídle YT Promotion.

Hlavní hvěždou večera byl londýnský Aphrodite. Byl jsem docela překvapen, takový třicátník v rozevláté košili, hrál velmi pestrý set plný nástupů a různých pecek. V hale bylo totálně narváno a až na problémy s teplotou to byla velmi vyvedená akce. Až jsem z toho na týden onemocněl.

Ten týden jsem se "hrabal" v nejrůznějších věcech na svém Gentoo Linuxu a taky došlo na Portage. Velmi mě štve, jak je tento balíčkovací systém pomalý. Strace ukázal, že kámen úrazu je v adresáři /usr/portage, který se prochází skoro při každé operaci celý.

Ačkoli mi bylo jasné, že díky rsyncu se tohoto uložení vývojáři jen tak nevzdají, jal jsem se zkoumat zdrojový kód systému Portage. Věděl jsem, že je napsaný v Pythonu, takže jsem čekal výborný objektový návrh...

A byl jsem zděšen. Takhle prasácky napsaný program jsem dlouho neviděl. Že je zdroják neuklízený, plný hacků a TODO poznámek by mi ani nevadilo, ale že všechny třídy naplácali vývojáři do jednoho souboru to bylo na mě příliš. Dále pak se mi nezamlouvaly některé "hack"-funkce a ke všemu byl téměř celý kód nedokumentovaný. Korunu tomu nasadila "organizace" výstupů na konzoli:

write( green( "Checking portage...") )

Tomu říkám oddělení uživatelského rozhraní...

Zjistil jsem, že problém rychlosti se již jednou řešil - u stromu závislostí. Je tam možnost použít kromě adresářů s mnoha soubory také formát cpickle nebo anydbm. Ale hlavní bolístka je ve stromu balíčků. Řešení jsem nenalezl.

Open source projekty často potřebují pevnou ruku, někoho, kdo by se ujal těžkého úkolu návrhu programu a dohledu nad dodržováním standardů psaní kódu. Bohužel je až příliš mnoho programů "uháčkovaných".

       

Komentáře

[Michal Vyskočil]

Možná by to řešil databázový souborový systém portagefs, který by zachovával možnost klasického procházení souborů na disku, ale pro uložení stromu portage by používal databázi.

[Lukáš Zapletal]

Už jsem nad tím přemýšlel, ale:

- dnešní souborové systémy jsou rychlé, přesto trvá načítání /usr/portage i vteřinu (napoprvé) - ThinkPad R50e, XFS, 2.6

- úzkým hrdlem je spíše velký počet volání (stat() na každém souboru), tudíž by DB asi nepomohla (i když bude možná rychlejší v průchodu indexem, stále bude aplikace volat 9000x stat() )

- portage jako takový si přímo koleduje o zásadní změnu, už na to poukázali uživatelé i vývojáři

[Michal Vyskočil]

Já to myslel tak, že z uživatelského hlediska by se nic nezměnilo. Pořád bychom mohli ručně procházet /usr/portage, jako by to byly soubory a adresáře (ani by nevadilo, kdyby to bylo o něco pomalejší, než klasický fs). Uvnitř by to samozřejmě byla databáze a emerge by k tomu taky tak přistupoval. Co se týká synchronizace dat, ta se dá udělat přes rsync i u binárních souborů, v tom by neměl být problém.

[Lukáš Zapletal]

Jo takhle, tak to jo, problém ale je, že portage je tak prasácky napsaný, že tam nelze vložit nějakou "mezivrstvu". Prostě k těm souborům se přistupuje přímo, z různých míst. Žádnou třídu, která by to nějak zapouzdřovala, jsem nenašel. Pouze k těm závislostem.

[Voidless]

Proste postup by musel byt:

1) prepsat portage do poradneho (OO) kodu s kvalitnim navrhem

2) prevest na databazovy backend

Way too much work...

O pomalosti portage vypovida i treba existence eix, ktery si vytvari vlastni databazi a hleda v ni (a je daleko daleko rychlejsi). Uvazoval jsem o tom zkusit napsat program pro graficke zobrazeni dependencies mezi balicky a prvni co me napadlo bylo, ze tam musi byt nejaka databazova cache (treba SQLite), jinak se to ani nehne...

[Michal Vyskočil]

Aha, no tak to je jediná možnost - celé to přepsat . Je nějaký takový projekt, nebo se o tom zatím pouze uvažuje?

[Lukáš Zapletal]

Zatím je to ve stádiu "uživatelé si stěžují/developeři o to vědí". S narůstajícími balíčky se to bude dále zhoršovat.

portage má asi 660MB (aktualizoval jsem asi před 14 dny)

[trancelius]

Myslíš /usr/portage ?! 4 minuty stará má 84 MB. Nezapletly se do tvého měření adresáře jako "packages" (binární balíčky) a "distfiles" (stažené zdroje) ??

[Lukáš Zapletal]

Jsem nepozorný, ovšem, to je ono. Nicméně i tak je to pěkný bumbrlík...

[dekon]

Kdyz si prohledate gentoo forum zjistite, ze pomalost portage se tam resila.

Chce to jen vytvorit samostatny oddil pro /usr/portage ten pote naformatovat na Reiserfs4 a je po problemu.

[dekon]

http://forums.gentoo.org/viewtopic-t-374850.html

[Lukáš Zapletal]

Moc se mi tomu teda nechce verit, ja sam jsem migroval z ext3 na xfs a nezaznamenal jsem absolutne zadnou zmenu.

Tak jako tak je portage spatne navrzen. Je sice krasne, ze se to aktualizuje pouhym volanim rsync, ale prave kvuli tomu se to spatne rozsiruje...

Jinak diky za tip, az bude ve vanille, urcite to zkusim.