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.
OK.
- 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
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
