Rumor has it that Jeremy Huntwork may have mentioned these words:
Alexander E. Patrakov wrote:
2) Compression quality:
Method 1: zlib, applied to specially-designed filesystem. No possbility
to plug in a better (e.g. LZMA-based) compressor.
Method 2: zlib, applied to ext2 filesystem. Compression is a bit worse
because ext2 inodes have large size and no duplicate file detection
exists. If we move from zisofs to cloop, compression may become better.
I would like to see this quantified. The ability to plug in a another
compressor is nice, however, it's not very useful if the achieved
compression is the same or worse as what we currently have with squashfs.
Not necessarily, IMHO. Personally, a slightly (2-4%) worse compression
factor might be preferable if the decompression speed increased 20-40% or
more. It's all a matter of where one's priorities lie, and at least for
now, we have room to spare on the CD.
Granted, I'm the village idiot around here, so take all above with a grain
of salt... ;-)
On a totally different and wacky tack, has there been any tests done
with... say... building all the apps for the LiveCD with dietlibc or uclibc
- that would make the apps themselves much smaller and take less RAM -- but
-- would those apps still be viable as a platform to build the normal
glibc-based libs & apps?
Just a (prolly stupid) thought...
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger -- SysAdmin, Iceberg Computers
_±±_ [EMAIL PROTECTED]
(©||®) If at first you don't succeed, nuclear warhead
_)(_ disarmament should *not* be your first career choice.
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
