On Sat, Feb 23, 2013 at 07:38:05PM -0600, Bruce Dubbs wrote: > > Minimal maintenance (fixing broken things) is not the same as optimizing. > > I have considered removing compressdoc because I think it pretty much > useless, but since it works, it's more effort to remove it than to just > leave it. Admittedly removing it would only require removing one line > from the xml. > > Armin, Randy, Ken, what do you think? > > -- Bruce > I remember I suggested something for a much earlier version of the script, back when (I think) Mark Hymers was in charge of BLFS. In those days my LFS box was a K6-2 (i586) and I guess my drive was probably 20GB - with several systems and /home in that space. But I haven't felt the need to save space to that degree for many years.
LFS is targetted at x86 - almost everyone can use large disks, even my oldest motherboard [ via SATA, can only access SATA-1 ] has several hundred GB - probably 320GB. People with only IDE drives (if they still build BLFS on them) probably have less space, but are more likely to have a lack of CPU power to decompress the pages. I understand people wishing to save space, particularly on old hardware, and I also understand the desire to have access to man and info pages in an under-endowed system : both of those situations may be more applicable to clfs. But I think that the savings from stripping files are considerably greater, and I'm unconvinced that .xz *de*compression is particularly fast (from memory, sitting waiting for a manpage to render can be extremely annoying). For BLFS I have no objection either to keeping the current version, or to deleting it, and my only objection to adding .xz compression is that I don't think the change is particularly beneficial. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
