Another article abour Reiser4 on linux.com

Another article abour Reiser4 on linux.com

[Tassilo Horn]

Hi,

there's another Reiser4 article on linux.com [1], mainly about
politics. Neither much of the technical discussion is covered, nor are
the comments too positive, but it may be interesting anyway.

One thing which bothers me most: Whenever such an article appears it's
commented mostly by kiddies speaking after the mouth of several kernel
developers, sophisticating most of their comments, ripping them out of
context or spreading superficial knowledge. Of course those comments let
it get to possible new users.

Kind regards and keep up the great work,
Tassilo (pleased Reiser4 user since 2.6.0_testX)

Footnotes: 
[1] http://www.linux.com/article.pl?sid=06/07/31/1548201
-- 
My opinions may have changed, but not the fact that I am right.

Re: Another article abour Reiser4 on linux.com

[David Masover]

Tassilo Horn wrote:

> [1] http://www.linux.com/article.pl?sid=06/07/31/1548201

 From the article:

"To complicate matters, Reiser4's approach lands the filesystem in the 
middle of a longstanding convention of avoiding plugins in the kernel, 
mainly to avoid architectural complications, but also to discourage 
proprietary drivers that circumvent the kernel's release under the GNU 
General Public License."

We should really find something better to call them than "plugins", or 
we should come up with a standard copy'n'paste statement to refute this.

Re: Another article abour Reiser4 on linux.com

[Maciej Sołtysiak]

Hello David,

Saturday, August 5, 2006, 4:55:16 PM, you wrote:
> We should really find something better to call them than "plugins", or
> we should come up with a standard copy'n'paste statement to refute this.
I agree. As Andrew Morton said:

"The plugins appear to be wildly misnamed - they're just an internal
abstraction layer which permits later feature additions to be added in a
clean and safe manner.  Certainly not worth all this fuss."

So we're talking about extensibility. How about we call it
'extensions' ?

-- 
Best regards,
Maciej

Re: Another article abour Reiser4 on linux.com

[Maciej Sołtysiak]

> So we're talking about extensibility. How about we call it
> 'extensions' ?
Or just modules... netfilter has modules that allow us to write
very cool and weird stuff (like unclean match once was) and
nobody complains.

Another word could be 'hooks'

--
Maciej

Re: Another article abour Reiser4 on linux.com

[Clay Barnes]

I like using a term that is already in an accepted part of the
kernel.  Extensions might smack of plugins a bit much, and we're
trying to avoid just doing a s/plugins/extensions/ of the
arguments we're seeing now.

--Clay

On 18:22 Sat 05 Aug     , Maciej Sołtysiak wrote:
> > So we're talking about extensibility. How about we call it
> > 'extensions' ?
> Or just modules... netfilter has modules that allow us to write
> very cool and weird stuff (like unclean match once was) and
> nobody complains.
> 
> Another word could be 'hooks'
> 
> --
> Maciej
> 
> 

Re: Another article abour Reiser4 on linux.com

[David Masover]

Clay Barnes wrote:
> I like using a term that is already in an accepted part of the
> kernel.  Extensions might smack of plugins a bit much, and we're
> trying to avoid just doing a s/plugins/extensions/ of the
> arguments we're seeing now.

We could do that with almost anything:

>> Or just modules... netfilter has modules that allow us to write
>> very cool and weird stuff (like unclean match once was) and
>> nobody complains.

Except that modules could also possibly remind people of proprietary 
modules, like the nvidia/ATI/vmware stuff.

Still, if we allow netfilter, why not Reiser4 modules?

>> Another word could be 'hooks'

I don't think this would quite work.  A hook describes more the place 
you connect to, whereas a module/plugin/whatever...

Think of it this way -- the hook is what a plugin would plug in to.

So it may not matter much what we name them, we're probably still going 
to need that cut'n'paste argument.  Might be easier with "modules", though.

Re: Another article abour Reiser4 on linux.com

[Clay Barnes]

I think the core thing we have to have to win this argument is
a) A word that isn't *instantly* associated with banned things.
b) The ability to point to the technology to point to the design
and say look, "Look, it's *impossible* to use this design to put
binary modules into the kernel."  Even if it's as hard as ATI or
nVidia modules to put it in, that'll be enough to put up a fight
against inclusion.  The *only* way to win a polical/personal fight
is to remove any possible objection until resistance looks purely
stupid and wholly unsubtantiated.  Yes, things with reservations
have made it in in the past, but only when there is no personal
conflict.

I was just saying to my roomate that I was losing hope for Reiser4
because I didn't see an end to the politics any time soon.  I
would *love* to see Reiser 4 in the kernel, but you guys are
fighting a worse than uphill battle.  As long as there's a stalemate
the kernel people win, since no change is all they want.  It's 
also quite easy for them to find something new to complain about
if you solve their current problems.

There's only one possible way I see to get in.  You must ask for an
absolute list of things that are objectionable.  You should then
ask *before you start work*  about removal of any items that are 
either a) impossible, or b) illogical.  Once you've gotten the
official stamp of approval of the (posibly recvised) absolute list
of objections, you have to do it, completely and exactly.  If they
agreed that that is everything they find wrong and promised that
they would include Reiser4 if those issues were resolved, then they
really *have* to put it in then.

The down side of course is that they may ask for a lot.  Even if
it's more than you find fair, remember that they can effectively
kill your project by inaction.  Fair?  No.  The way the world
works?  Unfortunately, yes.

The core of all this is that rather than leaving an open-ended task
that can be expanded at will, they are given limits to how long the
objections can be spread out.  The bonus to you is that if anyone
tries to drag out issues after you've done the list, you can point
to the it and say "These were the limit of the real issues that
were raised.  Anything beyond is someone else's preference, and 
therefore their job to get included."

--Clay

On 17:40 Sat 05 Aug     , David Masover wrote:
> Clay Barnes wrote:
> >I like using a term that is already in an accepted part of the
> >kernel.  Extensions might smack of plugins a bit much, and we're
> >trying to avoid just doing a s/plugins/extensions/ of the
> >arguments we're seeing now.
> 
> We could do that with almost anything:
> 
> >>Or just modules... netfilter has modules that allow us to write
> >>very cool and weird stuff (like unclean match once was) and
> >>nobody complains.
> 
> Except that modules could also possibly remind people of proprietary 
> modules, like the nvidia/ATI/vmware stuff.
> 
> Still, if we allow netfilter, why not Reiser4 modules?
> 
> >>Another word could be 'hooks'
> 
> I don't think this would quite work.  A hook describes more the place 
> you connect to, whereas a module/plugin/whatever...
> 
> Think of it this way -- the hook is what a plugin would plug in to.
> 
> So it may not matter much what we name them, we're probably still going 
> to need that cut'n'paste argument.  Might be easier with "modules", though.

Re: Another article abour Reiser4 on linux.com

[David Masover]

Clay Barnes wrote:
> I think the core thing we have to have to win this argument is
> a) A word that isn't *instantly* associated with banned things.

That'd be nice.

> b) The ability to point to the technology to point to the design
> and say look, "Look, it's *impossible* to use this design to put
> binary modules into the kernel."  Even if it's as hard as ATI or
> nVidia modules to put it in, that'll be enough to put up a fight
> against inclusion.

Why?

Why does it have to be impossible to do binary things with the kernel? 
I mean, if Linus hates GPL3 because it limits what people do with the 
kernel...

Besides, you can't make it impossible, you can only make it about as 
hard as it is now.  The license is the issue here.

> The *only* way to win a polical/personal fight
> is to remove any possible objection until resistance looks purely
> stupid and wholly unsubtantiated.

I agree.  That's why we not only need a new name, we also need a 
cut'n'paste argument that just makes this look stupid.

And it has to be short enough that cut'n'paste isn't bad, because if we 
refer people to the FAQ, they won't read it.

> I was just saying to my roomate that I was losing hope for Reiser4
> because I didn't see an end to the politics any time soon.

Yes, it can look pretty hopeless.

> There's only one possible way I see to get in.  You must ask for an
> absolute list of things that are objectionable.  You should then
> ask *before you start work*  about removal of any items that are 
> either a) impossible, or b) illogical.  Once you've gotten the
> official stamp of approval of the (posibly recvised) absolute list
> of objections, you have to do it, completely and exactly.  If they
> agreed that that is everything they find wrong and promised that
> they would include Reiser4 if those issues were resolved, then they
> really *have* to put it in then.

The problem is, they don't.  There have been some fairly definitive 
lists in the past, that were done, but maybe not quite the way they were 
expected.

> The core of all this is that rather than leaving an open-ended task
> that can be expanded at will, they are given limits to how long the
> objections can be spread out.

Problem is, dictators can do whatever they want, even if they said 
something else before.

And that's all assuming you can get them to agree to such a list, and 
agree to abide by it.  They either wouldn't go for it, or they would 
come up with a list that effectively kills Reiser4, turning it into ext3.

Re: Another article abour Reiser4 on linux.com

[TongKe Xue]

A really stupid question ... why not put Reiser4 in one of the BSDs?

And after it's got mainstream use, if it proves its worth, there'll be 
more pressure for Linux to adopt.

On Sat, 5 Aug 2006, David Masover wrote:

> Clay Barnes wrote:
>> I think the core thing we have to have to win this argument is
>> a) A word that isn't *instantly* associated with banned things.
>
> That'd be nice.
>
>> b) The ability to point to the technology to point to the design
>> and say look, "Look, it's *impossible* to use this design to put
>> binary modules into the kernel."  Even if it's as hard as ATI or
>> nVidia modules to put it in, that'll be enough to put up a fight
>> against inclusion.
>
> Why?
>
> Why does it have to be impossible to do binary things with the kernel? I 
> mean, if Linus hates GPL3 because it limits what people do with the kernel...
>
> Besides, you can't make it impossible, you can only make it about as hard as 
> it is now.  The license is the issue here.
>
>> The *only* way to win a polical/personal fight
>> is to remove any possible objection until resistance looks purely
>> stupid and wholly unsubtantiated.
>
> I agree.  That's why we not only need a new name, we also need a cut'n'paste 
> argument that just makes this look stupid.
>
> And it has to be short enough that cut'n'paste isn't bad, because if we refer 
> people to the FAQ, they won't read it.
>
>> I was just saying to my roomate that I was losing hope for Reiser4
>> because I didn't see an end to the politics any time soon.
>
> Yes, it can look pretty hopeless.
>
>> There's only one possible way I see to get in.  You must ask for an
>> absolute list of things that are objectionable.  You should then
>> ask *before you start work*  about removal of any items that are either a) 
>> impossible, or b) illogical.  Once you've gotten the
>> official stamp of approval of the (posibly recvised) absolute list
>> of objections, you have to do it, completely and exactly.  If they
>> agreed that that is everything they find wrong and promised that
>> they would include Reiser4 if those issues were resolved, then they
>> really *have* to put it in then.
>
> The problem is, they don't.  There have been some fairly definitive lists in 
> the past, that were done, but maybe not quite the way they were expected.
>
>> The core of all this is that rather than leaving an open-ended task
>> that can be expanded at will, they are given limits to how long the
>> objections can be spread out.
>
> Problem is, dictators can do whatever they want, even if they said something 
> else before.
>
> And that's all assuming you can get them to agree to such a list, and agree 
> to abide by it.  They either wouldn't go for it, or they would come up with a 
> list that effectively kills Reiser4, turning it into ext3.
>
>

Re: Another article abour Reiser4 on linux.com

[David Masover]

TongKe Xue wrote:
> A really stupid question ... why not put Reiser4 in one of the BSDs?
> 
> And after it's got mainstream use, if it proves its worth, there'll be 
> more pressure for Linux to adopt.

It will likely take far more work to port it to BSD than it will to be 
included in Linux.  And you're talking about probably even less chance 
of inclusion or of picking up a large community than in Linux.

Re: Another article abour Reiser4 on linux.com

[TongKe Xue]

(I lost someone's response sorry)

Re: hard to get into BSD

There's Dragonflybsd; they seem very chill / acceptable to new ideas.

On Sat, 5 Aug 2006, TongKe Xue wrote:

> A really stupid question ... why not put Reiser4 in one of the BSDs?
>
> And after it's got mainstream use, if it proves its worth, there'll be more 
> pressure for Linux to adopt.
>
> On Sat, 5 Aug 2006, David Masover wrote:
>
>> Clay Barnes wrote:
>>> I think the core thing we have to have to win this argument is
>>> a) A word that isn't *instantly* associated with banned things.
>> 
>> That'd be nice.
>> 
>>> b) The ability to point to the technology to point to the design
>>> and say look, "Look, it's *impossible* to use this design to put
>>> binary modules into the kernel."  Even if it's as hard as ATI or
>>> nVidia modules to put it in, that'll be enough to put up a fight
>>> against inclusion.
>> 
>> Why?
>> 
>> Why does it have to be impossible to do binary things with the kernel? I 
>> mean, if Linus hates GPL3 because it limits what people do with the 
>> kernel...
>> 
>> Besides, you can't make it impossible, you can only make it about as hard 
>> as it is now.  The license is the issue here.
>> 
>>> The *only* way to win a polical/personal fight
>>> is to remove any possible objection until resistance looks purely
>>> stupid and wholly unsubtantiated.
>> 
>> I agree.  That's why we not only need a new name, we also need a 
>> cut'n'paste argument that just makes this look stupid.
>> 
>> And it has to be short enough that cut'n'paste isn't bad, because if we 
>> refer people to the FAQ, they won't read it.
>> 
>>> I was just saying to my roomate that I was losing hope for Reiser4
>>> because I didn't see an end to the politics any time soon.
>> 
>> Yes, it can look pretty hopeless.
>> 
>>> There's only one possible way I see to get in.  You must ask for an
>>> absolute list of things that are objectionable.  You should then
>>> ask *before you start work*  about removal of any items that are either a) 
>>> impossible, or b) illogical.  Once you've gotten the
>>> official stamp of approval of the (posibly recvised) absolute list
>>> of objections, you have to do it, completely and exactly.  If they
>>> agreed that that is everything they find wrong and promised that
>>> they would include Reiser4 if those issues were resolved, then they
>>> really *have* to put it in then.
>> 
>> The problem is, they don't.  There have been some fairly definitive lists 
>> in the past, that were done, but maybe not quite the way they were 
>> expected.
>> 
>>> The core of all this is that rather than leaving an open-ended task
>>> that can be expanded at will, they are given limits to how long the
>>> objections can be spread out.
>> 
>> Problem is, dictators can do whatever they want, even if they said 
>> something else before.
>> 
>> And that's all assuming you can get them to agree to such a list, and agree 
>> to abide by it.  They either wouldn't go for it, or they would come up with 
>> a list that effectively kills Reiser4, turning it into ext3.
>> 
>> 
>

Re: Another article abour Reiser4 on linux.com

[Hans Reiser]

TongKe Xue wrote:

> A really stupid question ... why not put Reiser4 in one of the BSDs?
>
The cost to port to BSD is about $500k, and I am not possessed of a lot
of money at this time.  There is also a license issue, I don't want
reiser4 to be BSD licensed, people who want proprietary additions to
reiser4 should pay me for reiser4.

Re: Another article abour Reiser4 on linux.com

[Bernd Schubert]

On Sunday 06 August 2006 10:20, Hans Reiser wrote:
> TongKe Xue wrote:
> > A really stupid question ... why not put Reiser4 in one of the BSDs?
>
> The cost to port to BSD is about $500k, and I am not possessed of a lot
> of money at this time.  There is also a license issue, I don't want
> reiser4 to be BSD licensed, people who want proprietary additions to
> reiser4 should pay me for reiser4.

An alternative might be a reiser4 fuse port. Has some advantages:

- Doesn't need to be included into the kernel.

- can be GPL

- Referring to the fuse site it also works on BSD (http://fuse4bsd.creo.hu/).

- Kills one of the major arguments on LKML - if reiser4 is included but 
Namesys abandons  it in the future and reiser4 has to be removed from the 
kernel that time again, it still could be mounted.

Sorry, I have never looked into any of the reiserfs code, but looking at the 
simple interface of fuse, it might be possible that you could reuse lots of 
your present code.
There even is ongoing work to get a ZFS fuse port 
(http://www.wizy.org/wiki/ZFS_on_FUSE).

Cheers,
	Bernd

-- 
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg

Re: Another article abour Reiser4 on linux.com

[Lexington Luthor]

Bernd Schubert wrote:
> An alternative might be a reiser4 fuse port. Has some advantages:
> 
> - Doesn't need to be included into the kernel.
> 
> - can be GPL
> 
> - Referring to the fuse site it also works on BSD (http://fuse4bsd.creo.hu/).
> 
> - Kills one of the major arguments on LKML - if reiser4 is included but 
> Namesys abandons  it in the future and reiser4 has to be removed from the 
> kernel that time again, it still could be mounted.
> 

Please please no. The kernel people will use that as an argument for 
keeping it out of the kernel. I want reiser4 to be popular enough to 
make my apps depend on it and not have the users complain about having 
to use an obscure fs.

Besides, the only thing about reiser4 that interests me more than XFS or 
reiserfs is the speed. In FUSE, you lose all that (as well as millions 
of context switches, there is a huge amount of copying going on). If 
reiser4 gets slower, I might as well use XFS or even old reiserfs.


- LL

Re: Another article abour Reiser4 on linux.com

[Bernd Schubert]

On Sunday 06 August 2006 14:41, Lexington Luthor wrote:
> Bernd Schubert wrote:
> > An alternative might be a reiser4 fuse port. Has some advantages:
> >
> > - Doesn't need to be included into the kernel.
> >
> > - can be GPL
> >
> > - Referring to the fuse site it also works on BSD
> > (http://fuse4bsd.creo.hu/).
> >
> > - Kills one of the major arguments on LKML - if reiser4 is included but
> > Namesys abandons  it in the future and reiser4 has to be removed from the
> > kernel that time again, it still could be mounted.
>
> Please please no. The kernel people will use that as an argument for
> keeping it out of the kernel. I want reiser4 to be popular enough to
> make my apps depend on it and not have the users complain about having
> to use an obscure fs.
>
> Besides, the only thing about reiser4 that interests me more than XFS or
> reiserfs is the speed. In FUSE, you lose all that (as well as millions
> of context switches, there is a huge amount of copying going on). If
> reiser4 gets slower, I might as well use XFS or even old reiserfs.

Well, by having a FUSE port just more users would use reiser4, which might 
increase the force to the linux distributors to include reiser4 into their 
kernel versions. 

Regarding the speed, I understand that its slower with FUSE, I was also deeply 
impressed when I read this  
(http://sourceforge.net/mailarchive/forum.php?thread_id=23836054&forum_id=2697)

	But being twice as fast as ext3 is enough currently. It's even faster than 
	xfs what I use. Sometimes I'm quite suprised why something is so fast when
	I realize that it was actually ntfs-3g :-)


Cheers,
	Bernd

-- 
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg

Re: Another article abour Reiser4 on linux.com

[Lexington Luthor]

Bernd Schubert wrote:
> Well, by having a FUSE port just more users would use reiser4, which might 
> increase the force to the linux distributors to include reiser4 into their 
> kernel versions. 
> 

I don't think reiser4 would gain many users if it is crippled by being 
in userspace. All the lazy flushing and aggressive caching become 
useless if it cannot interact directly with the pagecache and respond to 
memory pressure. Would you tolerate a 2GB process just to run a 
filesystem? Thats what reiser4 can do if it is in the kernel, and 
silently give back memory only when needed.

> Regarding the speed, I understand that its slower with FUSE, I was also deeply 
> impressed when I read this  
> (http://sourceforge.net/mailarchive/forum.php?thread_id=23836054&forum_id=2697)
> 
> 	But being twice as fast as ext3 is enough currently. It's even faster than 
> 	xfs what I use. Sometimes I'm quite suprised why something is so fast when
> 	I realize that it was actually ntfs-3g :-)
> 

Those micro-benchmarks do not represent anything like normal use. NTFS 
is probably the most complicated filesystem on the planet, so there is 
zero chance that a *working* implementation of it can outperform 
something like XFS... even reiser4 barely beats XFS in many situations 
(actually slower than XFS for heavy local rsync activity).


- LL

Re: Another article abour Reiser4 on linux.com

[David Masover]

Lexington Luthor wrote:
> Bernd Schubert wrote:
>> An alternative might be a reiser4 fuse port. Has some advantages:

> Please please no. The kernel people will use that as an argument for 
> keeping it out of the kernel.

They'll use anything as an argument for keeping it out of the kernel. 
This one is particularly shallow, especially if we still have the kernel 
version, because the performance difference will be significant.

If it isn't, maybe it is time for things like FUSE to take us in the 
direction of microkernels...

> I want reiser4 to be popular enough to 
> make my apps depend on it and not have the users complain about having 
> to use an obscure fs.

Well, an obscure program (FUSE) is probably a lot easier to convince 
users of than an obscure filesystem (reiser4 in-kernel).

> Besides, the only thing about reiser4 that interests me more than XFS or 
> reiserfs is the speed.

That's you.  There are other reasons to like it.

But I agree with you in that I don't think it's worth the resources to 
do a FUSE port, especially when there is (again) NO guarantee that 
anything we do will get us in the kernel, so better to do things that 
will either get us users anyway (like distro inclusion) or do things the 
kernel people specifically ask for.

Re: Another article abour Reiser4 on linux.com

[TongKe Xue]

I'm a total idiot. Please forgive my stupidity.

From a purely technical perspective, what does VFS lack that makes 
VFS-modules so much harder than Reiser-modules?

Thanks,
--TongKe

On Sun, 6 Aug 2006, David Masover wrote:

> Lexington Luthor wrote:
>> Bernd Schubert wrote:
>>> An alternative might be a reiser4 fuse port. Has some advantages:
>
>> Please please no. The kernel people will use that as an argument for 
>> keeping it out of the kernel.
>
> They'll use anything as an argument for keeping it out of the kernel. This 
> one is particularly shallow, especially if we still have the kernel version, 
> because the performance difference will be significant.
>
> If it isn't, maybe it is time for things like FUSE to take us in the 
> direction of microkernels...
>
>> I want reiser4 to be popular enough to make my apps depend on it and not 
>> have the users complain about having to use an obscure fs.
>
> Well, an obscure program (FUSE) is probably a lot easier to convince users of 
> than an obscure filesystem (reiser4 in-kernel).
>
>> Besides, the only thing about reiser4 that interests me more than XFS or 
>> reiserfs is the speed.
>
> That's you.  There are other reasons to like it.
>
> But I agree with you in that I don't think it's worth the resources to do a 
> FUSE port, especially when there is (again) NO guarantee that anything we do 
> will get us in the kernel, so better to do things that will either get us 
> users anyway (like distro inclusion) or do things the kernel people 
> specifically ask for.
>

Re: Another article abour Reiser4 on linux.com

[Hans Reiser]

Bernd Schubert wrote:

>
>
>An alternative might be a reiser4 fuse port. 
>
Fuse is not performance effective.

article abour Reiser4 on linux.com

[Hans Reiser]

Bruce, regarding "a longstanding convention of avoiding plugins in the
kernel", considering that we are the first and only ones ever to have
plugins, and considering the existence of binary kernel modules, I don't
think your characterization is accurate.  Perhaps there was some
licensing controversy on lkml I am unaware of?  Since plugins are
(always) compiled in, unlike kernel modules, I don't see how there is a
licensing issue.

I think your characterization of plugins as something we impose on the
VFS is unfair.  Plugins exist entirely internally to reiser4 --- we
impose nothing on anyone.  I only wish to impose my views on Reiser4,
not on VFS, because I really don't care for haggling with others about
the code they wrote not having the features I want.  I don't think you
should characterize me as saying coding style conformity is the issue:
that is how my opponents portray it, as some sort of 80 characters vs.
120 characters per line disagreement in which I refuse to go along.  I
think social connections prevailing over technical merits is the issue,
and perhaps also whether VFS should intrude deeply into the independence
of filesystem design based on the assumption that the VFS authors are
more likely to get it right, or whether it should let each filesystem do
what it wants to do based on the hope that if enough people try their
own thing in a decentralized system, odds are that one of them will get
it more right than the others and users will be able to choose that FS.

I never made a reference to Steve Lord or Jim Lord, so suggesting that I
got it wrong about him is inaccurate. 

Your characterization of the issue of whether Linux should double its
filesystem performance as a philosophical point seems odd to me --- I
think my writing failed to reach you as an audience on that point.

Reiser4 was first proposed for inclusion in October 2002, and a casual
reader of your article would think it was proposed in 2005.

Many journalists will run my words past me to see if it fairly portrays
my views --- perhaps you might choose to do that with those you write
about in the future.  In my experience it is a good journalistic practice.

On a positive note, it seems like Andrew Morton will singlehandedly turn
the Reiser4 review process into a technical not a political process, and
I am much encouraged by that.  He has made numerous useful technical
remarks in his last email, and we are addressing them.

Thanks for your time,

Hans


Tassilo Horn wrote:

>Hi,
>
>there's another Reiser4 article on linux.com [1], mainly about
>politics. Neither much of the technical discussion is covered, nor are
>the comments too positive, but it may be interesting anyway.
>
>One thing which bothers me most: Whenever such an article appears it's
>commented mostly by kiddies speaking after the mouth of several kernel
>developers, sophisticating most of their comments, ripping them out of
>context or spreading superficial knowledge. Of course those comments let
>it get to possible new users.
>
>Kind regards and keep up the great work,
>Tassilo (pleased Reiser4 user since 2.6.0_testX)
>
>Footnotes: 
>[1] http://www.linux.com/article.pl?sid=06/07/31/1548201
>  
>

Re: article abour Reiser4 on linux.com

[Clemens Eisserer]

Hi again,

> I think your characterization of plugins as something we impose on the
> VFS is unfair.  Plugins exist entirely internally to reiser4 --- we

to be honest I hope the force from kernel developers will not take
away any more abilities and features away from reiserfs!
If reiser4 is tied witth VFS whats about ports to e.g. windows or
other unix systems - its more or less a lock-in ... an own
implementation could solve. XFS also does not integrate well into the
linux kernel (its basically a big mess), so I don't think the "does
not integrate nicely" argument counts at all.

lg Clemens

Re: article abour Reiser4 on linux.com

[Bruce Byfield]

Hans:

I suspect that most of your comments are a result of mild misreadings,
or inferences that may not be inevitable. 

My comments are interspersed below.

On Sun, 2006-08-06 at 03:19 -0600, Hans Reiser wrote:
> Bruce, regarding "a longstanding convention of avoiding plugins in the
> kernel", considering that we are the first and only ones ever to have
> plugins, and considering the existence of binary kernel modules, I don't
> think your characterization is accurate.  Perhaps there was some
> licensing controversy on lkml I am unaware of?  Since plugins are
> (always) compiled in, unlike kernel modules, I don't see how there is a
> licensing issue.

I believe that the controversy has arisen largely with commercial
companies who would like a way to keep their drivers proprietary.
Without actually doing a search, I seem to remember that the last time
the controversy arose was around October or November 2005.


> I think your characterization of plugins as something we impose on the
> VFS is unfair.  

I report that others make this claim. I don't characterize plugins in
any way myself. 

That said, if I were writing the article now, I would certainly mention
your rebuttals on the lkml since then. 

Researching the article, I realized early that I was attempting to
summarize a series of immensely complicated issues for people who might
know almost nothing about it, and my aim was not to take sides, but to
present the highlights as neutrally as possible. That means reporting
opinions that I don't necessarily agree with.

> I never made a reference to Steve Lord or Jim Lord, so suggesting that I
> got it wrong about him is inaccurate. 

I mention something like "Reiser and his supporters," which simply means
that the reference arises during the thread. I believe that you make a
reference to two people working on XFS, one of whom other people later
identify as Steve Lord. 

> Your characterization of the issue of whether Linux should double its
> filesystem performance as a philosophical point seems odd to me --- I
> think my writing failed to reach you as an audience on that point.

I characterized it as a philosophical issue because, although the focus
for everyone is superficially technical, it quickly spills over into
larger issues, such as whether following the conventions is more
important than performance.

> Reiser4 was first proposed for inclusion in October 2002, and a casual
> reader of your article would think it was proposed in 2005.

That was an unintended implication, and I apologize for it.

> Many journalists will run my words past me to see if it fairly portrays
> my views --- perhaps you might choose to do that with those you write
> about in the future.  In my experience it is a good journalistic practice.

Unfortunately, it's not one of which editors approve. It too easily
looks as though the writer is being influenced by the source. 
If I were to do so, I'd risk being banned from publication. 

That said, while I strive for accuracy, I am more than capable of making
mistakes. Moreover, on an issue as complicated as this one, mistakes are
even more likely than usual. That's why comments are an important part
online journalism.

> On a positive note, it seems like Andrew Morton will singlehandedly turn
> the Reiser4 review process into a technical not a political process, and
> I am much encouraged by that.  He has made numerous useful technical
> remarks in his last email, and we are addressing them.

That's good news. It seems long past the time that someone like Andrew
Morton stepped in to allow people to focus.

And when the day comes that Reiser4 is added to the kernel, I hope that
you will let I or somebody else from NewsForge interview you on the
subject. That will be a milestone that many people, including me, have
been waiting a long time for.

> >One thing which bothers me most: Whenever such an article appears it's
> >commented mostly by kiddies speaking after the mouth of several kernel
> >developers, sophisticating most of their comments, ripping them out of
> >context or spreading superficial knowledge. Of course those comments let
> >it get to possible new users.

Tassilo:

As I said to Hans, please step in and correct any misconceptions, either
from the article or its comments. Personally, I take the educational
goals of journalism seriously, and they aren't served by allowing
mistakes to stand unchallenged.

All the best,

-- 
Bruce Byfield 604-421-7177
Burnaby, BC, Canada
http://members.axion.net/~bbyfield

"All the ancient kings came to my door
They said, "Do you want to be an ancient king too?"
I said, "Oh yes, very much
But I think my timing's wrong"
-Dan Bern, "Jerusalem"

Re: article abour Reiser4 on linux.com

[Hans Reiser]

Bruce, I read your article on Linus and GPL V3, and I understand that
you are frustrated by his not going for V3.   I suspect the main thing
that sparked your concern in writing the article about reiser4 is that I
am somehow doing something different that affects licensing, and not
conforming on that issue.  Plugins have nothing to do with licensing
issues --- that was purely Linus getting confused.  Plugins are compiled in.

Bruce Byfield wrote:

>
> I believe that you make a
>reference to two people working on XFS, one of whom other people later
>identify as Steve Lord. 
>  
>
They wrongly identify him.

>
>
>Unfortunately, it's not one of which editors approve. It too easily
>looks as though the writer is being influenced by the source. 
>  
>

>If I were to do so, I'd risk being banned from publication. 
>  
>
Wow.  I thought only the judiciary insulated itself from ever learning
of its mistakes that well.:-/

Re: article abour Reiser4 on linux.com

[Andreas Schäfer]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On 02:28 Wed 09 Aug     , Hans Reiser wrote:
> >Unfortunately, it's not one of which editors approve. It too easily
> >looks as though the writer is being influenced by the source. 
> >  
> >
> 
> >If I were to do so, I'd risk being banned from publication. 

Uhm... interesting. It's not that I have so much experience with the
press (just three interviews so far), but everytime I got the article
for review before publication. It is considered as good manners here
to avoid misquoting. Of course the can always opt to disregard any
changes, but in reality this procedure is just like a two phase
interview with the goal to improve accuracy.

If you didn't trust the source in the first place, why should you
bother to take information from it at all? If you do trust it, why not
ask again?

Just my (humble and uninformed) $0.02 8-)
-Andreas

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: article abour Reiser4 on linux.com

[David Masover]

Andreas Schäfer wrote:
> On 02:28 Wed 09 Aug     , Hans Reiser wrote:
>>> Unfortunately, it's not one of which editors approve. It too easily
>>> looks as though the writer is being influenced by the source. 
>>>  
>>>
>>> If I were to do so, I'd risk being banned from publication. 
> 
> Uhm... interesting. It's not that I have so much experience with the
> press (just three interviews so far), but everytime I got the article
> for review before publication.

> If you didn't trust the source in the first place, why should you
> bother to take information from it at all? If you do trust it, why not
> ask again?

Hmm.  Except in this case, they were summarizing a rather large debate, 
so it's not a question of trusting the source or not, it's a question of 
whether you want to fact-check with every person on reiserfs-list and 
lkml, until you've got the whole thing so debated and watered-down that 
it's meaningless.

Then, too, sometimes it's better to check ahead of time than to get it 
wrong and have to correct later, because people won't always read the 
corrections.

Re: article abour Reiser4 on linux.com

[Bruce Byfield]

On Wed, 2006-08-09 at 02:28 -0600, Hans Reiser wrote:
> Bruce, I read your article on Linus and GPL V3, and I understand that
> you are frustrated by his not going for V3.  

To be honest, it was more the fact that he made an obviously false
statement, and I happened to be in a position to know it was so. Linus'
other comments about GPL3 are at least worth a serious discussion, but
his comment about the procedure was off base.

>  I suspect the main thing
> that sparked your concern in writing the article about reiser4 is that I
> am somehow doing something different that affects licensing, and not
> conforming on that issue.  Plugins have nothing to do with licensing
> issues --- that was purely Linus getting confused.  Plugins are compiled in.

My concern was even simpler than that: The story was one that lots of
people want to know about and that I, personally, would like to see
resolved as soon as possible. 

As for the licensing concerns, I mention them not because they are a
burning issue for me personally (although I do write about them
sometimes, because I have a reasonable amount of experience in dealing
with them, despite not being a lawyer), but because they are one of the
peripheral issues that seemed worth mentioning. 

It would be much easier if everyone separated legal and philosophical
issues from technical ones, and I'd prefer to to do so myself.
Unfortunately, people will keep mixing them.


> Wow.  I thought only the judiciary insulated itself from ever learning
> of its mistakes that well.:-/

Oh, we have ways of learning. As witness this email exchange :)

-- 
Bruce Byfield 604-421-7177
Burnaby, BC, Canada
http://members.axion.net/~bbyfield

"All the ancient kings came to my door
They said, "Do you want to be an ancient king too?"
I said, "Oh yes, very much
But I think my timing's wrong"
-Dan Bern, "Jerusalem"

Re: article abour Reiser4 on linux.com

[Hans Reiser]

Bruce Byfield wrote:

>
>  
>
>>Wow.  I thought only the judiciary insulated itself from ever learning
>>of its mistakes that well.:-/
>>    
>>
>
>Oh, we have ways of learning. As witness this email exchange :)
>
>  
>
You are right, it is only the judiciary.....;-)