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 it. 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 -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0