On Sat, 2003-01-11 at 17:36, Vojtech Pavlik wrote:
> > I'd say terribly presumptuous, but I don't think it is presumptuous to
> > say that if there are many patches (bug fixes, mostly) coming in that
> > the code that was originally there was of questionable quality.
>
> Very interesting idea. But not correct.
>
> The reason is code rot(*).
Which by definition you gave on the tuxedo.org site is a lack of
robustness in the original code. Again, pointing to the fact that the
original code was not well designed, and hence the term "kernel hacking"
being more relevant than "software engineering" when it comes to linux.
Of course, that is what makes it fun..
> You have never to stop maintaining and patching
> and fixing the code to keep it working.
That's a software developers dream: Never to become obsolete.
One problem I remember UNIX having, and I don't know if this has been
addressed yet, was that UNIX systems that I used to work on had a
forthcoming "Year 2036 or Year 2037" (thereabouts) bug coming whereby
they had no method of representing years beyond that year because dates
were stored as the number of [seconds|minutes|days] since a certain
date. I'm curious if Linux has this same kind of problem, and if we'll
be seeing a rush of "Year 2037 bug fixers" the way we saw year 2000 bug
fixers in 2000 years.
I mention the above to stay relevant to the linux-kernel mailing list,
though forgive me if this is a non-kernel (i.e. library) issue. The
line between kernel and library is always blurry from a programmer's
perspective.
> A perfectly good and clean code,
> if you don't touch it, becomes crusty and smelly over time(**).
Per your comment, re: hardware changing over time, why can't linux just
come up with a nice binary plug-in driver architecture (ok, it has
kernel modules, but from one compile of a kernel to another, the modules
aren't portable). If there were a module plug-in architecture, the
kernel code wouldn't have to change much to support new hardware.
A little "design time" up front (in other words) would save a lot of
coding time later...
Also -- Why hasn't there been a move to something like CVS for the
kernel -- perhaps with linus being the cvs 'god' or whatever the person
who authorizes changes to the code is called. This way you get to
always have the latest code, and check the changes back in without using
an ancient mail text-based interface, and you can describe your changes
(which get forever stored with the change), and changes can always be
backed out. Remember, I'm a newbie, so point me to the FAQ if this is
there.
> This is why
> the number of patches daily entering the kernel is actually a sign of good
> overall code quality. ;)
Oh, I should've known there was a smiley coming <smirk>
-Rob
[Pushing the NVIDIA thread further because I have one of these damned
cards and want support for it in the 2.5+ kernels.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:38 EST