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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel



#include <hallo.h>
* Robert Millan [Sat, Nov 08 2003, 05:00:07PM]:
> On Sat, Nov 08, 2003 at 03:33:43PM +0100, Eduard Bloch wrote:
> > 
> > Or they found a sane trade-off between optimisations and compatibility
> > (see Wiki page below which was born in discission!). You did not discuss
> > it. You took your own ideas as guidelines for the future kernel
> > development.
> 
> No, I took the ideas from the thousands of packages in Debian. How many of
> them provide optimised binaries?

Where do you see an inconsistence in my argumentation? libssl and atlas
are examples whehere optimisations make sence, there are real jumps in
performance. I would do the same for the kernel: pure i386 and something
to make most users crying for optimisations happy (i686 version which is
good for p2..4 and various k7 steppings).

> > So please maintain your packages in some personal
> > repository to not fuck up the name space (don't even think about
> > experimental tree!) as long as we don't have a consens about it.
> 
> If you want me to provide optimised binaries, then this is you who should go
> and get the consensus. So instead of drawing your silly threats, bring up
> some points and I'll gladly discuss them with you.

I did enough. If you did not notice, there are requests for the
debian-kernel mailing list.

> > Your reasoning is flawed. The packages you refer to as examples (gcc,
> > libc) are maintained buy whole projects. And the do much more testing
> 
> The current Linux kernel maintainers, which provide that patchset on which my
> package is based, don't do any testing?

How do you know that they like your model at all? What you you do if it
takes 2-3 months to make a new kernel release ready for
$the_exotic_arch? Do you want to make the people wait?

> > and they don't plan to drop parts or whole architectures with the first
> > appearence of problems as you are going to do.
> 
> Someone said fixing support for some architectures properly is a "fucking
> huge task". Now it is a "first appearence of problems". Would you people get
> a clear idea of what the problem is?

It seems that you cannot even imagine it...

> And stop using it as an argument. If there are no up-to-date patches for one
> architecture in Debian, this is a problem by itself. It doesn't have anything
> to do with my package.

So package it for i386 only. Than you can guarantee that it won't have
anything to do with your package.

> > And as said before, your ideas are not consistent. You claim to create a
> > linux-kernel package for every architecture, but only for that you like.
> 
> Erm.. don't put words in my mouth?

Well, think about the words. They are implication of the facts that you
try to ignore.

> > indicated above), there is no way to fix it unless there is human
> > operator sitting in front of the box.
> 
> So, you can repair from an initrd system, but you can't load a backup Linux
> kernel?

If you expect possible breakage, you can make preparations to rescue the
system. If someone unintentionaly installs a new kernel just because you
decided to change the dependency in "linux", this will hit the user
unexpectedly.

MfG,
Eduard.
-- 
Auf einem Tisch liegt ein 100,-DM-Schein; am Tisch sitzen der
Weihnachtsmann, der Osterhase, ein schneller und ein langsamer Beamte -
Wer bekommt den Hundertmarkschein? Der langsame Beamte, denn den
Weihnachsmann, den Osterhasen und den schnellen Beamten gibt es nicht. 



Reply to: