On Wed, 2009-08-05 at 05:28 +0200, Roland Mainz wrote: > Hi! > > ---- > > Since a while I am thinking how we can handle space problems on the > LiveCD without getting a performance penalty caused by compression for > normal systems. > The random thoughts on the problem look like this: > 1. We need to conserve space on the LiveCD as much as possible > 2. We mainly try to use compression but decompression needs lots of CPU > time > 3. The use of filesystem-based compression is usually inefficient > compared to application-specific compression (for example the FreeType2 > library supports transparent compression of font files which is usually > more efficient (e.g. memory no longer needed is free'ed and doesn't use > up filesystem cache pages) than using ZFS with GZIP) > 4. Other methods may be nice to be considered, for example we have > /usr/bin/shcomp as method to precompile shell scripts into binaries > (which saves CPU time, memory and improves performance and reduces > startup time) > > These items leads to an old idea: > What about allowing one file entry in IPS database to be represented by > multiple different "mutations" of a file, e.g. one and the same source > file is "mutated" into different formats depending on platform > attributes. > > Example 1: > We have a font file called "songti.ttf" (large chinese font) which is > quite large but the size is only a problem when we're low on disk space: > 1. The source file is called "songti.ttf" > 2. The "mutation" for LiveCD targets would be gzip compressed, e.g. > "songti.ttf.gz" > 3. The "mutation" for embedded systems with a minimum of disk space > would be bzip2-compressed, e.g. "songti.ttf.bz2" > > Example 2: > There are _lots_ of shell scripts in /lib/svc/method/ which could be > greatly reduced in size by compiling them. Also we can divided these scripts for x86/64 and sparc versions - now all stuff on one > Quick comparisation shows this: > $ du -ks compiled > normal > > 420 compiled > 1464 normal > e.g. there is a ~~1MB difference between both directories. > > The concept of adding "file mutations" unfortunately has one flaw: > - If the file name changes (like in example 1 (which is unavoidable > since the FreeType2 code mainly looks at the file name and not file > signatures)) other files (in the fonts case the "fonts.dir" files) > need > to be changed, too (which creates dependicy trees or even graphs) ... > > ... comments/rants/ideas/etc. welcome... > > ---- > > Bye, > Roland >
-- ::alhazred _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
