On Dec 17, 2007 7:51 PM, Emmet Hikory <<a href="mailto:emmet.hikory@gmail.com">emmet.hikory@gmail.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Bandwidth will always be location dependent, so package size related to bandwidth is not an easy item for discussion. Smaller is nice, but for some it doesn't matter very much, as their connections are either fast enough that it's not important, or slow enough that they download overnight (or otherwise deeply backgrounded) anyway. Processor speed is similarly variable. Not that benchmarks (1) mean much, but the interesting point is only relative time for decompression, as for most packages the IO load delay is concentrated on unpack rather than decompress (and further that packing happens once per revision per architecture, and unpacking happens a lot). Is 3-5 times as long acceptable? Maybe. Is 10-15 times as long acceptable? Probably not (so we shouldn't use bzip2 unless it gets a lot faster).</blockquote></div> If the decompress time isn't a huge factor to begin with and most of the install time is spent putting things in the right place during unpack, do we really need to worry too much about decompression time? We know for sure that in a lot of areas broadband isn't available or at least isn't practical. There are DVD sets that people can share to get everything from the repo, but those don't include security updates, so those still would be problematic for users. If we can make the updates' downloads smaller and faster, updates become more accessible to people in those low-bandwidth areas. -- Mackenzie Morgan Linux User #432169 ACM Member #3445683 <a href="http://ubuntulinuxtipstricks.blogspot.com">http://ubuntulinuxtipstricks.blogspot.com</a> <-my blog of Ubuntu stuff apt-get moo