Re: Size matters. Debian binary package stats
"Steinar H. Gunderson" <email@example.com> writes:
> 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.
Spare disk space isn't available to add amd64 to mirrors.
Spare bandwith isn't available to add amd64 to mirrors.
Users disk space might be cheap but they have the unpacked binaries
Users bandwith might be cheap but often very limited due to
infrastructure. A lot of analog modems are still out there.
> - CPU doesn't grow nearly as fast as those three.
Any arch where cpu speed still grows has plenty of cpu time to spare
anyway. Only old archs (and the embedded stuff) have cpu problems. But
do they want a 200MB OpenOffice?
> - Human power grows even slower.
> - The administrative overhead of transitioning to a new .deb format
> would be huge.
Where do you get this from? Where is this relevant?
The overhead to change to a new deb format is small. A very few
packages have to change (dpkg, apt, DAK, mini-dinstall). A few man
hours of work and compared with the amount of changes in debian every
day that is miniscule.
The transition itself would go completly unadministered. Once dpkg is
switched to default to a different compression all freshly build
packages use it and the archive transitions itself over time.
All the transition needs, after the initial infrastructure change, is
a lot of time. At least one stable release to get stable dpkg to cope
with differently compressed unstable packages and then time for every
package to get a new upload.
> Thus, anything sacrificing lots of human power and CPU power to save on disk
> or bandwidth just doesn't make sense.
Don't forget CD/DVD space. With better compression you could probably
fit Sarge i386 on a dual layer dvd again.
The businesscard and netboot images would also shrink alowing some
more debs on them, e.g. a graphical installer.