Portál AbcLinuxu, 27. července 2025 07:30
Ja bych to chapal jako rozdil, mezi novou a starou verzi programu.. Vyhoda = nemusis tahat cely novy balik, ale jen nove veci, stare uz mas naistalovane.. Takova "zaplata"
PS: rozhodne ti to tu nekdo sofistikovaneji popise..
Pri update sa netahaju cele rpm baliky, ale len rozdiel medzi starym a novym.
Ako mate delta t (teda cas) rozdiel noveho a stareho casu, tak mate aj delta rpm rozdiel noveho a stareho balicka. A kedze medzi prevratne zmeny v novej verzii xyz-3.0.3 zaberajuce priblizne 1% celkovej velkosti balicka, stiahnete iba tento kusok.
(teda aspon tak si to vysvetlujem)
vice teda ne o moc zde: http://www.opensuse.cz/o_suse_a_deltaiso_deltarpm
Pritom jak pomerne pravidelne probihaji aktualizace u Fedory (preklad: vysledna nefunkcni aplikace nebo rovnou cely system),tak s timhle bude taky kopec legrace Jinak to vypada,ze nekdo s velkou pompou a slavou znovu vynalezl kolo -> unified diff ; jen ve forme pro rpm
Věřím tomu, že s tim kopec legrace užiju, jako vždycky když už se release u Fedory dá používat končí mu podpora -> viz teď Fedora 9
Ale jinak mam Fedoru rád
Asi by som sa tým nemal chváliť, ale ja stále používam Fedoru 8. Aj keď som si už prekompiloval nejaké balíčky z F10 a nejaké z F11 (Rawhide) kvoli bezpočnostným (a iným) záplatám, základ je stále Fedora 8 aj s jej NetworkManagerom 0.7.0-0.6.9.svn3675.fc8
Už len čakám na F11, ktorú testujem na druhej partícií - hádam aj budem upgradovat za tých pár dní
Tak ono vynalezt kolo ktere dela zaplatu v binarnich komprimovanych souborech neni uplne tak jednoduche jako si rict "budiz kolo". Ale hlavne ze tomu rozumite, nenechte se rusit.
Zajemci si muzou precist vice o problematice binarnich zaplat na RPM soubory tady: Algoritmus a implementace software pro tvorbu binárních záplat.
-Yenya, http://www.fi.muni.cz/~kas/blog/
Ono kdyz mate v systemu textove zdrojaky,pomoci unified diff(napr. pres cvs) si stahnete jen rozdily a nasledne se zkompiluji nove binarky (coz na modernim PC je tak cca do 30 minut),tak je vysledek uplne ten stejny - taky jste usetril prenosy po siti.Ale tohle se uz pouziva roky a diplomek je na to na Inernetu prilis
Takže jak vidno, u RPM balíků to bude, nebo již funguje. A co na to Debian? Má někdo něco bližšího?
debdelta
.
Skusal som vcera na bete f11 a update mal 6.7 MB, ale pri pouziti delta rpm sa stiahlo len 800 kB. Co je velmi pekne.
vsetko ma dve strany: ak by ste mali platit za gigabajt odchadzajucich dat na yum repo mirrore tak by ste zacali rozmyslat ako posielat len skutocne to co sa zmenilo.
Souhlas. A ted je jeste otazkou, jestli bude pretizeny server a nebo prave ta linka, po ktere poleze vsechno nebo jen diffy.
Na debianu (asi 4, nevim presne) to bylo videt dost drasticky, kdyz se do upadte dostal kompletne cely xorg a par dalsich "drobnosti" (pres 100MB)... tahali vsichni s Xama a asi den se tomu vubec nechtelo. (tam byval defaultne update.debian.org centralizovany, ikdyz klasicke baliky byly na mirrorech). Nevim co se od te doby zmenilo.
Předpokládal jsem, že se jedná o obecný způsob, kdy klient pošle dva názvy souborů a server mu z nich pošle rozdíl (který si samozřejmě uloží, aby jej nemusel druhému klientovi znovu počítat). Pokud se repozitář z rodičovského serveru aktualizuje často a zato lidi aktualizují náhodně, tak by se dalo čekat, že rozdílových balíčků se takto bude muset navyrábět velmi mnoho.
Pokud ale rozdílové balíčky vyrábí už distributor, a to jen vždy pro sousední verze, tak je to jiná.
Přiznávám, že první věc, která mě napadla, byl rsync a jigdo. Asi to mají v Red Hatu více optimalizované ;)
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.