From: Rich Cloutier <[EMAIL PROTECTED]>
To: Internet Mail::[[EMAIL PROTECTED]]
Subject: Fwd: Re: [rtl] Real Time Application Interfaces/
Date: 3/12/99 8:18 PM
I think at issue here is the fact that RTL's development is occurring
at too fast a pace to allow in-line development.
In other words, the "stable" releases cannot be made more stable except
by diverging from the main development path. This is the only method that
makes sense if RTL is to be used in such super-critical applications as
that which Mr. Lillard has mentioned. Once thorough testing and debugging
of a stable release has qualified it for these super-critical applications,
the bug fixes cannot then be incorporated into the latest code and used
by these users, because recently added functions will not have had the
benefit of such thorough testing.
Either of two approaches can be taken:
1. Each "stable" release could be beaten to death by interested parties,
and terminate at a truly stable minor release level (dead end,) or,
2. There could be a second development path that lags the first, testing
and debugging each release only when the participants determine that the
previous release is truly "bug free." This group would of course submit
bug fixes to the faster-paced releases to improve the stability of the
"core."
This second option should be the model for open software development anyway,
however not all users (myself included) are qualified to debug the RTL
kernel when we find a problem with it.
Rich Cloutier
========================================
From: Nate Downes <[EMAIL PROTECTED]>
To: Internet Mail::[[EMAIL PROTECTED]]
Subject: Re: [rtl] Real Time Application Interfaces/
Date: 3/12/99 4:34 PM
"Raymond Y. Lillard" wrote:
> Zdenek Kabelac wrote:
> > "Raymond Y. Lillard" wrote:
> > > I find RTL very attractive for all of the obvious reasons, but
for
> > > my comfort I need to see two things.
> > >
> > > 1. Certainity (as best as can be had) that Linux portion of the
> > > OS code contains no suprises. In the Linux development model
> > > the opportunity to mess up is non-trivial. This means to me
> > > that RTL should not be chasing the latest offerings from Linus
> > > and company, but rather focus on more deliberate changes.
> >
> > On the opposite side, I always like to run the latest kernel - there
> > is usually smaller amount of bugs and new features and new supported
> > hardware.
> > So my advice is to concern on the latest kernels. I would like to
> > see the RT-Linux fully working with 2.2 linux.
> >
> > > Toward that end I would like to see as few releases as is
> > > consistant with bug fixing. Let the improvements (new features)
> > > come in larger chunks.
> >
> > Linux is not commercial product and I don't want to wait 3/4 of
> > the year for another 'service pack' to fix some stupid hole
> > in the system - thats simply the difference between the free-open-source
> > unix OS and closed commercial - thus I would be in the same situation
> > as you are by using such system.
>
> I understand your viewpoint and clearly the present development model
> serves your needs well. I am not proposing that the present development
> model be stopped and the code become more closed or stagnate. I am
> proposing that a more stable development model be placed on top of the
> existing efforts, in effect the present layer would feed a more stable
> one. The current rock-and-roll that exists must continue, but versions
> of RTL that are offered to heavy industrial users needs to be tamed.
>
> My experience is largely in the semiconductor process industry where
> a single cassette of wafers, in the later stages of processing, is often
> worth over half a million dollars US. A software malfunction can destroy
> that in the blink of an eye.
>
> I doubt you have the faintest clue as to what is required to qualify
a
> tool for a process line at Intel. While I will not discuss specifics,
> to just say that it is rigorous and data driven is an understatement.
> Change control at successful chip manufacturing companies is not just
> a business practice, it is a religion.
>
> I do not wish to sound condescending. I understand your perspective
> and hope you will try to understand mine. I would like to see
> RT-Linux accepted in heavy industry and am exposing issues that
> impede that goal. Then again, maybe we don't share this goal.
Now, whatI'm seeing here is two differing opinions, each with valid points.
On one hand, someone wants stability at all cost for the RT section of
the
kernel, on the other, someone who wants overall stability (which is what
the
newer kernels offer) In either case, both sides need some kind of resolve.
Unless RTLinux keeps a steady pace with the new kernels, it will be left
behind in the Linux community, and many potential RTLinux customers will
seek
elsewhere for their RT apps, no matter how stable the RT kernel is. All
due
to a 'dated' core.
In either case, we must continue development.
Nate
--- [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/
