* Anthony Liguori <[EMAIL PROTECTED]> wrote:
> [...] Did Linux have extremely high quality code in 1994?
yes! It was crutial to strive for extremely high quality code all the
time. That was the only way to grow Linux's codebase, which was ~300,000
lines of code in 1994, to the current 7.2+ million lines of code,
without losing maintainability. Code quality is more important than any
feature. 99% of feature patches sent to lkml get rejected in the first
review round on quality/design grounds, it always takes at least a
couple of iterations to make it nice and clean. Look at Apache, it's
evolving along the same lines. Or Samba. Or any of the really large and
important OSS projects. (even X, after years of struggle and stagnation,
seems to have gotten this point now.) In the past 10 years the OSS
community wrote more than 1 billion lines of new code (!), and all the
successful projects have a clean codebase. _It cannot be done any other
way_, because cleanliness and pride over good code is what keeps
developers and it is what attracts new developers.
now this doesnt mean that Linux's code quality is good in every spot -
it's an eternal fight. But the core subsystems are pretty damn clean.
When i prepare patches for the Linux kernel more than 50% of the work i
do is related to making the changes clean, or cleaning up some existing
aspect of the kernel that the new code triggers. Often it's 90% of the
work!
the 'get functionality now, clean up later' mentality is what leads to
throwaway, use-once codebases that the majority of closed-source
projects do. Once the cruft level reaches a certain threshold it's
cheaper to just throw away old code and just rewrite the whole thing
(users and costs be damned). Cleanups must not be an afterthought, code
cleanliness and gradual code evolution is _the_ most valuable property
of OSS codebases.
i guess my negative Qemu experience is dominated by my recent failure of
trying to untangle its timer code, so that qemu properly adopts to
changes in PIT/lapic programming and maps that correctly to OS timers.
(so that a dynticks/NO_HZ guest's reduced irq rate becomes visible on
the host too) I'll be a happy camper if that's fixed ;-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
