lkml.org 
[lkml]   [2006]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion)
Hans Reiser wrote:

> plugins if not for us. Our plugins affect no one else. Our
> self-contained code should not be delayed because other people delayed

And at the moment, I can still use Reiser4. If I ever make a distro, I
will include Reiser4 support, probably as the default FS. That will
help with getting into the kernel.

So, why is it that it's urgent to get into the kernel? It will have to
be bootstrapped one way or another -- either get it into the kernel so
distros are more likely to include it, or get it into distros so the
kernel is more likely to include it.

But this is exactly the kind of thing that has happened before. With
XFS, with Nvidia even -- clean it up, do it the way the kernel people
want you to, because they're the ones who will have to maintain it for
20 years, and make sure it doesn't stop working or break anything else.

> advantage from leading. If they want to some distant day implement
> generic plugins, for which they have written not one line of code to
> date, fine, we'll use it when it exists, but right now those who haven't
> coded should get out of the way of people with working code. It is not
> fair or just to do otherwise. It also prevents users from getting
> advances they could be getting today, for no reason.

It prevents users from doing nothing.

> Our code will not
> be harder to change once it is in the kernel, it will be easier, because
> there will be more staff funded to work on it.

If indeed it can be changed easily at all. I think the burden is on you
to prove that you can change it to be more generic, rather than saying
"Well, we could do it later, if people want us to..."

> As for this "we are all too grand to be bothered with money to feed our
> families" business, building a system in which those who contribute can
> find a way to be rewarded is what managers do. Free software
> programmers may be willing to live on less than others, but they cannot
> live on nothing, and code that does not ever ship means living on nothing.

Let me put this in perspective the best way I know how, with an inane
analogy:

Suppose there's a band. A good band, full of impossible superstars, led
by a benevolent dictator -- for the sake of argument, let's call him
Elvis. (the King -- dictator...) The band's doing really well, and
Elvis & crew are getting paid fairly well just to share their music.

(Ok, maybe Elvis didn't write anything, but bear with me...)

Now, along comes a young Jimi Hendrix. He wants to be in the band, and
Elvis says "Sure, just come up with a song we like and we'll play it,
and you can even play it with us!" Sounds like a pretty good deal, so
Jimi goes and tells all his friends, a couple of girls...

Now, Jimi finishes his song, Elvis listens to it, and if you know
anything about the music Elvis did and the music Hendrix did, you can
imagine what happens next. Elvis says "This song just isn't us. But if
you change it here, and here, and maybe here, we'll play it."

Jimi is devastated. He'd been counting on playing it with them that
night, and if he doesn't, he won't have any groupies, all his friends
will laugh at him, and his life will kind of suck.

But, does anyone really think Elvis has any business singing Voodoo
Child? Or Purple Haze? Is it really fair to ask Elvis to completely
change his act and embarrass himself to help Jimi out?

The answer is, Jimi shouldn't have staked so much on something that was
never a guarantee. And what's more, the real-life Jimi Hendrix never
played with Elvis, but had a very successful band of his own. And if
Elvis was still alive, seeing Jimi play might make him change his mind,
maybe -- but at least with his own band, Jimi's success isn't pinned on
playing with Elvis.

This analogy is flawed in many ways, aside from just being plain
chronologically impossible, but while I'm sure Linus feels bad for you,
I don't think it's his obligation to compromise his kernel to help you
out with your financial situation. So it would help a lot if you
wouldn't keep bringing it up in what should be a technical discussion.



So, if you can't make it work with VFS, then I guess you can't, and
you're stuck either creating another interface which is not tied to any
one filesystem and isn't tied to the VFS either, or coming up with a
better (more specific) idea of how to make the Reiser4 plugin system
acceptable to kernel maintainers without having to eat Ramen for a few
years.

Understand that I'm putting on my devil's advocate hat right now. I'd
love to see Reiser4 merged tomorrow, or a week from now, exactly as it's
written today, but I just don't see it happening. I'd also love to get
more technical, but I just don't know the Reiser4 internals well enough
to understand the feasibility (or not) of any of my vague ideas.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-28 23:57    [W:0.436 / U:0.136 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site