Courgette: új, hatékony bináris diff algoritmus a Google-től

Szerszám

Stephen Adams szoftvermérnök arról ír, hogy egy új algoritmust készítettek, amelynek segítségével az eddiginél sokkal hatékonyabban tudják majd a Google Chrome frissítéseit terjeszteni. A Google, ha egy tíz soros biztonsági frissítést kell kiadnia, nem tolja le a felhasználókhoz a Google Chrome böngésző újabb, körülbelül 10MB-ot kitevő teljes frissítését. Ehelyett inkább egy diff-et küld, majd fogja a korábbi verziót és a diff felhasználásával egy újabb, javított verziót hoz létre.

A Google-nél kipróbáltak több diff algoritmust is, de a legjobban a bsdiff vált be és eddig azt is használták a bináris patchelés-hez. Azonban a bsdiff még mindig nagyobb diff-et hoz létre, mint az a vállalat szeretné. Éppen ezért készítettek egy új algoritmust, amelyet Courgette neveztek el.

A hatékonyságáról:

Teljes frissítés: 10,385,920 byte
bsdiff frissítés: 704,512 byte
Courgette frissítés: 78,848 byte

A részletek itt és itt.

?

mi van? disztró témához csak disztrókészítő szólhat hozzá? csupán próbáltam rávilágítani, hogy a fedora csomagkezelője se egy álom, mielőtt még nagyon olvadozni kezdenének a srácok

a debian sid-et (aka debian unstable) végképp nem értem, hogy jön ide?

szerintem.

Irta hogy van ilyen X distro-ban. Erre irta valaki hogy igen, Y-ban is van ilyen. Erre te felhozod a szokasost. .."mielőtt még nagyon olvadozni kezdenének a srácok".. Igen mindenki azt akart. Mar el is kezdtek.. nem latod?

"a debian sid-et (aka debian unstable) végképp nem értem, hogy jön ide" < Unstable-t azert hoztam fel mert ott aztan tenyleg szerencsejatek frissiteni. (Na jo ha az ember figyel tobb hirforrast, levelezolistat, esetleg mas dolgokat, akkor talan megussza.)

Nem a rendszer lett elcseszve (lasd anno Debian osszes openssh-ja IIRC), hanem a repokkal adodott megint gond. Ez megint mas, s nem nem lehetett frissiteni, jopar mirror esett ki a szinkronbol, de volt ami maradt. A betoreses dolognal is csak a mirror hullott, nem a rendszer. Engem nem zavar hogy ha a gepemre nem tudok 0-24 csomagot telepiteni, ugyis csak egyszer install utan rakok fel mindent amire szuksegem van es kesz.

először is. stabilt egy erősen fejlesztőknek szánt branch-csel összevetni nagyon "értelmes" ötlet volt.

másodszor. debian-nál legalább ami van, az megbízhatóan megy (sid-en is kb. kéthavonta, ha van valami gond, és az is megoldódik pár napon belül), nem arról szól a történet, hogy beletalicskázzunk mindenfélét a rilizbe, aztán majd lesz valami (pl. olyan emlék is dereng, hogy rc kernel került rilizbe).

harmadszor. igen, olvadozás-szaga volt, kezdve a zsuzsis "ők frissek e téren!" szöveggel, meg a blogpostos linkben lévő sírásrívással az ellenoldalon. amúgy meg nem tudom, mi volt ebben szokásos. ő elmondta, hogy a fedora frissítés bizony nagyon okos, én meg hozzátettem, hogy biztos az, már amikor működik, erre te elkeztél cirkuszolni, hogy nekem nincs saját disztróm, meg hogy a debian unstable nem stabil. nahát, micsoda fordulat, és tényleg mennyire idevágó.

negyedszer. továbbra sem világos, hogy miért ellenérv számodra a debian, mintha én a debian kereszteslovagja lennék kb. ha erre számítottál, nagyon mellélőttél. egyébként is, attól még, hogy a debianban szar valami, a fedora nem lesz kevésbé szar, szóval nem teljesen világos a gondolatmenet. de ha már itt tartunk, a debianban hamarabb bíznék, mint a fedoraban, bár a témához ez a tény abszólút nem kapcsolódik, csak gondoltam megnyugtatlak, ha már ennyire izgat a dolog :)

szerintem.

Most annyira nem folynék bele, mert hülyeség az egész téma, csak a saját tapasztalataimat adnám hozzá: Az utóbbi öt és fél évben, mióta fedorát használok kétszer volt frissítési gond, egyszer talán tavaly betörés miatt két hétig nem voltak frissítések, meg a héten vagy három napig, a tükörszerverek félrekonfigolása miatt. Azért ez _szerintem_ nem olyan rossz rendelkezésre állás.
Csaba

'jaj, a "nemlehetfrissíteni" fedora :)'

Készülj fel, hogy ha majd debiannál becsúszik egy kis malőr, tíz évig hallgathatod... :)
Egyébként a debian csomagkezelés biztosan jó meg kényelmes, de ettől még Téged miért zavar hogy valakik kipróbálnak új dolgokat és próbálnak fejlődni?

---
;-(

Finishing rebuild of rpms, from deltarpms
| 80 MB 01:06
Presto reduced the updates to 9.5 M from 80 M which is a 89% savings.
Package(s) data still to download: 76 k

Jo dolog is.. :) (Ps.: Nekem eddig sem volt update gondom fedora-val, amikor updatelni akartam, nem volt semmi gubanc. Lehet csak nekem van makom.)

na, ez azért nem olyan egyszerű, mint ahogy a szakértő úr leírja. egy dolog, hogy ő remekül eljátszik az egy szem rendszerén egyetlen csomag két, egymást követő verziója között, egy másik dolog ezt megoldani több(száz)ezer konfigon, rengeteg csomag rengeteg verzióján, a disztró több kiadásán (azon belül variánsán) keresztül (főleg, hogy pl. ubuntunál egyszerre vagy 3-4-et támogatnak ezekből, 3 variánson), csomagkezelőbe integrálva, automatikusan. közel sem triviális.

"A kérdés tényleg az, hogy miért, miért, miért?"

hát ezért.

szerintem.

Milyen százezer konfigon? A user konfighoz nyilván a Google sem nyúl, a disztró több kiadása sem más, mint bizonyos verziójú csomagok összepakolása. A verziók között lehet xdelta-val diffelni.

Szerintem túlbonyolítod. Ahogy alul látod, néhány distro érdekes módon meg tudta csinálni, de nem baj, debian és ubuntu majd a XXII. századba betervezi...
---
;-(

"Milyen százezer konfigon?"

PC konfigon. google-t nagyon sok értelme volt idekeverni.

"a disztró több kiadása sem más, mint bizonyos verziójú csomagok összepakolása"

ez csak azért igaz, mert a különböző variánsok csomagjai nyilván bekerülnek a közös repóba, de attól még valakinek karban kell őket tartani.

azt arc meg nagyon nagy, csak nem tudom, hogy mire. lehet dobálózni ilyen-olyan bleeding-edge szarokkal, csak értelme nincs. fedora-n pl. van restart nélküli kernel hotfix? amúgy meg elhiszem, hogy kurvajó a fedora csomagkezelő, bár nekem lassabb volt, meg kb. szart se ér a gui-ja. de szeressétek világgá, nem érdekel.

szerintem.

( prygme | 2009. 07. 17., p – 21:57 )

ez igazán csodás, de mi lesz azokkal a chromeokkal, amiket nem frissítettek egy ideje? tárolni kell majd az örökkévalóságig az összes diff fájlt. bár az csak az update server oldalt terheli:)
__________
made in germany

( hofi75 | 2009. 07. 17., p – 23:57 )

pár hete volt szerencsém megnézni egy mainframe assembly-ben irt programhoz készülő bináris patch (ott ZAP-nek hívják) kódolási folyamatát. hát nem volt egy egyszerű téma, nagyon ott kell lenni a szeren, hogy ne nyúljon mellé az ember. a kódot eleve úgy írják, hogy nyitott legyen kellő mennyiségű javítás befogadására. a CSECT-ben mindenütt NOP utasítások és szabad területek a pathceknek. harmadik fordítás után hibátlanul működött a javított program. érdekes volt látni, hogy a 25-30 éves tapasztalattal rendelkező rendszerprogramozók mennyire másként nyúlnak egy adott problámához. na meg, hogy először gondolkodnak azután gépelnek.

( Josephus | 2009. 07. 17., p – 23:57 )

Binaris diff my a$$

"Courgette transforms the program into the primitive assembly language and does the diffing at the assembly level"

Es mit csinal egy mp3mmal a google binaris differ? Fourier transzformal?

jpg-nél legalább tényleg lehet fourier-trafót nyomni ;D

feltehetőleg az update-ek során a program változik többet. a többinél meg használnak valami más diffet. eddig is jöhetett más az update-tel, mint csak bináris, és eddig is megoldották. mostantól nem a bináris-nembinárisra kell figyelni, hanem a progam-nemprogramra. miért kell ezen ennyit lovagolni? :)

szerintem.

( msandor v | 2009. 07. 18., szo – 09:28 )

az UHU-Linux évek óta támogatja az rsync-es csomag frissítést, azaz ha megvan a cache-ben a korábbi verzió, akkor csak a különbséget tölti le, ha nincs, akkor az egészet, ez nagy ötlet, csak két probléma van vele: meg kell hagyni a cache-t, illetve nagy a CPU terhelése a dolognak, főleg szerver oldalon...

más disztró ilyet nem csinált eddig?

--
by Mikul@s