John M McIntosh wrote:
(a) The OLPC actually uses a compressed file system already, because of that Published Sophie Books for the OLPC use a zipped file with no compression. The zipped file will live in the journal at some point.
(b) Does setting oops values back to start of zero actually make it more compressable, versus say a start value of 0x00004000?
We are not actually setting the oops back to zero, but back relative-to-zero, They are just numbers, just different numbers. I would not imagine that this has any effect upon the compressibility of any single image. However diff algorithms working with two or more images are more likely to see that much of a saved image is the same as the last time it was saved. From the little I know it seems that the OLPC file system (as well as mercurial binary storage) is designed with this in mind.
Indeed you make a good point, if we can pick a good number that runtimes can use without traversing the image then great. What number should it be?
Since OLPC applications have a virtual linux box to themselves can we just pick a number that suits us/them?
Otherwise the computational energy used to traverse the image is technically wasted.
(c) ittle/big endian? OLPC is based on the geod aka intel instruction set.
So it looks like little-endian is the favoured choice for the normalized image.
best regards
Keith