In article <4012ae7a@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> Please reduce a tiny bit your expression of the "POV-code-is-the-best-
> code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
> theoreme.

I didn't say that at all.  And I definitely never said such a thing to the
contrary.

On the other hand, how old is the Mozilla code base, or the Linux kernel?
The POV-Ray code dates back to the mid 1980s.  And it has not required a
rewrite since.  Yet, the two projects mentioned have had their whole design
turned over how many times in just the last five years?

> From those bugs I have found myself in POV code, the code is not as
> high-quality as you consider it to be. I am really sorry to say that
> but sometimes it is healthy to face truth.

Read my other post.  It is very easy to complain about bugs and then to do
nothing about them.  Of course, you just want to do the fun part, but hey,
guess what, everybody want to do just that.  The difference between a
POV-Team member (or everybody with source code access) and the average patch
writer is that a POV-Team member takes the responsibility of a feature's
bugs getting fixed and to make it bug free eventually.

> [BTW, I do not remember my mozilla ever crashing. But I remember
> POVRay 3.5c (official) crashing. But I am using mozilla only when
> konqi does not get along with a page...]

Sure, Mozilla never crashing, not consuming a gigabyte of memory and taking
an hour to start up the first time.  Even Konqueror crashes if fed with the
"right" page.  At least my "version" of it does.  And I tend to use IE 5.2
to view pages in such cases.  Yet, compare Konqueror to Mozilla.  The first
one is well structured with a simple yet powerful and considerate design,
the later is a huge waste of compilation time with *much* more code to do
the same thing.  Code quality is more than just not crashing.  In fact,
crashing bugs are the easiest to find and solve.  The design on the other
hand...

> But stop. I do NOT want to start a discussion here about mozilla, the
> linux kernel, XFree86, the different development models around etc.

Ah, yes, the other two high-profile projects showing clear signs of forking
and serious code quality problems.  Of course, monolithic kernels are such a
great idea, so they flaw must be elsewhere than in the fool who conceived
it.

> Especially, I would ask you not to answer here, that if we would put
> POVRay code in a public CVS and let all the world contribute, then the
> code will be fubar within very short time.

CVS, sure.  Ever looked into the CVS source code?  I had the stupid idea to
do so just three weeks ago.  Two hours later, I rushed to delete it from my
harddisk again.  There are things I don't even want to know, and I really
don't want to know what holds CVS together.  But this shouldn't be the point
here:

Even if the code would not be "fubar within very short time", the ability of
every user to use any new feature would be very quickly.  Of course, I don't
want to point at the contribution of anybody (after all the POV-Team did
pick them up and was and still is committed to the original work and it was
all very useful), but if you look at how some patches had to be used (even
putting their flaws with fixed buffers and such aside) prior to being
included in 3.5, it should not be too hard to get an idea why I am
concerned.  Of course, you cannot know this because you probably never tried
to fix any of the old patches before they were added to 3.5...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message