Hi,
> Rather than a subliminal political dispute we have two open
> disagreements (1) a commercial one and a (2) technical one.
> I've started a company to do some commercial development of RTLinux core
> code in addition to our work at the university. Zentropix is a company
> that previously sold our RTLinux and has apparently
> decided to support Paolo's "RTAI" as an alternative commercial
> strategy. I wish people would cool the advertising in the list, but
> it's natural. So that's the commercial dispute. The technical dispute
> is muddier, but I think really comes out of a design philosophy
> difference in that RTLinux tries to be as absolutely simple as possible
> and RTAI seems to be more oriented towards more features integrated
> into the main system. This is a very interesting and positive
> development, exactly what we are supposed to get in free software.
> Unfortunately we are also getting a little too much "mine is better
> than yours" here, but I don't really know if there is a solution other
> than the delete key.
The above statement is false as it tend to convey the idea that RTAI is
commercial. So first of all everybody should read what I wrote on
15.9.1999, 15:45:22 (browse the mails):
"8) RTAI is and will remain basically an in house effort based primarily
on our in house needs, and on our amusement in developing it. As such it
will be always freely available and we would like people to use it and
help us in getting it better by discovering bugs and building new
features around it, again provided that they will be available to
everyone. Right now something happened in that sense as I got a, for me,
nasty bug corrected by a user, some other users helped to fix a couple
of significant bugs and someone else added a POSIX interface to RTAI. It
is much more than we here expected but nothing was asked and nothing was
promised, and the all stuff remains, updated and free, at
http://www.aero.polimi.it/projects/rtai/."
Now Zentropix has chosen RTAI, for me is good as I get an advertisement
for free. I even go further, they have contributed RTAI with bugs
corrections and POSIX API. Should we RTAI users and developers feel
sorry for that? I myself am happy and thank them for their help. They
wrote a paper on RTAI and I allowed them to put my name on it. Again
thank, I do not have time for writing papers, contrary to Victor I'm not
in computer science and such papers are of no value to me. At the moment
RTAI has got from Zentropix what I have been always looking for: "help"
and discussion "a la pair". They are not the only ones however and I
always acknowledge contributions within RTAI.
So going commercial is only Victor's problem. If Zentropix will stop
using RTAI I will not care, they already made the mistake of using RTL
instead of our RTL variant. RTAI will always live the way explained
above. I want to recall also that I always advised RTL of bugs I
discovered, first in RTAI, and then in RTL. I stopped contributing
specifically since they were often treated as bullshit. Be sure that I
always keep an eye on it because I'm far from thinking that RTL people
are no good, it is exactly the opposite. I always stated that I learned
a lot from them and it all started from the old RTL days, even if the
legacy is now only in fifos.
About "mine being better than yours" for us there is no doubt of that.
With that I'm not saying that we are better, in fact they are likely to
be far better than us in computer science, but just that I can take
whatever RTL application and swiftly put it in RTAI, the opposite is far
from being possible. For sure I know that they can catch RTAI up quite
easily, but I not willing to wait on the prioritiy list of FSMLABS.
> Just to put some technical content in this note, RTLinux has a optional
> approach to floating point. That is, RTLinux tasks are assumed to not
> use FP unles they tell the scheduler that they do want to use FP.
> We do this because non FP tasks should not pay any price for saving
> and restoring FP registers. RTLinux interrupt handler do not automatically
> enable FP, because of the same reason -- in fact, I believe that if you need
> FP in an interrupt handler, you are doing something wrong.
The RTAI approach is not different at all. The true fact, an old story,
is that we got working fp support far ahead of RTL, sent a patch for it.
RTL user had to wait months before getting it "a la Victor". Moreover we
invite anybody to use fp in handlers. Most of the discussion on this
list shows that many of you do not need any scheduler at all but just
irq handlers. See the fp support tutorial at
http://www.aero.polimi.it/projects/rtai/.
> Similarly, semaphores are not integrated
> into the RTLinux default scheduler because there are many many applications
> that do not use semaphores and they should not pay performance costs
> for semaphores. I hope to add some non-semaphore based synchronization
> primitves in the future and also encourage others to experiment.
> And when I began with RTLinux I was convinced that
> nobody had any good ideas about scheduling, so the scheduling component
> had to be made replaceable. All these are part of our keep it simple
> design philosophy and also why I have been very reluctant to take
> patches that integrate new features into the core modules instead of
> providing compatible "add on " or "Replacement" modules.
Here I disagree again. But their is point I want to touch. Our NMT
friends seem to be ashamed of their schedulers. Get the very first RTL
release and see the short comment at the scheduler beginning. In fact
the simplicity of that scheduler, we maintained in RTAI schedulers, is a
strength for the kind of application RTL-RTAI are mostly aimed. It is an
illusion that you can get better performances with another
implementation. On a Pentium 200 we verified that with a fully fledged
scheduler, multiple priority ready and timers queues, for up to 30 tasks
you can gain 1 or 2 us but, if all the tasks are timed, you can even
loose performances. In any case it should be far less on more modern
machines, and 1-2 us are negligible anyhow when you have jitters in
excess of 10 us. (For Victor: believe that the following is nasty but is
said in full friendship) The real point is that computer science
professionals are supposed to do it better; a professor of
aeroelasticity, myself, instead does not care if talking about RTL and
RTAI to his computer science colleagues gets a laughter.
Ciao, Paolo.
--- [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/
