Paul Koning wrote:
>
> >>>>> "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/
>
--- [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/
