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

Re: kernel-{image,headers} package bloat

On Sun, Apr 22, 2001 at 01:38:42PM +1000, Herbert Xu wrote:
> > if the user needs a more specific kernel (e.g. with SMP or compiled
> > for a P2 or a K6 or whatever) then they can use manoj's excellent
> > kernel-package (one of debian's best features, IMO) to build a
> > custom kernel.
> This is exactly our disagreement.  My position is that it is well
> within our capabilities to make this unnecessary.  And you disagree
> with that which is fine with me.

i disagree with you primarily because the cost of having so many
kernel-image packages is too high.

that cost is over 100MB per kernel version, that's several hundred MB
with several kernel versions available (1 or 2 x 2.2.x kernels and 1 or
2 x 2.4.x kernels, possibly a 2.5.x kernel as well)

that means extra bandwidth consumed to sync each and every mirror
site...repeated every time a kernel-image is added to or upgraded in
the archive. that could easily run into several gigabytes per month
PER mirror...and dozens of gigabytes extra per month for master and
ftp.debian.org to feed all the mirrors.

there's also an economic cost too, of course. some places in the
world have much cheaper bandwidth than Australia, some have much more
expensive bandwidth, but here in Australia, a GB costs about $AUD200 (~=
$USD100) to download. that's at $0.20/MB, an average price for Australia
- some people pay more than that (as much as $0.35/MB), some pay less
(as little as $0.07/MB)...so the price per GB ranges from $AUD70 to $AUD350.

it also means more space consumed on the CD-ROM - several hundred MB
extra wasted on kernel images in the release will mean at least one
extra CD-ROM. that means a more expensive release, and more difficult
and time-consuming to produce.

it also means more gigabytes of bandwidth used by people mirroring the
ISO images.

the benefit of having all those extra kernel-image packages around is
soemwhere been non-existant and negligible...but the cost is enormous.

it's just plain wrong, and it should not happen.

just as you stated you'd be filing bug-reports to get 2.2.17 kernel
image removed from the archive, i'll be filing "package should not
exist" bugs against all the excess kernel-image bugs.

the correct thing to do is to encourage and educate our users about
compiling their own kernel. if it's "too hard" then we should try to
make it easier.

why pander to ignorance when ignorance is a curable affliction? it's
much better to cure it through education than to support and encourage

what you want to do is detrimental in the long run - it serves to
perpetuate the myth that compiling kernels is extremely difficult, and
encourages laziness and ignorance on the part of the user.

> Most are.  In my opinioin, there isn't anything that is particular
> important to most people which haven't been modularised yet.

you seem to think that optimisations for specific ia32 sub-architectures
are important enough to package...

> > 2. it is, in general, *far* better to run a kernel which is specific to
> > your exact hardware and your exact requirements than to use a generic
> > kernel with a bunch of options you don't use and don't care about
> > compiled in.
> IMHO, with the current 2.4.* setup, the difference between compiling your
> own and using the preexisting one is so minimal that most people will be
> able to use the precompiled one rather than building their own.

there's good reason to worry about kernel modules now that there are
known hax0r stealth modules which exist purely to hide the fact that a
system has been compromised.


craig sanders <cas@taz.net.au>

      GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Reply to: