Forum boinc.cz

Ten sice komprimuje velice ucinne, ale pry jsou jeste v kodu chyby a tak je obcas vysledny soubor poskozeny. Takze ne.

fatbozz píše:Kdo je pro kompresní formát 7zip ať zvedne tlapku !

Nemyslím si, že by zrovna tenhle formát byl vhodný pro tyhle aplikace. Právě poměrná pomalost a náročnost na procesor při pakování by to nakonec pěkně pohřbila. V tomto případě je jasný favorit ZIP(gZIP), pořád je to nejvýkonější pakovací formát z hlediska rychlosti.

Od dobu DOSu používám RAR, resp. nyní WinRAR a neměnil bych. Je fakt, že na největší stupeň komprimace to trvá strašně dlouho, ale těch stupňů tam je 5.
dejv

Pokud je mi znamo, tak ani RAR ani ARJ nejsou public/free. A to je jedna z podminek pouziti v boincu. Takze kandidaty jsou zip, lzw a lzh, a samozrejme na zaver huffman Takze zapomente na proprietarni formaty.

2 Honza: je pravda, ze samotne aplikace by mohly komprimovat, ale ty se nemeni a tudiz z dlouhodobeho hlediska nemaji na traffic vliv. Nevim, jestli sis nekdy s kompresi hral, nebo psal vlastni kompresni programy, ale jakakoli komprese nezatezuje jen cpu, ale vyzaduje i urcite mnozstvi pameti. Stale jsem toho nazoru, ze rozhodnuti tymu seti bylo spravne. Myslim, ze cekaji az se situace ustali a pokud to bude mozne, tak kompresi "zapnou". Na to si ale urcite budeme muset pockat.

2 Ford Prefect: no Honza ma pravdu v tom, ze download aplikace by skutecne mohl byt komprimovan - to zadny CPU ani pamet nesezere, protoze se to zkomprimuje jen jednou, kdyz vyjde nova verze aplikace. Na druhou stranu, soucasna aplikace je mala (mnohem mensi nez ta optimalizovana od Crunch3ra) a taha se jich nekolik desitek tisic denne - proti milionum jenotek je to pomerne nezanedbatelne mnozstvi dat. Kazdopadne by to bylo ale mnohem kritictejsi v pripade nove Enhanced verze, kterou za prve bude tahat mnohem vice lidi, a za druhe bude i s knihovnami pravdepodobne mnohem vetsi. Je ale otazka, jestli se to nahodou v Bete uz nestahuje zkomprimovane - ja jsem to sam nekontroloval, a to ze se na disku objevi hned rozbalene soubory jeste zdaleka neznamena, ze se tak prenasely. HTTP protokol umoznuje prenos zkomprimovanych dat a jejich dekomprimaci pri prijmu (a knhovny na to v Boinc klientu jsou), takze pokud nesledujes velikost prenesenych dat, tak neuvidis jestli to prislo zkomprimovane nebo ne.

Doporucil bych aby se na to Honza na foru Bety zeptal a pripadne jim pripomenul jakou zacpu riskuji v pripade, ze by novou aplikaci planovali v normalnim S@H prenaset nezkomprimovane.

Co se tyce jednotek, to je samozrejme jine, a tam si stojim za tim, co jsem rekl.

2 Trux: i ja v predchozim prispevku pisu: "je pravda, ze samotne aplikace by mohly komprimovat, ale ty se nemeni a tudiz z dlouhodobeho hlediska nemaji na traffic vliv"

@ FordPrefect - pakoval jsem si veci uz v 80. letech, takze s tim minimalni zkusenosti mam

Muj navrh/diskuse spociva v tom, ze lze pakovat (a) aplikaci+knihovny, (b) WUs. Nebo podrobnejsi deleni je (a) aplikace+knihovny, (b1) WU na download, (c1) WU na upload.
Asi to stale neni zrejme, takze udelam hlasovani

KAZDY projekt usetri tim, ze bude pakovat (a), aniz by to zatizilo servery nebo pamet.
(b1) je vhodne v pripade, ze WU typu neni prilis nebo jsou pouze dopovazene souborem s paramtry analyzi - CPDN, Rosetta, Einstein. WU zasilana k analyze nejsou vetsinou analyzovana na servech ze strany projektu, takze jejich zapakovany stav nevadi.
(c1) je vhodne tak, kde je upload veliky [CPDN]. Jelikoz je vsak rozbalovani o dost rychlejsi nez baleni, muze to byt uzivano obecne, pokud se to stiha zpracovat. Jelikoz vysledky uploadu stene vetsinou lezi v nejakem poolu a cekaji ve fronte, nevidim v tom problem.

Stale nikdo nedal rozumny argument pro nepakovani aplikace+knihoven.

@trux - ano, ne BETA SETI jsem ten navrh vznesl - prave v souvislosti s tim, ze to na BETE lze otestovat a ze by tim distribuce Enhanced aplikace mohla pomoci SETI nabyt trochu "efektivity", ktera zalostne chybi. Reakci nebylo mnoho, ale minimalne jsem se dozvedel o tom, ze se o tom jiz uvazovalo. Stale se ale mnoho lidi zasekava na pakovani WU a pakovani aplikace ignoruji.
Vychazim z toho, ze pokud davame k dispozici CPU cycles, misto na disku, prenosove pasmo a elektrinu (+dalsi), melo by to byt vyuzito efektivne.

Myslim, ze o pakovani clientu a jejich soucasti asi neni sporu. Mozne to je, a i ja zasnu nad tim, ze v berkeley vyrabeji nejenze nepakovane appz, ale dokonce nestripovane ! To by urcite zmenit meli.

V otazce pakovani WU asi nikdo neni proti, otazkou je ovsem zatizeni serveru v berkeley a asi tam vsichni maji obavy, jestli by to system ustal. Ja na dvou mistech stahuju WU pomoci GPRS, takze na traffic taky nadavam.

imho tohle hlasovani povazuju za nesmyslne

Jestli o pakovani aplikace a jeji soucasti neni sporu, proc uz se to na SETI leta nedeje??? Projekt, ktery ma nejvyssi cetnost stahovani aplikace (nejvice pripojenych masin) by mohl jit prikladem
Kazdy si ucinnost i narocnost pakovani muze zkusit a pak hodnotit.

Duvod hlasovani jsem psal - rozliseni dvou (tri) casti, kde lze pakovani aplikovat: 1. aplikace+prislusenstvi, 2. WUs. Jsem rad, ze uz je to ted jasne.

2 Honza: ano, trochu ostudne to je. Ale nesmime, zapominat na fakt, ze napr windows nemaji zadny zakladni kompresni program integrovan. Na unixovych systemech je napriklad gzip standartem, to ale neznamena, ze bude uplne na kazdem unixovem stroji. Chapu tedy jejich rozhodnuti mit exec aplikaci.

btw imho podobne bychom mohli hlasovat, jestli nasi maji v Turine na olympiade v hokeji ziskat zlate medaile. Kazdy z nas si to asi preje, ale je to jen zbozne prani, bez jakohokoli vlivu na vyvoj situce.

Myslim, ze budu mluvit i za Truxe kdyz reknu, ze nejsme proti kompresi appz+wu, ale jen nastinujeme duvody, ktrere mohly team seti vest k tem rozhodnutim

2 FordPrefect: Jak uz jsem psal, BOINC jadro v sobe zip knihovny zabudovane ma, takze neni potreba zadna podpora OS.

Jinak samozrejme jsem taky pro pakovani. Jak jsme ale uz rikal, prozatim to u jednotek neslo kvuli zatezi, a u aplikace to bylo dost nedulezite, takze se nedivim, ze si s tim moc nelamali hlavu. Doufam ale, ze pri prechodu na Enhanced to zavedou. Hlavne ale, jak uz jsme psal, je velmi dobre mozne, ze se to zkomprimovane uz stahuje, ale protoze je to udelane transparentne, tak to ani nevidime. Ma nekdo vubec nejaky dukaz pro to, ze se to taha nekomprimovane, abychom tady nediskutovali o necem co je uz davno vyreseno?

trux píše:2 FordPrefect: Jak uz jsem psal, BOINC jadro v sobe zip knihovny zabudovane ma, takze neni potreba zadna podpora OS.

Uz ti podruhe pisu, ze to ja vim. Ja mel na mysli rozpakovani clienta samotneho

FordPrefect píše:Uz ti podruhe pisu, ze to ja vim. Ja mel na mysli rozpakovani clienta samotneho

O pakovani klienta se tu nikdo nebavi Ten uz zapakovan je - v installeru jsou vsechny soubory zapakovany. Rec je o pakovani aplikace, a jak uz jsem rekl, v jadru klienta BOINC zip funkce jsou, takze zadnou podporu OS na rozbaleni zdownloadovane aplikace nepotrebujes. A navic jeste rikam, ze zatim nemhou vyvratit, ze tomu uz tak nedeje - mozna se tu bavime o nicem, protoze je velmi dobre mozne, ze to cele probiha uz komprimovane.

2 Trux: nemuzu vyloucit, ze nejaky installer existuje. Krom toho je asi jen pro windows. A ty ja nepouzivam

FordPrefect píše:2 Trux: nemuzu vyloucit, ze nejaky installer existuje. Krom toho je asi jen pro windows. A ty ja nepouzivam

To se nezlob, ale Linuxovou verzi BOINC clienta tahas z jejich serveru taky v instalcnim komprimovanem balicku. Ale hlavne to nemeni nic na tom, ze otazku klienta tady vubec neprobirame a nepokladam to vubec za dulezite. Podstatne je zda se uz komprimuje nebo bude komprimovat aplikace projektu, coz v pripade downloady Enhanced verze na nejakeho pul milionu pocitacu, preci jen uz muze byt dost podstatne. A jak jsem rikal, technicky to mozne je - co ale nevim, bez toho abych prostudoval prislusnou cast zdrojaku, nebo zmeril download, je jestli to tak uz probiha ted nebo ne.