Re: [firstname.lastname@example.org: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
>>"Ian" == Ian Jackson <email@example.com> writes:
Ian> Well, certainly it's not decisive, but we're unlikely to get better
Ian> information. We're going to have to decide on the basis of the
Ian> information we have available, I think.
Then I do not think we have enough data to override a
maintainers decision about his own package.
>> >> Con:
>> >> * A small increase in kernel size. This has not been quantified.
>> >> Allegedly, including all drivers which are in roughly the same
>> >> situation as VESA fb would increase the kernel size significantly.
>> Lack of modularity in the kernel is a bad idea, and unless
>> there is overwhelming need for it, I would much rather not taint the
>> kernel with non modular code; in this I agree with Herbert.
Ian> This argument seems aesthetic, possibly even emotional, to me. Is
Ian> there actually any _problem_ with the non-modular code ?
Maintainability? There is more to clean code than mere
aesthetics. As the kernel moves towards initrds and modularity,
Ian> (I should say that personally, I find kernel modules a mixed
Ian> blessing, and on my own systems often avoid them because of
Ian> their extra complexity. That's not to say that they're not
Ian> useful in distribution kernels, of course, but I think I should
Ian> warn you about my prejudices ...)
You seem to be in a small minoruty when it comes to opinions
about monolithic kernel vs modular kernels. Indeed, there is talk of
moving to initrd and modular solution as a default on the kernel
Ian> Guesswork. No-one in this argument has any concrete data.
Yes. But the mainainer, being close to the package, and
presumably interacting with more users than non maintainers, often
has a better feel for subjective guess work like this.
Ian> Do business users often turn on quotas on desktop machines ? I'd be
Ian> surprised. For servers, of course, most people will (or should!)
Ian> build their own kernels.
Then I think you should be prepared to be surprised;
Dec/Compaq, the university of massachusetts at amherst (various
departments), and several other companies I a=have ahd contact with
all had soft and hard quotas turned on.
My take on this is this:
A user had a wishlist item to add functionality that some users
The maintainer has come up with a reasonable stance that the
solution requires suboptimal code; prevents inclusion of
modular code that other users may like, there is a reasonable
alternative (vga16), and in his considered judgement
fulfillment of the wishlist is bad.
The ctte has no grounds to override the maintainer based on
mere guesswork, since they can't in honesty claim to have better
guesses than the maintainer.
The only people for me are the mad ones -- the ones who are mad to
live, mad to talk, mad to be saved, desirous of everything at the
same time, the ones who never yawn or say a commonplace thing, but
burn, burn, burn like fabulous yellow Roman candles. Jack Kerouac,
"On the Road"
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C