Zisofs provides much larger files to be downloaded into desktop; for example, cramfs has 16MB file size(compressed) but zisofs produces OpenOffice2.0 at a compressed size of 120.2MB and when running produces 242.6MB of application.
Thus the klik system enables three compressions in LiveCD, cloop, cramfs, and zisofs. More
may be possible.....
Archlinux could be enhanced by reducing the installed application size with this klik system from Knoppix.
It works in arch!
]]>In addition, the "klik" feature seems to be present but cannot verify its operation until the " atekon.de" server is again operating.
This system (Klik)permits downloads of applications while operating with LiveCD and running the downloaded image files.
This "klk" system utilizes a "second compression" on the LiveCD after the CD is booted...an "overlay" mechanism..
The "readahead" download is an activity generated in Japan and available via download from url's in the forum "Ideas" .
The "klik" system has been found to operate in another distro...PCLINUX OS pre8 at this writing.
The "klik" system extends the limited capability of Live CD's to a great extent, limited only by the available downloads in .cmg format ( and a server having enough bandwidth!!...better to have more servers!!!!).
Give the readahead idea a shot!
]]>The referenced .cmg files are added to a burn of KnoppixLive CD(no change to it) with a modified mkisofs command and the .cmg files are 50% pre-compressed and are burned on the DVD after the Knoppix data.
This enables a fuller use of the media space on a given disc.
The cmg files are accessed by command line. The Knoppix is still 680+MB and bootable. The remaining DVD space up to 4.4GB is useable by .cmg files.
I haven't tried the system but understand that it does work.
The Knoppix and .cmg files are placed in a common file to be processed by the mkisofs procedure before a k3b burn to DVD as I understand the system.
The original KnoppixLiveCD format is not disturbed (same compression as before) and a second series of compressed files(.cmg) are added. Thus a second compression system is initiated on the same DVD. Result is two compressions on the same media.
The DVD+R/W would allow experimenting with .cmg with a KnoppixLive CD.
I would expect the same system to apply to other LiveCD's.
...........................................................................................................................................
Some software is required to prepare the .cmg files of applications to be provided by .cmg.
..........................................................................................................................................
EDIT: Some Live CD's are only 20 to 50MB in size. Adding .cmg files would enhance the use of CD burn space as well. Not limited to DVD as far as I can tell...
To longhornxtreme:
Making a bigger local dictionary of patterns doesn't improve the overall compression.
The compression ratio is about 50% with fast compression methods, and closer to 30% with slower, "better" ones, depending on the data.
]]>The technique allows the use of the full DVD capability of 4.4gb while retaining the original KnoppixLive CD (680+MB) capability and making the added files accessible as well.
The .cmg files are pre-compressed and the mkisofs command line data is modified to accept the two modes. Not all programs can be modified to .cmg format according to the data discussion.
]]>I've always wondered by increasing the size of the compression program locally i.e. storing more patterns locally would help decrease file sizes....
]]>the mathematical theory behind compression is this - it takes repeating patterns and basically tags them... stores the pattern once and replaces the pattern with the tag - of course this is a simplification of the process, and some algorithms are much more indepth (bz2).
The thing is that once a repeating pattern is removed the only way that pattern will show up again is coincidence... it wont be repeating anymore, it will be random... so compressing a compressed archive will be insignificant...
by example:
if compressing a.tar to a.tar.gz shrinks the file size by 80%, the next run to a.tar.gz.gz will shrink the size by maybe 5%... and after that probably nothing will change.
Also, with multiple compression you run the risk of data corruption.. and REPEATED corruption due to what was explained above....
To answer the question, no there is absolutely no way in hell a 2GB archive could be compressed to 800MB with mutliple compression (however a single run of a very very good compression algorithm could do it)
]]>Edit: readon......................
]]>