Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: What's left over.
Original-Message-ID: <Pine.LNX.4.44.0210310737170.2035-100000@home.transmeta.com>
Date: Thu, 31 Oct 2002 15:47:14 GMT
Message-ID: <fa.m6e6eav.14gg9gr@ifi.uio.no>

On Wed, 30 Oct 2002, Matt D. Robinson wrote:

> Linus Torvalds wrote:
> > > Crash Dumping (LKCD)
> >
> > This is definitely a vendor-driven thing. I don't believe it has any
> > relevance unless vendors actively support it.
>
> There are people within IBM in Germany, India and England, as well as
> a number of companies (Intel, NEC, Hitachi, Fujitsu), as well as SGI
> that are PAID to support this.

That's fine. And since they are paid to support it, they can apply the
patches.

What I'm saying by "vendor driven" is that it has no relevance for the
standard kernel, and since it has no relevance to that, then I have no
incentives to merge it. The crash dump is only useful with people who
actively look at the dumps, and I don't know _anybody_ outside of the
specialized vendors you mention who actually do that.

I will merge it when there are real users who want it - usually as a
result of having gotten used to it through a vendor who supports it. (And
by "support" I do not mean "maintain the patches", but "actively uses it"
to work out the users problems or whatever).

Horse before the cart and all that thing.

People have to realize that my kernel is not for random new features. The
stuff I consider important are things that people use on their own, or
stuff that is the base for other work. Quite often I want vendors to merge
patches _they_ care about long long before I will merge them (examples of
this are quite common, things like reiserfs and ext3 etc).

THAT is what I mean by vendor-driven. If vendors decide they really want
the patches, and I actually start seeing noises on linux-kernel or getting
requests for it being merged from _users_ rather than developers, then
that means that the vendor is on to something.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: What's left over.
Original-Message-ID: <Pine.LNX.4.44.0210310918260.1410-100000@penguin.transmeta.com>
Date: Thu, 31 Oct 2002 17:27:53 GMT
Message-ID: <fa.oaa5d6v.jku5b1@ifi.uio.no>

[ Ok, this is a really serious email. If you don't get it, don't bother
  emailing me. Instead, think about it for an hour, and if you still don't
  get it, ask somebody you know to explain it to you. ]

On Thu, 31 Oct 2002, Matt D. Robinson wrote:
>
> Sure, but why should they have to?  What technical reason is there
> for not including it, Linus?

There are many:

 - bloat kills:

	My job is saying "NO!"

	In other words: the question is never EVER "Why shouldn't it be
	accepted?", but it is always "Why do we really not want to live
	without this?"

 - included features kill off (potentially better) projects.

	There's a big "inertia" to features. It's often better to keep
	features _off_ the standard kernel if they may end up being
	further developed in totally new directions.

	In particular when it comes to this project, I'm told about
	"netdump", which doesn't try to dump to a disk, but over the net.
	And quite frankly, my immediate reaction is to say "Hell, I
	_never_ want the dump touching my disk, but over the network
	sounds like a great idea".

To me this says "LKCD is stupid". Which means that I'm not going to apply
it, and I'm going to need some real reason to do so - ie being proven
wrong in the field.

(And don't get me wrong - I don't mind getting proven wrong. I change my
opinions the way some people change underwear. And I think that's ok).

> I completely don't understand your reasoning here.

Tough. That's YOUR problem.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: What's left over.
Original-Message-ID: <Pine.LNX.4.44.0210310951180.1410-100000@penguin.transmeta.com>
Date: Thu, 31 Oct 2002 17:57:27 GMT
Message-ID: <fa.o9q9e6v.i424b8@ifi.uio.no>

On Thu, 31 Oct 2002, Matt D. Robinson wrote:
>
> This isn't bloat.  If you want, it can be built as a module, and
> not as part of your kernel.  How can that be bloat?

I don't care one _whit_ about the size of the binary. I don't maintain
binaries, and the binary can be gigabytes for all I care.

The only thing I care about is source code. So the "build it as a module
and it is not bloat" argument is a total nonsense thing as far as I'm
concerned.

Anyway, new code is always bloat to me, unless I see people using them.

Guys, why do you even bother trying to convince me? If you are right, you
will be able to convince other people, and that's the whole point of open
source.

Being "vendor-driven" is _not_ a bad thing. It only means that _I_ am not
personally convinced. I'm only one person.

		Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: What's left over.
Original-Message-ID: <Pine.LNX.4.44.0210311015380.1410-100000@penguin.transmeta.com>
Date: Thu, 31 Oct 2002 18:26:31 GMT
Message-ID: <fa.ob9nd6v.jkg5bc@ifi.uio.no>

On Thu, 31 Oct 2002, Chris Friesen wrote:
>
> How do you deal with netdump when your network driver is what caused the
> crash?

Actually, from a driver perspective, _the_ most likely driver to crash is
the disk driver.

That's from years of experience. The network drivers are a lot simpler,
the hardware is simpler and more standardized, and doesn't do as many
things. It's just plain _easier_ to write a network driver than a disk
driver.

Ask anybody who has done both.

But that's not the real issue. The real issue is that I have no personal
incentives to try to merge the thing, and as a result I think I'm the
wrong person to do so. I've told people over and over again that I think
this is a "vendor merge", and I'm fed up with people not _getting_ it.

Don't bother to ask me to merge the thing, that only makes me get even
more fed up with the whole discussion. This is open source, guys. Anybody
can merge it. Because I don't particularly believe in it doesn't mean that
it cannot be used. It only means that I want to see users flock to it and
show my beliefs wrong.

		Linus

Newsgroups: fa.linux.kernel
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: What's left over.
Original-Message-ID: <apt0td$3vq$1@penguin.transmeta.com>
Date: Fri, 1 Nov 2002 04:48:00 GMT
Message-ID: <fa.kale4gv.f3i3gq@ifi.uio.no>

In article <Pine.LNX.4.44.0210311923460.24182-100000@nakedeye.aparity.com>,
Matt D. Robinson <yakker@aparity.com> wrote:
>
>To spend the last month and a half finalizing things for Linus,
>sending this to him on multiple occasions, asking for his comments
>and inclusion, asking for his feedback (as well as others), and
>not hearing _one damn word_ from Linus all that time, and for him
>to wait until now to just say "LKCD is stupid" is insulting.

You got to hear my comment now, several times: convince somebody _else_.

But no, it wasn't the answer you wanted.  So you refuse to listen.  And
yes, I get irritated too.  So right now I won't touch LKCD with a
ten-foot pole, if only because I've been mail-bombed by people who argue
for it when I have better things to do than to explain myself over and
over again.

What's so hard to understand about the "vendor-driven" thing, and why do
people continue to argue about it?

			Linus

Newsgroups: fa.linux.kernel
From: Linus Torvalds <torvalds@transmeta.com>
Subject: Re: What's left over.
Original-Message-ID: <Pine.LNX.4.44.0210312233190.5595-100000@home.transmeta.com>
Date: Fri, 1 Nov 2002 06:52:55 GMT
Message-ID: <fa.m8uafqv.160cb0v@ifi.uio.no>

On Fri, 1 Nov 2002, Bill Davidsen wrote:
>
>   If you really believed the stuff you say you'd put it in and promise to
> take it out if people didn't find it useful or there were inherent
> limitations.

This never works. Be honest. Nobody takes out features, they are stuck
once they get in. Which is exactly why my job is to say "no", and why
there is no "accepted unless proven bad".

> It would probably take 10-30% off the time to a stable release.

Talk is cheap.

I've not seen a _single_ bug-report with a fix that attributed the
existing LKCD patches. I might be more impressed if I had.

The basic issue is that we don't put patches in in the hope that they will
prove themselves later. Your argument is fundamentally flawed.

		Linus