diff file to update porteus versions?

[Tonio]

Dear fanthom, brokenman, et. all

I had seen in old slax site a way to update between slax releases a diff file/ or similar. This way you download a small file and run diff command and you old file/version of OS became new and you did not have to download whole ISO to your machine. This of course was provided for folks who had slow internet connections or quotas on their ISP. Would you consider an idea like this for Porteus?

ftp://ftp.slax.org/SLAX-6.x/bsdiff/

for reference.

[Hamza]

That's a good idea

[82issa]

This is a wonderful idea. I wonder tho how large the files would be. Reason being. The majority of what is on the iso is "modules.xzm". These are compressed mini file-systems with a couple tools and such. Changing just a couple files within that can result in a huge difference between the 2 versions of .xzm resulting a rather large xzm. But not 100% sure on the size of the diffs when do this to a xzm it might be the same size as the xzm, only cause the compression algorithm is gona have a very different result even if we change just one file within that. The non compressed files would work great on. I wont have time to test this till I get home I will post up a report.

[Ahau]

There are a couple things we could do -- If there is a small update, it could be issued in the form of a patch. The updated files would go in a module, which could be downloaded and added to the /porteus/modules folder, so long as the first character in it's file name was higher than 0, it would overwrite the files that need to be updated (but would not change anything from rootcopy, /modules folder, or magic folders, so it would be painless for the user), or, we could have a compressed file that could get expanded and used a la update-module to update the actual files and recompress the base modules.

For major updates (updated program versions, etc.) downloading the whole ISO again would probably be better (less buggy). Of course, that's more difficult for dial-up users.

[brokenman]

For smaller updates 'between releases' i think it would be much easier to just stick the new file into rootcopy. If an update is for a text file in the BOOT or PORTEUS folder it would be easier just to replace it with the updated version. If the change is inside a module, then the user would need to unpack, edit and repack the module .... or a script would be written to automate it. Much easier to just dump the update in the rootcopy and meld it at next release.

I had toyed with the idea of using SVN to supply a script that updates Porteus on the users machine ... but the reality is that the user still needs to download a 'whole heap' of packages and files from a slackware repo anyway. Probably better, and easier if they just downloaded one single compressed ISO which a maintainer has assembled and tested. Less can go wrong.

[82issa]

Ok update I had a chance to mess around with this.

Code: Select all


5835   May 24 23:56 dir.changes        #### used regular diff here for catching locals and such text content files.
640770 May 24 23:54 n230*               #### no thrills compiled executable nano2.3.0
454656 May 25 00:21 n230.xzm         #### module of the nano 2.3.0
640994 May 24 23:54 n231*               #### no thrills compiled executable nano2.3.1
475136 May 25 00:21 n231.xzm         #### module of the nano 2.3.1
13355  May 25 00:19 nupgrade.p       #### bsdiff n230 n231 nupgrade.p
427255 May 25 00:22 nupgrade.zxm.p###  bsdiff n230.xzm n231.xzm nupgrade.xzm.p

640994-640770 = 224 byte size difference with 19,190 bytes patch < 4% difference in the data between just the executables.
475136-454656 = 20,480 byte size difference with 427,255 byte patch 89.9% difference in the data between just the modules.


I used the bsdiff 4.3 for this info. Just did standard config with no optimizations.
So in summary I don't think the would be reason enough to go through all this work, Just to save a 10 % bandwidth there. I think it would be well worth the 96% saved by doing the specified files. But the bulk of "porteus space consumers"are these xzm's. I love my xzm's tho. I think if it we were doing this with uncompressed filesystems it would be very reasonable.