[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Size matters. Debian binary package stats

Steinar H. Gunderson wrote:
On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:

I've run some scripts to find out the size of binary pakcages in debian
and how theycould be made smaller, here's the results:

My comments are about the same as on IRC:

  - Disk space is cheap, bandwidth is cheap.
In many parts of the world.  Nos so much in others.

  - CPU doesn't grow nearly as fast as those three.

In 1995 I had a Pentium 166 and a 56 kbps modem. Now, today the fastest CPU you can get from Intel is 3.6 GHz. However, the fastest dial modem you can get today is still 56k (remember that the majority of people worldwide are still on dial up). That means that for a 2200% increase in the maximum speed of a consumer-grade processor, there has a been 0% increase in the maximum speed of a dial up modem. A similar phenomenon has occurred for disk space.

  - Human power grows even slower.
  - The administrative overhead of transitioning to a new .deb format
    would be huge.
This is quite true.

Thus, anything sacrificing lots of human power and CPU power to save on disk
or bandwidth just doesn't make sense.
That really depends. I routinely see posts on debian-user asking about how to use a friend's fast DSL or cable connection to download packages to install on a Debian box that has only dial up access to the Internet.

I think that the biggest problem is really updates. Packages like XFree86 (no X.org) and Openoffice.org are *huge*. A simple security update to one of those packages causes all subordinate binary packages to get a version bump. That means that if there was a bug in the XFree86 driver for video card foo and I use video card bar, I still get download a many dozens of MB update. IIRC, something similar caused a major strain on security.debian.org shortly after the Sarge release.

If we focus our energy on anything to reduce bandwidth, it should be making apt/dpkg smart enough to only need to grab the single changed binary package out of the 50 produced by source package foo, or maybe to employ and rsync-like approach.


Roberto C. Sanchez

Reply to: