lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Jul 2006 13:46:18 -0600
From:	Hans Reiser <reiser@...esys.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: the " 'official' point of view" expressed by kernelnewbies.org regarding
 reiser4 inclusion

Is http://wiki.kernelnewbies.org/WhyReiser4IsNotIn truly the "official"
point of view as claimed by its author?  An interesting method of
expression for it.  I heard about it from a user who suggested that I
respond before it got slashdotted.

Let me ask that one compare and contrast the ext4 integration procedure
outlined by Ted Tso, with the procedure experienced by other
filesystems.  The code isn't even written, benchmarked, or tested yet,
and it is going into the kernel already so that its developers don't
have to deal with maintaining patches separate from the tree.  Wow. 
Kind of hard to argue that it is not politically differentiated, isn't it?

Consider what happened with XFS as the article writer mentions.  I met
the original XFS team, led by two very senior developers (Jim Grey, and
another fellow whose name I am blanking on, forgive me, I learned much
from him in just a few conversations).  They were kind enough to
instruct me on what ideas I should take from XFS, and you know what, I
listened.  Reiser4's allocate on flush is the result of their kind
instruction.  I then took it a bit further, like a good student, and
Reiser4 also has balance on flush, compress on flush, etc.

These guys wanted to port XFS to Linux, but there was a problem, which
was that IRIX was better in some ways than Linux, and XFS depended on
those advantages.  Now I met them, and I have to tell you that it was
pretty obvious that these guys knew what they were doing.  Suggest that
these guys needed supervision --- sorry, no way, we needed their
supervision.  What happened?  They got hassled.  Instead of learning
from them, welcoming into our community two very senior developers who
knew a lot more than any of us about the topics they chose to speak
about, they got hassled, they get ignored, they felt rejected, and left
the Linux community forever, never to return.  XFS is still with us, but
the loss of those two could only have been devastating for their
project.    I think the whole kernel community suffered from their loss.

Linux has a problem, which is that with success it is attracting people
with more skill than what it started with, and it is not doing a very
good job of handling that.  In fact, it downright stinks at it, behaving
in the worst way it could choose for handling that.  We have lost quite
a number of FS developers who just don't want to deal with people who
know less than they do but are obnoxious and disrespectful to
submissions because they enjoy powertripping.  We lost David Mazieres,
for example, because he is very very bright, is one of DARPA's most
promising security researchers, and he does not want to be bothered with
Viro et al. so he develops for BSD instead.  Linus, if you really want
to prove that Linux welcomes talented people, go sweet talk Mazieres
into giving Linux another try, you might succeed if you try.  The odd
thing is that Viro is not obnoxious at all in person.  lkml suffers from
email disease, and we need to make conscious efforts to reduce that.

Regarding distros accepting filesystems first, that is just completely
backwards from what it ought to be.  Linus, I respect you a lot, but I
know this one is your idea, and some things I disagree with you on. 
Distros are marketed towards people who do not know how to tar and untar
if an FS is dropped.  A reasonable approach would be to say that any
filesystem marked as experimental can be dropped at any time, so if you
aren't able to tar and untar the partition it is on when a new kernel
comes out, you should not use experimental filesystems.  Then most
distros will not make the experimental FS visible to users who don't
press three buttons acknowledging that they were warned....  Linspire's
view is pretty simple, they need to know that Reiser4 will be accepted
BEFORE they make their distro depend on it.  This is being responsible
to their users.  I could go ask Debian, etc., to include Reiser4, but it
is the wrong way, so I am shy about it.

I am not saying that ext4 should not be accepted as an experimental FS,
I don't even really believe that ext4 should only be accepted when it is
higher performance than Reiser4, I am saying that the process should be
the same for everyone.  Reiser4 is the upgrade for ReiserFS V3, in which
we fix all of V3's flaws without disturbing the mission critical servers
using V3 by changing the V3 code underneath them.  (Things like the bug
affecting MythTV users on V3 at the moment just should not be
happening.  Experiments belong in V4, and I wish there was more respect
for my views on this.).  V4 contains bug fixes for several V3 bugs that
are too deep to fix without deep rewrite, and since V3 does not have
plugins, disk format changes should not get added to a stable branch. 
When submitted Reiser4 was more stable than V3 was when it was
accepted.  (This is because we now have a much better test suite.   I
would never submit code that I know has a bug unfixed.  At the moment we
can crash Reiser4 using our test suite, as some of the linux kernel
inclusion related changes made recently were extensive, I hope we have
that bug fixed by next week.)

We should develop a culture in which acceptance is more based on whose
code measurably performs well than on who is friends with whom.  We
should not think that such a culture will develop without an effort
being made to grow it.

Actually, if we just had a few more akpms to go around, things would be
a lot better..... oh well.  We need to recruit more people like him. 
You can't really have code reviewed by persons less experienced and
proven than those being reviewed, it just doesn't work too well.  Linux
needs to look outward more, and welcome persons who have proven
themselves in other arenas as though we were lucky to get their time. 
Because we are.  Maybe when we don't have people with the expertise to
review something, we should go outside the Linux community, like the way
academic journals will solicit outside reviewers for particular articles
as they need them.  Our current attitude resembles that of BSD before it
lost the market to Linux, I remember it well, there was a reason why I
developed for Linux instead.

Avoiding the problems that some large corporations have with politics
does not happen automatically as a result of it being free software, it
requires as much effort as it does in the successful large
corporations.  Non-profits are in no way immune to being harmed by
internal politics.

If it is true that Reiser4 is likely to go in for 2.6.19, this is good
to hear, though an odd source to hear it from.  If it is true, then I
will skip lobbying distros to accept Reiser4 before the kernel does,
because really it makes little sense for them to do so.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ