Thanks for pointing .cmg file out for me.

I probably can understand the convinience argument for putting .cmg files on a DVD but I'm not buying the efficiency argument untill somebody show me a benchmark results.

Both cramfs and cloop do decompression "on-the-fly" they just do it on different levels - one on File System level, another on a block
level. Note, that what they decompress still lives on DVD for both of them even after they are mounted.

When cloop is mounted it reads all offsets of compressed blocks into memory therefore finding what to load from the DVD does not take much time - lookup in this translation table what to load, make corresponding request to DVD driver, and then send back to kernel decompressed data. As a result you would spend as much time looking for an application and loading it for a big cloop image as you would do for a small one.

As for .cmg files... It's very interesting approach, I admit it. Especially, for small programs depending only on their own resources and on core components. But I wonder how interdependency could be solved with it. What would .cmg file do if it needs something from another .cmg? Bundle all necessary files in its own .cmg? Look for another .cmg? And what if you start program twice? If you click the same .cmg you will spend another /dev/loop. Do you ask users to start .cmg differently if it is already started?

But, I'm sorry... This is not a .cmg discussion board.

Thanks,
Igor