"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/
