HTML

Bagoj úr blogja

Kíváncsi Bagoj befigyel a Linux belsejébe, illetve különféle Linux terjesztéseket próbál ki. Ha jó napja van, scriptet ír Neked.

Friss topikok

A nap kérdése: miért nincsenek különbség-csomagok?

2009.06.04. 11:10 bagoj ur

Nézegetem a 9.04 mai napi letöltés-adagját. Nekem természetes, hogy ilyenkor rászánom az időt, és megnézem, hogy mit írnak a changelogba, illetve a biztonsági frissítések hátterének utánanézek.

Igazából mellékes a téma, de mégis érzem a szépítés részét az Ubuntunál - ugyanis a CUPS frissítése úgy jött le, hogy "SECURITY UPDATE: Remote denial of service via ...", ha a Secunia.com-on nézem, ott már többszörös hibákról, és távoli kódfuttatásról is beszélnek a DOS-on kívül. A CUPS oldalán is 3 biztonsági hiba javításáról beszélnek. A Canonical már nem érezte fontosnak, hogy a DOS támadáson kívül jelezze a másik két - egyébként közepesen kritikusnak jelölt - hibát. Hát ezért nézek én utána ezeknek a dolgoknak... :-(

A lényeg, folytatván a CUPS csomaggal, hogy azt nézem, a változtatáshoz, ami lényegében minimálisnak mondható, le kell tölteni a következő csomagokat:

  • cups - ~2,1M
  • cups-bsd - 35 kb
  • cups-client - 112 kb
  • cups-common - 1 Mb
  • libcups2 - 169 kb
  • libcupsimage2 - 50 kb

Összesen: 3,4 Mb

Összesen 3-4 Mb nem a világ, viszont látván a patch-ek méretét, amiket a hibajavításhoz készítettek, kicsit összehúztam a szemöldököm: arányaiban közel ezerszeres a letöltendő. Miért foglaljuk ezzel a sávszélességet?

Gondoltam, csak egyetlen csomagnál ("cups") maradva összehasonlítom az 1.3.9-es és az új, 1.3.10-es csomag tartalmát, hogy egyáltalán mi az, ami változott? Mivel az 1.3.9-es nem volt már meg .deb formában, ezért a dpkg -L paranccsal kiírattam, hogy milyen fájlokból áll a fájlrendszeremen, és ezeket a fájlokat (ugyanabban a struktúrában, ahogy a fájlrendszerben van) lemásoltam egy alkönyvtárba:

for i in `dpkg -L cups`; do TMP=$(echo $i | sed 's_/__'); mkdir -p `dirname $TMP`; cp "/"$TMP $TMP; echo $i; doneA dpkg -L cups tehát egy listát ad a másolandó fájlokról, ezeken végigmegyek, egy átmeneti változóba belerámolom úgy, hogy a legelső perjelet leszedem (így mondjuk a /usr/share-ből usr/share lett), létrehozom a könyvtárat teljes struktúrával (-p paraméter), és belemásolom a /usr/share/.../fájlnevet a usr/share/.../fájlnév alá.

Az új csomaggal egyszerűbb a helyzet, egy apt-get -d install cups parancs csak letölti, de nem frissíti a csomagot - ilyenkor a /var/chache/apt/archives könyvtárba kerül. Megnyitottam a Midnight Commanderrel és kimásoltam belőle a fájlokat egy másik alkönyvtárba. Ezután már csak darabonként össze kellett hasonlítani:

for i in `find .`; do TMP=$(echo $i|sed 's/.//'); if [ -f $i ]; then  diff -qN ../139/$TMP $i; fi; done

(A diff tud rekurzívan is összehasonlítani, de előtte már szórakoztam vele, az if-fel kizártam a könyvtárakat, és mivel már az előbb így építettem fel a dolgot, nem akartam újraírni. Működik.) A változott fájlok listája (és méreteik):

  • /usr/share/man/man8/cupsd.8.gz - 1047
  • /usr/share/man/man8/cups-deviced.8.gz - 884
  • /usr/share/man/man8/cups-driverd.8.gz - 1701
  • /usr/share/man/fr/man8/cupsfilter.8.gz - 1012
  • /usr/share/man/fr/man8/cupsd.8.gz - 1198
  • /usr/share/man/fr/man8/cups-deviced.8.gz - 1067
  • /usr/share/man/fr/man8/cups-driverd.8.gz - 1976
  • /usr/share/man/fr/man8/cups-polld.8.gz - 880
  • /usr/share/man/fr/man5/cupsd.conf.5.gz - 4713
  • /usr/share/man/fr/man5/subscriptions.conf.5.gz - 1392
  • ./usr/share/man/fr/man5/printers.conf.5.gz - 1419
  • ./usr/share/man/fr/man5/mime.convs.5.gz - 1009
  • ./usr/share/man/fr/man5/mailto.conf.5.gz - 1042
  • ./usr/share/man/fr/man5/cups-snmp.conf.5.gz - 1425
  • ./usr/share/man/fr/man5/classes.conf.5.gz - 1377
  • ./usr/share/man/fr/man5/mime.types.5.gz - 1498
  • ./usr/share/man/fr/man7/backend.7.gz - 2567
  • ./usr/share/man/fr/man7/filter.7.gz - 2437
  • ./usr/share/man/man5/cupsd.conf.5.gz - 3989
  • ./usr/sbin/cupsd - 400584

Összesen 423 kbyte. És ez csak akkor, ha nem a bináris különbségeket, hanem az összes megváltoztatott fájlt egyszerre szállítanák. Mi van, ha csak a különbségeknek kéne lejönni?

xdelta

Van egy kis program a bináris különbségfájlok készítésére és kezelésére, ez az xdelta névre hallgat. Ha elkészítjük az előbbi fájlokról a bináris diffeket, meglesz hogy mekkora különbséggel számolhatunk:

for i in $(echo "./usr/share/man/man8/cupsd.8.gz ./usr/share/man/man8/cups-deviced.8.gz ./usr/share/man/man8/cups-driverd.8.gz ./usr/share/man/fr/man8/cupsfilter.8.gz ./usr/share/man/fr/man8/cupsd.8.gz ./usr/share/man/fr/man8/cups-deviced.8.gz ./usr/share/man/fr/man8/cups-driverd.8.gz ./usr/share/man/fr/man8/cups-polld.8.gz ./usr/share/man/fr/man5/cupsd.conf.5.gz ./usr/share/man/fr/man5/subscriptions.conf.5.gz ./usr/share/man/fr/man5/printers.conf.5.gz ./usr/share/man/fr/man5/mime.convs.5.gz ./usr/share/man/fr/man5/mailto.conf.5.gz ./usr/share/man/fr/man5/cups-snmp.conf.5.gz ./usr/share/man/fr/man5/classes.conf.5.gz ./usr/share/man/fr/man5/mime.types.5.gz ./usr/share/man/fr/man7/backend.7.gz ./usr/share/man/fr/man7/filter.7.gz ./usr/share/man/man5/cupsd.conf.5.gz ./usr/sbin/cupsd"); do TMP=$(echo $i|sed 's/.//'); xdelta delta ../139/$TMP $(basename $i)".diff" $i; done

Bocs, kicsit ronda lett, de az egyszerűség kedvéért felsoroltam a fájlokat, amit normál esetben egy fájlból olvasok fel.

A végeredmény: 54,768 byte. A letöltött, 1.3.10-es csomag mérete: 2,134,000 byte. Tehát elég lett volna leszedni a csomag

2,56%

-át, és ugyanazt a megoldást elértük volna az xdelta segítségével.

A másik, ami ma lejött, az evolution - 6,4 Mb-ot töltöttem le, azt nem számoltam ki hogy a mennyi helyett, de biztos vagyok benne hogy ennél is ergyább eredmény jönne ki, nézegetvén hogy mit patch-eltek a srácok.

Szóval, sok kicsi sokra megy. Mondjuk ha ezt a CUPS frissítést letöltik egymillióan, az kb. 1,9 Terrabyte felesleges forgalom! Az Internet forgalom 90%-a úgyis a spamekre megy el, miért nem becsüljük meg kicsit a maradékot?

Szóval tök jó lenne, ha a csomagkezelést átalakítanák ilyen xdelta-szerűre, és mondjuk csak a főverziókból jönne le teljes csomag (vagy ha akarom). Egyébként meg (ha akarom), csak a különbségek. A bináris patch-elés is rövidebb ideig tart egyébként az xdelta-val, mint leszedni a régi csomagot és feltenni az újat: 1,088 másodperc volt az xdelta patch <patchnév> <eredeti fájl> parancssal megcsinálni (az apt-get kb. 3-4 percet szöszölt - természetesen le kell futtatni ilyenkor szkripteket is, de azt is meg lehetne csinálni az xdelta után is).

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

7 komment · 1 trackback

Címkék: linux patch csomag ubuntu sávszélesség bináris deb diff xdelta

A bejegyzés trackback címe:

https://bagojur.blog.hu/api/trackback/id/tr351163031

Trackbackek, pingbackek:

Trackback: Cett blogja 2009.06.09. 05:42:57

Linux-os ill. web-fejlesztős hétvége, sok apróságBelefutottam egy nagyon-nagyon frappáns és teljesen jogos felvetésbe is a kedvenc blogjaim olvasgatva: Miért nincsenek különbségi csomagok?

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

cett · http://cettblogja.blogspot.com 2009.06.05. 16:15:41

hm.. elgondolkodtató.
ha tényleg ennyivel gyorsabb, mint az apt-get, én tuti szorgalmaznám.
valami ubi/rh fejlesztői fórumon nem lehet ezt nagyobb nyilvánosság előtt felvetni, hátha a 9.10-be még beférne kísérleti jelleggel? (hogy aztán a lts 10.04-ben stabil legyen)

csarlee 2009.06.05. 20:12:22

Lehet, hogy rosszul emlékszem de én anno használtam FreeBSD-t és ott volt valami deltás okosság mikor nyomot az embörfia egy portupgrade-t....

cett · http://cettblogja.blogspot.com 2009.06.07. 04:15:31

mondjuk ha ezt még variálnánk az apt-p2p -val.... :)
www.camrdale.org/apt-p2p/

zoltanh721 2009.06.07. 23:50:10

Teljesen igazad van, de nyitott kapukat döngetsz. A Fedorások már vagy egy éve használják a Presto szolgáltatás kiegészítőt a yumhoz, a 10-es Cambridge-ben már működik, de teljesen kiépítve csak a 11-es fogja használni. A letöltéseknél a fastestmirror pluginnal karöltve a Presto (deltarpm-ek alapján helyben építi újra az rpm-et) érezhetően gyors, mintha csak az alapot használnám...

zoltanh721 2009.06.07. 23:56:20

.. mármint gyorsabb mint az alap plugin nélküli letöltés. Egyébként az Ubisokat nem értem, vannak speciális csomagtípusok, pl. amelyekkel nem kell vacakolni, hogy ha valamit kihagynál, mert nincs benn a függőségekben, vagy pluszban szügséged lenne kiegészítőre a progihoz. Ezeket virtuális csomagoknak hívják, amik semmi mást nem tartalmaznak csak függőségeket. Így egész csoportosításokat lehet eszközölni a repoban, és elég csak ezeket a csomagokat meghívni... satöbbi, satöbbi...

bagoj ur 2009.06.17. 12:52:45

@cett: Ez az apt-p2p elég meredek húzás. :-) Az ötlet felvetésével kapcsolatban az a véleményem, hogy inkább le kellene programozni és úgy eléjük rakni, mert egy ötlet beböffentése majd a megoldás várása nem utal nagyon a konstruktivitás irányába. :-) Feldobom majd azért pár fórumon, hátha valakinek van affinitása.

@zoltanh721: Ez a Presto nekem kimaradt az életemből, mint ahogyan a Fedorat sem használtam még (ahogy írtam korábban valahol, mindenütt lassúnak és nagynak írják le, az én hardveremnek az Ubuntu is épp elég), de látszik hogy zseni megoldásaik vannak. Remélem, a Debian csomagkezelőjét is megreformálják majd egyszer, mert az RPM-hez képest tényleg vannak elmaradásai. De legalább kényelmes.

cett · http://cettblogja.blogspot.com 2009.06.18. 03:46:06

@bagoj ur: hidd el, ha delphiben OK lenne a megoldás, már megcsináltam volna, de annyira nem vágom a C-t, hogy full-ra megcsináljam. elsősorban felhasználója vagyok a linux-nak, mintsem fejlesztője.
süti beállítások módosítása