>>>>> "Raymond" == Raymond Y Lillard <[EMAIL PROTECTED]> writes:
Raymond> I understand your viewpoint and clearly the present
Raymond> development model serves your needs well. I am not
Raymond> proposing that the present development model be stopped and
Raymond> the code become more closed or stagnate. I am proposing
Raymond> that a more stable development model be placed on top of the
Raymond> existing efforts, in effect the present layer would feed a
Raymond> more stable one. The current rock-and-roll that exists must
Raymond> continue, but versions of RTL that are offered to heavy
Raymond> industrial users needs to be tamed.
Raymond> My experience is largely in the semiconductor process
Raymond> industry where a single cassette of wafers, in the later
Raymond> stages of processing, is often worth over half a million
Raymond> dollars US. A software malfunction can destroy that in the
Raymond> blink of an eye.
Raymond> I doubt you have the faintest clue as to what is required to
Raymond> qualify a tool for a process line at Intel. While I will
Raymond> not discuss specifics, to just say that it is rigorous and
Raymond> data driven is an understatement. Change control at
Raymond> successful chip manufacturing companies is not just a
Raymond> business practice, it is a religion.
A rather obvious point, probably, is that instability is not just a
property of open software. Indeed, it may well be less an issue with
open software. As any PC user knows, proprietary software can be very
unstable indeed.
My experience with proprietary RT kernels has had its bumps in it. A
big issue is that most of them (though not all) refuse to release
their source code. So not only can't you tell what happened from
version to version, but if things go wrong it is an absolute nightmare
to debug things, even if the support people are good -- which they
often are not. With source code you can see the change history and
you can debug as needed.
It seems to me that change control means you have to assume EVERY
piece of software is guilty until proven innocent. You go through a
major QA effort in-house, because you can't afford to assume that
anyone else has done a good enough job and/or covered the particular
cases that matter. You probably are running way behind the latest and
greatest release, partly because you want to move carefully and partly
because the applications rarely demand the latest bells and whistles
in the first place.
One great feature of Linux is that you can get a copy of every kernel
version ever released. In addition, there's a clear split between
"stable" releases which indeed are quite solid, vs. "experimental"
releases which are still surprisingly solid compared to many
proprietary alternatives, but clearly not as stable as the others.
I'd suggest that RT-Linux would do very well to follow that approach.
It may be that it isn't really far enough along yet, or that it is
just now reaching that point.
paul
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
