Ubuntu 13.04 gaat mogelijk xz-compressie voor packages gebruiken

Enkele ontwikkelaars die volgende maand gaan werken aan Ubuntu 13.04 hebben voorgesteld om alle packages van de Linux-distributie voortaan met xz-compressie te verkleinen. Xz zou data beter comprimeren dan het huidige gzip-formaat.

Bij het xz-formaat wordt het lossless compressiealgoritme lzma2 gebruikt, dat deels ook in 7zip is te vinden. Bestanden die met xz worden gecomprimeerd zijn compacter dan files die zijn verkleind met het aloude gzip-formaat, dat leunt op het deflate-algoritme. De extra benodigde processorkracht voor het uitpakken van xz-bestanden ten opzichte van gzip zou zeer beperkt zijn, terwijl ook de benodigde tijd mee zou vallen. Het inpakken van data duurt wel aanzienlijk langer dan met gzip, maar daar staat een gemiddeld 20 procent betere compressie tegenover.

Inmiddels is voor de aankomende Ubuntu 13.04 Developer Summit het idee geopperd om xz-compressie te gaan toepassen op de packages van het Linux-besturingssysteem. Hierdoor zouden niet alleen de images kleiner kunnen worden, maar ook het downloaden van losse packages zal sneller verlopen.

Volgens enkele developers is de tijd rijp om xz-compressie toe te passen op Ubuntu-packages. Zo heeft Debian plannen om ook dit compressieformaat te gaan gebruiken, ondersteunt de Debian-packagetool dpkg xz-packages en hebben de ontwikkelaars van Fedora zonder noemenswaardige problemen xz al in de praktijk toegepast op zowel rpm-packages als live-cd's. Indien Ubuntu 13.04 xz-compressie zal gaan toepassen, dan willen de developers ook alle bestaande packages tot en met Ubuntu 10.04 in dit formaat gaan aanbieden om zo upgrades te vereenvoudigen.

Reacties (81)

Was 7z geen kandidaat? Die is al bekend en heeft toch ook erg goede compressieprestaties.

7zip is een soort van container gebaseerd op het lzma-compressiealgoritme.

Nu staat er in de tekst:

Bij het xz-formaat wordt het lossless compressiealgoritme lzma2 gebruikt, dat deels ook in 7zip is te vinden.

Oftewel, dit formaat leunt op hetzelfde algoritme, maar dan versie twee. En voor 7zip is geen officiele Linux client, en xz blijkbaar wel Hmm, p7zip (de cli versie) is wel cross-platform. Ook zit de support voor xz al in dpkg, de Debian (en dus Ubuntu) package installer.

Dus, waarom zou 7zip gebruikt worden als dit beter of net zo goed werkt?

[Reactie gewijzigd door marcop23 op 14 oktober 2012 17:03]

Nog zo'n vraagje tussendoor: in het artikel staat in italics dat lzma2 lossless is. Is dat bij gzip ook niet het geval? Ik ben bijvoorbeeld nog nooit characters in textfiles of data in binaire files kwijtgeraakt door gzip compressie. Dus waarom dan expliciet iets zeggen over of lzma2 lossy is of niet?

Uiteraard, alle compressiealgoritmes die voor dit soort toepassingen relevant zijn zijn lossless.

gzip is net als lzma2 lossless. Of een compressiealgoritme lossless of lossy is, is best een belangrijke eigenschap en dat is vermoedelijk de reden waarom het genoemd wordt, al is een lossy algoritme gebruiken voor het comprimeren van willekeurige data als packages uitgesloten.

Datacompressie die niet lossless is, is niet geschikt voor installatiebestanden. Hoewel je compileren van programmacode misschien wel lossy compressie mag noemen.

Ik snap ook al niet waarom benadrukt moet worden dat de compressie lossless is. Dat spreekt namelijk voor zich.

xz staat tot gzip; als 7zip tot pk-zip staat.

xz (net zoals gzip en bzip) is puur een stream compressie en geen archive formaat (wat pk-zip, 7zip, rar, etc. wel is).

20% betere compressie... verbaasd mij dat er nog zoveel 'lucht' in ge-gzipte data zit. Klinkt wel als een zinnige verbetering.

tja, probleem is nog altijd dat je ook nog rekening moet houden met de tijd die het kost om uit te pakken. er zijn nog wel betere compressiemethodes dan die lzma2, maar die vergen nog veel meer rekenkracht, en een gebruiker gaat echt niet uren/dagen zitten wachten om een beetje data uit te pakken.

Daaar geloof ik niet zoveel van, volgens mij gaat het veel meer om het feit dat er een theoretisch maximum is aan informatie-dichtheid. iedereen die wel eens een JPEG oid probeert te comprimeren weet dat dat bijna niet meer kan. Of wie een zip-bestand omzet in XZ, of rar in bz2; veel verder lukt niet.

Allicht is het zo dat hoe dichter je bij het maximum zit, hoe meer moeite het kost. Dus voor de laatste 2% zou het idd teveel computer kracht kosten, maar als 3% meer comprimeren 'theoretisch onmogelijk' is, lijkt het me meer een theoretische beperking dan een computerkracht-technische.

Helaas is er wel ruimte. De stap wordt nu gemaakt om van hele bits naar gedeeltes van bits te gebruiken om data op te slaan. Een "e" zou dus dan ipv maar 1 bit in het beste geval bijvoorbeeld nog 0,23 bit kunnen zijn in de nieuwe situatie. Arithmetic compression biedt die mogelijkheid. Het punt is wel dat er een goede integer implementatie moet zijn van een methode die eigenlijk floating point georienteerd is om zo snelheid te blijven behouden op alle platformen.

De kunst nu nog is om de frequentietabel goed van single character model naar een dictionary model te krijgen waarbij zo efficient mogelijke verhouding wordt gekozen. Dit verschilt per source helaas. Wat je nu bij oa Debian-packages ziet (en dus ook Ubuntu) is dat bepaalde bestanden vooraf worden opgeschoond zoals PNG en JavaScript om zo compact mogelijk te zijn.

Maar dit hele verhaal is net zoals met bijvoorbeeld met SHA3 die nu gekozen is. SHA3 is niet gekozen omdat het de beste is wat nu mogelijk is wiskundig, maar wat het beste te implementeren is door iedereen. Dus door software ontwikkelaars, maar ook door chipbouwers en ook met embedded devices in het achterhoofd.

Los of XZ de beste keuze is voor nu, is echt een gelopen race aangezien de keuze al was gemaakt bij de ontwikkeling van Debian 5.0. Dit om met Debian 7.0 het af te hebben voor het brede publiek. Aangezien Ubuntu 13.04 na Debian 7.0 uitkomt is de keuze eigenlijk vanzelf gekomen, maar niet na z'n vijf a zes jaar minimaal aan voorbereiding. Dus verwacht geen veranderingen voor Debian 10.0 zou ik bijna willen zeggen ;-)

Ook met bzip2 kan je al veel beter comprimeren dan met gzip. Hiermee haal ik ook vaak 15-20% betere compressie.
Gzip is al erg oud en achterhaald, word tijd dat deze vervangen word.

bzip2 is ook al oud en eveneens achterhaald... comprimeert minder goed dan xz en decomprimeert langzamer. Volstrekt overbodig dus.
gzip heeft tenminste nog het voordeel dat het heel snel is, zowel met comprimeren als met decomprimeren.

Dit doet Debian ook al, toch krijgt Ubuntu de credit?

Debian KAN het, Maar doet het niet al standard in releases.

Ik weet niet of ik je comment helemaal kan volgen. Voor GNOME is een transitie gaande om het naar .xz over te zetten. Dus Debian DOET (om ook maar even in caps te communiceren) dit al om de 700 MB cdrom standaard uit te blijven geven met GNOME. Verder is het een release goal van Debian Wheezy om alles in .xz over te zetten.

punt is dat debian wat minder gebruiks vriendelijk is, en dus tweakersnet onwaardig... zo zul je ook pakketten als amahi (wat werkelijk een draak van een meuk distro is), wel in de lijsten vinden, maar zaken als clearos zentyal en uninvention niet.... die zijn namelijk niet NOOBIE genoeg...

en als je me niet geloofd kijk de meuk tracker er maar op na... en voor de wijsneuzen, JA ik submit geregeld van elke van deze 3 die ik tegen kom wel een wel een update.

Dus dan is het geen nieuws? En op Tweakers zit ook quantum mechanica news, wil je echt zeggen dat Debian zo moeilijk is? Debian is net zo makkelijk als Ubuntu, je hoeft alleen maar de nVidia driver bijvoorbeeld te apt-getten in plaats van dat het automatisch gaat. Dat is alsnog idiot proof. En aangezien Debian stabieler is, is het naar mijn idee meer noob friendly. Dat Ubuntu zo mooi en makkelijk is is gewoon marketing...

Maar goed, Fedora kwam eerder met het .xz idee en uitvoering. Dus de credit gaat naar hun in principe en als laatste naar Ububu.

Pak eerst de bloatware eens aan daar is meer winst te halen. Alleen een pakket als Openoffice gebruikt al 400 MB aan schijfruimte.

Het grootste deel daarvan bestaat uit woordenboeken in allerlei talen ten behoeve van de spellingscontrole. Bij de installatie kun je aangeven wat je daarvan wilt installeren. De eigenlijke programma's beslaan samen ca. 25 MB.

alsof dat pakket 400MiB gaat innemen bij een download ... . LibreOffice (wat in Ubuntu zit) neemt als installatie slechts een 180MB in met de huidige gz compressie en bevind zich ook niet op CD1. Het gaat hier om installatiepaketten, niet om om ingenomen schuifruimte na installatie.

Het hoeft niet het één of het ander te zijn. Met LZMA (xz) in plaats van DEFLATE (gzip) win je sowieso al 10-15% aan bandbreedte, los van wat je verder nog bespaart door grote packages zoals Open/LibreOffice uit te kleden. Maar zelfs als je die package uitgekleedt hebt, kun je winst behalen door een beter compressie-algoritme te gebruiken.

Dan heb je met Ubuntu de verkeerde distro, die verkiest namelijk gebruikers gemak boven footprint en zo. Als je liever een minimalistische distro hebt waar je zelf alles naar jouw zin kan aanpassen moet je iets als Arch Linux proberen.

Installeer je die toch niet.
Standaard heb je LibreOffice Tekstverwerker voor 22,3 MB geinstalleerd.
En Math, Presentatie en rekenblad zit er ook standaard op.
Genoeg keuze dus.
Edit: ik dacht dat het verschillende pakketten waren, maar zijn hetzelfde.

[Reactie gewijzigd door Soldaatje op 14 oktober 2012 17:42]

Die pakketten bedoeld hij dus met bloatware. Hij wil het waarschijnlijk helemaal niet standaard geïnstalleerd hebben.

Ik durf wel met enige stelligheid te beweren dat de gemiddelde ubuntugebruiker blij is dat ze word-documentjes kunnen openen zonder dag ze moeite hoeven doen

Dat durf ik ook wel met enige stelligheid te beweren, heb er zelf namelijk meerdere malen dankbaar gebruik van gemaakt.

Dan moet hij bij Arch Linux zijn en niet bij Ubuntu.

Mini ISO, geen bloatware: https://help.ubuntu.com/community/Installation/MinimalCD

tja, de voor de hand liggende vraag dan maar.. comprimeert het beter dan bzip2? anders zie ik het nut niet zo

Ja, het comprimeert beter dan bzip2.
Bzip kost waanzinnig veel cpu tijd en geheugen om iets te compressen.
En LZMA is ook fors (hoe meer geheugen je er aan toekent hoe beter het wordt), maar het gaat om het eindresultaat.
BZip2 is best goed, maar LZMA is een eindbaas.

xz decomprimeert ook sneller dan bzip2, niet onbelangrijk

Het internet ligt aan je voeten... zoek het uit (hint: ja)

precies, daarom vroeg ik het hier, op het internet

Als ze nu eerst eens Ubuntu stabiel maken. Ik probeer zo'n beetje om het jaar weer een nieuwe Ubuntu versie en ik heb het werkelijk nog NOOIT stabiel gezien.

Verschillende laptops & PC's. Zodra je een 2e scherm hebt en je wil 3D acceleratie dan moet ik helaas constateren dat heel veel schermen & apps fouten hebben.

Versie 12.04 wilde niet eens starten vanaf mijn Toshiba L650-1NC. Grub geeft een melding dat het "Out of diskspace" is.

Fedora & Ubuntu zijn niet te gebruiken. Nee dan liever Debian Stable, het is oud maar het is tenminste fatsoenlijk getest.

EDIT: Natuurlijk zijn er weer genoeg wie natuurlijk zeggen dat ze nergens last van hebben. Zelf vind ik dat ongeloofwaardig want het is niet alsof ik dit op enkele PC's geprobeerd heb.

[Reactie gewijzigd door Anoniem: 461593 op 14 oktober 2012 19:08]

Tja, ik heb het ook op vele systemen geprobeerd, desktops, laptops en servers. Nergens last van is een groot woord, maar ernstige problemen ook zeker niet.

Met name op mijn Macbook Pro draait Ubuntu ICM met de binaire Nvidia-drivers enigszins onstabiel, het scherm wil wel eens vastlopen waarna je dan wel via SSH de X-server kunt rebooten, dan wel een harde reset kunt doen. Sinds ik de Nouveau drivers gebruik werkt alles als een zonnetje.

Het werkt niet perfect, nee. Ik heb echter met Ubuntu alleszins minder problemen dan ik ooit met Windows gehad heb, dat is een ding wat zeker is. En dat is wat mij betreft al een hele prestatie. Zeker als de mensen van Nvidia er echt eens hun schouders onder zouden zetten schieten we flink wat op.

Ongeloofwaardig! Sorry hoor maar als je hardware goed is en goed is ingesteld dan werkt Windows stabieler dan Ubuntu. Ik beheer op mijn werk 500+ PC's en geen enkele PC heeft problemen met Windows (op de PC's met een defect na natuurlijk). Ubuntu daarentegen, we hebben vaak genoeg gepoogd Ubuntu te gebruiken op oude afgeschreven systemen om deze een 2e leven te schenken. Als het daar al niet fatsoenlijk op werkt dan geef ik weinig kans op nieuwe systemen.

Ik vergeef het een besturingssysteem als het niet werkt op een PC waar het niet voor ontworpen is. Kijk als je een spiksplinternieuwe Core I7 koopt en je probeert Vista of zelfs XP te gebruiken dan vind ik het niet zo gek dat het fout gaat. Zelfde geld voor Ubuntu. Ik vind het niet erg als moderne hardware nog niet volledig ondersteunt word. Ik kom op Windows PC's of Apple systemen zelden tot nooit incomplete schermen tegen. Rare opmaak fouten waarbij bijvoorbeeld de progresbar buiten het schemr valt. Problemen met het domweg niet willen opstarten vanaf de HD, ook al doe je een cleaninstall. Dat zijn toch echt problemen die je alleen met Ubuntu ziet.

Problemen in Windows komen vaak door mensen die denken een PC te kunnen bouwen door zelf de onderdelen bij elkaar te zoeken. Vaak begrijpen mensen bijvoorbeeld niet dat je compatible geheugen dient te kopen voor het MB dat je gebruikt en dat wanneer je alle geheugensloten gebruikt, je soms een dip in de voltage krijgt. Windows heeft alles in zijn kernel gebakken. Linux niet, daardoor zal Windows bij defecte of slecht werkende hardware eerder op zijn gat gaan dan Linux.

Oorzaak ligt dan in ieder geval niet bij Windows maar toch bij slecht functionerende PC's.

Ik zie over het algemeen dat Linux juist beter werkt op nieuwe hardware dan WIndows. USB3 bijvoorbeeld werd ook eerder ondersteund door Linux net als een hele hoop andere nieuwe technologiën. Drivers voor nieuwe hardware zijn vaak binnen notime geintegreerd in de Linux-kernel terwijl dat voor Windows zelden tot nooit gebeurd, je moet altijd in heel veel gevallen nog bij de leverancier langs om drivers te downloaden.

Vind je het gek dat als je Ubuntu gaat installeren op oude, afgeschreven systemen dat je tegen problemen aanloopt? Voor hetzelfde geld is het geheugen brak, de processor losgekomen of weet ik wat je allemaal tegen kan komen.

(K)ubuntu werkt als een trein op mijn Core i7 PC en deed dat vanaf het moment dat ik de hardware thuisbezorgd kreeg. Met Windows echter vele malen meer problemen gehad, met name met de onboard netwerkkaart waarvoor ik eerst een driver moest installeren terwijl Ubuntu deze out-of-the-box ondersteunde en instabiele ATi Radeon drivers die leidden tot visuele corruptie en vastlopers.

Als gezegd, op mijn MBP heb ik wat problemen met de grafische driver op Ubuntu gehad, maar sinds ik de open source nouveau driver gebruik heb ik daar in ieder geval geen last meer van. Windows draait er ook op, maar de performance daarvan is dan weer niet om over naar huis te schrijven. Bovendien wil die nog wel eens de controle over het touchpad kwijtraken waarna een reboot alles is dat helpt.

Granted, heel veel van alle problemen leunt op device drivers waarop zowel Microsoft als de Linux-community niet volledige invloed hebben. De schuld zal dus in veel gevallen feitelijk bij de leverancier van de hardware gelegd moeten worden. Neemt niet weg dat mijn ervaring met Ubuntu vele malen beter is dan met Windows.

Windows en Ubuntu falen allebei op een andere manier, dat moet niet vergeten worden.

Ubuntu - en meestal Linux - wordt door de loop van de tijd vaak beter, ook naarmate je er meer moeite in steekt, Windows slechter.

Bij Windows is het voornamelijk het gebrek aan centraal update-management wat het tot zo'n rampzalig OS maakt. Al die applicaties installeren hun eigen update-service, en die maken het systeem dikwijls traag als dikke stront. Sterker nog: Alle applicaties denken dat ze de baas zijn. Het ecosysteem is totaal vernaggeld: Omdat de instellingen in Windows zo verstopt zijn / niet gebruiksvriendelijk, download iedereen een applicatie om dat te doen. En die nemen altijd weer een hoop adware en troep mee, wegens gebrek aan software-vergaarbak (of de daarvan afgeleide AppStore).

Wat ook enorm rot is in Windows, is dat zelfs als er nog zat RAM over is, het OS toch de hele tijd op de harde schijf wil swappen. Hierdoor is de PC van mn ouders simpelweg onbruikbaar, en net een laptop voor me gehad die door de vele services / processen erop helemaal 'volgelopen' is.

Vervolgens moet je dan gaan uitzoeken welke processen nuttig zijn en welke niet, en dat is allemaal een behoorlijk gedoe. Maw; Het grootste probleem is bij Windows dat er altijd een rits programma's nodig is Windows in toom te houden / managen, dan zijn er weer per 2 programma's weer 3 andere nodig om die weer te managen en dan komt de hele boel tot stilstand.

Laatst ook nog lang bezig geweest met 2e scherm met Windows: Het is inderdaad waar dat je er met Linux al snel 3 uur mee bezig bent, maar bij Windows kostte het me ook 1 uur.

Die bloatware-problemen zie ik bij Linux nooit, en als je het hebt gooi je zo een hele rits programma's weg of gooi je ze uit de opstartlijst.

Wat ik bij Linux wel vaak ben tegengekomen (Arch / Gentoo) zijn vicueuze faal-cirkels die bijna niet te doorbreken zijn (er zit een bug in A die je via B kan oplossen, maar in B zit ook een bug waarvoor je eerst A moet oplossen), inderdaad problemen met display-drivers (sleep werkt bijv. niet), software die het vaak niet doet, lekkend RAM geheugen in Firefox (maar dat gebeurt net zo hard in Windows 7 soms), FF-plugins die om de haverklap crashen, soms wat foutmeldingen omdat bepaalde programma's niet installeren, dat soort spul.

Maar als het eenmaal werkt, werkt het goed en blijft het werken. Kan je rustig 4 jaar gebruiken zonder defragmenteren, registry-cleanup, AdAware, SpyBotSD, urenlange "bloatware-verwijder'sessies", virusscanner en al dat soort Windows-onzin die me tientallen uren van m'n leven gekost hebben.

[Reactie gewijzigd door kidde op 14 oktober 2012 23:52]

en dat kun je staven met bronnen... ik draai al jaren met zowel ubuntu als windows... en onder ubuntu heb ik toch duidelijk minder problemen, en dat is zowel op een laptopje acer, als op het nieuwste spull van dell en hp..

ik herken dan ook veel uit het verhaal van kidde, dat is ook een van de redenen dat ik bij ubuntu lts releases blijf zowel met servers als met desktops.. de enige uitzondering wil nog wel 's een laptop je zijn - maar dan ook alleen als ik tijd heb om te spelen... gaat het ding mee op reis oid dan toch een image van de laatste lts erop...

Zelf vind ik dat ongeloofwaardig want het is niet alsof ik dit op enkele PC's geprobeerd heb.

Het is het ene anekdotische bewijs tegen het andere. Jouw bewering dat Ubuntu onbruikbaar zou zijn vind ik juist weer heel ongeloofwaardig. Ik kan me niet voorstellen dat al die mensen die Ubuntu downloaden het nooit zouden kunnen gebruiken.

Ik heb zelf de ervaring dat zowel Windows als Linux goed hun werk doen. Linux herkend de hardware vaak beter tijdens installatie, terwijl je bij Windows op zoek moet naar drivers. Als je oudere hardware hebt, waarvoor geen drivers meer zijn in Windows, dan kan je het meestal definitief vergeten.

Omgekeerd heb je onder Linux een hoop gedoe als je hardware nog niet ondersteund wordt of nog volop in ontwikkeling is.

Het komt bij beide terug bij ondersteuning door fabrikanten. Heel vervelend dat iets niet goed werkt, maar ik vind niet dat je de os ontwikkelaar daar de schuld van kan geven. Maar gek genoeg zit daar een hele rare spagaat. Onder Windows wijst iedereen wel naar de slechte driver support, terwijl het in Linux vaak wel bij het os wordt gelegd.

En dat Debian beter getest is lijkt me logisch. Je kiest dan tenslotte voor een distro die niet, zoals Ubuntu, kiest voor bleeding edge. Dat is iets wat je mee moet nemen in je distro keuze. Wil je het nieuwste van het nieuwste op gebied van drivers en software, of kies je voor ouder maar vertrouwder? Wederom, dat moet je niet Linux voor de voeten gooien. Dat moet je eerder jezelf aanrekenen.

Mooi als ze inderdaad gaan overstappen naar xz compressie. NOG mooier zou zijn als ze alle executables eerst eens door UPX heen halen. Dan heb je en nog betere compressie en je hebt er na installatie ook nog plezier van.

[Reactie gewijzigd door Killemov op 14 oktober 2012 23:19]

Ooit eerder was er een discussie over Ubuntu images te compressen omdat we dan nog langer op de 700MB konden blijven.

rulus schreef op zondag 11 maart 2012 @ 13:40
Gzip heeft een "--rsyncable" optie die rsync-friendly zip's maakt (die dus door rsync kunnen geüpdate worden, waardoor er enkel hetgeen veranderd is in de zipfile overgezet moet worden).

Xz heeft die optie (nog) niet, waardoor als er iets aan het bestand verandert het door rsync helemaal opnieuw gekopieerd moet worden.

Althans, dat is wat ik ervan begrijp.

--------

Ertepeller schreef op zondag 11 maart 2012 @ 14:12
Je hebt gelijk, ik zat net dit verhaal te lezen waar uitgelegd wordt hoe rsyncable werkt.
Dit wist ik nog niet: nooit te oud om te leren dus
Wel jammer, xz is verder een perfecte zipper, iets anders gebruik ik niet meer.


Dit vond ik nog op een Ubuntu manpage:

Compressed output may vary
The exact compressed output produced from the same uncompressed input
file may vary between XZ Utils versions even if compression options are
identical. This is because the encoder can be improved (faster or
better compression) without affecting the file format. The output can
vary even between different builds of the same XZ Utils version, if
different build options are used.

The above means that implementing --rsyncable to create rsyncable .xz
files is not going to happen without freezing a part of the encoder
implementation, which can then be used with --rsyncable.

[Reactie gewijzigd door afraca op 14 oktober 2012 23:50]

Ik vraag me af waarom ubuntu bijv. nog niet met delta updates werkt? Dat lijkt me veel meer impact hebben?

Voor fatsoenlijk gecomprimeerde data is een delta vziw totaal nutteloos.

Wie twee lange randomgetallen neemt, ontdekt al snel dat de 'delta' om van het oude naar het nieuwe getal te komen, bijna net zo groot is als het nieuwe getal zelf.

Dus van het oude bestand
o 0001000101010011101 naar het nieuwe
n 0110101000101010001 zou men een delta kunnen verzinnen
d 1000010010000110010

en alleen als de delta korter is dan het nieuwe getal zelf, heeft het zin om een delta te gebruiken ipv. de nieuwe data zelf.

Nu is het geinige, dat de "hoogste informatiedichtheid" exact dezelfde eigenschap heeft als random data, dus als twee bestanden maximaal zijn gecomprimeerd, is de delta net zo groot als het nieuwe bestand zelf.

Een delta heeft dus waarschijnlijk geen nut als een goed gecomprimeerd bestand vervangen moet worden door het andere. Een delta heeft wel zin als:

1) De comprimeer-algorithmes niet perfect zijn (en dat zijn ze nooit helemaal),
2) Er een groep van gecomprimeerde bestanden is waarvan sommigen niet veranderd zijn,
3) men te maken heeft met bestanden die niet gecomprimeerd zijn.

Dan is de miljoen dollar vraag, of het nuttiger is om niet gecomprimeerde bestanden met delta's te gebruiken (voor bestanden in /etc of verschillen in twee bijna gelijke xml-bestanden zou dat erg goed werken), en de delta's zelf kunnen weer wel gecomprimeerd worden. Of om toch gecomprimeerde data te versturen. Volgens mij zijn voor allebei de methoden situaties te bedenken dat die het meest geschikt zijn.

Stel ik heb een programma met 4000 png plaatjes. Ik wijzig 1 van die plaatjes en genereer een update. Bij een delta update ziet het systeem dat slechts 1 file is aangepast en de andere 3999 worden genegeerd. Resultaat een update ter grote van 1 gecomprimeerde file.

Bij een non-delta update worden alle 4000 png plaatjes (en de rest van het programma) gecomprimeerd. Deze update is dus grofweg 4000 keer zo groot.

Een Delta update is dus zeer zinvol aangezien alle ongewijzigde data niet in het delta package zit maar er aangenomen wordt dat je die data al hebt. Enkel gewijzigde data wordt verstuurd.

In gevallen waarin je kleine aanpassingen aan een groter geheel doet is een delta update zinvoller dan het verzenden van de complete informatie. Het grootste probleem van Delta updates is dat je dus niet zomaar een nieuwe versie kan downloaden maar alle tussenliggende versies tussen de huidige en gewenste versie moet hebben. Dat maakt het gebruik van delta updates ingewikkelder dan het gebruik van volledige updates.Ook voor situaties waar grote veranderingen worden doorgevoerd kan een delta package niet de beste oplossing zijn. Maar bij de meeste programma's zijn de aanpassingen klein (bug fixes) en zijn delta updates dus zeer effectief.

[Reactie gewijzigd door humbug op 15 oktober 2012 06:57]

In dit geval zou je het in theorie kunnen combineren.

Lokaal in /var/cache/apt kan je oude installatiepackages vinden. Je zou dus delta-packages aan kunnen bieden met alleen de gewijzigde bestanden en een configuratiebestand dat aangeeft hoe de client uit een oude package en deze deltapackage een nieuwe package moet maken.

Je zou zelfs delta-bestanden in deze delta-packages kunnen stoppen zodat de client met een delta-update en een oude binary de nieuwe binary kan bakken. Zo heeft de delta dus geen last van de compressie.

[Reactie gewijzigd door Mentalist op 15 oktober 2012 07:17]

En als je 'apt-get clean' doet zijn deze weg. Ik zie veel meer in de techniek zoals humbug beschrijft: een delta- package maken van alleen de gewijzigde bestanden.

Overigens, een package met 4000 png plaatjes wordt niet (ook niet grofweg) 4000x zo groot. In ieder geval de bestandsheader is al hetzelfde en zo zal er waarschijnlijk wel meer data overlap hebben, waardoor het beter comprimeert. En ook het compressieformaat voegt een header en andere overhead toe.

[Reactie gewijzigd door Jaap-Jan op 15 oktober 2012 14:16]

Waarom niet iets nieuwer als PAQ?
Die heeft zelfs betere compressieratio's en heeft al diverse prijzen in gewacht geslepen.

Misschien omdat PAQ (volgens diezelfde wikipedia pagina) welliswaar bijna een factor 2 meer compresst dan bzip2 op plain text, maar er wel 170x zo lang over doet en 231x zo veel geheugen nodig heeft. Dat zorgt ervoor dat je installatie ipv 20 minuten een paar dagen duurt, en je PC's met minder dan 2 GB geheugen kan vergeten.

Nou is plain text niet hetzelfde als binaries, dus de waarden zullen niet helemaal overeenkomen, maar de ordegrootte verandert denk ik niet.

Tekst is geloof ik ook relatief makkelijk te comprimeren, dus het verschil in compressie zal tussen de twee algoritmes minder groot zijn in normale situaties. En (de)compressietijd is inderdaad een belangrijke factor in dit soort situaties.

Compressietijd is in deze situatie niet van groot belang, decompressietijd echter wel. En aangezien het merendeel bestaat executable code lijkt mij juist het gebruik van een compressor zoals UPX een goed plan.