Russell Cattelan wrote:
> On Sun, 2006-07-23 at 01:20 -0600, Hans Reiser wrote:
>> Jeff, I think that a large part of what is going on is that any patch
>> that can be read in 15 minutes gets reviewed immediately, and any patch
>> that is worked on for 5 years and then takes a week to read gets
[...]
>> It is importand that we embrace our diversity, and be happy for the
>> strength it gives us.  Some of us are good at small patches that evolve,
>> and some are good at escaping local optimums.  We all have value, both
>> trees and grass have their place in the world.
>>
> Which is summed up quite well by:
> http://en.wikipedia.org/wiki/Color_of_the_bikeshed
> 
> It seem to be a well know tendency for people to want to
> be involved in some way, thus keeping to much of the development
> cycle internal tends to generate friction.

No, I think Hans is right.

Although I should mention, Hans, that there is a really good reason to
prefer the 15 minute patches.  The patches that take a week are much
harder to read during that week than any number of 15 minute incremental
patches, because the incremental patches are already broken down into
nice, small, readable, ordered chunks.  And since development follows
some sort of logical, orderly pattern, it can be much easier to read it
that way than to try to consider the whole.

Think of it this way -- why are debuggers useful?  One of the nicest
thing about a debugger, especially for newbies, is the ability to step
through a program a line at a time.  It's the same principle -- you can
understand the program state at one point in time, and the impact of one
line of code, much more easily than the overall model of the program
state (and all of its edge cases), or the impact of several hundred
(thousand? tens of thousands?) lines of code.

So while I don't blame the Namesys team for putting off inclusion till
it's done, I also can't really blame the kernel guys for not wanting to
read it, especially if it's revolutionary.  Revolutionary ideas are hard
to grasp, and it's not their fault.

I mean, if revolutionary ideas were easy, why didn't you write Reiser4
for a system like, say, Tunes? (http://tunes.org/)  Say what you will,
but there are ways of doing fast filesystems which don't require that
said filesystems be written in kernel C.  Consider this:

http://www.cs.utah.edu/flux/oskit/

If I understand that right, it's a mechanism for writing kernel code in
languages like "Java, Lisp, Scheme, or ML"...

If we could all grasp every single good (best) idea from every corner of
software engineering, and write completely new software (including the
OS) using those ideas, we could potentially replace all existing
software in something like 3-5 years with software which has none of the
problems ours does now.  We'd never have inflexibility, insecurity,
instability, user interface issues...  Never have to worry about getting
software out the door (it'd be so fast to develop), but always have it
designed the right way the first time, yet be able to rearrange it
completely with only 5-10 line patches.

So it's not always the computer hardware that's the limitation.  Often
it's our hardware as well.  Human beings usually aren't equipped to be
able to grok the whole universe all at once.  If we were...  see above.